Compliance vs real security: the check-box trap¶
What you'll be able to do in this chapter
- Explain why compliance is necessary but not sufficient for security.
- Recognise the check-box trap and the ways an organisation games it.
- Explain why the socle covers ordinary risk and what is left for Module 4.
Compliance does not prove security¶
Imagine Scaldimet a year from now. The ISO 27001 certificate hangs in reception, the CyFun label is filed with the CCB, the customer renewed the contract, and the security committee meets quarterly. Then Beta's production line stops for three days, because a targeted attacker exploited exactly the kind of bespoke weakness no generic baseline ever asked about. Everything was compliant, but the company was not secure. This chapter is about why that can happen, and how to make sure it does not happen to you. It is also the bridge from this Module to the next.
Compliance is necessary but not sufficient¶
Hold both halves of that sentence at once, because losing either is a mistake.
Compliance is necessary. The baseline deals with the bulk of ordinary, common risk efficiently; it satisfies the law and the customer; it gives you structure, evidence and a way to talk to the board. An organisation that dismisses compliance and skips the socle is exposed to the very attacks that hit everyone, and has no defensible story for the regulator. Compliance is not the enemy of security.
But compliance is not sufficient. A baseline is, by definition, general: it addresses the risks common to organisations like yours, derived from what has hit everyone else. It does not, and cannot, know that Scaldimet has an unsupported French SCADA reachable through one specific contractor's unmonitored VPN, feeding a line whose three-day stoppage breaches the very contract the compliance work was meant to protect. That risk is specific to Scaldimet, and finding it requires looking at Scaldimet as an attacker would, not ticking a generic list. That is Module 4.
How the check-box trap works¶
The trap is mistaking the measurement for the thing measured: treating "passed the audit" as "is secure". It shows up in recognisable ways, and naming them is how you avoid them:
- Controls present, not effective. The control exists on paper and in the SoA, but it was never tested for operating effectiveness (Lesson 3.6), so it does nothing. The monthly access review that no one has run since March.
- Scope gaming. The certificate is valid, but scoped to exclude the risky systems, so it certifies the safe office and omits Beta's OT (Lesson 3.5).
- Letter without spirit. The minimum is met word-for-word while the obvious intent is missed: backups exist (the control is "met") but were never test-restored, so they will not actually save the line.
- Point-in-time blindness. The audit passed on the day; the control decayed the week after, because nothing sustains it.
Every one of these passes a careless audit and leaves real risk untouched. The defences are everything this Module built: every control carries a risk rationale (so an ineffective control is visible as a risk left untreated), scope reflects reality, evidence is real and tested, and controls operate continuously rather than only for a one-day performance.
The bridge to Module 4¶
Recall the EBIOS framing from the start of this Module. Workshop 1 builds the socle through a compliance approach. That is what Chapters 3.1 to 3.6 have covered. But the analysis does not stop there. You have to look at the risks that are specific to Scaldimet: who might target the company, how they could move through its ecosystem, how likely the scenarios are, and what should be done about them. The socle covers common risk. Module 4 examines what is specific to Scaldimet.
So the right way to leave this Module is with both halves intact: the socle is built and proven, which is a real achievement and a legal necessity, and the most dangerous, Scaldimet-specific risks have not yet been examined. Passing the audit marks the beginning of continued operation and improvement, not the end of the security effort.
Where Scaldimet is compliant but not yet secure
After a successful compliance programme, Scaldimet could still be exposed exactly where it is most specific: a targeted attacker using the maintenance contractor's trusted access to reach an unsupported SCADA on a flat network, to stop the line at the worst commercial moment. A generic baseline reduces the chance of this in general; it does not analyse this attack path against this company. Keeping that gap visible in the risk picture is what stops the certificate from becoming a false comfort.
Application: find Scaldimet's check-box risks¶
On paper, name two places where Scaldimet could plausibly pass its audits and still be insecure, and classify each by the trap it represents (controls present but not effective, scope gaming, letter without spirit, or point-in-time blindness). For each, write the one question an honest internal audit or a Module 4 risk analysis would ask that the compliance checklist did not. The habit of asking that question is how you avoid the trap.
Key takeaway
Compliance is necessary but not sufficient. The socle efficiently covers the bulk of ordinary risk, satisfies the law and the customer, and gives structure and evidence, so skipping it is reckless. But a baseline is general by design and cannot see Scaldimet's specific exposures, so treating a passed audit as proof of security is the check-box trap: controls present but ineffective, gamed scope, letter without spirit, point-in-time blindness. The defences are this Module's disciplines (risk rationale, appropriate scope, real evidence and testing, continuous operation), and the remaining work, the targeted attack scenarios the socle does not cover, is Module 4. Compliance reaches the starting line of real security, not the finish.