Does GDPR require penetration testing? What Article 32 asks

Does GDPR require penetration testing for our systems?

The GDPR does not use the words penetration test. What Article 32(1)(d) requires is a process for regularly testing, assessing and evaluating the effectiveness of the technical and organisational measures that secure personal data. Penetration testing can satisfy that duty when it is scoped to the risks of the processing, but it is one method among several, and a questionnaire asking for a pen test report is really asking whether you test your security regularly and act on what you find. Start by answering that question for your own systems, then decide what evidence to show.

Both roles carry this duty. A controller must review and update its measures where necessary under Article 24(1), and a processor must make available all information needed to demonstrate compliance and allow for and contribute to audits under Article 28(3)(h). A customer may therefore ask a processor for test evidence, and the processor should be able to explain its test calendar, its scope and how findings were tracked to closure. No regulator issues a certificate for passing a test, and no independent auditor confirms GDPR compliance on the basis of a pen test alone.

The required depth depends on risk, not on a fixed checklist. Ask which data categories are processed, whether special category data is involved, which internet-facing applications, APIs and administrative interfaces hold that data, and what a breach would mean for individuals. A test of a customer portal handling health records will differ from a test of an internal reporting tool. Confirm the scope, testing frequency and remediation timelines with your own risk owner and document the decisions, since regulators have cited inadequate checks in security failings and the record of your reasoning is part of the evidence.

Which testing methods satisfy regular testing in practice

Article 32(1)(d) asks for a process of regular testing, assessing and evaluating effectiveness, but it does not name a method. The methods below answer different questions, so most organizations combine several and record what each one covered and what it missed.

Application and API penetration tests

A tester attempts to exploit authentication, authorization, input handling and business logic in a defined application or API version. This shows whether personal data can be reached by someone who should not reach it. It does not cover what was never in scope, so check that the test scope lists every system that stores or exposes personal data, and that retests confirm the fixes. Ask for a written list of findings with status.

Infrastructure and cloud configuration testing

This method reviews hosts, network segments, identity settings, storage permissions and cloud account configuration for weaknesses that expose data. It tests the environment as deployed, which matters when platforms change often. A clean result reflects only the configuration tested on the day, so confirm that the scan covers production, backups and administrative consoles, not only a staging copy.

Vulnerability assessments

Automated scanning identifies known vulnerabilities and missing patches across systems at a broad scale. It shows that the organization knows what is exposed and how quickly it reacts, which supports the process element of Article 32(1)(d). It does not prove that a weakness can be chained into a data breach. Check how scan results feed a tracked remediation plan with owners and due dates.

Control reviews and internal audits

Reviewers check whether documented measures such as access reviews, change approvals, logging and backup restores actually operate as described. This tests effectiveness over time rather than a single attack path, and it produces evidence an assessor can sample. Its limit is that a reviewer reads records rather than attacking systems, so pair it with technical testing. Ask whether the review samples real tickets and logs.

Red team exercises

A red team tests whether an attacker can reach a defined objective, such as extracting a customer database, while the defenders may or may not know. This shows how detection and response perform, which a standard penetration test rarely measures. Red teaming is narrower in coverage and more costly to scope, and its findings are only useful if the blue team review and breach response procedures are updated afterward. Confirm the rules of engagement and who approves them in writing.

How controllers and processors share the testing duty

As the controller, the organization decides why and how personal data is processed, and it carries the primary accountability for the measures protecting that data. Article 24(1) requires the controller to implement appropriate technical and organisational measures, to be able to demonstrate that processing complies, and to review and update those measures where necessary. Article 32(1)(d) adds a specific expectation: a process for regularly testing, assessing and evaluating the effectiveness of the security measures. The controller cannot hand that duty to a vendor. Even when the platform is run by an outside partner, the controller must be able to show how it knows its measures still work.

Review obligation: Article 24(1) requires measures to be reviewed and updated where necessary, so a one-time test at go-live does not satisfy it.
Testing duty: Article 32(1)(d) requires a regular testing process, which can include penetration tests, vulnerability assessments and configuration reviews chosen by risk.
Scope of ownership: The controller owns the test scope, the remediation decisions and the record of what was found and fixed.
Evidence trail: Dated reports, ticketed findings and retest results show the process operating over time.
Risk basis: The frequency and depth of testing should follow the risk assessment that Article 32(2) requires.

Before relying on any external test, confirm with your team which tests are scheduled, who signs off on remediation and where the dated evidence is kept.

What regulators have cited after security failures

Regulators do not wait for a test report to find out whether security was tested. In its Article 32(1) decision against Miljödata, the Swedish supervisory authority IMY, in a decision dated 22 September 2026, fined the company and cited inadequate checks when installing new software among its security failings. The lesson for penetration testing is direct: a release that goes into production without a verified check of its security is the kind of gap an authority will name. Teams should confirm that every new component, configuration change and vendor update passes through a documented verification step before it touches personal data, and that the result is kept on file.

The CNIL fined Hôpital Privé de la Loire EUR 500 000 on 9 September 2026 in a case tied to a health data breach. The decision concerns a breach of health data, which is the category where Article 32 expectations are highest, and it shows that a fine can follow a security failure with no need for a deliberate act by the controller. Penetration testing is one way to find the exposed services, weak authentication and misconfigurations that attackers use. Before relying on that link, read the CNIL's own page for the findings it relied on, because the summary does not describe the technical causes in detail.

For planning, treat these decisions as a checklist of questions to answer about your own environment. Which systems hold health or other special category data? Which changes went live without a security check in the last year? Can you show a regulator the date, scope and remediation status of your most recent test? The Miljödata and Hôpital Privé de la Loire pages are the primary sources for what each authority examined, and they should be read before you write a testing policy or scope a test.

How a test program produces GDPR evidence

A penetration test on its own proves little under Article 32(1)(d). The sequence below turns testing into documented evidence that the controller or processor tested its measures, acted on the results and kept checking them.

Scope the test by data flow and risk
The organization, with its security and data protection leads, maps the systems that store, transmit or administer personal data and ranks them by the risk of destruction, loss, alteration or unauthorised disclosure named in Article 32(2). Scope covers applications, APIs, cloud accounts, administrative paths and any processor-operated components. The output is a written scope statement listing in-scope systems, excluded systems with reasons, test types and the data flows each test must cover, approved by the person accountable for the processing.
Engage a qualified tester under written terms
The organization selects a tester with demonstrable skills for the chosen scope and agrees rules of engagement covering test windows, access accounts, data handling during testing, and stop conditions if personal data is exposed. Where a processor or an external implementation partner runs the test, the contract should state who owns the findings. The output is a signed statement of work and rules of engagement that the records can later show, so the test is clearly a planned measure and not an ad hoc event.
Execute the test and record the results
The tester runs the agreed tests against the scoped environment, documenting methods, tools, accounts used, timestamps and the evidence of each finding. Testers should flag any personal data they touch and handle it under the agreed rules. The output is a dated report that lists each finding with severity, affected system, data categories potentially involved and reproduction steps, so a reviewer can verify what was tested and what was found.
Triage findings and assign remediation owners
The security lead and data protection lead review each finding, confirm severity against the organization's own risk method, and decide whether the issue is a security defect, a configuration gap or a process failure. Each accepted finding gets an owner, a remediation approach and a target status. The output is a findings register linked to the risk assessment, with documented reasons for any finding the organization decides to accept, so that risk decisions are visible rather than silent.
Remediate and document each fix
Owners implement fixes through the normal change process, recording what changed, when, and whether any personal data processing was affected. Where a fix changes processing, the related records, DPIA or processor documentation are updated. The output is closed-out entries in the findings register that point to the change record, so each remediation can be traced from the original finding to the deployed control.
Retest to confirm the fix works
The tester or an independent reviewer repeats the relevant tests against the remediated systems and confirms whether each issue is resolved, partly resolved or still open. Retest results are added to the report. The output is a retest record per finding that states the outcome and the date, which is the proof that the organization checked the effectiveness of its measures rather than assuming the fix worked.
Maintain a monitored action plan at senior level
The organization keeps a documented action plan covering open items, deadlines it has set internally, and risk acceptances, and reports progress to senior management on a set cadence. The EDPB's guide for small business recommends periodic security audits, each producing an action plan whose implementation is monitored at the highest level of the organization. The output is board or executive minutes or a signed status report showing that leadership reviewed the plan, which is evidence of accountability under Article 24(1).

How test evidence affects fine exposure

Test evidence affects fine exposure only indirectly. Article 83 lists the factors a supervisory authority weighs when it sets a fine, and several of them concern security testing: the degree of responsibility the controller or processor bears given the technical and organisational measures it applied under Articles 25 and 32, whether it mitigated the damage, how it cooperated with the authority, and how the authority learned of the infringement. Regular, documented testing helps on these points because it shows that the organization assessed its measures and acted on what it found. It does not, on its own, guarantee a lower fine.

The maximum amounts are set by Article 83. Infringements such as those in Articles 25 to 39 carry a maximum of EUR 10 million or 2% of total worldwide annual turnover, and infringements of the principles, lawful basis, data subject rights and transfer rules carry a maximum of EUR 20 million or 4%, in each case whichever is higher. EDPB Guidelines 04/2022 on the calculation of administrative fines explain how an authority starts from the seriousness of the infringement and then adjusts for aggravating and mitigating circumstances. For a security case, the questions are usually whether known weaknesses were left open, how long they persisted and whether the organization's own review would have caught them. Ask your assessor or counsel how the guidelines apply to your data categories and processing volume.

Test evidence is useful only if it is acted on. Keep a dated record of each test scope, the findings, the remediation owner and the retest result, and make sure the organization can show that high-risk findings were addressed. Be cautious with claims in contracts or marketing that a test certifies compliance: the GDPR requires no certificate, and a report is one input to the controller's own accountability. Confirm with your legal team which evidence you will present to a customer or authority, and whether the test was performed by a party independent of the team that built the system.

What changes the depth and scope of testing

Article 32(1)(d) does not fix a test schedule or depth, so the scope of a penetration test should follow the risk of the processing. The drivers below change which systems are in scope, how deep the test goes and what the organization must record to show the test was proportionate.

Volume and sensitivity of personal data

The more personal data a system holds, and the more sensitive it is, the higher the risk that Article 32(2) asks you to weigh. Systems holding special categories of data, such as health or biometric data, or large volumes of records on many individuals should be tested deeper and more often, with attack paths that reach the data store, not only the login page. Document the data categories, record counts and the systems where each category resides, so the test scope can be traced back to the processing it protects.

Internet exposure of processing systems

Systems reachable from the public internet face a wider range of attackers than internal tools, so their external attack surface belongs in every test. Include public APIs, administrative portals, remote access gateways and file transfer endpoints, and check for exposed services that were added during deployment and never removed. Record which hosts and endpoints are internet facing, who owns each one and when they were last tested.

Third-party and sub-processor systems

When a processor runs a platform that touches personal data, the controller's security obligations still depend on how that platform is tested. Confirm whether the test covers the processor's hosted components, the integrations with sub-processors and the identity providers they share. Under Article 28(3)(h), a processor must contribute to audits, so ask for the test scope, rules of engagement and summary findings in writing before you rely on them.

Cross-border data transfer paths

Where personal data flows to a recipient outside the EEA, the transfer path is part of the attack surface. Test the connections, tunnels, support access and replication links that carry data across borders, as well as the endpoints at each end. The Commission's standard contractual clauses list testing of security measures among the example measures to describe, so the results of these tests can support the transfer assessment and show the supplementary measures work in practice.

Recent software and configuration changes

Each new install, major upgrade or configuration change can create a weakness that a previous test never saw. The Swedish IMY's Article 32(1) decision against Miljödata cited inadequate checks when new software was installed, which shows regulators look at change control. Trigger a targeted test after significant changes, and keep the change record, the test scope and the remediation of findings together so you can show the change was checked before it went live.

In-house testing or an outside tester

This table compares internal security staff, an independent external penetration test and a retainer for continuous testing against the Article 32(1)(d) expectation of regular testing. Read each row to see which option produces evidence an assessor or customer will accept, and which questions to ask before you rely on it.

Option	When it fits	Evidence it produces	Independence and skill questions to ask
Internal security staff	Teams with trained testers who can run regular checks between formal tests and fix findings quickly.	Internal test plans, scan outputs, retest records and tracked remediation tickets that show testing is regular and acted on.	Can the testers review systems they built or operate? Who signs off on findings, and how are results kept separate from delivery pressure?
Independent external penetration test	Periodic checks of high-risk systems, after major changes, or when a customer or regulator asks for evidence from a party outside the organization.	A written scope, methodology, findings with severity, a remediation plan and a retest report. Evidence depends on the scope written before work starts.	Does the firm have no role in building or running the system? Ask for tester credentials, references you can verify, and how they handle critical findings found mid-test.
Retainer for continuous testing	Platforms that change often, where waiting for an annual test leaves gaps, and where the organization wants steady assurance between formal reports.	Recurring test cycles, a running register of findings and retests, and change-linked test records that show testing follows system changes.	Which assets are covered each cycle and how is new scope added? Who reviews quality, and how quickly are retests done once fixes are deployed?
Scope and cost basis	Use this to decide how much to spend on each option.	The written scope sets the deliverables and effort. DeployOpen does not publish a price list, so costs follow a quote from that scope.	Ask each provider for the assets, test types, retests and reporting included, and what would change the quote.
Report ownership	Applies to every option, since no testing provider issues compliance certificates.	Test reports are internal or contractual evidence. The organization owns its controls, and only an independent auditor or certification body issues assessments or certificates.	Confirm with your auditor or customer which test reports they will accept before you commission the work.

Questions buyers ask about GDPR penetration testing

Does a GDPR penetration test certificate exist?

No. The GDPR issues no penetration test certificate, audit report or attestation, and no test vendor can issue one that satisfies the regulation on its own. Article 32(1)(d) requires a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures. The evidence is the controller's or processor's own documented process: the test scope, the findings, the remediation plan and proof that fixes were verified. A tester's report is one input to that evidence. Only an independent auditor or certification body issues reports or certificates, and certification under Article 42 is voluntary and does not reduce the organization's responsibility for compliance.

How often must GDPR penetration tests run?

The GDPR does not set a fixed interval. Article 32(1)(d) says testing must be regular, and the right frequency depends on the risk of the processing, how fast the systems change, and what earlier tests found. The EDPB's guide for small businesses recommends periodic security audits, each producing an action plan whose implementation is monitored at the highest level of the organization. In practice, a regulator will ask whether your interval is justified, whether it was followed, and whether tests run after significant changes such as new software, new integrations or major configuration work. Document the interval and the trigger events in writing so you can defend them.

Can a customer demand a penetration test report?

A controller can require it only through the contract or audit rights it holds. Under Article 28(3)(h), a processor must make available all information necessary to demonstrate compliance and must allow for and contribute to audits, including inspections, by the controller or an auditor it mandates. A summary of test results, remediation status and scope is a common way to meet that duty without exposing raw exploit details. Whether the full report is shared depends on the processing agreement, the sensitivity of the findings and your own security policy. Agree the disclosure terms before the customer asks, and confirm them with your legal team.

What does a penetration test need from our own team?

Most of the effort falls on your internal team, even when an outside tester does the attack work. You need to define the scope and the systems that process personal data, provide accounts and environment access, name a contact for urgent findings, and assign owners for remediation. You also need to keep the records a regulator would ask for: the test plan, the findings, the risk rating, the fix, the retest and the sign-off. The EDPB's guide for small businesses suggests a regularly updated risk management spreadsheet to track this. Ask any provider for a written scope and a list of the internal inputs before work starts, and check that remediation tracking is included in the engagement.

Can an outside tester alone satisfy the GDPR testing duty?

No. An outside tester can supply skilled attacks and an independent view, but Article 32 places the duty on the controller or processor, and the process must be part of how the organization runs its security. Testing without remediation, retesting, governance and records would not show that measures are effective. Use outside testers to add depth and independence, and keep ownership of the program internally. Be clear in the contract about who decides scope, who receives findings, who approves risk acceptance and who verifies fixes. DeployOpen runs security testing of applications, APIs, cloud and infrastructure, and AI systems, and prepares the evidence for assessments, but the organization owns its controls and the decisions about them.

How do test results affect a regulator inquiry or fine?

Test results can help or hurt. Article 83(2) lists factors an authority weighs, including the degree of responsibility given technical and organisational measures under Articles 25 and 32, mitigation, cooperation and intent or negligence. Documented tests, prompt remediation and verified fixes show that measures were reviewed and improved. Known findings left open for long periods show negligence. The Swedish IMY's Article 32(1) fine against Miljödata, decided on 22 September 2026, cited inadequate checks when installing new software among the failings, which is a reminder that the regulator looks at the testing process around changes, not only at the existence of a test. Ask counsel how your records would read to an authority before an incident happens.

Do self-hosted platforms change the penetration testing duty?

They do not remove the duty. Self-hosting usually reduces the number of processors and transfers you manage, but it moves full responsibility for security onto your organization, including testing of the platform you run in your own cloud accounts, data center or air-gapped network. Your test scope must cover the open-source components, their configuration, the hosting layer, backups and integrations, and any updates or patches you apply. Changes to a self-hosted platform are changes you make, so each significant upgrade or customization should trigger a review. Confirm with any implementation partner exactly which layers they test and which remain your responsibility.

How DeployOpen prepares systems and evidence for testing

DeployOpen plans, implements and hardens self-hosted open-source platforms inside the client's own infrastructure, and runs security testing on them. For GDPR penetration testing questions, we help the organization define what gets tested, prepare the systems and logs that testing depends on, and document the results so the controller can show how it reviews its security measures.

How we scope

Agree in writing which systems, processors, data flows and environments the testing covers.
Map the tested components to the personal data they hold and the risks that matter for Article 32.
Confirm test types, rules of engagement, testing windows and who at the organization approves each step.

How we build

Deploy and harden the open-source platforms in your cloud accounts, data centers or air-gapped networks.
Configure logging, access controls and monitoring so that test activity and findings can be traced.
Prepare a test environment that reflects production configuration, and record every change made to it.

How we hand over

Deliver the test report with findings, reproduction steps, severity and recommended remediation.
Track remediation items to closure and retest fixed issues, recording the outcome for your evidence file.
Provide documentation your team can give to an independent auditor, assessor or customer reviewing your testing program.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope engagement.
Help your team schedule regular re-testing as systems, configurations and data flows change over time.
Keep the testing record current so it supports your periodic review of security measures and any customer audit.

Does GDPR require penetration testing?