What does data protection by design require in system procurement?

In brief

Data protection by design and by default means that a system must support lawful, limited and secure processing before it is taken into use. In procurement, you turn General Data Protection Regulation (GDPR) Article 25 into concrete requirements for data fields, access rights, default settings, retention, user information, data subject rights and supplier duties. The controller remains responsible for showing that the processing meets the GDPR, even when a supplier builds or runs the system. If the purchase creates high risk, the order changes: the data protection impact assessment must be done before processing starts.

Procurement must turn Article 25 into practical requirements

A system procurement is often where data protection either becomes practical or stays as a policy document. GDPR Article 25 requires the controller to use appropriate technical and organisational measures when defining the means of processing and when processing itself takes place. In everyday language, the controller must decide how the system should work so that the GDPR principles are built into the workflow.

A technical measure is something the system does. An example is access control that limits an employee to the customer records needed for that employee’s work. An organisational measure is something the organisation does. An example is an approval rule for creating new user roles.

For procurement, Article 25 means that the request for proposal, requirement list and acceptance testing should cover data protection topics, not only features and price. The source is not only Article 25. GDPR Article 5 sets the principles, and Article 5(2) says the controller is responsible for showing compliance. GDPR Article 24 also requires the controller to implement measures that can ensure and demonstrate compliance, taking account of the nature, scope, context and purposes of processing and the risks to people.

A useful procurement requirement is therefore written as a work requirement, not as a slogan. For example:

Procurement question	Why it matters under the GDPR
What exact purpose does each data field serve?	Article 5 requires purpose limitation and data minimisation.
Who can see, change, export or delete personal data?	Articles 25 and 32 require suitable measures and security for the risk.
How are data subject requests handled in the system?	Articles 12–20 give people rights to access, rectification, erasure, restriction and portability.
What is the default retention time?	Article 5 requires storage limitation, and Article 13 requires information on retention or the criteria for it.
How does the supplier support breach handling?	Articles 33 and 34 set duties when a personal data breach occurs.

A personal data breach means a security event that affects personal data. A lost laptop with unencrypted customer records is a simple example. More on the reporting clock is covered in Personal data breach: the 72 hours start when an employee notices.

Necessity is visible in forms, default settings and retention

Data protection by default is the part of Article 25 that is easiest to miss in procurement. It is not only about cybersecurity. It is about what the system does before anyone changes a setting.

Article 25 requires that, by default, only personal data necessary for each specific purpose is processed. The same obligation covers the amount of personal data collected, the extent of processing, the storage period and access to the data. It also requires measures to ensure that personal data is not made available to an unlimited number of people by default without a person’s action.

In a procurement, this can be seen in simple places:

• A form should not make an optional personal identity code mandatory unless the purpose needs it.
• A search function should not show more people than the user needs for the task.
• A new user role should not get broad access by default.
• A default report should not include personal data that is not needed for the report’s purpose.
• A retention setting should support deletion or review when the data is no longer needed for the purpose.

The same thinking affects the privacy notice. GDPR Articles 13 and 14 require the controller to give people information about the purposes and legal basis of processing, recipients, retention, rights and certain transfers. If the system cannot describe where the data comes from, where it goes and how long it stays, the controller will struggle to give clear information.

Article 12 also matters at procurement stage. It requires information to be concise, transparent, easy to understand and easy to access. It also requires the controller to facilitate the exercise of data subject rights under Articles 15–22. That is a system requirement. The organisation needs a way to find a person’s data, correct it, restrict it, delete it when the conditions apply, and provide a copy when required. The one-month deadline for responding to requests under Article 12 is operational, so the system should not make the work impossible.

The legal basis for processing is a separate decision. A system feature does not create a legal basis by itself. The starting point is explained in What legal basis permits processing personal data?.

The supplier’s role must be decided before the contract

The supplier’s legal role changes the contract. A controller decides the purposes and means of processing. A processor processes personal data on behalf of the controller. If two or more controllers jointly determine the purposes and means, GDPR Article 26 treats them as joint controllers.

This role decision should be made before signature. If the supplier is a processor, GDPR Article 28 allows the controller to use only processors that provide sufficient guarantees for suitable technical and organisational measures. Article 28 also requires a contract or other legal act. The contract must set the subject and duration of processing, the nature and purpose of processing, the type of personal data, the categories of data subjects, and the controller’s obligations and rights.

For procurement, this affects questions such as:

• whether the supplier may use sub-processors;
• how the supplier follows documented instructions;
• how confidentiality is ensured for people who can access the data;
• how the supplier helps with data subject requests;
• how the supplier helps with security, breach notification and impact assessments;
• what happens to personal data when the service ends;
• what information the supplier provides to show compliance;
• whether audits or inspections are allowed.

International transfers must also be known early. GDPR Article 44 sets the general rule for transfers of personal data to a third country or an international organisation. Articles 45, 46 and 49 then describe adequacy decisions, appropriate safeguards and specific derogations. In procurement language, the controller needs to know where personal data will be processed and on what transfer basis. More on this topic is covered in When may personal data be transferred outside the EU?.

If the supplier relationship is unclear, the contract risk is unclear too. The Article 28 issue is discussed further in Controller or processor: when a data processing agreement is needed and what Article 28 requires.

High risk changes the procurement order

Some procurements need a data protection impact assessment (DPIA) before processing starts. GDPR Article 35 requires a DPIA when a type of processing is likely to result in a high risk to the rights and freedoms of natural persons, especially when new technology is used and the nature, scope, context and purposes are considered.

Article 35 names situations where a DPIA is required in particular. These include a systematic and extensive evaluation of personal aspects based on automated processing, including profiling, that leads to legal effects or similarly significant effects. They also include large-scale processing of special categories of personal data or data on criminal convictions and offences, and large-scale systematic monitoring of a publicly accessible area.

A DPIA is not a formality after the system is live. Article 35 says it is done before processing. If a data protection officer (DPO) has been appointed, the controller must seek advice from the data protection officer when carrying out the DPIA.

The minimum contents also matter for procurement. Article 35 requires a systematic description of planned processing and purposes, an assessment of necessity and proportionality, an assessment of risks to people’s rights and freedoms, and planned measures to address the risks. Those measures include safeguards, security measures and mechanisms for showing GDPR compliance.

This means that the DPIA can change requirements. It may require narrower access, shorter retention, stronger logging, a different workflow, clearer human review, or a decision not to use a feature. A practical explanation is available in Data protection impact assessment: when a DPIA is mandatory and what goes into it.

AI procurement may also need a fundamental rights impact assessment

An artificial intelligence purchase can add another assessment. The AI Act (EU) 2024/1689 Article 27 requires a fundamental rights impact assessment (FRIA) for certain deployers before the first use of a high-risk AI system. A deployer is the organisation that uses the system in its own processes.

Article 27 covers deployers that are public-law bodies or private entities providing public services. It also covers deployers of high-risk AI systems referred to in Annex III point 5(b) and point 5(c). The same paragraph excludes high-risk AI systems intended for use in the area listed in Annex III point 2.

The FRIA must describe the deployer’s processes where the high-risk AI system is used, the intended period and frequency of use, the categories of people and groups likely to be affected, specific risks of harm to those people or groups, human oversight measures, and measures to take if risks materialise. Article 27 also requires the deployer to notify the market surveillance authority of the results after the assessment is completed, unless the Article 46(1) situation applies.

The GDPR and the AI Act can meet in the same procurement. Article 27 says that if an obligation has already been met through a DPIA under GDPR Article 35, the FRIA supplements that DPIA. In practical terms, the organisation should not run two isolated assessment tracks. The personal data risks and the broader fundamental rights risks should be connected before the system is first used.

AI use at work raises separate questions about what employees may enter into tools. That topic continues in What may employees enter into an AI tool at work?. High-risk AI deployer duties are covered in High-risk AI: what a deployer must do before December 2027.

What the obligation does not mean

Data protection by design does not mean that every system must use the same technical solution. GDPR Article 25 is risk-based. It refers to the state of the art, implementation costs, the nature, scope, context and purposes of processing, and risks to people’s rights and freedoms. A small internal tool and a large public-facing service can therefore need different measures.

It also does not mean that a supplier’s product sheet is enough. GDPR Article 5(2) and Article 24 keep the controller responsible for being able to show compliance. A certificate under Article 42 can be used as one factor under Article 25, but the procurement still needs requirements, records and decisions that fit the processing.

It does not mean that all personal data must always be deleted when a person asks. GDPR Article 17 gives a right to erasure when one of the listed grounds applies, but it also contains exceptions. A system should support deletion where required, but the organisation still has to decide the legal ground for each case.

It does not remove the need for security under GDPR Article 32. Article 25 is about embedding data protection principles into processing. Article 32 separately requires a level of security appropriate to the risk, including measures such as pseudonymisation and encryption, the ability to ensure confidentiality, integrity, availability and resilience, restoration after an incident, and regular testing and evaluation of measures.

Finally, it does not make the data protection officer the owner of the procurement. GDPR Articles 37–39 describe when a data protection officer is appointed, the role’s position and tasks. Article 39 includes advising and monitoring, including advice on DPIAs when requested. The controller still decides and must be able to show what was decided and why.