The Performance
Most security programmes perform to produce a certificate, not to protect the business. Everyone involved knows it.
You passed your security audit. Congratulations. The ISO 27001 certificate is on the wall. The sales team is already using it in proposals, and the LinkedIn post got 200 likes.
Let me ask you something. If a critical vendor went down tomorrow — the one that hosts your customer database, or the one that notifies users about transactions — how quickly could you identify which of your services are affected — not just the obvious ones? Which customers would be impacted? What contractual notification obligations kick in?
If the answer is minutes, you have a security programme. If the answer is hours, or days, or “I’d need to ask someone,” you have a certificate, and on its own, it’s just a decoration.
The certificate looks the same on the wall of a company that runs its programme continuously and a company that scrambles for six weeks before the audit. The auditor can tell the difference — most of them — but the certificate doesn’t reflect it. Your customers can’t tell the difference. Your board doesn’t ask.
In the end, the audit is binary: you passed or you didn’t. Your actual security posture is a spectrum. The gap between the two is the reality you live in — and what this book is about.
The rational minimum
A thought experiment that makes security professionals uncomfortable:
If the certificate is the same regardless of how well you run your programme, and the certificate is what the business is paying for — why would a rational organisation do more than the minimum required to pass?
The answer is: many don’t. And the ones that don’t aren’t negligent. They’re doing the rational thing, given the incentives in front of them.
Think about it from the CFO’s perspective. Security costs money. The security team wants headcount, tools, time from other departments. The measurable output is a certificate. The certificate is achieved at a certain level of investment. Increasing the investment beyond that level produces no immediately measurable output — the certificate is the same. In an environment where spending is scrutinised line by line, the rational investment is the minimum that produces the certificate.
From the CTO’s perspective: security competes with product development for engineering time. Every hour spent on access reviews is an hour not spent shipping features. The access review needs to happen — the auditor will check. But it needs to happen at the minimum depth that satisfies the audit, because anything beyond that has no visible return.
From the security lead’s perspective: you know the programme could be better. You know the risk register is partially stale. You know some evidence was assembled retrospectively. But you also know that raising these issues gets you one of two responses: a budget discussion you’ll lose, or a conversation about whether the current approach is “good enough.” It is good enough — to pass. And passing is what was asked for.
This isn’t laziness. It’s economics. The system produces exactly what it incentivises: a certificate.
The annual panic
This is what the year looks like in a typical security programme. I’m going to describe it, and it’s going to sound familiar.
Months one through nine: The programme runs on autopilot. The risk register exists but nobody looks at it. Policies exist but nobody reads them. Access reviews are supposed to happen quarterly but they’ve slipped. The asset inventory is somewhere — probably a spreadsheet last updated before the last audit. The security lead — or whoever security landed on — is busy with other things, because security is rarely their only job. Tasks accumulate. Evidence doesn’t.
Month ten: The external audit dates are confirmed — eight weeks out, and nothing can be postponed any longer. A mild panic sets in. The security lead starts reviewing what’s current and what isn’t. The answer: not much is current.
Month eleven: The mild panic turns into irritation — why am I the only one who cares about this? Evidence needs to be collected for the past year. But the evidence doesn’t exist, because the work wasn’t done when it should have been — or it was done but not documented. So evidence is assembled retrospectively. The access review that should have happened in Q2 is conducted in Q4. The evidence is dated November, and presented in the hope that nobody looks too closely at the rhythm. The risk register is updated to reflect current reality, but the update is recorded as though it was a routine review, not a pre-audit scramble — and the story of how the risks actually moved during the year is lost entirely. Policies are opened, the revision date is changed, and they’re closed again.
I’m not describing fraud. I’m describing what happens when a programme is designed around a deadline rather than a rhythm. The work is real — compressed into six weeks instead of spread across twelve months. The evidence is retrospective: a snapshot, assembled to look like a cadence.
Month twelve: The audit. The auditor arrives, samples evidence, asks questions. The security lead has prepared meticulously — for the audit. The programme looks good enough. The auditor notes a few observations, maybe a minor non-conformity. The certificate is renewed.
Month one: The cycle resets. Everyone is tired (and happy we passed). The programme returns to autopilot. The lessons learned from the audit scramble are: start earlier next year. They won’t.
This is the annual panic cycle. It’s so common that it’s normalised. People talk about it as “audit season” — as if the concentration of an entire year’s security work into six weeks were weather, not a decision the industry has collectively made.
Everyone knows
Here’s the part that makes people squirm.
The auditor knows. Experienced auditors can tell the difference between a programme that runs continuously and one that was assembled for the audit. They see the evidence dates clustering in October and November. They notice the risk register updated the week before the audit and not since the last one. Policies “reviewed” without a single substantive change.
But the audit isn’t designed to fail you for this. The audit checks whether the programme meets the standard’s requirements at the time of the audit. If the evidence is there, if the controls are documented, if the risk register is current (as of now), the programme passes. The auditor’s primary job is to assess conformity, not to investigate the operational rhythm behind it.
The CISO knows. Or the security lead, or whoever manages the programme. They know which controls are genuinely operational and which ones are maintained just enough to pass. They know the difference between the programme as described in the Statement of Applicability and the programme as it actually runs day-to-day. This knowledge is carried privately, because surfacing it creates problems without creating solutions. Admitting that the programme is partially theatre doesn’t reduce the theatre — it just makes you the person who admitted it.
The board knows — or at least suspects. They see the annual spike in security activity before the audit. They notice that security is invisible for ten months — unless there’s an incident — and then suddenly urgent for two. They’ve learned not to ask too many questions, because the answer is “we need more budget” and the certificate arrives anyway.
Everyone involved in the system understands, at some level, that the programme is not quite what it appears. But nobody has an incentive to say so. The auditor’s incentive is to conduct a thorough assessment. The CISO’s incentive is to pass the audit. The board’s incentive is to have a certificate. The system perpetuates because the incentives align around the performance, not around the substance.
The trust death spiral
The performance creates a cost that doesn’t appear on any budget: trust.
When the security team knows the programme is partially theatre, they stop investing in it emotionally. Their relationship to the programme becomes transactional — just do what’s required. When the business sees security as a cost centre that produces a certificate, they invest the minimum. “We already passed the audit” wins resource conversations. When non-security staff experience the programme as a tax — an annual burst of confusing requests that produces a formal piece of paper — they disengage. Everyone complies. Nobody truly cares.
Each response is individually rational. Collectively, they create a death spiral. Less investment produces weaker programmes, which produces more theatre, which produces less trust, which produces less investment. The certificate continues to arrive on schedule. The programme behind it hollows out.
Compare year one — when the certification was new and people were genuinely building something — to year four, when it’s running on inertia and audit preparation. The certificate looks the same. The programme doesn’t.
Compliance-driven vs. reality-driven
Let me name the structural root of the performance, because it matters for everything that follows.
A compliance-driven security programme starts from the framework. What does ISO 27001 require? What does the auditor expect? The programme is shaped by the standard’s requirements, and the business’s reality is fitted into that shape.
This produces a programme optimised for the audit. Controls are selected because the framework lists them. Evidence is structured because the auditor expects it. The Statement of Applicability is the programme’s spine, and everything else hangs from it.
A reality-driven security programme starts from the business. What do we actually do, what are we protecting, and what would genuinely hurt? The programme is shaped by the organisation’s actual security goals, and the framework is used as a lens to verify that the programme is comprehensive.
The difference is subtle in description and enormous in practice. A compliance-driven programme asks: “Do we have a vendor assessment process?” A reality-driven programme asks: “Do we know which vendors could hurt us, and are we watching them?” The first produces a spreadsheet that says “assessed” next to names nobody’s looked at in eleven months. The second concentrates effort on the payment processor handling customer financial data and ignores the office vending machine supplier. Both pass the audit. One of them would know, within minutes, if a critical vendor went down.
Most programmes are compliance-driven, because compliance-driven is easier to start. There’s a checklist, and working through it produces the certificate. The path is clear and the outcome is defined. The problem is that compliance-driven programmes tend to stay compliance-driven. The checklist becomes the organising principle. The audit becomes the rhythm. The programme starts to serve the framework rather than the business. And when the framework and the business diverge — as they always do, because frameworks are static and businesses are dynamic — the programme follows the framework.
That gap — between what the certificate asserts and what the programme actually delivers — is what I call washing security. Like greenwashing, it’s the appearance of the thing without the substance. The performance of security without the operation of it.
The alternative is a programme that starts from your reality, connects what it knows, and tells you — continuously, not annually — whether what you’re doing is working and whether the effort is proportionate to what’s actually at risk.
This book is about how to build one.
You know which one your programme is. The certificate won’t tell you. The remaining chapters are about what to do once you’ve admitted it.
What to do Monday morning
Ask yourself the vendor question. Pick your most critical vendor — the one whose outage would affect your customers. Time how long it takes you to identify: which services depend on them, what data they process, what your notification obligations are, and who needs to be told. If it takes more than thirty minutes, the gap between your certificate and your operational reality is wider than you think.
Look at when your evidence was created. Pull up last year’s audit evidence. Check the dates. How much was created during the month or two before the audit? How much was generated throughout the year as a natural byproduct of the programme running? The ratio tells you how much of your programme is continuous and how much is performative. Be honest about what you find.
Ask one person on your team: “What do you think our security programme actually does?” Not the security lead — someone outside the security team who interacts with the programme. A team lead who does access reviews, a manager who approves policies, an engineer who handles vulnerability findings. Their answer will tell you what the programme looks like from the outside — and whether it looks like working security or paperwork.