Passing the audit and being secure are two different projects, and most teams only fund the first. I've walked into organisations with SOC 2 Type II certifications, ISO 27001 badges on their website, and recent clean NIS2 assessments — and found exposed admin interfaces, unrotated credentials from departed engineers, and incident response playbooks that nobody on the current team had read. The audit said yes. The attackers would have said thank you.
Compliance theater is not about lying to auditors. It is about optimising for the audit rather than the threat. These are different optimisation targets, and the gap between them is where your actual risk lives.
What the Audit Is Actually Testing
This is not a criticism of auditors. SOC 2, ISO 27001, DORA technical standards, and NIS2 all have legitimate purposes — they create a baseline of documented controls and a process for reviewing them. The problem is structural: an audit tests whether controls exist and whether they were operating as documented during the audit period. It does not test whether those controls would stop an actual attacker.
The incentive structure flows from that structural problem. To pass the audit, you need documentation, evidence of control operation, and a demonstrated process. To be secure, you need controls that work against real attack techniques, threat modelling that reflects your actual risk profile, and a team that has practised responding to incidents. The first set of deliverables is legible to auditors. The second is largely invisible to them.
Consider what a typical SOC 2 Type II audit actually examines:
| SOC 2 Control Category | What the Audit Tests | What It Doesn't Test |
|---|---|---|
| Logical access | Access provisioning policy exists, reviews documented | Whether terminated employees' access was revoked within 24 hours |
| Change management | Change control process documented, tickets exist | Whether unapproved changes were deployed to production last month |
| Incident response | IR plan exists, roles defined, tabletop exercise run | Whether the team can execute the plan under actual pressure |
| Encryption | Encryption policy documented, TLS enforced | Whether encryption keys are managed securely or in a shared credential store |
| Vulnerability management | Scanning policy exists, remediation SLAs documented | Whether critical CVEs are actually patched within those SLAs |
| Vendor management | Vendor assessment process documented | Whether your highest-risk vendors have been assessed in the last 12 months |
None of these are fake controls. They matter. The issue is that the audit tests the existence and documentation of a process, not the operational effectiveness of that process against the attacks that are actually happening.
The 'audit window' problem
The most sophisticated form of compliance theater is preparing the environment for the audit period and reverting to normal operations afterward. I've seen this explicitly and I've seen it implicitly — teams that run their access review process quarterly because the auditor checks quarterly, but would not pass an unannounced spot check in month two. The audit cadence becomes the actual control cadence, which is almost never the right cadence for the actual risk.
The Five Patterns I See Most Often
In fifteen-plus years across financial services, insurance, energy, and SaaS environments — including post-incident engagements where something had already gone wrong — these are the failure modes that repeat.
Pattern 1: The Policy That Lives Only in Confluence
The organisation has a password policy, a data classification policy, an incident response policy. They are well-written, they reference appropriate standards, they were approved by the CISO. Nobody in engineering has read them in the past year. The policies exist; the behaviours they describe do not.
The audit tests whether the policy exists. It does not test whether engineers follow it, whether it's enforced by tooling, or whether the policy reflects how systems actually work. A password policy requiring 16-character passwords is meaningless if your internal admin tools authenticate via shared credentials that haven't rotated since 2022.
Pattern 2: The Access Review That Reviews Nothing
Quarterly access reviews are a near-universal SOC 2 requirement. The typical implementation: a spreadsheet is generated from identity provider exports, it is sent to managers for "review," managers click approve on most of it because they don't know what half the permissions mean, and the spreadsheet is filed as audit evidence.
What this process does not catch: former contractors whose accounts were never deprovisioned, engineers with production database access they don't need, service accounts with human-level privileges that have never been rotated, and accumulated permissions from three job changes ago that were never cleaned up. The access review ran. The access problem remains.
Pattern 3: The Penetration Test That Tests Nothing Relevant
Annual penetration testing is required by most compliance frameworks. The typical procurement: scope defined as "external perimeter," vendor engagement of five days, report produced with findings categorised by CVSS score, critical and high findings remediated in time for the attestation. Clean report. Renewed certificate.
What the test did not cover: your internal network segment where your legacy ERP lives, your supply chain integrations with third-party data providers, your Kubernetes API server that is not accessible from the internet but is accessible from your developer VPN, or your CI/CD pipeline which is the highest-value attack surface in your environment and is never in the pentest scope.
Pattern 4: The Incident Response Plan Nobody Has Executed
Tabletop exercises satisfy the audit. They do not prepare teams for actual incidents. The gap between a tabletop exercise and an actual incident is roughly the gap between a fire drill and a fire. In a tabletop, people know it's a drill, roles are pre-explained, and the scenario unfolds at a manageable pace. In an actual incident, you have incomplete information, staff you can't reach, systems that aren't behaving as expected, and external pressure from customers, regulators, or the press.
I have been called in to lead incident responses where the IR plan was compliant, detailed, and completely unused. The team was making decisions ad hoc because they had never practised the actual process under any realistic pressure. The plan was a document. It was not a muscle memory.
Pattern 5: The Risk Register That Accepts Everything
Risk registers are a compliance staple. The typical enterprise risk register has 40 to 80 entries, most of them rated medium, most of them with an "accepted" status and an owner who last reviewed them when the register was first populated. Adding "AI/ML risks" and "supply chain risks" to reflect recent regulatory language without changing the residual risk scores is the fastest path to a compliant but useless risk register.
The test for a real risk register
Ask the CISO or risk owner to point to a risk that was accepted last quarter with a documented rationale and a review date. Then ask to see the risk that was escalated to the board in the last six months because it exceeded the organisation's risk appetite. If neither of those exists, the risk register is a compliance document, not a management tool.
What Genuine Security Posture Looks Like
The difference is not about spending more money. I've seen over-budgeted security programmes that were entirely compliance-oriented and under-budgeted programmes that had genuinely strong security practices. The difference is about what you are optimising for.
| Practice | Compliance-Oriented Version | Security-Oriented Version |
|---|---|---|
| Access reviews | Quarterly spreadsheet review, manager approval | Continuous access monitoring, automated anomaly detection, principle of least privilege enforced by tooling |
| Penetration testing | Annual external perimeter test | Threat-model-driven scope, internal and supply chain coverage, red team exercises |
| Incident response | Annual tabletop exercise, plan documented | Quarterly simulations with realistic scenarios, on-call rotation practised, runbooks tested against real systems |
| Vulnerability management | Scanning policy + SLA documentation | CI gate on critical CVEs, continuous monitoring, MTTR tracked as an operational metric |
| Risk management | Risk register maintained, items accepted | Risk appetite defined, risks actively escalated, risk reduction tracked over time |
| Vendor security | Annual vendor questionnaire | Continuous monitoring of critical vendors, contract security requirements, right-to-audit clauses |
None of the security-oriented practices are exotic. They're simply oriented toward the threat rather than the audit. The reason most organisations default to the compliance column is resource constraint combined with audit deadline pressure. The audit has a date. The attacker does not.
The Regulatory Paradox
Here is the tension that is worth naming explicitly: compliance frameworks are becoming more prescriptive at exactly the moment when they are becoming less sufficient. NIS2, DORA, and the CRA are materially more demanding than their predecessors — they require specific technical controls, documented processes, and in some cases near-real-time incident reporting. Complying with them requires genuine effort.
But complying with them is still not the same as being secure, because no framework can anticipate every attack technique, and no audit cadence can match the speed at which threat actors evolve their methods. The frameworks define a floor, not a ceiling. Organisations that treat compliance as the destination rather than the minimum have confused the map for the territory.
The organisations with the strongest security postures I've encountered are compliant as a by-product, not as a primary objective. They do threat modelling because it improves their actual risk position. The compliance attestation reflects that.
How to Diagnose Whether You're in Theater
Run these five tests. They take less than a day and give you an honest picture.
Test 1: Ask any senior engineer to describe your incident response process without looking at the plan. Note what they get right and what they get wrong.
Test 2: Pick any five accounts in your identity provider and trace their access history. Check whether access was removed within your policy's defined window when those employees left or changed roles.
Test 3: Pull the last penetration test report. Identify the three most critical findings. Check whether all three were remediated. Then ask whether any of those findings covered your CI/CD pipeline, internal network segments, or supply chain integrations.
Test 4: Open your risk register. Find the most recently "accepted" risk. Ask the owner to explain, without prompting, what controls are in place and when they last verified those controls were operating as expected.
Test 5: Generate a list of your ten highest-risk third-party vendors. Check when each was last assessed. Check whether your assessment questions have been updated to reflect your actual current integration scope.
If any of these tests surface a gap, you are not alone. The gap between compliance and security is the default state for most organisations operating under audit pressure with finite security resources. Knowing where the gap is, is the starting point for closing it.
If you're preparing for a NIS2, DORA, or SOC 2 renewal and you want an honest assessment of whether your controls would survive an actual incident — not just an audit — let's talk. Book a 30-minute discovery call. I'll tell you what I see and where the real exposure is.