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

Why Are Technical Measures Important for GDPR Compliance?

In the 21st century, personal data has become a valuable asset that requires the same level of protection as finances or intellectual property. Within the European Union, the General Data Protection Regulation (the “GDPR”) establishes the core obligations for businesses regarding the security of personal data processing.

Compliance with GDPR is often perceived as a set of policies and procedures. However, true compliance begins not with documentation, but with technology. Without adequate technical safeguards, even the most carefully drafted procedures cannot fully protect a business from risks and potential fines.

This is why the so-called “technical GDPR”,  a set of technical measures and requirements embedded in the GDPR,  should be regarded as the foundation of genuine data protection.

In this article, we will examine the technical and organisational measures envisaged by the GDPR and discuss practical aspects of their implementation, based on the recommendations of the European Data Protection Board (the “EDPB”). 

Which Article of the GDPR Refers to Technical Measures?

Article 5 of the GDPR sets out the principle of security of processing. To comply with this principle, a company must demonstrate both on paper and technically  that personal data is protected.

The key provisions concerning technical safeguards are embedded throughout the GDPR. Among the controller’s obligations are the principles of “privacy by design” and “privacy by default” (Article 25), which require the integration of data protection into processing activities and systems from the very outset of a project.

According to Article 32, examples of appropriate organisational and technical measures include:

• encryption and pseudonymisation,
• role-based access control with multi-factor authentication,
• continuous security monitoring and logging,
• regular testing and auditing of information systems,
• data backup procedures, and
• incident response and recovery plans.

However, it is important to understand that GDPR itself does not prescribe a fixed checklist of mandatory actions. Instead, it provides a framework indicating which aspects must be considered, leaving each organisation to determine the specific measures suitable for its context. GDPR requires the implementation of “appropriate technical and organisational measures”  meaning that the level of protection must correspond to the nature, scope, and risks of the processing.

How to Choose the Right Set of Technical Measures

The choice of technical safeguards is never arbitrary. It must always be based on a comprehensive risk assessment. European courts have repeatedly emphasised that the adequacy of measures must be evaluated “in concreto” and “on a case-by-case basis”, meaning that it depends on the specific circumstances of each organisation.

When determining the right level of protection, companies should consider the state of the art, the implementation costs, the nature, scope and purposes of the processing, and, most importantly, the actual risks to individuals’ rights and freedoms.

For example, the Italian supervisory authority held the controller Postel S.p.A. liable for failing to update its Microsoft Exchange server software despite known vulnerabilities. The company was fined under Article 32 GDPR for not applying “state of the art” security measures that had already been publicly recommended at the time. This case demonstrates that once a threat becomes known, inaction or delayed response can justify sanctions.

Another essential principle is continuous risk management.

In a case involving malicious attacks, Sandbox Interactive GmbH avoided penalties because it had already implemented modern safeguards prior to the incident — including HTTPS encryption, two-factor authentication, and bcrypt password hashing. The attacker exploited a vulnerability in third-party software, but the regulator concluded that the controller had adopted all “appropriate technical measures” and therefore was not at fault.A contrasting example is the Pieces Interactive AB case, where website pages containing contact forms lacked HTTPS protection. The supervisory authority found a violation of Article 32 GDPR and imposed a fine, stating that the measures in place were insufficient and failed to ensure a secure level of data protection.

Who Is Responsible?

The GDPR leaves no room for doubt – the data controller holds primary responsibility for security, and relying on contractors or previous owners does not absolve them from their duty to act.

Privacy by Design and Privacy by Default

Article 25 of the GDPR requires organisations to embed data protection principles into the very architecture of their products (“privacy by design”) and to ensure that, by default, only the minimum amount of personal data necessary for each specific purpose is processed (“privacy by default”).

In practice, this can be illustrated as follows:

• Privacy by Default:

A new mobile ticketing app collects only the personal data strictly required to provide the service. All optional fields, such as marital status or preferences, are disabled by default and can only be activated through the user’s explicit consent.

• Privacy by Design:

A transport analytics start-up implements pseudonymisation at the data collection stage: GPS data are stored without direct identifiers, while the decryption key is kept separately and rotated automatically.

A real-world example of non-compliance comes from the Venice City Council, which was fined €10,000 in relation to the implementation of a “tourist tax” system. The city’s data collection process was excessively complex and disproportionate. Duplicate information was collected from users, and payment kiosks used auto-fill settings that inadvertently exposed other users’ data. This case demonstrates how failing to design systems with privacy in mind can directly result in regulatory sanctions.Ultimately, privacy must be designed and built into a project’s architecture from the very beginning, not added as an afterthought.

Encryption

Under the GDPR, encryption is one of the primary ways to ensure the confidentiality, integrity, and availability of personal data. It’s a practical tool that can determine whether a security incident qualifies as a “data breach”. For example, the European Data Protection Board notes in its Guidelines 01/2021 on Examples regarding Personal Data Breach Notification that if stolen data were encrypted with a modern algorithm and the keys were stored separately, the incident may not require notifying data subjects. In such cases, the risk of identification is minimal.

Pseudonymisation

Pseudonymisation replaces real personal data, such as names or ages, with unique codes or hashes, while the keys for decryption are kept separately. The controller can re-identify individuals only when necessary. Legally, these remain personal data and are fully subject to GDPR requirements. Banks, healthcare providers, and marketing companies often use pseudonymisation to analyse customer behaviour without revealing identities at every stage.

It’s worth noting the difference with anonymisation. Once done correctly, anonymised data can no longer be traced back to a person and is no longer considered personal data. A good example is aggregated mobile operator statistics on population movements during epidemics, where only flow patterns matter, not individual identities. 

The key challenge for businesses is to choose the right approach to protect data effectively.

Logging

Logging (the collection and maintenance of technical records) is also a critical way to prove that a company is controlling personal data processing. Article 32 of the GDPR explicitly requires controllers and processors to ensure the “integrity and availability” of data. Without logs, demonstrating compliance with this obligation is nearly impossible.

The Swedish Data Protection Authority (IMY) issued a formal warning to Verisure Sverige AB for insufficient log retention, which made it impossible to trace potential misuse of personal data captured by home security cameras. Although no unlawful data sharing was identified, the IMY stressed that the processing of such sensitive information requires robust technical and organisational measures, proper logging being one of them. The breach was deemed minor, and the company received an official warning rather than a fine.

Well-structured logging can answer the critical questions who, when, and how in the event of a security incident. It enables not only rapid containment but also provides evidence to the regulator that the controller has fulfilled its obligation to “ensure the security of processing” under Article 32 GDPR.

Monitoring

Article 32 of the GDPR explicitly requires controllers and processors to implement “procedures for regularly testing, assessing, and evaluating the effectiveness of technical and organisational security measures”. In other words, your protection system must operate under continuous monitoring. Without it, a company cannot detect incidents in time or limit their impact – which in itself constitutes a breach.

In practice, monitoring means a complete system for detecting and preventing intrusions, including automatic alerts for suspicious activity, regular vulnerability scans, and penetration testing.

Supervisory authorities increasingly emphasise that the absence of monitoring, or failing to update alert rules promptly, is equivalent to having no security measures at all under Article 32.

How to Prevent Security Incidents?

A company must operate in a state of constant readiness. No internal policy or procedure will protect personal data if the technical infrastructure cannot withstand an attack. True security comes from technical solutions embedded directly into business processes from day one. This includes regular software updates, multi-factor authentication, network segmentation, encrypted backups, and real-time monitoring. Only such integrated measures can prevent, detect and contain breaches effectively.

Conclusion

Supervisory authorities assess the real effectiveness of technical measures by looking at the current state of technology, the scale of processing, and the potential risks to individuals’ rights. If a company can demonstrate that it has conducted penetration testing, implemented multi-factor authentication, maintains signed audit logs, and regularly tests its incident response plan – it stands a strong chance of withstanding even a major cyberattack without penalties.

That’s why true data protection doesn’t start with “tick-the-box” policies. It starts with technology-driven solutions that are built into the very architecture of your business processes.

Who can help you design an effective GDPR compliance programme?

Legal IT Group combines deep expertise in data protection with a hands-on understanding of how businesses operate in the digital environment. We help companies implement practical and effective GDPR solutions – not just on paper, but in real workflows.

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

With this comprehensive approach, Legal IT Group helps organisations avoid fines and build a transparent, secure, and trusted data management ecosystem.