Article 25: Data protection by design and by default

Article 25 requires you to build privacy controls into how products, systems, and processes are designed and operated, and to make privacy-protective defaults the standard setting for personal data processing. Operationalize it by embedding privacy gates into your SDLC and change management, enforcing data minimization by default, and retaining decision-level evidence for each material processing design choice. (Regulation (EU) 2016/679, Article 25)

Key takeaways:

• Treat Article 25 as an engineering and process requirement, not a policy statement; embed it into SDLC, procurement, and change control. (Regulation (EU) 2016/679, Article 25)
• “By default” means the baseline configuration limits collection, access, retention, and sharing to what’s necessary for the stated purpose. (Regulation (EU) 2016/679, Article 25)
• Your audit defense is an evidence packet: design decisions, risk assessment outputs, approvals, exceptions, and remediation. (Regulation (EU) 2016/679, Article 25)

Compliance teams often treat “privacy by design” as a principle and then struggle to prove it during regulator inquiries, customer due diligence, or internal audit. Article 25: data protection by design and by default requirement is different: it expects concrete technical and organizational measures, implemented at two moments that matter to operators—when you decide how processing will work (architecture, tooling, vendors, data model), and while processing is running (operations, monitoring, access governance, retention, incident response). (Regulation (EU) 2016/679, Article 25)

For a CCO, GRC lead, or privacy program owner, the fastest path is to translate Article 25 into a few “always-on” gates: a role-and-scope register that nails down controller/processor role and processing scope, a requirement-specific operating procedure with named owners and trigger events, and a repeatable evidence packet you can produce on demand. These artifacts let you demonstrate that privacy constraints were considered before build, enforced in production, and revisited when risk changes. (Regulation (EU) 2016/679, Article 25)

This page gives requirement-level implementation guidance you can assign to Engineering, Security, Product, and Procurement tomorrow.

Regulatory text

Article 25(1) requires the controller, taking into account “state of the art,” cost of implementation, the nature/scope/context/purposes of processing, and the risks to individuals, to implement appropriate technical and organizational measures (example given: pseudonymisation). These measures must be designed to implement data protection principles and protect data subject rights, and they must be implemented both when determining the means of processing and during processing. (Regulation (EU) 2016/679, Article 25)

Operator translation: you must (a) make privacy requirements a design input (not a post-launch fix), (b) select measures proportional to risk, and (c) run those measures continuously in operations. If your organization is a controller for a product or service, regulators will expect you to show how architecture and default settings prevent over-collection, uncontrolled access, indefinite retention, and unnecessary sharing. (Regulation (EU) 2016/679, Article 25)

Plain-English interpretation (what Article 25 demands)

Data protection by design: privacy constraints are part of the build plan. Before you collect personal data, you decide what you need, why you need it, who can access it, how long you will keep it, and how you will protect it. You implement the controls in the system and supporting processes. (Regulation (EU) 2016/679, Article 25)

Data protection by default: the “out-of-the-box” configuration is privacy-protective. Optional processing (extra data fields, additional sharing, extended retention, broad internal access) should be off unless there is a documented need aligned to the purpose and risk. (Regulation (EU) 2016/679, Article 25)

Who it applies to (entity and operational context)

Article 25 places explicit obligations on controllers. If you determine purposes and means for processing, you are in scope. (Regulation (EU) 2016/679, Article 25)

Operational contexts where Article 25 shows up immediately:

• Product development and engineering: new features, telemetry, analytics, identity flows, customer onboarding forms, and new integrations.
• Security and IT operations: access control, logging, environment separation, encryption, key management, and incident response workflows.
• Data platform teams: data lake ingestion rules, schema design, data classification, and retention automation.
• Procurement/third-party risk: introducing a third party that changes the “means” of processing (SaaS tooling, processors, analytics SDKs).
• Change management: any change that expands data categories, data subjects, purposes, recipients, retention, or cross-border access. (Regulation (EU) 2016/679, Article 25)

What you actually need to do (step-by-step)

Use this as an implementation checklist you can assign with owners.

1) Lock down role and scope for each processing context

Deliverable: a GDPR role-and-scope register covering:

• controller vs. processor role
• processing purpose(s)
• data categories (personal data types)
• data subjects
• systems involved and data flows
• third parties involved and their role (processor/sub-processor/independent controller where applicable)
• where defaults are configured (app settings, IAM roles, data platform policies) (Regulation (EU) 2016/679, Article 25)

Why auditors ask for this: Article 25 measures must be “appropriate” to risk; you cannot show appropriateness without a defined scope.

2) Embed privacy-by-design gates into SDLC and change control

Implement these gates as “no-merge/no-launch” criteria for in-scope changes:

• Intake trigger: any story/epic that creates or changes personal data processing must trigger a privacy design review.
• Design review output: documented decisions on minimization, access, retention, and sharing.
• Approval routing: DPO/privacy, security, and product owner sign-off for high-risk changes. (Regulation (EU) 2016/679, Article 25)

Practical gate language for engineering: “No production release if the data inventory entry is missing, default settings are not documented, or retention controls are not implemented.”

3) Define “by default” settings as enforceable configuration standards

Translate “by default” into configuration requirements you can test:

• Collection defaults: only required fields are mandatory; optional fields are clearly optional and off by default where feasible.
• Access defaults: least privilege roles; restrict broad access groups; default deny on new datasets until classified.
• Sharing defaults: no external sharing, no onward transfers, no marketing reuse unless explicitly enabled with a documented purpose.
• Retention defaults: deletion or anonymization is the standard path; exceptions require justification and approval. (Regulation (EU) 2016/679, Article 25)

How to operationalize: convert these into baseline configuration templates (IAM role templates, dataset policy templates, logging defaults, CI/CD checks).

4) Select technical and organizational measures proportional to risk

Article 25 names “pseudonymisation” as an example measure; treat it as a menu item, not the only option. Build a risk-to-control mapping that connects processing risk to control strength:

• higher-risk processing → stronger access controls, stronger data separation, stronger review and monitoring, and more restrictive defaults
• lower-risk processing → lighter measures, still documented (Regulation (EU) 2016/679, Article 25)

Decision discipline: document why a measure is “state of the art” and feasible given cost and context, in a way a non-engineer auditor can follow. (Regulation (EU) 2016/679, Article 25)

5) Make it repeatable with an operating procedure (runbook)

Create a requirement-specific operating procedure with:

• owners (privacy, security, engineering, product)
• triggers (new system, new integration, new data category, new purpose, major architecture change)
• required approvals
• required evidence packet contents
• exception process with expiration and remediation ownership (Regulation (EU) 2016/679, Article 25)

This is where teams usually fail: they have a privacy policy, but no operational runbook that forces consistent execution.

6) Build your “evidence packet” and keep it current

Retain auditable evidence packets on a recurring cadence:

• role-and-scope register entries (current version + history)
• design review checklist and outcomes
• architecture/data flow diagrams for in-scope systems
• default-setting screenshots/config exports (what is actually configured)
• access control reviews for sensitive datasets/systems
• retention schedules and deletion job logs (or tickets proving execution)
• exception approvals and remediation tickets with closure evidence (Regulation (EU) 2016/679, Article 25)

Daydream fit (earned, not forced): many teams track these artifacts across Jira, Confluence, cloud consoles, and spreadsheets. Daydream becomes useful when you need a single place to define the operating procedure, assign owners and triggers, and generate a consistent evidence packet for Article 25 without rebuilding the audit binder each quarter.

Required evidence and artifacts to retain (minimum viable set)

Artifact	Owner	What “good” looks like
Role-and-scope register	Privacy/GRC	Every material processing activity has role, purpose, data categories, systems, and third parties documented. (Regulation (EU) 2016/679, Article 25)
Privacy-by-design review record	Product/Engineering + Privacy	Shows design choices for minimization, access, retention, and defaults, with approvals. (Regulation (EU) 2016/679, Article 25)
Default configuration standard	Security/Engineering	Written baseline plus proof it’s implemented (templates, policy-as-code, screenshots). (Regulation (EU) 2016/679, Article 25)
Exception register	GRC	Lists exceptions, approver, scope, expiry, and remediation plan. (Regulation (EU) 2016/679, Article 25)
Evidence packet repository	GRC/Privacy	Easy retrieval per system/processing activity; includes history and change rationale. (Regulation (EU) 2016/679, Article 25)

Common exam/audit questions and hangups

Expect questions like:

• “Show me where privacy requirements are applied during design, not after release.” (Regulation (EU) 2016/679, Article 25)
• “What are your default settings for collection, retention, access, and sharing in System X?” (Regulation (EU) 2016/679, Article 25)
• “How do you decide what measures are appropriate given risk and ‘state of the art’?” (Regulation (EU) 2016/679, Article 25)
• “Provide evidence that defaults are enforced in production, not just documented.” (Regulation (EU) 2016/679, Article 25)
• “How do third parties affect the means of processing, and how did you evaluate the impact on defaults?” (Regulation (EU) 2016/679, Article 25)

Hangup to plan for: teams can describe good intentions but cannot produce configuration evidence (IAM policies, tenant settings, dataset policies) that matches the narrative.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating Article 25 as a privacy policy statement.
   Fix: implement SDLC gates and make approvals and artifacts mandatory for release. (Regulation (EU) 2016/679, Article 25)

2. Mistake: Defaults are permissive because “customers can opt out later.”
   Fix: define safe defaults first, then build opt-in paths with documented purpose and access controls. (Regulation (EU) 2016/679, Article 25)

3. Mistake: No clear controller/processor call.
   Fix: maintain the role-and-scope register and require role confirmation in intake workflows. (Regulation (EU) 2016/679, Article 25)

4. Mistake: No exception discipline.
   Fix: create an exception register with expiry and remediation tracking; review exceptions as part of governance. (Regulation (EU) 2016/679, Article 25)

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this page, so this guidance avoids case-specific claims.

Practically, Article 25 failures create two recurring risk patterns:

• Over-collection and uncontrolled reuse: personal data appears in more places than intended, making data subject rights execution and breach response harder to control. (Regulation (EU) 2016/679, Article 25)
• Weak defensibility: you cannot show that measures were selected with risk, state of the art, and cost in mind, which weakens your posture during regulator questions and enterprise customer diligence. (Regulation (EU) 2016/679, Article 25)

Practical execution plan (30/60/90-day)

A “day-based” plan is useful for operators, but timelines depend on your environment and aren’t mandated by the text. Treat these phases as a sequencing guide aligned to Article 25’s design-time and run-time expectations. (Regulation (EU) 2016/679, Article 25)

First 30 days (Immediate stabilization)

• Stand up the role-and-scope register and populate it for your highest-impact systems and products. (Regulation (EU) 2016/679, Article 25)
• Publish a one-page Article 25 operating procedure: triggers, owners, required approvals, required evidence. (Regulation (EU) 2016/679, Article 25)
• Define minimum default standards for access and retention that teams must follow while you mature the program. (Regulation (EU) 2016/679, Article 25)

Days 31–60 (Embed controls into how work happens)

• Add privacy-by-design steps into SDLC: intake form fields, Jira templates, architecture review checklists, and release criteria. (Regulation (EU) 2016/679, Article 25)
• Implement at least one technical enforcement mechanism for defaults (policy-as-code checks, baseline IAM templates, dataset access gates). (Regulation (EU) 2016/679, Article 25)
• Create an exception workflow with expiry and remediation ownership. (Regulation (EU) 2016/679, Article 25)

Days 61–90 (Evidence hardening and audit readiness)

• Standardize the evidence packet format per system/processing activity; run a mock audit and test retrieval speed. (Regulation (EU) 2016/679, Article 25)
• Close gaps between documented defaults and actual production settings (this is where most findings live). (Regulation (EU) 2016/679, Article 25)
• Operationalize a recurring review of high-risk processing changes and exceptions, with tracked remediation. (Regulation (EU) 2016/679, Article 25)

Frequently Asked Questions

Do we need pseudonymisation to comply with Article 25?

Article 25 lists pseudonymisation as an example of an appropriate measure, not a universal mandate. Your obligation is to select technical and organizational measures appropriate to your processing risks and implement them at design time and during processing. (Regulation (EU) 2016/679, Article 25)

What does “by default” mean for a SaaS product’s settings?

Defaults should limit collection, access, retention, and sharing to what is necessary for the stated purpose. Document the baseline configuration and keep evidence (tenant settings exports, screenshots, policy-as-code outputs) that proves the defaults are enforced. (Regulation (EU) 2016/679, Article 25)

Does Article 25 apply if we only act as a processor?

Article 25 places the explicit obligation on controllers in the text excerpt provided. Even as a processor, you will often be asked by customers to demonstrate privacy-by-design behaviors, so implementing similar gates and evidence is still operationally useful. (Regulation (EU) 2016/679, Article 25)

What triggers a “design time” review in practice?

Trigger on any change that affects purposes, data categories, data subjects, recipients, retention, or system architecture for personal data processing. Put the trigger in your SDLC intake so it happens before build decisions become expensive to unwind. (Regulation (EU) 2016/679, Article 25)

What’s the minimum evidence we should be able to produce in an audit?

Produce a role-and-scope record, a design review decision log, proof of default settings in production, an exception log, and remediation records for any identified gaps. Keep them organized per system or processing activity so retrieval is fast. (Regulation (EU) 2016/679, Article 25)

How do we keep Article 25 from becoming a blocker for engineering teams?

Make the requirements concrete and automatable: templates, checklists, and pre-approved patterns. Treat exceptions as time-bound with clear owners, so teams can move forward while risk is visible and managed. (Regulation (EU) 2016/679, Article 25)