NIST CSF 2.0 vs 1.1: The 79 Subcategories That Changed

What this guide covers

• NIST CSF 2.0 vs 1.1: what actually changed
• NIST CSF 2.0 vs 1.1: the numbers, side by side
• The twelve Categories that no longer exist
• Two withdrawal wordings, and why they matter
• The identifier format trap in NIST CSF 2.0 vs 1.1
• The sixteen outcomes with no NIST CSF 1.1 predecessor
• A three-step transition from NIST CSF 1.1 to 2.0
• What survives a NIST CSF 2.0 vs 1.1 comparison unchanged?
• Common questions on NIST CSF 2.0 vs 1.1
• Getting the transition documented

NIST CSF 2.0 vs 1.1: what actually changed

A comparison of NIST CSF 2.0 vs 1.1 usually starts and stops with “they added GOVERN”. That is the headline, but it understates the work by a wide margin. CSF 2.0 withdrew 79 Subcategories and removed 12 whole Categories. If your Current Profile, risk register, control matrix or supplier questionnaire cites CSF 1.1 identifiers, a majority of them no longer point at anything.

The good news is that NIST publishes the successor for every withdrawn identifier in its own reference data, so the re-mapping is mechanical. The work that is not mechanical is everything GOVERN asks for, and the sixteen outcomes that have no predecessor at all.

NIST CSF 2.0 vs 1.1: the numbers, side by side

The Category and Subcategory totals barely move, which is exactly why the change gets underestimated. Twenty-three Categories became twenty-two and a hundred and eight outcomes became a hundred and six — but 79 of those outcomes are not the same outcomes.

The twelve Categories that no longer exist

The clearest way to see NIST CSF 2.0 vs 1.1 is to look at what was removed rather than what was added.

These disappeared entirely between the two versions. If you have evidence filed under any of these headings, it needs re-mapping:

Four of the twelve — ID.BE, ID.GV, ID.RM and ID.SC — moved into GOVERN. That is the structural story of NIST CSF 2.0 vs 1.1 in one line: governance was scattered inside IDENTIFY, and it is now a Function of its own with 31 Subcategories.

Two withdrawal wordings, and why they matter

NIST’s reference data maps NIST CSF 2.0 vs 1.1 identifier by identifier, marking each withdrawn one with its successor, but it uses two different phrasings:

• [Withdrawn: Incorporated into GV.RR-02, GV.SC-02] — 61 entries
• [Withdrawn: Moved to PR.AA-05] or Moved into — 18 entries

If you are extracting the mapping programmatically and you match only on “Incorporated into”, you will silently lose 18 of the 79. They are not obscure ones either: PR.AC-02, PR.AC-04, PR.AC-06 and PR.AC-07 are all in the “Moved to” set, and PR.AC is one of the Categories an access-control programme will have the most evidence under.

A handful of successors point at a whole Category rather than a single Subcategory — ID.GV-01 was incorporated into GV.PO, for example. Treat every successor as a Subcategory and your extraction will reject real NIST data.

The identifier format trap in NIST CSF 2.0 vs 1.1

CSF 1.1 numbered Subcategories with one digit — ID.AM-1. CSF 2.0 uses two — ID.AM-01. That looks like a reliable version test, and it is not.

CSF 1.1 outcomes numbered past ten also carry two digits: PR.IP-10, PR.IP-11 and PR.IP-12 are all 1.1 identifiers in 2.0 format. Any check built on digit count skips every row carrying them, and because PR.IP was the largest Category in CSF 1.1 with 12 Subcategories, that is a meaningful blind spot.

The reliable test is to resolve each identifier against the live list of 106. Anything that is not on it is either withdrawn or was never real — and both happen. PR.AT-6, for instance, exists in neither version; 1.1 stops at -5 and 2.0 stops at -02.

The sixteen outcomes with no NIST CSF 1.1 predecessor

Sixteen Subcategories in CSF 2.0 have no CSF 1.1 informative reference behind them. These are genuinely new, and an organisation transitioning starts them from zero:

• GOVERN — GV.RM-07 (positive risks and opportunities), GV.RR-01 (leadership accountability and culture), GV.OV-01, GV.OV-02 and GV.OV-03 (the three oversight outcomes)
• IDENTIFY — ID.AM-07 (data and metadata inventories), ID.IM-01 (improvements identified from evaluations)
• PROTECT — PR.AA-04 (identity assertions protected, conveyed and verified), PR.PS-05 (unauthorised software prevented)
• RESPOND — RS.MA-05 (criteria for initiating recovery), RS.AN-07 (incident data and metadata integrity and provenance), RS.AN-08 (incident magnitude estimated and validated)
• RECOVER — RC.RP-03, RC.RP-04, RC.RP-05 and RC.RP-06

The RECOVER cluster is telling. Four of the six outcomes in RC.RP are new, and all four are about verification and declaration — verifying backup integrity before restoring, establishing post-incident operational norms, verifying restored assets and confirming normal operating status, and declaring the end of recovery against criteria. NIST evidently concluded that organisations restore service and then discover they restored the problem with it.

PR.PS-05 is another one worth noticing, because the verb changed. It asks that installation and execution of unauthorised software is prevented. Detection is not prevention, and a blocklist prevents known software while unauthorised software is mostly not known.

A three-step transition from NIST CSF 1.1 to 2.0

1. Inventory every citation. Profile, risk register, control matrix, audit checklist, board reporting — and contracts and supplier questionnaires, which are the ones people forget. A CSF 1.1 identifier written into a customer contract does not update itself.
2. Re-map, then re-read the successor’s wording. The mapping is mechanical; the reading is not. The successor’s text is not the predecessor’s text, and where the new outcome asks for more, that is a gap rather than a mapping. This is the step that separates a real transition from a find-and-replace.
3. Assess GOVERN and the sixteen new outcomes from a standing start. Budget on that basis. In a typical transition the re-mapping takes days and GOVERN takes months. What GOVERN actually asks for is covered in our guide to the NIST CSF GOVERN function.

The failure mode to avoid is relabelling: putting a CSF 2.0 identifier on a document whose text still answers the 1.1 outcome. It is the defect an assessor finds fastest, because the wording will not match the outcome it now claims to answer, and it is invisible to any check that only looks at identifiers.

What survives a NIST CSF 2.0 vs 1.1 comparison unchanged?

Ninety of the 106 outcomes have a CSF 1.1 ancestor, so most of your evidence maps across. Categories that came through with their identifiers intact — ID.AM, ID.RA, PR.AT, PR.DS, DE.CM, DE.AE, RS.AN, RS.CO, RS.MI, RC.CO — still had individual Subcategories withdrawn inside them, which is why the numbering has gaps.

Those gaps are correct and should not be tidied. ID.AM runs 01–05, 07, 08 with no ID.AM-06. PR.DS is 01, 02, 10 and 11. DE.CM is 01, 02, 03, 06 and 09. A workbook that fills a gap to make a sequence look neat is citing an outcome that does not exist.

Common questions on NIST CSF 2.0 vs 1.1

Is CSF 1.1 withdrawn?

CSF 2.0 supersedes it. NIST published CSF 2.0 on 26 February 2024 and it is the current version; there is no revision to 2.0 published or announced. Nothing forces a migration — the Framework is voluntary — but new mappings, Community Profiles and informative references are being produced against 2.0.

How long does a NIST CSF 1.1 to 2.0 transition take?

The re-mapping in a NIST CSF 2.0 vs 1.1 move is short once you have NIST’s successor data in hand. The programme work is dominated by GOVERN, which went from four Subcategories to 31, and by the sixteen outcomes with no ancestor. Scope the effort on those two things rather than on the number of identifiers.

Can we keep using CSF 1.1?

You can, since there is no certification either way and nothing expires. The practical pressure comes from elsewhere: customer questionnaires increasingly ask about CSF 2.0, Community Profiles are being published against it, and NIST’s informative references to 800-53, ISO/IEC 27001 and 800-171 are maintained for 2.0.

Where does NIST publish the withdrawal mapping?

In its CSF 2.0 reference data, which lists all 185 Subcategory rows — the 106 live ones plus the 79 withdrawn entries with their successors. Be careful with that file: counting rows in it gives 185, not 106, and validating identifiers against it unfiltered accepts exactly the withdrawn identifiers you are trying to find.

Do the Implementation Tiers change in NIST CSF 2.0 vs 1.1?

Yes, in emphasis. CSF 2.0 characterises each Tier across two axes — cybersecurity risk governance and cybersecurity risk management — reflecting GOVERN’s arrival. An old Tier rating does not map cleanly, so reassess rather than carry it forward. Our guide to the NIST CSF Tiers covers the two-axis reading in detail.

Getting the transition documented

CSF 2.0 is free and you should read it: NIST publishes it at nist.gov/cyberframework. For background on the Framework’s components before you start, our NIST Cybersecurity Framework overview covers the Core, Profiles and Tiers together.

Our NIST CSF Toolkit ships the transition as two artefacts: a Transition Guide that explains what changed and what to do about it, and a Transition Map workbook carrying all 79 withdrawn identifiers with the successor NIST assigns to each, plus a column for the evidence you already hold against them. Alongside it sit the Core Reference with all 106 outcomes, both Profile workbooks, and a scored assessment tool — 164 editable documents in total.