Organisations that adopt both the NIST Cybersecurity Framework (CSF) 2.0 and the NIST Privacy Framework usually end up maintaining two Profiles, two evidence sets and two owners for the same access control and data security outcomes, while the privacy risks that have nothing to do with a breach go unowned. The two frameworks share a structure on purpose, and NIST describes them as tools that can be used together, but it leaves the mechanics to you. This guide covers those mechanics: where the frameworks overlap and where they do not, how to crosswalk subcategories, how to build one combined Profile, and how to split ownership between the CISO and the DPO or privacy lead. It assumes you know each framework already; for the frameworks themselves, read the NIST CSF 2.0 Guide and the NIST Privacy Framework 1.1 Guide.
Key takeaways
- Overlap is real but partial. NIST states that managing cybersecurity risk contributes to managing privacy risk but is not sufficient: the shared zone is cybersecurity-related privacy events, and everything else in privacy is out of CSF's reach.
- Protect-P is the seam. The Privacy Framework lets you drop Protect-P and use all six CSF 2.0 Functions alongside Identify-P, Govern-P, Control-P and Communicate-P, which removes most duplication.
- Crosswalks are mostly yours to build. As of November 2026 NIST's crosswalk repository lists crosswalks for Privacy Framework 1.0, and version 1.1 is still an Initial Public Draft, so a CSF 2.0 to Privacy Framework 1.1 mapping is something you maintain.
- One Profile, two lenses. A combined Profile records each outcome once, tags it as cybersecurity, privacy or both, and scores it against both risk appetites.
- Ownership follows risk type, not Function. Security owns outcomes that protect data from unauthorised access; privacy owns outcomes about whether the organisation should process the data at all, and how.
Short answer: how the two frameworks differ
CSF 2.0 itself describes cybersecurity and privacy as independent disciplines whose objectives overlap in certain circumstances, and says the two frameworks can be used together. The table summarises the difference that matters for running them side by side.
| Dimension | NIST CSF 2.0 | NIST Privacy Framework |
|---|---|---|
| Risk it manages | Cybersecurity risk to the organisation: loss of confidentiality, integrity and availability | Privacy risk to individuals from data processing, including risk unrelated to any security incident |
| Who is harmed | Primarily the organisation and its mission | Primarily individuals, with organisational impact as a consequence |
| Adverse event | Cybersecurity incident | Privacy event: the occurrence or potential occurrence of problematic data actions |
| Functions | Govern, Identify, Protect, Detect, Respond, Recover | Identify-P, Govern-P, Control-P, Communicate-P, Protect-P |
| Objectives | Confidentiality, integrity, availability | Predictability, manageability, disassociability, plus the security objectives through Protect-P |
| Current version (checked 14 November 2026) | 2.0, final, February 2024 | 1.0 final (January 2020); 1.1 Initial Public Draft (CSWP 40, 14 April 2025), final listed as "coming soon" |
| Profiles and Tiers | Organisational and Community Profiles; Tiers 1 to 4 | Current and Target Profiles, Community Profiles; Tiers 1 to 4 with the same names |
| Typical owner | CISO | DPO, chief privacy officer or privacy counsel |
The practical consequence: if you adopt only CSF 2.0, you cover the breach side of privacy and miss the processing side (purpose, minimisation, transparency, individuals' rights). If you adopt only the Privacy Framework with Protect-P, you get a thinner treatment of detection, response and recovery than CSF provides.
Where the risks overlap and where they do not
The Privacy Framework 1.1 draft illustrates the relationship as two overlapping areas, with cybersecurity-related privacy events in the overlap. A useful working test is to ask what caused the harm.
| Scenario | Cybersecurity risk | Privacy risk | Primary framework |
|---|---|---|---|
| Attacker exfiltrates a customer database | Yes | Yes (cybersecurity-related privacy event) | Both: CSF for response, Privacy Framework for impact on individuals |
| Ransomware encrypts HR records, no exfiltration | Yes | Yes, through loss of availability of personal data | CSF leads; privacy assesses impact on individuals |
| Marketing reuses support transcripts to train a model without notice | No | Yes | Privacy Framework (Control-P, Communicate-P) |
| Analytics links pseudonymous IDs back to named users | No | Yes (loss of disassociability) | Privacy Framework (CT.DP-P) |
| Retention schedule not enforced, years of call recordings kept | Indirect, larger breach impact | Yes | Privacy Framework, with security enforcing deletion |
| Source code repository leaked, no personal data | Yes | No | CSF |
| Security monitoring captures employee browsing in detail | Control is security | Yes, the control itself creates privacy risk | Both: security designs, privacy sets limits |
The last row is the one programmes most often miss: security controls are themselves data processing. Logging, endpoint telemetry, insider risk tooling and identity analytics all process personal data, and CSF gives no outcome for limiting that. See the Privacy in Security Logging and Monitoring Guide.
Crosswalk mechanics
What NIST provides
NIST's Privacy Framework resource repository lists a Cybersecurity Framework crosswalk and a combined Privacy Framework and Cybersecurity Framework to SP 800-53 Rev. 5 crosswalk. The repository page is titled for Privacy Framework 1.0 crosswalks, and as of November 2026 it lists no crosswalk between CSF 2.0 and the 1.1 draft. Inside the 1.1 draft itself, NIST marks each Category and Subcategory that is identical to the Cybersecurity Framework or adapted from it. That marking is the starting point for your own crosswalk. The National Online Informative References (OLIR) Program, described in NIST IR 8278 Rev. 1, provides the wider infrastructure for mapping documents to NIST frameworks and a Derived Relationship Mapping tool that relates documents through a common focal document.
How to build your own
- Pick the focal document. Use CSF 2.0 as the focal point if security already runs a CSF Profile; privacy subcategories then map to it or stand alone.
- Classify each Privacy Framework subcategory: identical to a CSF 2.0 subcategory, adapted from one, or privacy-only. Use the 1.1 draft's markings, then confirm by comparing texts.
- Record the relationship type for adapted pairs: equivalent, privacy narrower, privacy broader, or intersecting. Note the wording difference that causes it.
- Attach control mappings once. Map each outcome to SP 800-53 Rev. 5 controls (security and privacy controls share one catalogue) or to ISO/IEC 27001 and 27701 controls, so evidence is collected once.
- Version it. Record the Privacy Framework version each row refers to. When 1.1 is finalised, re-run the comparison because the draft's identifiers and wording can change.
Representative pairs
The pairs below compare the 1.1 draft text with CSF 2.0. They are an illustration of the method, not an official NIST crosswalk.
| Privacy Framework 1.1 draft | CSF 2.0 | Relationship | Note |
|---|---|---|---|
| PR.AA-P1 identities and credentials for authorised individuals, services and hardware | PR.AA-01 identities and credentials for authorised users, services and hardware | Equivalent | Wording adapted; covers service accounts and devices in both |
| PR.AA-P5 access permissions defined in policy, least privilege and separation of duties | PR.AA-05 | Equivalent | Same outcome text |
| PR.DS-P1, PR.DS-P2, PR.DS-P9 data at rest, in transit, in use | PR.DS-01, PR.DS-02, PR.DS-10 | Equivalent | Note the numbering differs for data in use |
| PR.DS-P10 backups | PR.DS-11 backups | Equivalent | Numbering differs |
| PR.PS-P1, PR.PS-P2 configuration and software maintenance | PR.PS-01, PR.PS-02 | Equivalent | Evidence fully shared |
| PR.IR-P1 networks protected from unauthorised logical access | PR.IR-01 | Equivalent | Evidence fully shared |
| GV.RR-P1 leadership accountable for privacy risk | GV.RR-01 leadership accountable for cybersecurity risk | Intersecting | Same structure, different risk; often the same board committee |
| GV.RM-P6 consistent method to calculate and rank privacy risks | GV.RM-06 standardised method for cybersecurity risks | Intersecting | Opportunity for one enterprise risk scale with two impact lenses |
| GV.DE-P2 contracts with ecosystem parties support privacy objectives | GV.SC-05 supply chain requirements in contracts | Intersecting | One contract schedule can carry both sets of clauses |
| ID.RA-P3 potential problematic data actions identified | None | Privacy-only | Risk to individuals; no CSF equivalent |
| CT.DP-P and CM.AW-P (disassociated processing, data processing awareness) | None | Privacy-only | Owned by privacy and engineering |
| None | DE.CM and RS categories (continuous monitoring, incident management) | Security-only in the combined model | Privacy consumes outputs for breach impact assessment |
Combined Profile mechanics
Neither framework prescribes a Profile template; the Privacy Framework draft says so explicitly and adds that there is no required order for developing Profiles. That freedom is what makes one combined Profile possible.
Structure
- Rows: all six CSF 2.0 Functions plus Identify-P, Govern-P, Control-P and Communicate-P, with Protect-P dropped. This is the option the Privacy Framework draft describes for organisations using CSF 2.0.
- Risk lens column: each row tagged cybersecurity, privacy or both. Rows tagged both are the identical and adapted pairs from your crosswalk.
- Current and Target columns: one Current state per row; where a row is tagged both, the Target is the stricter of the two requirements.
- Driver column: the legal, contractual or risk reason for each Target, so privacy obligations (for example a statutory duty to assess high-risk processing) are traceable.
- Owner and contributor columns: one accountable owner per row, with contributors named.
- Evidence column: one link to the evidence store, shared by both programmes.
Scoring
Use one scale for achievement (for example not achieved, partial, achieved) for every row, so rows tagged both are not scored twice with different results. Keep separate risk appetites: a gap in PR.DS-01 may be tolerable for internal telemetry under the security appetite and unacceptable for health data under the privacy appetite. Score the gap once and record both risk ratings.
Tiers
Both frameworks use the same four Tier names: Partial, Risk Informed, Repeatable and Adaptive. Assess them separately. A security programme at Repeatable with a privacy programme at Partial is common, and averaging them hides the gap. The Privacy Framework draft lists the degree to which privacy risk is integrated into enterprise risk management as one factor in selecting a Tier, which is a useful board question in its own right.
For the CSF side of the template, see the CSF 2.0 Organisational Profiles Template and the NIST CSF 2.0 Profiles and Tiers Guide.
Ownership: CISO and DPO
The Privacy Framework draft notes that different parts of the workforce may take responsibility for different Categories or Subcategories, and encourages cross-organisation collaboration on Profiles. SP 800-53 Rev. 5 reflects the same split with two leadership controls: PM-2 Information Security Program Leadership Role and PM-19 Privacy Program Leadership Role. The table is a starting RACI for the combined model (A accountable, R responsible, C consulted).
| Area | CISO | DPO or privacy lead | Others |
|---|---|---|---|
| CSF Govern: cybersecurity strategy, supply chain (GV.SC) | A | C | Procurement R for contracts |
| Govern-P: privacy policies, legal obligations, privacy roles | C | A | Legal R |
| Enterprise risk method (GV.RM-06 with GV.RM-P6) | A jointly | A jointly | Enterprise risk R |
| Identify-P inventory and mapping of data actions | C | A | System owners R |
| CSF Identify: asset and data inventories (ID.AM-07) | A | C | IT R |
| CSF Protect (replacing Protect-P) | A | C | IT and engineering R |
| Control-P: retention, rights, disassociated processing | C | A | Engineering R |
| Communicate-P: notices and transparency | I | A | Communications R |
| CSF Detect and Respond | A | C for personal data incidents | SOC R |
| Breach notification decision | C | A | Legal R |
Two design rules stop this RACI from failing. First, do not let one person be accountable for both a control and the review of its privacy impact; the Privacy Framework draft recommends managing conflicts of interest where one person holds several roles. Second, give privacy a formal veto, or at least an escalation route, over security monitoring that processes personal data. For the role distinction itself, see DPO vs CPO.
Decision criteria
| Situation | Recommended model | Why |
|---|---|---|
| CSF 2.0 Profile exists, privacy programme starting | Combined: six CSF Functions plus ID-P, GV-P, CT-P, CM-P | Reuses security evidence, adds only privacy-only outcomes |
| Privacy programme mature, no CSF programme | Privacy Framework with Protect-P | Self-contained; add CSF later if security matures |
| Separate security and privacy functions that report to different executives | Two Profiles with a maintained crosswalk | Keeps clear accountability; crosswalk prevents duplicate evidence |
| Small organisation, one person covers both | Combined, scoped to high-risk data domains | One spreadsheet is realistic; two is not |
| Regulated sector with a published Community Profile | Start from the Community Profile, add privacy-only rows | Inherits sector baseline |
| Formal attestation due before Privacy Framework 1.1 is final | Assess against 1.0; design against the 1.1 draft | The draft's identifiers may change |
Worked scenario: a new customer analytics platform
A retailer plans a platform that joins loyalty card data, web behaviour and store purchases. Security already runs a CSF 2.0 Profile.
- Shared rows: PR.AA-01 and PR.AA-05 for analyst and service account access, PR.DS-01 and PR.DS-02 for encryption. The CISO owns them; the existing evidence process covers them.
- Privacy-only rows: the DPO's team runs ID.RA-P3 to identify problematic data actions (re-identification of pseudonymous web visitors, inferring sensitive attributes from purchases), and sets CT.DP-P targets for disassociation and CM.AW-P targets for notices.
- Intersecting rows: the analytics vendor contract carries both GV.SC-05 security clauses and GV.DE-P2 privacy clauses in one schedule.
- Conflict: security wants full event logging on the platform; privacy wants logs minimised. The combined Profile records one logging outcome with both drivers, and the agreed design pseudonymises user identifiers in logs while keeping administrator actions in full.
- Result: one Profile with 14 rows changed, not two Profiles with 30, and a single evidence pack for audit.
Where identity fits
Identity outcomes sit squarely in the shared zone: PR.AA-P1 and PR.AA-01 both cover services and hardware, not just people, so service accounts, API keys and AI agents that touch personal data are in scope of both frameworks. In a combined Profile, add a privacy lens to identity rows: record which non-human identity performs each data action mapped under Identify-P, so the access review for that identity also tests purpose limitation. Identity logs are themselves personal data and need a retention rule. See the Data Mapping and ROPA Guide.
Detection and measurement
- Duplicate evidence rate: evidence items requested twice for rows tagged both. Target zero after the first combined cycle.
- Privacy-only coverage: percentage of privacy-only Target outcomes with an owner and a Current score.
- Security control privacy review: percentage of new monitoring or telemetry controls with a recorded privacy review before go-live.
- Crosswalk currency: date of last crosswalk review against the latest NIST publication status; review when Privacy Framework 1.1 is finalised.
- Joint incident assessments: percentage of security incidents involving personal data where privacy completed an impact assessment within the agreed window.
Framework mapping
| Need | NIST SP 800-53 Rev. 5 | CSF 2.0 | Other |
|---|---|---|---|
| Leadership roles for both programmes | PM-2 Information Security Program Leadership Role; PM-19 Privacy Program Leadership Role | GV.RR-01, GV.RR-02 | Privacy Framework GV.RR-P |
| Joint risk method | PM-9 Risk Management Strategy | GV.RM-06 | Privacy Framework GV.RM-P6 |
| Privacy programme and assessment | PM-18 Privacy Program Plan; RA-8 Privacy Impact Assessments | GV.OC-03 legal requirements including privacy | ISO/IEC 27701 privacy information management |
| Processing authority and purpose | PT-2; PT-3 | None | Privacy Framework Control-P |
| Engineering for both | SA-8 Security and Privacy Engineering Principles | PR.PS | Privacy Framework objectives table |
| Incident response with privacy | IR-8 Incident Response Plan | RS.CO-02 | Breach notification rules in applicable law |
For the ISO side of a combined programme, see the NIST CSF to ISO 27001 Mapping Guide and the ISO/IEC 27701 Privacy Information Management Guide.
Common failure patterns
- Treating privacy as a subset of security: the programme maps CSF to GDPR security clauses and declares privacy covered, leaving purpose, minimisation and rights unowned.
- Keeping Protect-P and CSF Protect side by side: the same encryption and access evidence is collected twice by two teams with different scores.
- Building on draft identifiers without versioning: a crosswalk keyed to 1.1 draft numbers breaks when the final renumbers; record the version on every row.
- Averaging Tiers: a single combined Tier hides an immature privacy programme behind a mature security one.
- No privacy review of security tooling: monitoring and insider risk tools go live without limits on what they collect about staff.
- One owner for everything: a CISO accountable for privacy outcomes, or a DPO accountable for encryption, with no one checking the other's work.
Practitioner checklist
- Confirm the current status of Privacy Framework 1.1 on NIST's site before each review cycle.
- Choose the model: combined, Privacy Framework with Protect-P, or two Profiles with a crosswalk.
- Build a versioned crosswalk classifying every Privacy Framework subcategory as identical, adapted or privacy-only.
- Map each outcome once to SP 800-53 Rev. 5 or ISO controls and share one evidence store.
- Tag each Profile row cybersecurity, privacy or both, with a driver and one accountable owner.
- Agree one enterprise risk method with separate cybersecurity and privacy impact lenses.
- Assess Tiers separately for each programme and report both.
- Require a privacy review for new security monitoring and telemetry.
- Rebase the crosswalk and Profile when Privacy Framework 1.1 is published as final.
Standards and references
- NIST: The NIST Cybersecurity Framework (CSF) 2.0 (CSWP 29)
- NIST: Privacy Framework 1.1 Initial Public Draft (CSWP 40)
- NIST: Privacy Framework Version 1.1 project page
- NIST: Privacy Framework crosswalks repository
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: National Online Informative References (OLIR) Program
Related NHI Mgmt Group resources: Privacy Programme Guide for Security Teams · NIST CSF 2.0 Govern Function Guide · DPIA Guide: Running a Data Protection Impact Assessment · Privacy Programme Metrics