NIST CSF 1.1 vs CSF 2.0: What Changed and What to Update

Many organisations still carry a CSF 1.1 Current Profile, board report or supplier questionnaire, and the quickest way to break it is to relabel the old Subcategory IDs as CSF 2.0 and call the job done. CSF 2.0, published by NIST on 26 February 2024, kept the outcome-based idea of version 1.1 (April 2018) but moved governance into its own Function, rebuilt supply chain risk management, renumbered or withdrew 79 Subcategories and changed how Profiles and supporting material are delivered. This guide compares the two versions element by element, shows where each 1.1 Category went using NIST's own transition data, and gives a migration plan, controls and measures that prove the move was real rather than cosmetic. It is for GRC leads, internal auditors, CISOs and consultants who own a CSF assessment and need to bring it up to date. For the framework itself, see the NIST CSF 2.0 Guide; this page covers only the delta and the migration.

Key takeaways

• Short answer: CSF 2.0 adds a sixth Function, Govern (GV), widens the audience from critical infrastructure to organisations of all sizes and sectors, folds supply chain into GV.SC, and moves examples and Informative References online.
• Most change is in governance and Protect: 1.1 Categories ID.BE, ID.GV, ID.RM and ID.SC were absorbed into Govern, and PR.IP, PR.MA and PR.PT were broken up into PR.PS, PR.IR, ID.AM-08 and the new Improvement Category ID.IM.
• Relabelling is the classic failure: 1.1 IDs do not map one to one; ID.SC-02 alone feeds five 2.0 Subcategories, and gaps in 2.0 numbering mark outcomes that moved, so a find-and-replace migration silently drops scope.
• Re-score, do not convert: new outcomes such as GV.OC-05 (dependencies), GV.SC-10 (end of supplier relationships) and ID.RA-10 (critical suppliers assessed before acquisition) have no 1.1 evidence to inherit.
• Use NIST's transition data: the CSF 1.1 to 2.0 Core Transition Changes Overview (September 2024) and the incorporated-into and moved-to links in NIST's machine-readable CSF 2.0 catalogue are the authoritative crosswalk.

The short answer: what actually changed

Both versions are voluntary, outcome-based and non-prescriptive. Neither is a certification scheme, and both describe three parts: the Core, Profiles and Tiers. What changed is the shape of the Core, the stated audience, and the way NIST supports adoption.

The 1.1 document itself said Tiers "do not represent maturity levels" and that the Functions "are not intended to form a serial path". CSF 2.0 keeps both ideas, so a migration is not a reason to start reading Tiers as a maturity score.

Govern: the change with the most audit impact

In 1.1, governance was one Category among six in Identify. In 2.0 it is a Function with six Categories, and NIST's release notice framed it around how organisations make and carry out cybersecurity decisions, treating cybersecurity as a major source of enterprise risk alongside finance and reputation. NIST's transition data shows where the old outcomes went:

Two Govern Categories have no real 1.1 ancestor. GV.OV Oversight asks that strategy outcomes are reviewed (GV.OV-01), that coverage is adjusted (GV.OV-02) and that risk management performance is evaluated (GV.OV-03). GV.RR-01 makes leadership accountable for cybersecurity risk and a risk-aware culture. A 1.1 assessment that scored ID.GV highly because a policy existed will usually score lower against GV.OV, because oversight needs evidence of review cycles, decisions and adjustments, not a document. The NIST CSF 2.0 Govern Function Guide covers how to implement each Govern outcome.

Supply chain: from five Subcategories to a life cycle

Version 1.1 introduced ID.SC with five Subcategories, added a Buying Decisions section and added supply chain criteria to the Tiers. CSF 2.0 keeps the intent but expands it into GV.SC-01 to GV.SC-10 and spreads related outcomes into Identify and Improvement.

The practical effect is that a vendor risk programme which assessed suppliers once at onboarding no longer covers the outcomes. GV.SC-10 in particular catches the exit problem: credentials, API keys, OAuth grants and data held by a supplier after the contract ends. See the NIST SP 800-161 Cyber Supply Chain Risk Management Guide for the control depth behind GV.SC.

Protect, Detect, Respond and Recover: what moved

Outside Govern, the biggest reshuffle is in Protect. Three 1.1 Categories (PR.IP, PR.MA and PR.PT) disappear and their outcomes land in four places.

• Platform security: configuration baselines (PR.IP-1, PR.IP-3 in part, PR.PT-3) go to PR.PS-01; audit logging (PR.PT-1) becomes PR.PS-04; secure development (PR.IP-2) becomes PR.PS-06 with life cycle management in ID.AM-08.
• Infrastructure resilience: network segregation (PR.AC-5) and communications protection (PR.PT-4, in part) go to PR.IR-01; capacity (PR.DS-4) becomes PR.IR-04; resilience mechanisms (PR.PT-5) become PR.IR-03; the physical operating environment (PR.IP-5) becomes PR.IR-02.
• Maintenance: PR.MA-1 and PR.MA-2 are moved to ID.AM-08 and PR.PS-02 or PR.PS-03.
• Identity: PR.AC becomes PR.AA. PR.AC-1 maps to PR.AA-01 and PR.AA-05; PR.AC-4 to PR.AA-05; PR.AC-6 (identity proofing) to PR.AA-02; PR.AC-7 (authentication) to PR.AA-03; PR.AC-2 (physical access) to PR.AA-06. PR.AA-01 now names identities and credentials for "authorized users, services, and hardware", which makes service accounts and workload credentials explicit in scope.
• Detect: DE.DP disappears. Detection roles go to GV.RR-02, testing to ID.IM-02, communication of detection information to DE.AE-06 and improvement to ID.IM-03. Several DE.CM Subcategories (DE.CM-4, DE.CM-5, DE.CM-7) merge into DE.CM-01 and DE.CM-09, and vulnerability scanning (DE.CM-8) moves to ID.RA-01. Incident declaration becomes an explicit outcome, DE.AE-08.
• Respond and Recover: RS.RP-1 folds into RS.MA-01; RS.AN-1, RS.AN-2 and RS.AN-4 fold into RS.MA-02 to RS.MA-04; RS.AN-5 (vulnerability disclosure intake) moves to ID.RA-08; RS.IM and RC.IM both go to ID.IM-03 and ID.IM-04.

These moves change who owns evidence. Incident response plan maintenance, for example, now sits in ID.IM-04 under Identify rather than in Respond, so the team that owns Identify scoring has to collect it. The NIST CSF 2.0 Respond Function Guide and NIST CSF 2.0 Protect Function Guide go deeper on each Function.

Profiles and Tiers: same names, different workflow

Version 1.1 gave a seven-step process: prioritise and scope, orient, create a Current Profile, conduct a risk assessment, create a Target Profile, determine and prioritise gaps, implement the action plan. CSF 2.0 gives five steps: scope the Profile, gather information, create the Profile, analyse gaps and create an action plan, implement and update. The risk assessment step is no longer a separate numbered step, and CSF 2.0 adds Community Profiles: baselines of outcomes published for a sector or use case.

The NIST CSF 2.0 Profiles and Tiers Guide covers rating scales, and the CSF 2.0 Organisational Profiles Template gives a starting worksheet.

Failure mode in depth: relabelling the old Profile

Threat model: the risk is not an attacker but a false assurance signal. A board, regulator or customer reads a CSF 2.0 Profile that was produced by renaming 1.1 rows, and believes Govern and supply chain outcomes were assessed when they were not.

How it happens: a spreadsheet of 108 scored 1.1 rows is converted by a lookup that takes the first 2.0 destination for each row. Because NIST records many one-to-many links (ID.SC-1 incorporated into five Subcategories, PR.AC-3 into PR.AA-03, PR.AA-05 and PR.IR-01), the lookup copies one score into one destination and leaves the others blank or, worse, defaulted. Outcomes with no 1.1 ancestor, such as GV.OV-01 to GV.OV-03, GV.RR-01, GV.SC-10 and ID.RA-10, never appear at all.

How to detect it: count rows. A complete 2.0 Profile has 106 Subcategory rows (or a documented subset with scoping rationale). Then check that every 2.0 score cites evidence dated after the migration, and that Govern rows name evidence owners outside the security team.

Controls: require a crosswalk sheet that records, for each 1.1 row, every 2.0 destination and the change type; mark inherited scores as provisional until re-tested; and have internal audit sample at least the Govern and GV.SC rows before the Profile is reported.

Worked scenario: a mid-sized insurer moving its Profile

An insurer has a 2022 CSF 1.1 Current Profile at Tier 2 with a Tier 3 Target, used in board reporting and in answers to broker due diligence questionnaires.

1. Inventory where 1.1 is cited: the board dashboard, the information security policy, two outsourcing contracts and the third-party questionnaire all cite 1.1 IDs. Each gets a change ticket.
2. Build the crosswalk: the GRC team exports the CSF 2.0 catalogue with its withdrawn entries and links, producing 79 withdrawn 1.1 Subcategories mapped to their 2.0 destinations.
3. Classify each 2.0 row: "inherited" where a single 1.1 row moved unchanged (ID.GV-3 to GV.OC-03), "re-assess" where outcomes merged or split (ID.SC-2), and "new" where nothing maps (GV.OV-02).
4. Re-score Govern with new people: the Chief Risk Officer, procurement and legal are interviewed for GV.OC, GV.RM and GV.SC. The previous Tier 2 rating for governance holds, but GV.SC-10 scores low because supplier exit does not include revoking service accounts and API keys.
5. Re-issue reporting: the board dashboard moves to six Functions, with a note that scores for merged rows are not comparable with 2022 figures.

The result is a lower headline score in two areas and a credible one everywhere else, which is the honest outcome of a migration.

Migration plan, step by step

1. Freeze and archive the 1.1 Profile: keep the original scores and evidence as the baseline, versioned and read-only. Rollback is simply continuing to report against it until the 2.0 Profile is approved.
2. Pull authoritative data: download the CSF 1.1 to 2.0 Core Transition Changes Overview and the CSF 2.0 dataset from NIST's Cybersecurity and Privacy Reference Tool. Do not rebuild the crosswalk by hand.
3. Check for a Community Profile: review the published Community Profiles for your sector before setting a Target. See the NIST CSF 2.0 Community Profiles Catalogue Guide.
4. Scope the 2.0 Profile: follow the five CSF 2.0 steps; record scoping decisions for any Subcategory you exclude.
5. Classify rows as inherited, re-assess or new: inherited scores carry over with their evidence reference; the other two classes are assessed fresh.
6. Pilot on one business unit: run the full Govern and GV.SC assessment on one unit to calibrate interview questions and rating scales before rolling out.
7. Re-map controls: refresh mappings from the online Informative References (including SP 800-53 Rev. 5) and any ISO/IEC 27001 crosswalk. See the NIST CSF 2.0 Informative References and OLIR Guide and the NIST CSF to ISO 27001 Mapping Guide.
8. Update external artefacts: contracts, questionnaires, policies and board templates; publish a comparability note for trend charts.
9. Approve and retire 1.1: once Govern sign-off is obtained, report on 2.0 only and keep the 1.1 archive for audit trail.

When to migrate now and when to wait

• Migrate now: if customers, regulators or insurers ask for CSF evidence, if your Profile feeds board reporting, or if supply chain risk is a known weakness. The Govern and GV.SC outcomes are where questions now come from.
• Short bridge is acceptable: if a 1.1-based audit cycle is mid-way, finish it, then migrate at the next cycle, recording that intent in the risk register.
• Small organisations: start with the NIST Quick-Start Guides and a reduced scope of High-relevance Subcategories, but still include Govern; a two-page GV.OC and GV.RR statement is better than none.
• Large or regulated organisations: build the crosswalk as a controlled document, map to SP 800-53 or ISO 27001 through the online references, and have internal audit validate the Govern rows.
• Sector profiles: where a Community Profile exists, such as the NIST CSF Financial Sector CRI Profile Guide or the NIST CSF Manufacturing Profile Guide, check its CSF version before adopting it as a Target.

Detection and measurement

• Row completeness: 2.0 Subcategories scored or formally scoped out, against 106. Target 100 percent before reporting.
• Fresh evidence ratio: share of "re-assess" and "new" rows with evidence dated after the migration start. Target 100 percent.
• Govern evidence owners: number of Govern rows whose evidence owner sits outside security (risk, legal, procurement, HR). A low number suggests Govern was scored by the security team alone.
• Supplier life cycle coverage: percentage of critical suppliers with documented pre-contract assessment (ID.RA-10) and exit provisions (GV.SC-10).
• Residual 1.1 citations: count of policies, contracts and questionnaires still citing 1.1 IDs. Target zero by the end of the plan.

Common failure patterns

• Find-and-replace migration: renaming PR.AC-1 to PR.AA-01 and stopping, which loses PR.AA-05 and any one-to-many destinations.
• Govern scored by the security team: self-assessed oversight and accountability rows without board or risk committee evidence.
• Supplier exit ignored: GV.SC-10 left blank because the 1.1 Profile had no equivalent, leaving supplier credentials and integrations active after contracts end.
• Trend charts across versions: plotting 2022 1.1 scores and 2025 2.0 scores on one line, which hides that the questions changed.
• Treating Tiers as a maturity target: raising every Tier because the new Function looks immature, contrary to NIST's guidance that progression depends on risk, mandates and cost-benefit.
• Using printed 1.1 Informative References: keeping old COBIT or ISO mappings from the 1.1 PDF instead of the maintained online references.

Framework mapping

Practitioner checklist

• Archive the CSF 1.1 Profile, scores and evidence as a read-only baseline.
• Download NIST's Core Transition Changes Overview and the CSF 2.0 dataset; build the crosswalk from them.
• Record every 2.0 destination for each 1.1 row, not just the first.
• Classify each 2.0 Subcategory as inherited, re-assess or new.
• Interview risk, legal, procurement and HR owners for Govern rows.
• Assess GV.SC-06, GV.SC-10 and ID.RA-10 for every critical supplier.
• Rewrite Tier rationale against governance and management rigour.
• Refresh control mappings from the online Informative References.
• Replace 1.1 citations in policies, contracts, questionnaires and board templates.
• Publish a comparability note with the first 2.0 trend report.

Standards and references

• NIST: The NIST Cybersecurity Framework (CSF) 2.0, CSWP 29
• NIST: Framework for Improving Critical Infrastructure Cybersecurity, Version 1.1
• NIST CSRC: CSF 2.0 publication page and supplemental materials
• NIST: OSCAL content, CSF 2.0 catalogue with withdrawn and moved elements
• NIST: NIST Releases Version 2.0 of Landmark Cybersecurity Framework
• NIST: CSF 2.0 dataset in the Cybersecurity and Privacy Reference Tool

Related NHI Mgmt Group resources: NIST CSF 2.0 Guide, NIST CSF 2.0 Govern Function Guide, NIST CSF 2.0 Profiles and Tiers Guide, NIST CSF to ISO 27001 Mapping Guide, NIST CSF 2.0 Self-Assessment.