Privacy by Design Guide for Engineering Teams

Privacy by design is a legal duty under GDPR Article 25, but most engineering teams meet it with a policy document and a late-stage review rather than with code, defaults and deletion pipelines that actually work. Regulators expect measures that are effective and demonstrable, applied when a system is designed and maintained while it runs. This guide turns that duty into engineering practice: what Article 25 and the EDPB guidelines require, privacy design strategies and patterns, LINDDUN privacy threat modelling, privacy requirements and reviews in the SDLC, data minimisation, pseudonymisation, retention and deletion engineering, privacy testing and metrics. It is for software engineers, architects, product managers and the privacy staff who support them; DPIAs, records of processing and subject requests have their own guides.

Key takeaways

Article 25 has two halves. By design means building data protection principles into the means of processing; by default means only the data necessary for each purpose is processed, judged on four dimensions: amount collected, extent of processing, storage period and accessibility.
Effectiveness is the test. The EDPB says each measure "should produce the intended results", and controllers should be able to show it, for example with key performance indicators. A privacy policy without enforcement in code does not meet it.
Threat model for privacy, not just security. LINDDUN covers harms STRIDE misses, such as linking, identifying and unawareness, using the same data flow diagrams engineers already draw.
Deletion is a feature to build, test and monitor. The EDPB says deletion "should be automated"; that means a pipeline that reaches every store, cache, index, backup and third party, with evidence that it ran.
Defaults decide outcomes. Many users never change settings, so sharing, tracking and retention defaults are where privacy by default is won or lost.

What Article 25 actually requires

Article 25(1) requires the controller, "both at the time of the determination of the means for processing and at the time of the processing itself", to implement "appropriate technical and organisational measures, such as pseudonymisation, which are designed to implement data-protection principles, such as data minimisation, in an effective manner". What is appropriate depends on the state of the art, cost, the processing and its risks to individuals.

Article 25(2) is the by default rule: "only personal data which are necessary for each specific purpose of the processing are processed." It applies to "the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility", and by default personal data must not be made accessible "without the individual's intervention to an indefinite number of natural persons." Article 25(3) lets an approved certification under Article 42 serve as one element of demonstrating compliance.

The EDPB's Guidelines 4/2019 (version 2.0, October 2020) add points engineers should know:

It applies to everyone: "DPbDD is a requirement for all controllers, including small businesses and multinational companies alike", and it "does not lower the threshold of requirements for SMEs".
It moves and continues: state of the art is "a dynamic concept that cannot be statically defined at a fixed point in time", and once processing starts there is "a continued obligation to maintain DPbDD", including for legacy systems.
Bought software is in scope: functions in off-the-shelf software that lack a legal basis should be switched off. Processors and producers are "key enablers", and the ICO adds that although Article 25 does not directly address product providers, designing for it is "in their best interests".

The ICO notes that by default "doesn't necessarily require you to switch everything to 'off' by default"; it requires that the default does only what each purpose needs. Outside the GDPR, ISO 31700-1:2023 (Consumer protection: Privacy by design for consumer goods and services, Part 1: High-level requirements) sets high-level requirements across a consumer product's lifecycle without prescribing methods or technologies. The wider legal context is in the GDPR Compliance Guide for Security Teams.

Privacy design strategies and engineering patterns

ENISA's report "Privacy and Data Protection by Design: from policy to engineering" sets out eight design strategies (from Hoepman), four data-oriented and four process-oriented. The NIST Privacy Framework expresses similar goals as privacy engineering objectives: predictability, manageability ("granular administration of data, including alteration, deletion, and selective disclosure") and disassociability.

Strategy	ENISA definition (abridged)	Engineering patterns
Minimise	"restricted to the minimal amount possible"	Field-level justification, optional rather than required fields, collect derived values (age band, not birth date), sample telemetry
Hide	personal data and interrelationships "hidden from plain view"	Encryption at rest and in transit, pseudonymous identifiers, log redaction, masking in support tools
Separate	processed "in separate compartments whenever possible"	Separate identity data from behavioural data, per-service databases, on-device processing
Aggregate	"at the highest level of aggregation"	Counts and cohorts for analytics, coarse location, minimum group sizes in reports
Inform	data subjects "adequately informed"	Just-in-time notices at the point of collection, in-product privacy centre
Control	"agency over the processing"	Granular settings, self-service export and deletion, consent records honoured by downstream services
Enforce	a compliant privacy policy "in place and ... enforced"	Purpose tags on data, policy-as-code checks, access control on personal data stores
Demonstrate	able to "demonstrate compliance"	Design records, privacy review artefacts, deletion and access logs, test evidence

Data minimisation in practice, beyond the table:

Purpose per field: every personal data field in a schema carries a documented purpose and retention class; a field with neither does not ship. The EDPB gives the example that non-essential fields "cannot be required fields" in an order form.
Collect less precisely: the ICO's examples include a cake retailer that needs a birthday but not the birth year, and a running app that collects location only when a run begins.
Keep personal data out of side channels: URLs, query strings, analytics events, error trackers, crash dumps and debug logs collect personal data nobody designed for. Use structured logging with allowlisted fields rather than redaction after the fact.
Use synthetic or masked data outside production: copies of production data in test environments multiply exposure and are rarely covered by deletion.

Privacy threat modelling with LINDDUN

LINDDUN, developed at KU Leuven's DistriNet group, is a privacy threat modelling method built on data flow diagrams (DFDs). The process is: model the system as a DFD, map threat categories to DFD elements (external entities, processes, data stores, data flows), elicit and document threats, then select mitigations such as privacy-enhancing technologies and privacy patterns. LINDDUN GO is a lightweight card-based version for workshops; LINDDUN PRO is the systematic, element-by-element version for high-risk systems.

Threat category	Meaning	Example in a typical app	Typical mitigation
Linking	Items of interest can be linked without knowing the identity	Same device ID across analytics, ads and support logs builds a profile	Per-purpose pseudonyms, rotating identifiers
Identifying	A person can be singled out from data or behaviour	"Anonymised" export with postcode, birth date and gender	Generalisation, aggregation thresholds, re-identification testing
Non-repudiation	A person cannot deny an action, where deniability matters	Whistleblowing or health service logs tie every action to a named user	Minimise attribution where not required, restricted logs
Detecting	Someone can infer that data about a person exists	Account recovery confirms "this email is registered" on a sensitive service	Uniform responses, rate limiting
Data disclosure	Excessive collection, sharing or exposure of personal data	API returns full user objects to the client; overshared support exports	Field-level response filtering, least privilege, encryption
Unawareness and unintervenability	People do not know about, or cannot influence, the processing	Contacts uploaded silently; no way to correct or delete	Just-in-time notices, settings, self-service rights
Non-compliance	Processing breaches law, policy or the organisation's own promises	Retention longer than the privacy notice says	Policy-as-code, retention enforcement, audits

Run LINDDUN alongside security threat modelling (for example STRIDE) on one DFD. Where a feature uses AI agents or models, combine it with the AI Agent Threat Modelling Guide. High residual risks feed the DPIA; see the DPIA Guide: Running a Data Protection Impact Assessment.

Privacy in the SDLC

Privacy reviews fail as a single sign-off before launch. Spread them across the lifecycle, sized by threshold questions at intake.

Phase	Privacy activity	Artefact or gate
Intake and discovery	Threshold questions: personal data? special category? children? new purpose? new recipient?	Privacy risk tier; DPIA screening
Requirements	Privacy requirements and user stories with acceptance criteria	Stories in the backlog, not a separate document
Design	DFD, LINDDUN, data inventory entries, retention classes, default settings	Design review sign-off for medium and high tiers
Build	Privacy code review, schema and logging checks, secrets and test data rules	Pull request checklist, automated checks in CI
Test	Privacy test cases: defaults, consent honoured, deletion and export work end to end	Test evidence attached to the release
Release	Notice updated, record of processing updated, feature flag for staged rollout	Release checklist
Operate	Deletion job monitoring, access reviews, drift detection on new fields and data flows	Metrics and periodic review

Privacy requirements as user stories

Minimisation: "As a customer, I can complete checkout without creating an account, so that the shop holds only order data." Acceptance: no account record is created; order data follows the order retention class.
Retention: "As the data owner, I need inactive accounts deleted 24 months after last sign-in" (an illustrative period). Acceptance: deleted from primary stores, search index and caches, with evidence recorded.

Privacy code review checklist

New personal data fields: purpose, retention class and classification tag present in the schema.
Logging: no personal data, tokens or full request bodies in logs; identifiers pseudonymised. The EDPB lists pseudonymising "back-ups/logs" as a security measure.
APIs: responses return only the fields the client needs.
Third parties: new SDKs, analytics tags or outbound calls are listed and approved.
Access: new service identities reading personal data have scoped permissions.

Privacy feature flags help: ship new data collection behind a flag, enable it for a pilot ring, and switch it off quickly if defaults, notices or deletion misbehave.

Pseudonymisation done properly

The EDPB's Guidelines 01/2025 on Pseudonymisation (adopted 16 January 2025 for public consultation) confirm that pseudonymised data "remains information related to an identifiable natural person, and thus is personal data", but that pseudonymisation "reduces confidentiality risks when done effectively" and is "an effective measure for data protection by design and by default".

Choose the technique: keyed one-way functions "like HMACs", encryption, or random pseudonyms held in a lookup table. Plain unsalted hashes of emails or phone numbers are easily reversed by guessing and are not adequate.
Keep the additional information separate: the key or lookup table lives in a different system, under different access control (a KMS or tokenisation vault), from the pseudonymised data.
Define the pseudonymisation domain: decide which teams or recipients must not be able to re-identify, and use different keys per domain so data sets cannot be joined across them.
Rotate and retire keys: destroying a pseudonymisation key can be part of a deletion design, provided no other path back to the person remains.

Anonymisation, tokenisation, differential privacy and other techniques are compared in the Privacy-Enhancing Technologies Guide.

Retention and deletion engineering

Storage limitation fails quietly. The EDPB lists automation, anonymisation, deletion procedures and tests of their effectiveness as key elements, and the NIST Privacy Framework subcategory CT.DM-P5 reads "Data are destroyed according to policy." A working deletion pipeline needs four things: an inventory of where each data class lives (see the Data Mapping and ROPA Guide), a retention class on each record or table, a trigger (age, inactivity, account closure, erasure request), and verification.

Store	Deletion mechanism	Common pitfall
Relational and document databases	Scheduled jobs by retention class; hard delete or anonymise in place	Soft-delete flags that never purge
Object storage and data lakes	Lifecycle rules by prefix or tag; partition by date to drop whole partitions	Records mixed into large files that cannot be rewritten cheaply
Search indexes, caches, vector stores	Delete events propagated from the source of truth	Index rebuilt from a stale snapshot restores deleted data
Logs and telemetry	Short default retention, pseudonymised identifiers	Indefinite retention "in case it is useful"
Backups	Expire on rotation; per-user encryption keys allow cryptographic erasure	Restores reintroduce deleted records without re-applying deletions
Processors and third parties	Deletion API calls or contractual deletion with confirmation	No record of what was sent where

Use one deletion event: publish an "erase subject" event that every service subscribes to and acknowledges, rather than one script that knows every table.
Respect legal holds: a hold flag suspends deletion for named records, with an owner and expiry.
Verify: sample deleted identifiers and search for them across stores; alert when a deletion job fails or processes zero records for longer than expected.

Erasure requests use the same pipeline; handling of requests themselves is in the DSAR Guide: Handling Data Subject Requests.

Privacy by default settings

Visibility: profiles, posts and shared items start private or limited, never public to "an indefinite number of natural persons".
Collection: optional tracking, precise location, contact upload and microphone access are off until the user turns them on for a purpose they understand.
Retention: the default is the shortest period that serves the purpose; longer history is a user choice.
Honest interfaces: the ICO tells organisations to "Avoid harmful design practices that use elements like language and colour to influence users' decisions". Consent and cookie flows are covered in the Consent Management Guide: Cookies, CMPs and GPC.
Bought and configured software: review vendor defaults (telemetry, data sharing, AI features) before deployment, since the EDPB expects functions without a legal basis to be switched off.

Where identity fits

The accessibility dimension of Article 25(2) is an access control question, and much of it concerns machines rather than people: service accounts, ETL jobs, analytics connectors and AI agents that read personal data stores. Give each its own identity scoped to the data it needs, review it like human access, and log sensitive reads. The 23andMe breach showed how access to around 18,000 accounts exposed data on nearly 7 million people through a sharing feature, which is a design and default question as much as an authentication one. See the Identity Data Privacy and Consent Guide.

Choosing an approach: small and large teams

Small teams: a privacy champion per product team, a one-page threshold questionnaire, LINDDUN GO in design sessions, a pull request checklist, and platform features (lifecycle rules, TTL indexes) before custom tooling.
Large organisations: a privacy engineering function that owns shared services: inventory fed from schema metadata, a deletion and export orchestrator, a pseudonymisation service and policy-as-code checks in CI, with low-risk changes self-certifying.
Regulated or high-risk processing: LINDDUN PRO, a full DPIA, independent review, and documented testing evidence for every release that changes personal data flows.

Implementing privacy by design in phases

Baseline: inventory personal data stores and flows for the highest-risk products, and record privacy debt: unused fields, missing retention, logs with personal data, unscoped service identities.
Standards: publish the threshold questionnaire, retention classes, logging rules and code review checklist, and add them to engineering templates.
Pilot: run the full process with two teams for a quarter and adjust effort to what teams will sustain.
Automate: add CI checks for new personal data fields without tags, logging of blocked fields and new third-party domains; start in warning mode, then fail builds.
Build deletion: implement the deletion event and per-store jobs, run in report-only mode first, then delete, with verification sampling. Keep the ability to pause a job if it deletes the wrong scope.
Pay down debt and demonstrate: schedule privacy debt like security debt, starting with excess retention and logs, and keep design records, review outcomes and deletion evidence.

Detection and measurement

The EDPB suggests key performance indicators to show effectiveness. Useful engineering measures:

Review coverage: percentage of releases touching personal data that completed the required privacy tier.
Tagged fields: percentage of personal data fields with purpose and retention class in schema metadata.
Retention compliance: records held beyond their retention class, by store, trending to zero.
Deletion reliability: share of erasure events acknowledged by all subscribed services within the target time, and failed deletion jobs per month.
Log hygiene: personal data detections in logs and telemetry per week from scanning.
Privacy debt: open privacy debt items and their age.

Framework mapping

Practice	GDPR	NIST Privacy Framework 1.0	NIST SP 800-53 Rev. 5	ISO/IEC 27001:2022 Annex A
Security and privacy engineering principles	Art. 25(1)	CT.PO-P	SA-8, SA-8(33)	A.8.25, A.8.27
Minimisation and defaults	Art. 5(1)(c), Art. 25(2)	CT.DM-P	SI-12(1), PT-2	A.5.34
Pseudonymisation and disassociation	Art. 4(5), Art. 25(1), Art. 32	CT.DP-P1, CT.DP-P2	SI-19	A.8.11
Retention and deletion	Art. 5(1)(e), Art. 17	CT.DM-P5	SI-12(3)	A.8.10
Threat modelling and DPIA	Art. 35	ID.RA-P	RA-8	A.5.34
Privacy testing and test data	Art. 25(1)	CT.DM-P	SA-11	A.8.29, A.8.33

CIS Controls v8.1 covers the operational side under Control 3: 3.1 (data management process), 3.4 (enforce data retention) and 3.5 (securely dispose of data). ISO/IEC 27701 extends an ISO 27001 management system to privacy. Programme-level structure is in the Privacy Programme Guide for Security Teams.

Common failure patterns

Review at the end: privacy sees the feature a week before launch, when the only options are delay or accept the risk.
Soft delete forever: records are flagged deleted but remain in tables, indexes and backups, so erasure promises are untrue.
Personal data in logs: request bodies, tokens and identifiers flow into logs and chat transcripts kept indefinitely. The DeepSeek database exposure leaked chat logs from an open database.
Storing what should never be stored: the Firebase misconfigurations exposed 125 million user records including 19 million plaintext passwords.
Hashing as anonymisation: unsalted hashes of emails are treated as anonymous and shared, then reversed by lookup.
Sharing defaults that scale harm: features that expose one user's data to many others by default turn a small account compromise into a large breach.

Practitioner checklist

Add privacy threshold questions to feature intake and tier reviews by risk.
Require purpose and retention class tags on every personal data field.
Run LINDDUN on the data flow diagram for medium and high-risk features.
Write privacy requirements as user stories with testable acceptance criteria.
Use the privacy code review checklist and CI checks for logging and new fields.
Pseudonymise with keyed functions or vault tokens, with keys held separately.
Build an event-driven deletion pipeline covering indexes, caches, backups and processors, and verify it.
Set private, minimal defaults and review vendor defaults before deployment.
Track review coverage, retention compliance and deletion reliability as KPIs.

Standards and references

Related NHI Mgmt Group resources: GDPR Compliance Guide for Security Teams · Privacy-Enhancing Technologies Guide · Data Mapping and ROPA Guide · DSAR Guide: Handling Data Subject Requests · Data Classification Guide. This guide summarises GDPR Article 25, EDPB and ICO guidance and related standards for engineering teams and is not legal advice.