Article 25 of the GDPR turns "privacy by design" from a slogan into an obligation. It requires controllers to build data protection into how processing is designed, and to set defaults that process only what is necessary. It applies to every controller, for every processing activity.
The obligation is easy to agree with and hard to evidence. Ask an engineering team how they meet it and the answer is often a general commitment to caring about privacy. Ask what record shows that a particular feature was designed with Article 25 in mind, and the answer is often silence.
This article sets out what Article 25 says, how the EDPB interprets it, and how to make it a visible step in your development process rather than an intention.
What Article 25 requires
Article 25 contains two obligations and a way to help demonstrate them.
Data protection by design (Article 25(1)). Taking into account the state of the art, the cost of implementation, the nature, scope, context, and purposes of processing, and the risks to individuals, the controller must implement appropriate technical and organizational measures. Those measures must be designed to implement the data protection principles effectively and to integrate the necessary safeguards. The controller must do this both when it determines the means of processing and during the processing itself. Pseudonymization is the example measure the article gives. Data minimization is the example principle.
Data protection by default (Article 25(2)). The controller must implement measures ensuring that, by default, only personal data necessary for each specific purpose is processed. That applies to the amount of data collected, the extent of processing, the period of storage, and accessibility. In particular, personal data must not be made accessible to an indefinite number of people by default, without the individual's intervention.
Certification (Article 25(3)). An approved certification mechanism under Article 42 may be used as an element to demonstrate compliance.
Three features of the text matter in practice:
It binds the controller. Processors and product vendors are not directly subject to Article 25. Recital 78 encourages producers of products, services, and applications to take it into account, and Article 28(1) requires controllers to use only processors that provide sufficient guarantees. If you sell software to controllers, they will pass the expectation to you.
It is continuous. "At the time of the processing itself" means the obligation does not end at launch.
It is risk-based, but not optional. Cost and the state of the art affect which measures are appropriate. They do not excuse having none.
How the EDPB reads it
The EDPB's Guidelines 4/2019 on Article 25 add points that change how you should approach it.
Effectiveness is the test. Measures must actually implement the principles. A policy that says "we minimize data" is not a measure unless something in the system or the process enforces it. The guidelines expect controllers to be able to demonstrate effectiveness, and suggest key performance indicators as one way.
Every principle is in scope. Article 25 is not only about minimization and security. The guidelines work through each principle in Article 5: transparency, lawfulness, fairness, purpose limitation, data minimization, accuracy, storage limitation, and integrity and confidentiality. For each, they list design and default elements a controller might implement.
Defaults include configurable settings. "By default" covers the pre-set values and options in a system, such as a profile visibility setting, an optional field, or a retention period. The default should allow only the processing the purpose needs. Anything beyond that should require the individual to choose it.
Where it shows up in a SaaS product
Abstract principles become concrete at a small number of decision points. These are the ones worth checking on every relevant change.
Collection. Which fields are required and which are optional, whether optional fields start empty, and whether free-text fields invite data you do not need. A full minimization review is its own exercise. Article 25 asks that the review takes place.
Visibility and sharing. Whether new workspaces, profiles, files, or links default to private. Article 25(2) singles out accessibility to an indefinite number of people, which maps directly onto public-by-default links.
Internal access. Whether your own staff can see customer data by default, or only through a logged, time-bound grant.
Retention. Whether a new data store ships with a deletion rule, or whether deletion is a later ticket that never lands.
Logging and analytics. Whether events carry raw identifiers or pseudonymous ones, and whether logs capture request bodies that contain personal data.
Third parties. Whether a feature sends data to a new vendor, and whether that was a design decision or a side effect of an SDK.
Each of these is cheaper to decide at design time than to retrofit. That is the practical argument for Article 25, separate from the legal one.
Building it into your development process
The aim is that every change touching personal data passes a short, recorded privacy check, without turning each pull request into a legal review.
Define the trigger. A change needs a privacy check if it collects new personal data, uses existing data for a new purpose, changes who can see data, adds a recipient or vendor, or changes retention. Put the trigger in your design document template or ticket type.
Use a short checklist. One question per decision point above. Most answers will be "no change". The record of those answers is the evidence.
Escalate on thresholds. Certain answers route the change to a DPIA screening. A new purpose or recipient updates the record of processing.
Review defaults in code review. A change that adds a setting is reviewed for its default value as well as its behavior. Name the reviewer role.
Keep the record with the change. The checklist answers live in the design document, ticket, or pull request, dated and attributed, so they can be retrieved later without reconstruction.
What evidence looks like
When a supervisory authority, a customer, or your ISO 27701 auditor asks how you meet Article 25, a statement of intent will not satisfy them. These will:
a documented privacy-by-design procedure that names the trigger, the checklist, and the escalation path,
completed checklists on a sample of recent changes,
DPIA screenings that the process triggered,
configuration showing protective defaults for visibility, retention, and sharing, and
training records for the engineers and product managers who run the checklist.
The honest concession is that this produces paperwork, and most of it records "no change". That is the point. It shows the question was asked each time, which is what an obligation that applies "at the time of the determination of the means for processing" requires.
What people get wrong is treating Article 25 as a launch gate only. A feature that passed review two years ago may now feed a new analytics pipeline or a new vendor. The check belongs on the change, whenever it happens.
Article 25 is principle-based, so what counts as appropriate for your processing involves judgment. Confirm your approach for higher-risk processing with counsel.
How TrustLynce helps
TrustLynce's policy management versions your privacy-by-design procedure and tracks acceptance by the engineers who apply it. Evidence collection gathers change records from your code systems on a schedule, timestamped and attributed, so a sample of privacy checks is ready when someone asks for it.