Contents
An organisation has a ticketing system, a delivery pipeline, a database activity monitor and a log platform. Each was bought separately, each runs separately and each produces correct data. Yet answering one question from an auditor takes half a day. This article gives that half day a name: the correlation tax.
The Auditor's Single Question
The question asked in an audit meeting is usually this simple: "Who requested the change made to the production customer table at 14:00 on Tuesday, who approved it, and was the text that ran the text that was approved?"
The question is simple because it concerns one event. The answer is hard because it does not live in one system. The organisation struggles not because it cannot answer, but because it has to assemble the answer.
Four Systems, Four Half Answers
The pieces of the answer sit in four places, and each piece knows something the others do not.
| System | What it knows | What it does not know |
|---|---|---|
| Ticketing | What was asked for, who asked and the business reason | The final text of the script; it may have changed many times after the ticket was opened |
| Delivery pipeline | What it carried, and which version went to which environment | Work that reaches production outside the pipeline; emergency fixes usually bypass it |
| Database activity monitoring | What ran, from which session and at which second | Why it ran and who allowed it; the record forms after the event and does not prevent it |
| Email and chat | How the decision was really taken and who gave the go ahead | It proves nothing; it can be deleted, edited and is not accepted as evidence |
Nothing in this table is missing as a record. What is missing is the link. No field ties the ticket number to the text that ran, the text that ran to the approval decision, and the approval decision to the rule in force that day.
A common mistake: collecting more logs
The reflex answer is usually to collect more data: raise the log level, add another collector, feed a new source into the SIEM. The result is the same half answers in greater volume. The problem is not missing data, it is the absence of a shared identity across the records.
What the Correlation Tax Is
The correlation tax is the human effort spent turning correct records held in separate systems into a single narrative. It is paid in three places.
During the audit. The auditor picks a sample, evidence is requested for each item, and it is collected as screenshots from different systems. In most organisations this consumes several people for several weeks per audit.
During incident review. When something breaks in production, the first question is what changed in the database in the last 24 hours. Finding out means aligning timestamps across systems by hand. Meanwhile the outage continues.
In daily work. If answering whether a change was approved starts a chat thread, the tax is being paid every day. This item never appears on an invoice, which is why it stays invisible.
Why It Grows Every Year
Correlation cost does not grow linearly with the number of systems. Every new system increases the number of pairings that must be maintained: three systems need three pairings, five systems need ten. As the tool count rises, the cost of producing evidence grows faster than the count itself.
The second source of growth is time. Rules change. Today's approval policy is not the policy of eighteen months ago. When an auditor asks about a past event, you also have to show the rule as it stood then. If no past state of the rule set is kept anywhere, proving that a past decision was correct becomes impossible.
The "which rule was in force that day" question
This is the hardest question in an audit, because the answer sits in the configuration of that day rather than in a policy document. Freezing the rule set at the moment of the request means no later change can blur a past decision.
Not Paying It: One Record
Escaping the correlation tax is not about reducing the number of tools. The tools can and should stay. What has to change is that every piece of work bound for production receives one identity at birth, and that identity carries through every stage.
In a single record model these fields sit on the same row:
- Who opened the request, the business reason and a ticket number matching the organisation's format rule
- The script itself and the rules it triggered
- The rule set frozen at request time and the rationale behind the risk assessment
- The approval steps the policy produced, and who completed each one and when
- The script digest computed at execution time; the proof that the approved text and the executed text match
- The outcome, the error text if there was one, and the trace of any rollback that ran
When these fields live on one record, the auditor's question stops being a search exercise. You give the request number, open the record and the whole answer is there.
Trusting that record requires two conditions. First, the record must be tamper evident: the audit trail signed with a secret key and a second copy kept in a separate database. Second, the system that writes the record must not hold the right to delete it. Without both, a single record model is merely a tidier list.
Measure Your Own Setup
You do not need to look at a budget to find out whether you pay the correlation tax. Ask your team these five questions and measure how many minutes the answer takes.
- Pick a change that ran in production last month at random. Can you show the final script, the approver and the reason for approval on one screen?
- For that same change, how do you prove that the text which ran matches the text that was approved?
- Can you show which approval policy was in force on that date?
- How many separate paths deliver change to your production database, and how many land in the same record?
- Can the team that keeps the record alter it? Can you verify independently that it has not been altered?
If you cannot answer three of the five within minutes, the problem is not your tools. They are doing their own jobs correctly. What is missing is the layer above them that ties the decision to the evidence.
Frequently Asked Questions
Can we solve this by adding fields to our ticketing system?
Partly. You can add a script field to the ticket and even define approval steps. What cannot be solved is that the ticketing system cannot see what ran in the database. Proving that the approved text and the executed text are the same requires a digest computed at execution time, which is outside a ticketing system's reach.
Our SIEM already correlates events. What is the difference?
A SIEM correlates events that already happened, and it does that well. What it cannot know is whether an event was permitted, because the permission decision never reaches it. A SIEM can say a query ran; it cannot say the approval required for that query had been obtained. The governance layer produces that second sentence, and it does not replace the SIEM.
Does this layer not slow the process down?
What slows things down is not control, it is applying the same weight of control to every change. A model that gates by risk band speeds ordinary changes up and sends only high risk ones through the full process. The number to measure is not how many approval steps exist, but how long a request takes from opening to execution.
Where should we start?
With one production server. Instead of a programme covering the whole estate, bring every path into your most critical server onto a single record. A quarter later you will be answering the auditor's questions about that server within minutes, and widening the scope with that proof in hand is far easier.
See it on your own records
We will walk the flow from opening a request to the sealed evidence file, live and with your own scenario.
Book a Demo →