Log Management Does Not Produce Audit Evidence

Log management platforms are mature and effective tools. Central log collection in an organisation is good news. But when an auditor asks to see the evidence for a change, it helps to understand why the output of a log platform falls short. This article is about that difference.

The Common Assumption: We Collect Logs, So We Have Evidence

There is a sense of relief when a central log platform goes live. If servers, applications and databases all ship their logs to one place, it feels as though any question can be answered.

The first audit tests that assumption. The auditor picks one change and asks: who requested it, against which rule was it assessed, who approved it, was the text that ran the text that was approved. The log platform has no answer, because a log records an outcome, not a decision.

A database log contains a line saying that at 09:40 on Tuesday this statement ran against that table. The line shows the statement. It does not show the decision, the reason, the approval or the rule in force that day. Those are exactly what the auditor is looking for.

Three Differences Between a Log and Evidence

The difference is not in the format but in the moment of production.

• A log is written after the event; evidence forms with it. A log line is the system's observation once the work is done. Evidence is produced at the same moment as the decision: who approved, under which rule and with what reason all enter the record then.
• A log is a set of independent lines; evidence is a chain. Deleting a log line leaves no trace anywhere. Deleting a record from a chain breaks it, and verification shows exactly where.
• A log carries no context; evidence arrives with it. The gap between "this statement ran" and "this statement ran under this request, after the two approvals the policy required, in an execution started by this person" is the whole of an audit.

Does Immutable Storage Solve It

Write once storage, retention locks and similar features provide real protection and should be used. But the problem they solve is a different one: they prevent a log from being altered after it is stored. They touch nothing that happens before storage.

A record written incompletely at the source enters immutable storage incomplete. A record never written never enters it at all. The storage layer cannot know about an event that never reached it, and this is the point most often missed in an audit.

The second limit is how integrity is demonstrated. Immutable storage says the file has not changed, and the proof of that is the storage system's own assertion. A chain embeds the proof in the data itself: the linkage between records can be shown without trusting the storage system at all. Independent verification by an auditor needs the second.

Which Layer Answers Which Question

The fifth row is missed in most organisations. A rejected request leaves no trace in production because it never ran. Yet it is exactly the evidence an auditor needs to be convinced that the control actually filters anything.

Using Both Together

This is not a replacement argument. The log platform should stay; the job it does is one the governance record does not.

The log platform looks broad: it collects every system and every event and detects anomalies. The governance record looks narrow and deep: it covers only database changes and production data access, but for each one it carries the decision, the reason and the approval.

The place where the two layers meet is the valuable one. The log platform says a table changed in production on Tuesday night. The governance record says whether that change was permitted and which approval it rests on. An event visible in the log platform with no counterpart in the governance record is the most valuable finding of all: a change that came from outside the process.

Building that intersection does not require a third tool. Data exported from the governance record can be fed into the log platform; today that flow is one way and triggered by hand, with no ready made connector. It is still enough to build the intersection, and most organisations run it as a quarterly reconciliation.

Frequently Asked Questions

Do we need to replace our log platform?

No. The two layers answer different questions and neither replaces the other. The log platform detects anomalies across a broad scope; the governance record produces decisions and evidence in a narrow one. The right setup runs both and reconciles their intersection regularly.

Can you forward audit records to a SIEM?

Records can be pulled and exported over the application interface; a ready made connector and live streaming do not exist today and are on the roadmap. We state this plainly because your evaluation should rest on what exists now. Periodic export has been sufficient for many organisations.

Is the database's own audit feature not enough?

Database auditing records what happened very well, and that has its own value; only it surfaces an intervention made without touching the application. What it does not show is the decision: the request, the reason, the approval and the rule in force that day. Database auditing is also a feature managed by the database administrator, and whether the audited and the auditor are the same person is an auditor's first question.

What should the retention period be?

In a log platform, retention is a cost decision and is usually measured in months. A governance record is different: its volume is far smaller and deleting from it breaks the chain. SQL Change Guard does not delete audit records on its own; retention is left to the organisation's database and archive policy. If a record has to be removed, it should be done knowing that chain verification will show it.