GDPR Article 25 makes data protection a decision to take when a controller chooses how processing will work, and a condition to maintain while it operates. Paragraph 1 addresses appropriate technical and organisational measures at design time and at the time of processing. Paragraph 2 addresses defaults: for each specific purpose, the default configuration must process only the personal data necessary. The official Article 25 text and the EDPB’s final Guidelines 4/2019 are the starting points.
The direct Article 25 duty is the controller’s. A supplier’s design matters because the controller chooses and configures the service, and a processor has its own GDPR duties, but the Regulation does not automatically make every software vendor a controller’s statutory Article 25 substitute. The useful question for a buyer is therefore concrete: can this product be configured and operated so our processing meets the rule? The useful question for a product team acting as controller is whether its actual defaults, data flows and later changes do so. These questions connect privacy-by-design implementation to Article 32 security without treating security alone as privacy compliance.
Read the two duties together
Article 25(1) requires measures designed to implement data-protection principles and integrate safeguards into processing, taking account of the state of the art, implementation cost, the nature, scope, context and purposes of processing, and risks of varying likelihood and severity to people’s rights and freedoms. Pseudonymisation is one example in the text, not a universal prescription. Measures should be effective for the particular system and revisited when the system or risk changes. A design review before launch helps, but a configuration that drifts after launch can make an originally sound decision ineffective.
Article 25(2) specifies that, by default, only data necessary for each specific purpose is processed. The rule covers the amount collected, extent of processing, storage period and accessibility. Personal data must not, by default, be made accessible to an indefinite number of natural persons without the individual’s intervention. A private account setting may be appropriate for a public profile service, but Article 25 does not say every service must use the same privacy switch. It requires the controller to explain the chosen purpose and why its ordinary starting state does no more than necessary.
The two paragraphs interact. A team cannot cure an unnecessary default collection field simply by encrypting the resulting database. Encryption reduces certain security risks; it does not establish that collecting the data was necessary. Conversely, removing a field does not replace access control or retention management for the fields that remain. The lawful-basis guide helps identify the legal ground for each purpose, while the data-minimisation guide helps test individual data fields.
Start with a purpose and a real workflow
Before choosing a technical control, describe one actual processing operation: who supplies data, for what purpose, which staff and suppliers see it, when it is deleted, and what a person can reasonably expect. “Improve the service” is too vague to determine whether recording every support call or retaining every device identifier is necessary. “Resolve support tickets for existing customers” permits a more specific design: contact details, issue history, restricted support access and a justified retention period. Product analytics may be a different purpose with different data and legal analysis.
A design record can pair each field with the action it enables. For an appointment service, a contact address may be needed to send confirmation; a birth date may not be. If age eligibility matters, ask whether an age band or yes/no eligibility answer can serve the purpose. If a feature uses precise location, test whether it needs continuous tracking or only a user-initiated location lookup. These are not abstract preferences. They change the amount collected, the defaults seen by new users and the attack surface later addressed under Article 32.
The controller should ask what happens when the person does nothing. Are optional boxes unchecked? Does the interface disclose personal details to a public audience without an active choice? Does an imported customer record immediately become visible to every employee? Is an optional data transfer enabled before its purpose is explained? A protective default cannot be hidden behind a settings page the individual is unlikely to find. At the same time, an individual choice does not make otherwise unlawful processing lawful; consent, legitimate interests or another ground still needs its own analysis.
Map the four dimensions of data protection by default
Amount concerns the fields and records obtained. Eliminate unused mandatory fields, unnecessary document uploads and broad API payloads. If a support agent needs an order number and delivery status, the full payment-card record should not appear in the support view. Extent concerns operations performed. A form collected for service delivery should not automatically feed an unrelated training dataset or audience-building pipeline. Storage period requires a reasoned trigger for deletion or review, not indefinite retention because storage is cheap. Accessibility concerns who can see or export data at the start of the workflow. A role labelled “standard employee” should not quietly inherit organisation-wide customer export rights.
These dimensions require decisions at several layers. Front-end controls govern what is requested. APIs and queues govern what travels between services. Databases and logs govern what persists. Roles and sharing settings govern who can access it. Backups and vendor integrations govern where copies remain. A default privacy notice alone cannot constrain a background export. Review the actual data flow, including telemetry and support tooling that may be configured outside the main product interface.
A practical control is to test a fresh account and a newly added employee role, without manually changing any settings. Inspect the data collected, visible profiles, recipient list, exports and retention settings. Repeat after a major feature release or migration. Capture the observed configuration and the reason it matches each purpose. This yields better evidence than a design checklist marked complete before anyone used the system.
Select measures for effectiveness, not for their label
Pseudonymisation can reduce direct attribution when identifiers are separated from working data and the additional information is protected. It does not turn the working data into anonymous data if re-identification remains possible. Encryption protects confidentiality but depends on key management and the moment data is decrypted for use. Access controls should match tasks and remain manageable when employees move roles. Retention controls need a deletion path for exports and derived copies. A measure is appropriate when it actually mitigates the risks of the processing operation, not because it appears in a generic catalogue.
Consider an internal case-management tool used by a small legal team. The controller might separate clients’ identifiers from analytical labels, limit bulk export to two reviewed roles, prevent a case from appearing in search results outside the assigned team and purge temporary attachments after closure. Another controller using the same tool for an emergency helpline may need broader urgent access, but can log that access and review it. Article 25 allows context-sensitive design. It calls for a documented explanation of why the chosen access pattern serves the purpose and manages risk.
Organisational measures matter too. A change request can require the owner to state the new purpose, affected data and default state. Procurement can require a real demonstration of export and deletion. Support staff can have a route to report excessive visibility. A release process can prevent a new field from going live until the privacy notice, retention logic and access role are updated. None of those controls is helpful if a decision has no owner or if known exceptions remain untracked indefinitely.
Treat suppliers and settings as a controller decision
A controller buying software should ask the supplier what data the service collects by default, including diagnostic data, how sharing and retention are configured, which roles can access records, and whether optional modules add new purposes. Demonstrations should use the package being purchased, not a higher tier with protections unavailable to the customer. Contractual terms and processor arrangements are relevant, but they do not prove that the live tenant is configured safely.
Ask for a test tenant or a written configuration map. Create a basic user, a manager and a support role. Check what each sees before anyone adjusts permissions. Check whether an unused integration starts transferring data automatically. Check whether closed accounts remain in the user directory and backups according to a published retention method. If an essential safeguard cannot be enabled or evidenced, the controller must decide whether another configuration or service is needed. The controller cannot outsource its Article 25 judgment simply by copying the supplier’s privacy statement into its own files.
A vendor that itself determines purposes for telemetry, billing or marketing is a controller for those operations and must assess its own obligations. For customer data it processes only on instruction, the processor provisions of the GDPR and the contract also matter. Keep those roles distinct; one organisation can act in different roles for different data uses. The general compliance guide puts that role analysis in the wider programme.
Use DPIAs and records as evidence, with the right trigger
A data protection impact assessment is required where a type of processing is likely to result in a high risk, particularly using new technologies and considering the nature, scope, context and purposes. It is a way to examine Article 25 design choices, not a mandatory document for every routine form. Record planned safeguards, remaining risks and who approved changes. If the DPIA shows a high risk that the controller cannot sufficiently mitigate, Article 36 prior consultation may be required before processing. An incomplete DPIA by itself does not automatically trigger consultation. The Article 36 guide explains the decision.
For less risky activities, a short design record can still be useful: purpose, fields, recipients, default visibility, retention, risk assumptions, selected measures and review date. Cross-reference the record of processing where applicable instead of duplicating inconsistent descriptions. During an audit, evidence should show what was actually configured and when. A screenshot alone may be misleading after a later release; pair it with version or change information. Article 25(3) says approved certification under Article 42 may be used as an element to demonstrate compliance, but a label or an unrelated standard is not automatic proof that this processing meets Article 25.
Check a change before it silently expands processing
A feature may begin as a narrowly scoped support form and later gain image upload, auto-transcription, external analytics and AI summarisation. Each addition can affect data categories, recipients, retention and visibility. Reopen the design record when the team changes the purpose or means, not only on a calendar date. Ask whether existing users inherit the new feature by default, whether old records are backfilled, and whether an interface choice truly controls the underlying transfer. If an optional function needs additional data, make the boundary clear to the user and to internal operators.
An example is adding a “share with team” button. If new case files are visible to all colleagues unless a user opts out, the default may be too broad. A design alternative is restricted visibility initially, with a deliberate action to add named collaborators. The team can still support a public sharing feature where that is the user’s chosen purpose, but should verify that the ordinary starting state does not expose unrelated personal data. Test imports, mobile views and API access as well as the main web screen; a protective display setting is ineffective if the same record is returned through a broad endpoint.
Measure whether controls work. Review access-denied events and exceptional access, sample newly created records, verify deletion after a retention trigger, and check that a newly introduced integration stays off until approved. Frequency depends on risk and pace of change; Article 25 does not prescribe a universal monthly or annual test schedule. When the result fails, record the affected records, fix, possible breach question and change to prevent recurrence. A meaningful review distinguishes a design intention from observed behaviour.
Questions to resolve before release
Can the owner explain the specific purpose of each data category? Can a fresh user accomplish the necessary task without providing unrelated information? Who can read, search, export or disclose a new record by default? When will the record and its copies cease to be necessary? Does a supplier’s standard configuration match the intended processing, and can the controller change it? Which person will recheck those answers when the workflow changes? These questions turn Article 25 into a reviewable decision rather than a slogan.
Read Article 25 on EUR-Lex for the legal wording and the EDPB Guidelines 4/2019 for interpretation and examples. The EDPB guidance is guidance, while the Regulation binds controllers. The appropriate design still depends on the actual purpose, risks and available measures; no generic setting or certificate resolves that assessment for every controller.