Last updated on September 18th, 2026 at 10:49 am
This is one of many areas most compliance guides ignore: data with an elegantly drafted privacy policy, a DPIA on record, and a DPO who actually reads the GDPR, yet you are still entirely vulnerable the instant an auditor reviews your actual data flows.
That is the gap Privacy-Enhancing Technologies (PETs) were designed to bridge. Not theoretically. In live system schemas, API‘s, analytics pipelines.
PETs are not one product. They encompass a group of techniques and approaches: encryption, pseudonymization, differential privacy, federated learning, trusted execution environments, and others. What unites these techniques is the principle of reducing the amount of raw, identifiable data that ever exists in any environment.
As they stand today, most are at an intriguing stage: a few are developed enough for regulators to name them by title, many are emerging from research into manufacturing, and one or two remain in a state of near-auto-standardization.
Table of Contents
GDPR, CCPA, and Where PETs Sit Legally
These two regulations take different approaches, and that matters when choosing where your PETs sit.
Underpinned by risk, the GDPR can be understood as Article 25 (“data protection by design and by default”) and Recital 78, meaning to integrate privacy as a principle into your system from the outset, not as an afterthought. Article 32 mandates “appropriate technical measures,” with encryption and pseudonymization as specific examples. And this requirement is ‘not merely aspirational’, with enforcement bodies such as the ICO or the EDPB approaching a functioning PET used for compliance purposes as a representation of good practice, not just good faith.
More rights-centric CPRA (and the more comprehensive CCPA) focuses on rights such as consumer access, deletion, opt-out of sale, and transparency. Privacy-by-design is not an explicit statutory requirement here, as it is under the GDPR; it’s another emerging best practice. Nonetheless, PETs make it possible to fulfill several CCPA requirements in practice, especially around restricting the amount of raw data exported from the protected environment:
| GDPR data minimization (Art. 5) | Pseudonymization, synthetic data, aggregation, differential privacy |
| GDPR integrity/confidentiality (Art. 5 & 32) | Encryption (at rest, in transit, in use), TEEs |
| GDPR privacy-by-design (Art. 25) | Any PET applied at schema/design stage |
| GDPR cross-border transfers (Chapter V) | Encryption, federated learning, DP as supplementary measures |
| CCPA “reasonable security” | Encryption, pseudonymization |
| CCPA data minimization (emerging) | Federated learning, aggregation |
One simple mapping I find useful to explain to non-legal teams is this: one complication that’s tripped people up is that the GDPR doesn’t specify which PETs you need to use, only that you should choose “appropriate” measures based on the risk. This is a bit of a trap – it’s clearly designed to give you flexibility, but you’ll be expected to justify your decisions in your DPIA documentation.
What’s Already Production-Ready
Encryption: The Non-Negotiable Baseline
Encryption at rest and in transit is the standard now, not the maximum. Both GDPR Articles 5 and 32 list it. The ICO, the EDPB, and almost every sectoral supervisor take it as a minimum safeguard.
What’s newer and therefore more interesting is encryption in operation. Confidential computing (Intel SGX, AMD SEV, ARM TrustZone) lets data be processed within a trusted execution environment where no one can see it in the clear, not even the cloud provider.20 It’s becoming a production solution for healthcare and financial data.21
Pseudonymization More Nuanced Than Most Teams Realize
I’ve seen one common mistake across the organizations I compare: conflating pseudonymization with anonymization. They are not the same, and the EDPB has been quite clear on this.
Pseudonymized data remains personal data for GDPR purposes until it can be re-identified by anyone (including the original controller) using additional information. In the EDPB’s 2024 guidance on pseudonymization, it introduced a new concept: the “pseudonymization domain.” You’ll need to specify who has access to the re-identification keys, where they are stored, and what controls are in place. That‘s a lot tighter than just swapping out tokens, isn’t it?
The good part: if you get this right, pseudonymization makes any DSAR and ‘right to deletion’ process ten times easier to deal with – you look for a key and delete rather than sift through the table.
Differential Privacy From Research to Regulated Practice
Differential privacy (DP) obscures data outputs by injecting custom, computational noise into data or queries such that you can no longer determine, from the output, whether or not a person’s data was part of the sample. Apple, Google, and the US Census Bureau have deployed it in the wild for years.
What has improved is that NIST issued draft guidance for evaluating DP guarantees. This was the leap to “something you can reference in a DPIA (with an evaluation method specified). And if you are a company needing to demonstrate a principled approach to regulators…
PETs for Regulatory Compliance: The Second Wave That Is Only Beginning
The frontier now isn’t inventing new PETs. It’s mainstreaming, bundling, and testing them in existing regulatory programs.
Hybrid PET Stacks
Several organizations working on cross-border analytics and AI training on sensitive data are experimenting with several PETs at once, what practitioners call hybrid stacks. These could include a differential privacy layer on top of the aggregate output, a federated learning architecture to avoid collecting real data in a single place, a pseudonymized data store, and a TEE for any identifiable input. Each layer forestalls a different article of the GDPR. The problem is that the overheads accumulate, which is why such architectures are still used selectively.
Federated Learning and Multi-Party Computation
PoLP can be achieved in several ways. Crowdsourcing can pool training samples into one corpus, but federated learning lets multiple entities train a joint model without transmitting the data itself. Multi-party computation enables joint computation on combined datasets without any single party gaining insight into other users’ input. Both are cited as useful analytics tools in the ICO’s PETs paper, the sUN’s PET Guide 2023, and the Bank of International Settlements whitepaper.
In my experience reviewing FL implementations, the compliance story is much easier to tell than with traditional central management because the data architecture is minimized, not because policy controls force that result.
Evaluation Frameworks Are Catching Up
The NIST PETs Testbed is developing reference architectures and evaluation criteria to help organizations rationalize their DP parameters and PET configurations in documentation, rather than relying on instinct. The EDPB’s comprehensive pseudonymization guidance, the ICO’s two-part PETs document (one for DPOs, one for technologists), and the UN’s PET Guide these all represent a transition: regulators are moving from broad support to specific standards with example reference models.
This matters because “we use encryption and pseudonymization” is no longer enough. We want to ask how it was configured, why, and what assessment led to that decision.
Where This Gets Hard: Real Challenges, Not Hypotheticals
The Anonymization vs. Pseudonymization Line Is Still Blurry
Genuine anonymization – permanent, irreversible, and cannot be re-identified based on any realistically available auxiliary data source – then the dataset itself ceases to be subject to the GDPR. That all sounds great, but the EDPB guidance also demonstrates how difficult comprehensive anonymization is in practice. Auxiliary data sources make re-identification possible.
When organizations mistakenly treat pseudonymized data as truly anonymous, they make one of the most significant and risky compliance errors I have seen. It introduces concealed GDPR risk exactly because management assumes it no longer applies.
The Utility-Privacy Trade-Off Has No Perfect Answer
Differential privacy mitigates re-identification risk by adding noise, but more noise means reduced analytical accuracy. Regulators have not objectively determined a “correct” epsilon (the privacy budget parameter in DP) to mandate. Organizations will be called upon to defend their selection by reference to the risk profile of the use case. Which… is not unreasonable, if technical staff, DPOs, and legal teams can agree on what they are talking about.
Governance and Skills Gaps Are the Real Bottleneck
The ICO, ISACA’s 2024 PETs white paper, and many other references trace back to the same fundamental issue: most firms have the legal awareness and even the technical curiosity about PETs, but no internal structure to judge, implement, and record PETs uniformly. DPOs and engineers, more often than not, have entirely separate mental templates of what a DPIA entails and what PETs seek to prove.
[H3] Compliance Theater Is a Real Risk
The ISACA white paper noted this up front: configuring PETs as part of a solution without threat modeling and governance leads to a false sense of security. The weakest key-management encryption: domain-undefined pseudonymization. A DP with an epsilon value providing effectively no protection and using PETs in name only.
How to Actually Leverage This: A Practical Path
Start With Legal Mapping, Not Technology Selection
Frame the set of requirements, which are derived from the principles of GDPR and CCPA obligations, and then ask: which PET maps to which obligation for this use case? Cross-border analytics maps differently than internal reporting or training an AI model: Reference ICO’s PETs guidance and the UN PET Guide for this mapping.
Design for Minimization First, Then Layer Up
Begin with pseudonymization and aggregation at the schema level; control identifiers where the API touches the world, isolate re-identification keys behind access control. Design the pseudonymization domain around the domain the EDPB recommends. Then layer in differential privacy or federated learning where the use case makes the engineering effort worthwhile.
Build Evidence, Not Just Implementation
Keep documentation that ties specific PET configurations to specific obligations under GDPR or CCPA. (Include threat models, configuration choices, and, if you have them, test results or outputs from NIST-aligned frameworks.) Regulators & auditors aren’t checking whether you have PETs; they’re checking whether you understand why you did.
Who Should Actually Be Reading About This
If you’re building data products, working in ML engineering, or sitting in a DPO role at any organization that owns EU or California resident data at scale, this isn’t hypothetical. Regulators are no longer satisfied with policy-level privacy. They want it in the architecture.
The incremental approach is feasible: encrypt and pseudonymize first, then implement the DP and FL where the risk deserves it. The ones who are doing it successfully are the organizations that have brought their legal and engineering functions together around common evaluation frameworks, not the ones with the most advanced crypto.
I’m a technology writer passionate about AI and digital marketing. I create engaging and useful content that bridges the gap between complex technology concepts and digital technologies. My writing makes the process easy and engaging. I encourage participation I continue to research innovation and technology. Let’s connect and talk technology!
