Home | Blog |

2. October 2026

Privacy by Design: Data Protection by Design and Privacy-Enhancing Technologies (PETs)

Kategorien: ,

Art. 25 GDPR obliges controllers to treat data protection not as an afterthought, but as an integral part of system design . The principle of “privacy by design” requires technical and organisational measures to be taken into account as early as the design of processing activities, from development and procurement to ongoing operation.

For companies, this means: Data protection is not a task limited to drafting privacy notices or maintaining a record of processing activities. It is part of the system architecture itself. Where this integration does not take place, the result is not only regulatory risk but also structural weaknesses in data processing, which can only be remedied retrospectively at considerable effort.

This article systematically classifies the legal requirements of Art. 25 GDPR , explains their practical implementation on the basis of the relevant data protection principles and presents the most important privacy-enhancing technologies (PETs) that can be used to implement these requirements technically.

The legal framework: Structure of Art. 25 GDPR

Art. 25 GDPR is divided into two independent but interrelated provisions.

Privacy by design (Art. 25(1) GDPR)

Taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing, the controller shall implement appropriate technical and organisational measures, designed to implement the data protection principles effectively and to integrate the necessary safeguards into the processing itself. The likelihood and severity of the risks to the rights and freedoms of natural persons posed by the processing are also decisive; the provision thus follows a risk-based approach.

The decisive factor is the reference point of the obligation: it is not directed at the finished system, but at its development process. It covers both the time of determining the means of processing and the time of the processing itself.

Privacy by default (Art. 25(2) GDPR)

The controller must ensure, through appropriate technical and organisational measures, that by default, only personal data which are necessary for each specific purpose of the processing are processed. This obligation applies to the amount of data collected, the extent of their processing, the period of their storage and their accessibility. No processing beyond what is necessary may take place without the active intervention of the data subject.

The dynamic element: State of the art

Both paragraphs refer to the “state of the art” as a benchmark. This is deliberately not a static standard: what is considered an appropriate safeguard today may be inadequate in two years’ time, because technical possibilities and attack scenarios continue to evolve. For companies, this results in an obligation to continuously evaluate their technical safeguards; privacy by design is not a one-off project, but a continuous process.

Place within the sanctions regime

Art. 25 GDPR is designed as a cross-cutting provision: a violation of the requirements of data protection by design regularly also affects compliance with the principles of Art. 5 GDPR and the security requirements of Art. 32 GDPR . In their enforcement practice, supervisory authorities have repeatedly made it clear that inadequate technical design, for example in consent management or deletion routines, is treated as a separate offence subject to fines under Art. 83(4) GDPR .

Data protection principles as the benchmark for technical design

Art. 25 GDPR refers to the principles of Art. 5 GDPR as the substantive benchmark for technical design. For practical implementation, eight areas of requirements can be derived from this, which must be taken into account in all phases of processing: design, procurement, development, testing, operation, maintenance and deletion.

  • Transparency. Data subjects must be informed clearly and comprehensibly about the collection, use and disclosure of their data. Technically, this means, among other things, that information flows within a system must be designed in such a way that transparency obligations can be fulfilled at all, for example through traceable logging of processing steps.
  • Lawfulness. Before a processing activity begins, there must be an appropriate legal basis that continues to exist throughout the entire processing life cycle. Systems must be designed in such a way that changes to the legal basis, for example when consent is withdrawn, actually lead to an adjustment of the processing.
  • Fairness. Data subjects must be enabled to exercise their rights through appropriate system settings. Furthermore, the highest possible degree of autonomy over one’s own data must be preserved; this applies in particular to the design of user interfaces and setting options.
  • Purpose limitation. The technical architecture must ensure that data is processed exclusively for the specified purposes. A change of purpose must not take place merely through modified analysis logic without the legal requirements being re-examined.
  • Data minimisation. The amount of data processed must be limited to what is necessary for the purpose. This applies to collection as well as to storage and further processing; systems should be designed so that they structurally do not retain excess data.
  • Accuracy. System design must ensure that inaccurate data can be rectified or erased without delay. This requires appropriate technical correction mechanisms.
  • Storage limitation. Personal data may only be stored for as long as is necessary for the purpose of processing. Technically, this requires automated deletion routines or retention concepts embedded in the system architecture; a manual “delete when convenient” approach generally does not meet the requirements.
  • Integrity and confidentiality. Appropriate technical design must ensure that processed data is protected against unauthorised or unlawful processing and against loss or destruction. In terms of content, this principle overlaps with the requirements of Art. 32 GDPR and marks the interface with technical safeguards in the narrower sense, including the privacy-enhancing technologiesdescribed below.
Programmer implementing privacy-enhancing technologies

Privacy-enhancing technologies

Privacy-enhancing technologies (PETs) are software and hardware solutions that make it possible to process or analyse personal data without compromising the confidentiality of the underlying information or the identifiability of data subjects. They therefore represent a technical toolkit for implementing the principles described above, in particular data minimisation as well as integrity and confidentiality.

The European Union Agency for Cybersecurity (ENISA) defines PETs as technologies that support privacy features, for example by implementing privacy design strategies or by taking into account specific protection goals of privacy engineering. This definition makes it clear that PETs are not a closed catalogue of fixed technologies, but a functional concept: it covers any technical procedure that structurally contributes to achieving data protection objectives.

PETs are currently gaining particular practical relevance in connection with the use of artificial intelligence (AI). Since AI systems regularly rely on large, often personal, data sets, the question arises as to how the use of AI systems can be reconciled with the requirements of data minimisation and purpose limitation. PETs offer technical solutions for this that enable data to be used without undermining data protection principles.

The basic distinction: Input privacy and output privacy

PETs can be divided into two fundamental categories, which are based on different phases of data processing.

PETs in the category of input privacy aim to significantly reduce the number of parties who have access to the personal data being processed. In practice, this means that input privacy enables two or more parties to contribute data to a computation without the other parties being able to see the data in plain text. This is particularly relevant for data collaborations between several controllers where an exchange of raw data is not legally permissible or not desired.

Output privacy is intended to prevent (sensitive) data in the data output from being attributed to the data subjects. This category becomes particularly important when analysis results are to be published, shared with third parties or provided as anonymous statistics. The underlying individual data may be personal; what matters is that the published output does not allow re-identification.

This distinction is of practical importance for selecting suitable PETs: a company that wants to process personal raw data jointly with an external partner needs different technical solutions than a company that merely wants to publish aggregated analysis results.

Significance for business practice

The implementation of privacy by design and the use of suitable PETs are not limited to fulfilling a legal obligation. From both a legal and a strategic perspective, three levels of impact can be distinguished.

  • Legally compliant use of data. Well-designed technical solutions not only reduce the risk of objections from supervisory authorities, but also create the legal basis for carrying out certain data processing operations in a legally compliant manner in the first place, particularly in connection with AI applications or data collaborations.
  • Trust as a competitive factor. In industries with sensitive data, such as health, finance and HR, demonstrable data protection is increasingly becoming a selection criterion for business partners and customers.
  • Access to new forms of data use. PETs make it possible to work with particularly sensitive categories of data.

Recommendations

A structured approach is recommended for practical implementation:

  1. Stocktaking. Review which technical settings have already been made in existing systems and to what extent they meet the requirements of Art. 25 GDPR .
  2. Risk-based selection of measures. Implementation of appropriate technical and organisational measures, taking into account the respective processing risks.
  3. Technology selection. Review which PETs are suitable for the respective processing situation and compatible with the existing technical infrastructure.
  4. Continuous monitoring. Monitoring of further developments and industry-specific standards in order to do justice to the dynamic nature of the “state of the art”.

Conclusion

Privacy by design is not an isolated compliance task, but a systematic design principlethat transfers the data protection principles of Art. 5 GDPR into the technical architecture of processing activities. The privacy-enhancing technologies described provide an increasingly sophisticated technical toolkit for this, enabling companies to treat data use and data protection not as opposites, but as compatible objectives.

We will be happy to support you in reviewing your existing systems and implementing privacy by design in your company.

Contact

FAQ: Frequently asked questions about privacy by design

What is privacy by design?

Privacy by design (data protection by design) means that data protection is integrated as early as the development and design of IT systems. Data protection is not an afterthought, but an integral part of the system architecture throughout the entire life cycle of data processing.

What is the difference between privacy by design and privacy by default?

The difference lies in the starting point: Privacy by design requires data protection to be structurally embedded in the IT architecture during development. Privacy by default (privacy-friendly default settings) requires a system to be configured by default so that only the data that is strictly necessary is processed without any active intervention by the user.

Is privacy by design required by law?

Yes, privacy by design is legally binding. The legal basis is Art. 25(1) of the General Data Protection Regulation (GDPR). Controllers are therefore legally obliged to implement appropriate technical and organisational measures in order to build the data protection principles effectively into their systems.

What happens if the requirements for privacy by design are not met?

Supervisory authorities penalise violations of the requirements for technical design as a separate offence subject to fines under Art. 83(4) GDPR . In addition to substantial fines, non-compliance creates structural security risks that can often only be remedied retrospectively at extremely high financial and technical cost.

What needs to be considered with regard to AI and privacy by design?

AI systems require huge amounts of data, which quickly conflicts with the GDPR principle of data minimisation. To ensure privacy by design in artificial intelligence, privacy-enhancing technologies (PETs) must be used. These technical solutions enable AI training with personal data without jeopardising the identifiability of data subjects.

What are privacy-enhancing technologies (PETs)?

Privacy-enhancing technologies (PETs) are privacy-friendly technologies and software solutions. They enable the joint analysis and processing of personal data without disclosing its confidentiality. PETs are divided into input privacy (protection of the raw data contributed) and output privacy (protection against re-identification in the results).

How can companies implement privacy by design in practice?

For implementation in compliance with Art. 25 GDPR, a structured four-step process is recommended:

  1. Stocktaking: Analysis of existing systems for legal and technical deficiencies.
  2. Risk assessment: Selection of safeguards based on the specific processing risks.
  3. Technology selection: Implementation of suitable privacy-enhancing technologies (PETs).
  4. Monitoring: Continuous adaptation of systems to the current “state of the art”.
Who is liable for violations of privacy by design if a company purchases ready-made standard software from a third-party provider?

The data protection obligation under Art. 25 GDPR primarily applies to the purchasing company as the controller. Before using the software, it must check whether it offers privacy-friendly default settings; in the event of deficiencies, the company is liable to the authorities, but may, under certain circumstances, take contractual recourse against the software manufacturer.

Questions?

We look forward to hearing from you regarding this and other matters!

Get in touch

More Posts

Hand mit Cloud- und Schloss-Symbol als Sinnbild für die NIS-2-Pflichten von SaaS-Anbietern

NIS2 for Software Companies: When Your SaaS Business Must Report Incidents

IT Law · Digital Law Series, Part 3 | Part 1: Product Liability for Software | Part 2: Cyber Resilience ... Read more
Cyber Resilience Act: Schutzschild mit Schloss auf einer Platine als Symbol für sichere Software und vernetzte Produkte

Cyber Resilience Act: What Software and SaaS Providers Need to Implement Now

IT Law · Digital Law Series, Part 2 | Part 1: Product Liability for Software | Part 3: NIS2 ·As ... Read more
System Hacked Warnmeldung auf Bildschirm bei kritischem Softwarefehler

Product Liability for Software: Why Your Code Will Be Liable Like a Machine from December 2026

IT Law · Digital Law Series, Part 1 | Part 2: Cyber Resilience Act | Part 3: NIS2 · As ... Read more