Data protection by design and by default: test the starting state
A practical GDPR Article 25 guide to building privacy into product, vendor and workflow decisions, with the four default dimensions reviewers should test before launch.
A product team is ready to launch a new customer portal. The portal needs an email address to send account notices. The team also wants to collect a date of birth, keep detailed activity logs, enable vendor analytics, and make user profiles searchable by default.
The project plan says users can change these settings later.
The privacy review should ask a harder question: What will the system do before anyone changes a setting? That starting state is part of the controller's legal decision. A later preference screen cannot turn an unnecessary default into a necessary one.
Article 25 of the GDPR requires the controller to implement appropriate technical and organisational measures when deciding how processing will work and while the processing continues. Those measures must implement data-protection principles and safeguards effectively. Article 25(2) adds a concrete default rule: only personal data necessary for each specific purpose should be processed by default. The rule covers the amount collected, the extent of processing, the storage period and accessibility. 1
That is data protection by design and by default. It turns privacy from a late approval question into a property of the product, workflow, vendor configuration and operating process.
Two duties across one lifecycle
Data protection by design is the proactive part. The controller builds the GDPR principles and safeguards into the way processing is chosen and implemented. The relevant design decision can be broad, such as choosing a cloud service, or detailed, such as deciding whether a location field is mandatory, whether a log stores the full value, or whether a report exposes individual records.
The EDPB says the design obligation applies when the controller determines the means of processing. That includes architecture, procedures, protocols, layout and appearance, as well as procuring software, hardware and services. The obligation continues after launch. Controllers must review the effectiveness of their measures as the technology, processing context and risks change. The EDPB also applies that continuing review to processing carried out through processors. 2
Data protection by default is the limiting part. A default is the pre-existing or preselected configuration value in a system, service, device or manual procedure. The controller chooses that state and remains accountable for it. The EDPB says the default should carry out only processing strictly necessary for the specific, lawful purpose. 3
The distinction matters in a familiar product conversation. A team may offer a switch for targeted advertising, public profile visibility or precise location sharing. That choice can be available to the person. The initial state still needs its own necessity analysis. The product cannot collect extra data, run extra operations, keep the data longer or expose it more widely while waiting for the person to intervene.
Test the four default dimensions
Article 25(2) gives reviewers four places to look. The EDPB's 2026 summary uses the same four dimensions and gives practical examples such as removing an unnecessary date-of-birth field, separating location search from advertising, automating deletion or anonymisation, and restricting access to authorised people. 4
| Article 25 dimension | Question before launch | Default failure | Evidence of a working control |
|---|---|---|---|
| Amount collected | What fields, categories and level of detail does this purpose require? | A receipt form makes date of birth or a phone number mandatory when the purpose does not need either. 4 | The purpose map, field specification, required/optional state and a test showing the unnecessary field is not collected by default. |
| Extent of processing | Which operations will run on the data, and how often? | Location used to find the nearest store also feeds individual advertising without a separate decision. 4 | A processing-flow test showing which jobs, models, exports and recipients receive the data for each purpose. |
| Period of storage | When does this purpose stop needing the data? | The system stores detailed event history indefinitely because no expiry rule was designed. | An expiry rule, deletion or anonymisation job, exception record and test result. The EDPB links this default dimension to storage limitation and systematic deletion or anonymisation procedures. 3 |
| Accessibility | Who needs access, what type of access do they need, and when should a person intervene before publication? | A profile or dataset is searchable by an indefinite audience without the person's intervention. | Role-based access tests, publication controls, access logs and a test of the state before the person changes a privacy setting. 3 |
These dimensions prevent a narrow reading of minimisation. A team can collect only one field and still process it too widely. It can limit collection and still retain the result without an end point. It can set a short retention period and still expose the data to too many people. The default review follows the data through the whole path.
Build the decision screen before launch
A useful review record follows the order in which the system is designed. It should answer these questions before procurement, build or launch approval.
1. Define the purpose at the level of the processing
Start with a sentence that names the outcome the organisation needs. "Improve the customer experience" cannot decide whether the system may collect precise location, create a profile, train a model or share data with an advertising partner.
A workable purpose might be: "Send account notices to the customer who created the account." That purpose can justify an email address for the notice. It does not, by itself, justify retaining a date of birth, recording every click, or making the account searchable to the public.
Split distinct purposes before choosing settings. The EDPB says the controller must predetermine the specified, explicit and legitimate purposes and assess necessity against the particular processing. The controller should ask whether the purpose can be achieved with aggregated, anonymised or less granular information, then document why the chosen data and operations are needed. 3
Purpose also sets the boundary for later reuse. A field necessary for account notices does not become available for behavioural advertising because the same database already contains it. A new operation needs its own purpose, necessity and lawful-basis analysis before the system enables it.
2. Choose the means and safeguards together
Article 25(1) requires the controller to consider four factors when choosing measures: the state of the art, the cost of implementation, the nature, scope, context and purposes of processing, and the risks of varying likelihood and severity to people's rights and freedoms. 1
The EDPB treats cost as a real factor. A controller can choose a less resource-intensive measure when it provides equal protection. Cost does not justify a measure that leaves the processing in breach. The comparison must therefore ask what each option does for the specific rights risks, rather than comparing purchase prices alone. 3
The safeguard should have an owner and an enforcement point. "Limit access" needs a role model, an approval path, a revocation process and a test. "Delete after the purpose ends" needs an expiry event, a job or manual procedure, an exception path and evidence that the result was checked. "Give users control" needs a screen, a state transition and a downstream propagation test.
This is where design becomes more than a privacy requirement in a ticket. The requirement must change a field, job, permission, interface, data flow or operational decision.
3. Set the least intrusive state as the starting state
The system should begin with the processing that the documented purpose needs. Optional processing can require a separate user action where the legal basis and context support that choice. The team should record what happens when the person takes no action.
That question catches several common defaults:
- A signup form asks only for the information needed to create the account. Optional profile details remain optional.
- A location feature uses the least precise location that meets the stated purpose. It does not silently add the data to an advertising audience.
- A reporting tool shows aggregate results when individual records are unnecessary.
- A service keeps access private until the person actively chooses to publish information.
- A vendor's analytics, enrichment, profiling or sharing functions stay off when the purpose and lawful basis do not support them.
The EDPB says controllers using third-party or off-the-shelf software should assess the product and switch off functions that lack a legal basis or are incompatible with the intended purposes. The same reasoning applies to organisational procedures and staff access: the process should begin with only the data and access each role needs. 3
A person can choose to expand a setting when the controller has designed a valid choice around it. The default should not make that expansion the hidden price of using the core service.
4. Test the path, not only the setting
A preference centre can show a privacy-protective value while a background job continues to use the data. A vendor console can display an off switch while an export still carries the field. A deletion policy can exist while backups, search indexes or reporting tables keep the value available.
Testing should begin from a fresh account, a fresh device, a new employee role and a new vendor connection. Inspect the first request, the first database write, the first event, the first downstream transfer and the first access decision. Then exercise the user or reviewer action that changes the scope.
The test plan should cover:
- The initial state before the person changes a setting.
- The data fields, granularity and metadata collected at that state.
- The processing jobs, models, exports and recipients that receive the data.
- The retention and deletion behavior when the purpose ends.
- The staff, vendor and public access paths.
- The result after a person changes a setting or exercises a right.
- The result after a product, vendor, purpose or risk change.
The EDPB requires a case-by-case risk assessment and verification of the effectiveness of safeguards even when a controller uses standards, baselines or recognised practices. The controller must also keep reviewing existing systems, including legacy systems, as risks and technology change. 3
5. Record the decision and the next review trigger
The record should let another reviewer reconstruct the decision without relying on the original meeting. Capture the purpose, data, operations, recipients, role allocation, default state, user intervention, retention event, access model, safeguards, test evidence, owner and approval date.
Add the facts that could change the conclusion: a new data category, a new recipient, a new model, a new public-facing feature, a change in the lawful basis, a material vendor change, a new risk pattern or a failed control test.
The ICO recommends considering data protection from the initial planning stage through the processing lifecycle. Its operational guidance also calls for up-to-date data mapping, documented decisions, regular audits, senior accountability, staff training and strong privacy protections in default settings. 5
Keep the neighbouring concepts in their places
Data minimisation supplies one of the principles Article 25 must implement. The default rule makes minimisation operational across collection, processing, retention and access. A minimisation statement without a default, owner or test remains a requirement waiting for implementation.
Security protects confidentiality, integrity and availability. Security controls belong inside a design review, yet a secure system can still collect unnecessary data or use it for an unrelated purpose. Encryption does not justify a mandatory field that the service does not need.
A DPIA helps identify and reduce risks. The GDPR requires one when processing is likely to result in a high risk to people's rights and freedoms. Article 25 still applies to the design and maintenance of processing when the activity does not cross that threshold. The ICO describes DPIAs as an important part of applying design and default protection, while the EDPB treats a DPIA or update as an additional step that may follow the Article 25 risk assessment. 35
Storage limitation sets the principle for keeping data only as long as necessary. Article 25 turns that principle into a default behavior: the system should have a deletion or anonymisation path rather than relying on a future manual clean-up.
Vendor procurement distributes implementation work without transferring the controller's accountability. The ICO says controllers should use processors that provide sufficient guarantees for their technical and organisational measures, and should consider whether products and services support their design obligations. A processor's contract, certification or product description can support the review. The controller still needs to understand the data flow and test the settings it relies on. 5
Approved certification can help demonstrate compliance with Article 25(1) and (2), as Article 25(3) provides. Certification is evidence for the control decision. It does not replace the controller's analysis of the particular processing, purpose and risk. 1
Failure modes that should stop sign-off
The privacy review happens after the architecture is fixed
The team has already selected the database, vendor, fields and public-sharing model. The review can now recommend only expensive workarounds. Bring the purpose, data flow, access model and default state into the design and procurement decision.
The product treats a later choice as a cure for an intrusive default
A setting that starts enabled still determines the initial processing. Test the state before any user intervention and show why each default operation is necessary for its purpose.
The vendor's privacy label replaces a product test
Ask which functions collect, enrich, profile, export or share personal data. Check whether the controller can disable them, whether the setting propagates to downstream systems, and what evidence the vendor provides. Record any compensating control or supplier decision.
The team tests collection and forgets access
A form can collect the minimum and still expose the result to a broad internal group, a search engine or a public endpoint. Test role-based access, publication gates, recipient lists and the user's opportunity to intervene.
The team writes a retention period without building the expiry path
A policy statement does not delete data. Identify the event that ends the purpose, the automated or manual action that follows, exceptions, backups and the evidence that confirms the action ran.
The review ends at launch
The EDPB treats maintenance and review as part of the continuing obligation. Create a re-review trigger for material changes and inspect legacy systems when their risks, technology or processing context changes. 3
The record a reviewer can use
A concise Article 25 record should answer these questions:
- What specific purpose does the processing serve?
- What data, level of detail and processing operations does that purpose require?
- What legal basis, transparency information and user control apply to each distinct purpose?
- What will the system collect, process, store and expose before anyone changes a setting?
- Which four default dimensions were tested: amount, extent, period and accessibility?
- What risks to people's rights and freedoms shaped the measure choice?
- How did the team weigh state of the art, implementation cost, context and purpose?
- Which technical and organisational measures enforce each requirement, and who owns them?
- Which vendor functions are enabled, which are disabled, and what evidence supports that configuration?
- How were the first request, downstream flows, access paths, deletion path and user intervention tested?
- What evidence shows that the controls worked, and where is it stored?
- What change or review event will reopen the decision?
The record should make the default visible. A reviewer should be able to answer one sentence without opening a meeting transcript: "If nobody changes a setting, the system does X with Y data for Z purpose, keeps it until A, and exposes it only to B."
That is the working standard for data protection by design and by default. The organisation has chosen the processing method with the rights risks in view, made necessary processing the starting state, connected each safeguard to an enforcement point, and kept evidence for the next review. Privacy is then present in the system's first behavior, not waiting in a document for someone to remember it.
References
- 1GDPR Article 25
legislation.gov.uk
- 2EDPB Guidelines 4/2019 on Article 25
edpb.europa.eu
- 3EDPB Guidelines 4/2019, paragraphs 40-46
edpb.europa.eu
- 4
- 5
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.