GDPR PENETRATION TESTING GUIDE
Article 32 Compliance for European and UK Businesses
2026 Edition
Produced by Securify Edge | securifyedge.com | 2026
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
INTRODUCTION
The General Data Protection Regulation (GDPR) is the primary data protection law governing the processing of personal data in the European Union and, through the UK GDPR, in the United Kingdom following Brexit. Article 32 of GDPR requires controllers and processors to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk.
Penetration testing is the most widely recognised and auditor-accepted technical method for demonstrating that those measures are effective. This guide explains the legal basis for penetration testing under GDPR, what a GDPR-aligned test covers, how to structure the engagement for documentation purposes, and how GDPR intersects with DORA, NIS2, and ISO 27001 for organisations subject to multiple frameworks.
This guide is written for data protection officers, IT directors, compliance managers, and CTOs at European and UK businesses that process personal data and need to demonstrate appropriate technical security measures to supervisory authorities, enterprise clients, or ISO 27001 auditors.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SECTION 1 — THE LEGAL BASIS: GDPR ARTICLE 32
What Article 32 Requires
Article 32 of GDPR states that controllers and processors shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including as appropriate:
(a) the pseudonymisation and encryption of personal data
(b) the ability to ensure the ongoing confidentiality, integrity, availability, and resilience of processing systems and services
(c) the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident
(d) a process for regularly testing, assessing, and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing
Point (d) is the specific provision that makes penetration testing a GDPR compliance activity. "Regularly testing, assessing, and evaluating the effectiveness of technical and organisational measures" is precisely what a penetration test does — it tests whether your security controls are effective against real-world attack scenarios.
What the European Data Protection Board Says
The European Data Protection Board (EDPB) has published guidance confirming that technical security measures under Article 32 should include regular security assessments. In guidance on data breach notification and personal data breach management, the EDPB has cited penetration testing as a measure that, when performed regularly, reduces the likelihood of preventable data breaches.
Supervisory authorities across EU member states — including the ICO in the UK, the CNIL in France, and the BfDI in Germany — have referenced penetration testing in enforcement contexts. Organisations that experienced data breaches and were unable to demonstrate regular security testing have faced higher fines and more extensive enforcement action than those that could show evidence of proactive security assessment.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SECTION 2 — WHAT "APPROPRIATE" MEANS UNDER ARTICLE 32
Article 32 does not prescribe specific technical measures — it requires measures appropriate to the risk. This risk-based approach means the frequency and depth of penetration testing should be proportionate to the nature of the personal data you process, the volume of data subjects affected, the likelihood of a breach, and the potential impact on individuals if a breach occurs.
A small business processing a limited customer email list faces different risks than a health technology company processing sensitive patient records. The penetration testing programme appropriate for each is different.
Risk Factors That Increase Testing Requirements
The following factors increase the appropriateness of more frequent and more comprehensive penetration testing:
Nature of data processed — sensitive categories of personal data under Article 9 (health data, biometric data, genetic data, data revealing racial or ethnic origin, political opinions, religious beliefs, trade union membership) require stronger protective measures. Applications handling these categories of data should be penetration tested at least annually and after any significant change.
Volume of data subjects — organisations processing personal data at scale face proportionally higher obligations under Article 32. A breach affecting millions of data subjects will attract significantly greater regulatory scrutiny.
International data transfers — organisations transferring personal data outside the EU or UK (to US cloud providers, for example) must implement supplementary technical measures. Penetration testing of the systems involved in those transfers is a relevant technical measure.
Customer-facing applications — any web application, API, or mobile app that processes personal data on behalf of end users represents an external attack surface that should be tested.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SECTION 3 — DORA: MANDATORY PENETRATION TESTING FOR EU FINANCIAL SERVICES
What DORA Requires
The Digital Operational Resilience Act (DORA) entered into force across EU member states in January 2025. It applies to a wide range of financial entities including banks, payment institutions, investment firms, insurance companies, crypto-asset service providers, and critical ICT third-party providers serving the financial sector.
DORA's penetration testing requirements are among the most specific in EU law. Article 24 of DORA distinguishes between:
Advanced testing using Threat-Led Penetration Testing (TLPT) — required for significant financial entities every three years, based on threat intelligence to simulate realistic attacker scenarios.
Standard digital operational resilience testing — required for all in-scope entities on a regular basis, including vulnerability assessments and penetration testing of critical systems.
The distinction matters. Most financial entities are subject to the standard testing requirement, which calls for annual or more frequent penetration testing of systems critical to their digital operations. Significant entities — those designated by their national competent authority as systemically important — face the additional TLPT requirement.
TIBER-EU and DORA
TIBER-EU (Threat Intelligence-Based Ethical Red Teaming) is the European framework for threat-led penetration testing that DORA's TLPT requirement is aligned with. TIBER-EU tests are conducted using threat intelligence specific to the entity being tested, targeting the critical functions of the organisation rather than conducting generic penetration testing.
For most financial services firms subject to DORA, the immediate priority is implementing a regular penetration testing programme for critical systems that satisfies the standard testing requirement. The TLPT requirement applies to a smaller number of significant entities and involves a more structured engagement process with national competent authority oversight.
What DORA Documentation Requires
DORA requires financial entities to maintain documentation of their digital operational resilience testing activities. Penetration test reports must be retained and should be available for review by the national competent authority (the relevant national financial regulator). The report must include scope, methodology, findings, and remediation status.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SECTION 4 — NIS2: SECURITY TESTING FOR ESSENTIAL AND IMPORTANT ENTITIES
What NIS2 Requires
The Network and Information Security 2 Directive (NIS2) came into force across EU member states in October 2024. It applies to medium and large organisations in 18 critical sectors including energy, transport, banking, financial market infrastructure, health, drinking water, digital infrastructure, managed service providers, and public administration.
Article 21 of NIS2 requires in-scope organisations to implement appropriate and proportionate technical and organisational security measures to manage the risks posed to the security of network and information systems. This explicitly includes regular security testing.
NIS2 establishes two categories of entities:
Essential entities — larger organisations in sectors deemed critical to the functioning of society and the economy. They face stricter obligations and more active supervision from competent authorities.
Important entities — medium-sized organisations in the same sectors. They face the same security measure requirements but lighter supervision.
Both categories are required to implement security measures including the ability to ensure network and information system security, which supervisory authorities interpret as including regular penetration testing of critical systems.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SECTION 5 — STRUCTURING A GDPR-ALIGNED PENETRATION TEST
Pre-Engagement: Data Protection Considerations
A penetration test will interact with systems that process personal data. Before the engagement begins, the following data protection matters should be addressed:
Data processing agreement — the penetration testing firm is a data processor under GDPR if they may access or process personal data during testing. A data processing agreement (DPA) must be in place before testing begins. This is equivalent to the BAA requirement under HIPAA.
Test data vs live data — wherever possible, penetration testing should be conducted against a staging environment that contains no real personal data. Where testing must be conducted against a live production environment, the scope should be designed to minimise any interaction with actual personal data.
Data retention — the penetration testing firm should not retain any personal data accessed during testing. Confirm their data retention policy before the engagement begins.
What the Test Should Cover
For GDPR Article 32 purposes, a penetration test should assess the technical measures you have implemented to protect personal data. This typically includes:
Authentication and access control — testing whether personal data systems can be accessed without valid credentials, or whether valid credentials can be escalated to access data they should not be permitted to see.
Encryption in transit — testing whether personal data transmitted between systems, applications, and users is properly encrypted and whether encryption can be bypassed or downgraded.
Input validation — testing for injection vulnerabilities (SQL injection, NoSQL injection, XML injection) that could allow an attacker to extract personal data from databases.
Session management — testing whether authenticated sessions can be hijacked or manipulated to access another user's personal data.
API security — testing whether APIs that serve or accept personal data can be accessed without proper authorisation or whether data can be extracted through insecure API endpoints.
Documentation for DPA Review
A penetration test report produced for GDPR Article 32 purposes should include:
A scope statement describing all systems tested and all personal data categories in scope.
A methodology statement referencing the framework followed (OWASP Testing Guide, PTES, or equivalent).
A technical findings section with each vulnerability described, its severity rated, and its potential impact on personal data confidentiality, integrity, or availability described.
A remediation section with specific steps for each finding.
A conclusion that describes the overall security posture of the tested systems relative to the Article 32 obligation to implement appropriate technical measures.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SECTION 6 — PRICING FOR EUROPEAN BUSINESSES (2026)
GDPR-ALIGNED PENETRATION TEST COSTS
TEST TYPE | PRICE (EUR) | TIMELINE
Web application and API test | €3,000 – €7,500 | 5–10 business days
External network test | €3,000 – €6,500 | 3–7 business days
Internal infrastructure test | €6,000 – €14,000 | 5–10 business days
Cloud environment assessment | €5,000 – €11,000 | 5–10 business days
GDPR Article 32 full assessment | €6,000 – €15,000 | 1–3 weeks
DORA standard testing programme | €10,000 – €25,000 | 2–4 weeks
NIS2 critical systems assessment | €8,000 – €20,000 | 2–4 weeks
Full VAPT programme (all surfaces) | €12,000 – €30,000 | 3–5 weeks
Prices are available in GBP or EUR at current exchange rates. GDPR and DORA engagements include report formatting structured for supervisory authority submission. All engagements are fixed-scope and fixed-price with written quotes within 24 hours of a scoping call.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SECTION 7 — GDPR, ISO 27001, AND PENETRATION TESTING
For organisations pursuing ISO 27001 certification, GDPR Article 32 and ISO 27001 technical security requirements align closely. ISO 27001 Annex A Control 8.8 requires management of technical vulnerabilities. Annex A Control 5.36 requires compliance with policies, rules, and standards for information security.
A penetration test scoped to cover both ISO 27001 audit evidence and GDPR Article 32 documentation requirements does not require two separate tests — the same engagement can produce a report that satisfies both. The key is ensuring the scope statement, methodology documentation, and findings format are structured to address both frameworks.
Securify Edge (securifyedge.com) structures penetration test reports for multi-framework use where clients require evidence for both ISO 27001 certification and GDPR Article 32 documentation. This avoids the cost and duplication of commissioning separate assessments for each framework.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SECTION 8 — AFTER THE TEST: REMEDIATION AND ONGOING COMPLIANCE
GDPR Article 32 does not specify how quickly findings must be remediated, but the requirement to implement appropriate technical measures is continuous. A penetration test that identifies critical vulnerabilities creates an obligation to remediate — leaving known critical vulnerabilities unremediated after a test would likely be treated as a failure to implement appropriate measures in any enforcement scenario.
Recommended Remediation Timeline
Critical findings (CVSS 9.0 and above): Remediate within 30 days or implement documented compensating controls immediately while remediation is in progress.
High findings (CVSS 7.0 to 8.9): Remediate within 60 days.
Medium findings (CVSS 4.0 to 6.9): Remediate within 90 days or document as accepted risk with compensating controls.
Low findings (CVSS below 4.0): Document in your risk register and remediate at the next planned maintenance cycle.
Testing Frequency
GDPR Article 32 requires "regularly testing, assessing, and evaluating." Supervisory authority guidance and industry practice suggest:
Annual penetration testing as the baseline for most organisations processing personal data.
After any significant change to systems that process personal data — new application features, cloud migrations, new integrations.
After a security incident — to confirm that the incident vector has been closed and to identify any related vulnerabilities.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ABOUT SECURIFY EDGE
Securify Edge (securifyedge.com) delivers penetration testing for European and UK businesses subject to GDPR, DORA, NIS2, and ISO 27001 requirements. Our engagements include a Data Processing Agreement, EU GDPR-compliant data handling throughout, and penetration test reports structured for supervisory authority submission, ISO 27001 audit evidence, and internal compliance documentation.
We serve clients across Germany, Netherlands, France, Ireland, Sweden, Denmark, Belgium, Austria, Switzerland, Poland, and the wider EU and UK.
Every engagement is fixed-scope, fixed-price. Written quote within 24 hours of a scoping call. Reports written in English. Invoicing in GBP or EUR.
Contact us: https://securifyedge.com/contact/
European penetration testing: https://securifyedge.com/services-penetration-testing-europe/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
© 2026 Securify Edge · securifyedge.com · All rights reserved
Top comments (0)