GDPR Article 25 data protection by design and by default

What GDPR Article 25 asks of existing systems as well as new ones

Article 25 applies to systems that were built before the GDPR, not only to new builds. If you are the compliance lead or engineer who must show that a system protects personal data by design and by default, the question is not whether the platform was designed under GDPR principles. The question is whether the controller has taken appropriate technical and organisational measures, such as pseudonymisation, that put data minimisation and the other principles into the means of processing and into the processing itself, and whether the defaults limit what is collected, how far it is used, how long it is kept and who can reach it. The EDPB's Guidelines 4/2019 (version 2.0, adopted 20 October 2020) say the duty applies to all controllers regardless of size and requires regular review of whether the chosen measures remain effective.

That review duty is what makes existing systems hard to evidence. A legacy application may collect fields nobody needs, keep backups and logs indefinitely, or grant broad read access because a role was copied years ago. Each of those is a default that may have been set long before anyone asked whether it met Article 25(2). Start by inventorying the settings that control collection, retention, access and sharing, then record for each one the purpose it serves, the owner who can change it and the date it was last reviewed. Where a default exposes more data than a specific purpose needs, the change is a decision you must document, not a configuration tweak you can leave undocumented.

The risk is real money: Article 83 sets maximum administrative fines of EUR 10 million or 2% of total worldwide annual turnover for infringements of obligations such as Article 25, whichever is higher, and Article 83(2)(d) makes the measures taken under Article 25 a factor in deciding any fine. The GDPR requires no audit, attestation or certificate for this. An approved certification under Article 42 may be used as an element of evidence, but it is voluntary and does not transfer responsibility from the controller. Confirm with your supervisory authority or legal counsel which records they expect to see, and bring an independent assessor in only where the scope or the risk justifies it.

Which systems, data and teams fall under Article 25 scope

Article 25 applies to every controller and reaches the systems that already process personal data, not only new builds. The cards below cover the scoping decisions that most change the work, from legacy systems and new features to internal tools and the processors the controller relies on.

Legacy systems built before the GDPR

The EDPB's Guidelines 4/2019 state that the obligation also covers systems that existed before the GDPR applied. Start by inventorying every system that stores or processes personal data, including older databases, batch jobs and archives that nobody has reviewed since 2018. Each one needs a documented check against minimisation, default retention and access limits. Effort depends on how much of the legacy estate can be changed versus how much must be wrapped with compensating controls, so confirm which systems the organization can still modify.

New product features and data fields

Each new feature that collects a field, extends a purpose or widens who can see a record is a design decision under Article 25. Check whether the feature collects only what its stated purpose needs, whether optional fields are off by default, and whether the data is shared beyond the team that asked for it. Making this review a required step in the product approval process usually costs less than retrofitting a feature after release.

Internal tools and analytics copies

Internal dashboards, exports, spreadsheets and analytics copies are often outside the production scope but still hold personal data. Article 25(2) concerns accessibility, so an internal tool that exposes records to every employee can fail the default test even when the main application passes. Confirm which internal stores hold personal data, who can reach them, and whether copies are kept longer than the source system.

Processors and sub-processors

The controller remains responsible for data protection by design and by default in processing carried out by its processors and sub-processors, and the EDPB expects this to be considered at contracting. Before signing, ask each provider how it limits collection, sets retention and restricts staff access, and whether it requires your instruction before adding a sub-processor. Expect longer procurement reviews for hosting, support and SaaS tools that touch personal data.

Engineering and CI pipelines

Repository and pipeline controls determine whether privacy-protective changes can be reviewed and reverted. Protected branches restrict who can push or merge, and disabling force pushes keeps the change history intact for review. Static analysis in CI can flag code that logs personal data or writes it to unapproved locations. Ask engineering to show which branches and pipelines are protected, since these controls shape how much manual review each release needs.

Procurement, product and data teams

Article 25 work is shared. Product owners set purpose and collection, data teams decide retention and aggregation, engineers implement defaults, and procurement negotiates processor terms. A single owner should maintain the scope register and sign off changes that alter collection, extent, retention or access. Ask each team which decisions they control today, because gaps between teams are where defaults usually go unreviewed.

How an assessor tests privacy by design and by default

This table compares each test an assessor or supervisory authority typically runs against Article 25, the evidence requested for it and the findings that appear most often. Read it as a checklist for preparing your own assurance file, since no certificate is issued for this requirement and the controller owns the result.

Test area	Evidence requested	Common findings
Design decisions	Dated design records showing how data minimisation and pseudonymisation were considered before build, and who approved them	Decisions exist only as informal chat or tickets with no record of the privacy analysis
Default configuration	Exports of collection fields, retention settings and access scope for each system, compared against the stated purpose	Optional fields collected by default, or retention set to indefinite because no value was chosen
Access scope by default	Role definitions, access grants and a sample of accounts showing personal data is not open to an indefinite number of people without intervention	Broad read access granted to whole teams or all staff as the default role
Retention defaults	Retention schedule mapped to each data store, with deletion job configuration and run logs	Schedule exists on paper, but no automated or scheduled deletion runs for some stores
Regular review	Change records, review minutes and effectiveness checks for measures, covering systems that predate the GDPR	No review cycle for legacy systems, or reviews that do not test whether the measures still work
Processor and sub-processor contracts	Contract clauses and due diligence records showing privacy by design and by default was considered when selecting processors	Contracts silent on default settings, or hosting vendors whose defaults were never assessed
Pre-existing systems	Gap analysis and remediation plan for systems built before the GDPR applied	Legacy systems carried forward without any documented assessment

How to implement Article 25 in a system that already runs

This sequence takes an existing system from an unexamined state to one where privacy-protective defaults, retention and access limits, and change controls are documented, enforced and reviewed on a schedule, with evidence the controller can show a supervisory authority.

Inventory processing purposes and data flows
Start by listing every purpose for which the system processes personal data, the data elements collected for each purpose, where they are stored, which internal teams and processors touch them, and which sub-processors sit behind each service. The system owner and the privacy lead do this together, because engineers rarely know the purpose behind every field. The output is a processing inventory that ties each data element to a stated purpose. The step is complete when someone outside the build team can trace any stored field back to a purpose and an owner.
Compare each data element against its purpose
For each data element, ask whether the specific purpose needs it, how much of it is needed, how long it must persist and who must be able to see it. Mark every element that exceeds its purpose, such as full dates of birth held for an age check, free-text fields retained indefinitely, or support staff with read access to the whole customer table. The privacy lead records the result in an exceptions list with a proposed change for each item. The step closes when every exceeding element has a decision: remove, reduce, pseudonymize, or document a justified reason to keep it.
Set privacy-protective defaults and pseudonymization
Change default configuration so that new records collect only the required fields, optional fields are off unless a user opts in, sharing and public visibility are restricted, and analytics identifiers are pseudonymized where the purpose allows it. Where pseudonymization is used, document the separation of the key or mapping table and who can access it. The output is a default-settings register listing each setting, its previous value, its new value, the purpose it serves and the approver. The step is done when the register is signed off and the configuration in each environment matches it.
Define retention and access limits in configuration
Translate the retention decisions into enforceable rules: a storage period for each data category, automated deletion or anonymization at expiry, and role-based access limits that grant each role only the data it needs for its tasks. Confirm with the system owner that deletion jobs also reach backups, logs and replicas, or that the restore process respects expiry. The output is a retention schedule linked to configuration and an access matrix by role. The step is complete when test accounts in each role show only the permitted data and a test record reaches its deletion date and is removed as documented.
Create a configuration baseline and monitor drift
Record the approved settings as a configuration baseline in version control, so every change to a default, retention rule or access role is visible and attributable. Use a policy-based scanner or configuration assessment tool to check deployed infrastructure against the baseline, and use endpoint or device policy tooling where administrators work from managed devices. The output is the baseline file, the scanning policy, and a report of current pass and fail results. The step is complete when a deliberate change to a protected setting produces a finding that the team must resolve.
Embed privacy review gates in change management
Add a data protection review to the change process for any change that adds a data element, a new purpose, a new recipient, a new processor or a new storage location. Protect the main branch so that changes cannot reach production without review by a named approver, and require the privacy lead to sign off on changes that affect the processing inventory. Static analysis in the pipeline can flag new logging of sensitive fields or hard-coded identifiers as an early signal. The output is a change record template with a privacy checkbox and an approval log. The step is complete when a test change touching personal data cannot merge without that review.
Schedule effectiveness reviews and keep the record
Article 25 requires regular review of whether the chosen measures remain effective, so set a review cycle for each system, agreed by the controller's governance body and written into the policy. Each review re-checks the inventory, samples default settings, tests retention deletion and access rights, reviews drift reports and open exceptions, and records any corrective action with an owner. The output is a dated review record per system. The organization should confirm its own review frequency with its data protection officer or legal counsel, because the researched guidance does not fix one.

Evidence that shows privacy-protective defaults are working

Article 25 is tested by what a controller can show, not by what it intends. The artifacts below record how privacy decisions were made, which defaults are live, who can reach personal data, when it is deleted, and whether those settings still work after launch. Each card names the owner and the refresh habit that keeps the evidence current between audits.

Design review records

Written records of privacy design decisions made before a system, feature or data flow went live, including the data minimisation, pseudonymisation and access choices considered and the option chosen. Store them with the change request or architecture decision record so they are versioned with the system. Refresh them whenever a design changes materially, and check that each record names the reviewer who accepted the privacy risk. The product or engineering lead usually owns the record, with the DPO or privacy lead reviewing it.

Register of default settings

A register listing every default that governs personal data: fields collected at signup, optional fields, sharing toggles, logging levels, retention periods and visibility of records. Each entry needs the privacy-protective value, the reason for it and the approver. Article 25(2) asks that only data necessary for each purpose is processed by default, so an entry without a rationale is a gap. Review the register at each release and when a new feature adds a field or a sharing option. Product owners maintain it, with the privacy lead approving changes.

Configuration baselines

Versioned baseline configurations for servers, containers, databases and SaaS tenants that hold personal data, showing the hardened state that deployments must match. Checks should confirm that public access is off, that verbose logging of personal data is disabled and that encryption is enabled. Scanning tools such as Wazuh Security Configuration Assessment can compare live hosts to YAML policies and report drift with remediation steps. The platform or infrastructure team owns the baselines and the scan results are reviewed by the security team.

Access role definitions

Documented roles that define who may view, change or export personal data, with the purpose each role serves and the data it can reach. Article 25(2) requires that data are not made accessible to an indefinite number of people without the individual's intervention, so the role matrix should show least privilege and the names of groups granted each role. Export the current group memberships at each access review and record removals. The identity or IT administrator owns the matrix, and the data owner approves each role.

Retention settings and deletion logs

Configured retention periods for each category of personal data, the automated jobs that enforce them and the logs proving deletions ran. Article 25(2) names the storage period as one of the defaults to limit, so a retention schedule with no working deletion job is weak evidence. Check that backups and logs follow the same schedule or have a documented exception. Records should show what was deleted, when and by which job, without retaining the deleted personal data itself. The system owner runs the jobs, and the privacy lead signs off on the schedule.

Pseudonymisation design notes

Design notes that explain where pseudonymisation applies, which identifiers are replaced, where the mapping key is stored and who can reverse the mapping. Article 25(1) names pseudonymisation as an example of an appropriate measure, so the notes should state the purpose, the technique and the separation between the key and the pseudonymised dataset. Record the reason when a dataset stays identifiable. The security architect owns the notes and should revisit them when analytics or export paths change.

Periodic effectiveness review records

Dated records of reviews that test whether the chosen measures still work, as EDPB Guidelines 4/2019 expect from controllers that must review effectiveness regularly. Each record should list the defaults tested, the method used, the findings and the actions with owners. Include findings from security testing and from scans of code and endpoints where they cover personal data handling. Set the review cadence in the policy and confirm the date of the last review with the DPO. The privacy lead or DPO owns the record, with system owners responding to findings.

Which self-hosted open-source tools produce supporting evidence

Article 25 asks that privacy principles are built into how systems are designed and changed, so one useful source of evidence is the record of who was allowed to change production code and whether that record was enforced. Self-hosted code platforms and static analysis tools can show that changes to data handling logic went through a controlled path. They do not show that the resulting defaults are privacy-protective, which requires review of the design itself.

Protected branches in GitLab Community Edition: The MIT-licensed edition lets maintainers restrict which roles can push or merge to a branch, block direct pushes by setting push access to no one, and keep force pushes disabled unless explicitly allowed. Exported settings give an assessor a concrete record of the rule in force.
Semgrep Community Edition in CI/CD: The LGPL-2.1-only edition scans code in languages including Python, Java, JavaScript, TypeScript and Terraform with community or custom rules. Custom rules can flag patterns such as logging of personal fields or unencrypted storage resources.
Continuous scanning evidence: Pipeline logs and scan results over time show that checks ran on each change, not only at release.
Infrastructure as code review: Terraform scanning output can show whether storage defaults, such as public access settings, were set in code before deployment.

Confirm the license terms of each edition against your own distribution and internal use before relying on them in a contract or audit pack.

What meeting Article 25 costs in money and effort

This table breaks down the cost components of meeting Article 25 and shows who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a written quote and to compare how each component scales across your systems. No prices or durations are given because none are supplied for this topic, so ask each provider to state their assumptions.

Cost component	Who is paid	One-time or recurring	What drives it up or down
Tooling and licenses	Tool vendors or a hosting provider, if any	Recurring for hosting and support; the named open-source tools carry no license fee under their stated licenses	Number of repositories, code languages scanned, endpoints monitored and hosting footprint
Engineering time for defaults and data reduction	Internal engineers or an implementation partner	One-time for the initial review, recurring for each change to collection, retention or access	System age, number of data elements, and how many features collect data that is not needed for the stated purpose
Privacy engineering review of existing systems	Internal privacy team, consultant or implementation partner	One-time for legacy systems, then recurring as part of design reviews	Number of legacy systems, documentation quality and whether data flows are already mapped
Evidence upkeep	Internal compliance staff or an implementation partner	Recurring, tied to release cycles and periodic review of measures	Change frequency, number of owners for each system, and whether evidence is generated automatically in CI/CD and device management
Processor and sub-processor review	Internal legal or procurement staff	Recurring, at onboarding of each processor and when sub-processors change	Processor count, number of sub-processors and how often contract terms change
External review or assessor time	Independent auditor, assessor or consultant, if engaged	Recurring when a review or certification cycle is scheduled	Scope of systems reviewed, whether Article 42 certification is pursued, and readiness of evidence at the start
Staff training on privacy by design	Internal training team or external trainer	Recurring for onboarding and refresher sessions	Headcount of engineers and product staff and turnover rate

Where organizations fall short on Article 25 and how to close the gap

Most Article 25 gaps are not missing policies. They are product defaults, legacy data and access settings that quietly collect, keep and expose more personal data than each purpose needs. The cards below cover the gaps assessors see most often, why they are flagged, and what to change.

Optional fields collected by default

Sign-up forms, support tickets and profile screens often request fields the stated purpose never needs, such as date of birth, phone number or employer. Article 25(2) requires that by default only the personal data necessary for each specific purpose is collected. An assessor will ask who decided the field was required and where that decision is recorded. Check each form and API payload against a written purpose, make non-essential fields opt-in, and confirm that defaults in configuration files match the intended design.

Undefined retention for legacy data

Databases and file stores built before the GDPR often hold records with no retention period, sometimes going back many years. Article 25 applies to systems that existed before the GDPR, and the EDPB guidelines expect the controller to take the storage period into account by default. Assessors look for a retention rule per data category and evidence that old records were purged or justified. Inventory legacy stores, assign each dataset a period tied to its purpose, and schedule deletion jobs that can be shown to run.

Broad access granted to whole teams

Access to customer records is often granted to an entire department or to a shared service account because it is simpler than role design. Article 25(2) requires that personal data is not made accessible to an indefinite number of people without the individual's intervention. Assessors test whether access follows documented roles and whether access reviews happen. Replace shared accounts with named roles, scope read access to the minimum dataset, and keep the access review evidence with the role definitions.

No record of design decisions

Teams make choices about pseudonymisation, field-level encryption, default retention and data sharing during sprints, and the reasoning rarely survives. Article 25(1) asks the controller to consider the state of the art and the cost of implementation when choosing measures, and an assessor cannot test a decision that was never written down. Keep short design records for each feature that processes personal data, listing the purpose, the defaults chosen and the alternatives rejected. Link these records to the release that shipped them.

Processor contracts that ignore privacy defaults

Hosting providers, SaaS tools and sub-processors are often configured with vendor defaults, such as public storage buckets, extended log retention or analytics switched on. The EDPB guidelines make the controller responsible for data protection by design and by default in processing carried out by processors and sub-processors, and expect this to be considered when contracting. Assessors compare the contract's instructions with the vendor's actual configuration. Write required default settings into the processing agreement, and ask each processor to confirm them in writing after onboarding.

No scheduled effectiveness review

Measures are chosen at launch and then left alone, even as data volumes, features and integrations change. The EDPB guidelines require regular review of the effectiveness of the chosen measures and safeguards, and Article 83(2)(d) treats Article 25 measures as a factor when fines are set. Assessors ask for the review calendar, the last review record and the changes it produced. Set a recurring review per system, record its findings, and track each finding to closure.

Who does what: your team, an implementation partner and the auditor

The controller remains accountable for Article 25. Only the controller can decide why personal data is processed, which categories are necessary for each purpose, how long data is kept and who should be able to see it. Those decisions cannot be delegated to a vendor, and a partner cannot make them on the controller's behalf. Under Article 25, the EDPB guidelines also expect the controller to review whether chosen measures remain effective over time, including on systems that predate the GDPR.

Processing decisions: Set the purposes, lawful basis and data categories for each system, and record them in the record of processing.
Default approval: Sign off on retention periods, default access groups and which fields are collected by default.
Design review: Decide when a change to a system triggers a privacy review before release.
Processor oversight: Assess processors and sub-processors for their own design choices when contracting.
Accountability records: Keep the decisions, approvals and review dates that show the measures are maintained.

Check that someone named in the organization owns each decision, and that the approvals are dated and retrievable without the partner.

Questions buyers ask before bringing in outside help for Article 25

How much effort does Article 25 work take, and what drives it?

The effort depends mostly on how many systems process personal data, how well their data flows are documented, and how much of the existing design has to change. Article 25 applies to all controllers regardless of size, and the EDPB Guidelines 4/2019 state that it also covers systems that existed before the GDPR. A small internal tool with one data store and clear owners is a different job from a platform with dozens of integrations and third-party components. Other drivers include the number of data categories, whether special categories are involved, how many processors and sub-processors sit in the chain, and how mature the existing configuration management and logging are. Ask any provider to break its estimate down by system, not by project.

How long does Article 25 work take for a single system?

There is no supplied duration for this work, so treat any timeline as something to confirm against a written scope. In practice the timeline follows the same drivers as effort: the size of the system, the completeness of its data inventory, and the number of decisions that need sign-off from legal, product and security owners. A single system with an existing inventory and a clear owner usually moves faster than one where the data flows must be mapped from scratch. Ask for phases, what each phase delivers, and which steps depend on the client's staff being available.

What does the work need from our own staff?

The work needs named people who can make decisions, not just give access. Typically this includes a system owner who knows the purposes and retention needs, engineers who can change configuration and code, someone who can confirm the legal basis and retention periods, and a contact who can approve changes to defaults that affect users. Staff time is a real cost even when an outside partner does the technical work, because defaults such as which fields are collected or who can see a record are business decisions. Ask the provider to list each role, the hours it expects from that role, and the points where work waits on a client decision.

Can our in-house team implement Article 25 without outside help?

Yes, an in-house team can do this work if it has engineers who understand the system, a privacy lead who can make decisions about purpose and retention, and time to review the work regularly. Article 25 requires ongoing review of the effectiveness of measures, so the question is not only whether the team can build the changes but whether it can keep them working after each release. Outside help is most useful when the team lacks experience with pseudonymisation, configuration hardening or evidence collection, or when the same people are needed for product delivery. Compare the cost of the outside work against the staff time it would take to learn the same skills.

Do we need a certificate to show compliance with Article 25?

No. Article 25 does not require a certificate, audit or attestation. Article 42 certification is voluntary, is issued by accredited certification bodies or supervisory authorities for at most three years, and under Article 25(3) can only be used as an element to demonstrate compliance. It does not reduce the controller's responsibility. What the controller needs is documented decisions, configured systems and evidence that the chosen measures work and are reviewed. Any outside partner can prepare that evidence, but only an independent body issues a certificate, and no provider can promise a regulator's view.

What should we ask for in a written quote?

Ask for a written scope that lists each system, the data categories it processes, and the Article 25 measures to be designed or reviewed. The quote should separate one-time work, such as the initial assessment and configuration changes, from recurring work, such as periodic reviews, retesting after releases and evidence updates. Ask which deliverables are produced, who owns each one afterward, what the client must provide and by when, and how changes to scope are priced. Confirm the provider does not issue certificates or audit reports, and ask how it handles sub-processors that touch the client's data.

How DeployOpen scopes and prepares Article 25 evidence

DeployOpen plans, implements and documents privacy-protective design inside your own infrastructure, using self-hosted open-source platforms. We prepare the systems, settings and records an assessor would look at, while your organization keeps ownership of its processing decisions and controls.

How we scope

Agree in writing which systems, data flows and processing purposes the Article 25 work covers before any build starts.
Identify where your organization decides the means of processing, since that is where design-time measures are set.
Record the default settings to be reviewed, including collection fields, retention periods and who can access each dataset.
Engagements are fixed-scope, with deliverables and timelines confirmed in writing; ongoing support is available as a retainer.

How we build

Configure pseudonymisation and minimization in the chosen platforms so only fields needed for each purpose are collected.
Set restrictive defaults for access and retention, and confirm them against the scope document rather than assumptions.
Test the configured defaults with security tooling such as code scanning and endpoint configuration checks where they apply.
Confirm with your team which platform capabilities are available in the versions you deploy before relying on them.

How we hand over

Document each design decision, default setting and the reason it protects personal data, mapped to the agreed scope.
Provide configuration records, test results and change history that your DPO or assessor can review directly.
Deliver a review schedule describing when defaults and safeguards are rechecked as systems and processing change.
Final decisions on adequacy of measures remain with your organization and, where relevant, its independent auditor or certification body.

How we support

Offer retainers for ongoing review of defaults when new features, data fields or integrations are introduced.
Re-run configuration and security tests after upgrades, and update documentation to match the deployed state.
Support responses to supervisory authority questions by supplying the evidence already produced in the engagement.
Ask us to confirm how a retainer covers existing legacy systems, since Article 25 applies to systems that predate the GDPR.