NIST Privacy Framework Guide: Core, Profiles, and Tiers

Three components with distinct jobs. The Core is a taxonomy of privacy outcomes, not requirements: five functions (Identify-P, Govern-P, Control-P, Communicate-P, Protect-P) decompose into categories (e.g., Data Processing Ecosystem Risk Management) and then subcategories, discrete outcome statements like 'data elements can be accessed for deletion.' Nothing in the Core says you must achieve any outcome; it gives a common vocabulary for describing what a privacy program could do. Profiles do the selecting: a Current Profile records which outcomes you achieve today and how well; a Target Profile selects the outcomes your legal obligations, risk assessment, and business context require; the gap between them is, quite literally, the program roadmap, and Profile construction is where the framework earns its keep. Implementation Tiers (1 Partial, 2 Risk Informed, 3 Repeatable, 4 Adaptive) describe how the organization manages privacy risk, ad hoc versus institutionalized versus continuously improving, informing how ambitious the Target Profile should be; they are explicitly not maturity grades to chase, Tier 4 everywhere is rarely the right answer. Working method: inventory processing (Identify-P outcomes), assess privacy risk, build the Target Profile from legal-plus-risk drivers, score the Current Profile honestly, and run the gap as a prioritized backlog with owners, revisiting Profiles as processing, law, and incidents teach you things.

The framework's central analytical move: privacy risk arises from data processing itself, not only from unauthorized access. Its model runs: data actions (collection, retention, logging, analysis, disclosure) can become problematic data actions when they cause problems for individuals, dignity losses, discrimination, economic harm, loss of autonomy, physical safety, even when every actor is authorized and no control failed. A perfectly secured analytics pipeline that re-identifies users, a lawful disclosure that enables stalking, an accurate inference that embarrasses: security risk zero, privacy risk real. Consequences for method: the risk assessment must model likelihood that a data action is problematic and the resulting impact on individuals (NIST's Privacy Risk Assessment Methodology, PRAM, operationalizes this with worksheets), and organizational impact follows from individual impact via regulatory, litigation, and trust channels. This is why Protect-P (safeguards against unauthorized access) is only one of five functions: Control-P governs authorized processing (minimization, disassociated processing, deletion capability), and Communicate-P governs whether individuals understand and can act on what is happening. Security teams inheriting privacy work systematically under-invest in exactly those two functions, because their risk model has no category for harm through authorized behavior, which is precisely the gap the framework was designed to close.

Deliberately, they were built to interlock. The overlap is explicit: Protect-P largely mirrors CSF protective outcomes, and the frameworks share the Profile-and-Tier machinery, so an organization running CSF-based security can bolt privacy on without new governance mechanics. The division of labor: CSF manages risks from cybersecurity incidents (loss of confidentiality, integrity, availability); the Privacy Framework manages risks from data processing; breaches of personal data sit in the intersection, where both apply. Operationally: one risk-governance structure, two typed risk registers (or one register with typed entries), shared context and inventory work (the system and asset inventories CSF requires seed the data-processing inventory Identify-P requires), and joint Profiles for the overlapping protective outcomes. CSF 2.0's 2024 restructuring, adding a Govern function and reorganizing categories, created drift against the Privacy Framework's 1.0 structure, which is what NIST's Privacy Framework 1.1 update work (drafted 2025) addresses: realignment with CSF 2.0's structure plus attention to AI-driven processing. Sequencing advice unchanged by versions: organizations with working CSF programs should implement the Privacy Framework through the same offices and rhythms, and organizations with neither should stand both up together, the joint implementation costs little more than either alone, and the seams (breach response, data inventories, vendor management) are where separate implementations leak.

It is architecture, not compliance, by design and explicitly: NIST frameworks are law-agnostic so they can organize compliance with any regime. The mechanism is the Target Profile: each law you face contributes outcome selections, CCPA's deletion and opt-out rights select the Control-P deletion and Communicate-P preference outcomes; GDPR's Articles 25 and 30 select data-inventory and privacy-by-design outcomes; state biometric or health laws select their slices, and NIST plus third parties publish crosswalks mapping subcategories to specific statutes and to ISO 27701 clauses. What the framework contributes that statutes do not: coherence (fifteen laws' obligations deduplicate into one outcome set, implemented once, evidenced once), risk coverage beyond legal minima (problematic data actions that no current statute reaches but that produce tomorrow's FTC consent decree), and a defensibility narrative, in FTC and state-AG matters, documented adoption of a recognized framework supports the 'reasonable data practices' position, the same role NIST frameworks play in security enforcement. What it cannot contribute: the legal determinations (is this a sale under CCPA, which lawful basis applies), deadlines, and jurisdictional analysis, counsel's column remains. The efficient pattern: privacy-legal maintains the obligation register by law; the framework's Profile translates the register into program outcomes; engineering and operations implement to the Profile; evidence flows back against both views.

A four-quarter arc, typically. Quarter one, foundations: constitute governance (a privacy lead with cross-functional authority, Govern-P outcomes), build the data-processing inventory (systems, data categories, purposes, flows, third parties, Identify-P), and pick the legal obligation set with counsel. The inventory is the long pole and the highest-value artifact; scans, questionnaires, and pipeline reviews all feed it. Quarter two, risk and Profiles: run PRAM or an equivalent privacy risk assessment over the inventory's riskiest processing; construct the Target Profile from legal obligations plus risk findings; score the Current Profile honestly (the same maturity trap as ISO gap work applies, 'documented' is not 'operating'); publish the gap as a costed backlog. Quarters three and four, build and operationalize: close the gaps in priority order, deletion capability and preference handling are the usual expensive items, wire evidence generation into operations, and stand up the review rhythm (quarterly Profile health, annual Profile refresh, event-driven updates on new processing, new laws, incidents). Tier ambitions: most organizations rationally target Tier 3 (Repeatable) for the outcomes their laws require and Tier 2 elsewhere; Tier 4 is for outcomes where the business differentiates on privacy. Common failure: treating the framework as a documentation exercise, the binder ships, nothing operates. The counter-discipline is the same as everywhere in this field: every Profile outcome claimed 'achieved' names the artifact that proves it.