How to Fulfill the Security Requirements of a GDPR Data Protection Impact Assessment (DPIA)

Introduction

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.

GDPR Article 32 Requirements and How to Fulfill Them

1. Encryption of Personal Data in Transit and at Rest

Article 32 lists encryption of personal data as one of the measures that may be appropriate to keep security matched to the risk of the processing. Depending on the processing and the risks involved, this can mean protecting the data both while it is moving and while it is stored.

In day-to-day terms, this usually looks like the following:

• Strong TLS configurations for data transmitted over networks
• Encryption for databases and storage containing personal data
• Encryption of backups where appropriate
• Secure key management and access controls
• Regular review of cryptographic configurations

What matters for any assessment is that the encryption described is the encryption that is actually in place and working.

2. Pseudonymisation and Anonymisation

Article 32 specifically identifies pseudonymisation and encryption as security measures that may be appropriate depending on the risks involved. Anonymisation is different. If data has been genuinely anonymised so that an individual is no longer identifiable, it may fall outside the scope of the GDPR.

With pseudonymisation, the data remains personal data, but the identifying information is separated or transformed so that it cannot be attributed to a specific person without using additional information. That additional information needs to be kept separately and protected appropriately. Teams may:

• swap names for consistent pseudonyms in analytics sets
• keep customer IDs and personal details in separate systems
• replace identifying values in logs with appropriately protected pseudonymous identifiers
• use tokenisation where the tokenisation system and re-identification information are appropriately separated and protected
• keep live customer data out of development and test environments

Anonymisation goes a step further. The data is processed so that individuals are no longer identifiable, taking into account the means reasonably likely to be used for identification. If the data is genuinely anonymised and individuals are no longer identifiable, it falls outside the scope of the GDPR. Reaching and maintaining that level is harder, especially if the dataset might later be combined with other sources.

Pseudonymisation can be a practical way to reduce risk while keeping the data usable for legitimate purposes. Full anonymisation is reserved for cases where the business purpose allows the data to be permanently stripped of identifiability. Whatever route is chosen, the measures written in the assessment need to match what is running.

3. Access Controls Limiting Who Sees What

Access control is one of the practical measures organisations can use to meet the GDPR’s requirements for confidentiality and appropriate security. Article 32 requires organisations to implement security measures appropriate to the risk, while the GDPR also requires people acting under the authority of a controller or processor to process personal data only on instructions.

The usual way organisations meet this follows a clear chain:

Identify the role → grant only the access that role needs → apply stronger authentication where the risk calls for it → log relevant access → review rights regularly → remove unnecessary access when someone changes role or leaves

Customer-service staff see customer records, finance sees payment information, and developers stay away from live personal data. Application-level checks also stop one customer from viewing another’s information.

For example, during an API assessment, a tester may change an object identifier in a request from one customer record to another. If the application returns the second customer’s data without checking whether the authenticated user is authorised to access it, the issue is an authorisation failure that can expose personal data across accounts. 

4. Integrity Verification: Ensuring Data Hasn’t Been Modified

Article 32 also requires organisations to maintain the ongoing integrity of processing systems and services. In practice, this can involve a mix of logging and protective controls:

• Detailed audit logs are switched on in databases that hold personal data, recording who changed what and when.
• Checksums or digital signatures are applied to the most sensitive records.
• Change tracking is enabled where appropriate to the systems and risks involved.
• Backups are protected against unauthorised alteration or deletion.
• Configuration files sit under version control.
• Logs are kept long enough to support later investigation.

What counts is that the logging and integrity checks described in the assessment are the ones actually operating.

5. Availability and Resilience

Under the European Data Protection Regulation, Article 32 expects organisations to maintain the availability and resilience of processing systems and services, with the ability to restore access to personal data on time after an attack, system failure or other physical or technical incident.

Redundant systems are put in place so one failure does not stop service. Data is replicated to a second location. Automated failover brings the backup systems online without waiting for someone to intervene. Backups are tested regularly rather than assumed to work. Recovery steps for each critical system are written down. Clear targets are set for how quickly service should return and how much data can be lost.

For higher-risk processing, recovery and data-loss targets should be set according to the nature of the processing, the systems involved and the potential impact on individuals. Building the full arrangement will also depend heavily on the existing infrastructure.

6. Regular Testing and Monitoring

Article 32 requires a process for regularly testing, assessing and evaluating whether the security measures are still effective.

• Ongoing: Continuous monitoring of systems that hold personal data, with alerts for unusual access patterns and regular review of security logs.
• At risk-based intervals: Vulnerability scanning, security assessments and other technical checks across the relevant systems.
• Periodically: Penetration testing and other forms of security testing where the nature and risk of the processing make them appropriate.

The exact timetable can be adjusted according to the risk of the processing, but the principle remains the same: the controls listed in any assessment have to be checked in practice, not simply left running unexamined.

7. Staff Training and Awareness

Security also depends on the people handling personal data. Anyone who handles personal data needs to understand what is expected of them and how to avoid common mistakes.

Organisations may use mandatory staff training who work with personal data, followed by periodic refreshers. Developers can receive extra sessions on secure coding, customer-service teams can practise spotting phishing attempts, and system administrators can cover the rules around granting and removing access. Completion can be recorded with dates, with a short quiz or practical exercise used to confirm the main points have landed.

The programme can then be repeated periodically and updated for new joiners, changes in the processing, and new security risks.

Want a Sample Security Testing Report?

See how our experts document vulnerabilities, risk severity, and clear remediation steps.

Download Sample Report →

How Offensive Security Validates Your GDPR Security Controls

Once the controls are in place, the next question is whether they actually stand up when someone tries to break them. Automated scanners help, but they are limited in what they can identify without understanding the application’s business logic, access model, and attack paths. They can miss weak business logic, chained attack paths, or the kind of misconfiguration that lets an outsider pull personal data without triggering an alert.

That is where GDPR DPIA penetration testing can add useful evidence to the assessment. The test is designed to answer practical questions:

• Can someone reach systems without valid credentials?
• Can a normal user see another person’s data?
• Is personal data encrypted both while it moves and while it sits in storage?
• Do the logs capture enough detail to spot unusual access?
• Are APIs and cloud storage locked down so they cannot be used as a quiet exit route?
• Can an attacker move from a less protected system into one that holds sensitive records?
• Are the backups themselves protected and actually restorable?

A typical scope covers the areas that matter most for personal data:

A finding like this can surface during testing when the documented control does not match the way the system is actually configured. Documentation may state that patient data is encrypted with AES-256, yet testing can show that the encryption only covers the backup copies while live databases remain readable. The finding forces additional work, a retest, and an update to the assessment before the organisation can treat the control as complete.

The value of the exercise is clear. It turns the security measures written into the GDPR DPIA from claims into something that has been challenged and, where necessary, corrected.

How Qualysec Bridges the Gap Between Legal GDPR DPIA and Technical Pentesting

A lot of organisations still treat the legal work on a GDPR DPIA and the day-to-day security work as two separate jobs. The privacy team works on the assessment. The security or IT team looks after the controls. The two sides rarely sit down together and check whether the statements in the document still match what is running in the systems. That is usually where problems surface later.

Common mismatches include:

• the assessment says personal data is encrypted, yet some databases have been left unencrypted for performance reasons
• role-based access is described as complete, but old accounts and shared logins are still active
• Logging is listed as in place, yet the records needed for an investigation turn out incomplete or missing
• API protections appear in the document, but the interfaces still accept requests without proper authentication

When a supervisory authority asks for evidence, the written claims and the live environment no longer line up.

Qualysec works across both sides of this picture. The team starts with the finished GDPR data protection impact assessment, reads every technical claim, and then tests those GDPR DPIA security controls directly against the systems. Each control is checked to see whether it is present and whether it behaves as described. The results are turned into clear evidence that can be written back into the assessment.

The work normally follows this order: the written controls are reviewed, each one is tested against the relevant systems and environment, any differences are recorded, the necessary fixes are supported, the controls are retested, and an evidence pack is supplied showing that the measures now match the document. This process can also support a GDPR data privacy audit by providing evidence that the documented controls have been technically reviewed and verified.

The result is an assessment that rests on controls that have been examined and confirmed, not on assumptions. When the next review or enquiry arrives, the organisation already has the tested evidence ready.

How a Strong GDPR DPIA Helps You Close Enterprise Deals Faster

A strong GDPR DPIA can also help when enterprise customers carry out privacy and security due diligence. Buyers handling personal data want to understand what processing is involved, what risks have been identified, and what measures are in place to address those risks.

The buyer may ask for:

• A documented assessment showing that the processing risks have been examined
• Information about the technical and organisational measures used to protect personal data
• Evidence that relevant security controls have been tested where appropriate
• Clear procedures for breach notification and incident response
• A plan for reviewing the risks and security measures as the processing changes

When this information is already documented, security and privacy questions can be answered without starting the process from scratch each time. That can remove some of the back-and-forth that often happens during enterprise due diligence.

A DPIA supported by tested security controls does not guarantee that a deal will close faster. What it does provide is evidence that can help customers, legal teams and procurement teams understand how the organisation manages the risks associated with personal data.

For organisations selling to enterprise customers, having that evidence ready can make the security review easier to handle and reduce delays caused by unanswered questions or missing documentation.

Conclusion

When a supervisory authority reviews a GDPR DPIA, the written assessment is only part of the picture. The organisation needs to be able to show that the security measures identified to address the risks are appropriate and, where relevant, actually operating. A document by itself does not provide evidence that those measures are actually working.

The practical step is to check the technical controls that appear in the assessment, fix anything that does not hold, and keep a clear record of what was tested. With that evidence ready, the organisation can support the DPIA with a clearer record of how its security measures were assessed, and the assessment remains useful for later reviews.

Organisations that keep the security measures under regular examination find later regulatory compliance questions or procurement checks far less stressful. The verification is already complete.

If you would like support testing the controls listed in your current assessment, Qualysec can help review and validate them against the live environment.

Speak Directly With Qualysec’s Certified Security Experts

Discover vulnerabilities before attackers exploit them

Schedule Free Consultation
→

Frequently Asked Questions (FAQ)

1. Can’t I just use a free automated tool to satisfy the GDPR testing rule?

Automated scanners are useful for finding known vulnerabilities, but they do not test every part of an application’s security. They can miss business-logic flaws, access-control issues, and attack paths that require manual testing. GDPR does not prescribe a particular automated tool or require every organisation to perform the same type of security test. The appropriate approach depends on the nature of the processing and the risks involved. Using automated scanning alongside targeted manual testing can provide stronger evidence that the relevant controls have been examined.

2. How does your VAPT report actually help my DPO complete the DPIA?

A VAPT report does not complete the DPIA. It can provide supporting evidence for the security measures and risks documented in it. It turns general statements about encryption, access control or logging into specific, dated findings. The organisation can use that evidence to show that the measures were examined and either confirmed or corrected.

3. Why should we care about CREST accreditation?

CREST is a recognised industry organisation that develops standards and accreditation schemes for cybersecurity services, including penetration testing. For organisations choosing a testing provider, recognised accreditation can be one factor to consider alongside the tester’s experience, methodology, scope and quality of reporting. It is not a specific GDPR requirement.

4. Our setup is 100% cloud-native. Do you audit that?

Yes. Cloud environments can be included in the scope of a security assessment or penetration test. Cloud setups can contain exposed storage, weak identity rules, or permissive APIs that can expose personal data. Qualysec shapes the testing around the actual cloud environment rather than treating it as an afterthought.