In March 2025, the California Privacy Protection Agency fined American Honda Motor Co. $632,500. Honda is not a company without a privacy program. It had policies, a rights-request process, a consent banner, and vendors. What it got fined for were specifics no framework document on earth would have flagged: requiring consumers to submit more verification data than the law permits for opt-out requests, presenting a cookie banner where “accept all” took one click but declining took more, and failing to produce contracts with ad tech vendors containing the required contractual terms. Sephora before it paid $1.2 million largely because its website ignored the Global Privacy Control signal. Every one of those failures lives at a level of granularity that sits far below the altitude at which privacy frameworks operate.
This matters because “which privacy framework should we adopt — NIST, ISO, something else?” remains one of the most common questions privacy and security leaders ask, and it is usually asked with the wrong expectation attached. The expectation is that the framework, once adopted, defines what the organization must do. It doesn’t. It never will. And organizations that run privacy the way they run security — pick a framework, implement the controls, pass the audit, done — are building programs that look mature in a board deck and fail on the exact details regulators and plaintiff firms actually test.
This piece takes the question seriously, compares the real options, and then reframes it into the question that actually determines whether you end up compliant. The short version: a privacy program has three layers — an organizing framework, a legal obligations register, and operational proof — and the framework is the only one of the three you get to choose. The other two are chosen for you, by legislatures and by your own data flows.
Why the Security Playbook Fails in Privacy
It is worth being precise about why importing a security mindset into privacy goes wrong, because the instinct is completely rational and the failure is structural, not a matter of effort.
Security frameworks like ISO 27001 or the NIST Cybersecurity Framework can function as near-complete operating systems for a security program because security law is sparse and outcome-based. Outside of sector regimes like HIPAA, GLBA, PCI DSS, and NYDFS Part 500, most security obligations are variations of “maintain reasonable safeguards,” enforced after an incident. When the legal standard is “reasonable,” the framework becomes the standard — implementing a recognized control baseline is both the program and the defense. Security frameworks converge because the law leaves a vacuum for them to fill.
Privacy is the inverse. It is one of the most statute-dense areas in commercial law, and the statutes legislate at the interface level: the literal text of a hyperlink, the number of days you have to respond to a request, the age at which parental consent kicks in, the specific clauses that must appear in a vendor contract, which executive signs an attestation and to whom it is submitted. There is no vacuum for a framework to fill. The specifics already exist — around twenty US state comprehensive laws, GDPR and its national implementations, ePrivacy, sectoral statutes, and a court system busy inventing new theories under wiretapping and consumer protection laws — and they conflict with each other in ways no single control set can harmonize. A framework can organize this landscape. It cannot substitute for it.
One clean illustration: every major framework contains a principle about honoring individual choice. None of them tells you that California requires an opt-out link reading “Do Not Sell or Share My Personal Information” in the law’s own words (or the alternative “Your Privacy Choices” link with the official icon), that the choice must be honored via GPC without the consumer asking, that opt-out requests cannot be subjected to the verification you would apply to a deletion request, and that a banner making refusal harder than acceptance is itself a violation. Honda’s penalty was built out of exactly those clauses. “Honor individual choice” was never the hard part.
The Three-Layer Model of a Privacy Program
Instead of asking “which framework,” structure the program as three distinct layers with three distinct jobs:
- Layer one: the organizing framework. A common vocabulary and structure for the program — how you categorize activities, communicate risk to leadership, benchmark maturity, and divide ownership. This is where NIST, ISO 27701, and their peers live. It is genuinely valuable and genuinely optional.
- Layer two: the obligations register. A living inventory of every specific legal requirement that applies to your organization, derived from where your customers, users, and employees are located and what your data flows actually do. This layer is not optional and cannot be adopted off a shelf, because it is unique to your footprint.
- Layer three: operational proof. The evidence that layer two is actually true on your properties and in your systems on any given day — scan results, consent records, request logs, contract inventories, assessment documentation. This is the layer enforcement actions and lawsuits are actually decided on.
Most framework-first programs build layer one thoroughly, gesture at layer two, and discover layer three exists when a regulator’s screenshot or a plaintiff’s forensic capture shows their website doing something their policy says it doesn’t. The rest of this article works through each layer, starting with an honest comparison of the frameworks themselves.
Layer One: What Each Framework Actually Gives You
The NIST Privacy Framework
NIST’s Privacy Framework is voluntary, law-agnostic, and organized into five functions: Identify-P (know your data and its processing risk), Govern-P (policies, roles, and accountability), Control-P (data management capabilities like minimization and retention), Communicate-P (transparency and disclosure), and Protect-P (safeguards against unauthorized access). NIST has been updating it — the 1.1 revision effort realigns it with Cybersecurity Framework 2.0 and addresses AI-related privacy risk, reflecting that most organizations now run it alongside the CSF and, increasingly, the NIST AI Risk Management Framework. Keep those three straight: they are siblings with similar shapes, but separate documents with separate scopes.
Where it shines: cross-functional communication, program structure for organizations starting from zero, and mapping privacy work into an enterprise risk language that boards and security teams already speak. It also comes with crosswalks mapping its subcategories to laws like GDPR — useful scaffolding, though a crosswalk tells you a requirement exists somewhere in the neighborhood, not what satisfying it takes.
Where it stops: NIST is not certifiable, prescribes no specific artifacts, and by design contains no jurisdiction-specific requirements. Identify-P tells you to understand your processing and its risk. It does not tell you that GDPR splits that single idea into two separate legal deliverables — the Article 30 record of processing activities, specific enough that France’s CNIL publishes a dedicated ROPA template, and the Article 35 DPIA, triggered before high-risk processing begins with “high risk” defined through regulatory guidance and case-by-case analysis. An organization can satisfy Identify-P in spirit and still walk into an audit with neither artifact in defensible shape.
ISO/IEC 27701
ISO 27701 is the privacy information management standard in the ISO family, originally built as an extension bolted onto ISO 27001, and restructured in its recent revision to stand more fully on its own as a certifiable privacy management system standard. Its differentiators are auditability and commercial signaling: it is the framework you adopt when procurement teams, enterprise customers, and international partners want a certificate. It also maps controller and processor obligations separately, which is more operationally honest than most frameworks manage.
The trap is certification theater. An ISO 27701 certificate attests that your privacy management system exists and operates as documented. It does not attest that your cookie banner is lawful in California, that your sensitive-data handling meets Maryland’s minimization standard, or that your DSAR responses hit statutory deadlines. Companies holding clean certificates get sued and fined on those specifics regularly, and no regulator in any jurisdiction accepts a certificate as a compliance defense. Treat 27701 as a management-system discipline and a sales asset, never as a legal conclusion.
SOC 2 privacy criteria and the rest
SOC 2’s privacy trust services criteria matter mainly because customers demand the report; as a program backbone they are the thinnest of the options, oriented around commitments you yourself made in your notices rather than around external law. Older scaffolding like GAPP and the fair information practice principles survive inside these newer frameworks as DNA rather than as things anyone should adopt directly today. And many mature organizations end up doing what serious advisory shops do: building an internal hybrid that uses NIST’s function structure as the skeleton and hangs jurisdiction-specific requirements off it. That instinct is correct — it is essentially the three-layer model built by hand.
Choosing among them
The honest selection logic is short. If your driver is internal organization and risk communication, use NIST’s structure — it is free, familiar to security teams, and flexible. If your driver is external attestation and enterprise sales, pursue ISO 27701, knowing you are buying a management-system certificate rather than legal coverage. If customers demand SOC 2, produce it, but do not mistake it for a program. In every case, the framework decision is a two-week decision. The obligations register underneath it is the two-year discipline, and it is the same register no matter which framework you picked — which is precisely the point.
Where Every Framework Runs Out: Five Gaps With Real Consequences
1. The documentation artifacts are law-specific, down to the template
“Conduct risk assessments” is a framework sentence. The legal reality is a family of superficially similar, mechanically different obligations. The privacy impact assessment is the oldest and loosest term, born in US federal agency practice. GDPR’s DPIA is triggered by a principle-based high-risk standard, decided case by case, with regulator consultation required only when significant risk survives mitigation. Most US state laws require “data protection assessments” with their own trigger lists. And California’s regulations created the privacy risk assessment with the most concrete mechanics anywhere: enumerated triggers including selling or sharing personal information, processing sensitive personal information, and certain automated decision-making uses; prescribed content; and — the detail that should focus executive attention — a certification submitted to the California Privacy Protection Agency, signed by a company executive under penalty of perjury, on a recurring schedule with initial submission deadlines now on the calendar. A DPIA process does not automatically satisfy a California PRA, and a PRA does not satisfy a DPIA. Assuming interchangeability is exactly the gap a framework will never catch, because from the framework’s altitude they all look like the same box being checked.
2. The interface-level mandates
Statutes now legislate user-interface details: exact link text, GPC recognition, symmetry between accept and decline paths, response windows (45 days under CCPA with a defined extension; one month under GDPR), appeal mechanisms that several states require with their own notice requirements, rules about which rights requests may be verified and how, and authorized-agent handling. This is the layer where Sephora and Honda lost, where dark-pattern theories are litigated, and where automated compliance scans generate findings. No framework subcategory reaches it.
3. Sensitive data is defined differently everywhere you operate
Frameworks say heightened care for sensitive data; statutes disagree about what sensitive data is and what heightened care means. GDPR’s special categories, CCPA’s sensitive personal information list, and the varying state definitions overlap without matching — precise geolocation, immigration status, union membership, and biometric identifiers move in and out of scope depending on the statute. Then the treatment diverges harder than the definitions: Virginia, Colorado, and Connecticut require opt-in consent before processing sensitive data; California runs a right-to-limit model; Maryland’s MODPA bans the sale of sensitive data outright and imposes a data-minimization standard strict enough to prohibit collection beyond what is reasonably necessary for the requested service; Washington’s My Health My Data Act wraps consumer health data in a consent-and-authorization regime with a private right of action attached. A single internal definition of “sensitive,” applied uniformly, guarantees you are over-compliant somewhere and violating the law somewhere else.
4. Consent architecture is a statute decision, not a design decision
Opt-in versus opt-out is decided law by law: GDPR requires prior consent for special category data and, via ePrivacy, for non-essential cookies; CCPA is opt-out for most personal information but opt-in for sensitive processing limits in specific contexts and for minors; states diverge on strictly-necessary carve-outs. Children’s data is the sharpest example of granularity no framework captures — COPPA at under 13, CCPA’s opt-in requirements running to under 16 with parental consent under 13, GDPR letting each member state set its digital consent age anywhere from 13 to 16 so the same feature needs parental consent in one EU country and not its neighbor, and newer state laws layering additional thresholds and duties of care on top. That is not a principle. That is a lookup table, and it changes several times a year.
5. Frameworks are static; the patchwork is not
A framework revision cycle runs on years. The legal landscape moves quarterly: new state laws taking effect in waves, CPPA rulemaking packages, CNIL and EDPB guidance, court decisions expanding CIPA and wiretapping theories to technologies nobody contemplated when the framework was drafted. A program whose obligations are defined by a framework document inherits the framework’s update cadence. A program whose obligations are defined by a maintained legal register inherits the law’s.
The Reciprocity Trap
The framework mindset produces one more expensive assumption worth naming: treating the first law you complied with as a de facto framework for all the others. It runs in both directions. “We’re GDPR compliant, so the US is covered” fails because GDPR compliance, for all its rigor in data mapping, lawful basis, and accountability documentation, produces neither a compliant California opt-out mechanism, nor the state-specific privacy policy disclosures, nor GPC handling, nor the state-by-state patchwork of rights procedures. “We handled CCPA, so GDPR is fine” fails harder, because CCPA’s notice-and-opt-out chassis simply lacks GDPR’s load-bearing structures — legal basis analysis, ROPAs, DPIAs, DPO designation where required, transfer mechanisms. And the same trap now operates state-to-state: a sensitive-data approach built for California’s right-to-limit model does not satisfy Connecticut’s opt-in requirement or Maryland’s sale prohibition. Compliance does not transfer. Only the underlying program discipline does.
Layer Two: Building the Obligations Register
The obligations register is the deliverable that actually determines compliance, and it is buildable in a defined sequence:
- Establish jurisdictional scope from people, not offices. Where your customers, users, prospects, and employees are located determines which laws apply — including extraterritorial regimes like GDPR that follow the data subject, and applicability thresholds in state laws that turn on volume and revenue.
- Inventory processing activities against each law’s trigger vocabulary. Whether an activity is a “sale,” a “share,” “targeted advertising,” “profiling,” or “high-risk processing” differs by statute, and the classification drives the obligations. The same ad tech integration can be a sale in one state, sharing in another, and joint controllership under GDPR.
- Extract requirements at the level of testable specifics. Not “provide opt-out rights” but “opt-out link with statutory text in the footer, GPC honored, no verification demanded, effect within 15 business days, and downstream notification to third parties.” Every register entry should be phrased so a scan, an audit, or a screenshot can prove it true or false.
- Map each requirement to a framework function and an owner. This is where NIST’s structure earns its keep — as the filing system for legal specifics and the assignment of accountability, including the named executive who will be signing California certifications under penalty of perjury.
- Resolve conflicts deliberately. Decide, requirement by requirement, where you will run a highest-common-denominator standard globally and where jurisdiction-specific behavior is worth the operational complexity. Consent flows and sensitive data are usually where a single global standard breaks.
- Attach the artifact list. ROPAs, DPIAs, state data protection assessments, California PRAs and their certification calendar, vendor contract clauses, retention schedules — each with its trigger, its content requirements, and its refresh cycle.
- Version it against legal change. Assign ownership for monitoring new laws, regulations, guidance, and litigation theories, with a defined path from “the law changed” to “the register changed” to “the website changed.”
- Train the escalation reflex. The most common operational failure is a team member treating a framework summary as the legal requirement. People making daily data decisions need to recognize the moment a question crosses from best practice into statutory specifics, and know exactly who to pull in when it does.
Layer Three: Proof, or Why Programs Fail on Paper They Never Wrote
The final layer is the one enforcement actually runs on. Regulators and plaintiff firms do not audit your framework maturity; they capture what your website did on a particular date — which cookies fired before consent, whether GPC changed anything, what the banner’s decline path looked like, how long a deletion request took — and compare it against your published representations. Every gap between the two is simultaneously a statutory violation and, as covered elsewhere on this blog, raw material for UCL and CLRA claims about misrepresented practices. Layer three is therefore continuous by nature: tag managers change weekly, marketing adds pixels without tickets, vendors update SDKs, and a program verified last quarter is a program unverified today. The operational answer is standing infrastructure — continuous scanning of actual tracker behavior, consent records that hold up as evidence, request logs with timestamps against statutory clocks, and a privacy policy that updates when reality does rather than when someone remembers.
Frequently Asked Questions
Should we adopt the NIST Privacy Framework or ISO 27701?
Choose based on the driver: NIST for internal program structure and risk communication, ISO 27701 when customers or partners require a certifiable attestation. Either way, the framework only organizes the program — your legal obligations come from the specific privacy laws that apply to your data footprint, and those must be mapped separately.
Does ISO 27701 certification mean we are GDPR or CCPA compliant?
No. Certification attests that your privacy management system operates as documented. It is not a legal compliance determination, no regulator accepts it as one, and certified companies are regularly fined for jurisdiction-specific failures like unlawful cookie banners, GPC non-compliance, and missed request deadlines.
Is a GDPR DPIA the same as a California privacy risk assessment?
No. They share a purpose but differ in triggers, required content, and mechanics. California’s regulations enumerate specific triggering activities and require recurring certification to the California Privacy Protection Agency signed by an executive under penalty of perjury — obligations a DPIA process does not satisfy on its own.
If we comply with GDPR, are we covered for US state privacy laws?
No, in either direction. GDPR compliance builds strong foundations but does not produce CCPA-compliant opt-out mechanisms, state-specific disclosures, or GPC handling; CCPA compliance lacks GDPR’s lawful basis, ROPA, DPIA, and DPO requirements. Compliance with one state law also does not guarantee compliance with another.
What should come first, the framework or the legal analysis?
The legal analysis. Determine which laws apply based on where your customers, users, and employees are, extract each law’s specific requirements into an obligations register, then use a framework to organize ownership and structure around those requirements. A framework gets you organized; the law is what gets you compliant.
The Layer No Framework Can Give You
Frameworks organize. Laws obligate. Evidence decides. Captain Compliance is built for the two layers you cannot adopt from a PDF: our platform maps the specific consent, disclosure, and opt-out requirements of each jurisdiction your visitors come from, enforces them through an IAB TCF-validated consent management platform with automatic GPC handling, keeps your privacy policy dynamically synchronized with the trackers actually running on your site, and continuously monitors your properties so the evidence layer is maintained every day instead of assembled in a panic after a regulator’s letter arrives. Adopt whichever framework fits your organization — then book a demo with Captain Compliance to see what the statutes underneath it actually require of your website. We work with privacy consultancies across the world that use our software to automate your legal privacy requirements.