Security Certifications != Privacy Compliance: Why Your ISO 27001 Isn't Enough
I ask this question frequently: "What's your privacy maturity looking like?"
The answer I get back, say eight times out of ten, is some variation of: "Oh, we're good on that front. We've got ISO 27001" or "We're SOC 2 compliant." And then there's a pause, as if that settles the matter entirely.
Here's the rub: it doesn't.
Don't get me wrong. Security certifications like ISO 27001 and reports like SOC2 are fantastic achievements. They demonstrate that you've put serious effort into protecting your environment, securing your systems, and implementing controls that keep the bad actors at bay. They're badges of honor that show your clients you take security seriously (hopefully; dodgy SOC2’s are a topic for another time).
But here's what they don't do: they don't necessarily mean you're compliant with privacy legislation.
The Fundamental Misunderstanding
There's a persistent misconception in software companies that security and privacy are interchangeable. That if you've ticked the boxes on your security framework, you've automatically sorted out privacy too. It's an easy assumption to make, especially when both disciplines talk about "protecting data" and "implementing controls."
But security and privacy, while related, are fundamentally different beasts.
Security is about the protection of information. It's about keeping it confidential, maintaining its integrity, and ensuring it's available when you need it. It's the locks on the doors, the firewalls on the network, the encryption on the databases. It answers the question: "Are we keeping this data safe from unauthorized access?"
Privacy, on the other hand, is about the rights of individuals and the lawfulness of how you use their data. It answers entirely different questions: "Are we actually allowed to have this data? Are we using it for the purposes we said we would? Can we demonstrate lawful basis? Can we fulfill data subject rights requests?"
Where Security Certifications Fall Short
When you dig into what most security certifications actually cover, you'll find they're predominantly focused on your business controls. This means your policies, your access management, your incident response procedures. They're looking at whether you've got the right guardrails in place at the organizational level.
What they're not doing is diving down into your codebase to check whether your application can actually fulfill a data subject access request. They're not validating whether you've implemented privacy by design in your product development. They're not confirming that you have proper consent management workflows or that you're only processing data for the purposes you've disclosed.
Even with SOC 2, which has a privacy Trust Service Criteria, many companies don't actually include it in their scope. They'll complete the security criteria and assume that's sufficient. And even when privacy is included, it still may not cover all the nuances of, say, GDPR or CCPA compliance that your business model requires.
The Scoping Problem
Here's another gotcha: the way you've scoped your certification might exclude the very areas where privacy matters most.
I've seen companies with beautiful ISO 27001 certifications that only cover their corporate IT environment, but their customer-facing SaaS platform, where all the personal data actually lives, is entirely out of scope. Technically compliant with the standard? Sure. Actually protected from a privacy perspective? Not so much.
This scoping issue becomes critical when a regulator or privacy commissioner comes knocking. They're not going to care that you have a certificate on the wall if the systems processing personal data weren't part of what you certified.
Getting It Right
The reality is this: security is a component of privacy, but it's not the whole picture. You need both, and you need them working in harmony.
Your ISO 27001 or SOC2 gives you an excellent foundation. It means you've got mature processes for protecting data. But you still need to layer on the privacy-specific requirements: lawful basis documentation, privacy notices, consent management, data subject rights fulfillment, privacy impact assessments, vendor due diligence from a data protection perspective, and so on.
And critically, you need to ensure that your actual product (the code your developers write every day and the SDLC that they follow) is built with privacy in mind, not just secured after the fact.
Take Stock of Where You Stand
If you've been assuming that your security certification has privacy covered, now's the time to take a closer look. Walk through your development lifecycle, data flows, your processing activities, your legal bases. Can you demonstrate compliance with privacy legislation to a regulator or even a client if they asked today?
If you're not sure, or if the answer is "probably not," you're not alone. This is one of the most common gaps I see, and it's fixable.
Want to understand where your privacy gaps in dev might be? I've put together a free privacy maturity assessment that walks through your development lifecycle and identifies where you might be exposed. Take the assessment, and I'll follow up with a complimentary consultation to talk through your specific situation and what practical steps you can take. No pressure, no sales pitch. Just a genuine conversation about getting your privacy house in order.
Start the assessment via my website, or if you'd prefer, I'm always happy to come speak to your team about bridging the gap between security and privacy in your development practices.