NIST Privacy Framework 1.1 vs 1.0: Every Change Mapped

NIST Privacy Framework 1.1 looks like a modest update if you only read the totals. Version 1.0 had 100 Subcategories; NIST Privacy Framework 1.1 has 102. Two more outcomes, and you might reasonably conclude that an existing programme needs a light touch-up.

It does not. Four Categories were retired, six were created, and 34 Subcategory identifiers moved. Map your old evidence across by identifier alone and a substantial part of it lands on the wrong outcome.

What this guide covers

• NIST Privacy Framework 1.1 is still a draft
• What changed at a glance
• The three stated goals of NIST Privacy Framework 1.1
• Four Categories retired in NIST Privacy Framework 1.1
• Six Categories new in NIST Privacy Framework 1.1
• Where the 34 moved identifiers went
• Two Subcategories withdrawn
• What NIST Privacy Framework 1.1 adds that 1.0 did not have
• Why the numbering has gaps
• Migrating a 1.0 programme to NIST Privacy Framework 1.1
• Frequently asked questions
• Documentation for the transition

NIST Privacy Framework 1.1 is still a draft

Before anything else: version 1.1 is an Initial Public Draft, published 14 April 2025 as NIST CSWP 40 ipd. The comment period closed on 13 June 2025 and NIST has not announced a publication date for the final.

Version 1.0, published 16 January 2020, remains the only final version. Nobody can be certified against either — no such scheme exists — and the correct phrasing for a programme built on 1.1 is aligned to the draft.

The draft’s own Note to Reviewers also asks reviewers whether NIST should renumber the Subcategory identifiers in the final draft, to close the gaps that this relocation created. So the numbering below may itself change.

What changed at a glance

The count moving from 100 to 102 is the misleading part. Underneath it, the Protect and Identify Functions were substantially re-cut.

The three stated goals of NIST Privacy Framework 1.1

NIST gives three reasons for the update: address current privacy risk management needs, realign with the NIST Cybersecurity Framework 2.0, and enhance usability. The second is the one that drove the structural changes, and it is the strongest argument for building to the draft rather than to 1.0 — if you already run a CSF 2.0 programme the two now share a vocabulary, whereas 1.0’s Protect Function still uses category names CSF 2.0 retired.

Four Categories retired in NIST Privacy Framework 1.1

The ID.DE-P relocation carries the most weight for an existing programme. Ecosystem risk — how you manage the third parties that process data for you — stops being something you identify and becomes something you govern. Accountability moves to leadership rather than to whoever maintains the inventory.

Six Categories new in NIST Privacy Framework 1.1

Govern-P grew from four Categories to seven. Protect-P kept its size but changed shape almost entirely — PR.PO-P retains only two of its former ten Subcategories.

Where the 34 moved identifiers went

This is the table an existing programme actually needs. Every relocation is taken from the draft’s own “Moved to” pointers.

Note the one-to-many rows. PR.AC-P3 became three outcomes; PR.DS-P5 became three. Evidence that satisfied one 1.0 Subcategory may only partially satisfy its successors, which is why an arithmetic conversion of an old Profile does not work.

Two Subcategories withdrawn

Two outcomes were removed with no successor:

• ID.RA-P2 — withdrawn. It related to artificial intelligence systems.
• CM.AW-P8 — withdrawn.

Evidence held against these is retired, not remapped. Do not attach it to a neighbouring identifier to keep a coverage figure looking tidy.

ID.RA-P2’s withdrawal does not put AI outside the framework. An AI system performing data actions is assessed like any other system, and NIST Privacy Framework 1.1 adds CT.DM-P11, a new Subcategory requiring stakeholder privacy preferences to be included in algorithmic design objectives and outputs evaluated against them.

What NIST Privacy Framework 1.1 adds that 1.0 did not have

The migration tables above deal with outcomes that moved. Three outcomes are genuinely new, and a programme aligned to 1.0 will have nothing against them at all.

GV.RM-P7 is easy to skip, because a register of positive risks looks like an odd artefact until you use it. Its purpose is to give privacy improvements that also deliver a commercial benefit somewhere to be recorded, which is a materially easier case to argue for funding than a purely defensive one.

GV.OV-P deserves attention for a different reason. Oversight asks for strategy outcomes to be reviewed, not activity. A management review that reports how many assessments were performed has not satisfied it; one that reports whether privacy risk is lower than at the last review, and how that is known, has.

Why the numbering has gaps

Relocation left holes: ID.RA has no P2, GV.PO has no P3 or P4, GV.RM has no P3, PR.PO is missing P1, P2, P3, P4 and P6, and PR.DS is missing P4 through P7.

These gaps are expected. A missing number is not a missing document and not an incomplete framework — and it is exactly what the Note to Reviewers proposes closing by renumbering.

There is a practical consequence worth planning for. If you cite NIST Privacy Framework 1.1 identifiers in a policy, a contract clause, an audit checklist or a supplier questionnaire, a renumbering at final would leave every one of those references pointing at a different outcome. Hold the identifiers in one place that feeds the rest — a single register, a single workbook column — rather than typing them across dozens of documents. That way a renumber is one edit, and the alternative is a document-by-document sweep with no reliable way to confirm you caught them all.

Migrating a 1.0 programme to NIST Privacy Framework 1.1

1. List every 1.0 Subcategory for which you hold evidence.
2. Look each up in the table above. Absent from it means unchanged — it carries over.
3. Re-point the evidence to the new identifier in your evidence register.
4. Retire the evidence for the two withdrawn Subcategories, ID.RA-P2 and CM.AW-P8, with a dated note.
5. Re-run the Current Profile against all 102. Do not convert the old one arithmetically.
6. Have someone independent confirm every piece of evidence has exactly one home.

Step 5 is the one most likely to be skipped and the one that matters. The Categories were re-cut, not merely renamed — an outcome that moved from Protect-P into Govern-P is now assessed in a different context, and the honest answer may have changed.

On how to run that reassessment without simply restating the old position, see Current and Target Profiles.

For background on the framework as a whole see our NIST Privacy Framework guide, and on why a security programme will not find these risks, privacy risk vs cybersecurity risk. The draft itself is free at nist.gov/privacy-framework.

Frequently asked questions

Should we move to NIST Privacy Framework 1.1 now?

If you are starting fresh, building to 1.1 avoids adopting Protect categories that CSF 2.0 already retired. If you have a working 1.0 programme, the migration is real work and the identifiers may change again before the final — so the case for moving now rests on the CSF 2.0 alignment, not on urgency.

Will the identifiers change again?

Possibly. The draft explicitly asks reviewers whether NIST should renumber the Subcategory identifiers in the final draft to close the gaps left by relocation. Keep identifiers in a place you can revise rather than embedded across dozens of documents.

Is version 1.0 now obsolete?

No. Version 1.0 is the only final version and remains the correct citation for anything that needs a published reference. Version 1.1 is a draft, however far ahead of 1.0 it is structurally.

Does 1.1 add new obligations?

It is voluntary, so it adds no obligations in the legal sense. It does add outcomes that were absent from 1.0 — notably GV.OV-P Oversight, GV.RM-P7 on strategic opportunities, and CT.DM-P11 on algorithmic design — so a programme aligned to 1.0 will have gaps against 1.1.

Documentation for the transition

Our NIST Privacy Framework Toolkit is 145 editable Word and Excel templates covering all 102 Subcategories of the draft, and it ships a PF 1.0 to PF 1.1 Transition Guide carrying every relocation in the table above, plus Current and Target Profile workbooks pre-loaded with all 102 outcomes so a remap is a re-assessment rather than a rebuild.