The OECD Built a Catalogue of Privacy-Enhancing Technologies. Here Is How to Use It Without Overrating It

The OECD has launched a Global Repository for Privacy-Enhancing Technologies, a public toolkit meant to help organizations pick a privacy-enhancing technology (PET) for a given job and understand the legal and technical obligations that come with it. The launch was announced at the first in-person meeting of the OECD’s Data Free Flow with Trust expert community, held in Paris on October 19 and 20, 2026, according to Japan’s Digital Agency, whose vice-minister attended.

The repository brings together applicable legal obligations and regulator guidance for PETs, relevant technical standards, suitable use cases, differential privacy tools and the main steps for deploying a PET well. It also includes a configuration tool that lets users narrow options by use case and context. For privacy teams that have heard “use PETs” from regulators for years without much detail, a single reference point is welcome. It does not answer the harder question, which is whether a particular PET deployment actually reduces risk enough to change your legal position.

Why the OECD is doing this now

The repository comes out of the OECD’s Data Free Flow with Trust (DFFT) work, which G7 leaders endorsed in 2023. The expert community behind it focuses on three practical projects: PETs, health and medical data, and cross-border data flows in supply chains. PETs sit at the center of all three, because they promise a way to use or share data without exposing the individuals in it.

Regulators have been circling the same idea from different angles. Data protection authorities in the UK, Singapore, Israel and elsewhere have published PET guidance, and we covered Israel’s guide to PETs for AI when it appeared. NIST has published a standard method for judging differential privacy claims, explained in our piece on NIST SP 800-226. What has been missing is a place where these strands sit side by side. That is the gap the OECD is trying to fill.

The main PET families, in plain terms

Most PETs fall into a few groups. Knowing which group a tool belongs to is the first step to knowing what it can and cannot do.

• Differential privacy adds calibrated statistical noise to data or query results so that no single person’s presence can be inferred. It protects outputs, not inputs. Our explainer on how differential privacy works covers the trade-off between privacy and accuracy.
• Homomorphic encryption allows computation on encrypted data without decrypting it. It is powerful but still slow for many workloads.
• Secure multi-party computation lets several parties compute a joint result without any of them seeing the others’ inputs.
• Federated learning trains a model across many devices or organizations, sending model updates instead of raw data. Updates can still leak information, so it is often combined with differential privacy.
• Trusted execution environments run code in hardware-isolated enclaves so that even the system operator cannot see the data being processed.
• Synthetic data generates artificial records that mimic the statistics of a real dataset. Quality and re-identification risk vary widely.
• Pseudonymization and anonymization techniques remove or replace identifiers. They are the oldest tools and the most often overestimated.

What PETs change legally, and what they do not

This is where organizations most often go wrong. A PET is a control. It can reduce the likelihood or severity of harm, support a data protection impact assessment, and make a transfer or a secondary use easier to justify. In some cases, done well, it can take data outside the scope of privacy law altogether by making it genuinely anonymous. But most PET deployments do not reach that bar, and regulators have become more skeptical of anonymization claims as re-identification methods improve. We discussed that shift in why anonymization is no longer a safe harbor.

Under the GDPR, pseudonymized data is still personal data for anyone who can reasonably re-identify it. Encrypted data is personal data for whoever holds the key. A federated model may still memorize personal data. In each case, the PET lowers risk but leaves the organization’s obligations in place: a lawful basis, transparency, rights handling, security, and accountability. A repository that maps legal obligations next to each technology should make that clearer, and that may be its most useful feature.

A five-step way to use the repository

The OECD toolkit is a reference, not a decision. Teams that get value from it will usually follow a sequence like this:

1. Start with the use case, not the technology. Write down what data you want to use, for what purpose, with whom, and what the risk is if it leaks or is re-identified.
2. Use the repository to shortlist PETs. Filter by use case and context, then read the legal and standards material attached to each candidate.
3. Check the threat model. A PET protects against specific risks. Confirm that the risk you care about, such as a curious partner, an external attacker or a later re-identification attempt, is the one it addresses.
4. Test before you rely on it. Measure utility loss, privacy parameters and re-identification risk on your own data. Record the results.
5. Document the decision. Put the PET, its settings and its limits into your impact assessment and records of processing, so the choice can be explained later.

Where privacy engineering fits

PETs are most effective when they are built into the design of a system rather than added at the end. That is the practical meaning of data protection by design. Our earlier look at PETs moving into infrastructure traced how large platforms have started treating them as standard components.

For most businesses, though, the first privacy controls are less exotic: knowing which scripts and vendors receive data, honoring choices, and documenting what each system does. Captain Compliance’s tools for engineering teams focus there, helping deploy consent controls, block covered technologies, recognize privacy signals and detect changes across websites. They are not PETs in the OECD sense, and they do not replace one where a PET is the right answer. They make sure the basic data flows are under control before more advanced techniques are added.

Frequently asked questions

Is the OECD repository binding?

No. It is a reference toolkit. Legal obligations come from the laws and regulators it points to, not from the repository itself.

Does using a PET make data anonymous?

Usually not. Some techniques, applied well, can support an anonymity claim, but most reduce risk while leaving the data within the scope of privacy law. Treat anonymity as a conclusion you have to prove, not a property of the tool.

Which PET should a small company start with?

It depends on the use case. For publishing statistics, differential privacy is the most mature option. For sharing data with a partner, contractual controls combined with pseudonymization may be enough. For analytics on sensitive data, a trusted execution environment or secure computation may be worth the cost.

Do regulators expect PETs?

Not in general. Several regulators encourage them, and they can support data protection by design and impact assessments. Whether one is expected depends on the risk of the processing and the alternatives available.

The OECD has given PETs something they lacked: a shared index. Whether that changes practice depends on what organizations do after they find a tool in it. A PET picked from a catalogue and switched on without testing is just another line in a privacy notice. One that is chosen for a defined risk, measured and documented is evidence, and evidence is what regulators ask for.