ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
The NIST Privacy Framework is a voluntary tool for managing the privacy risks that arise when an organisation processes data about people. It is free, it is published by the US National Institute of Standards and Technology, and it is built to sit alongside a security programme rather than inside any single privacy law.
That last point is what most introductions get wrong. This is not a compliance checklist for GDPR or for a US state statute. It is a risk model — and the risks it surfaces are ones your security programme is structurally unable to find.
It has three components, and a toolkit or article that only covers the first is describing about a third of it.
| Component | What it does | Unit |
|---|---|---|
| Core | A set of privacy outcomes, grouped so they can be discussed across an organisation | Functions → Categories → Subcategories |
| Profiles | Which outcomes you achieve today (Current) and which you need (Target) | A selection of Subcategories |
| Implementation Tiers | How rigorously privacy risk is managed, from Partial to Adaptive | The programme as a whole |
The Core has five Functions: Identify-P, Govern-P, Control-P, Communicate-P and Protect-P. If those look familiar, that is deliberate — the framework was modelled on the NIST Cybersecurity Framework, so an organisation already running CSF meets a structure it recognises.
Here is the sentence worth reading twice: a privacy problem can arise from data processing that is authorised, accurate and perfectly secure.
No attacker. No vulnerability. No breach. No failed control. Consider an organisation that keeps purchase history for six years when its stated purpose expires after twelve months, or one that infers a health condition from shopping patterns and uses it to target offers, or one that makes an automated decision a person cannot challenge.
Run a security review over any of those and it returns no finding. The access was authorised. The data was encrypted. Every control operated exactly as designed. The problem is the processing itself — and that is the territory the NIST Privacy Framework exists to cover.
This is why an information security management system is not a privacy programme. The two overlap on breaches, and only on breaches.
That distinction is worth understanding properly before you assess anything — see privacy risk vs cybersecurity risk for the three regions and what falls in each.
| Region | Example | Who finds it |
|---|---|---|
| Security only | Ransomware on a system holding no data about people | Security programme |
| Overlap | A breach exposing customer records | Both |
| Privacy only | Over-retention, undisclosed inference, purpose drift, a default nobody would choose | Only a privacy programme |
The third row is the whole argument. If your privacy risk register contains nothing but breach scenarios, it was produced by a threat-modelling exercise wearing privacy vocabulary, and the risks in that row remain unmanaged.
The Functions are the top level of the Core. Each answers a different question, and the split is where the framework earns its keep, because the five are not equally served by an existing security programme.
| Function | The question it answers | Typical gap |
|---|---|---|
| Identify-P | What data do we process, on whom, for what purpose, and what could go wrong for them? | Systems that only infer are left out of the inventory |
| Govern-P | Who is accountable, what is our appetite, how do we oversee it? | Resourcing is asserted rather than derived from committed work |
| Control-P | Can we actually manage data — reach it, correct it, delete it, disassociate it? | Deletion works on the primary store and not the warehouse or backups |
| Communicate-P | Do the people affected know what happens to their data? | Notices describe practices but never the associated risks |
| Protect-P | Are the safeguards in place? | Usually the strongest, because an existing security programme already covers much of it |
Note the shape of that last column. Protect-P overlaps heavily with an existing security programme, so it is usually the least new work. Control-P overlaps least: manageability — the ability to administer one person’s data across every store it reached — is a capability that has no security equivalent, so nothing in a security programme builds it. That asymmetry is the single most useful thing the NIST Privacy Framework surfaces.
Communicate-P deserves a mention too. It asks for purposes, practices and associated privacy risks to be communicated. The third element is the one to check your own notice against: a notice can describe what you do in full detail and still say nothing about what could go wrong for the reader.
This is the part competitors selling privacy packs tend not to mention. NIST Privacy Framework 1.1 is an Initial Public Draft. It was published on 14 April 2025 as NIST CSWP 40 ipd and the comment period closed on 13 June 2025. NIST has not announced a publication date for the final.
Version 1.0, published 16 January 2020, remains the only final version.
Three consequences follow, and none of them is a reason to avoid the draft:
Version 1.1 has five Functions, 20 Categories and 102 active Subcategories. Version 1.0 had five Functions, 18 Categories and 100 Subcategories.
If you open the draft and text-search for identifiers you will count 138, which is easy to misread. That figure is 102 active, plus 34 retired 1.0 identifiers carried only as “Moved to” pointers, plus two withdrawn — ID.RA-P2, which related to artificial intelligence systems, and CM.AW-P8. The number of outcomes you actually implement is 102.
The order matters, and the most consequential decision is where you start.
Do not start at Protect-P. It is the Function that most resembles an existing security programme, which makes it the most tempting entry point and the least useful one. Start there and you end up with a security programme wearing privacy labels.
Each of those steps has its own detail: building the data map, identifying problematic data actions, and then recording where you stand in a Current and Target Profile. The rigour with which you run all of it is characterised separately by the Implementation Tiers.
It is voluntary. Implementing it does not by itself satisfy GDPR, CCPA/CPRA, HIPAA or any statute. What it gives you is the operating model those obligations are managed through.
That composition is the framework’s design intent. It deliberately avoids the vocabulary of any one regime — it speaks of data actions and problematic data actions rather than controllers, processors and data subjects — which is what lets one programme serve several jurisdictions at once. Track the obligations themselves separately, and keep the distinction visible: a regulator enforces the law, not the framework.
If you need a certifiable management system instead, ISO/IEC 27701 is the standard to look at. We compare the two directly in NIST Privacy Framework vs ISO 27701, and set the framework against the law in NIST Privacy Framework vs GDPR. If your driver is a specific statute, start with the GDPR principles or CCPA compliance and use the framework underneath.
It is free. Download it from nist.gov/privacy-framework. There is no paywall and no licence to buy, which is unusual in this field and worth taking advantage of before you buy anything at all.
No. It is a voluntary risk management tool. No law requires it and no regulator enforces it. Organisations adopt it because it gives them a defensible way to identify and prioritise privacy risk, not because they are obliged to.
No. No certification scheme exists, in version 1.0 or 1.1. Any vendor implying otherwise is describing something that does not exist. You can be assessed against it internally or by a third party, and you can state that your programme is aligned to it.
Version 1.0 is the only final version, so it is the safe citation. Version 1.1 is aligned with CSF 2.0 and is where the framework is going. Many organisations build to 1.1 while citing 1.0 as the published baseline — the risk being that NIST may renumber identifiers before the final is published.
The inventory and data map dominate the timeline. Everything downstream depends on knowing what is processed, so the assessment work cannot start until that is done, and it is the part that scales with the size of your estate rather than with the framework. Plan the map first and treat the Current Profile as the milestone that follows it.
The framework tells you which outcomes to achieve. It does not give you the policies, procedures, registers and profile workbooks that evidence them — that is the work.
Our NIST Privacy Framework Toolkit is 145 editable Word and Excel templates covering all 102 Subcategories of version 1.1, including Current and Target Profile workbooks, an Implementation Tier assessment, a transition guide for the 34 identifiers that moved from 1.0, and crosswalks to CSF 2.0, SP 800-53, ISO/IEC 27701, GDPR and US state law.
September 3, 2026
September 3, 2026
September 3, 2026
September 3, 2026
September 3, 2026