A security certificate next to a privacy compliance checklist

"Security Certifications != Privacy Compliance: Why Your ISO 27001 Isn't Enough"

I ask this question frequently: "What does your privacy maturity look like?"

The answer I get back, roughly eight times out of ten, is some variation of: "We are good on that front. We have ISO 27001" or "We are SOC 2 compliant." Then there is a pause, as if that settles the matter.

It does not.

Security certifications like ISO 27001 and SOC 2 are genuine achievements. They demonstrate that you have put serious effort into protecting your environment, securing your systems, and implementing controls that keep threats at bay. They are meaningful signals that you take security seriously.

But they do not necessarily mean you are compliant with privacy legislation.

The Fundamental Misunderstanding

There is a persistent misconception in software companies that security and privacy are interchangeable. Tick the boxes on your security framework and you have sorted privacy too. It is an easy assumption to make when both disciplines talk about "protecting data" and "implementing controls."

But security and privacy are fundamentally different.

Security is about the protection of information. Confidentiality, integrity, availability. 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 unauthorised 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 find they focus predominantly on your business controls: policies, access management, incident response procedures. They are looking at whether you have the right guardrails in place at the organisational level.

What they are not doing is diving into your codebase to check whether your application can actually fulfill a data subject access request. They are not validating whether you have implemented privacy by design in your product development. They are not confirming that you have proper consent management workflows or that you are only processing data for the purposes you have disclosed.

Even with SOC 2, which includes a privacy Trust Service Criteria, many companies do not include it in their scope. They complete the security criteria and assume that is sufficient. And even when privacy is included, it may not cover all the nuances of GDPR or CCPA compliance that your specific business model requires.

The Scoping Problem

Here is a gap I see repeatedly: companies with solid ISO 27001 certifications that only cover their corporate IT environment, while their customer-facing SaaS platform, where all the personal data actually lives, is entirely out of scope. Technically compliant with the standard. Not actually protected from a privacy perspective.

This becomes critical when a regulator or privacy commissioner comes looking. They are not going to care that you have a certificate on the wall if the systems processing personal data were not part of what you certified.

Getting It Right

Security is a component of privacy, not the whole picture. You need both, and you need them working in harmony.

Your ISO 27001 or SOC 2 gives you an excellent foundation. It means you have 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, your actual product, the code your developers write every day, needs to be built with privacy in mind, not just secured after the fact.

If you have been assuming your security certification has privacy covered, now is a good time to take a closer look. Walk through your development lifecycle, your data flows, your processing activities, your legal bases. Can you demonstrate compliance with privacy legislation to a regulator or a client if they asked today?

If you are not sure, start with a conversation. This is one of the most common gaps I see, and it is fixable.