NIST CSF 2.0 changes from 1.1

Govern is the most changed Function because it is entirely new. Its new items form the Oversight Category (GV.OV), which asks leaders to review whether the cybersecurity strategy is achieving its outcomes, whether it covers the right areas, and whether risk management performance is good enough to justify changing direction. Two other new items sit in neighboring Categories: GV.RM-07 on how risk management strategy reacts to changing context, and GV.RR-01 on leadership accountability for cybersecurity risk.

• GV.OV-01: Results of the cybersecurity strategy are reviewed and used to adjust the strategy and its direction.
• GV.OV-02: The strategy is reviewed to confirm it still covers the organization's requirements and risks.
• GV.OV-03: Cybersecurity risk management performance is evaluated and reviewed for needed adjustments.
• GV.RM-07: Strategic opportunities and changing context are characterized and included in risk discussions.
• GV.RR-01: Organizational leadership is responsible and accountable for cybersecurity risk.

Evidence for these items is usually meeting minutes, board or committee packs, strategy review records and dated decisions showing that results changed direction. A 1.1 governance binder rarely contains this trail. Check whether your leadership reviews are recorded with outcomes, not only attendance.

Identify gains one new item in CSF 2.0. Much of the 1.1 Identify content moved into Govern, and the Improvement Category (ID.IM) was added so that lessons from evaluations, tests, exercises and daily operations feed back into the program. ID.IM-01 is the new Subcategory and it is the only new item in this Function. It is the link between assessments and the plans that people actually use.

• ID.IM-01: Improvements are identified from evaluations, including assessments, tests and exercises.
• Related Subcategories: ID.IM-02 and ID.IM-03 cover improvements from tests and operations and the maintenance of incident response and other operational plans, so the new item is best evidenced alongside them.
• Evidence shift: A dated improvement log that links each finding to a plan update or closed action is stronger than a list of past audit findings.
• Scope check: Confirm whether your 1.1 asset and risk records feed the improvement log, since NIST expects findings to reach the plan owners.
• Ask your assessor: Which tests and exercises they will accept as evaluation sources for ID.IM-01.

The new evidence for ID.IM-01 is usually an improvement register with owners, due dates and closure proof. If your 1.1 program only tracked findings without closing them, this item will look unmet even though the older Subcategories were answered.

Protect has one new item, PR.AA-04, in the Identity Management, Authentication and Access Control Category. CSF 1.1 PR.AC became PR.AA, and PR.AA-04 covers identity assertions, meaning how identity information is communicated and trusted across systems. The Category's other items cover identities, credentials, proofing, authentication and permissions, and PR.AA-04 is the one that most often exposes weak federation and single sign-on records.

• PR.AA-04: Identity assertions are protected, conveyed and verified, for example through signed tokens or federated sign-on.
• Split mapping: The 1.1 access control Subcategory PR.AC-1 maps to PR.AA-01 and PR.AA-05 in NIST's crosswalk, so existing access evidence needs rework rather than a simple relabel.
• Evidence to produce: Identity provider configuration exports, token lifetime and signing settings, and federation trust records.
• Scope check: Confirm which applications accept identity assertions from outside your directory, including SaaS and partner integrations.
• Ask your assessor: Whether configuration exports or test results are preferred as evidence for assertion protection.

The new evidence for PR.AA-04 is technical configuration and test output from identity systems. A 1.1 policy stating that access is controlled does not show how assertions are protected.

Five of the new items sit in the Respond and Recover Functions and one of them is in Respond. Respond gains RS.AN-07, which concerns how incident data is collected and preserved for analysis. Recover gains three new items in the Incident Recovery Plan Execution Category (RC.RP), which cover how recovery actions are verified and when recovery is declared complete. Detect has no new Subcategories in this list, but its 1.1 content was restructured, so check mappings there too.

• RS.AN-07: Incident data and metadata are collected, preserved and integrity-protected for analysis.
• RC.RP-04: Recovery-related norms are set after an incident, such as public or stakeholder expectations for restored services.
• RC.RP-05: The integrity of restored assets is verified before they return to service.
• RC.RP-06: The end of recovery is declared based on documented criteria and the incident is recorded.
• Evidence to produce: Forensic collection records with hash or chain-of-custody details, restoration checklists signed off before go-live, and a documented recovery closure form.

The new recovery items need evidence from actual or tested recoveries, such as restoration test logs that show integrity checks. A 1.1 disaster recovery plan that has never been exercised will not satisfy RC.RP-05 by itself.

The 11 new Subcategories are GV.RM-07, GV.RR-01, GV.OV-01, GV.OV-02, GV.OV-03, ID.IM-01, PR.AA-04, RS.AN-07, RC.RP-04, RC.RP-05 and RC.RP-06. Govern holds the largest share, and the Oversight Category is entirely new. NIST says no content was removed from CSF 1.1, so a 1.1 program is not wasted, but the new items need their own evidence rather than a relabel of older records.

• Count: Five items in Govern, one in Identify, one in Protect, four across Respond and Recover, which totals 11.
• Relocated items: Gaps in 2.0 numbering mark 1.1 Subcategories that moved, so an old identifier may now mean a different outcome.
• Crosswalk use: NIST's transition resources, including the Core Transition Changes spreadsheet, show which 1.1 items feed each new 2.0 item.
• Evidence reuse: Reuse the 1.1 record where the outcome is unchanged, and add dated, specific evidence for the new items.
• Ask your assessor: Which mapping they will use and whether they expect a 2.0 Current Profile to cite the new items.

Before you rely on any prior assessment, confirm which of the 11 items your current evidence set actually covers.

The organization owns its cybersecurity program, so it also owns the decisions that move a CSF 1.1 program into CSF 2.0. Leadership decides how each relocated or split CSF 1.1 Subcategory maps to its CSF 2.0 successors, signs the Current and Target Profiles, and keeps the evidence that shows each outcome is in place. NIST's crosswalk and transition spreadsheet are inputs to these decisions, not answers that can be accepted unreviewed.

• Mapping decisions: Accept, adjust or reject each proposed CSF 1.1 to 2.0 mapping, including splits such as PR.AC-1 moving across PR.AA-01 and PR.AA-05.
• Profile sign-off: Named executives approve the Current Profile and the Target Profile, since these record the organization's own status and goals.
• Evidence custody: Policies, tickets, logs and review records stay in the organization's systems, with owners assigned for each.
• Governance decisions: The Govern Function outcomes, including the new GV.OV Oversight Subcategories, need board or leadership records that only the organization can create.

Check that your mapping register names an accountable owner for every Subcategory and that someone inside the organization can explain each decision to an assessor.

An implementation partner such as DeployOpen can prepare the systems, mapping workbooks and evidence the organization needs to run the transition. Its work is technical and documentary: it builds the working mapping from CSF 1.1 to CSF 2.0, configures the platforms that generate evidence, and records where outcomes are not yet met. It does not decide the organization's risk positions and does not issue any report, attestation or certificate.

• Mapping workbooks: Converting the NIST transition resources into a working register that lists each CSF 1.1 Subcategory, its CSF 2.0 successors and the evidence source for each.
• Systems and logging: Configuring self-hosted tools so that the evidence for relocated Categories, such as platform security and identity controls, is generated and retained.
• Gap documentation: Recording where the current program does not yet meet a CSF 2.0 outcome, with the remediation owner and the evidence still missing.
• Evidence packs: Assembling the artifacts that the organization reviews and then presents, without changing the organization's conclusions.

Ask for the written scope and deliverables before work starts, and confirm that every workbook and pack will be reviewed and approved by the organization's own owners.

An independent assessor or auditor is the only party that can give a third-party view of the mapping. NIST does not offer certification or endorsement of CSF implementations or services, and it has no plans for a conformity assessment program, so any independent report on a CSF 2.0 transition comes from a firm chosen for that engagement, not from NIST. The assessor tests whether the organization's stated mapping and Profiles are supported by evidence, then reports its own findings.

• Independence: The assessor must be separate from the team that built the mapping, so the testing is not self-reviewed.
• Testing scope: Agree in writing which Categories, Subcategories and Profiles the assessor will test, and what sampling it will use.
• Reports: Only the assessor issues the report, and its wording is set by the assessor and the engagement terms.
• Customer requirements: Confirm whether the customer or contract accepts an independent view, and in what form, before the work is commissioned.

Ask the assessor what it will test and what it will produce, and confirm in advance that the contracting party accepts that output.