Data Protection by Design and by Default (GDPR Article 25): A Practical Checklist

Two duties, one article

Duty	What it requires	Article
By design	Appropriate technical and organisational measures, such as pseudonymisation, designed to implement the data protection principles effectively and to integrate the necessary safeguards, both when you decide the means of processing and during the processing itself	25(1)
By default	Measures ensuring that, by default, only the personal data necessary for each specific purpose is processed, covering the amount collected, the extent of processing, the storage period and accessibility. In particular, data must not by default be made accessible to an indefinite number of people without the individual's intervention	25(2)

What is "appropriate" depends on the state of the art, the cost of implementation, the nature, scope, context and purposes of the processing, and the risks for people's rights and freedoms (Article 25(1)). An approved certification under Article 42 can be used as an element to demonstrate compliance (Article 25(3)).

The duty sits with the controller. The EDPB's Guidelines 4/2019 on Article 25 (version 2.0, adopted 20 October 2020) note that processors and producers of products, services and applications are not directly addressed, but are key enablers; recital 78 encourages producers to take data protection into account when developing their products. In practice, buyers will ask software vendors how their product supports Article 25.

It is enforceable: infringing Article 25 falls in the fine tier of up to €10 million or 2% of worldwide turnover (Article 83(4)), and the technical and organisational measures a controller implemented under Articles 25 and 32 are a factor in setting any fine (Article 83(2)(d)). See how GDPR fines are calculated.

From principles to design measures

The EDPB guidelines go through each principle of Article 5 and list key design and default elements. A selection, with what they usually mean for a software product or internal tool:

Principle	Design and default elements (EDPB)	In practice
Transparency	Clear, plain and concise information, provided in context at the relevant time, accessible to all users	Short notices at the point of collection, a layered privacy notice, explanations next to settings
Lawfulness	The right legal basis for each processing activity, clearly linked to its purpose; consent freely given, specific, informed and unambiguous, and as easy to withdraw	A legal basis per feature, consent separated from terms of service, a withdraw switch in the account
Fairness	No deception or manipulation, respect for the reasonable expectations of users, no lock-in	No dark patterns in consent and settings, honest defaults, easy export
Purpose limitation	Purposes defined before processing starts, with new purposes checked for compatibility	Tag data with its purpose; a review step before data is reused for analytics or AI training
Data minimisation	Only data that is adequate, relevant and necessary; pseudonymise or anonymise where possible; periodically check whether data is still needed	Optional fields really optional, no free-text fields that invite sensitive data, aggregated analytics
Accuracy	Reliable sources, ways for users to correct data, checks for errors	Self-service profile editing, validation at input
Storage limitation	Defined retention, automatic deletion or anonymisation	Retention settings in the code, deletion jobs, retention tested like any other feature
Integrity and confidentiality	Security measures proportionate to risk, access control, encryption, resilience and backups	Least-privilege access, encryption in transit and at rest, logging of access to personal data
Accountability	Being able to demonstrate that the measures are in place and effective	Design decisions recorded in tickets or DPIAs, a privacy review in the definition of done

Privacy-friendly defaults to ship

Profiles, posts and shared items private or limited to the user's team by default, never public by default (Article 25(2)).
Optional analytics, personalisation and marketing switched off until the user opts in where consent is the basis.
Only the fields needed for the feature collected at sign-up; the rest asked for later, when it is needed and explained.
Short default retention for logs, exports and deleted items, with longer periods only where justified.
Access to personal data in admin tools limited to the roles that need it, with access logged.

Building it into your process

Screen early. Add a short privacy question set to the template for new features and new tools: what personal data, which purpose, which legal basis, who can see it, how long it is kept.
Escalate high risk. If the screening shows likely high risk, run a DPIA before building. Article 25 applies to all processing; the DPIA is the deeper check for the risky cases.
Choose processors with Article 25 in mind. Ask vendors about default settings, retention controls, export and deletion, and check their data processing agreement.
Test the defaults. Include privacy defaults in acceptance criteria and regression tests, so a later change does not silently make data public or keep it forever.
Record decisions. A line in the ticket or the design document explaining why a field or a retention period was chosen is the evidence accountability asks for.
Review periodically. The guidelines expect controllers to keep measures effective as the state of the art and risks change.

A checklist for every new feature. The Privacy Impact Assessment Bundle includes a data protection by design checklist, a DPIA screening checklist, a DPIA template and register, a transfer impact assessment and a DPO consultation record.

Data Protection by Design and by Default (GDPR Article 25): A Practical Checklist

Two duties, one article

From principles to design measures

Privacy-friendly defaults to ship

Building it into your process

Sources

Related tools

DPIA Helper

GDPR Compliance Checklist