ENISA Data Protection Engineering - From Theory to Practice

Protect communications using end-to-end encryption (preventing intermediaries from accessing content) and traffic-pattern hiding (proxy and onion routing) to limit metadata exposure; choose mechanisms commensurate with the threat model and the data category.

• E2EE protocol and key management evidence
• Traffic-pattern protection where metadata sensitivity is high

• Transport encryption mistaken for end-to-end encryption
• No metadata-protection consideration

Storage protects personal data at rest via encryption, key management, access segmentation, deniable/searchable encryption where required, and tamper evidence; storage architecture decisions (e.g. centralisation, replication) are part of the privacy design.

• At-rest encryption with documented key-management
• Access segmentation and least-privilege storage roles

• Encrypted storage with poorly managed keys
• Unsegmented access to sensitive data stores

Privacy-enhancing access control includes privacy-enhancing attribute-based credentials (ABCs) and zero-knowledge proofs (ZKPs), which let a subject prove possession of attributes or facts to a relying party without disclosing the underlying data, supporting selective disclosure and unlinkability.

• ABC/ZKP integration evidence
• Selective-disclosure and unlinkability tests

• Disclosing more attributes than needed when ABC/ZKP could be used

Anonymisation removes all means reasonably likely to be used to identify a natural person from a dataset; if successful the data is outside GDPR scope. The report surveys the main anonymisation models including k-anonymity, l-diversity and t-closeness and warns that anonymisation must be assessed against motivated-intruder and re-identification attacks.

• Anonymisation method documented and risk-assessed against re-identification
• Periodic re-assessment as auxiliary data increases

• Claiming anonymisation when only basic suppression is applied

Pseudonymisation (GDPR Art.4(5)) processes personal data in a way that the data can no longer be attributed to a specific data subject without additional information kept separately and subject to technical and organisational measures. The report describes pseudonymisation techniques and the practice of keeping mapping tables/secrets separate.

• Pseudonymisation procedure with separated re-identification information
• Access controls and key management for pseudonymisation secrets

• Pseudonymisation key stored alongside the pseudonymised data

Differential privacy provides mathematically bounded privacy guarantees (parameterised by epsilon and delta) by adding calibrated noise to query results or to released data, controlling the influence of any single record on the output. The report covers global and local differential privacy and the engineering trade-off between utility and privacy budget.

• Documented differential-privacy mechanism with epsilon/delta budget
• Privacy budget accounting and decay over multiple queries

• Unbounded queries against a 'private' dataset without budget tracking

Selecting an anonymisation/pseudonymisation scheme should be driven by the data utility required, the threat model (motivated intruder), the data type (microdata, statistical, streaming) and the legal context (whether the goal is GDPR-out-of-scope anonymisation or risk-reducing pseudonymisation).

• Scheme-selection rationale linked to use-case and threat model

• Scheme picked by default without threat-model consideration

Selection of the most applicable PET should be driven by the data protection requirement (the principle being implemented), the threat model, the data utility needed and the operational/cost constraints, with multiple PETs typically combined to achieve the goal.

• PET-selection rationale per processing activity
• Justification for combining multiple PETs

• Selecting a single PET as a checkbox without context

GDPR Article 32 requires measures that reflect the state of the art; engineers should track PET and security state-of-the-art (e.g. ENISA guidance, academic and industry benchmarks) and revisit deployed measures as state-of-the-art evolves.

• Periodic state-of-the-art review of deployed PETs and security measures
• References used to establish state-of-the-art

• Frozen baseline that lags state-of-the-art

Demonstrate accountability under GDPR Article 5(2): document the data protection engineering decisions, the implemented PETs, their parameters and the residual risks; provide assurance via DPIAs, conformity assessments, certifications and audit trails.

• Documented data protection engineering record
• DPIAs/certifications/audit trails of PET implementation

• No accountability record of engineering decisions and PET parameters

Moves the high-level requirements of Data Protection by Design into engineering practice: identifying the data protection requirements from the processing context, deriving engineering goals (unlinkability, transparency, intervenability, data minimisation, accuracy, confidentiality, integrity, availability) and translating them into concrete controls.

• Mapping from DPbD requirements to engineering goals and controls
• Traceability between processing requirements and implemented PETs

• No bridging between DPbD policy and engineering controls

Engineering decisions on PETs and other measures should be informed by, and feed back into, the Data Protection Impact Assessment (DPIA): identified high-risk processing drives the engineering measures, and the implemented measures reduce the residual risks recorded in the DPIA.

• Linkage between the DPIA and the chosen engineering measures
• Residual-risk evidence post-engineering measures

• DPIA and engineering performed in isolation

Categorises Privacy-Enhancing Technologies (PETs) and frames how each addresses data protection principles. Three broad categories underpin the report: anonymisation/pseudonymisation, privacy-preserving computation, and PETs for access/communication/storage; complemented by user-facing transparency and intervenability mechanisms.

• PET inventory and taxonomy classification for each in-scope processing activity

• Selecting PETs without an explicit taxonomy/risk fit

Data Protection by Design and by Default (GDPR Article 25) requires that, at the time of determining the means for processing and at the time of the processing itself, the controller implements appropriate technical and organisational measures designed to implement the data protection principles in an effective manner and to integrate the necessary safeguards into the processing.

• DPbD policy and engineering procedures
• Evidence DPbD is applied at design time and during processing

• DPbD treated as documentation only, not engineering practice

The scope of data protection engineering is the practical implementation of GDPR-aligned privacy-engineering measures within products, services and information systems, balancing technical and organisational measures with the state of the art, costs and the rights and freedoms of natural persons.

• Scope statement linking engineering measures to the processing activities
• State-of-the-art justification for the chosen measures

• Engineering measures not tied to identified processing

Homomorphic encryption allows computation over encrypted data without first decrypting it, with partial schemes (additive or multiplicative) and fully homomorphic schemes (arbitrary computation). The report surveys current performance trade-offs and use cases (cloud analytics on sensitive data, secure ML inference).

• Documented HE library/parameters and threat model
• Performance/security trade-off analysis

• Treating HE as a universal solution without performance/scope analysis

Secure multiparty computation lets parties jointly compute a function over their inputs while keeping those inputs private, supporting use cases such as privacy-preserving analytics across organisations and confidential auctions. The report covers protocol families (secret sharing, garbled circuits) and threat models.

• MPC protocol specification and party-trust model
• Adversary model (semi-honest, malicious) selection rationale

• Using MPC outside the threat model it was designed for

TEEs (e.g. Intel SGX, ARM TrustZone, AMD SEV) provide a hardware-protected enclave where confidential computation can run with attestation and integrity guarantees, supporting confidential cloud workloads and processing of regulated data.

• TEE attestation records
• Enclave software measurement and side-channel mitigation

• Trusting a TEE without remote attestation
• Ignoring side-channel risks

Private information retrieval allows a client to retrieve a record from a database without revealing which record was requested, supporting privacy-preserving lookups (e.g. patient records, search). The report covers single-server (computational PIR) and multi-server (information-theoretic PIR) constructions.

• PIR construction and threat-model documentation

• Disclosing query patterns despite using PIR libraries incorrectly

Synthetic data generation produces artificial datasets that preserve statistical properties of the original data without containing real personal data, supporting model training and testing while reducing personal-data exposure; quality and re-identification risk must be assessed.

• Synthetic-data generation methodology and quality/risk assessment
• Membership-inference test results

• Treating synthetic data as inherently safe without re-identification testing

Privacy policies provide the data subject with the GDPR Article 13/14 information in a concise, transparent, intelligible and easily-accessible form, in clear and plain language; engineering practices should support layered policies, machine-readable variants and just-in-time presentation.

• Layered/just-in-time privacy notice
• Plain-language and accessibility review

• Single long legalese policy with no layering or just-in-time presentation

Engineering support for the rights to rectification (GDPR Article 16) and erasure (GDPR Article 17): identifying and reaching all copies and downstream processors, secure deletion or correction, suspension/correction propagation, and audit-trail of the action.

• Erasure/rectification procedure covering primary, replicas, backups and processors
• Propagation evidence to recipients
• Audit trail of rights actions

• Deletion only in the primary store while backups retain the data
• No propagation to processors

Standardised privacy icons supplement textual notices and convey the key elements of a processing activity (purpose, retention, sharing) at a glance, supporting GDPR Article 12's transparency and accessibility expectations.

• Use of standardised privacy icons in notices
• Usability testing of icon comprehension

• Custom icons with no shared meaning or testing

Sticky policies bind a machine-readable usage policy to the personal data itself, supporting downstream enforcement of purpose limitation and onward-transfer restrictions, particularly relevant in data sharing and processor relationships.

• Sticky-policy attachment to data flows
• Downstream enforcement evidence (e.g. usage controls)

• No machine-readable policy binding when data is shared

Privacy preference signals (e.g. Global Privacy Control, OAS/Tracking Preference) let users automatically communicate consent or opt-out preferences to services and devices, supporting machine-readable choice.

• Recognition and honouring of recognised privacy preference signals
• Audit log of signal-driven decisions

• Ignoring known privacy preference signals

Privacy dashboards (service-side and user-side) give data subjects visibility into and control over the personal data a service holds about them and how it is processed, supporting transparency, rights exercise and intervenability.

• Functioning privacy dashboard exposing data, purposes and recipients
• Rights-request actions accessible from the dashboard

• Privacy dashboard that shows data but cannot trigger rights actions

Consent management covers consent gathering (granular, specific, informed, unambiguous, freely given, easy to withdraw) and consent management systems that persist, propagate and demonstrate consent across services in line with GDPR Article 7.

• Consent gathering UX and storage records
• Consent withdrawal mechanism and propagation evidence
• Demonstrability of consent (who/what/when/scope)

• Pre-ticked consent
• Withdrawal of consent harder than granting it

Engineering support for data subject right of access (GDPR Article 15): authenticated request channels, machine-readable export, scope coverage across systems, and where applicable delegation of access requests on behalf of the data subject (Section 6.9.1).

• Right-of-access procedure with response-time SLA
• Coverage of all systems holding the subject's data
• Delegation handling where used

• Right of access limited to a single primary system
• No authenticated channel for SAR