GDPR Article 25 in Practice. What Privacy by Design Actually Demands When You Mean It.

Anyone starting a small app in Germany who wants to be honest about data protection will run into the phrase “Privacy by Design” early on. It appears in privacy notices, in marketing texts, in product descriptions. It is also a term from Article 25 of the GDPR, and in that capacity it is not optional but mandatory. The question is what the duty practically means.

What Article 25 actually says

Article 25(1) requires the controller, taking into account the state of the art, the cost of implementation, and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for the rights of natural persons, to implement, both at the time of determining the means of processing and at the time of processing itself, appropriate technical and organisational measures, which are designed to implement data protection principles in an effective manner and to integrate the necessary safeguards into the processing to meet the requirements of the GDPR and protect the rights of data subjects.

Article 25(2) adds a second duty: default settings must be such that only the personal data necessary for the specific purpose are processed by default. This applies to the amount of data collected, the extent of processing, the storage period and accessibility. An app that sends telemetry to a cloud service by default does not meet this duty, even if the telemetry can be turned off.

Both duties are addressed to the controller, typically the operator of the app or service. The EDPB Guideline 4/2019 stresses that Article 25 covers the entire lifecycle of processing, from requirement definition through implementation to operation and later adjustment.

What “state of the art” means

The Regulation requires appropriate measures, taking into account the state of the art. This is not a duty to use the most expensive available solution, but a duty to know the established practices and be able to justify why a particular variant was chosen. Pseudonymisation, encryption, separated data storage, access controls, automatic deletion deadlines, local-only storage are all examples of measures described in relevant guidance, for instance from BSI and ENISA.

A small practice cannot implement everything theoretically possible. It must, however, document what it considered and why it decided for or against a particular measure. The risk assessment is part of compliance.

Defaults are the practical heart

Article 25(2) is often the most effective provision in practice, because it translates into concrete UI and architecture decisions. A newsletter form where tracking cookies are off by default satisfies it. An app that asks for location only when the function genuinely needs it satisfies it. A patient record that shows by default only the fields needed for the current session satisfies it.

The duty is thus a duty to be sparing from the start. It inverts the usual pattern where users must switch off all the things they do not want. Instead, the provider must switch on everything they want to process.

Privacy by default is the one place in the GDPR where the Regulation imposes a concrete UI duty on the provider. The default setting is itself the measure.

Local-only storage as a technical measure

One of the most effective measures under Article 25 is local-only storage: keeping personal data on the user’s device and processing it there, without transmitting it to provider servers. If personal data never leave the device storage, they cannot be reached by third parties. No cloud sync risks, no provider data breach impact, no state requests, no Schrems II issues from third-country transfers.

Local-only storage does not fit every application. If the value of the application lies in cross-device synchronisation or in server-side analysis, it is not possible. For many applications, especially in healthcare and social services, it is realistic. A complementary perspective on the architecture side can be found in Privacy by Design in Health Apps.

A caveat: local storage alone does not automatically satisfy Article 25. It must be documented, with a clear listing of which data stay local, which telemetry (if any) reaches the server, how backups are handled (if local, then encrypted locally; if cloud backup, that is a transfer), and how that relates to the data protection principles in Article 5.

What supervisory authorities actually check

The German data protection authorities work with the Standard Data Protection Model, which translates the data protection principles into seven protection goals: availability, integrity, confidentiality, transparency, intervenability, unlinkability, data minimisation. Each goal comes with concrete audit criteria.

In an audit, supervisory authorities typically examine:

• the documentation of processing activities under Article 30,
• the justification for why certain data are collected and not others,
• the default settings of the application,
• the retention and deletion concept,
• the technical measures for confidentiality and integrity (encryption, access control),
• the documented risk assessment,
• the data protection impact assessment, if Article 35 requires one.

The most important thing is consistency between documentation and practice. A carefully written processing record that does not match reality is worse than a brief record that describes exactly what the application does.

What is left for a small practice

For a small studio, Article 25 comes down to a few practical points. Before coding: which data do we actually need, and which not? Which defaults do we choose? Where do the data sit? While developing: are those decisions documented in version control? Are they revisited when requirements change? After release: is there a process that keeps the processing record current?

None of this requires a compliance department. It is careful product engineering that happens to coincide with the law. The Regulation asks no more, but no less either.

Frequently asked

What does Article 25 GDPR actually require?

Article 25(1) requires the controller, taking into account the state of the art, the costs of implementation and the risks of processing, to implement appropriate technical and organisational measures to give effect to the data protection principles. Article 25(2) requires privacy-friendly defaults: only personal data necessary for the specific purpose are processed by default. Both duties are mandatory; breaches can be fined up to 10 million euros or 2 percent of worldwide annual turnover.

Is it enough to mention Privacy by Design in the privacy policy?

No. Article 25 requires implemented measures, not a declaration. The EDPB Guideline 4/2019 makes clear that the duty is continuous: present already in the planning phase, then during the processing itself. A clause in the privacy notice without documented decisions does not satisfy it.

Does local-only storage help with Article 25?

Local-only storage is one of the most effective technical measures under Article 25 because it reduces the risk of processing at source. If no personal data leaves the user's device, it is not reachable by third parties: neither through provider data breaches nor through state requests. The measure must, however, be documented, with a clear description of which data stay local and which (if any) reach the server.

What do supervisory authorities check under Article 25?

The German data protection authorities work with the Standard Data Protection Model (SDM), which translates the GDPR principles into seven protection goals: availability, integrity, confidentiality, transparency, intervenability, unlinkability, data minimisation. Audits typically look at documented decisions on data minimisation, default settings, the retention concept, architecture decisions with data protection implications, and whether the implementation matches the documented measures.