Insights
Why Most Cybersecurity Audits Don't Survive Reality
A cybersecurity audit gets finalized in March. Sixty-page PDF, properly bound, signed off by everyone whose signature was needed. It lands in a SharePoint folder. The audit committee notes its receipt. Boxes are checked.
In June, an organization in the same sector — same regulator, same general posture — gets compromised by exactly the kind of vulnerability the March audit had flagged on page 38. The findings were correct. The recommendations were sound. Nothing was technically wrong with the audit.
So what failed?
After two decades of running these programs across utilities, banks, government, and industrial estates, I've concluded that the audit profession has a quiet, expensive secret: most audits don't fail at the audit. They fail at everything that comes after. And the patterns are repeatable. There are four of them.
1. The audit gets filed and forgotten
The most common failure mode is the simplest. The audit is treated as a deliverable, not a starting point.
Once the report is signed and the closing meeting concludes, ownership evaporates. The CISO has the next quarter's priorities to manage. Operations has its own list. Internal Audit moves to the next program in the plan. The findings sit in a tracker that gets reviewed at quarterly committee meetings, and the only column that updates is the "target date" — which slides quietly to the right, then to the right again.
Six months later, half the high-severity findings are still open. Nobody owns getting them closed; they're just managed in a register.
This isn't malice. It's structural. The auditors did their job — find and report. The remediators are doing theirs — operate the business. There's a gap in the middle where someone needs to own the follow-through, and that role usually doesn't exist.
What works instead: treat the audit closing meeting as the start of a 90-day remediation program with a named owner, a weekly cadence, and an end-of-program report-out to the same forum that received the audit. The audit answered "what's wrong." The remediation program answers "what's done about it." Both deserve their own discipline.
2. Findings are too abstract for the people who have to fix them
A finding reads: "Network segmentation is insufficient between the corporate IT environment and the OT process control network. Recommendation: implement Purdue Model–aligned segmentation with defined trust zones and documented conduit traffic."
That's a defensible finding. It maps to IEC 62443. It's how the standard wants you to think.
But the control engineer reading it on Monday morning is staring at twelve cabinets, eighty PLCs, four substations, and a maintenance schedule. Their question isn't "what does the standard say." Their question is "what do I unplug, what firewall do I order, and which vendor support contract do I update."
When the gap between the finding and the work to remediate it is too wide, the work doesn't happen. People aren't lazy — they're prioritizing what they can act on.
What works instead: co-author findings with the team that has to implement them. Before the report is finalized, walk the high-severity findings with operations leads. Translate "implement segmentation" into a concrete project: which cabinets, which devices, which conduits, which order, which week. The auditor doesn't have to do the project plan — but the finding should be specific enough that the project plan is obvious.
This adds a week to the audit. It saves quarters of stalled remediation.
3. Recommendations that ignore production reality
The audit recommends patching all OT devices to current firmware within 30 days.
The plant manager has been trying to get a four-hour maintenance window for that exact patch since last August. The window keeps getting pre-empted by production demand. The vendor will only certify the patch on a major-release cycle, not on the auditor's timeline. The reactor doesn't shut down because someone in compliance wrote "30 days."
Recommendations that ignore the operating reality of the system don't get implemented. They get politely deferred. The risk register gains another row marked "compensating controls in place" and the underlying issue stays open.
The auditor's instinct here is correct — the device should be patched. But the question isn't whether it should be. The question is what intermediate state buys down the risk while the proper patch is sequenced into a real maintenance plan.
What works instead: build recommendations that respect the operating envelope. "Patch within 30 days" becomes "isolate the device behind a one-way gateway within 30 days; patch in the next scheduled outage; if the outage doesn't happen by Q4, escalate to the steering committee." That's a recommendation operations can actually agree to and act on. The risk gets reduced now, the proper fix lands when it can, and the escalation path is documented in advance instead of negotiated under pressure.
4. Compliance theatre — controls that pass the audit but wouldn't survive an attacker
This one is the most uncomfortable.
A control passes the audit because it satisfies the test the auditor is running. The test is derived from the framework — ISO 27001, NIST, IEC 62443, take your pick. The framework was written by smart people. But frameworks codify yesterday's understanding of how attackers behave. A control that satisfies a 2018-vintage test may have very little to do with whether it survives a 2026-vintage attack.
Multi-factor authentication on the VPN passes the test. Does it survive an attacker who phishes a session cookie? Maybe, maybe not — depends on how the MFA is implemented and whether the session lifetime allows token replay.
Network segmentation between zones passes the test. Does it survive an attacker who pivots through a vendor's remote-access tool that has a documented exception in your ACLs? Probably not.
The audit isn't lying. The control does exist. It just exists at the level of "is the policy in place" rather than "does the policy work against an active adversary."
What works instead: adversarial review. Once the control framework audit is done, run a second pass with one question: "How would the attack we saw at [peer org] last quarter work against these controls?" You're not retrofitting the audit; you're stress-testing its conclusions. Sometimes the controls hold and the audit's confidence was warranted. Sometimes they don't, and you've found the next audit cycle's high-severity findings six months early.
This is what mature security organizations do quietly under different names — "purple team exercises," "tabletop testing," "adversary emulation." Most regulated organizations don't, because the audit framework didn't ask for it.
What changes when your next audit is built differently
If any of the above sounds familiar, the question to bring to your next audit isn't "did we satisfy the framework." It's:
- Who owns turning these findings into closed work, on what cadence, with what accountability?
- Are the findings written so the people implementing them know what to do Monday morning?
- Do the recommendations work inside our actual operating envelope, or are they written for a system we don't have?
- Have we tested the controls against attacks we know about, not just against the framework?
These four questions don't appear on standard audit checklists. They should.
The audit profession isn't broken. The audit delivery model is. The fix doesn't require new frameworks — it requires changing how the audit handshakes with everything that happens before and after it. That's where the next decade of cybersecurity assurance gets won or lost.
If your organization is preparing for a regulatory audit, recovering from one that didn't translate into change, or trying to make the next one count — I'm available for selective advisory engagements. The contact form on singleclick.ae comes straight to me.