Skip to content

3.1.A Laws vs standards vs frameworks · why selection matters ~45 min Module 3 · Compliance

Laws vs standards vs frameworks · why selection matters

The pile of acronyms on your desk

By your second month, four different obligations have landed on you. NIS2 is a European law that applies to Scaldimet whether you like it or not. The OEM customer has written that it wants Scaldimet to hold ISO 27001. A consultant has suggested adopting the NIST Cybersecurity Framework. And the Belgian authority keeps mentioning something called CyFun. They overlap, they use different words for similar things, and a tempting but costly instinct is to try to "do all of them". You cannot, and you should not. The skill this Lesson builds is telling these four kinds of thing apart, and then choosing.

Four kinds of obligation, in operational terms

Lesson 1.4 introduced these distinctions; now you use them to make a decision. The practical differences are what matter:

Kind What it is Is it mandatory? Scaldimet example
Law A legal obligation set by a state or the EU Yes, by force of law NIS2 (and its national transpositions in Belgium and France); the GDPR (data protection)
Standard A published, often certifiable specification Only if you choose it, or a law or contract requires it ISO/IEC 27001
Framework A structure for organising practice No; it is a tool for thinking and communicating NIST CSF; CyFun
Contract A private obligation between parties Yes, by force of the agreement The OEM's requirement that Scaldimet hold ISO 27001

The categories do not always fit neatly, and that overlap is normal. CyFun is a framework that a Belgian law leans on to satisfy a legal obligation. ISO 27001 is a voluntary standard that a customer's contract has made mandatory for Scaldimet in practice. What matters is not which category it falls into, but what drives it: a regulator, a customer, or your own judgement.

Why selection matters: the socle idea

This is the decision that separates a competent compliance programme from a disorganised one. You do not comply with everything. You select a baseline of controls that covers the bulk of ordinary, standard, sector-typical risk, and you make that one baseline satisfy as many of your drivers as possible.

ANSSI's risk method, EBIOS Risk Manager, has a precise name for this: the socle de sécurité, the security baseline. Its first step is a compliance approach: take a recognised reference (a standard, a hygiene guide) and put its controls in place, because they address the risks that are common to everyone. Only after the socle is built does the method study the targeted attacks specific to your organisation. The socle is the foundation; the bespoke risk work sits on top.

Security socle Security socle

The reason to think this way is economic and it is about risk. Most organisations are exposed to the same general, common risks (ransomware, data leaks) through the same common weaknesses (weak passwords, no backups, flat networks, unmanaged access). A known baseline of controls closes most of those weaknesses efficiently, and with them most of the risk. Using an established baseline avoids spending time and budget repeatedly addressing common risks. Build the socle from an established baseline, then spend your judgement on what the baseline does not cover, which is Module 4. Selecting a baseline is therefore not bureaucratic tidiness; it is how you direct effort at risk.

One baseline, many drivers

The corollary is that you should resist running three parallel programmes (one for the law, one for the customer, one for good practice). They overlap enormously. The practical approach is to pick a baseline that, implemented once, can be shown to satisfy several drivers: the law, the contract, and your own risk reduction. The next Lesson does exactly this for Scaldimet. Here, hold the principle: choose a coherent baseline, map it to every driver it can satisfy, and only add separate work where a driver genuinely demands something the baseline does not give.

Scaldimet's drivers

  • NIS2 (law): mandatory, both in Belgium (headquarters) and France (Site Beta). The non-negotiable floor.
  • GDPR (law): also binds Scaldimet because it handles personal data (staff, customers). It sits alongside NIS2 as a legal driver; this course does not cover it in depth, but a real baseline must account for it.
  • ISO 27001 (standard, made contractual): the OEM customer wants it; the contract renewal depends on demonstrable progress.
  • CyFun (framework): the Belgian authority's framework, and a recognised path to NIS2 conformity.
  • NIST CSF (framework): a useful organising structure, not an obligation in itself.

Several drivers, but not several programmes. The next Lesson combines them into one baseline.

Application: driver or tool?

On paper, take the six items from the table (NIS2, the GDPR, ISO 27001, CyFun, NIST CSF, the OEM contract). For each, decide two things: is it a driver (it binds Scaldimet whether it likes it or not) or a tool (a means Scaldimet chooses to satisfy a driver)? And for each driver, what happens if Scaldimet simply ignores it? Draft your six answers before reading on.

Model answer (open after you've drafted yours)

The drivers, which bind regardless of choice: NIS2 (the law; ignored, it risks fines and enforcement), the GDPR (also law, because Scaldimet handles personal data; ignored, it risks its own fines and a data-protection breach, though this course does not cover it in depth), and the OEM contract (ignored, the contract renewal is at risk). The tools, which Scaldimet selects: CyFun and NIST CSF are frameworks adopted to satisfy those drivers efficiently, and ISO 27001 is the standard adopted to satisfy the customer because the contract names it; it is still a means, not an end. The distinction that matters: you cannot negotiate a driver away, but you can choose, and later change, the tool. If the distinction is lost, the programme can start treating ISO 27001 as the objective rather than as a means of meeting the customer's requirement.

Key takeaway

A law binds you by force of law (NIS2); a standard is a specification you adopt or are required to hold (ISO 27001); a framework is a structure for organising practice (NIST CSF, CyFun); a contract binds you by agreement (the OEM's ISO 27001 demand). The categories blur, so look at what drives each obligation. The competent move is not to comply with everything but to select a baseline (the EBIOS socle) that covers the bulk of ordinary risk and satisfies several drivers at once, leaving your scarce effort for the organisation-specific risk that Module 4 addresses.


Next: Lesson 3.1.B · Choosing Scaldimet's baseline →