NIST Privacy Framework: Managing Privacy Risk in Software and Data

The NIST Privacy Framework is a voluntary tool from the US National Institute of Standards and Technology that helps organisations identify and manage privacy risk. Released as version 1.0 in January 2020, it follows the structure of the NIST Cybersecurity Framework, so security and privacy teams can work from compatible models. It does not tell you which law applies; instead, it helps you build a program that can meet many laws at once.

NIST published a draft version 1.1 in April 2025 to align with Cybersecurity Framework 2.0 and address AI, and the final 1.1 had not been released as of October 2026. This guide explains the Core, Profiles and Tiers, how NIST defines privacy risk, how to use the framework in software development, and how it maps to the GDPR, US state laws and ISO/IEC 27701.

What is the NIST Privacy Framework?

The Privacy Framework was developed by NIST through public workshops and comment periods between 2018 and 2020. It is designed to be law-neutral, technology-neutral and usable by any organisation, regardless of size or sector. It has three parts:

• Core: a set of privacy activities and outcomes arranged in functions, categories and subcategories.
• Profiles: selections of Core outcomes that represent an organisation's current privacy activities or its target state.
• Implementation Tiers: a way to describe how well an organisation's processes and resources manage privacy risk.

It is a framework, not a law or certifiable standard, so it complements legal compliance rather than replacing it.

How NIST defines privacy risk

NIST frames privacy risk differently from security risk. Security risk arises from unauthorised activity affecting confidentiality, integrity and availability. Privacy risk arises from problematic data actions: operations on data, even authorised ones, that can cause problems for individuals, such as dignity loss, discrimination, economic loss, loss of trust or loss of autonomy. Examples include re-identification, unanticipated revelation, surveillance, distortion and insecurity. Privacy and security risks overlap where a breach causes privacy harm, but privacy risk also exists when a system works exactly as designed.

This view is useful for product teams: a recommendation engine that infers health conditions, or a feature that exposes location to other users, may be secure and still create privacy risk.

Is it mandatory or voluntary?

Voluntary. US federal agencies use it alongside required NIST guidance, some contracts and procurement questionnaires reference it, and some state laws let organisations show reasonable practices by aligning with recognised frameworks. There is no certification.

The Core functions in version 1.0

Function	Purpose	Example categories
Identify-P	Understand privacy risks from data processing	Inventory and mapping, business environment, risk assessment, data processing ecosystem risk management
Govern-P	Establish governance structure for privacy risk	Policies and procedures, risk management strategy, awareness and training, monitoring and review
Control-P	Enable management of data with sufficient granularity	Data processing policies, data processing management, disassociated processing
Communicate-P	Enable reliable understanding and dialogue about processing	Communication policies, data processing awareness
Protect-P	Develop and implement data processing safeguards	Data protection policies, identity management and access control, data security, maintenance, protective technology

Identify-P, Govern-P, Control-P and Communicate-P address privacy risk from authorised processing. Protect-P addresses privacy breaches and overlaps with the Cybersecurity Framework; organisations already using the CSF can use its Protect function in place of Protect-P.

What Core outcomes look like in practice

Subcategories are written as outcomes, not instructions, so each organisation decides how to achieve them. A few examples show how they translate into everyday work:

• Inventory and mapping: systems, products and services that process data are inventoried, along with the owners, data categories, purposes and data actions involved. In practice, a maintained data map linked to the architecture diagram.
• Data processing ecosystem risk management: third parties in the data processing ecosystem are identified, assessed and bound by contracts. In practice, a vendor register with privacy assessments and data processing agreements.
• Data processing management: data elements can be accessed for review, transmission, correction, deletion and retention policies. In practice, admin tools and APIs that can find, export, correct and delete one person's data across systems.
• Disassociated processing: data is processed in ways that limit observability and linkability. In practice, pseudonymous analytics IDs and aggregated reporting.
• Data processing awareness: mechanisms exist for communicating data processing purposes, practices and associated risks. In practice, layered notices, release notes for privacy-relevant changes and a privacy centre.
• Monitoring and review: privacy values, policies and training are reviewed and updated, and privacy risk is re-evaluated as conditions change. In practice, an annual review and a trigger to reassess when a product adds new data types.

Roles and ownership

The framework works best when responsibilities are clear. Senior leadership sets risk tolerance and approves the Target Profile. A privacy lead or data protection officer coordinates the program and legal requirements. Product managers own privacy risk for their features and include it in requirements. Engineers implement controls such as deletion, consent and access restrictions, and keep data maps current. Security teams own Protect-P outcomes in line with the security program. Customer support and marketing teams handle rights requests and communications. Writing these roles into the Govern-P function avoids the common situation where privacy belongs to everyone and therefore no one.

Profiles and Implementation Tiers

A Current Profile records which Core outcomes an organisation achieves today. A Target Profile records the outcomes it wants to achieve, based on its laws, contracts, risk tolerance and mission. The gap between them becomes the roadmap. Profiles can be built for the whole organisation, a product line or a single system.

Implementation Tiers range from Tier 1 (Partial) through Tier 2 (Risk Informed) and Tier 3 (Repeatable) to Tier 4 (Adaptive). They describe the maturity of privacy risk management processes, integration across the organisation, workforce and ecosystem relationships. Tiers are not a scoring system; organisations choose the tier that fits their risk.

Version 1.1

NIST released the Privacy Framework 1.1 Initial Public Draft (NIST CSWP 40) on 14 April 2025, with comments closing on 13 June 2025. The draft aligns the framework's structure with Cybersecurity Framework 2.0, which added a Govern function in 2024, revises Core categories and subcategories, adds material on AI and privacy risk, and moves guidance on using the framework into online resources. NIST's project page still described the final version as coming soon in 2026. Organisations can start with version 1.0 and map to 1.1 when it is final; most outcomes carry over.

Who uses it

The framework is used well beyond US federal agencies. Software and SaaS companies use it to structure privacy programs that span several jurisdictions. Healthcare, financial services and education organisations use it to organise privacy work that sits outside their sector laws, such as marketing and analytics. Startups use small Target Profiles to prepare for enterprise customer questionnaires. Consultancies and auditors use it as a common reference when assessing privacy maturity. Because NIST publishes crosswalks to laws and standards, it also serves as a translation layer between legal teams, which think in terms of statutes, and engineering teams, which think in terms of systems and controls.

It is particularly useful for organisations that do not want or need ISO/IEC 27701 certification but still want a recognised, defensible structure that customers and regulators will understand.

How to use it, step by step

1. Set scope: the organisation, a product or a system.
2. Inventory and map data processing, including systems, data types, purposes, data flows and third parties.
3. Identify legal and contractual requirements, such as the GDPR, CCPA, DPDP Act, sector laws and customer contracts.
4. Assess privacy risk by identifying problematic data actions, their likelihood and impact on individuals. NIST's Privacy Risk Assessment Methodology (PRAM) worksheets help.
5. Build Current and Target Profiles, choosing subcategories relevant to your risks and requirements.
6. Prioritise gaps and create an action plan with owners.
7. Implement controls, often drawn from NIST SP 800-53 privacy controls or ISO/IEC 27701.
8. Monitor and review as products, laws and risks change.

Using the framework in software development

For engineering teams, the framework translates into concrete practices:

• Inventory and mapping: maintain data maps generated from schemas, data catalogues and API definitions.
• Disassociated processing: use pseudonymisation, aggregation, differential privacy or on-device processing to reduce identifiability.
• Data processing management: build retention, deletion, correction and export capabilities into data models from the start.
• Communication: design just-in-time notices, preference centres and clear settings.
• Privacy reviews: add privacy risk questions to design reviews and pull request templates for features touching personal data.
• Protection: apply access control, encryption and logging aligned with security practice.

This approach also supports privacy by design obligations under the GDPR and similar laws.

Integrating with the Cybersecurity Framework and AI RMF

NIST designed its frameworks to be used together. The Privacy Framework and the Cybersecurity Framework share a structure, so organisations can run one assessment covering both and avoid duplicated control work in areas like access control and data security. The AI Risk Management Framework adds outcomes for AI systems, such as managing bias and transparency, and the 1.1 draft adds privacy considerations for AI, such as data used for training and inferences produced by models. A product team building an AI feature can therefore check security, privacy and AI risk outcomes in one design review.

Measuring progress

Because the framework is outcome-based, measurement matters. Useful indicators include the percentage of systems with current data maps, time to complete access and deletion requests, number of features that completed a privacy review before release, vendors with completed privacy assessments, and privacy incidents and their root causes. Tracking the gap between Current and Target Profiles each quarter shows leadership how the program is moving and where to invest next.

Documentation you will need

• Scope and data processing inventory and maps.
• Legal and contractual requirements register.
• Privacy risk assessments.
• Current and Target Profiles and the gap analysis.
• Policies for data processing, retention and communication.
• Action plan and progress tracking.
• Training records and review reports.

Timeline and cost considerations

A first Current and Target Profile for a mid-sized software company typically takes four to eight weeks, mainly in data mapping and interviews. Implementation of gaps takes months and depends on how mature data management is. There are no licence costs; NIST publishes the framework, mappings and tools for free.

Benefits and limitations

• Benefits: one program for multiple laws; shared language between legal, product and engineering; easy integration with the Cybersecurity Framework and AI Risk Management Framework; flexibility for any size.
• Limitations: no certification, so it carries less weight with buyers than ISO/IEC 27701; it does not tell you specific legal requirements; and the 1.1 transition means some mappings will change.

Common mistakes

• Treating privacy as only security and focusing only on Protect-P.
• Building Profiles without data maps, which leads to generic targets.
• Selecting every subcategory instead of those that fit the organisation's risks.
• Not involving engineering, so outcomes stay on paper.
• Assuming framework alignment equals legal compliance.

Best practices, tools and technologies

• Use NIST's crosswalks to map subcategories to laws and standards.
• Combine privacy and security profiles with the Cybersecurity Framework.
• Use the AI Risk Management Framework alongside it for AI features.
• Automate data discovery and classification.
• Use privacy-enhancing technologies where data utility allows.
• Choose ISO/IEC 27701 if customers want certification.

We build data inventories, preference centres, retention and deletion workflows into products through our web application development and SaaS product services.

How it maps to laws and standards

Law or standard	Relationship
GDPR	Framework outcomes support accountability, privacy by design, records and rights; NIST publishes a crosswalk.
US state privacy laws	Supports data protection assessments, notices and rights handling.
DPDP Act	Can structure notice, consent, rights and safeguard obligations.
ISO/IEC 27701	Certifiable privacy management system with overlapping controls.
NIST SP 800-53	Catalogue of privacy controls used to implement outcomes.

Real-world example

An Indian-built health and fitness SaaS with users in the US, EU and India uses the Privacy Framework to create one Target Profile covering the GDPR, US state laws and the DPDP Act. Data mapping reveals that analytics events include free-text notes. The team removes those fields, pseudonymises user IDs in analytics, adds an export and deletion feature, introduces a privacy question in design reviews and records progress against the Target Profile each quarter.

Next steps

1. Map your data processing.
2. List legal and contractual requirements.
3. Assess privacy risk using problematic data actions.
4. Build Current and Target Profiles.
5. Plan for version 1.1 when final.

Frequently asked questions

Is the NIST Privacy Framework mandatory?

No. It is voluntary, though some contracts and questionnaires reference it.

Can you get certified to the NIST Privacy Framework?

No. Organisations self-assess; ISO/IEC 27701 is the certifiable alternative.

What are the five functions?

Identify-P, Govern-P, Control-P, Communicate-P and Protect-P in version 1.0.

Is version 1.1 final?

Not as of October 2026. A draft was published in April 2025.

What is a problematic data action?

A data operation that could cause a problem for individuals, such as re-identification, surveillance or unanticipated revelation.

How is it different from the Cybersecurity Framework?

It focuses on privacy risks from data processing, including authorised processing, while the CSF focuses on security risks.

Does it help with GDPR compliance?

Yes, as a structure for accountability and privacy by design, though it does not replace legal analysis.

What are Implementation Tiers?

Four levels, from Partial to Adaptive, describing how mature privacy risk management processes are.

What is a Target Profile?

The set of Core outcomes an organisation aims to achieve based on its requirements and risk.

Can small companies use it?

Yes. It is designed to scale, and small companies can select a limited set of outcomes that match their main risks and customer requirements.