How To Fulfill The Security Requirements Of A GDPR Data Protection Impact Assessment (DPIA

In late 2025, Spain’s data protection authority fined AENA just over €10 million in connection with its use of biometric facial-recognition systems at airports. The case raised concerns around the organisation’s data protection impact assessment (DPIA), including how it assessed the necessity, proportionality and risks of the processing. The authority also imposed corrective measures in relation to the processing.

If you have ever signed off a DPIA and then felt that quiet unease about whether the technical controls actually match what was written down, you already know the problem. A DPIA is not just a document to file away. Organisations need to be able to demonstrate that the measures identified to address the risks are actually implemented and remain effective.

A common practice that still trips teams up when completing a GDPR DPIA is listing generic security measures and then treating the residual risk as closed. Without evidence that those measures are in place and working for the specific processing, the assessment does not hold. This blog shows how to avoid that.

What GDPR Actually Demands for Technical Security

When teams put together a GDPR DPIA, Article 32 of the GDPR is often treated as a demand for the highest possible security. In practice, it requires a level of security appropriate to the risk of the processing in question.

This difference becomes clear during reviews. Controls are sometimes taken from an earlier assessment, the residual risk is marked acceptable, and the work moves on. Months later, a supervisory authority may ask for evidence that those same controls are operating for the current data set. If that evidence is limited, the assessment can face difficulty.

Payment data may require stronger protection than routine newsletter preferences, depending on the nature and risks of the processing. Similarly, processing children’s data can involve higher risks than some routine employee processing, depending on the circumstances. The security measures considered in the assessment should reflect those differences. Using generic controls that look solid on paper but do not match the actual processing is still one of the more common reasons DPIAs run into problems when looked at closely.

The practical test is whether the security measures written in the GDPR DPIA are the ones running for that processing today. A proper DPIA technical risk assessment makes that match visible.

It is also worth keeping the roles of the DPIA and security assessment separate. A DPIA looks at the processing as a whole, including necessity, proportionality, and risks to individuals. Technical security testing addresses one part of that picture by checking whether the safeguards identified in the assessment are actually working.

Source: https://qualysec.com/gdpr-d ...
Back Next