The Database Side of a Regulatory IT Audit: Four Questions, Four Kinds of Evidence

Most teams preparing for an information systems audit focus on the application side: the authorisation matrix, the code change process, test records. The database side usually comes up only after the audit has started, and that is where things slow down. The reason is not an absence of records but that the records kept do not answer the question asked.

The Database Facing Side of the Audit

The regulatory framework does not treat the database as a separate heading; it places it inside two general obligations. The first is that access to systems holding confidential data is managed through appropriate authorisation and access control. The second is that accessing information, querying it, and granting or changing access rights are recorded through an audit trail mechanism.

For a database team those two sentences mean this: who reached production data, what they queried, and who was granted which permission must be on record. The record must not only exist; it must also be possible to show that nobody altered it afterwards. Everything an audit asks about the database side follows from those two sentences.

Four Questions, Four Kinds of Evidence

An auditor usually works from a sample and repeats four questions. The table below shows which record answers each question and when that record is not accepted.

In all four cases the rejected evidence actually carries correct information. The problem is not that it is wrong but that the record cannot be verified independently of whoever did the work.

What an Audit Trail Mechanism Means

Keeping logs and having an audit trail mechanism are not the same thing. Three questions separate them.

Who writes the record and who can delete it? If the application writing the record can also delete it, the record does not corroborate itself. Giving the application account insert only rights on the audit table, with update and delete denied, is therefore an installation step rather than a preference.

How is the integrity of the record shown? By signing rows with a secret key, keeping that key outside the database and holding a second copy of the trail in a separate database. A keyless digest chain offers no protection against someone who can write to the database, because it can be recomputed with the same formula.

Is the scope complete? If the record covers only operations that pass through the application, an operation that bypasses it stays invisible. Where the scope is incomplete is exactly where an audit presses hardest.

Five Habits That Weaken the Evidence

1. Producing evidence as screenshots. An image is a statement by whoever took it: when it was taken, with which filters and whether it was edited afterwards cannot be read from it. An auditor will not reject it but will treat it as weak and widen the sample.
2. Opening a ticket after the fact. Raising a ticket in the morning for work done overnight is not a process. The record has to be produced at the moment of the work, by the tool doing it.
3. Keeping the approval rule only in a document. A document describes the rule, a system enforces it. An auditor wants both but accepts the second as evidence.
4. Rewriting history when the rule changes. Today's policy is not the policy of eighteen months ago. A past decision that cannot be shown together with the rule of that day cannot be defended. Freezing the rule set at request time is the only practical answer.
5. Hiding the exception. Cases where the requester executed their own request do occur. Not showing them on the record puts the credibility of the whole process in question once an audit finds one. A visible exception can be managed; an invisible one becomes a finding.

What to Do Before the Audit

Once the audit date is set, the most useful thing to do is not to gather evidence but to test that evidence can be produced. Run this rehearsal:

1. Pick at random a change that ran in production last quarter.
2. Ask the four questions in the table in order, and write down how many minutes and how many systems it took.
3. Repeat the same for one production data request and one permission change.
4. For all three, answer whether your own team could alter that record.

This rehearsal shows where the audit will press before the audit does. That place is almost always the same: where the record exists but cannot be verified independently.

Frequently Asked Questions

We have a database activity monitor. Is that not enough?

An activity monitor records what ran very well, and that is a valuable record. The question it cannot answer is whether the operation was permitted. The permission decision never reaches it. The two do not replace each other: the monitor carries the event, the governance record carries the decision and the reason.

Why should an auditor trust a record we produced ourselves?

What matters is not who produced the record but whether it can be verified. If the audit trail is signed with a secret key, the key lives outside the database and a second copy of the trail is held in a separate database, the claim stops being a statement and becomes a repeatable check. The auditor can run it themselves.

We are a small team. Can we carry this much control?

The weight of the control can follow the risk of the change. An ordinary change moves quickly with a single approval while a high risk one goes through the full process. In a small team the goal is not to give every role to a different person but to stop one person holding two critical roles on the same item of work.

Which records should we keep, and for how long?

Retention is set by the regulation your institution is subject to and by your internal policy; that is outside the scope of this article. On the technical side what matters is that the record cannot be deleted before its retention expires and that deletion itself is recorded. Keeping a daily row count anchor is a practical way to detect bulk deletion from outside the database.