Skip to main content
Privacy Track
Category: Privacy Governance & Design

Privacy-Preserving Techniques

Also known as: PPTs, Privacy-Preserving Technologies, Privacy-Enhancing Techniques
Simply put

Privacy-preserving techniques are methods designed to protect the privacy of individuals while still allowing data to be used, analysed, or shared. They generally aim to reduce the risk that a person can be identified from data, or to keep sensitive information hidden even while it is being processed. Common examples include modifying data so individuals cannot be readily identified, and encrypting data during use or storage.

Formal definition

Privacy-preserving techniques refer to a broad set of methods and technologies used to advance data privacy and security objectives while still enabling data processing, analysis, or model training. Reported examples in the evidence include data anonymisation (modifying personal information so individuals cannot be readily identified), encryption, federated learning, homomorphic encryption, and secure computation methods; privacy-preserving machine learning specifically describes training, tuning, and inference on models without exposing the underlying sensitive data. The evidence characterises these techniques with reference to technical parameters such as plaintext and ciphertext size. Note that these techniques vary widely in the degree and type of protection they provide, and their effectiveness is context-dependent; the source evidence does not specify how any given technique maps to GDPR concepts such as anonymisation, pseudonymisation, or 'appropriate technical and organisational measures', and readers should assess each technique's legal status against the current regulatory position rather than assuming any technique renders data non-personal.

Why it matters

Privacy-preserving techniques matter because they address a recurring tension in data-driven work: organisations often need to analyse, share, or train models on data, while remaining subject to obligations to protect the individuals that data may relate to. By reducing the risk that a person can be identified, or by keeping sensitive information hidden even during processing, these techniques can support a controller's efforts to implement appropriate technical and organisational measures and to apply data protection by design and by default. They are therefore frequently discussed as tools that may help manage privacy risk rather than as a single guaranteed compliance outcome.

That said, the techniques vary widely in the degree and type of protection they provide, and their effectiveness is context-dependent. The source evidence does not establish how any given technique maps onto GDPR concepts such as anonymisation, pseudonymisation, or 'appropriate technical and organisational measures'. This distinction is significant in practice: genuinely anonymous data generally falls outside the scope of the GDPR, whereas pseudonymised data typically remains personal data and stays in scope. Whether a particular technique achieves anonymisation in the legal sense is a matter of assessment against the current regulatory position and relevant guidance, and regulators may take differing views.

Readers should therefore treat privacy-preserving techniques as a category of risk-reducing measures whose legal status depends on how, and how robustly, they are implemented in a specific processing context. A technique that reduces identifiability in one dataset may not do so in another where additional data could enable re-identification. The prudent approach is to assess each technique's actual effect on identifiability and residual risk rather than assuming any technique automatically renders data non-personal or delivers full compliance.

Who it's relevant to

Data Protection Officers and privacy leads
DPOs and privacy leads may consider privacy-preserving techniques when advising on measures that reduce identifiability or protect data during processing. They should assess, rather than assume, whether a given technique achieves anonymisation or amounts only to pseudonymisation, since this affects whether data remains within the scope of the GDPR. Determinations of this kind are context-dependent and should be verified against current regulatory guidance.
Engineers and data scientists
Engineers and data scientists implementing analytics or machine learning are the practitioners most likely to apply techniques such as encryption, federated learning, homomorphic encryption, secure computation, and privacy-preserving machine learning, which the evidence describes as training, tuning, and inference without exposing sensitive data. They should be aware that technical parameters and implementation choices influence the level of protection actually achieved.
Compliance and legal teams
Compliance and legal teams evaluating vendor claims or internal proposals should treat privacy-preserving techniques as risk-reducing measures whose legal effect depends on implementation and context. The evidence does not map these techniques to specific GDPR concepts, so teams should avoid assuming any technique automatically renders data non-personal or delivers full compliance, and should assess residual re-identification risk on the facts.
Controllers and processors sharing or reusing data
Organisations that need to analyse, share, or reuse data while managing privacy risk may find these techniques relevant to their choice of technical and organisational measures. Because effectiveness is context-dependent and a technique that lowers identifiability in one dataset may not do so in another, the appropriate technique and its legal characterisation should be determined per processing activity.

Inside PPTs

Pseudonymisation
A technique, expressly referenced in the GDPR, that processes personal data so it can no longer be attributed to a specific individual without additional information kept separately and subject to technical and organisational measures. Pseudonymised data generally remains personal data and stays within the scope of the Regulation, so it does not remove data protection obligations but can serve as a safeguard and risk-reduction measure.
Anonymisation
A process intended to render data no longer relating to an identifiable individual, taking account of all means reasonably likely to be used to re-identify. Where anonymisation is genuinely achieved, the resulting data is generally outside the scope of the GDPR. Whether a given technique achieves true anonymisation is context-dependent and subject to assessment, and regulator guidance on the threshold can vary.
Encryption
A technical measure that renders data unintelligible to those without the decryption key. It is commonly used to protect confidentiality of personal data at rest and in transit. Encrypted personal data typically remains personal data for those able to reverse it, so encryption is treated as a security safeguard rather than a means of taking data out of scope.
Data minimisation and aggregation
Approaches that limit the volume, granularity, or identifiability of processed data, including aggregating records so that individual-level detail is reduced. These support the principle of processing only what is adequate, relevant, and limited to what is necessary, though whether aggregated outputs are non-personal depends on re-identification risk in context.
Privacy-enhancing technologies (PETs)
A broad, evolving category of technical methods designed to reduce identifiability or exposure of personal data during processing. Their maturity, effectiveness, and acceptance by regulators differ, so their suitability should be evaluated case by case rather than assumed.

Common questions

Answers to the questions practitioners most commonly ask about PPTs.

Does anonymisation mean the data is fully outside the scope of the GDPR?
Generally, truly anonymous data, where individuals are no longer identifiable, directly or indirectly, taking account of all means reasonably likely to be used, falls outside the material scope of the GDPR. However, this is a high and context-dependent threshold, and data that is merely de-identified but still re-identifiable typically remains personal data. Pseudonymisation, in particular, does not achieve anonymisation: pseudonymised data is still personal data under the GDPR. The assessment of whether data is genuinely anonymous should be revisited over time, since re-identification risk can change as techniques and available datasets evolve. Regulators and guidance in this area continue to develop, so the boundary should be verified against current official sources.
Is applying a privacy-preserving technique on its own enough to make processing compliant?
No. Privacy-preserving techniques such as pseudonymisation, encryption, aggregation, or differential privacy can support compliance, for example, as technical and organisational measures, but they do not by themselves establish a lawful basis under Article 6 (or an additional condition under Article 9 for special category data), nor do they discharge other obligations such as transparency, purpose limitation, or data subject rights. Compliance is context and risk dependent, and these techniques are typically one component of a broader accountability and data protection by design and by default approach rather than a standalone solution.
How do we decide which privacy-preserving technique to apply to a given processing activity?
Selection generally depends on factors such as the nature, scope, context, and purposes of the processing, the risks to individuals, the state of the art, and the cost of implementation. Different techniques serve different goals: pseudonymisation can reduce linkability while retaining utility for a controller, encryption can protect confidentiality in transit and at rest, and aggregation or generalisation can reduce identifiability in outputs. The choice is typically informed by a risk assessment, and where processing is likely to result in a high risk to individuals, a Data Protection Impact Assessment may be required. There is no single correct technique for all cases, so the decision should be documented and revisited.
Where in a project lifecycle should privacy-preserving techniques be introduced?
As a matter of good practice consistent with data protection by design and by default, these techniques are typically considered as early as possible, at the design stage of a system or processing activity, rather than retrofitted afterwards. Introducing them early generally allows privacy considerations to shape architecture, data flows, and retention decisions. The specifics vary by organisation and project, and the approach should be documented so that design choices can be evidenced as part of accountability.
Can privacy-preserving techniques act as supplementary measures for international data transfers?
In some cases, technical measures such as strong encryption or robust pseudonymisation may form part of the supplementary measures considered alongside a transfer tool. However, transfer mechanisms, adequacy decisions, and the expectations around supplementary measures continue to evolve, and their effectiveness must be assessed on a case-by-case basis in light of the circumstances of the transfer and the destination. A technique that is appropriate in one scenario may not be sufficient in another, so the position should be verified against current official guidance rather than treated as settled or permanent.
How should the effectiveness of a chosen technique be maintained over time?
Because re-identification risk and the state of the art can change, the effectiveness of privacy-preserving measures is generally something to review periodically rather than to treat as fixed. This typically includes reassessing whether pseudonymisation or anonymisation still holds given new data sources or methods, whether encryption standards remain appropriate, and whether organisational controls (such as separation of additional information used for re-identification) continue to be enforced. Ongoing review supports the accountability principle and should be documented as part of the organisation's governance.

Common misconceptions

Pseudonymised data is anonymous and therefore falls outside the GDPR.
Pseudonymisation and anonymisation are distinct. Pseudonymised data can generally still be attributed to an individual using separately held additional information, so it typically remains personal data within scope. Only data that is genuinely anonymised, judged against all means reasonably likely to be used for re-identification, is generally outside scope.
Applying a privacy-preserving technique makes processing automatically lawful or fully compliant.
These techniques are safeguards that can reduce risk and support principles such as data minimisation and security, but they do not by themselves supply a lawful basis under Article 6 or an additional condition for special category data under Article 9. Compliance remains context- and risk-dependent and must be assessed separately.
Encryption removes personal data from the scope of the Regulation.
Encryption is generally treated as a security measure. For parties able to reverse it with the key, the data typically remains personal data, so encryption reduces risk of unauthorised access rather than taking data out of scope.

Best practices

Assess re-identification risk against all means reasonably likely to be used before treating any dataset as anonymised, and document that assessment.
Do not rely on a privacy-preserving technique as a substitute for identifying an appropriate lawful basis under Article 6, plus an additional condition under Article 9 where special category data is involved.
Where personal data (including pseudonymised data) remains in scope, continue to apply the full set of data protection obligations rather than assuming the technique removes them.
Combine techniques such as pseudonymisation and encryption with organisational measures, including keeping any additional attribution information separate and access-controlled.
Treat the effectiveness and regulatory acceptance of PETs and anonymisation methods as evolving, and periodically re-evaluate against current official guidance and the state of the art.
Record the rationale for the chosen technique as part of accountability documentation, noting any recognised uncertainty or divergence between regulators on the relevant threshold.