What is Compliance?¶
What you'll be able to do in this chapter
- Define compliance, including the word "demonstrable".
- Distinguish law, standard, framework and contractual obligation.
- Separate mandatory from voluntary obligations.
- See, in outline, why compliance does not automatically equal security.
The same word, four different things¶
The customer's letter to Scaldimet mentioned two requirements: ISO 27001 and NIS2. In a single meeting about that letter, you hear all of the following:
- "NIS2 is the law, so we have no choice."
- "ISO 27001 is a standard (we could get certified, but nobody's forcing us)."
- "Our customer's contract now requires the certificate, so actually we kind of are forced."
- "Can't we just use the NIST framework instead?"
Four sentences, four different kinds of obligation, and they are being treated as if they were one thing. A new CISO who cannot tell a law from a standard from a contract from a framework will agree to the wrong things, miss real obligations, and waste effort on optional ones. Sorting this out is what this Lesson does.
What compliance is¶
Compliance is the state of meeting your obligations (and being able to demonstrate that you meet them). Those obligations may come from law, regulation, contracts, or the organisation's own internal policies.
Two concepts are particularly important: obligations and demonstration.
-
Obligations: compliance is always to something; there is no such thing as being "compliant" in the abstract, only compliant with a named requirement.
-
Demonstration: compliance requires more than doing the required things: the organisation must also be able to demonstrate that it does them. If Scaldimet does everything ISO 27001 asks but keeps no records, it cannot pass an audit (it is, for practical purposes, non-compliant). Evidence therefore needs to be treated as part of the control, rather than something reconstructed before an audit. Hold on to that; it shapes the whole Compliance Module.
Four kinds of obligation: get these straight¶
Here are the four kinds in the meeting above, sorted. This table is one to keep.
| Kind | What it is | Mandatory? | Scaldimet example |
|---|---|---|---|
| Law / regulation | A binding rule set by a government or regulator | Yes (non-negotiable) | NIS2 (as transposed into national law) |
| Standard | A published, agreed specification you can be measured or certified against | Voluntary in itself… | ISO 27001 |
| Framework | A structured set of good practices to guide and organise your work | Usually voluntary; a guide, not a pass/fail | NIST CSF |
| Contract | A binding agreement between two parties | Yes (if you signed it) | The OEM's clause requiring ISO 27001 alignment |
Now the four confused sentences resolve cleanly. NIS2 is law: mandatory, no choice. ISO 27001 is a standard: voluntary in principle, which is why someone said "nobody's forcing us." But the OEM contract makes that same standard contractually mandatory for Scaldimet (so it is now compulsory, not because the standard forces it, but because the contract does). And NIST CSF is a framework: a perfectly good one, but offering to "use it instead" of ISO 27001 misunderstands the situation: the customer asked specifically for ISO 27001 alignment, so a different framework, however good, does not discharge that contractual obligation.
Technical explainer (read & discuss, don't build): standard vs framework
These two are the most-confused pair, so be precise.
A standard (like ISO 27001) is something you can be formally certified against by an accredited body (there is a defined bar, an audit, and a pass/fail certificate). It answers "did you meet the specification?"
A framework (like the NIST Cybersecurity Framework) is a structured set of practices and outcomes that organises and guides your work. You generally don't get "certified" in a framework; you use it to structure your programme and measure maturity. It answers "are we covering the right areas, and how mature are we?"
Both are useful, and they often work together (a framework can give you the shape, a standard the certifiable proof). Module 3 uses several of each. For now: certifiable specification = standard; organising guide = framework.
Mandatory vs voluntary, and why "voluntary" is rarely simple¶
The cleanest split is mandatory (law, signed contracts: you must) versus voluntary (standards and frameworks you choose to adopt). But notice from the table how slippery "voluntary" is. ISO 27001 is voluntary as a standard (until a customer's contract requires it, at which point it becomes mandatory through the contract). This is exactly how supply-chain pressure works, and exactly Scaldimet's situation: a "voluntary" standard has become non-negotiable because a major customer attached it to revenue.
The practical lesson for a CISO: don't classify an obligation by its type alone. Ask what makes it binding for us, specifically. ISO 27001 is binding for Scaldimet not because standards are compulsory (they aren't) but because Scaldimet's biggest customer made it a condition of the contract. Knowing the real source of the obligation tells you how hard it is, what happens if you miss it, and how to argue for the budget to meet it.
Compliance and security are not the same thing¶
One more idea, planted now and returned to in full in Module 3: compliance is not the same as security.
It is entirely possible to be compliant and unsafe. An organisation can meet compliance requirements and still have significant security weaknesses (because it treated the requirements as boxes to tick rather than risks to reduce). Equally, an organisation can be reasonably secure while failing a specific compliance requirement it simply hasn't documented yet.
This does not mean compliance is pointless (far from it). A well-chosen standard or law encodes hard-won good practice and covers most of the ordinary, sector-wide risks an organisation faces (this is the very reason the course teaches compliance before risk: Lesson 1.5 explains it properly). Compliance is a powerful floor, not a ceiling. It gets you to a sound, defensible baseline efficiently. What it cannot do is notice the risks specific to your organisation that no standard anticipated. Scaldimet's flat French network, its unmonitored contractor, its ageing OT. Those need risk thinking on top. Compliance and risk are partners; treating compliance as the whole job is the "check-box trap" Module 3 dismantles.
Application: classify Scaldimet's obligations¶
Here are five obligations landing on Scaldimet. For each, identify (a) the kind: law, standard, framework, or contract: and (b) whether it is currently mandatory or voluntary for Scaldimet specifically, and why. Decide before the debrief.
- NIS2 incident-reporting duties.
- ISO 27001 certification.
- The OEM contract clause requiring ISO 27001 alignment.
- Adopting the NIST Cybersecurity Framework to structure the programme.
- Scaldimet's own (not-yet-written) internal acceptable-use policy.
Debrief. (1) Law: mandatory. No choice. (2) Standard: voluntary in itself, but see (3). (3) Contract: mandatory, and it is this that drags (2) into the mandatory column for Scaldimet: the certificate is voluntary as a standard but compulsory via the contract. (4) Framework: voluntary; a sensible choice to organise the work, but nobody is requiring it, and adopting it does not satisfy the ISO 27001 obligation. (5) Once written and approved, an internal policy becomes a self-imposed obligation: mandatory inside Scaldimet, and something Scaldimet must then be able to demonstrate it follows (compliance applies to your own rules too, not just outside ones). The recurring insight: the kind of obligation and whether it binds you are two separate questions, and the second is the one that decides your priorities.
Key takeaway
Compliance is meeting your obligations and being able to prove it: the word demonstrate is half the definition; without evidence there is no compliance. Obligations come in four kinds: law and contracts (mandatory), standards and frameworks (voluntary in themselves). But "voluntary" is slippery (a customer's contract can make a voluntary standard compulsory, which is exactly Scaldimet's case). Always ask not just what kind an obligation is, but what makes it binding for us. And remember the warning the course returns to: compliance is a strong floor, not a ceiling (it is not the same as security).