Security of Processing Is Not Privacy Engineering

“We meet GDPR Article 32 and our SOC 2 is clean, so the personal data is handled properly.”

Hold that sentence up to the light.

It answers one question and claims to have answered four.

Security of processing is not privacy engineering.

Security of processing asks whether the data is protected.

Privacy engineering asks whether the processing should happen at all, for whom the consent actually holds, and what the data is being used for now.

Those are different questions.

They fail in different places.

And the documented privacy failures, the famous ones, happened in systems whose security worked exactly as designed.

Look at what the security frameworks actually specify.

Article 32 of the EU GDPR is titled security of processing, and it means it.

Paragraph 1 requires “appropriate technical and organisational measures”, calibrated to the state of the art, the costs of implementation and the nature, scope, context and purposes of processing.

It names four categories of measure.

Pseudonymisation and encryption.

Ongoing confidentiality, integrity, availability and resilience of processing systems.

The ability to restore availability and access in a timely manner after a physical or technical incident.

A process for regularly testing, assessing and evaluating whether those measures work.

Paragraph 2 names the risks the assessment must account for: accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data.

That is a security article.

A good one.

It does not ask whether you needed the field.

The US HIPAA Security Rule, at 45 CFR Part 164, Subpart C, is built from administrative, physical and technical safeguards, with encryption of ePHI at rest and in transit as the central technical expectation.

SOC 2 has exactly one mandatory category, and it is called Security.

Three frameworks.

All three are about protecting the data you hold.

None of them is a test of whether you should hold it.

1. “But the Data Is Encrypted at Rest and in Transit.”

Good.

That is Article 32(1)(a), one of four categories.

It is not even the whole of Article 32, let alone the whole of the regulation.

Encryption answers a precise question: can someone who obtains the storage or the wire read the contents?

Now look at how the documented privacy failures actually happened.

In 2006 Netflix released 100,480,507 movie ratings from 480,189 subscribers across 17,770 films for its Prize competition, with subscriber identities replaced by numeric IDs.

Arvind Narayanan and Vitaly Shmatikov, then at the University of Texas at Austin, re-identified individual subscribers by matching ratings and approximate dates against public IMDb reviews the same people had posted under their real names.

Nobody broke into Netflix.

The dataset was released deliberately.

The second dataset was public.

Encryption at rest would have protected that data perfectly, right up to the moment the company chose to publish it.

The failure was the decision, not the storage.

Target’s pregnancy-prediction score is the same point from another angle.

Its statistical team took ordinary purchase data, roughly 25 products including unscented lotion, calcium and magnesium supplements, scent-free soap and large quantities of cotton balls, and estimated both pregnancy and an approximate due date.

Then it routed maternity coupons to customers who had never told Target they were pregnant.

In one case Forbes reported in 2012, a father in a Minneapolis suburb confronted a store manager over maternity coupons mailed to his teenage daughter, then called back days later to apologize.

She was pregnant.

The purchase data was collected for retail operations and loyalty tracking.

No attacker.

No exposure.

No law necessarily broken, and no fine.

Whether that data sat in an encrypted column makes no difference at all to what the inference did.

2. “But Our SOC 2 Report Covers Our Controls.”

It covers the controls in the categories your report covers.

Read which ones.

A SOC 2 report is built against the AICPA’s Trust Services Criteria, organized into five categories: Security, Availability, Processing Integrity, Confidentiality and Privacy.

Security, the Common Criteria, is the only category mandatory in every report.

The other four are elective.

An organization picks them according to what it wants to demonstrate to customers.

Which is why two companies can both accurately say “we have a SOC 2” while describing materially different ground.

A SOC 2 with only the Security category is not silent on privacy by accident. It is silent by scope.

And the report is a CPA firm’s written opinion, not a certificate.

It contains management’s description of the system, the auditor’s opinion, and the auditor’s test results.

It has no regulator behind it either.

No statute switches SOC 2 on.

An organization pursues one because a customer, a prospect or an investor asked for evidence of controls, and the penalty for lacking one is commercial: a lost deal or a failed vendor review.

That is a perfectly respectable reason to have a report.

It is not a reason to cite it for something it never examined.

Before a SOC 2 appears in a privacy answer, the question is one line long.

Is Privacy in scope?

If not, the report has nothing to say.

3. “But the User Clicked ‘Accept,’ So We Have Consent.”

You have a recorded click.

Whether that click governs what every recipient does is a separate fact.

In February 2022 the Belgian Data Protection Authority ruled that the IAB Europe Transparency and Consent Framework, the industry standard for passing an advertising-consent choice across the ad-tech supply chain, had “multiple failings”.

Among them: it could not ensure the consent signals it generated and passed downstream were actually valid.

The authority fined IAB Europe €250,000.

The Dutch data protection authority followed by advising Dutch public agencies to stop using the framework.

IAB Europe said it would appeal.

Note what the ruling was not about.

Nobody was hacked.

Consent was captured, which is the framework’s entire purpose.

The part that failed was the part after the click.

The Facebook quiz “This Is Your Digital Life” shows a harsher version.

About 270,000 users installed it and agreed to its terms.

Facebook’s platform at the time also exposed each installer’s friend-graph data to the app.

The friends consented to nothing.

The result was data on approximately 87 million profiles, 70.6 million of them in the United States.

Do the division yourself: 87,000,000 divided by 270,000 is about 322 profiles for every person who actually took part in the consent event.

Both inputs are approximate, so read that as roughly 320, not a precise ratio.

The API worked as built.

The access control did what it was configured to do.

The consent attached to one person’s decision was simply never bounded to that person before the data flowed outward.

4. “But No One Breached Anything.”

Exactly.

That is the point, not the defence.

Article 32(2) lists the risks security of processing addresses: destruction, loss, alteration, unauthorised disclosure, unauthorised access.

Every one of them is something happening to data against the controller’s will.

Now run the documented failures through that list.

Netflix published its own dataset.

Target used its own purchase records.

The quiz data was obtained through the platform’s own interface, then put to a use nobody had declared.

Users were told their data would be used for academic research.

It was used to build psychographic profiles for political-campaign ad targeting.

The data never changed.

Only its use did.

Purpose creep does not trip a breach detector, because nothing is breached.

The EU regulation itself draws this line in its penalties.

Article 83 sets two fine tiers.

The lower tier, up to €10 million or 2% of total worldwide annual turnover, whichever is higher, covers among other things Article 32 security-of-processing violations.

The higher tier, up to €20 million or 4%, covers violations of core processing principles, data-subject rights and international-transfer rules.

Both caps apply to organizations of any size; the turnover alternative exists to make the fine meaningful against very large ones.

So the regulation that gave you Article 32 prices the principles at double the security article, on both the fixed cap and the percentage.

A clean security posture speaks to the lower tier’s subject matter.

It leaves the higher tier where it was.

And GDPR’s reach does not wait for an EU office.

Under Article 3 it applies to a controller established in the EU wherever processing happens, and to an organization with no EU establishment that offers goods or services to people in the Union or monitors their behaviour there.

5. “But the Data Inventory Is Complete; It Is in the Register.”

It is complete according to whom?

An inventory is only as good as the discovery behind it.

A register built from what engineering teams voluntarily enter will systematically miss what they did not enter.

The marketing pixel.

The analytics SDK.

The vendor integration someone set up on a Friday.

Measuring completeness means looking for the gap directly.

Scan production schemas and data warehouses for columns holding personal-data patterns, whatever the register says is there.

Audit outbound network traffic and third-party SDK calls for data leaving through channels nobody recorded as a flow.

Then do it again, because an inventory’s completeness decays every time a system, integration or vendor is added after the last pass.

The NIST Privacy Framework, Version 1.0 of January 2020, is built on the same idea.

Its Identify-P function underlies the inventory and risk mapping.

Its Govern-P function underlies accountability for keeping that mapping current.

Both are framed as continuous activities, not a snapshot.

An inventory check that only confirms the document agrees with itself measures its tidiness, not its completeness.

This is where the security frameworks help less than people assume.

Article 32 asks for measures appropriate to the processing.

It does not hand you a list of the processing.

If the register is short, the security assessment built on it is a careful assessment of a smaller estate than the one you run.

6. “But Privacy Is Legal’s Job, Not Engineering’s.”

Legal can say what the law requires.

It cannot tell you which columns exist, which SDKs send what, or whether a consent flag reaches the third recipient.

The EU regulation’s own gate makes this concrete.

Article 35 requires a Data Protection Impact Assessment for processing likely to result in high risk.

Its named triggers include new technologies, systematic large-scale monitoring of a publicly accessible area, large-scale processing of special-category data, automated decision-making with legal or similarly significant effects, and processing children’s personal data.

A DPIA must contain a systematic description of the processing and its purposes.

An assessment of whether the processing is necessary and proportionate to those purposes.

An evaluation of risk to the people concerned.

And the safeguards adopted.

The useful version is written during planning, before anything is built.

Necessity and proportionality are not properties of the storage layer.

A well-protected mechanism can be applied to a use of data that a DPIA would flag as unnecessary in the first place.

No strength of encryption changes that answer.

And the facts the DPIA needs, field by field, what is collected, where it goes, what uses it, live in engineering.

A DPIA that cannot show a field is necessary for its stated purpose is documenting a minimization failure in the organization’s own paperwork.

Legal can sign that document.

Only the people who built the system can make it true.

7. No, This Does Not Mean Security Controls Are Irrelevant to Privacy.

They are not.

Article 32’s measures are real obligations, with a real fine tier attached.

A breach is a privacy failure too.

The HIPAA Security Rule’s safeguards are binding where the rule applies, and every implementation specification is either required or addressable, which means implement it or document an equally effective alternative.

It does not mean optional.

PCI DSS v4.0.1, published June 2024, sets 12 numbered requirements under six goals for any organization that stores, processes or transmits cardholder data.

Do all of it.

The point is narrower.

A system can be secure, audited and compliant on security while still processing data it has no necessity for, beyond the consent it holds, or for a purpose nobody declared.

Note, too, how the security frameworks decide who is even in scope.

HIPAA applies by role: covered entities and their business associates handling ePHI in a regulated activity.

A wellness app that is not a business associate has no Security Rule obligation, however sensitive its data.

PCI DSS applies by touching card data.

Neither trigger asks whether the processing is justified.

Protection is necessary. It is not a justification.

8. What You Should Actually Do

Run a DPIA before you build. For any processing that meets an Article 35 trigger, write the assessment during planning, with a necessity-and-proportionality section per field.

A field that cannot be justified there should not reach the schema.

Read the SOC 2 scope before citing it. Check which Trust Services Criteria categories the report covers.

If Privacy is absent, the report is not evidence about privacy, and should not be offered as such.

Test consent propagation end to end. Record a choice, then confirm it changes what each downstream recipient actually does.

A timestamp in a preference centre is capture.

The behaviour of the third recipient is propagation.

Audit the inventory with independent discovery. Scan schemas and warehouses, watch outbound traffic and SDK calls, and repeat on a schedule.

Self-reported entries are a starting point, not evidence.

Review each new use against the declared purpose. When existing data meets a new model, a new partner or a new campaign, check the purpose stated at collection.

A purpose written only in a privacy notice constrains nothing.

Keep the security work, and label it correctly. Article 32 evidence answers Article 32.

Put it in the security column, where it belongs.

9. The Model Is Not Complicated.

Security of processing is the protection plane.

Encryption, pseudonymisation, confidentiality, integrity, availability, resilience, restoration, testing.

Privacy engineering is the justification plane.

Necessity, proportionality, consent scope, propagation, inventory, purpose.

Security asks whether the data is safe. Privacy engineering asks whether the processing should exist, and for what.

Netflix, Target, the quiz app and the consent framework all got through the first question in the way people usually check it: nobody broke in.

Every one of them failed the second.

A clean Article 32 posture and a clean SOC 2 are worth having.

They are receipts for a well-built vault.

They say nothing about whether the contents were yours to keep, or what you are doing with them now.