Technical Measures for GDPR Compliance: What Exactly Needs to Be Done?

Why Are Technical Measures Important for GDPR?

In the twenty-first century, personal data has become a valuable asset requiring the same reliable protection as finances or intellectual property. In the European Union, the General Data Protection Regulation (“GDPR,” “the Regulation”) establishes key requirements for businesses regarding the security of personal data processing.

GDPR compliance is often perceived as a set of policies and procedures. However, genuine GDPR compliance does not begin with documents — it begins with technology. Without proper technical solutions, even the most carefully drafted processes will not protect a business from risks and fines.

This is why the so-called “technological GDPR” (the set of technical measures and requirements enshrined in the Regulation) should be regarded as a fundamental prerequisite for real data protection.

In this article we will examine the technical measures provided for by the GDPR and the practical aspects of their implementation in accordance with the recommendations of the European Data Protection Board. We will also show why it is technological solutions that ensure genuine security and which steps should be integrated into internal business processes.

In Which Article of the GDPR Are Technical Measures Mentioned?

Article 5 of the GDPR establishes the principle of security in the processing of personal data. To implement this principle, a company must demonstrate — not only on paper, but technically — that personal data is protected.

The key provisions regarding technical requirements are enshrined in the Regulation itself. Among the controller’s obligations, the principles of “privacy by design” and “privacy by default” (Article 25) are mentioned, requiring the technical construction of data protection processes at all stages, starting from project planning.

The basic solutions among the “organizational and technical measures,” taking into account the recommendations of Article 32, include:

• encryption and pseudonymization,
• role-based access control with multi-factor authentication,
• continuous security monitoring and logging,
• regular testing and auditing of information systems,
• backup, and
• an incident recovery plan.

But it is not quite that simple. This is not a clear list of measures to be implemented in internal business processes for compliance. It is rather a pointer — indicating which aspects must definitely be taken into account, while the measures themselves are chosen by the company. Because the GDPR requires the application of “appropriate technical measures.”

How to Choose the Required Set of Technical Solutions?

The choice of measures is not arbitrary — it is always based on a risk assessment. European courts emphasize that the adequacy of measures is assessed “in concreto” and “on a case-by-case basis,” that is, depending on the circumstances of the specific company. The choice must also be based on the current “state of the art,” the company’s costs, the scale and purposes of processing, and above all — the real risks to individuals.

For example: the Italian regulator held the controller company Postel S.p.A. liable for failing to update Microsoft Exchange server software despite known vulnerabilities. The fine was imposed for non-compliance with Article 32 of the GDPR because “state of the art” security measures had not been applied, even though they had already been publicly recommended at that time. This shows that even when a threat has become known, the absence of an active response provides grounds for sanctions.

Significant attention should also be paid to continuous risk management.

In the case involving malicious attacks, the company Sandbox Interactive GmbH avoided sanctions precisely because, prior to the attack, it had already implemented modern measures: HTTPS encryption, two-factor authentication, and bcrypt password hashing. The attacker exploited a vulnerability in third-party software, but the regulator acknowledged that the controller had applied all “appropriate technical measures” and therefore bore no liability. A different situation arose in the case of Pieces Interactive AB. There, the protection was selective: the website pages containing contact forms did not have HTTPS. The result was a violation of Article 32 and a fine. The measures applied were, in the regulator’s view, insufficient.

Who is responsible?

The GDPR leaves no doubt: the data controller bears primary responsibility for security, and no references to contractors or previous owners relieve them of the obligation to act.

Privacy by Design and Privacy by Default in More Detail

Article 25 of the GDPR requires a company to embed data protection principles into the very architecture of the product (“privacy by design”) and to guarantee the minimization of collection and processing by default (“privacy by default”).

In practice, this may look as follows:

privacy by default — A new mobile application by an online ticket sales company collects only the data without which the service cannot be provided, while all optional fields (for example, information about marital status) are disabled until the user’s explicit consent.

privacy by design — In a startup that analyzes traffic movement, GPS data is immediately pseudonymized: only coordinates are stored without direct identifiers, and the decryption key is kept separately and automatically rotated.

An example of a violation of the principles of privacy by design and privacy by default is the case involving the introduction of a “tourist tax” by the city authorities of Venice. The city council was fined €10,000 for excessively collecting personal data from persons who were exempt from paying the tax. The verification system was excessively complex. The data collection steps duplicated information, and the payment kiosks had auto-fill settings that allowed other people’s data to be seen. In conclusion, privacy must be thought through and built into the architecture of a project from the very beginning of its launch.

Encryption

Pursuant to the GDPR, encryption is one of the main ways of “ensuring the confidentiality, integrity, and availability of personal data.” It is a real instrument that often determines whether an incident will be classified as a “data breach.” For example, the European Data Protection Board in its recommendations (Guidelines 01/2021 on Examples regarding Personal Data Breach Notification) notes that if stolen data was protected by a modern encryption algorithm and the keys were stored separately, the incident may not require notification of data subjects. The risk of identification in such a case is minimal.

Pseudonymization

Pseudonymization involves replacing real personal data (names, age, etc.) with unique codes or hashes, the decryption key to which is stored separately. Only when necessary can the controller re-establish who is who. Such data legally remains personal data and is subject to all GDPR requirements. It is actively used by banks, medical institutions, and marketing companies when it is necessary to analyze customer behavior without revealing the identity of each individual at every stage.

Questions also frequently arise regarding anonymization, but that is a different story. After a proper anonymization procedure, the connection with a specific individual is irreversibly lost. Such data is no longer considered personal data. An example is the aggregated statistics of mobile operators on population movements during epidemics, where only the dynamics of flows matter, not individual people.

The key challenge for business is to correctly choose the approach to protect data.

Logging

Logging (the collection of technical files) is also a mechanism for proving that a company controls the processing of personal data. Article 32 of the GDPR directly obliges the demonstration of “integrity and availability,” and without logs this is almost impossible to prove.

The Swedish supervisory authority (DPA) issued a warning to the company Verisure for insufficient log retention, which made it impossible to trace possible misuse of personal data from cameras in private homes. Although no actual unauthorized data sharing was recorded, the DPA emphasized that for the processing of data of such sensitivity, high-level technical and organizational measures are required, including proper logging. The violation was found to be minor, so the company was only officially warned.

Well-configured logging, in the event of an incident, provides answers as to who, when, and how accessed data. This means it helps not only to quickly localize an attack, but also to prove to the regulator that the controller genuinely fulfilled the obligation to “ensure the security of processing” under Article 32 of the GDPR.

Monitoring

Article 32 of the GDPR directly requires the controller and processor to implement “procedures for regularly testing, assessing, and evaluating the effectiveness of technical and organizational security measures.” In other words, the protection system must operate in a mode of continuous monitoring. Indeed, without continuous oversight a company is unable to detect an incident in time and limit its consequences — and this in itself already constitutes a violation.

In practice, monitoring is an entire system of intrusion detection and prevention, automatic alerts about suspicious actions, regular vulnerability scans, and penetration testing.

Regulators are increasingly emphasizing that the absence of controls or untimely updating of notification rules is equated with “absence of security measures” within the meaning of Article 32.

How to Avoid Security Incidents?

The company must be in a state of constant readiness. No policy or lengthy register of internal procedures will save data if the infrastructure cannot withstand an attack. Genuine security is guaranteed only by technological solutions embedded in business processes from day one. This means that continuous software updates, multi-factor authentication, network segmentation, backup, and monitoring must be part of the company’s infrastructure.

Conclusion

Supervisory authorities assess the real effectiveness of technical measures in light of the current state of the art, the volume of processing, and the risks to the rights of individuals. If a company can demonstrate that it has conducted penetration testing, implemented multi-factor authentication, maintains signed logs, and regularly reviews its response plan, it has a chance of surviving even a large-scale attack without sanctions.

This is why genuine data protection does not begin with tick-box policies, but with technological solutions embedded in the very architecture of business processes.

Who Can Help with Planning the Technical Measures of a GDPR Compliance Program?

Legal IT Group combines expertise in the field of data protection with a practical understanding of how business operates in the digital environment. We help companies implement practical and effective solutions for GDPR compliance — not only on paper, but in real business processes.

Our team supports every stage of compliance: from technical implementation in your IT infrastructure to organizational and marketing measures, ensuring that all documents and processes meet the highest regulatory standards.

Through this comprehensive approach, Legal IT Group helps organizations avoid fines and create a transparent, secure, and reliable data management system.