Data protection by design for software and product teams

The EDPB small business guide uses an online bookshop as an illustration of data minimisation at the order form. In the original design, date of birth, phone number and home address were mandatory for every order, whether the customer bought a printed book or a digital copy. The fix was to split the form by purpose, so that an eBook order no longer asks for a delivery address. The shop collects only what each purpose needs, which is the core of Article 25(2) applied to the amount of data collected.

• Design decision: Make the form branch on product type, so the delivery step appears only for physical goods.
• Data not collected: Home address on eBook orders. Date of birth and phone number remain out of the eBook path unless a stated purpose requires them.
• Evidence to keep: The form specification or user flow diagram for each product path, the field-level justification for each mandatory input, and the change record showing when the split was introduced.
• Testing point: Confirm that the database schema and downstream systems (payment, fulfilment, email) do not still require the removed fields for eBook orders.
• Illustrative extension: Check whether analytics or fraud tools receive the address field through a default data layer, since that can undo the minimisation.

This is an EDPB illustration, not a client engagement. Before reusing the pattern, check that your own order flows, integrations and records retention rules match the split you designed.

The EDPB guide's medical practice example addresses data protection by default for accessibility. Access to patient files is granted by default only to the treating doctors, rather than being open to all staff who use the practice system. The point is that the default setting, not an individual's later choice, limits who can see the data. Article 25(2) states that personal data should not be made accessible to an indefinite number of people without the individual's intervention, and this example shows how a default role configuration meets that requirement.

• Design decision: Set the access model so that patient files are visible only to the treating clinicians by default, with any wider access requiring an explicit, logged action.
• Data not collected or exposed: Clinical notes and records that reception or administrative staff do not need for their role are not visible to them by default.
• Evidence to keep: The role and permission matrix, the default configuration as deployed, records of any access grants and their approvals, and access logs that show who opened which files.
• Review point: Re-check the matrix when staff roles change, since default access tends to widen through group memberships over time.
• Illustrative extension: Confirm how emergency or cover access is granted and whether it is reviewed afterwards.

This is an EDPB illustration, not a client engagement. Before relying on it, confirm your jurisdiction's health data rules and test the default in your own identity and access setup.

Both examples share a pattern: the design decision is made once, in the product or configuration, and the protection applies to every later use without further action by the user. A team reviewing its own systems can compare each new feature against the same questions the EDPB examples answer. The EDPB guide also makes the controller responsible for these outcomes when processors and sub-processors build or run the system, so the design choices should be written into contracts and specifications.

• Purpose first: For each collected field, record the purpose and the flow that needs it.
• Default state: Check what a new user, a new role or a new integration receives on day one.
• Downstream copies: Trace whether removed or restricted data still reaches logs, exports, analytics or backups.
• Processor configuration: Confirm that vendor or hosted defaults match the controller's design, and record this in the processing agreement.
• Regular review: Schedule re-testing, because EDPB Guidelines 4/2019 expect controllers to review the effectiveness of their measures.

When preparing evidence for an assessor, ask whether each tab's design decision can be shown with a specification, a configuration export and a dated test result.

Your organization remains the controller and carries the legal responsibility for data protection by design and by default. That means deciding which personal data each purpose needs, choosing the measures that limit collection, storage and access, accepting residual risk and signing off the design. Article 25 applies regardless of company size, and the EDPB's guidance expects regular review of whether the chosen measures still work, so this ownership does not end at launch.

• Purpose and data decisions: Define the purposes, the data each purpose needs and the retention period for each dataset.
• Default settings: Approve which fields are optional, who can see what by default and how long records remain accessible.
• Design sign-off: Record who approved each design choice and the risk reasoning behind it.
• Processor and sub-processor terms: Decide what privacy defaults you require from vendors and write them into contracts.
• Ongoing review: Schedule reviews of the measures, especially after product changes or changes to legacy systems.

Check that each design decision has a named owner, a date and a documented rationale that someone outside the build team could follow.

An implementation partner such as DeployOpen can configure self-hosted open-source platforms inside your own infrastructure, test whether default settings limit data as intended, and prepare the technical evidence that supports your design decisions. The partner works to a written scope and does not take over the decisions listed in the first tab. Its output is configuration, test results and documentation for your review, not a compliance conclusion.

• Configuration work: Set collection fields, pseudonymisation, access roles and retention jobs in the platform as your team specifies.
• Default testing: Check that a new account, form or record exposes only the intended data to the intended users.
• Design documentation: Write up the choices made, the tests run and the known limits in a form your DPO and assessors can read.
• Evidence preparation: Collect configuration exports, test logs and change records that show the design in operation.
• Legacy analysis: Map older systems that predate the GDPR and propose changes for your team to approve.

Check the written scope for named deliverables, who signs off each one, and what the partner will not do, such as deciding lawful bases or certifying compliance.

Only an independent auditor, assessor or certification body issues a report or certificate. Under Article 42, certification is voluntary, is issued for at most three years by accredited certification bodies or supervisory authorities, and does not reduce the controller's or processor's responsibility. Article 25(3) allows an approved certification mechanism to serve as one element in demonstrating compliance with Article 25, which is why assessor independence matters.

• Independence: The assessor must not design or configure the system it tests, or the result loses its value.
• Scope of testing: Assessors test the design and operating evidence against the mechanism's criteria, not your intentions.
• Certificate ownership: Certification is issued to the organization and its scope, and it must be maintained over its validity period.
• Limits of certification: A certificate is one element of evidence and does not replace your own records or your accountability to a supervisory authority.
• Cost drivers: Assessor fees depend on scope, number of processing activities and evidence quality, so ask each body for a written quote.

Confirm which certification mechanisms are approved for your jurisdiction and whether the assessor is accredited for them before you commit.

Organizations commonly outsource the technical work that is expensive to staff in-house: platform configuration, default-setting tests, documentation drafting and evidence collection. Decisions that carry legal weight, such as the purposes, lawful bases and acceptable residual risk, are usually kept in-house or taken with the DPO's advice. Outsourcing is cheaper and faster when the scope is narrow and the internal owners are ready to decide.

• Usually outsourced: Hardening self-hosted platforms, configuring pseudonymisation and access controls, and testing defaults.
• Usually shared: Writing design documentation, where the partner drafts and your DPO reviews.
• Usually kept in-house: Purpose definitions, lawful basis choices, risk acceptance and final sign-off.
• Often outsourced separately: Certification audits and formal assessments, which must come from an independent body.
• Cost components: One-time build and documentation work, plus recurring review, upgrades and retained support.

Ask any partner to state in writing which tasks it performs, which it supports and which it will not perform.

The independence boundary separates the party that builds and evidences a control from the party that tests it and issues an opinion. A partner that configures a system should not also be the assessor that certifies it, because a certification based on self-review gives little assurance to customers or regulators. The boundary also protects the controller: outside help never transfers the legal duty to comply.

• Build side: Implementation partners, your engineers and your DPO's internal reviews.
• Assess side: Independent auditors and accredited certification bodies only.
• Separate roles: Keep the person who designed a control out of its formal assessment where the assessor requires it.
• Documented handover: Record what the partner delivered, so the assessor can trace each claim to evidence.
• No compliance claims by partners: Implementation work supports compliance but does not establish it.

Before engaging anyone, confirm with the assessor which parties it can work alongside and what documentation it will request.