After I was asked the same question 3x in one day, and it’s one of the most common questions I get, I opted to make it today’s newsletter topic.

🥁 Drumroll please ….

What privacy framework should we adopt? NIST? ISO?  Another one?

I want to say up front that frameworks are genuinely useful. We created the Privacy☘︎Ops® Framework and use it with clients all the time. They give you a way to organize a mess of information (yes, formal phrase) into something you can actually work with and can be very valuable.

With more security teams owning privacy, or for organizations just getting started where they are used to having a security framework, this is where I think people get tripped up. They are bringing a security mindset into privacy, without realizing the two don’t work the same way.

Security frameworks work because there are very few specific security laws (there are security requirements within specific industries like health or finance). Data Breach laws come into play after an incident. There’s no global patchwork of security laws (at least not yet!).

Privacy is governed by actual laws, and those laws get specific in a way a framework was never built to capture. When someone runs their privacy program the way they’d run a security program, off a framework alone, they end up with great overarching themes and might even have policies and processes in place. All that work likely will not cover the nitty-gritty details required by privacy laws.

People like to organize information, and a framework helps make sense where it’s complex. Since I get asked most about the NIST Privacy Framework, I’ll walk through what NIST covers, how it can be helpful, and why companies still need to actually create an approach to comply with each individual applicable privacy law.

What the NIST Privacy Framework actually is

NIST built this framework to give organizations a common language for thinking about privacy risk. It’s voluntary, it isn’t tied to any one law, and it’s organized around five functions: Identify-P, Govern-P, Control-P, Communicate-P, and Protect-P.

It’s worth knowing, NIST maintains a few of these voluntary frameworks, not just this one. There’s the NIST Cybersecurity Framework, the NIST Privacy Frameworkthat this piece is about, and the newer NIST AI Risk Management Framework for AI-specific risks (and fun fact, I had one of the co-authors of the NIST AI RMF on the podcast recently. Listen here). They’re related in spirit, all voluntary, all organized around similar functions, but each one is its own document with its own scope. It’s easy to blur them together in conversation, so I wanted to link the actual sources here.

Understanding each section

Identify-P is understanding what data you have, where it lives, and what risk comes with processing it. Govern-P is the policies, roles, and accountability that let an organization manage privacy on an ongoing basis, who owns the decisions, and how they get documented.

Control-P is giving people, and the organization itself, the ability to manage data in ways that reduce risk, things like minimization and retention limits.

Communicate-P is transparency, telling people what you’re doing with their data so they can make an informed decision. Protect-P is security, the safeguards against unauthorized access, use, or disclosure.

If you know privacy law, this probably feels familiar, and that’s on purpose. These five functions echo themes that show up across privacy regulation generally. But echoing a theme and meeting a legal requirement are two different things, and I think Identify-P and Govern-P show that gap especially well.

Take Identify-P. Its own definition already covers two different jobs: knowing what data you have, and knowing what risk that data carries. GDPR actually splits those into two separate legal obligations. Article 30 requires records of processing activities (ROPA), documentation of what data you process and why. Article 35 separately requires a Data Protection Impact Assessment, or DPIA, before you start any high-risk processing activities. Different requirements, different purposes, but both are fundamentally about identifying what you have and what it’s exposing you to, which is why I’d put both under Identify-P rather than Govern-P.

If you only relied on NIST, you’d miss knowing what is considered high risk under GDPR or exactly what is required in a ROPA under GDPR. For example, it’s so specific, the French Data Protection Authority, CNIL, has an article and a dedicated ROPA template.

Govern-P is where ownership comes in. Who’s responsible for making sure that the data inventory is done and those risk assessments actually happen, and who has to answer for it if they don’t. GDPR requires many organizations to designate a data protection officer, and that comes with specific job requirements (see here for what the UK ICO says on DPOs).

CCPA’s newer regulations get at the same idea from a different angle. Under CCPA’s risk assessment requirement, a company executive has to personally certify to the California Privacy Protection Agency, under penalty of perjury, that the required assessments were actually completed. PRAs are a different mechanism than NIST and while it’s the same principle underneath – someone with real authority is on the hook, not just a policy that says it should happen. CCPA’s risk assessment is triggered by a specific list of activities: selling or sharing personal information, processing sensitive personal information, or certain automated decision-making uses. And no matter what the assessment finds, CCPA requires an annual report and executive certification to the California Privacy Protection Agency. Those same risk assessments are also particular about what needs to be included. 

While I’m on the topic of risk assessments, it’s worth slowing down here because “risk assessment” isn’t one universal thing, even though it sounds like it should be. A Privacy Impact Assessment, or PIA, is the oldest and broadest term. It started as a US federal agency requirement and has since become general industry practice, not tied to one specific law.

A DPIA is GDPR’s version, triggered by an open, principle-based standard, and it’s focused on processing that’s likely to result in high risk to people’s rights, decided case by case, with no obligation to loop in a regulator unless significant risk remains after mitigation. Several US state laws use the phrase data protection assessment, which resembles a DPIA but comes with its own state-specific triggers.

Definitely an area where companies have to decide which phrase they will use internally to ensure they meet all applicable requirements. FWIW: I’m seeing and trying to personally use CCPA’s privacy risk assessment (PRA). Out of all the names, I also think that one makes the most sense to me.

We know it’s confusing, so check out our guide to all things assessments.

GDPR’s DPIA and CCPA’s risk assessment share a general idea, but the mechanics underneath are genuinely different. Assuming a DPIA process automatically satisfies a CCPA risk assessment, or the other way around, is exactly the kind of gap a framework won’t catch for you.

TLDR: While NIST might say you need risk assessments, it will not specify exactly when each state or jurisdiction says you need to document one.

Where the specifics live

Control-P tells you to give people some ability to manage their data. Good principle. It doesn’t tell you that under CCPA, your opt-out link has to say “Do Not Sell or Share My Personal Information” (OR that you can use Your Privacy Choices with a nifty icon from the California Attorney General Office) using the law’s own wording, placed somewhere a consumer can actually find it.

A framework points you toward the idea of choice. It won’t write the link text, and it won’t tell you where on the page it has to sit. Or the very long list of other specific privacy rights requirements like how many days you have to respond, which rights can and cannot be verified, how to work with an authorized representative, etc.

Sensitive data is the same story. Communicate-P and Control-P will tell you, in general terms, that certain data deserves more care. What they won’t tell you is that the definition of sensitive data changes depending on which law you’re reading. For a great chart on sensitive data (and more), check out the resource center at Stauss Firm.

CCPA has its own list. Other state laws define it a bit differently. GDPR calls it special category data and has its own list again. If you’re operating across jurisdictions, a single internal definition of “sensitive” isn’t going to cover you everywhere. You have to know which law applies to which piece of data.

Consent works the same way. A framework tells you people should have meaningful choices. It won’t tell you when that choice needs to be opt-in versus opt-out. GDPR generally requires opt-in consent before you touch special category data. Several US state laws also require opt-in for sensitive data, and some have a unique concept called strictly necessary.

CCPA is mostly built around opt-out rights for standard personal information, not opt-in. Whether you need permission first or just have to let people say no afterward isn’t a framework decision. It’s a statute decision, and it changes law by law.

And kids’ data might be the clearest example of how granular this gets. COPPA applies to children under 13. CCPA has separate opt-in requirements that kick in under 16.

GDPR lets each EU member state pick its own digital consent age for children, somewhere between 13 and 16, so the same activity can require parental consent in one country but not the one next door.

Several newer US state laws layer on their own age thresholds too. None of that lives in a framework. It lives in the statute text, and it moves depending on where your users are.  

The GDPR and CCPA trap

I hear a version of this a lot, in both directions: “we’re GDPR compliant, so we’re covered in the US,” or “we handled CCPA, so we’re fine for GDPR.” This is usually the point where a company ends up building its own informal framework without meaning to, treating whichever law it tackled first as the template and assuming compliance with that one will carry it over to the rest. Neither direction holds up, and it’s one of the more expensive assumptions I see companies make.

GDPR compliance is a strong foundation, to be fair. It pushes you toward real data mapping, a lawful basis for processing, and actual accountability documentation, and those habits carry over well. But GDPR compliance on its own doesn’t give you a CCPA compliant opt-out mechanism, doesn’t give you the specific disclosures California requires in a privacy policy, and doesn’t touch the rest of the US state law patchwork, each with its own thresholds and its own rights process. Just to name a few.

Going the other way, CCPA compliance doesn’t get you to GDPR either. CCPA runs on a notice and opt-out model for most personal information. GDPR starts from a different place entirely and asks for things CCPA doesn’t. We’ve addressed some, like a formalized ROPA, a legal basis, and a formal data protection officer. If your program was built for California, assuming it covers you in Europe is going to leave real gaps. And if you comply with one state, it may, but not always, cover you for another state. How you manage sensitive data for CCPA will not cover you for states like Connecticut, Colorado, Virginia, or Maryland (and again just examples).

How to actually use a framework well

None of this means frameworks aren’t worth using. I still think NIST’s structure is useful, especially early on, when you’re trying to figure out where to start and how to talk about privacy risk with people outside the privacy team. The mistake isn’t using the framework. It’s stopping there.

Use it to organize the program, not to define your obligations. Build a matrix of the laws that apply to you. Start with where your customers, prospects, and employees are located, since that tells you which laws are in play. Then map the long list of specifics, such as opt-in versus opt-out, sensitive data definitions, age thresholds, disclosure requirements, response timelines, etc. This is the layer a framework can’t do for you.

Train your team on the difference between the two. This is the part I see skipped most. Someone reads a summary of the framework and assumes it tells them what’s legally required. It doesn’t, and that’s not a knock on them, it’s just not what the framework was built to do. The people making day-to-day decisions about data need to recognize when a question has moved from general best practice to a specific legal requirement, and know when to ask for help (and who to ask!).

I get why people want one framework to be the whole answer. It would make all of this a lot simpler. But privacy law is still a patchwork party, and it’s only going to get more complicated.  The risk lives in the details of that patchwork, not in the principles sitting above it.

A framework gets you organized. The law gets you compliant. Companies need both.

This is how we assess maturity and compliance when we conduct a Privacy Program Assessment. We also use the same framework to manage privacy programs for companies.

We don’t start with NIST and treat it as the finish line. We line NIST’s structure up alongside the specific state privacy law requirements that actually apply to that business, so the client gets the best of both: a framework to organize the program and the legal specifics that tell you what actually has to be true inside it.

Compliance starts with knowing which laws apply to you and what each one requires. Once that’s mapped, aligning it to a framework is the easy part. If you want help with either, hit reply and let’s chat.

Jodi

💡 When you’re ready, here’s how we can help:

⚙ Privacy Advisory & Implementation: We help companies navigate privacy requirements with confidence. Our advisory support covers strategy, operations, and real-world implementation.

⚙ Fractional Privacy Services: We provide fractional privacy leadership tailored to your needs and pace. From program development to day-to-day support, we help you build and sustain a strong privacy program.