What actually changed in February 2024
NIST published version 2.0 of the Cybersecurity Framework on 26 February 2024, ten years after the first. Everyone remembers the arrival of a sixth function, Govern, alongside Identify, Protect, Detect, Respond and Recover. Almost nobody notices the three words that vanished from the title. Version 1.1 was called Framework for Improving Critical Infrastructure Cybersecurity. Version 2.0 is called the NIST Cybersecurity Framework, full stop, and its stated scope covers any organisation, whatever its size, sector or level of maturity.
For a European CISO, that second piece of news carries more weight than the first. It removes the convenient argument that CSF is a US federal instrument reserved for operators of vital importance. That was never quite accurate; it is no longer defensible at all.
The Core itself got tighter: six functions, 22 categories, 106 subcategories, against five, 23 and 108 in version 1.1. The framework gained a function and shed two subcategories — the point was not to add material, it was to redistribute responsibility. The mappings to ISO/IEC 27001, SP 800-53 and COBIT also left the document's appendices for the CPRT, NIST's online reference tool, so they now live and get corrected instead of sitting frozen in a PDF from 2018.
Govern at the centre, not at the head of the queue
On the official diagram, the five original functions form a cycle. Govern does not take sixth place in that queue: it sits in the middle and touches all five. This is not a layout decision. Govern is not a step you run before Identify, it is what determines whether the other five produce anything at all.
Six categories make it up: organizational context, risk management strategy, roles and authorities, policy, oversight by leadership, and cybersecurity supply chain risk management. That last one is worth pausing on. In version 1.1, supply chain lived under Identify. It moved to Govern. That is a position, and it is the right one: choosing a supplier, accepting their contractual terms, deciding you will tolerate a hosting provider with no audit clause — those are governance decisions, not an inventory exercise.
The category that hurts most in an assessment is oversight. It asks whether the risk management strategy is reviewed and adjusted in light of the results obtained. Almost every organisation has a strategy. Very few can show what they changed in it after putting it up against reality.
Tiers are not a score
Partial, Risk Informed, Repeatable, Adaptive. Numbered 1 to 4. It takes an executive committee about thirty seconds to read that as a mark out of four, and it is the most common and most expensive mistake we run into in the field.
Tiers describe the rigour with which an organisation governs its cyber risk: how it decides, how it connects cyber risk to enterprise risk, how it accounts for its ecosystem and its dependencies. They do not describe the level of protection achieved. You can be Tier 3 and get encrypted on a Monday morning; you can be Tier 2 with a properly hardened estate and backups that work.
Tier 4 is not everyone's target. An adaptive posture has a price: threat intelligence that is genuinely consumed, dynamic reallocation of resources, continuous revision of the risk strategy. For a three-hundred-person industrial firm whose leading feared scenario is ransomware arriving through remote access, aiming at Tier 4 is a budgetary category error. It needs multi-factor authentication, backups whose restore has actually been rehearsed, and segmentation that holds. Declaring Tier 2 as the target and reaching it beats declaring Tier 4 and manufacturing the evidence to match.
When a board asks "how mature are we?", the honest answer is not a number: it is a list of scenarios, what we can put up against them today, and the evidence for it.
The profile is the working instrument
The current profile describes the outcomes actually achieved. The target profile describes the ones you want, over a stated horizon. The gap between them is the plan. The whole method sits there, and it is more useful than any radar chart.
Two forms exist, and the second is badly under-used. The organizational profile is yours. A community profile is a baseline published by a community — a sector, a technology, a threat family — that you adopt as the basis for your target. There are community profiles for ransomware risk, for genomic data, for hybrid satellite networks, and NIST has published a dedicated guide to building them. Starting from one saves months, and more importantly it kills the sterile negotiation about what "target" means.
One observation from practice: do not build a target profile at uniform ambition. A profile aiming at the same level across all 22 categories is a profile nobody arbitrated. The imbalance is what proves a choice was made and can be defended in front of a CFO.
The six functions, and what gives away a rushed assessment
| Function | The question it asks | The tell-tale sign of rushed work |
|---|---|---|
| Govern | Who decides, on what basis, and who answers for the outcome? | A policy signed four years ago, never revised, that nobody quotes |
| Identify | What do we own, what matters, and what is aimed at us? | An asset inventory exported from a tool, with no owner and no business criticality |
| Protect | What have we put in place to reduce likelihood? | Solid controls on the endpoint, absent from business SaaS and OT |
| Detect | How long before we know? | A SIEM collecting everything and alerting on nothing actionable |
| Respond | What do we do, in what order, and who speaks? | A plan never rehearsed, with out-of-date on-call numbers |
| Recover | How fast do we come back, and in what state? | Backups validated by the job succeeding, never by an actual restore |
CSF and ISO 27001 are not rivals
The question "should we do CSF or ISO 27001?" is malformed, because the two objects are not in the same trade.
ISO/IEC 27001 is a certifiable management system. It has a declared scope, a statement of applicability, an audit cycle, an accredited body and a certificate you hand to your client's procurement team. A large part of its value is evidential value, enforceable against a third party.
CSF has none of that. No certification, no auditor, no certificate. What it gives you is a shared vocabulary for describing security outcomes and a structure for choosing between them. It is excellent for talking to a board, for comparing two subsidiaries that share neither tooling nor vocabulary, for building a three-year trajectory that fits on one page without lying.
We frequently run both at once: CSF as the reading grid for the executive committee and the roadmap, ISO 27001 over the scope a client or a tender demands be certified. Mappings between them exist and are imperfect. That is fine — what you want from a mapping is a direction of travel, not term-by-term equivalence.
Neither one tells you how to analyse a risk scenario. EBIOS Risk Manager does the job CSF never claims to do: credible strategic and operational scenarios, with named risk sources. CSF will happily consume what EBIOS RM produces; it replaces it nowhere.
A framework of outcomes, not of controls
Read any CSF subcategory. It states an expected outcome. It does not tell you to turn on MFA for administrative accounts, or how to log a domain controller. That abstraction is deliberate: it is what lets one framework apply to a teaching hospital and to a forty-person fintech. It is also what makes it unusable, as it stands, as an implementation plan.
So you have to pair it with something prescriptive. The CIS Controls suit that role unusually well, and CIS did the work in the right direction: version 8.1 of the Controls, published in June 2024, added a Govern security function to its own taxonomy to line up with CSF 2.0, and publishes the mapping of its safeguards. Eighteen controls, 153 safeguards, three implementation groups; IG1 and its 56 safeguards are the honest starting point for most mid-sized organisations.
The division of labour is clean. CSF answers "what outcome are we aiming at, and does leadership agree". The CIS Controls answer "what do I do on Monday morning". The CIS Benchmarks answer "what does a correctly configured Windows Server look like". Wavatec resells CIS SecureSuite, so read this as an interested opinion; but that division of labour is why we took it on, not the other way round.
Where these assessments go wrong
The most ordinary failure is self-assessment drift. An internal score rises every year without a single test having been re-run. The 2.7 becomes 3.1 because the person filling in the questionnaire changed roles, or because last year they were in a pessimistic mood. A self-declared, unsupported maturity score measures only the self-confidence of whoever declared it.
The rule that fixes it is simple and unpopular: no rating without an artefact. A subcategory declared achieved must point to a dated procedure, a configuration capture, a closed ticket, an exercise write-up. If the artefact cannot be produced in ten minutes, the subcategory is not achieved — it is intended. That one rule typically knocks twenty to thirty per cent off the declared score on the first pass, and makes subsequent passes comparable with each other, which is the entire point.
Two other habits recur. The first is uniform assessment: working 106 subcategories at constant depth means working none of them properly. Pick the scenarios that would genuinely hurt and dig there, treating the rest declaratively and saying so. The second is the ownerless profile: one in which no category has a named owner is a document, not a programme; it will be reread once a year and will have moved nothing.
Then there is what you report upward. Replace the spider chart with three sentences: here is our target profile and why that level, here is where we stand and on what evidence, here are the three gaps we are funding this year. It is less pretty. It is checkable.
Where to start
Take the scope that matters most, not the whole company. Build a current profile on it, applying the evidence rule from the first interview onward. Check whether a community profile exists for your sector before writing your target from a blank page. Choose a Tier deliberately, and write the sentence explaining why that one and not the one above — you will be asked for that sentence again. Then translate every gap into CIS safeguards, so the plan contains verbs rather than intentions. Repeat the exercise twelve months later under the same evidence rule: that is the only way to end up with a trajectory instead of a series of incomparable snapshots.
This is the work we run out of Paris and Aix-en-Provence for around fifty client organisations: maturity assessments, EBIOS RM analyses, penetration tests, and the tooling — Elyys360, the GRC platform we publish — that lets a profile outlive the consultant who wrote it.
