Is penetration testing mandatory by law in the Netherlands?

Rarely as a literal obligation. The regimes that come closest are the DigiD norm (annual assessment with a penetration test as fixed evidence), DORA for financial entities (Article 25) and PCI DSS for card payments (Requirement 11.4). NIS2 via the Cyberbeveiligingswet, the GDPR, NEN 7510 and BIO 2.0 require you to test the effectiveness of your measures, which auditors expect you to evidence with a penetration test.

Does NIS2 require a penetration test?

Not by name. Article 21(2)(f) requires policies and procedures to assess the effectiveness of cybersecurity risk-management measures. Supervisors read that as independent testing of the systems behind essential or important services, evidenced by a penetration test report. The Dutch Cyberbeveiligingswet carries the same requirement.

Which regulations name penetration testing explicitly?

PCI DSS v4.0.1 (Requirement 11.4), DORA (Article 25, with TLPT in Articles 26 and 27), the FTC Safeguards Rule under GLBA (16 CFR 314.4(d)(2)), NYDFS 23 NYCRR 500.5, FedRAMP control CA-8 and, as a required input to the annual assurance report, the Logius DigiD norm. Everything else requires effectiveness testing without prescribing the method.

Is a penetration test required for ISO 27001 certification?

The standard does not say so, but certification auditors ask for one. Annex A controls 8.8 and 8.29 and clause 9.1 require vulnerability management, security testing and effectiveness evaluation, and the penetration test report is the standard evidence. Expect a nonconformity if you cannot produce one for the systems in your ISMS scope.

How often does a penetration test have to be done for compliance?

Annually is the common floor. PCI DSS, DORA, NYDFS, GLBA, FedRAMP and DigiD all set a 12-month cycle, and ISO 27001, NIS2 and NEN 7510 auditors expect the same. Most also require a test after significant changes. PCI DSS adds six-monthly segmentation testing for service providers; DORA adds TLPT every three years for designated entities.

Does the GDPR require penetration testing?

Not in those words. Article 32(1)(d) requires a process for regularly testing, assessing and evaluating the effectiveness of security measures. Supervisory authorities judge a breach of an untested system against that article, and penetration test reports are the usual evidence in breach investigations and DPIAs. Frequency must be proportionate to the risk.

Can a vulnerability scan replace a penetration test for compliance?

Usually not. PCI DSS, NYDFS and GLBA require both and keep them separate. Where a regime only asks for effectiveness testing, auditors accept a scan as part of the evidence but expect a manual test for internet-facing and high-impact systems, because a scan cannot show whether findings can be chained or whether authorisation and business logic hold.

1 November 2026 · 11 min read · By Michael van Mameren, Lead Penetration Tester (OSCP)

Is penetration testing mandatory? What NIS2, DORA, PCI DSS, ISO 27001, the GDPR, DigiD and the US regulators actually require

Short answer: in most jurisdictions no single law says 'you must run a penetration test'. A growing number of regimes name it outright, and the rest require you to prove that your controls work, which in practice ends in the same report. This guide takes each regime in turn: what the text literally asks, whether a penetration test is named, and what the auditor or supervisor accepts as evidence.

Scope a compliance penetration test

The short answer: rarely mandatory in name, unavoidable in practice

Penetration testing is explicitly required by a handful of regimes and implicitly required by most of the others. The explicit group is small and precise: PCI DSS v4.0.1 (Requirement 11.4), DORA (Article 25, with Articles 26 and 27 for threat-led testing), the FTC Safeguards Rule under GLBA (16 CFR 314.4(d)(2)), New York's 23 NYCRR 500.5, FedRAMP control CA-8 and, as a fixed input to the annual assurance report, the Dutch DigiD norm. Under these, only scope and cadence are open questions.

The implicit group is larger and covers almost every organisation of size in the EU and the US: NIS2 and its Dutch transposition, the GDPR, ISO 27001, NEN 7510, BIO 2.0, HIPAA and CMMC 2.0. None of these texts contain the words 'penetration test' as a hard obligation. All of them require you to assess, test or evaluate the effectiveness of your security measures, and the people who check compliance have settled on the penetration test report as the standard evidence for the technical half of that requirement.

So the honest answer to 'is a pentest mandatory?' has two parts. Legally: only under the explicit regimes. Practically: if you are audited, certified, supervised or assessed against any framework below, you will be asked for one, and 'we did not think it was required' is not an answer an auditor has ever accepted. The rest of this page goes regime by regime.

EU and Dutch regimes, one by one

For each regime: the literal requirement, whether penetration testing is named, and what the auditor or supervisor accepts as evidence.

NIS2 and the Dutch Cyberbeveiligingswet

Article 21(2)(f) of Directive (EU) 2022/2555 requires 'policies and procedures to assess the effectiveness of cybersecurity risk-management measures'. Penetration testing is not named. The Dutch transposition, the Cyberbeveiligingswet (Cbw), carries the same requirement for essential and important entities. Supervisors expect independent testing of the systems behind essential services; a scan alone rarely demonstrates 'effectiveness'. Evidence accepted: a risk-based testing policy, the latest penetration test of in-scope systems, remediation tracking, a retest.

DORA (financial sector)

Regulation (EU) 2022/2554, applicable since 17 January 2025. Article 24 requires a resilience testing programme that tests all systems supporting critical or important functions at least annually. Article 25 lists penetration testing by name among the required test types. Articles 26 and 27 add threat-led penetration testing (TLPT) at least every three years for entities designated by DNB or the AFM. Named: yes. Evidence accepted: the written programme, annual test reports per critical function, tester independence, and for designated entities the TLPT attestation.

PCI DSS v4.0.1 (payment card data)

Requirement 11.4 requires external and internal penetration testing at least once every 12 months and after any significant infrastructure or application change, following a documented methodology (11.4.1), with exploitable findings corrected and retested (11.4.4) and segmentation controls tested (11.4.5, and every six months for service providers under 11.4.6). Named: yes, in detail. The Qualified Security Assessor or your SAQ requires the report, the methodology, the retest evidence and proof of tester independence.

ISO/IEC 27001:2022

Not a law. ISO 27001 is a voluntary certification standard, mandatory only where a customer, tender or sector rule demands it. It never says 'penetration test'. Annex A control 8.8 (management of technical vulnerabilities), control 8.29 (security testing in development and acceptance) and clause 9.1 (monitoring, measurement, analysis and evaluation) require you to identify vulnerabilities, test security and evaluate effectiveness. Certification body auditors ask for the latest penetration test report as the evidence for 8.8 and record its absence as a nonconformity. Evidence accepted: an annual test of the ISMS scope, remediation records, a retest.

GDPR (personal data)

Article 32(1)(d) of Regulation (EU) 2016/679 requires 'a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures'. Penetration testing is not named. The Autoriteit Persoonsgegevens (AP) and its EU counterparts judge a breach of an untested system against Article 32, and penetration test reports are the standard exhibit in breach investigations and DPIAs. Evidence accepted: periodic, risk-proportionate testing of systems that process personal data, with records.

DigiD (Logius norm, public-sector login)

Every organisation with a DigiD connection must pass an annual ICT security assessment against the Logius DigiD norm (currently v3.0), reported by a NOREA-registered IT auditor. The implementation layer of the norm is assessed on technical evidence, and a penetration test of the DigiD application and its platform is a fixed part of it. Named: yes, as a required input to the assurance report. Logius can suspend a connection that remains non-compliant.

NEN 7510:2024 and MedMij (healthcare)

NEN 7510 is law for Dutch care providers through the Wabvpz and the Besluit elektronische gegevensverwerking door zorgaanbieders. It follows the ISO 27001 structure, so control 8.8 and the healthcare-specific access and logging controls apply. 'Penetration test' does not appear as an obligation, but certification auditors and the IGJ ask for the latest report, particularly for patient portals, EPD integrations and FHIR endpoints. The MedMij scheme additionally requires demonstrable security testing of the MedMij-facing environment. Evidence accepted: test reports on patient-data systems, remediation, a retest.

BIO 2.0 (Dutch government)

The Baseline Informatiebeveiliging Overheid is mandatory for central government, provinces, municipalities and water boards, and reaches suppliers through procurement. BIO 2.0 aligns with ISO/IEC 27002:2022; its vulnerability-management and technical-compliance controls expect regular, independent testing of internet-facing systems, and municipalities account for compliance annually through ENSIA. Named: not literally, but the government measures and the ENSIA questions ask for recent penetration tests of externally reachable systems. Evidence accepted: test reports per system, improvement plans, a retest.

US regimes: what they require

For US buyers and for European organisations with US customers, subsidiaries or government contracts. Three of these name penetration testing outright; the other two require an evaluation that assessors expect a test to evidence.

HIPAA Security Rule (healthcare)

45 CFR 164.308(a)(8) requires periodic technical and non-technical evaluation of security safeguards, alongside the risk analysis in 164.308(a)(1)(ii)(A). Penetration testing is not named in the current rule. A proposed Security Rule update published in January 2025 would make annual penetration testing explicit; at the time of writing it is not final. The Office for Civil Rights asks for evidence of the technical evaluation, and a penetration test report is the usual exhibit.

GLBA Safeguards Rule (non-bank financial institutions)

16 CFR 314.4(d)(2) requires either continuous monitoring or, as the alternative, annual penetration testing plus vulnerability assessments at least every six months and after material changes. Named: yes, as one of two permitted routes. The FTC enforces the rule; banks and credit unions are examined against the FFIEC handbook instead, where examiners expect independent testing of the systems that move customer funds.

NYDFS 23 NYCRR Part 500 (New York financial services)

Section 500.5(a)(1) requires penetration testing of information systems from both inside and outside the boundaries at least annually, by a qualified internal or external party, and 500.5(a)(2) adds vulnerability scanning. Named: yes, explicitly and annually. The Department of Financial Services checks it through the annual certification signed by the CISO and a senior officer.

CMMC 2.0 Level 2 (US defense supply chain)

Level 2 maps to NIST SP 800-171. Practice CA.L2-3.12.1 requires periodic assessment of security controls for effectiveness, and RA.L2-3.11.2 requires vulnerability scanning. Penetration testing is not named at Level 2; it enters at Level 3 through NIST SP 800-172. C3PAO assessors accept a penetration test as objective evidence for 3.12.1 and related practices.

FedRAMP Rev. 5 (cloud services to US federal agencies)

Control CA-8 requires penetration testing at least annually, performed by the Third Party Assessment Organization against the attack vectors prescribed in the FedRAMP Penetration Test Guidance, and CA-8(2) adds an annual red team exercise. Named: yes. The 3PAO performs the test and the authorizing agency reviews it.

Which regimes name penetration testing, and who checks

'Yes' means the text itself names penetration testing; 'implied' means auditors expect a test as evidence for an effectiveness or vulnerability-management requirement.

Regime	Names penetration testing	Frequency	Who checks
NIS2 / Cyberbeveiligingswet	Implied (Art. 21(2)(f))	Risk-based; annually for critical systems in practice	National sector supervisors
DORA	Yes (Art. 25); TLPT (Art. 26)	Annually; TLPT every three years for designated entities	DNB, AFM
PCI DSS v4.0.1	Yes (Req. 11.4)	Annually and after significant change; segmentation every six months for service providers	QSA or SAQ, acquiring bank
ISO/IEC 27001:2022	Implied (A.8.8, A.8.29, 9.1)	Annually in practice	Certification body auditor
GDPR	Implied (Art. 32(1)(d))	Regularly, proportionate to risk	Autoriteit Persoonsgegevens, EU DPAs
DigiD norm v3.0	Yes, as assessment input	Annually	NOREA IT auditor, Logius
NEN 7510:2024 / MedMij	Implied (control 8.8); MedMij requires testing	Annually in practice	Certification auditor, IGJ, MedMij
BIO 2.0	Implied	Annually for internet-facing systems; ENSIA cycle	ENSIA, internal audit, ADR
HIPAA Security Rule	Implied (164.308(a)(8)); explicit in proposed rule	Periodic; annual under the proposal	HHS Office for Civil Rights
GLBA Safeguards Rule	Yes (314.4(d)(2), alternative to continuous monitoring)	Annually	FTC; FFIEC agencies for banks
NYDFS Part 500	Yes (500.5(a)(1))	Annually	NY Department of Financial Services
CMMC 2.0 Level 2	Implied (CA.L2-3.12.1); named at Level 3	Periodic; assessment every three years	C3PAO, DIBCAC
FedRAMP Rev. 5	Yes (CA-8, CA-8(2))	Annually	3PAO, authorizing agency

Why 'not literally required' still ends in a penetration test

Compliance texts are written as outcomes, not procedures. 'Assess the effectiveness of measures', 'manage technical vulnerabilities', 'periodic technical evaluation': each is a question the auditor must answer with evidence. A policy document shows intent. A vulnerability scan shows known weaknesses. Only a penetration test shows whether a skilled attacker can actually get in, chain findings and reach the data the regime protects. That is why the test report has become the common currency across frameworks that never mention it.

The second reason is convergence. ISO 27001, NEN 7510 and BIO 2.0 share one control structure; DORA and NIS2 were drafted with ISO 27001 in mind; PCI DSS, NYDFS and FedRAMP borrow from each other. One well-scoped annual penetration test, mapped to the systems each regime cares about, remediated and retested, satisfies the testing requirement of most of these regimes at once. The organisations that struggle treat each framework as a separate exercise.

The third reason is accountability. Under NIS2 and DORA, management bodies are personally responsible for overseeing risk-management measures; under the GDPR, a breach of an untested system is judged against Article 32. A board that can show a report, a remediation plan and a retest has an easier conversation with the supervisor than one that cannot.

What you should do now

Eight steps, in order, to move from 'are we required to?' to a testing programme you can defend in front of any auditor.

List the regimes that apply to you by sector, data type, customers and geography, including those inherited through contracts: PCI DSS via your acquirer, BIO via public-sector customers, DORA via financial clients.
For each regime, note the literal requirement and the cadence, starting from the table above, and mark which ones name penetration testing outright.
Map your systems to the regimes: which applications, networks and cloud accounts hold cardholder data, personal data, patient data, DigiD sessions or critical-function workloads.
Define one annual programme that covers the union of those systems, at the cadence of the strictest regime that applies: annually at minimum, after significant change, every six months where PCI DSS segmentation testing applies.
Choose a tester independent from the teams that build and run the systems, with qualifications you can show an auditor: named testers, certifications, a methodology aligned with PTES, OWASP WSTG and NIST SP 800-115.
Ask for a report that cites the requirement per finding, so your compliance team can file one report under several frameworks without rework.
Remediate on a risk-ranked schedule and retest; most regimes, and every auditor, treat a report without a retest as unfinished.
Keep the evidence trail together: scope statement, authorisation, report, remediation tickets, retest report, date of the next test.

How HackersHub tests for compliance

We scope each engagement to the regimes you identified in step one. The scope statement lists the systems per framework, the report maps every finding to the relevant article or control, and the executive summary is written for the auditor or supervisor who will read it, not only for the engineers who fix it.

Every HackersHub tester holds at least OSCP, with OSWE and CREST-certified testers on the team, and is named in the report. Our methodology follows PTES, OWASP WSTG and MASTG, and NIST SP 800-115. A verification retest of medium and higher findings within 90 days is included, which closes the retest requirement most regimes carry. We have worked this way for more than ten years from Amsterdam, Netherlands.

Frequently asked questions

Deep dives per regime and related guides

Which of these regimes apply to you?

Tell us your sector, your data and your customers. We scope one penetration test that produces the evidence each of your auditors and supervisors will ask for, and we report it so every team can file it.

Scope a compliance penetration test Talk to an expert