Privacy by design.
What GDPR Article 25 makes you build.

Privacy by design is an engineering and governance approach in which privacy protections are part of how a system is built, not a layer bolted on once it is live. The concept was formalised by Dr. Ann Cavoukian in 2009 as seven foundational principles. It predates GDPR by nearly a decade and began as voluntary best practice.

GDPR changed its legal status. When the regulation took effect in 2018, Article 25 turned the concept into a statutory duty under the name "data protection by design and by default." The distinction is the one point most explainers blur:

GDPR did not adopt the seven principles wholesale. It selected specific elements — above all data minimisation (Article 5(1)(c)) and purpose limitation — and made them technically required defaults. "Privacy by design" is the idea; "data protection by design and by default" is the law. When a regulator audits you, they apply the law.

Article 25(1) — by design. The controller must act "both at the time of the determination of the means for processing and at the time of the processing itself" — at design time and throughout the lifecycle — implementing "appropriate technical and organisational measures, such as pseudonymisation, which are designed to implement data-protection principles, such as data minimisation." The text lets you weigh "the state of the art, the cost of implementation" against risk; proportionality is built in, but it is not a licence to do nothing.

Article 25(2) — by default. "By default, only personal data which are necessary for each specific purpose of the processing are processed." That default applies to four dimensions:

Article 25(3) — certification. An approved certification under Article 42 "may be used as an element to demonstrate compliance." It is evidence, not a safe harbour.

Who bears the obligation? Article 25 binds the controller — the organisation that determines the purposes and means of processing. For an executive the consequence is clear: your Data Protection Officer advises, but accountability for the technical and organisational measures rests with you and your engineering leadership.

These are Ann Cavoukian's original principles, in their exact formulation. They remain the conceptual backbone Article 25 draws on. Principles 2 and 5 map most directly onto Article 25's hard legal requirements.

Article 25 sits in the lower fine tier of GDPR — but "lower" still means up to €10 million, or 2% of total worldwide annual turnover, whichever is higher (Article 83(4)). Supervisory authorities treat design-and-default failures as systemic, because a missing default setting tends to affect every data subject in a system at once.

You cannot implement Article 25 by sending a memo. It has to become part of how systems get designed, built, and signed off. The sequence below is what most published guidance leaves out — it moves from governance gate to technical measures to evidence.

1. 01
   Put a privacy gate at design time, not at launch

   Article 25(1) begins "at the time of the determination of the means for processing." Make that a design-review gate: no system that processes personal data passes architecture sign-off without a privacy-by-design review, and any high-risk processing triggers a DPIA (Article 35) before development. The DPIA is your documented proof that risk was assessed at the right moment.
2. 02
   Implement the technical measures at the data layer

   Data minimisation (collect only necessary fields, unnecessary fields disabled by default), pseudonymisation and encryption (at rest and in transit, identifiers stored separately), least-privilege access control, and automated purpose-bound retention. Each has a named owner — privacy, IAM, data, and security engineers. The executive job is to ensure those owners exist and the measures are reviewable.
3. 03
   Make the defaults privacy-protective

   Article 25(2) is a default obligation, easy to verify and easy to fail. Profiles private by default, data sharing off by default, the most restrictive consent state as the starting point, and no broad exposure of personal data without deliberate action. Defaults are the first thing a regulator or journalist tests.
4. 04
   Map controls to obligations — the step everyone skips

   "Implement appropriate technical measures" does not tell an engineer which control satisfies which obligation. Security frameworks help (NIST CSF, ISO 27001, cloud baselines) but none is organised around GDPR obligations, and none captures Article 25's distinctive "by default" and "by design" requirements. Closing that gap by hand, per system, is the work that does not scale. Pre-built mappings from each obligation to the controls that satisfy it remove the per-team interpretation step.
5. 05
   Generate audit-ready evidence

   Article 5(2) — accountability — means it is not enough to be compliant; you must be able to demonstrate it. Design decision records, DPIA outputs, default-setting justifications, access matrices, retention schedules, and deletion logs are what a regulator or enterprise buyer expects. Decide up front what evidence each measure produces and where it lives.

A regulation defines obligations at the policy layer; engineers work at the execution layer — code, configuration, data, infrastructure. Privacy by design is, in the end, the discipline of connecting the two reliably and provably. The structured rule below is how RuleMesh expresses the Article 25(2) collection-minimisation obligation — the same way to a person, an AI agent, and an audit process:

SHALL configure data collection interfaces IN web forms, APIs, and user
interfaces TO collect ONLY personal data fields strictly necessary FOR each
specific processing purpose BY removing or disabling unnecessary fields
BY DEFAULT ;
EVIDENCE: form schemas, API specifications, field-level data mapping,
data minimisation review records, configuration change logs

AI systems process personal data by their nature — in training data, inference inputs, and outputs that can identify or profile individuals. Article 25 applies to them in full. For executives shipping LLM-based products, "by default" acquires new edges: minimum data into the model, no retention of personal data beyond the inference purpose, logging of what the system saw, and human oversight where decisions have legal or similarly significant effects (Article 22). Privacy by design is becoming the precondition for shipping AI features into regulated markets, not an afterthought to them.

They are two halves of one obligation: design builds the capability; default ensures the safe state is the starting state.

• GDPR Article 32 checklist — security measures mapped to cloud controls →
• Cloud control mappings (AWS, Azure, GCP) →
• Security control mappings (NIST CSF, OWASP) →
• GDPR for developers — full guide →