Beyond Compliance: Building Real Cyber Resilience

Certification proves that a management system existed on the day it was audited. It does not prove that the system will hold on the day it is attacked. Both statements can be true at once, and the gap between them is where most incidents happen.

The point is not that compliance is worthless — a well-run ISO/IEC 27001 system is genuinely valuable. The point is that compliance is a floor, and too many programmes treat it as a ceiling.

First, control coverage is reported instead of control effectiveness. A control that exists, is documented and has never been tested under adversarial conditions is a control of unknown value. "Multi-factor authentication is deployed" and "multi-factor authentication cannot be bypassed by a consent-phishing flow against our identity provider" are separate claims, and only the second one is evidence.

Second, scope is drawn to make certification easy rather than to reflect where the business actually holds risk. Production environments, OT networks and third-party integrations are quietly excluded. The resulting certificate is accurate and materially misleading at the same time — which is why sophisticated customers now read the scope statement before the certificate itself.

Third, the improvement cycle stops the week after the audit closes, and restarts eleven months later. Annex A of ISO/IEC 27001 was never intended as a checklist to be satisfied once; the management system exists to run continuously, and a system that only operates in the weeks before an audit is not a management system.

Resilience assumes compromise. It asks how quickly you would detect it, how far it could spread before containment, whether you could operate the business in a degraded state, and how long recovery would truly take — measured, not estimated.

That shifts investment towards detection, segmentation, tested backups, and rehearsed response. None of these are exotic. They are simply harder to evidence in a certificate, which is precisely why they get deferred.

The distinction shows up clearly in backups. A compliance programme asks whether backups run and whether the job completed successfully. A resilience programme asks whether the backups are reachable by an attacker who already holds domain administrator rights, whether restoring the full environment has been timed end to end this year, and whether anyone has verified that the restored data is actually consistent. Backup success rates are close to useless as an assurance metric; restoration evidence is close to conclusive.

The same logic applies to identity. Segmentation, tiered administration and break-glass accounts held offline are unremarkable engineering. What makes them resilience measures rather than compliance artefacts is that someone has confirmed the break-glass credential works, recently, on a system that was not warned in advance.

This distinction is no longer only good practice. NIS2 obliges in-scope entities to report a significant incident within tight deadlines and holds management bodies personally accountable for oversight of cyber risk. Those obligations are about capability under pressure, not documentation: an organisation that cannot determine within hours whether an event is significant will struggle regardless of how complete its control matrix looks.

The practical consequence is that detection and decision-making have become compliance concerns as well as engineering ones. An organisation with excellent paperwork and no rehearsed escalation path is now exposed on both fronts simultaneously.

Ask your team a single question: if the identity provider were compromised at 02:00 on a Sunday, what happens in the first hour? If the answer is a document reference rather than a set of names, decisions and verified capabilities, you have a compliance programme rather than a resilience programme.

Follow it with three more. Who can isolate a production segment without waiting for a change advisory board? What is the last date on which a full restore was completed and timed? If the primary communication platform is the thing that is compromised, how does the response team reach each other? These questions are answerable in an afternoon, and the answers tend to reorder the security roadmap more effectively than any maturity assessment.

The good news is that closing that gap rarely requires new tooling. It requires exercising what you already own.