GDPR penetration testing
GDPR (EU General Data Protection Regulation 2016/679)
Article 32 security testing evidence, demonstrating you regularly test the effectiveness of your technical measures.
Engagement at a glance
Drives testing
Article 32(1)(d): Regular testing of technical measures
Cadence
Regularly, which supervisory authorities read as at least annually and after significant change
Typical duration
2 to 3 weeks of testing, plus retest
Region
European Union and EEA, with extraterritorial reach
Issued by
Enforced by national supervisory authorities. No certificate exists.
32(1)(d)
Article evidenced
4%
Maximum fine of global turnover
Annual
Reading of "regularly"
DPA
Testing governed by
The requirement
What GDPR asks for
Article 32(1)(d) · Regular testing of technical measures
Article 32(1)(d) requires a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of processing. Article 32(1)(b) requires the ability to ensure ongoing confidentiality, integrity, availability and resilience of processing systems.
Most conversations about GDPR are about notices, consent and data subject rights. Article 32 is the part that gets overlooked until something goes wrong, and it is unusually explicit: you must have a process for regularly testing, assessing and evaluating the effectiveness of your security measures.
That word "effectiveness" matters. Having encryption configured is not the same as demonstrating it works. After an incident, a supervisory authority will ask what testing you did, when, and what you fixed as a result. An independent penetration test with a remediation and retest trail is the most direct answer to that question.
XHack delivers that testing evidence. We scope to the systems that process personal data, test them, report with severity and evidence, support remediation, retest to closure and sign an attestation letter covering it. Compliance with the rest of the regulation, from lawful basis to records of processing, is your programme to run.
What your auditor checks
The report has to clear every one of these
These are the questions a GDPR auditor asks of a penetration test before accepting it as evidence. Every engagement we run is built to answer all of them.
Independent testing, separate from the team that built the systems
Scope covering systems that process personal data
Recognised methodology documented in the report
Findings rated with a consistent scheme, CVSS v4.0
Clear link between findings and risk to data subjects
Evidence of remediation, with dates
Independent retest confirming measures now work
Dated report demonstrating regular testing over time
No live personal data exfiltrated during testing
Signed attestation letter for your accountability file
What we test
Where the testing effort concentrates
The surfaces this engagement covers, weighted by how much of the work they typically represent. Scope is confirmed with you before anything starts.
Systems processing personal data
Applications and databases holding personal data
95%
Access control and authorization
Cross-account access, privilege boundaries
90%
Encryption in transit and at rest
Verifying the measures actually hold
85%
External perimeter
Internet-facing exposure of processing systems
75%
Data export and sharing paths
APIs, integrations, third-party flows
65%
Weights are indicative of typical effort. Your exact scope is agreed and signed before testing begins.
How the engagement runs
Scope, test, close, attest
Typically 2 to 3 weeks of testing, plus retest. The retest is included, because a report full of open findings is not evidence of anything.
Scope to processing systems
We work from your data flows to scope the test on the systems that actually process personal data, so the evidence lines up with your records of processing.
Test under a DPA and signed rules of engagement
Testing runs under a Data Processing Agreement. No live personal data is exfiltrated, and only the minimum needed to demonstrate a finding is captured, then redacted in the report.
Report with data protection impact
Findings are described in terms of risk to data subjects as well as technical severity, which is the language a supervisory authority uses.
Remediation support
Your team fixes. Anything that could constitute a personal data risk is escalated immediately rather than held for the report.
Retest and accountability record
Each finding retested and closed, with a dated attestation letter that becomes part of your Article 5(2) accountability evidence.
Where the effort goes
Share of a typical engagement, by phase
Scoping to data flows
20%
Testing & exploitation
40%
Reporting & impact analysis
20%
Retest & attestation
20%
What we bring
Built for the GDPR auditor specifically
The parts of this engagement that are shaped by the framework rather than copied from a generic testing template.
Effectiveness, not configuration
We prove whether the technical measures hold under attack, which is what Article 32(1)(d) actually asks for.
Framed around risk to people
Findings are described in terms of impact on data subjects, not only CVSS, because that is how regulators assess them.
Tested under a DPA
We sign a Data Processing Agreement, and no live personal data leaves your environment during testing.
A record of regular testing
Dated reports year on year are what demonstrate the "regularly" part of the requirement.
The deliverable
What lands on your auditor's desk
A report structured so the evidence sits where the auditor is already looking, with every finding mapped to the control it touches.
In the report
Signed letter of attestation with testing dates
Scope tied to systems processing personal data
Methodology, qualifications and independence statement
Findings with CVSS v4.0 and impact on data subjects
Confirmation that no live personal data was exfiltrated
Remediation implemented and independent retest result
Article 32 mapping for your accountability file
Control mapping
How the report evidences each control
Article 32(1)(d)
The regular testing, assessing and evaluating of effectiveness that the article requires.
Article 32(1)(b)
Evidence that confidentiality, integrity and resilience hold under real attack conditions.
Article 32(1)(a)
Verification that encryption and pseudonymisation measures are correctly implemented.
Article 5(2)
Dated, independent evidence supporting the accountability principle.
Article 35
Technical input into Data Protection Impact Assessments for high risk processing.
Where our work stops, and who takes it from there
XHack provides the penetration testing evidence for Article 32(1)(d). We do not issue certificates, attestation opinions or regulatory approvals, and we do not run your wider compliance programme. For GDPR, that sits with: Enforced by national supervisory authorities. No certificate exists.. Staying independent of them is exactly what makes our evidence worth something when they review it.
Questions
GDPR testing, answered
Article 32(1)(d) requires a process for regularly testing, assessing and evaluating the effectiveness of your technical and organisational measures. It does not use the word penetration test, but independent security testing is the clearest and most widely accepted way to satisfy it.
No. Records of processing, lawful basis, privacy notices, data subject rights and DPIAs are your programme, usually run with a privacy specialist or DPO. We provide the Article 32 security testing evidence that programme needs.
We work under a Data Processing Agreement and signed rules of engagement. No live personal data is exfiltrated. Where proving a finding requires touching a record, we capture the minimum necessary and redact it in the report.
A supervisory authority will ask what you did to test your measures. A dated series of independent reports, each showing findings remediated and retested, is a materially stronger answer than a policy document.
Other frameworks we test for
Get the GDPR evidence sorted
Tell us who is auditing you and when your review period closes. We will scope the test, tell you what it costs, and make sure there is room to remediate and retest before the deadline.