GDPR Article 25 makes privacy by design a duty

You must now treat privacy by design as a lifecycle engineering duty that produces inspectable evidence at every stage: from initial processing decisions through supplier configuration, deployment, and operational review. Article 25 GDPR requires you to document the technical and organisational choices that govern personal data, revisit them as processing continues, and distribute accountability across builders, vendors, and deployment teams.

An analysis of 9 October 2026 of privacy by design as a lifecycle engineering duty argues that Article 25 requires controllers to make defensible technical and organisational choices, preserve evidence of those choices, and revisit them whilst processing continues. The analysis examines a confidential legal-document workflow that ingests contracts, sends selected context to a large language model for summarisation, and returns findings to counsel. In our assessment, this framing shifts privacy by design from a launch-phase compliance checkpoint into an operational accountability structure: you must be able to show not only what safeguards exist, but who implemented them, why they were chosen, and whether they remained in place.

What does Article 25 actually require you to do?

Article 25(1) requires you to implement appropriate technical and organisational measures when determining the means of processing and throughout the processing itself. This is not a one-time design review. It is a continuous obligation to embed safeguards into architecture, not add them after deployment. Article 25(2) requires that personal data necessary for each specific purpose be processed by default, limiting the amount collected, processing scope, storage period, and accessibility. A system can use strong encryption and still fail the default obligation if optional fields are enabled, retention lacks a defined purpose, or records reach more people than necessary.

The practical distinction is this: a privacy statement records intent. Inspectable evidence includes requirements records, data-flow diagrams, supplier instructions, configuration decisions, test results, retention rules, access reviews, and risk assessments. You must be able to show that builders documented the control, vendors exposed relevant settings and processing details, and deployment teams preserved evidence that production configuration matched the approved design.

Which four factors shape your design choices?

Article 25 does not demand one architecture for every controller. It demands a documented choice based on four factors: the state of the art, the cost of implementation, the nature, scope, context and purposes of processing, and the risks to people's rights and freedoms.

• State of the art — identify technical and organisational measures reasonably available for the processing rather than accepting a vendor's newest feature; encryption, tokenisation, segmentation, access restrictions, privacy testing, and controlled deletion may all be relevant.
• Cost — record implementation effort, operational constraints, and alternatives considered; a limited budget does not make a foreseeable high-impact risk acceptable.
• Nature, scope, context and purposes — describe what problem the controls must address; a confidential legal workflow, an employee-monitoring system, and a public-facing contact form involve different data, affected people, purposes, and operating conditions.
• Risks to rights and freedoms — describe possible harm to identifiable people, assess likelihood and severity, and link each risk to a safeguard; record who accepted any residual risk and when that decision must be revisited.

A defensible Article 25 file connects each factor to a decision, an accountable owner, an inspectable implementation artefact, and a review trigger. That structure makes responsibility testable across you, your builders, vendors, and deployment teams.

How do you implement the four control surfaces?

Article 25(2) becomes useful when you translate it into four control surfaces: collection, processing extent, retention, and accessibility. These are not abstract privacy principles. They are places where product requirements, code, configuration, and operational review can either restrict or expand exposure.

1. Establish field-level necessity at collection — each field should have a defined purpose; if a field has no purpose, the default should be to omit it, not collect it in case it becomes useful.
2. Remove or suppress attributes during processing — a summarisation service may need document text but not direct identifiers; an analytics pipeline may need an event category without retaining the underlying content; the control is inspectable when the transformation rule and resulting payload can be reviewed.
3. Enforce a retention schedule with deletion logic — deletion or archival should identify the purpose, the event that starts the retention period, the responsible system, and the evidence that the rule ran; where longer retention serves a separate purpose, that purpose should be assessed rather than inherited.
4. Control accessibility through role-based scopes and approval gates — role-based access, tenant isolation, approval gates, and restricted exports can prevent personal data from becoming available to an indefinite audience; pseudonymisation and encryption should be selected in light of the processing context and risk, not treated as substitutes for minimisation.
5. Document the trade-off between richness and exposure — keeping more fields for longer may support richer analysis, but it also expands the information available for later use, access, and disclosure; a privacy-by-default design makes that trade-off explicit and requires an active decision before expanding collection or visibility.

What does pseudonymisation require you to demonstrate?

Pseudonymisation is a risk-reduction architecture, not a conversion of personal data into anonymous data. Its protection depends on controlling the information that permits reversal. Under Article 25, pseudonymisation is an example of an appropriate measure, whilst pseudonymised data remains personal data when separately held information can support re-identification.

A defensible design preserves four inspectable artefacts: replacement logic, storage topology, access reviews, and re-identification test results. You should also record whether pseudonyms are stable, rotated, purpose-scoped, or shared across systems. Those records distribute accountability across the teams that build the control, vendors that operate components, and deployment teams that configure access and exceptions.

• Identifier replacement — substitute direct identifiers with tokens or other pseudonyms; the implementation record should specify what is replaced, how collisions are handled, and whether the transformation preserves linkability across events.
• Isolated mapping data — separate reversal information from the operational dataset through distinct physical or logical storage, with network segmentation where appropriate.
• Access controls on re-identification — establish a separate permission boundary for staff or services able to use the mapping, with restricted, authenticated access and monitoring independent of ordinary operational-data access.
• Re-identification limits — document when reversal is allowed, who authorises it, what logging is required, and how linkage risk is reassessed after system changes; conduct documented tests to verify the limits.
• Encryption and hashing — protect mapping material, but recognise that encryption does not determine who may decrypt it or under which conditions; hashing can reduce direct exposure whilst still permitting linkage or inference depending on implementation and available auxiliary information.

How do you manage privacy by design in a shared architecture?

Article 25 is often described as a controller obligation, but modern processing rarely sits inside one organisation's architecture. Software builders create the application, SaaS vendors operate components, model providers handle inference or logging, and deployment teams configure integrations. You still have responsibility for your processing decisions, yet you may not control every technical layer that affects the result.

A vendor may offer privacy settings without making restrictive defaults configurable or persistent. An AI provider may retain prompts or outputs in operational logs under terms your deployment team has not examined. An integration layer may pass complete records to a downstream service because no local filtering occurs before the API call. Each gap can undermine Article 25(2).

A practical control matrix should assign each safeguard to an owner and name the evidence that travels with the deployment. That evidence might include exported policies, configuration snapshots, supplier terms, access logs, and test results. In a shared architecture, documentation is not administrative residue. It is how you demonstrate which party made each privacy-relevant decision.

Tooling can automate evidence collection, configuration snapshots, and access logging. It cannot replace your legal assessment of the processing, your due diligence on suppliers, or your professional judgment about which safeguards fit the risk. The design record is only as useful as the decisions it reflects and the discipline with which you revisit them.