What the war room looks like
Quarter ends. The audit approaches. The chat channels explode and the emails fly. Teams scramble to collect evidence from fourteen different tools. Someone discovers a control that was, it turns out, someone else's job. The CISO becomes a project manager chasing screenshots. If that sounds familiar, you do not have a compliance programme. You have a panic programme, and most organisations are running exactly that.
A compliance operating system in one view
Seven layers, bottom up, always running. Each one removes a reason for the war room.
| Layer | What lives there | What it removes |
|---|---|---|
| 07 Regulatory governance | ISO 27001, PCI DSS 4.0, RBI directions, DPDP, audit and certification, all mapped to the same controls | One control, several regimes, no duplicate work |
| 06 Control tower | Compliance percentage, control effectiveness, risk heat map, audit-readiness score | The status meeting |
| 05 Analytics and correlation | SIEM, logs, metrics and traces correlated daily, weekly, monthly | Detection as a separate, unrelated programme |
| 04 Evidence engine | Logs, alerts, scan reports and access records collected by the system, not by people | Most of the panic |
| 03 Execution workflows | To do, in progress, evidence, review, closed; every control has an owner and a service level | "Someone else's job" |
| 02 Single source of truth | Activity register, ISO and PCI mappings, frequency model, in one place | Fourteen tools and version chaos |
| 01 Enterprise systems | Payment systems, APIs, databases, containers and cloud: where the risk actually lives | Compliance that describes a system nobody runs |
- Evidence collected from fourteen tools in the last fortnight
- The CISO chases screenshots
- A control turns out to be someone else's job
- A war room, every quarter
- Evidence generated by the systems as they run
- Every control has an owner and a service level
- Detection and compliance read the same data
- A control tower, always on
The problem is architecture, not people
It is tempting to read the war room as a discipline failure and answer it with more reminders and a stricter calendar. It is not a discipline failure. Compliance was never designed as a system. It evolved as a checklist, and checklists do not scale: they do not know which system a control lives in, who owns it, how often it should produce evidence or what that evidence should look like. So every audit rebuilds that knowledge from scratch, under time pressure, from memory.
Old way: compliance happens before an audit. New way: compliance happens every single day.
Seven layers, bottom up
What every enterprise and every fintech needs is a compliance operating system: seven layers, built from the bottom up, always running. Layer one is the estate itself, the payment systems, APIs, databases, containers and cloud accounts where the risk actually lives. Layer two is a single source of truth: the activity register, the ISO and PCI mappings and the frequency model in one place, with no version chaos. Layer three is execution: every control moves through to do, in progress, evidence, review and closed, and every control has an owner and a service level. Layer four is the evidence engine, which I return to below. Layer five is analytics and correlation, the SIEM, logs, metrics and traces already running for detection, read for compliance as well. Layer six is the control tower: compliance percentage, control effectiveness, a risk heat map and an audit-readiness score on one screen. Layer seven is regulatory governance, where ISO 27001, PCI DSS 4.0, the RBI directions and the DPDP Act are mapped to the same underlying controls, so one piece of evidence serves several regimes.
EstateSystems, APIs, data stores, containers and cloud accounts. Compliance starts from what is actually running, not from what the policy says should be.
Single source of truthOne register of controls, activities, mappings and frequencies. If two documents disagree, the system has already failed.
ExecutionA workflow per control with an owner and a service level. A control with no owner is a finding waiting for an auditor to write it.
Evidence engineLogs, alerts, scan results and access records collected by the systems that produce them, time-stamped and attributable.
AnalyticsThe detection stack read for compliance: the same correlation that finds an incident also shows a control working.
Control towerOne view of coverage, effectiveness and readiness, for the CISO and the board, updated as the estate changes.
Regulatory governanceEvery regime mapped to the same controls. Mapping supports your assurance; it is not certification, and the tower should say so.
Evidence that generates itself
Layer four is the one that changes the experience of an audit. Auditor-driven evidence is a screenshot taken under pressure by someone who is not sure it is the right screenshot. System-generated evidence is the access review the identity platform produced on the first of the month, the scan report the pipeline attached to the build, the alert the SIEM raised and the ticket that closed it. It exists whether or not an audit is coming, it carries its own time stamp and its own author, and nobody has to be asked for it. This single layer removes most of the audit panic on its own, because most of the panic is the collection.
Two disciplines make it work. Evidence has to be attributable, so that an auditor can trace a record to the system and the moment that produced it. And evidence has to be tamper-evident, so that the same auditor can check it was not edited between then and now. Both are engineering properties, and both are cheaper to build in than to argue about afterwards.
From war room to control tower
The difference between the two models is easiest to see in what the CISO does in the week before an audit. In the old model the CISO chases evidence. In the new model the evidence has already generated itself, and the CISO reads the control tower: which controls are effective, which are drifting, which regimes each finding touches, and how ready the organisation is today rather than how ready it hopes to be by Friday. The war room is replaced by a screen that was there all along.
Old way: CISO chases evidence. New way: evidence generates itself. Old way: war room. New way: control tower.
Where to begin
Do not start with the tower. Start with layer two: write down every control you are audited against, in one register, with a system, an owner and a frequency beside each. The gaps in that table are your first findings, found by you rather than by the auditor. Then take the five controls that consumed the most hours in your last audit and make each one produce its own evidence from the system that runs it. When those five need no war room, you will know how to do the rest.
Be honest: is your organisation still in war-room mode before audits?
Krishna works at the intersection of cyber security, infrastructure, AI and enterprise risk, with a focus on engineering trustworthy and resilient technology foundations.
Follow on LinkedInThis perspective expands a post first published by the author on LinkedIn.
