NIST Privacy Framework 1.1 Guide: Core, profiles and CSF 2.0 alignment explained

Security teams that already run on NIST CSF 2.0 are routinely asked to show privacy outcomes too, and without a shared structure the privacy programme ends up as a parallel set of spreadsheets that nobody can map to controls. The NIST Privacy Framework gives privacy risk the same Functions, Categories and Subcategories model as the Cybersecurity Framework, and version 1.1 realigns it with CSF 2.0. This guide explains the status of each version, the 1.1 Core and what moved, how Profiles and Implementation Tiers work, where identity and non-human identity outcomes sit, how to implement it alongside CSF 2.0, and what evidence an assessor will ask for. It is written for security and privacy leads, GRC teams and engineers who need one control language for both disciplines.

Key takeaways

• Version 1.1 is still a draft. As checked on 27 October 2026, NIST lists Privacy Framework 1.1 as an Initial Public Draft (NIST CSWP 40, 14 April 2025, comments closed 13 June 2025) with the final release "coming soon"; version 1.0 from January 2020 remains the current final.
• Five Functions, two of them shared with security. Identify-P, Govern-P, Control-P and Communicate-P cover privacy-specific outcomes; Protect-P covers cybersecurity-related privacy events and can be replaced by the CSF 2.0 Functions.
• 1.1 follows the CSF 2.0 shape. Protect-P now uses CSF 2.0 category names such as PR.AA-P, PR.DS-P, PR.PS-P and PR.IR-P, supplier risk moves into Govern-P as GV.DE-P, and a new GV.RR-P covers roles.
• Services and hardware are identities too. PR.AA-P1 requires identities and credentials for authorised individuals, services and hardware to be managed, which brings service accounts, API keys and devices that touch personal data into scope.
• Profiles do the work, Tiers do not. NIST is explicit that success depends on achieving Target Profile outcomes, not on reaching a particular Implementation Tier.

What it is and who it applies to

The NIST Privacy Framework is a voluntary tool for identifying and managing privacy risk while building products and services that protect individuals' privacy. It is not a law and creates no obligations by itself, but it is widely used as the operating model that sits under legal requirements such as GDPR, US state privacy laws and sector rules. For the broader programme structure, see the Privacy Programme Guide for Security Teams; this page goes into the framework itself.

Because 1.1 is a draft, subcategory identifiers and wording can still change. NIST has already left numbering gaps (for example ID.RA-P2 is withdrawn) and asked for feedback on whether to renumber, so build Profiles in a way that can absorb a remapping.

• Who uses it: any organisation that processes personal data, from small businesses (NIST publishes a Quick Start Guide) to federal agencies that pair it with SP 800-53 Rev. 5 privacy controls.
• Who owns it: typically the privacy office for Identify-P, Control-P and Communicate-P, with security owning Protect-P and both sharing Govern-P.
• Related NIST work: NIST has also announced a Data Governance and Management Profile as a separate project, and the 1.1 draft points to the AI Risk Management Framework for AI-specific risks. See the NIST AI RMF Guide.

Structure and key requirements

The framework has three parts: the Core (Functions, Categories, Subcategories), Profiles and Implementation Tiers. Privacy risk is framed as problems individuals may experience from data processing, which is why the Core talks about "data actions" rather than systems alone.

The 1.1 Core

What changed from 1.0

• Realignment with CSF 2.0: the 1.1 draft follows CSF 2.0 structure wherever possible, and marks Categories and Subcategories that are identical to or adapted from CSF 2.0.
• Govern-P grows: a new GV.RR-P category for roles, and the former ID.DE-P (data processing ecosystem) moves to Govern-P as GV.DE-P, mirroring CSF 2.0's move of supply chain risk into Govern.
• Protect-P restructured: the 1.0 categories PR.AC-P, PR.MA-P and PR.PT-P are withdrawn and their subcategories relocated into the CSF 2.0 style categories listed above.
• AI section: a new section 1.2.2 covers privacy risk in AI systems across the lifecycle, pointing to GV.RR-P for AI workforce roles, GV.MT-P for reviewing policies against AI risks, and Control-P and Communicate-P for de-identification and individuals' preferences. The AI-specific subcategory ID.RA-P2 is withdrawn to keep the Core technology neutral.
• Guidance moved online: the former Section 3 (how to use the framework) moves to the Privacy Framework website.

Profiles and Tiers

• Current Profile: the outcomes the organisation achieves today. Target Profile: the outcomes it needs. The gap between them is the roadmap. Sectors can publish Community Profiles. NIST does not prescribe a Profile template.
• Implementation Tiers: Tier 1 Partial, Tier 2 Risk Informed, Tier 3 Repeatable, Tier 4 Adaptive. They describe how privacy risk management is practised, from informal and reactive to adaptive. Progression is not required.

Using it with CSF 2.0

See the NIST CSF 2.0 Guide and the NIST CSF 2.0 Profiles and Tiers Guide.

Identity and NHI requirements

The identity outcomes in Protect-P are written to cover more than people. PR.AA-P1 in the 1.1 draft reads "Identities and credentials for authorized individuals, services, and hardware are managed by the organization", PR.AA-P3 requires individuals, services and hardware to be authenticated commensurate with risk, and PR.AA-P5 covers access permissions defined in policy and reviewed. These match CSF 2.0 PR.AA-01 and PR.AA-05.

• Map identities to data actions: ID.IM-P4 to ID.IM-P8 ask for data actions, purposes, data elements and processing environments to be inventoried and mapped. Each data action is performed by an identity, very often a service account, ETL job, API client or AI agent. Record which non-human identity performs each data action; that is the evidence that PR.AA-P5 least privilege is real. See the Data Mapping and ROPA Guide.
• Credentials for processors and partners: GV.DE-P2 uses contracts with data processing ecosystem parties to implement privacy measures. API keys and OAuth grants issued to processors are where those contracts become technical; scope, expiry and revocation on termination belong in the contract and the identity platform. See the Third-Party Access Guide.
• Logs about identities are personal data: CT.DM-P9 requires log records to be determined, documented, implemented and reviewed according to policy. Authentication logs record people; minimise and retain them deliberately. See the Privacy in Security Logging and Monitoring Guide.
• Disassociated processing for identity data: CT.DP-P2 (limit identification, for example by de-identification or tokenisation) and CT.DP-P5 (substitute derived attribute values, such as "over 18" instead of a date of birth) apply directly to identity attributes passed in tokens and assertions.
• AI agents: an agent that reads personal data is a service identity under PR.AA-P1 and its data actions belong in ID.IM-P. Treat agent tool access as a data action with a purpose. See the Identity Data Privacy and Consent Guide.

Implementation steps

1. Decide the version and the model. Use 1.0 for any formal attestation in the next cycle, design new Profiles against the 1.1 draft using NIST's 1.0 to 1.1 mapping, and choose the combined model if a CSF 2.0 Profile exists.
2. Set scope. Pick a product line, business unit or data domain rather than the whole enterprise for the first Profile.
3. Build the Current Profile. Work through ID.IM-P first: inventory systems, owners, categories of individuals, data actions, purposes, data elements and processing environments, then score each selected subcategory as achieved, partial or not achieved.
4. Run a privacy risk assessment. ID.RA-P asks for privacy risk to be assessed against problems for individuals. Use a DPIA format where law requires one. See the DPIA Guide.
5. Write the Target Profile. Select the subcategories that legal requirements, risk appetite and contracts demand, and note the legal driver for each.
6. Plan the gap. Prioritise by risk to individuals, not by ease. Typical first items: data inventory gaps, retention and destruction (CT.DM-P5), access reviews for service identities (PR.AA-P5), processor assessments (GV.DE-P4).
7. Assign owners using GV.RR-P. Every subcategory needs an accountable owner in privacy, security, engineering or legal.
8. Review on a cycle. GV.MT-P requires monitoring and review; reassess at least annually and whenever the final 1.1 is published, using NIST's mapping to rebase identifiers.

Small versus large organisations: a small organisation can start from the Quick Start Guide and a single Profile covering ID.IM-P, CT.DM-P and PR.AA-P. A large one will need Profiles per business unit, a Community Profile if the sector has one, and tooling that stores subcategory evidence alongside CSF 2.0 evidence.

Evidence and assessment

The framework has no certification scheme. Assessments are self-assessments, internal audit reviews or third-party reviews against a declared Profile.

Metrics:

• Percentage of systems processing personal data with a complete ID.IM-P record (owner, purpose, data elements, location).
• Percentage of Target Profile subcategories achieved, tracked per quarter.
• Median time to fulfil access and deletion requests (CT.DM-P1 and P4).
• Percentage of service identities with access to personal data that were reviewed in the last cycle.
• Percentage of processors assessed in the last 12 months (GV.DE-P4).

Mapping to other frameworks

NIST hosts crosswalks for the 1.0 Core, including GDPR, ISO/IEC 27701, CCPA and CPRA, LGPD, the Fair Information Practice Principles, CSF and SP 800-53 Rev. 5. The table below is indicative; use the official crosswalks for formal mapping.

For the management system standard, see the ISO/IEC 27701 Privacy Information Management Guide, and for 800-53 itself the NIST SP 800-53 Guide.

Common pitfalls

• Treating the draft as final. Citing 1.1 subcategory IDs in contracts or audit reports before the final release risks remapping work. Reference 1.0 for formal commitments until NIST publishes 1.1.
• Running Protect-P and CSF 2.0 in parallel. Two teams scoring the same access control and data security outcomes under different IDs produces contradictory answers. Pick the combined model and share evidence.
• An inventory of systems, not data actions. ID.IM-P asks for data actions, purposes and data elements. A CMDB list of applications does not show what personal data each processes or why.
• Ignoring non-human identities. Access reviews that cover only employees miss the integration accounts and API clients that perform most data actions.
• Chasing Tiers. Reporting "we are Tier 3" without a Target Profile says nothing about outcomes. NIST ties success to Profile outcomes.
• No legal driver per subcategory. Without recording which law or contract requires an outcome, the Target Profile cannot be defended when budgets are cut.

Practitioner checklist

• Record which version (1.0 final or 1.1 draft) each Profile uses and the date its status was checked.
• Choose the combined model with CSF 2.0 if a security Profile already exists.
• Complete ID.IM-P inventories at the level of data actions, purposes and data elements, including the identity that performs each action.
• Bring service accounts, API clients and AI agents that touch personal data into PR.AA-P access reviews.
• Write a Target Profile with a legal or contractual driver and an owner for each subcategory.
• Link processor contracts and API credential scopes under GV.DE-P.
• Apply CT.DM-P9 to security logs: decide what identity data is logged and for how long.
• Use NIST's official crosswalks for GDPR, ISO/IEC 27701 and SP 800-53 mappings.
• Plan a rebase to the final 1.1 Core using NIST's 1.0 to 1.1 mapping when it is published.

Standards and references

• NIST: Privacy Framework
• NIST: CSWP 40, NIST Privacy Framework 1.1 (Initial Public Draft)
• NIST: Privacy Framework 1.1 Initial Public Draft (PDF)
• NIST: Privacy Framework Version 1.1 project page
• NIST: Privacy Framework crosswalks
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls

Related NHI Mgmt Group resources: Privacy Programme Guide for Security Teams · NIST CSF 2.0 Guide · ISO/IEC 27701 Privacy Information Management Guide · DPIA Guide · GDPR Compliance Guide for Security Teams