Article 25: Data protection by design and by default

GDPR Article 25 requires you, as a controller, to build privacy controls into systems and processes from the earliest design decisions and to ship products with privacy-protective defaults. Operationalize it by embedding privacy requirements into intake, architecture, SDLC, and change management, then retain evidence that defaults, minimization, access controls, and retention limits are enforced in production. ¹

Key takeaways:

• You must implement technical and organizational measures at design time and during processing, proportionate to risk and “state of the art.” ¹
• “By default” means only necessary personal data is processed for each purpose, with strict default settings for amount, scope, access, storage period, and disclosure. ¹
• Regulators and customers will ask for operating evidence, not policy statements. Build an auditable trail from design decisions to production settings. ¹

Article 25 is the GDPR’s engineering and operations test: can you prove that privacy requirements are part of how you design, build, configure, and run systems that process personal data? The requirement has two linked obligations. “Data protection by design” focuses on embedding controls into the determination of the means of processing (product requirements, architecture, vendor selection, and system configuration) and into processing itself (how the system operates day to day). “Data protection by default” focuses on outcomes in production: only the personal data necessary for a specific purpose should be processed, and default settings should limit collection, access, storage duration, and disclosure. ¹

For a CCO or GRC lead, the fastest path is to convert Article 25 into an operating procedure that triggers on real events: new products, new data uses, new third parties, material system changes, and new analytics/AI features. Pair the procedure with a small set of “non-negotiable defaults” (for example: data minimization, least privilege, retention limits, secure defaults) and an evidence packet you can reproduce on demand.

Regulatory text

What the law says (operator-relevant excerpt): Article 25(1) requires the controller to implement appropriate technical and organizational measures, taking into account the state of the art, cost of implementation, the nature/scope/context/purposes of processing, and risks to individuals. These measures must be implemented both when determining the means of processing and during processing itself, and may include measures such as pseudonymisation. ¹

What you must do with it (practical interpretation):

• Treat privacy controls as design inputs, not after-the-fact remediation.
• Make design choices based on risk to individuals, balanced with state of the art and implementation cost.
• Ensure production defaults restrict processing to what is necessary for each purpose and limit access and exposure by default. ¹

Plain-English interpretation (what Article 25 requires)

Article 25 requires two things you must be able to demonstrate:

1. Privacy by design: before you build or buy, you decide how the processing will work and you bake in measures that reduce risk to individuals (for example: pseudonymisation, strong access controls, segregation, logging, deletion workflows). Then you keep those measures effective during normal operations and changes. ¹

2. Privacy by default: the default configuration of your product/service and internal systems must be privacy-protective. If a user, admin, or operator takes no extra action, the system should still process only the personal data needed for the stated purpose, limit who can access it, limit how long it is stored, and limit when it is exposed externally. ¹

Who it applies to

Primary obligated party: controllers. Article 25 is addressed to the controller, including controllers that build software, operate platforms, run HR/customer systems, or deploy analytics. ¹

Operational contexts where it shows up in audits and customer diligence:

• Product development and feature launches (especially new tracking, profiling, personalization, or data sharing).
• Data platform changes (new pipelines, new warehouses, new identity resolution).
• Security and IT operations (IAM, logging, backups, retention, access reviews).
• Third-party onboarding and integrations (SDKs, analytics tools, support tools, payment providers) where your configuration choices create default disclosures.

Practical scoping rule: if a system processes personal data and you can influence design, configuration, or defaults, Article 25 is in scope. ¹

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

Step 1: Establish role and scope for each processing area

Create and maintain a register that maps:

• Controller vs. processor role ¹
• Purposes of processing
• Personal data categories and affected systems
• Key third parties and data flows

This prevents teams from building “default” settings that conflict with your role or declared purposes. ¹

Step 2: Convert Article 25 into an operating procedure with triggers

Write a short procedure that answers:

• Trigger events: new product/feature, new data category, new purpose, new integration/third party, material configuration change, new region, or new analytics/AI use case.
• Required reviews: privacy review (and DPIA where applicable under your program), security architecture review, data retention review, and legal/compliance sign-off for high-risk changes.
• Decision rights: who can approve exceptions to defaults, and who can accept residual risk.

Make the procedure the gate for release and change management, not an optional checklist. ¹

Step 3: Define “privacy by default” configuration standards you can test

Document default standards that engineering can implement and QA can verify, such as:

• Default collection off unless necessary for the purpose
• Default sharing off unless required (including third-party SDK toggles)
• Least-privilege roles by default, with separation of duties for admin functions
• Default retention limits and deletion workflows (including backups where feasible)
• Default logging that supports accountability without excessive data capture

Tie each standard to a control owner and an automated or testable control where possible. ¹

Step 4: Embed design controls into SDLC and architecture

Operationalize “by design” with concrete integration points:

• Product requirements: require a “purpose + data needed” statement for each feature.
• Architecture review: require a data flow diagram and a control mapping (pseudonymisation/segregation/access controls).
• Secure configuration: baseline templates for storage, queues, and analytics with privacy defaults pre-set.
• Change management: any change affecting data categories, access paths, retention, or sharing must re-run the Article 25 check.

This is where “state of the art” becomes measurable: you pick modern controls your org can sustain, and you show consistency across systems. ¹

Step 5: Prove it in production (continuous control)

Build an evidence routine that answers: “Are defaults still in place after deployments and exceptions?”

• Periodic configuration attestations for key systems (IAM policies, data sharing toggles, retention policies).
• Exception register with approvals, expiry dates, and compensating controls.
• Testing artifacts (pre-release tests that confirm defaults, plus post-release monitoring where available).

Step 6: Vendor and third-party integration controls (where defaults often fail)

For third parties that receive data through default settings (support tooling, analytics, marketing tags):

• Require documented default settings at onboarding.
• Require a configuration review before enabling data sharing.
• Keep a record of what data is shared by default and why it is necessary for the purpose. ¹

Where Daydream fits naturally: Daydream can act as the system of record for the Article 25 operating procedure, linking each processing area to required reviews, owners, approvals, exceptions, and recurring evidence packets. That reduces scramble during customer diligence and supervisory inquiries because the “design decision trail” is already assembled.

Required evidence and artifacts to retain (auditable packet)

Keep artifacts tied to each trigger event and to steady-state operations:

• Role-and-scope register (controller/processor position, purposes, data categories, systems)
• Article 25 operating procedure with owners, triggers, approvals, and exception handling
• Design review evidence: requirements notes (purpose/data needed), architecture review record, data flow diagram
• Default configuration evidence: baseline configs, screenshots/exports of settings, infrastructure-as-code templates
• Testing evidence: test cases validating defaults; release sign-off
• Exception register: rationale, approvals, compensating controls, and closure evidence
• Recurring evidence packets: periodic exports/reports showing access controls, retention settings, and sharing controls remain in place

Regulators and enterprise customers tend to accept practical evidence even when controls differ by system, as long as the decision logic is consistent and risk-based. ¹

Common exam/audit questions and hangups

Expect auditors, DPAs, and customer assessors to ask:

• Show how privacy requirements are enforced before release (not after incidents). ¹
• What are your privacy-protective defaults for collection, sharing, access, and retention?
• How do you prevent teams from turning on broad collection “temporarily” and never reverting?
• How do you assess “state of the art” and decide what is appropriate given risk and cost? ¹
• How do you ensure defaults remain intact after changes, migrations, and new integrations?

Hangups usually come from missing linkage: policy exists, but there is no traceable path from a feature request to a production configuration and ongoing monitoring.

Frequent implementation mistakes (and how to avoid them)

• Mistake: treating Article 25 as a policy statement. Fix: make it a release and change-management gate with mandatory artifacts.
• Mistake: “defaults” defined only for end-user UI. Fix: include backend defaults (APIs, logs, exports, admin roles, third-party SDK toggles).
• Mistake: no exception discipline. Fix: require time-bound exceptions, named approvers, and compensating controls, then track closure.
• Mistake: relying on one-time privacy reviews. Fix: add recurring evidence pulls for high-impact systems so you can show continued operation “at the time of processing.” ¹
• Mistake: ignoring third-party defaults. Fix: treat third-party data sharing as a design choice; document and test default data flows.

Enforcement context and risk implications

No public enforcement case references were provided in the supplied source catalog, so this page avoids naming specific matters. What Article 25 changes in practice is your defensibility: if an incident, complaint, or investigation occurs, you will be asked to show that you considered risk to individuals and implemented appropriate measures at design time and in live operations. Weak evidence often converts a technical gap into a governance failure. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize and scope)

• Stand up the role-and-scope register for your highest-impact systems (customer data platform, core product databases, HR systems).
• Publish the Article 25 operating procedure with clear triggers, owners, and approval paths. ¹
• Define your privacy-by-default baseline standards (collection, sharing, access, retention) and identify where you can enforce them through templates.

Days 31–60 (embed into delivery and change)

• Integrate the Article 25 procedure into SDLC: product intake, architecture review, and release approvals.
• Create evidence packet templates for each trigger event (so teams produce consistent artifacts).
• Implement an exception register and start capturing existing deviations from defaults with remediation plans.

Days 61–90 (prove operation and close gaps)

• Run targeted configuration reviews of priority systems and third-party integrations to confirm defaults are actually set in production.
• Add recurring evidence collection for critical controls (access, retention, sharing toggles).
• Use findings to harden templates and guardrails so teams cannot ship non-default privacy settings without explicit approval. ¹

Frequently Asked Questions

Does Article 25 apply if we already have “privacy by design” language in policy?

Policy language helps, but Article 25 expects operational measures at design time and during processing. You need traceable evidence from requirements and architecture decisions to production defaults and ongoing control operation. ¹

What does “by default” mean for internal tools, not a customer-facing product?

“By default” still applies to how your systems process personal data: access, retention, disclosure paths, and the amount of data collected should be limited to what is necessary for each purpose. Document and test the default configurations the same way you would for product settings. ¹

How do we show we considered “state of the art” without writing a thesis?

Keep a short decision record that names the measures you chose (for example, pseudonymisation, least privilege, segregation) and why they are appropriate given the risks and your environment. Pair it with proof the measures exist in production configurations. ¹

Can we allow broader data collection if users opt in?

Article 25 focuses on defaults and necessity for each purpose. If you expand collection, document the purpose, the user choice mechanism, and how the system behaves when no action is taken (the default state). ¹

Where does the DPO fit in Article 25 execution?

Article 25 does not prescribe a specific org chart, but you should assign clear owners for design reviews, approvals, and exceptions. In practice, the DPO or privacy function often reviews high-risk changes and confirms defaults align with declared purposes. ¹

What evidence do customers typically request in a due diligence review?

Expect requests for your privacy-by-design process, examples of completed design reviews, default configuration standards, and proof of ongoing access/retention controls. An organized evidence packet per system or per product line reduces friction. ¹

Footnotes

1. Regulation (EU) 2016/679, Article 25