NIST Privacy Framework: NIST Privacy Framework – Tutorial (about 60 minutes)

The NIST Privacy Framework is a free, voluntary tool from the US National Institute of Standards and Technology (NIST) that helps any organisation identify and manage the privacy risks that arise when it processes data about people. It is used by privacy officers, security and engineering teams, product managers, legal and compliance staff and executives, in companies and public bodies of every size and in many countries. After this tutorial you will be able to explain how the framework thinks about privacy risk, read its Core, build Current and Target Profiles, choose a realistic Implementation Tier, and use it alongside the NIST Cybersecurity Framework and privacy laws.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The current final edition is NIST Privacy Framework: A Tool for Improving Privacy through Enterprise Risk Management, Version 1.0, published by NIST on 16 January 2020 as a Cybersecurity White Paper. A revision, Privacy Framework 1.1, was released as an Initial Public Draft (NIST CSWP 40 ipd) on 14 April 2025; its public comment period closed on 13 June 2025. As of the verification date, NIST's Privacy Framework page and the CSRC publication page still list 1.1 only as an Initial Public Draft, with no final version, so Version 1.0 remains the edition in force and is the one this course teaches. Where the 1.1 draft proposes changes (targeted revisions and restructuring of the Core to stay aligned with Cybersecurity Framework 2.0, a new section on artificial intelligence and privacy risk, and moving the usage guidance of Section 3 to the NIST website), this tutorial points them out so you are ready for the final release. Verified 2026-10-29.

Who this is for: engineers, architects and product owners who build systems that handle personal data; security professionals who are being asked to "cover privacy too"; privacy, legal and compliance staff who want a structured, risk-based method rather than a checklist; and managers who need to explain privacy posture to leadership, customers or partners.

Prerequisites: none. Some familiarity with the idea of risk management (likelihood, impact, controls) helps, and if you already know the NIST Cybersecurity Framework you will recognise the shape of the Core. Every term is defined when it first appears.

By the end of this tutorial:

You will be able to explain why NIST created the Privacy Framework, what problem it solves and why it is voluntary and outcome-based.
You will be able to describe the framework's model of privacy risk: data actions, problematic data actions, problems for individuals and impacts on the organisation.
You will be able to name the five Functions of the Core and say what kind of outcomes each one groups.
You will be able to build and compare a Current Profile and a Target Profile and turn the gaps into a prioritised action plan.
You will be able to describe the four Implementation Tiers and the four aspects they are judged on, and explain why the Tier is not a score to maximise.
You will be able to explain how use of the framework is assessed and why there is no official certification against it.
You will be able to position the framework next to the Cybersecurity Framework, ISO/IEC 27701, NIST SP 800-53 and privacy laws such as the GDPR.

Lesson 1 – Origins, purpose and scope

Why a privacy framework was needed

For years many organisations treated privacy as a legal topic: lawyers read the regulations, wrote a privacy notice and a set of policies, and engineers were asked to "make it compliant" late in a project. This approach has two weaknesses. First, laws differ between countries and change often, so a programme built only around one law is fragile. Second, compliance with a law does not guarantee that people are not harmed. A system can follow the letter of a regulation and still surprise, embarrass or disadvantage the people whose data it uses.

Security teams faced a similar problem a decade earlier, and NIST answered it with the Cybersecurity Framework (CSF), first published in 2014. The CSF gave organisations a common, risk-based vocabulary that executives and engineers could both use. Organisations that liked the CSF asked NIST for something comparable for privacy. NIST opened a public process in 2018 with a request for information, workshops and several drafts, and published Version 1.0 in January 2020. Like the CSF, it was developed openly with input from industry, government, academia and civil society.

What the framework is for

The framework's main idea is that privacy should be managed as a risk, alongside financial, operational, safety and security risks, rather than as a separate box-ticking exercise. Its subtitle, "a tool for improving privacy through enterprise risk management", says exactly this. Its goals can be summarised in three points:

Build trust by supporting ethical decisions in the design and use of products and services, so that people's privacy is considered from the start.
Meet obligations today and in the future, by giving a stable structure onto which current and new legal requirements can be mapped.
Improve communication about privacy practices with customers, partners, regulators and staff, using a shared language.

Scope and character

Several characteristics shape how you use the framework:

Voluntary. No law requires private organisations to adopt it, although some contracts, sector programmes or public bodies may ask for it.
Outcome-based. It describes outcomes to achieve ("data processing is mapped", "individuals are informed"), not specific technologies or controls to install.
Law-agnostic and technology-neutral. It does not restate any regulation and can be used in any country, sector or technology stack.
Scalable. A five-person start-up and a global bank can both use it, by choosing which outcomes matter for them.
Not a privacy notice or a policy. It is a structure for deciding, organising and communicating what you do; you still write your own policies, notices and procedures.
Complementary. It was designed to sit next to the Cybersecurity Framework and to be mapped to standards, laws and controls catalogues through "informative references".

The framework covers data about individuals in any form, digital or paper, and the whole data life cycle from collection to disposal. It also recognises that problems can arise even when data is not directly linked to a named person; for example, smart-city technologies could be used to steer where or how people move around a city.

Version 1.1 in brief

Five years after publication, NIST proposed a revision. The 1.1 draft keeps the same three-part design and the same basic approach, but makes targeted revisions to the Core and restructures it to follow the Cybersecurity Framework 2.0 (released in February 2024); for example, data processing ecosystem risk management moves from Identify-P into Govern-P, and Profiles are renamed Organizational Profiles. It also adds a short section on how artificial intelligence and privacy risk relate, and moves the long "how to use" guidance to the NIST website, where it is easier to update. Because 1.1 was still a draft on the verification date, treat its details as provisional and check the NIST site before you rely on a specific change.

Lesson 2 – Key concepts and vocabulary

The framework's power comes from a precise way of describing privacy risk. Learn these terms well; the rest of the framework is built from them.

Individual – a person (or group of people) whose data is processed or who interacts with a system, product or service. The framework is centred on what could happen to them.
Data action – any single operation in the data life cycle: collecting, retaining, logging, generating, transforming, using, disclosing, sharing, transmitting or disposing of data. "Our app reads the user's location every five minutes" is a data action.
Data processing – the collective set of data actions performed by a system, product or service.
Problematic data action – a data action that could cause an adverse effect, or problem, for individuals. Sharing a precise location history with an advertising partner may be problematic even if the sharing is technically secure.
Problem (for individuals) – the adverse effect a person experiences. NIST's examples run from harms to dignity, like being embarrassed or stigmatised, to concrete harms such as being discriminated against, losing money or being physically hurt.
Privacy event – the occurrence or potential occurrence of a problematic data action.
Privacy risk – the likelihood that individuals will experience problems resulting from data processing, combined with the impact should those problems occur.
Cybersecurity-related privacy event – a privacy event caused by a loss of confidentiality, integrity or availability, such as a data breach or an insider misusing access. This is where privacy and security risk overlap.
Privacy risk assessment – the sub-process of identifying and evaluating specific privacy risks so the organisation can weigh the benefits of processing against the risks and choose a proportionate response.
Privacy engineering objectives – three system properties from NIST IR 8062 that the framework uses throughout: predictability (people and operators can make reliable assumptions about what happens to data), manageability (data can be administered at a fine level, for example corrected, deleted or selectively disclosed) and disassociability (data or events can be processed without linking them to individuals or devices beyond what the operation needs).
Data processing ecosystem – the web of entities involved in or affected by processing: the organisation, its suppliers and service providers, manufacturers, developers, partners, government bodies, researchers, civil society and individuals themselves.
Core – the catalogue of privacy activities and outcomes, organised into Functions, Categories and Subcategories.
Profile – a selection of Core outcomes that an organisation has prioritised; a Current Profile records what is achieved today and a Target Profile what is needed.
Implementation Tier – one of four reference points describing how mature and well-resourced the organisation's privacy risk management is.
Informative reference – a mapping from a Subcategory to a standard, law, guideline or tool that helps implement it, often published as a "crosswalk".

Privacy risk is not the same as security risk

The single most important idea in the framework is that security and privacy overlap but are not identical. Security risk comes from threats to confidentiality, integrity and availability: attackers, failures, mistakes. Privacy risk can come from those same events, but it can also arise when everything works exactly as designed. A loyalty programme that correctly infers that a customer is pregnant and starts sending baby-product offers has not been hacked, yet the person may feel exposed. Smart electricity meters that faithfully record household consumption every few minutes can reveal when people are home or asleep. These are privacy risks from authorised processing.

Figure 1 – Privacy risk and cybersecurity risk overlap in cybersecurity-related privacy events, but privacy risk also arises from processing that works as designed.

This distinction explains why a strong security programme is necessary but not sufficient for privacy. Encryption, access control and monitoring prevent breaches; they do nothing about collecting more data than needed, using it for surprising purposes or making automated decisions people cannot challenge.

From problems for people to impacts on the organisation

Organisations often find it hard to prioritise privacy because the harm falls on someone else. The framework bridges this gap with a simple chain. A problematic data action creates a problem that an individual experiences directly. Because of that problem, the organisation suffers consequences of its own: customers abandoning the product, regulatory penalties and the cost of non-compliance, damage to reputation, or a loss of morale and culture inside the company. These organisational impacts are already familiar to enterprise risk management, so linking them back to individual problems lets privacy compete fairly for budget and attention.

Figure 2 – The framework connects problems that individuals experience to organisational impacts so privacy risk can be prioritised with other enterprise risks.

Lesson 3 – Structure of the framework

The framework has three parts that work together: the Core, Profiles and Implementation Tiers. The document itself also contains a short section on privacy risk management, a section on ways to use the framework, and five appendices: the full Core in table form, a glossary, acronyms, privacy risk management practices, and the definitions of the Tiers.

The Core

The Core is a hierarchy of outcomes. At the top are five Functions, the highest-level grouping of privacy activities. Each Function is divided into Categories, groups of outcomes tied to a programme need, and each Category is divided into Subcategories, specific outcomes of technical or management activities. Version 1.0 has 5 Functions, 18 Categories and 100 Subcategories. Every element has an identifier: the Function Identify-P is ID-P, its Category Inventory and Mapping is ID.IM-P and the Subcategories inside it are numbered ID.IM-P1, ID.IM-P2 and so on. The "-P" suffix exists so that privacy identifiers are never confused with Cybersecurity Framework identifiers.

Here is what each Function covers, in plain words, with its Categories:

Identify-P (ID-P) – understand the data processing and the privacy risks it creates. Categories: Inventory and Mapping (what systems, data, data actions and purposes exist and how data flows); Business Environment (the organisation's mission, role in the ecosystem and priorities); Risk Assessment (contextual factors, problematic data actions, likelihood and impact, and risk responses); and Data Processing Ecosystem Risk Management (managing privacy risk with suppliers, service providers and partners).
Govern-P (GV-P) – set up the governance that keeps privacy in the organisation's risk decisions. Categories: Governance Policies, Processes and Procedures (privacy values, policies, roles, legal requirements); Risk Management Strategy (risk tolerance and how privacy risk feeds enterprise decisions); Awareness and Training (staff, executives and third parties know their privacy roles); and Monitoring and Review (privacy risk is re-evaluated, and concerns, complaints and lessons learned are handled).
Control-P (CT-P) – give the organisation and individuals enough control over data to manage risk. Categories: Data Processing Policies, Processes and Procedures (for example, how authorisation, consent and preferences are handled); Data Processing Management (data can be reviewed, transmitted, altered, deleted and its processing limited in a controlled way); and Disassociated Processing (processing designed to limit observability and linkability, for example by de-identification or local processing on devices).
Communicate-P (CM-P) – make sure organisations and individuals understand how data is processed and can talk about it. Categories: Communication Policies, Processes and Procedures; and Data Processing Awareness (notices and reports, feedback channels, and informing people about data corrections or breaches).
Protect-P (PR-P) – put data processing safeguards in place to prevent cybersecurity-related privacy events. Categories: Data Protection Policies, Processes and Procedures; Identity Management, Authentication and Access Control; Data Security; Maintenance; and Protective Technology.

Notice the deliberate split. Identify-P, Govern-P, Control-P and Communicate-P handle privacy risks from data processing in general. Protect-P handles the security overlap. For detecting and responding to breaches, NIST suggests using the Detect, Respond and Recover Functions of the Cybersecurity Framework rather than duplicating them. An organisation can also use all CSF Functions together with the four privacy-specific ones, so a single programme covers both risks.

The Functions are not a sequence. NIST explicitly states that they should be performed concurrently and continuously, building a culture that keeps up with changing risk. Identify-P and Govern-P are described as foundational, because you cannot control or communicate what you have not understood or decided to govern.

Profiles

A Profile is the organisation's own selection from the Core, chosen according to its business or mission drivers, its role(s) in the data processing ecosystem, the types of processing it performs and the privacy needs of the people affected. An organisation may also add Functions, Categories or Subcategories that the Core lacks. Profiles come in two forms. The Current Profile describes outcomes achieved today (the "as is" state). The Target Profile describes outcomes needed to meet the organisation's privacy goals (the "to be" state). The gap between them drives the action plan. There is no fixed template: a Profile might be a spreadsheet listing each selected Subcategory with its priority, owner, current status and evidence.

Profiles are flexible in scope. You can write one for the whole organisation, for one product line, for one system or for one role in a supply chain. Industry groups can also publish common Profiles that their members tailor.

Implementation Tiers

The Tiers describe how an organisation views privacy risk and whether it has enough processes and resources to manage it. There are four:

Tier 1 – Partial: privacy risk management is informal and reactive; awareness is limited and practices are ad hoc.
Tier 2 – Risk Informed: management has approved practices, and there is awareness of privacy risk, but it may not be organisation-wide policy.
Tier 3 – Repeatable: practices are formally approved as policy, consistently applied and regularly updated as requirements and risks change.
Tier 4 – Adaptive: the organisation continuously adapts its practices from lessons learned and indicators, and privacy risk is part of its culture and its ecosystem relationships.

Each Tier is described along four aspects: the privacy risk management process, the integrated privacy risk management program (how far privacy risk is built into enterprise risk management), data processing ecosystem relationships (how well the organisation understands its role and dependencies and communicates risk with others) and the workforce (who has privacy responsibilities and what skills they have). An organisation can sit at different Tiers on different aspects.

Figure 4 – The four Implementation Tiers form a progression, but moving up is justified only when current processes and resources are not enough for the organisation's risk.

Two points about Tiers are often misunderstood. First, they are not a compulsory ladder. NIST says that an organisation at Tier 1 will probably benefit from reaching Tier 2, but not every organisation needs Tier 3 or 4, and some only need higher Tiers in certain areas. Second, success with the framework is measured by achieving the outcomes in the Target Profile, not by the Tier number. The Tier is a way to talk about resources and maturity, especially with executives and partners.

Lesson 4 – How it works in practice

Ready, Set, Go

The framework describes a simple three-phase way to establish or improve a privacy programme:

Ready. Use Identify-P and Govern-P to understand the context: the mission, privacy values and policies, legal and contractual obligations, risk tolerance, the data processing and its ecosystem. Begin drafting the Current and Target Profiles by reviewing the Categories and Subcategories of these two Functions, and conduct privacy risk assessments for the systems in scope. Good preparation here makes every later assessment better.
Set. Complete the Current Profile by recording which outcomes of the remaining Functions are achieved, fully or partially. Then complete the Target Profile, informed by the risk assessment results and by the needs of stakeholders such as business customers, partners and the people served. Compare Current and Target Profiles, identify the gaps and create a prioritised action plan with the funding and staff needed. Use this to inform the choice of a target Tier.
Go. Implement the plan: change processes, select and implement controls, adjust designs. Then monitor, update the Current Profile and repeat as risks and the business change.

Figure 5 – The Ready, Set, Go cycle turns risk assessment and profile comparison into an action plan that is revisited as risks change.

This cycle is deliberately similar to the "establish or improve a programme" steps of the Cybersecurity Framework. If your organisation already runs CSF Profiles, you can extend the same spreadsheet or tool with privacy Subcategories rather than starting a parallel effort.

Roles and communication

The framework describes three organisational levels that collaborate in both directions:

Senior executives express mission priorities, risk tolerance, privacy values and budget, and accept or decline risk decisions.
Business and process managers develop Profiles, allocate budget and inform which Tier is appropriate.
Implementation and operations staff implement the Profiles, run privacy risk assessments, select and operate controls and monitor progress.

Information flows down as values, policies and priorities, and back up as privacy posture, changes in risk, implementation progress and incident activity. This two-way flow is how the framework supports accountability: decisions are made by people with the authority to make them, using information from people who understand the systems.

Doing a privacy risk assessment

The framework does not mandate a particular risk method, but NIST publishes a free companion tool, the Privacy Risk Assessment Methodology (PRAM), a set of worksheets that walk a team through the analysis. The general steps are:

Frame the business objectives, the organisation's privacy governance and any legal requirements.
Map the system: data elements, data actions, purposes and flows, and the contextual factors (who the individuals are, what they expect, how sensitive the data is).
For each data action, ask what could go wrong for people. PRAM offers an illustrative catalogue of problematic data actions (for example surveillance, unanticipated revelation or induced disclosure) and of problems (such as dignity loss, discrimination, economic loss or loss of trust).
Estimate how likely each problem is in this context and how severe the impact would be, then combine them to rank the risks.
Choose a response for each significant risk: mitigate it, transfer or share it, avoid it by not doing the data action, or accept it within the organisation's tolerance.
Select controls or design changes and trace each one back to the privacy requirement it satisfies.

Appendix D of the framework lists practices that support this work: organising preparatory resources (roles, risk strategy, stakeholders, organisational privacy requirements, design artefacts, data maps), determining privacy capabilities, defining privacy requirements, conducting the assessments, creating traceability between requirements and controls, and monitoring for changing risks.

Using the framework with laws and other standards

Because the Core does not restate any law, you connect it to your obligations through informative references and crosswalks. NIST hosts a resource repository with crosswalks contributed by NIST and the community that map Subcategories to, among others, NIST SP 800-53 privacy and security controls, ISO/IEC 27701 and several privacy laws. A crosswalk shows, for example, which Subcategories help you meet a particular legal duty such as answering access requests. Crosswalks are aids, not legal advice: you still need a qualified person to interpret the law for your situation.

Other ways to use it

Across the system development life cycle. A Target Profile can be aligned with the plan, design, build, deploy, operate and decommission phases, so privacy requirements are built in from the start (often called privacy by design) and re-checked at deployment and during operation.
In the data processing ecosystem. An organisation that decides how data is used can express its privacy requirements to a service provider using a Profile; the provider can use its own Profile to show what it does. An industry group can publish a common Profile for its members.
To inform buying decisions. Because Profiles produce a prioritised list of outcomes, they can become criteria for choosing products and suppliers, for example favouring a device that lets you delete or de-identify data easily.

Lesson 5 – Assessment, certification and compliance

There is no certification

This point is simple but frequently misunderstood: there is no official certification against the NIST Privacy Framework. NIST does not certify organisations, accredit auditors or publish a register of "compliant" companies, and the framework does not contain a pass mark. In fact the framework itself discourages the idea of "compliance with the Privacy Framework" as a uniform concept that outsiders can rely on, because every organisation chooses its own Profile and can use the framework in different ways. If a vendor claims to be "NIST Privacy Framework certified", ask what that means: at best it describes a private assessment by a consultancy, not a recognised certificate.

How use of the framework is assessed

Even without certification, organisations regularly assess themselves against the framework, and customers or regulators may ask how they use it. Common forms of assessment are:

Self-assessment of the Current Profile. For each selected Subcategory, record whether the outcome is achieved, partially achieved or not achieved, with evidence: a data inventory, a policy, a training record, a deletion procedure, a test result.
Tier assessment. Judge the four Tier aspects separately, using the descriptions in Appendix E, and agree a realistic current and target Tier with leadership.
Internal audit or independent review. Internal audit or an external firm checks whether the evidence supports the claimed Current Profile and whether the action plan is progressing. This produces an assurance report, not a certificate.
Ecosystem assurance. A customer may require a supplier to share its Profile, answer questions mapped to Subcategories or demonstrate specific outcomes in a contract.

Good assessments measure outcomes rather than documents. Having a deletion policy is evidence for a Subcategory only if deletion actually happens when requested and within the promised time. Sampling real requests, inspecting data stores and interviewing staff give a more honest picture than counting policies.

Relation to legal compliance

Using the framework does not, by itself, make an organisation compliant with any privacy law. Laws such as the EU General Data Protection Regulation (GDPR), Brazil's LGPD, India's Digital Personal Data Protection Act or US state privacy laws have their own specific duties, enforced by regulators and courts. What the framework gives you is a structured programme in which those duties are mapped, owned, implemented and monitored. Many organisations use it as the operating model for a multi-jurisdiction privacy programme: one set of outcomes, with crosswalks showing which laws each outcome helps satisfy.

Where formal certification is needed

If a customer or regulator requires a certificate issued by an accredited third party, the usual route is a management system standard such as ISO/IEC 27701, which defines a privacy information management system that accredited certification bodies can audit. The NIST framework and ISO/IEC 27701 are often used together: the framework for risk thinking and communication, the ISO standard for an auditable management system. Lesson 7 compares them.

Lesson 6 – Worked example

This example is fictional but realistic. All scores and figures are illustrative.

The organisation

Pulsewise is a 300-person company that sells a fitness wristband and a companion mobile app. The band records heart rate, sleep and steps; the app adds GPS routes for runs and lets users join community challenges. Data is stored with a public cloud provider, crash reports go to an analytics vendor, and a marketing team wants to share "insights" with sports-brand partners. Pulsewise sells in North America, Europe and India. It already uses the Cybersecurity Framework and holds an ISO/IEC 27001 certificate for its information security management system, but its privacy work consists of a privacy notice, a consent screen and a lawyer who reviews new features "when asked". After a negative press story about fitness apps revealing users' running routes, the board asks the chief privacy officer (CPO) for a proper programme.

Step 1 – Ready: context and governance

The CPO forms a working group with engineering, security, product, legal, customer support and marketing. The executive team states three privacy values: no surprises for users, data minimisation by default, and no sale of personal data. Legal lists the obligations in each market. The board sets a risk tolerance: risks that could reveal a user's home location or health condition to others must be reduced to low; moderate risks to convenience are acceptable if users can opt out. These decisions cover outcomes in Govern-P (policies, roles, legal requirements, risk strategy).

Step 2 – Ready: mapping the data processing

Engineers produce a data map covering the band, app, cloud back end and vendors (Inventory and Mapping, ID.IM-P). It lists data elements (heart rate, sleep stages, GPS points, email, age, weight), data actions (collect, sync, store, analyse, share, delete) and purposes. Surprises appear: GPS routes are kept forever by default, raw crash logs sent to the analytics vendor sometimes contain email addresses, and community challenge leaderboards show the start point of each user's run.

Step 3 – Ready: privacy risk assessment

Using the PRAM worksheets, the group examines each data action and asks what problems could arise for users. Three stand out:

Public run start points could reveal where users live (unanticipated revelation), leading to stalking or burglary. Likelihood high, impact severe.
Sharing "insights" with partners could let partners infer health conditions, and users would not expect it (appropriation, meaning use beyond what people expect, with loss of trust and possible discrimination in offers). Likelihood medium, impact high.
Email addresses in crash logs mean a vendor holds identifiable data it does not need; a breach there would be a cybersecurity-related privacy event. Likelihood low to medium, impact moderate.

Each risk is linked to organisational impacts the board understands: churn after another press story, regulatory fines in Europe and India, and partner contracts that could become liabilities.

Step 4 – Current Profile

The group selects 52 of the 100 Subcategories as relevant for this product and records status and evidence for each. Highlights of the Current Profile:

Protect-P is strong: access control, encryption and maintenance are covered by the existing security programme.
Identify-P is weak: there was no data map before Step 2 and no repeatable privacy risk assessment.
Control-P is weak: users can export data but cannot delete individual routes, and retention limits are not enforced.
Communicate-P is partial: there is a notice, but no in-app explanation of who sees challenge data and no channel for privacy questions other than general support.

The CPO judges the organisation to be at Tier 1 (Partial) for the risk management process and workforce aspects, and Tier 2 (Risk Informed) for the integrated programme aspect because privacy is already on the enterprise risk register.

Step 5 – Set: Target Profile and action plan

The Target Profile raises priority on outcomes that address the assessed risks. Examples of the gaps and the planned actions:

Disassociated Processing (CT.DP-P): blur run start and end points on public views by default; aggregate partner insights so that no individual can be singled out, and drop any insight on groups too small to hide individuals.
Data Processing Management (CT.DM-P): let users delete single routes and their whole history; enforce a 24-month default retention for GPS data with an option to keep longer.
Data Processing Ecosystem Risk Management (ID.DE-P): amend the analytics vendor contract, strip identifiers from crash logs before sending, and require partners to accept the company's privacy requirements.
Data Processing Awareness (CM.AW-P): add a short in-app explanation at the moment a user joins a challenge, and a dedicated privacy contact form.
Monitoring and Review (GV.MT-P): make a privacy risk assessment a required step in the feature launch checklist, and review the risk register every quarter.
Awareness and Training (GV.AT-P): train product managers and engineers on the privacy engineering objectives and how to spot problematic data actions.

The target is Tier 3 (Repeatable) for the risk management process, because the company launches features every month and needs a consistent way to assess them, but Tier 2 is accepted for ecosystem relationships for the first year. Marketing's partner-insights plan is put on hold until aggregation is in place; the executives formally accept that delay as a business trade-off.

Step 6 – Go: implement and monitor

Over two quarters the teams deliver the changes. Security reuses its CSF incident response plan for privacy breaches, adding a step to assess harm to users and to notify them and regulators where required. The CPO maps the Target Profile to the obligations of each market using published crosswalks and legal advice, so the same work answers questions from European and Indian customers. Six months later the group updates the Current Profile: most gaps in Control-P and Identify-P are closed, the vendor no longer receives email addresses, and a new feature (sleep coaching) went through the launch-checklist assessment and was redesigned to process sleep data on the phone instead of the cloud. That redesign is a clear application of disassociability.

What the example shows

Pulsewise did not "implement 100 Subcategories". It used the Core as a menu, chose the outcomes that mattered for its risks, worked on the gaps that reduced real problems for users, and measured progress by updating its Profiles. Security strength did not protect against the biggest risk, which came from a feature that worked exactly as designed.

Lesson 7 – Relationship to other standards and frameworks

The Privacy Framework rarely stands alone. It was designed to be combined with other frameworks, controls catalogues and laws. The table summarises the most common neighbours.

Standard or framework	Owner and type	Main focus	How it relates to the Privacy Framework
NIST Cybersecurity Framework (CSF) 2.0	NIST; voluntary framework (2.0 published 2024)	Managing cybersecurity risk through six Functions: Govern, Identify, Protect, Detect, Respond, Recover	Sister framework with the same Core, Profile and Tier design. Covers the security side of the overlap; its Detect, Respond and Recover Functions handle privacy breaches. The PF 1.1 draft restructures its Core to follow CSF 2.0.
ISO/IEC 27701	ISO and IEC; certifiable management system standard (2025 edition)	Requirements for a privacy information management system (PIMS), with controls for controllers and processors	Provides an auditable management system and a route to accredited certification, which the NIST framework does not offer. Crosswalks map PF Subcategories to it.
NIST SP 800-53 Rev. 5	NIST; catalogue of security and privacy controls	Detailed controls, including privacy controls, for information systems and organisations	A source of concrete controls to achieve PF outcomes; NIST publishes a mapping between the two.
ISO/IEC 29100	ISO and IEC; privacy framework standard (first published 2011)	Common privacy terminology, actors and privacy principles	Supplies principles and vocabulary; the NIST framework supplies a risk-based structure to put principles into practice.
EU GDPR and other privacy laws	Legislators; mandatory law	Legal duties on organisations and rights for individuals, enforced by regulators	Laws set what you must do; the framework organises how you manage the programme and the risks. Crosswalks show which outcomes support which duties.
NIST AI Risk Management Framework	NIST; voluntary framework	Managing risks of AI systems, including privacy as one trustworthiness characteristic	Used together when AI systems process personal data; the PF 1.1 draft adds a section on AI and privacy risk.

Choosing a combination

A practical pattern used by many organisations is: use the Cybersecurity Framework and the Privacy Framework together as the shared language for risk and for talking to executives; draw detailed controls from SP 800-53 or from the ISO/IEC 27001 and 27701 control sets; map everything to applicable laws with crosswalks; and, if customers demand certification, run an ISO/IEC 27701 management system and have it certified. The frameworks do not compete. The NIST framework answers "what privacy outcomes do we need and how mature are we?", while management system standards answer "how do we run, audit and continually improve the system?", and laws answer "what are we obliged to do?".

When you combine the two NIST frameworks, avoid duplicate work. The privacy and security teams can maintain one Profile with both sets of Subcategories, use the CSF for detection and response, and agree who owns the overlap. A breach involving personal data is both a security incident and a privacy event; the plan should say how the harm to individuals will be assessed and who decides on notification.

Common pitfalls and best practices

Pitfalls

Treating privacy as security. Teams with a mature security programme assume they are covered and ignore risks from authorised processing, such as surprising uses, over-collection or inference.
Trying to implement every Subcategory. The Core is a menu, not a checklist. Selecting all 100 outcomes without prioritising wastes effort and hides the important gaps.
Chasing a Tier number. Declaring "we will reach Tier 4" without a risk reason leads to expensive bureaucracy. The Target Profile, not the Tier, is the measure of success.
Claiming certification or compliance. Marketing that says "NIST Privacy Framework certified" is misleading, because no such scheme exists.
Assessing only the organisation, not the individual. Risk assessments that only count fines and reputation miss the problems people experience, which is the framework's central idea.
A one-off project. Building Profiles once for an audit and never updating them leaves the programme blind to new features, vendors and laws.
Forgetting the ecosystem. Ignoring what suppliers, processors and partners do with data leaves some of the largest risks unmanaged.

Best practices

Start with Identify-P and Govern-P. A good data map and clear values, roles and risk tolerance make every later decision easier.
Use a repeatable risk method. Adopt PRAM or a similar method, build it into product launch and change processes, and keep the results in a risk register.
Prioritise by risk to people. Choose Target Profile outcomes that reduce the highest risks for individuals, and link them to organisational impacts to secure budget.
Integrate with the CSF and enterprise risk management. Share Profiles, tooling and incident processes with security, and put privacy risks on the enterprise risk register.
Apply the privacy engineering objectives in design. Ask early whether a design is predictable, manageable and disassociable; local processing, aggregation and fine-grained deletion are often cheaper when planned from the start.
Keep evidence of outcomes. Record how each selected outcome is achieved and test it periodically, so assessments rest on facts rather than documents.
Use Profiles to communicate. Share relevant parts of your Profile with customers and suppliers, and ask suppliers for theirs.
Watch for Version 1.1. Track the final release, review the mapping from 1.0 to 1.1, and plan the update of your Profiles when it is published.

Summary and key takeaways

The NIST Privacy Framework is a voluntary, outcome-based and law-agnostic tool that treats privacy as an enterprise risk; Version 1.0 (2020) is current and Version 1.1 was still a draft on 2026-10-29.
Privacy risk is the likelihood and impact of problems that individuals experience from data processing; it overlaps with security risk but also arises from processing that works as designed.
The framework has three parts: the Core (5 Functions, 18 Categories, 100 Subcategories), Profiles (Current and Target) and four Implementation Tiers.
Identify-P, Govern-P, Control-P and Communicate-P manage privacy risk from data processing; Protect-P covers the security overlap, with the CSF's Detect, Respond and Recover for incidents.
Ready, Set, Go turns context and risk assessment into Profiles, gaps, an action plan and continuous monitoring.
Tiers (Partial, Risk Informed, Repeatable, Adaptive) describe the maturity of privacy risk management across four aspects; higher is not always necessary.
There is no certification against the framework; organisations self-assess or obtain independent reviews, and use ISO/IEC 27701 when accredited certification is needed.
Crosswalks and informative references connect the framework to laws, SP 800-53, ISO standards and other frameworks.

Reflection questions

Think of a system you work on. Name one data action that is fully secure but could still cause a problem for the people whose data it processes. What would make it less surprising to them?
Which three Categories of the Core would you prioritise first in your organisation, and what evidence would you collect to show they are achieved?
Your executives want to announce a target of Tier 4 across the board. How would you respond, and what information would you bring to that discussion?
How would you divide responsibilities between your security team and your privacy team for the overlap between the two frameworks, especially during a breach?
A large customer asks for proof that you "comply with the NIST Privacy Framework". What would you send them, and how would you explain what it does and does not demonstrate?