Data Protection by Design and by Default Under the GDPR: What Article 25 Requires

Key Points: (1) Article 25 GDPR requires data protection by design and by default, making it a legal obligation for controllers. (2) Data protection must be built in from the start and considered throughout the entire processing lifecycle. (3) By default, only personal data necessary for a specific purpose should be processed, reflecting data minimization and purpose limitation. (4) Appropriate safeguards depend on the nature of the processing, state of the art, implementation costs, and risks to individuals.(5) Measures may include pseudonymization, privacy-protective defaults, transparency, user controls, access restrictions, and security safeguards. (6) Controllers remain accountable, although processors, developers, vendors, and other technology providers can play important supporting roles. (7) DPIAs can help implement data protection by design, but Article 25 applies even when a DPIA is not required. (8) Compliance is ongoing, not a one-time exercise—organizations should reassess safeguards as technologies, processing activities, and risks change.

European data protection law requires organizations to build data protection into the design and operation of systems, products, services, and business processes that involve personal data. This obligation is generally referred to as data protection by design and by default.

At its core, data protection by design and by default requires organizations to think about data protection before processing begins and throughout the entire lifecycle of the processing. Organizations should not add privacy and data protection safeguards only after a product has been developed, a system deployed, or a problem identified.

The concept is closely related to Privacy by Design, but under the GDPR it is a legal obligation—particularly through Article 25 GDPR—rather than simply a recommended privacy engineering practice.

The obligation is also closely connected to two broader features of the GDPR:

• Risk-based regulation. The measures an organization implements should reflect the risks that the processing creates for the rights and freedoms of individuals. Higher-risk processing will generally require stronger safeguards.
• Accountability. Organizations must not only comply with the GDPR but also be able to demonstrate that they have done so. Decisions about the design of processing activities, the safeguards selected, and the reasons for those decisions should therefore be appropriately documented.

Although both controllers and processors have important roles in implementing data protection safeguards, Article 25 GDPR places the express obligation to implement data protection by design and by default on the controller. Processors nevertheless play an important supporting role. Among other things, Article 28 requires processors to provide sufficient guarantees that they will implement appropriate technical and organizational measures and to assist controllers with certain GDPR compliance obligations.

What Does Article 25 GDPR Require?

Article 25 divides the obligation into two closely related concepts: data protection by design and data protection by default.

Data Protection by Design

Under Article 25(1) GDPR, controllers must implement appropriate technical and organizational measures designed to implement the GDPR's data protection principles effectively and integrate the necessary safeguards into processing.

This obligation applies at two important stages:

1. when determining the means of processing; and
2. while the processing itself is taking place.

Data protection therefore needs to be considered from the earliest stages of designing a processing activity and revisited as the processing, technology, risks, and circumstances evolve.

Article 25 specifically identifies pseudonymization as an example of a possible measure and data minimization as an example of a data protection principle that should be implemented effectively. These are examples rather than exhaustive requirements. Depending on the processing, appropriate measures might also include access controls, encryption, retention controls, purpose limitations, privacy-protective system architecture, user controls, transparency mechanisms, or organizational policies and procedures.

Importantly, Article 25 does not prescribe a single technical solution. In determining what measures are appropriate, controllers must take into account:

• the state of the art;
• the cost of implementation;
• the nature, scope, context, and purposes of the processing; and
• the risks of varying likelihood and severity to the rights and freedoms of natural persons.

The result is a contextual and risk-based obligation. What constitutes appropriate data protection by design for a small, low-risk processing activity may be very different from what is required for large-scale behavioral profiling, biometric identification, location tracking, or other processing capable of significantly affecting individuals.

Data Protection by Default

Article 25(2) GDPR addresses the settings and choices that apply automatically when an individual does nothing.

Controllers must implement appropriate technical and organizational measures so that, by default, only personal data that are necessary for each specific purpose are processed.

The GDPR expressly applies this requirement to:

• the amount of personal data collected;
• the extent of the processing;
• the period for which the data are stored; and
• the accessibility of the personal data.

In practical terms, the most privacy-protective configuration necessary to accomplish the specified purpose should generally be the default, rather than requiring individuals to find settings or take additional steps to obtain basic data protection.

Article 25(2) specifically provides that personal data should not, by default, be made accessible to an indefinite number of people without the individual's intervention.

Data protection by default requires controllers to ensure that, automatically, they process only the personal data necessary for each specific purpose. This requirement is closely connected to the GDPR principles of data minimization and purpose limitation.

Before processing begins, controllers should identify what personal data is actually necessary, clearly inform individuals about the processing, and configure systems accordingly. GDPR does not necessarily require a universal “default to off” approach. Instead, controllers should consider privacy-protective defaults, avoid presenting individuals with illusory choices, avoid unnecessary additional processing, ensure personal data is not made public by default, and provide individuals with meaningful controls over their data.

Demonstrating Compliance

Article 25 is also tied directly to the GDPR's broader accountability framework.

Under Article 25(3), an approved certification mechanism under Article 42 may be used as an element to demonstrate compliance with the data protection by design and by default requirements.

Certification is not the only way to demonstrate compliance, however. In practice, organizations may also rely on documentation showing how data protection requirements were considered throughout the development and operation of a processing activity—for example, design decisions, risk assessments, data protection impact assessments where required, technical specifications, testing, policies, retention schedules, access controls, and records explaining why particular safeguards were selected.

The key point is that data protection by design and by default is not a one-time compliance exercise. It is an ongoing obligation to translate the GDPR's principles and individual rights into the actual design, configuration, and operation of systems and processing activities.

Data Protection by Design Beyond System Settings

Data protection by design and by default extends beyond the initial configuration of a product or service. It can also be relevant to international data transfers. In particular, where personal data is transferred to a third country without an adequacy decision, the safeguards used for the transfer must provide appropriate protection. Recital 108 GDPR specifically identifies compliance with data protection by design and by default as part of the safeguards associated with legally binding and enforceable instruments under Article 46(2)(a).

The concept is also closely related to Data Protection Impact Assessments (DPIAs). A DPIA can help controllers identify risks and determine the technical and organizational measures needed to ensure that processing complies with the GDPR's data protection principles.

The two obligations should not, however, be confused. A DPIA is required only when processing is likely to result in a high risk to individuals' rights and freedoms. Data protection by design and by default applies much more broadly.Controllers must consider data protection from the outset and throughout processing, regardless of whether the particular activity ultimately requires a DPIA.

Who Is Responsible for Data Protection by Design and by Default?

The controller bears primary legal responsibility for complying with Article 25 GDPR. Data protection by design should therefore be treated as an organization-wide responsibility rather than something left exclusively to privacy or legal teams.

Different parts of the organization play different roles. Senior management should promote a culture of data protection and ensure that appropriate policies, governance structures, and procedures are in place. Software engineers, system architects, product teams, and application developers should understand relevant data protection requirements and incorporate them into the systems, products, and services they design. These technical and organizational measures may also be scrutinized by supervisory authorities when assessing GDPR compliance and potential penalties.

Processors are not directly subject to Article 25 in the same way as controllers. However, Article 28 requires controllers to use only processors that provide sufficient guarantees that appropriate technical and organizational measures will be implemented so that processing complies with the GDPR and protects individuals' rights. Processor selection is therefore an important component of a controller's data protection by design strategy.

Recital 78 GDPR specifically encourages manufacturers, product developers, application developers, and service providers to consider the right to data protection when designing products and services involving personal data. Although Article 25 does not itself impose the controller's legal obligation on these providers, their design choices can significantly affect whether controllers and processors are able to meet their own GDPR obligations.

The controller remains accountable, but effective data protection by design requires participation across the organization and consideration of privacy and data protection throughout the technology supply chain.

What Does Data Protection by Design Look Like in Practice?

Data protection by design requires controllers to translate GDPR principles into practical technical and organizational measures. Depending on the nature and risks of the processing, examples may include:

• Minimizing personal data processing by collecting and using only the data necessary for the specified purpose;
• Pseudonymizing personal data as early as reasonably possible;
• Building transparency into systems so individuals can understand how their personal data is being processed;
• Providing individuals with meaningful controls that allow them to understand and manage relevant processing; and
• Designing, maintaining, and improving appropriate security safeguards throughout the life of the system.

Data protection by design and by default should ultimately be translated into practical, actionable measures that can be applied across the organization.

There is no single checklist or compliance program that will work for every controller. The appropriate approach depends on factors such as the nature of the organization and its processing activities, the risks to individuals, available resources, and the types of personal data involved.

The objective is to establish an organizational approach that produces appropriate data protection outcomes. In practice, this means ensuring that:

• Data protection is considered from the design stage of systems, services, products, and business practices and throughout their implementation and operation.
• Data protection is integrated into core functionality, rather than added as a separate compliance feature after development.
• Only necessary personal data is processed, and that data is used only for the specified purposes.
• Personal data is protected by default, without requiring individuals to take additional steps simply to obtain basic data protection.
• Responsibility for data protection is clearly assigned, with appropriate contact information available internally and, where required, to individuals.
• Information provided to individuals is clear and accessible, using plain language to explain how their personal data will be processed.
• Individuals are given meaningful tools and controls to understand and manage how their personal data is used.
• Privacy-protective defaults are implemented, accompanied by user-friendly choices and controls that respect individuals' preferences.

The specific documentation, policies, and organizational controls needed will vary. What matters is that the controller can show that data protection has been deliberately incorporated into the design, operation, and governance of the processing—and that the measures adopted are appropriate to the risks involved.

Additional Resources

GDPR Provisions

• Article 25 GDPR — Data Protection by Design and by Default 
• Article 28 GDPR — Processor. Relevant to the selection of processors that provide sufficient guarantees regarding appropriate technical and organizational measures.
• Article 47 GDPR — Binding Corporate Rules. Includes data protection principles and safeguards relevant to processing and international transfers within corporate groups.
• Recital 78  — Appropriate Technical and Organisational Measures*
• Recital 81 — Address processor safeguards.
• Recital 108 — Addresses appropriate safeguards for international transfers and expressly references data protection by design and by default.

European Data Protection Board (EDPB)

• Guidelines 4/2019 on Article 25 Data Protection by Design and by Default — The EDPB's principal guidance on interpreting and applying Article 25, including the elements controllers should consider when implementing data protection principles through technical and organizational measures.

Guidance from European Data Protection Authorities

• Spanish Data Protection Agency (AEPD) — Guide to Privacy by Design — Practical guidance on incorporating privacy and data protection requirements into the design of products, services, and processing activities.
• French Data Protection Authority (CNIL) — Software Development and Data Protection by Design and by Default — Practical resources for developers and organizations seeking to integrate GDPR requirements into software development.
• UK Information Commissioner's Office (ICO) — Data Protection by Design and Default — Guidance explaining how organizations can incorporate data protection into their systems, services, products, and business practices.

Related Background

• Privacy by Design — For additional background on the concept that preceded and influenced Article 25 GDPR, see The De La Torre Review's separate article: From Privacy by Design to Data Protection by Design: Principles and Practical Implementation

Academic Commentary

• Lina Jasmontaite, Irene Kamara, Gabriela Zanfir-Fortuna & Stefano Leucci, “Data Protection by Design and by Default: Framing Guiding Principles into Legal Obligations in the GDPR,” European Data Protection Law Review (2018). — Academic analysis of how Privacy by Design principles were transformed into binding legal obligations under the GDPR. DOI: 10.21552/edpl/2018/2/7