In January 2025, Meta was fined €1.2 billion by Ireland’s Data Protection Commission for transferring European user data to the United States without adequate safeguards. The systems holding that data were not breached. No attacker stole it. No vulnerability was exploited. Meta’s security, by any technical measure, did its job. The company was punished anyway — because security wasn’t the question. Privacy was.
This distinction collapses constantly in boardrooms, vendor pitches, and breach disclosures. Companies announce “we take your privacy and security seriously” as if the two are interchangeable departments under one umbrella. They aren’t. Treating them as the same thing is why organizations keep getting compliance wrong even when their controls are technically sound, and why users keep getting harmed even when nothing was technically broken.
The categorical difference
Privacy is a claim about what may happen to information about a person — what gets collected, by whom, for what purpose, and under whose control. It is normative. It exists whether or not anyone tries to violate it.
Security is the set of mechanisms — technical, procedural, physical — that defend a system against unauthorized access, modification, or disruption. It is operational. It exists in response to threats.
The European Data Protection Supervisor draws this line cleanly: in EU law, privacy and data protection are increasingly treated as separate concerns, with data protection focused on the usage, storage, and movement of data while privacy preserves the older notion of private and public life. American practice tends to fuse them under the term “privacy,” which obscures the underlying split.
The categorical difference matters because the two failure modes are different. A security failure means someone got in who shouldn’t have. A privacy failure means the right people did exactly what they intended — and that itself was the harm.
How the conflation actually plays out
Three patterns recur. The first is the encryption-as-privacy claim. Vendors point to encryption at rest and in transit as evidence of privacy protection. Encryption defends against unauthorized parties reading data in transit or in storage. It says nothing about whether the authorized parties — the company itself, its processors, its advertising partners, its acquirers — should have the data in the first place. A perfectly encrypted dataset that was collected without lawful basis is still a privacy violation under GDPR.
The second pattern is the breach-disclosure substitution. When companies talk publicly about privacy, they usually mean breach response: notification timelines, identity monitoring offers, post-incident audits. GDPR requires breach notification to supervisory authorities within 72 hours, and that obligation has trained organizations to treat privacy as something that activates after a security failure. But most privacy obligations operate before any incident — at the point of collection, at the moment of processing, at the choice of legal basis.
The third pattern is the compliance-equals-protection assumption. SOC 2, ISO 27001, and similar frameworks certify security control posture. They are not privacy attestations. An organization can pass every security audit while violating data subject rights, retaining data past lawful periods, or sharing it with parties outside its disclosed processor list. The certifications are real and useful — they just answer a different question.
When good security still produces privacy harm
The Meta transfer fine is the clean case: working systems, lawful security posture, multi-billion-euro consequence for a privacy-law violation. There are messier ones.
In April 2025, Hertz disclosed a breach affecting over a million customers across its Hertz, Dollar, and Thrifty brands, stemming from zero-day vulnerabilities in Cleo’s file transfer platform exploited by the Clop ransomware gang. Hertz’s network was not directly compromised. The exposed data — names, dates of birth, driver’s licenses, credit card details, in some cases Social Security numbers and passports — sat with a third-party processor. From a security standpoint, this was someone else’s incident. From a privacy standpoint, Hertz remained the controller, and the affected individuals had a relationship with Hertz, not Cleo. The privacy obligations did not transfer with the data.
Then there is the inverse failure: privacy without security. First American Financial paid a $1 million penalty after a website vulnerability allowed unauthorized access to a vast database without any password or authentication — by simply changing a single digit in a URL, anyone could access a different customer’s documents. The company likely had a published privacy policy. It had legal bases for collection. Its disclosed processing was probably lawful. None of that mattered, because the practice underneath the policy did not exist.
Privacy without security is a promise the organization can’t keep. Security without privacy is a fortress around data the organization shouldn’t have collected, retained, or shared the way it did. Both fail the user. They fail differently.
Why the conflation persists
Part of the reason is structural. Inside organizations, privacy and security usually sit under the same executive — often the CISO, sometimes a Chief Privacy Officer who reports through the security org. Budget, headcount, and tooling get bundled. The CISO’s metrics tend to dominate because they are quantifiable: mean time to detect, patch latency, phishing-test pass rate. Privacy metrics — purpose limitation adherence, data minimization, consent quality — are harder to count and rarely make the dashboard.
Part is regulatory framing. GDPR’s lower-tier violations — including failures in record-keeping, inadequate security measures, and processor agreement violations — can result in fines up to €10 million or 2% of annual global turnover, while upper-tier violations covering breaches of data processing principles, unlawful data transfers, and violation of data subject rights can reach €20 million or 4%. The upper tier targets privacy principles, not security failures. The structural message is that the regulator considers a lawful-basis violation more serious than a control gap. Most companies still optimize as if it were the other way around.
Part is vendor incentive. Security tooling sells more easily than privacy tooling. A SIEM produces alerts; a data inventory produces a spreadsheet. Boards fund what looks like action.
What the distinction asks of practitioners
For security teams, the practical implication is narrow: stay in your lane on framing. Encryption is encryption. MFA is MFA. Calling these “privacy controls” outside a specific compliance mapping confuses the people you’re reporting to and overstates what the controls do.
For privacy teams, the implication is harder. Most of the work happens before any system gets built — at data-collection design, at lawful-basis selection, at vendor selection, at retention policy. By the time a security incident occurs, the privacy decisions that mattered most have already been made.
For everyone else, the test is simpler. When a company tells you it takes your privacy seriously, ask what data it collects that it doesn’t strictly need, who it shares that data with, and how long it keeps it. The answers describe the privacy posture. The answers about firewalls, encryption, and MFA describe something else.
The two are both worth caring about. They are not the same thing. Pretending they are is how organizations end up with billion-euro fines on systems that were never breached, and breached systems whose privacy promises were vacuous to begin with.
