NIST Privacy Framework Profiles: Building Current and Target

Three streams, merged. Legal obligations: counsel maintains the register of applicable regimes (state comprehensive laws, sectoral statutes, GDPR-family exposure, FTC expectations), and each obligation maps to Core outcomes, deletion rights select the Control-P data-management outcomes; notice duties select Communicate-P transparency outcomes; vendor obligations select the ecosystem risk-management categories. Published crosswalks (NIST's and third parties') accelerate this mapping, but validate them against your reading of each law, crosswalks generalize and your obligations are specific. Risk assessment: run the privacy risk analysis (PRAM or equivalent) over your processing inventory; problematic data actions the legal register never mentions, re-identification potential in analytics, inference harms, aggregation effects, select additional outcomes, and this stream is what keeps the Profile ahead of enforcement rather than trailing it. Business context: contractual privacy commitments to enterprise customers, public promises in your privacy notice (the FTC's favorite hook), industry codes, and deliberate brand positioning select the rest. Merge rule: an outcome selected by any stream enters the Target; annotate each selected outcome with its drivers, because when budgets tighten, outcomes with three drivers defend themselves and outcomes with one weak driver get honestly deferred. The Target that results is yours, defensibly derived, not the whole Core: selecting everything is the same as prioritizing nothing.

Score achievement per selected outcome on an evidence standard, and write the evidence pointer into the Profile. A workable scale: not achieved (nothing operates), partially achieved (operates for some systems, populations, or data flows, note which), largely achieved (operates across scope with known exceptions), achieved (operates, evidenced, and someone would bet their audit on it). The interrogation technique per outcome is always the same three questions: show me it operating (the artifact: logs, tickets, records, screens), show me its coverage (which systems and flows, because 'we do deletion' usually means 'the main database'), show me its last failure and what happened (processes with no known failures are processes nobody monitors). Structural honesty aids: have the outcome's operator, not its manager, answer; sample real cases (pull three deletion requests, trace them); and separate 'policy exists' from every achievement level, policy existence is a prerequisite for nothing operating in a documented way. The predictable soft spots where scores inflate: preference and opt-out propagation to downstream systems and vendors, deletion reaching backups and analytics copies, inventory currency (the map says twelve systems; procurement onboarded four more), and vendor-ecosystem outcomes generally. A Current Profile that scores everything green is not a good program; it is a bad assessment, and the difference becomes public at incident time.

Convert each gap (Target outcome minus Current achievement) into a work item with four attributes: risk reduced (from the risk assessment's harm analysis, plus legal exposure from the obligation drivers), effort class (weeks, quarter, multi-quarter, engineering versus process versus paper), dependencies (inventory completeness gates almost everything; tooling gates preference propagation; vendor paper gates ecosystem outcomes), and owner. Then sequence by risk-reduction-per-effort with dependency ordering, which in practice produces a familiar shape: inventory and data-mapping work first (it gates the rest and is chronically underestimated), high-legal-exposure rights machinery second (deletion, access, opt-out propagation, the items enforcement actions actually cite), transparency and notice alignment third (cheap, high FTC relevance, notices must match the machinery just built), ecosystem and vendor outcomes fourth (long timelines you do not control, start the paper early even though it completes late), and the risk-selected outcomes without current legal drivers slotted where capacity allows, with their rationale documented for the budget conversation. Two disciplines keep it alive: every completed item updates the Current Profile score with its new evidence pointer (the roadmap and the Profile are the same document in two views), and every deferral is written down with its risk acceptance owner, deferred-by-decision survives scrutiny; deferred-by-drift does not.

They are siblings solving the same problem, scoped selection from a catalog, and should share plumbing without merging. Against the ISO 27701 statement of applicability: the SoA selects controls for a certifiable management system; the Privacy Framework Target selects outcomes for a risk-managed program; the mapping between them (via published ISO-NIST crosswalks) lets one implementation evidence both, so build the crosswalk register with columns for both references and one evidence pointer, the 'one control, many reporters' architecture. Differences to respect: the SoA's exclusions need auditor-facing justifications; Profile non-selections need only internal rationale, so the Profile can be the more honest document and often should be built first, with the SoA derived for the certifiable subset. Against CSF Profiles: where the organization runs CSF 2.0 Profiles for security, align the shared protective outcomes (Protect-P mirrors CSF protective categories) so one implementation and one score serves both, and run the two Profile refresh cycles on the same calendar with a joint session for the overlap. Against the legal obligation register: the register is upstream input (it selects Target outcomes) and downstream consumer (its per-law compliance reporting extracts from Profile evidence); keep the mapping bidirectional so when a law changes, you can query which outcomes and which evidence it touches, and when an outcome fails, you can query which laws feel it. The anti-pattern across all three: maintaining them in separate tools by separate teams with no keys between them, which guarantees the contradiction one of your assessors eventually finds.

Two rhythms. Calendar: an annual full refresh, re-validate the obligation register with counsel, re-run the risk assessment over the updated processing inventory, re-score every selected outcome against current evidence, and re-sequence the remaining gap; budget it as a real exercise (weeks, not a meeting), because each input has drifted in a year. Quarterly light-touch: Profile health check in the governance rhythm, new work items completed (score updates), evidence spot checks on two or three outcomes, and a scan of the trigger list. Event triggers for off-cycle updates: a new applicable law or a material amendment (new state statute, new FTC rule, an adequacy or transfer development for international flows), selects or modifies Target outcomes; new processing (product launches, M&A, new analytics or AI capabilities, new vendor categories), extends the inventory and risk assessment, and M&A especially resets Current scores for the acquired scope; incidents and near-misses, an incident is empirical evidence about Current achievement (the deletion process that failed was not 'achieved'), so route post-incident findings into Profile scores mechanically; and framework-version changes (the 1.1 update's realignment with CSF 2.0) which re-key the taxonomy your Profiles reference, a mapping exercise rather than a re-assessment, but one to schedule deliberately. The failure mode is staleness with false precision: a beautifully formatted Profile describing the company as it was two product launches ago. Version-stamp Profiles, show refresh dates on the first page, and treat an 18-month-old Profile as presumptively wrong.