Which standards require a security testing and penetration testing policy?

ISO/IEC 27001:2022: 8.29; DORA (Regulation (EU) 2022/2554): Art. 24, Art. 25; The NIS2 Directive: Art. 21(2)(f).

What must a security testing and penetration testing policy contain under ISO 27001?

8.29: Define and run security testing across the development life cycle. The ISO 27002 guidance beside 8.29: Requires security testing processes to be defined and implemented within the development life cycle.

Who should own the security testing and penetration testing policy?

The clauses imply the information security lead (CISO or ISMS manager). The register names the role so the line on your list can carry a name.

How often should a security testing and penetration testing policy be reviewed?

Annual (the register's default: the clauses say planned intervals and on significant change, and do not fix a period).

Is there a template for a security testing and penetration testing policy?

Yes: https://compliance.theartofservice.com/policy-templates/penetration-testing-policy

Every policy type · Operations and technology

Security testing and penetration testing policy

How and how often systems are tested by attack, by whom, under what rules of engagement, and how findings are tracked to closure.

How the register reads it

Also called	pen test policy, VAPT, resilience testing
Family	Operations and technology
Document type	Policy. The regimes ask for the content, not the label; a line pasted as a standard, procedure, plan or schedule is placed here with the label noted.
Expected owner	The information security lead (CISO or ISMS manager).
Review cadence	Annual (the register's default: the clauses say planned intervals and on significant change, and do not fix a period).
On the gap list when	DORA is ticked and no line resolves to it (ISO 27001, NIS2 require it too, inside a parent document, so they do not list it separately).
Template	Penetration testing policy.

Which standards require it, and what each expects it to contain

4 requiring clauses, 3 regimes

Shown on a register for the regimes you tick; with none ticked, ISO 27001 is applied. Requirement text drawn from a human-verified compliance corpus under licence: the corpus statement of each clause, not the instrument verbatim.

ISO/IEC 27001:2022

ISO 27001 8.29 Security testing in development and acceptance

Define and run security testing across the development life cycle.

What the ISO 27002 guidance expects the document to say: Requires security testing processes to be defined and implemented within the development life cycle.

Evidence an auditor accepts: The security testing process defining what testing is performed at which stage, and the acceptance criteria; test results for the period, covering the techniques used such as static analysis, dynamic testing, dependency scanning and penetration testing; evidence testing occurs in the development lifecycle and again at acceptance, rather than only before a major release
Common gap: testing only after release
Source: ISO/IEC 27001:2022; guidance ISO/IEC 27002:2022

DORA (Regulation (EU) 2022/2554)

DORA Art. 24 General requirements for the performance of digital operational resilience testing

Financial entities shall establish, maintain and review a sound and comprehensive digital operational resilience testing programme as an integral part of the ICT risk management framework, following a risk-based approach.

Evidence an auditor accepts: A documented digital operational resilience testing programme
Common gap: No resilience testing programme
Source: DORA (Regulation (EU) 2022/2554)

DORA Art. 25 Testing of ICT tools and systems

The testing programme shall include a range of assessments and tests (e.g. vulnerability assessments and scans, open-source analyses, network security assessments, gap analyses, physical security reviews, questionnaires, source-code reviews, scenario-based tests, compatibility/performance tests, end-to-end and penetration testing), with critical ICT systems tested at least yearly.

Evidence an auditor accepts: Test plans and results across the required assessment types; at least-yearly testing of critical ICT systems
Common gap: Critical systems not tested annually
Source: DORA (Regulation (EU) 2022/2554)

The NIS2 Directive

NIS2 Art. 21(2)(f) Policies and procedures to assess the effectiveness of the cybersecurity risk-management measures

The entity has to be able to say whether its measures work, not merely that they exist. That calls for a defined assessment approach with a schedule, someone sufficiently independent of the people who operate the control doing the assessing, criteria for what effective means, and a route by which findings become tracked remediation. Testing, measurement and independent review all count; a maturity self-score does not, because it measures opinion. This point is the one that closes the loop back to Article 21(4), since the corrective-action duty is triggered by the entity finding it does not comply, and effectiveness assessment is how it finds out.

Evidence an auditor accepts: The documented effectiveness assessment approach, its criteria and its schedule; assessment and test results for the current period, covering the Article 21(2) categories; evidence of independence between the assessor and the control operator
Common gap: Effectiveness inferred from a maturity self-assessment rather than tested
Source: NIS2 Directive

Do this for every document on your list

Paste the list and get this reading for every document at once, with the owner and cadence against each, the clauses quoted, and the documents the regimes expect that the list does not carry. Eight documents free, no account.

Build a register

Secure development policy · Threat intelligence procedure