Series: Security Governance That Actually Works, Article 1
A certificate does one job well. It signals to the market that you follow a recognised process. That’s marketing and signalling, and both have real value. Customers, insurers and regulators all want the signal. What it won’t do is tell you what to protect.
If you buy SOC 2 or ISO 27001 from your suppliers, or hold one yourself and report it to a board, this is for you.
The framework behind the certificate is a taxonomy of controls, not a risk assessment of your business. It weights everything generically, because it doesn’t know your business. It can’t tell you your risk context. It can’t tell you which of your capabilities are business-essential, which threats actually target your sector, where your real exposure sits, or what your security programme should cover and, just as important, what it shouldn’t. That decision is yours. The framework quietly assumes you’ve already made it.
Miss that, and “we’re certified” starts standing in for “we’ve decided what to protect and what to accept.” The two are not the same. A SaaS company and a manufacturer can hold the same certification while their business-essential capabilities sit under-protected. Not because anyone was careless. Because a generic control set spreads effort evenly, and nobody brought the risk context that would have told them where to concentrate it instead.
It’s the same gap I wrote about in The ISMS beyond the certificate. An ISMS can run beautifully and still exist for the auditor, not for decisions. The certificate is one artefact of that system. Risk context is what makes the system mean anything.
The market won’t correct this for you. It rewards the badge, because the badge is visible and the quality of your scoping is not. So the pull is towards passing the audit rather than understanding your exposure. That is structural, not anyone’s bad faith. It is what happens when the signal is easier to see than the thing it signals.
Which points to the fix. The risk-context work is the part only you can do, because only you know your operation, your threat model, and which capabilities are business-essential. The certificate presupposes that work. It does not do it. So bring it. Buy assurance as a decision, not a badge.
Four moves make that real, and you can apply them to the certificates you already hold.
-
Start from your business, then reach for the framework. Decide what your programme should cover, and what it shouldn’t, based on your real exposure. Then map the control set onto that decision. The framework structures your answer. It doesn’t choose it. I made the fuller case for building a programme this way round in Control Frameworks Built Backwards.
-
Write down what the certificate doesn’t cover. For every certification you hold or accept, add one plain-language line. This attests to X. It does not answer whether Y is acceptable, and that decision is ours. A shared badge becomes an owned decision.
-
Ask what the assurance let you decide, not how many controls it counted. Control coverage is an activity number. A decision is an outcome. “We accepted this residual exposure, with these eyes open” is worth more to a board than “98% of controls implemented.”
-
Put an honest broker between the badge and the board. Someone whose job is to say, in plain language, what the certificate covers, what it doesn’t, and which gaps the board is now choosing to carry. Not an advocate for spending more. Not a rubber stamp. A broker.
The most useful security programme I’ve worked on, running across dozens of manufacturing sites, didn’t start with a framework. It started with a plain question. What would actually hurt this business, and where? The certificate came later, and it was better for it, because we knew what we were certifying and what we had deliberately left out.
Do this and you get three things. More security for the same spend, because effort follows your exposure instead of a generic list. A board story you can defend after an incident, because the scope decisions were named and owned, not found in the post-mortem. And a certificate that finally means what people assume it means.
The certificate signals. Your risk context decides. Don’t let the first stand in for the second.
One test. Can you say, in a sentence, what your security programme deliberately doesn’t cover, and why?
Related reading
- The ISMS beyond the certificate, the introduction to this series, on why most management systems exist for the auditor rather than for decisions.
- Control Frameworks Built Backwards, on starting from business context and threat landscape instead of a control catalogue.
This is Article 1 in the ‘Security Governance That Actually Works’ series. The introduction sets out the seven-capability model; the portfolio explores each capability in depth.
I advise manufacturing companies on security governance and risk management. If this resonates with challenges in your organisation, get in touch.