Quick answer: The GDPR never asks for a penetration test. The word "penetration" appears zero times in Regulation (EU) 2016/679, and so does the word "vulnerability". What Article 32(1)(d) requires is "a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing", and Article 28(3)(c) makes that requirement flow through to any processor by contract. That is a process obligation with an effectiveness test attached, which is why a single annual report satisfies the letter of it badly. The ICO has already put a number on getting it wrong: on 27 March 2025 it issued a penalty of £3,076,320 against a processor for infringing Article 32(1), finding among other things that penetration tests "were infrequent for each product and could not be relied upon to serve the same purpose as a regular ongoing vulnerability scanning programme" (penalty notice, paragraph 63).
Everything below is anchored to the Official Journal text, the Commission's own standard contractual clauses, one supervisory authority decision and one supervisory authority guide. Nothing here is legal advice, and the clause template later on is a drafting starting point rather than a legal opinion.
What Article 32 actually says
Article 32(1) is one sentence with four limbs, and reading it in full is the fastest way to understand why "do we need a pentest for GDPR" is the wrong question.
Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia 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.
Four things in that text govern how a testing programme should be designed.
"The controller and the processor shall implement". Not the controller alone. A SaaS company processing customer personal data is a processor, and Article 32 binds it directly, without needing a contract to say so.
"A process for". The obligation is to have a process, not to hold an artifact. A report is the output of a process. It is not the process, and a regulator reading your evidence will look for the difference.
"Regularly". The regulation refuses to define an interval, which is deliberate. The interval is a function of the risk-calibration factors in the chapeau: state of the art, cost of implementation, and the nature, scope, context and purposes of the processing, weighted by the risk to the rights and freedoms of natural persons.
"Effectiveness". This is the word that separates Article 32(1)(d) from a compliance checklist. You are not asked to evidence that you have controls. You are asked to evidence that you tested whether they work. A vulnerability scan tells you a component is out of date. A penetration test tells you whether an authorisation boundary holds when someone attacks it. Both are evidence of effectiveness testing, and neither substitutes for the other.
Article 32(2) then says what to weigh: "In assessing the appropriate level of security account shall be taken in particular of the risks that are presented by processing, in particular from accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data transmitted, stored or otherwise processed." Article 32(3) adds that adherence to an approved code of conduct under Article 40 or an approved certification mechanism under Article 42 "may be used as an element by which to demonstrate compliance". An element, not a defence.
The obligation-to-evidence table
This is the artifact to keep. Left column is the provision, middle is what it asks for in plain words, right is the thing a regulator, a controller's auditor, or a customer's security reviewer will actually accept as evidence that you did it.
Provision | What it asks for | Evidence that satisfies it |
|---|---|---|
Art. 32(1) chapeau | Measures appropriate to the risk, judged against state of the art and the processing context | A documented risk assessment that names the processing, the risks and the chosen measures, dated and reviewed |
Art. 32(1)(b) | Ongoing confidentiality, integrity, availability and resilience | Control inventory plus operating evidence: patch records, scan cadence, access reviews, backup and restore tests |
Art. 32(1)(d) | A process for regularly testing, assessing and evaluating effectiveness | A written testing standard naming methods, cadence and triggers; the completed test records; and the closure trail proving findings were acted on |
Art. 32(2) | Security calibrated to the specific risks of your processing | Test scope that demonstrably covers the systems that process personal data, not just the ones that were convenient to test |
Art. 32(3) | Codes of conduct and certifications as supporting elements | An ISO 27001 certificate or approved certification, offered as an element rather than as the answer |
Art. 5(2) | Accountability: be able to demonstrate compliance | The evidence bundle exists, is current, and can be produced on request without a scramble |
Art. 24(1) | Measures "shall be reviewed and updated where necessary" | Evidence of review after material change, not only on the anniversary |
Art. 28(1) | Controllers may use only processors giving "sufficient guarantees" | What you hand a prospect during procurement: a current test summary, the testing standard, the certification |
Art. 28(3)(c) | The processor "takes all measures required pursuant to Article 32" | The processor's own testing programme, evidenced in its own name rather than by pointing at a cloud provider |
Art. 28(3)(f) | The processor assists the controller with Articles 32 to 36 | A defined route by which a controller can get test assurance and breach support, written into the DPA |
Art. 28(3)(h) | Make available all information necessary to demonstrate compliance, and "allow for and contribute to audits, including inspections" | An audit clause that works in practice: report summaries, questionnaire responses, and a defined inspection path |
Art. 28(4) | Sub-processors carry the same obligations; the processor "shall remain fully liable" | Evidence that you test what you built on top of a sub-processor, and that you hold the sub-processor to the same clause |
Art. 35(7)(d) | A DPIA must describe the measures addressing the risks | Test evidence referenced inside the DPIA, so the DPIA is not a paper exercise |
The row most SaaS processors fail is 28(3)(c). A processor points at its cloud provider's certifications and calls that its Article 32 measures. The cloud provider's controls are the cloud provider's. Your application's authorisation logic, your tenancy isolation and your API surface are yours, and they are exactly where a test finds things.
What "regularly" means when the regulation refuses to say
There is no GDPR interval, so the interval has to be argued from the chapeau. In practice four inputs set it.
The risk profile of the processing. Special category data, data about children, data whose exposure would enable physical access to a person's home, or anything the regulator would describe as high risk pushes the cadence up. The ICO made this point directly in the 2025 penalty notice when it treated the health sector's status as critical national infrastructure as raising the severity of the risks to rights and freedoms.
The rate of change in the system. A product shipping weekly changes its attack surface weekly. An annual test on a weekly-release product evidences the state of one day in 365. Article 24(1) is the hook here: measures "shall be reviewed and updated where necessary", which is a change trigger written into the regulation.
What the state of the art makes reasonable. The chapeau names "state of the art" explicitly. Continuous scanning and continuous testing are now widely available and priced accessibly, which raises the bar for what "regularly" reasonably means compared to 2018.
Your contractual and framework commitments. If your DPA says quarterly, your DPA is your interval. If you also hold PCI DSS, its Requirement 11.4 twelve-month clock is real where the GDPR's is not, and it will govern.
A defensible written position for most SaaS processors looks like this: continuous or at least monthly automated scanning of the production estate, an independent application penetration test at least annually, an additional test on any change that alters authentication, authorisation or tenancy isolation, and retesting of every High and Critical finding. That is a process, it names methods, it has triggers, and it produces evidence at each step.
Why one annual test is a weak Article 32(1)(d) answer
The ICO's 2025 decision is the clearest published regulator reasoning on this, and two paragraphs of it are worth reading closely. At paragraph 62 the Commissioner recorded that the organisation had provided penetration test reports whose scope included vulnerability scanning, and held that "conducting scans as part of penetration test does not exclude the requirement for ongoing, regular scanning mechanisms". At paragraph 63 the Commissioner went further:
the evidence provided by Advanced in relation to penetration tests in the AHC environment shows that these were infrequent for each product and could not be relied upon to serve the same purpose as a regular ongoing vulnerability scanning programme. Where penetration tests were conducted, some of these revealed vulnerabilities which were later exploited in the Incident.
That second sentence is the expensive one. The tests worked. The process around them did not. The Commissioner found the failure to implement comprehensive vulnerability scanning amounted to a failure under both Article 32(1)(b) and Article 32(1)(d) (paragraph 66), and the final penalty was £3,076,320.
This decision is under the UK GDPR rather than the EU instrument, and it should be read as such. The relevance is that Article 32 is textually identical in both, and this is a supervisory authority setting out in detail what it expects a testing process to look like under that text.
Article 28: why processors carry this directly
A SaaS company selling into the EU is almost always a processor, and Article 28 is where a customer's lawyer will meet you. The contract must stipulate, in particular, that the processor:
28(3)(c) "takes all measures required pursuant to Article 32";
28(3)(f) "assists the controller in ensuring compliance with the obligations pursuant to Articles 32 to 36 taking into account the nature of processing and the information available to the processor";
28(3)(h) "makes available to the controller all information necessary to demonstrate compliance with the obligations laid down in this Article and allow for and contribute to audits, including inspections, conducted by the controller or another auditor mandated by the controller".
Three consequences follow that most vendor security questionnaires get to eventually.
You cannot subcontract Article 32 to your cloud provider. Article 28(4) puts the same obligations on a sub-processor and states that the initial processor "shall remain fully liable to the controller for the performance of that other processor's obligations". Your infrastructure provider's certification is a fact about their controls, not about your application.
The audit right in 28(3)(h) is real, and testing evidence is how you survive it at scale. Every enterprise controller has a contractual right to audit you, including by inspection. A processor with a current independent test report, a scan cadence and a closure register answers most of those requests with a document set. A processor without one answers them with meetings.
"Sufficient guarantees" under 28(1) is a procurement gate, not a post-signature problem. The controller's obligation is to use only processors that provide sufficient guarantees. That is the reason a customer's security review asks for your test evidence before signing, and it is why the evidence has commercial value beyond compliance.
The CNIL, France's supervisory authority, puts the practical version of this in its 2024 security of personal data guide: controllers should "provide the means to verify the effectiveness of the data protection guarantees offered by the processor (e.g.: security audits, site visits)". The same guide states that "security audits are an essential means of assessing the level of security of the systems on which the processing of personal data is based", that "carried out periodically, they allow taking changes in processing and threats into account", and that "each audit must produce an action plan, the implementation of which should be monitored at the highest level of the organisation".
Note what the CNIL puts weight on: not the audit, the action plan. Article 32(1)(d) says "testing, assessing and evaluating", and the assessing and evaluating are the parts most programmes skip.
The DPA penetration testing clause template
This is a drafting starting point, not legal advice. Have your own counsel adapt it. It is written to sit inside the technical and organisational measures schedule of a data processing agreement, and it is deliberately anchored to the European Commission's own wording, so it cannot be read as inventing an obligation that the standard clauses do not contemplate.
The anchor is Commission Implementing Decision (EU) 2021/915 of 4 June 2021, which lays down controller-to-processor standard contractual clauses under Article 28(7). Its Annex III, headed "Technical and organisational measures including technical and organisational measures to ensure the security of the data", lists as an example measure:
Processes for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures in order to ensure the security of the processing
And its explanatory note tells you how to fill it in:
The technical and organisational measures need to be described concretely and not in a generic manner.
The same example measure appears in the international-transfer clauses at Commission Implementing Decision (EU) 2021/914. So the drafting question is not whether to include testing. It is how to describe it concretely.
Template clause
Security testing. The Processor shall maintain a documented security testing process satisfying Article 32(1)(d) of Regulation (EU) 2016/679, covering the Processor systems used to process Personal Data under this Agreement. That process shall as a minimum provide for:
> > (a) Automated vulnerability assessment. Authenticated and unauthenticated vulnerability scanning of the in-scope production estate, performed no less frequently than monthly and promptly following any change made to remediate a critical issue. > > (b) Independent penetration testing. Penetration testing of the in-scope applications, application programming interfaces and supporting infrastructure, performed no less frequently than once every twelve months by a party organisationally independent of the team responsible for building and operating those systems. > > (c) Change-triggered testing. Additional penetration testing performed before or promptly after any change that alters authentication, authorisation, tenancy isolation, network segmentation, or the systems on which Personal Data is processed. > > (d) Remediation and retest. Risk rating of every finding, remediation within timescales defined by the Processor's documented policy, and retesting to verify that findings rated High or Critical have been corrected. Findings not corrected shall be recorded as accepted risks with a named owner and a review date. > > (e) Evidence. On the Controller's reasonable request and no more than once in any twelve-month period, save following a Personal Data Breach, the Processor shall make available: the security testing policy; a summary report for the most recent penetration test stating scope, dates, methodology and the independence of the tester; the current status of findings rated High or Critical; and confirmation of retest. The Processor may redact information whose disclosure would compromise the security of the Processor or of its other customers. > > (f) Sub-processors. The Processor shall require each Sub-processor engaged in the processing of Personal Data under this Agreement to maintain security testing obligations no less protective than those set out in this clause, and shall remain fully liable to the Controller for the performance of those obligations. > > (g) Notification. The Processor shall notify the Controller without undue delay where security testing identifies a vulnerability that has been exploited, or that the Processor reasonably believes has resulted in a Personal Data Breach.
Notes for whoever negotiates it
Limb (e) is the one that gets edited. Controllers push for the full report, processors offer a summary. The workable middle is a summary that names scope, dates, method and independence, plus the ability to review a fuller report under NDA at the processor's premises or through a secure data room. Give the summary willingly, because it is what makes limb (e) survive a security review without a call.
Do not accept an unqualified right to test the processor's production environment. It is a genuine risk to other customers on shared infrastructure. Offer a defined testing window in a dedicated environment instead, or offer the independent report.
The frequencies in (a), (b) and (c) are the ones to negotiate honestly. Write the cadence you will actually run. A clause promising quarterly testing that you deliver annually is a contractual breach on top of an Article 32 problem.
Limb (d) matters more than limb (b). The ICO's 2025 decision turned on the process around the tests, not on whether tests happened.
Where GDPR sits against NIS2 and DORA
Three EU instruments talk about testing and only one of them is prescriptive. Getting this ordering right stops a lot of wasted procurement.
Instrument | Does it name penetration testing as a requirement? | Cadence | Who it binds |
|---|---|---|---|
GDPR, Art. 32(1)(d) | No. It requires a process for regularly testing, assessing and evaluating effectiveness | None stated | Every controller and processor handling EU personal data |
NIS2 | No. Our reading of the Directive finds no testing frequency, with "penetration testing" appearing only in recitals (analysis) | None stated in the Directive | Essential and important entities in named sectors |
DORA | Yes for designated entities, through threat-led penetration testing (analysis) | At least every 3 years for TLPT, for entities designated by their competent authority | Financial entities in scope of Regulation (EU) 2022/2554 |
For a SaaS company selling into the EU, the practical order is: GDPR applies to you now and always; NIS2 applies if you are in scope by sector and still leaves the method to you; DORA applies in force only if you are a financial entity or a designated critical ICT third-party provider, and it is the only one of the three that will hand you a cadence.
The exposure, in numbers
Article 83(4) sets the fine ceiling for security failures. Infringements of "the obligations of the controller and the processor pursuant to Articles 8, 11, 25 to 39 and 42 and 43" attract administrative fines "up to 10 000 000 EUR, or in the case of an undertaking, up to 2 % of the total worldwide annual turnover of the preceding financial year, whichever is higher". Articles 28 and 32 both sit inside that range.
The ICO's 2025 processor case shows the arithmetic in practice: the notice records a statutory maximum of £8.7m or 2% of turnover, a starting penalty of £3,845,400, and a 20% reduction giving a final penalty of £3,076,320. The reduction is what a cooperative posture and post-incident remediation buy. The starting number is what the failure costs.
Compare that against what the testing programme costs. Published UK rate cards put the median penetration testing day at £1,000 with a central band of £800 to £1,200, per Stingrai's Penetration Testing Price Index 2026. The relevant comparison is not the fine against the test. It is the fine against a decade of testing.
What the engagement data says about the process
Article 32(1)(d) asks for effectiveness testing, and the honest reason to run it is that it finds things. Across 55 penetration tests and 1,206 verified findings, Stingrai's State of Penetration Testing 2026 recorded that 92.7% of tests surfaced a High or a Critical, that 67.2% of all findings were High or Critical, and that the false-positive rate across the set was 0.74%. The remediation numbers are the ones that map onto the "assessing and evaluating" half of the Article: the median Critical closed in 10.5 days and the median High in 38.0 days.
Two things follow for an Article 32 programme. First, if 92.7% of tests find something serious, then the absence of findings in your own history is a scoping question rather than a security result. Second, a 38-day median for Highs is why the DPA clause above puts remediation and retest in their own limb. The evidence a supervisory authority reads is the closure record, and closure takes weeks, not days.
What this means for defenders
Write the process down before you buy the test. Article 32(1)(d) asks for a process. A testing standard naming methods, cadence, triggers, risk rating and retest is the artifact that answers the article. The report is an output of it.
Run scanning and testing as two different controls. The ICO decision is explicit that testing does not discharge the scanning obligation. Frequency comes from scanning, depth comes from testing.
Own your own application layer. Article 28(4) leaves you fully liable for sub-processors, and no cloud certification covers your authorisation logic or your tenancy boundary.
Put change triggers in the contract, not just the policy. Authentication, authorisation, tenancy isolation and segmentation changes are the ones that make an annual test stale.
Make the evidence pack a sales asset. Article 28(1) means your buyers are legally obliged to check your guarantees. A ready pack shortens security review, which shortens the deal.
Track closure, and be able to prove it. The Article says testing, assessing and evaluating. The last two words are a register with dates in it.
Frequently Asked Questions
Does GDPR require penetration testing?
No, not by name. The word "penetration" appears zero times in Regulation (EU) 2016/679, and the regulation names no test type or methodology anywhere. What Article 32(1)(d) requires is "a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing". Penetration testing is the most common way organisations evidence the "effectiveness" half of that requirement for application and network controls, but the regulation leaves the method to you and judges the result against the risk of your processing.
What does GDPR Article 32(1)(d) actually require?
A process, run regularly, that tests, assesses and evaluates whether your security measures work. Three words carry the weight. "Process" means an ongoing programme rather than a one-off artifact. "Regularly" is undefined and has to be argued from the Article 32(1) chapeau, which weighs state of the art, cost of implementation, and the nature, scope, context and purposes of the processing against the risk to individuals. "Effectiveness" means the evidence has to show the control was exercised, not merely that it exists.
How often does GDPR require security testing?
The GDPR states no interval. The interval you can defend comes from the risk of your processing, the rate of change in your systems, what the state of the art makes reasonable, and any cadence you committed to contractually. For most SaaS processors a defensible written position is continuous or monthly automated scanning, an independent penetration test at least annually, additional testing on defined change triggers, and retesting of every High and Critical finding. Write the cadence you will actually run, because a contract or policy promising more than you deliver is worse than a modest commitment kept.
Do GDPR processors have to do their own penetration testing?
Yes, in practical terms. Article 32(1) binds "the controller and the processor", and Article 28(3)(c) requires the processor contract to stipulate that the processor "takes all measures required pursuant to Article 32". Article 28(4) puts the same obligations on any sub-processor and leaves the original processor "fully liable to the controller" for their performance. A processor cannot discharge Article 32 by citing its cloud provider's certifications, because those describe the provider's controls rather than the processor's own application logic, tenancy isolation and API surface.
Has any regulator fined an organisation over penetration testing under Article 32?
The clearest published decision is the ICO's, on 27 March 2025, imposing a penalty of £3,076,320 on a processor for infringing Article 32(1) UK GDPR. The penalty notice records at paragraph 63 that penetration tests "were infrequent for each product and could not be relied upon to serve the same purpose as a regular ongoing vulnerability scanning programme", and that some findings from those tests "revealed vulnerabilities which were later exploited in the Incident". The Commissioner found breaches of both Article 32(1)(b) and Article 32(1)(d). That is a UK GDPR decision, applying an Article 32 that is textually identical to the EU instrument.
Is a vulnerability scan enough to satisfy GDPR Article 32?
Not on its own, and the same is true in reverse. The ICO stated at paragraph 62 of the 2025 notice that "conducting scans as part of penetration test does not exclude the requirement for ongoing, regular scanning mechanisms". Scanning gives you frequency and coverage across the estate. Penetration testing gives you depth on authorisation, business logic and chained attack paths that no scanner reaches. Article 32(1)(d) asks about effectiveness, and evidencing effectiveness across both control classes takes both methods.
What penetration testing clause should be in a GDPR data processing agreement?
At minimum: automated vulnerability assessment at a stated frequency, independent penetration testing at a stated frequency, change-triggered testing tied to named change types, risk rating with remediation and retest of High and Critical findings, an evidence route for the controller, a flow-down to sub-processors, and a notification trigger. The template earlier on this page sets out drafting language for each of those. It is a starting point rather than legal advice, and it is anchored to the European Commission's own Annex III example measure in Implementing Decision (EU) 2021/915, whose explanatory note asks for measures "described concretely and not in a generic manner".
Can a customer demand to penetration test our production systems under GDPR?
Article 28(3)(h) gives the controller a contractual right to "audits, including inspections", so a request is legitimate. An unqualified right to attack shared production infrastructure is not the right way to satisfy it, because it creates real risk for your other customers. The workable answer is to offer a defined route instead: an independent test report summary, a completed security questionnaire, an inspection under NDA, and where a customer genuinely needs to test, a scheduled window against a dedicated environment with agreed rules of engagement.
Does an ISO 27001 certificate satisfy GDPR Article 32?
It helps, and it is not sufficient by itself. Article 32(3) states that adherence to an approved code of conduct under Article 40 or an approved certification mechanism under Article 42 "may be used as an element by which to demonstrate compliance". An element, not a defence, and ISO 27001 is not an Article 42 GDPR certification. In practice an ISO 27001 certificate is strong supporting evidence that a management system exists, and the Article 32(1)(d) evidence still has to be the testing programme itself. See our guide to ISO 27001 penetration testing requirements for how the same test evidences both.
What are the fines for a GDPR Article 32 breach?
Article 83(4) puts infringements of Articles 25 to 39, which includes both Article 28 and Article 32, at "up to 10 000 000 EUR, or in the case of an undertaking, up to 2 % of the total worldwide annual turnover of the preceding financial year, whichever is higher". The higher tier at Article 83(5), up to EUR 20,000,000 or 4%, covers the basic processing principles and data subject rights rather than security of processing. The ICO's 2025 processor case is a worked example of the lower tier: a stated statutory maximum of £8.7m, a starting penalty of £3,845,400, and a final penalty of £3,076,320 after a 20% reduction.
Does GDPR apply to a SaaS company outside the EU?
Article 3 extends the regulation to processing related to offering goods or services to data subjects in the Union and to monitoring their behaviour in the Union, regardless of where the organisation is established. In practice most non-EU SaaS companies meet Article 32 not because a supervisory authority arrived, but because EU customers are themselves controllers bound by Article 28(1) to use only processors providing "sufficient guarantees". The testing evidence gets requested in procurement long before it gets requested by a regulator.
How does GDPR testing compare with NIS2 and DORA?
GDPR Article 32(1)(d) requires a process with no stated cadence and no named method. NIS2 similarly sets no testing frequency and leaves the method to a risk-based decision, as covered in our NIS2 analysis. DORA is the prescriptive one: designated financial entities must carry out threat-led penetration testing at least every three years, with defined tester requirements, as covered in our DORA TLPT guide. If more than one applies to you, the most prescriptive instrument will end up setting the programme, and the same evidence usually serves the others.
Related reading
Penetration testing requirements by framework, the 2026 matrix, every framework's mandate, cadence and evidence artifact side by side.
ISO 27001 penetration testing requirements, the Annex A control mapping and auditor evidence.
DORA threat-led penetration testing, the one EU instrument with a stated cadence.
Pentest evidence auditors accept, the clause-level evidence guide across SOC 2, ISO 27001, PCI DSS and CMMC.
Penetration Testing Price Index 2026, published day rates and fixed fees.
The State of Penetration Testing 2026, 1,206 verified findings across 55 engagements.
References
European Union. Regulation (EU) 2016/679 (General Data Protection Regulation). Official Journal L 119, 4 May 2016. https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679. Source of every Article quotation on this page, including Articles 5(2), 24, 28, 32, 35(7) and 83(4), read in full on 5 September 2026.
European Commission. Commission Implementing Decision (EU) 2021/915 of 4 June 2021 on standard contractual clauses between controllers and processors under Article 28(7) of Regulation (EU) 2016/679. Official Journal L 199/18, 7 June 2021. https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32021D0915. Annex III technical and organisational measures, including the "processes for regularly testing" example measure and the explanatory note requiring concrete description.
European Commission. Commission Implementing Decision (EU) 2021/914 on standard contractual clauses for the transfer of personal data to third countries. https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32021D0914. Carries the same example measure in its technical and organisational measures annex.
Information Commissioner's Office. Monetary Penalty Notice: Advanced Computer Software Group Limited. 27 March 2025. https://ico.org.uk/media2/gdlfddgc/advanced-penalty-notice-20250327.pdf. Penalty of £3,076,320 for infringement of Article 32(1) UK GDPR, with detailed findings at paragraphs 61 to 66 on vulnerability scanning cadence and the limits of relying on periodic penetration tests.
Information Commissioner's Office. Advanced Computer Software Group Limited, enforcement action record. https://ico.org.uk/action-weve-taken/enforcement/2025/03/advanced-computer-software-group-limited/. The enforcement listing for the above decision.
Commission Nationale de l'Informatique et des Libertes (CNIL). GDPR Practice Guide: Security of Personal Data, 2024 edition. https://www.cnil.fr/sites/default/files/2024-03/cnil_guide_securite_personnelle_ven_0.pdf. A supervisory authority's own guidance on periodic security audits, action plans and verifying processor guarantees.
Stingrai. Does NIS2 require penetration testing or red teaming? https://www.stingrai.io/blog/does-nis2-require-penetration-testing-red-teaming. Directive-level analysis of NIS2 testing obligations.
Stingrai. DORA Threat-Led Penetration Testing 2026. https://www.stingrai.io/blog/dora-threat-led-penetration-testing-2026. Article-level analysis of the DORA TLPT regime and its three-year cadence.
Stingrai. Penetration Testing Price Index 2026. https://www.stingrai.io/blog/penetration-testing-price-index-2026. Median published day rate and central band across 30 public-sector rate cards.
Stingrai. The State of Penetration Testing 2026. https://www.stingrai.io/blog/state-of-penetration-testing-2026. 1,206 verified findings across 55 penetration tests, severity mix, false-positive rate and remediation timing by severity.
Stingrai. Pricing. https://www.stingrai.io/pricing. Published package prices for one web application and its APIs.
Build the Article 32 evidence your EU customers ask for
The Article 32(1)(d) obligation is a process, and the evidence a controller's security reviewer wants is the same evidence a supervisory authority would want: a testing standard, an independent report that names scope, method and dates, a findings register, and a retest that closes it. Stingrai's penetration testing supports GDPR, ISO 27001, SOC 2 and PCI DSS programmes by producing exactly that bundle, on both one-time annual engagements and continuous testing programmes. Senior penetration testers work the target alongside Snipe, our autonomous web application agent, throughout the engagement, which is how authorisation and tenancy-isolation flaws get found rather than assumed.
Book a free scoping call to map your processing to a test scope, request a quote for your application and APIs, or see published package prices on the pricing page.
