Penetration Testing Policy Template: Frequency, Authorisation, Testers and Findings SLAs Set

Penetration tests go wrong for governance reasons more often than technical ones: nobody signed the authorisation, a cloud provider's rules were broken, the tester was unqualified, or the report sat unread until the next annual test found the same issues. This template gives you numbered policy statements for when systems are tested, who may authorise and perform tests, how testing is controlled, how findings are fixed and retested, and how results are reported. It follows CIS Controls v8.1 Control 18 (whose safeguards require external and internal tests no less than annually), NCSC guidance on penetration testing and the cloud providers' own testing rules, and it maps to ISO/IEC 27001:2022, NIST CSF 2.0 and NIST SP 800-53. It is written for security leaders, testing managers and risk owners who need a policy they can adopt and defend to auditors. How to scope an individual test is covered in the Penetration Test Scoping Checklist; this page is the policy document.

How to use this template

• Replace text in square brackets, such as [Organisation], [Head of Security Testing] and [30 days], with your own roles and values. Bracketed values are illustrative starting points, not regulatory requirements.
• "Must" is mandatory; "should" is recommended practice where a documented deviation is acceptable.
• Check the frequency table against obligations that bind you, such as payment card, financial services or public sector requirements. See the Penetration Testing Compliance Requirements Guide.
• Keep per-test detail (scope, rules of engagement, contacts, dates) in a test plan for each engagement, not in this policy.
• Use this policy with the Vulnerability Management Policy Template. NCSC describes penetration testing as assurance over vulnerability management, similar to an external audit, so the two remediation timelines must match.

Choosing test frequency

1. Purpose

This policy sets the requirements for planning, authorising, performing and acting on penetration tests of [Organisation]'s systems. Its aim is to give independent assurance that security controls and vulnerability management work as intended, to find exploitable weaknesses before attackers do, and to ensure testing itself is lawful, safe and controlled, in line with [Organisation]'s [Information Security Policy].

2. Scope

This policy applies to all penetration tests, red team exercises and similar adversarial security tests of systems owned, operated or used by [Organisation], including:

• External and internal networks, servers, end-user devices and wireless networks.
• Web and mobile applications, APIs and software developed or procured by [Organisation].
• Cloud infrastructure, SaaS configurations and identity systems, including identity providers, directories, service accounts and API credentials.
• Operational technology and IoT, subject to section 4.5.
• Social engineering and physical security tests, which need the extra approvals in section 4.2.

It applies to internal testers and to external providers. Automated vulnerability scanning is covered by the [Vulnerability Management Policy], and bug bounty and coordinated disclosure by the [Vulnerability Disclosure Policy].

3. Roles and responsibilities

4. Policy statements

4.1 Testing programme

• [Organisation] must maintain a documented penetration testing programme appropriate to its size and complexity. As described in CIS Safeguard 18.1, it must define scope (network, web application, API, hosted services and physical controls), frequency, limitations such as acceptable hours and excluded attack types, points of contact, how findings are routed for remediation, and retrospective requirements.
• [Head of Security Testing] must publish an annual testing plan, based on the frequency table, the asset inventory and risk assessment, approved by [CISO].
• Testing must be risk-driven: systems with the highest business impact, internet exposure or sensitive data must be tested first and most often.
• The current vulnerability assessment for a system should be shared with testers, so the test checks whether known issues are understood and what has been missed.

4.2 Authorisation

• No test may begin without written authorisation from the system owner and [Head of Security Testing]. Testing without authorisation may be unlawful (for example under the UK Computer Misuse Act 1990) and is prohibited.
• Every engagement must have a signed test plan or rules of engagement stating scope (named hosts, ranges, URLs, accounts), exclusions, dates and hours, testing methods allowed and prohibited, data handling, emergency contacts and stop conditions. See the Red Team Rules of Engagement Template.
• Where systems are hosted or operated by a third party, testing must follow that party's rules and any required approval must be obtained first. Cloud providers publish their own rules: AWS lists services customers may test without prior approval and requires a Simulated Events form at least two weeks ahead for red team, command-and-control, phishing and malware simulations; Microsoft's Security Testing Rules of Engagement prohibit denial-of-service testing and testing other customers' resources.
• Denial-of-service, load flooding and destructive testing are prohibited unless separately approved by [CISO] and permitted by the hosting provider.
• Social engineering and physical tests require additional approval from [CISO], [HR] and [Legal], and testers must carry an authorisation letter with a 24-hour verification contact.

4.3 Tester qualifications and independence

• Tests must be performed by qualified, experienced testers, as required by CIS Safeguard 18.2 and NCSC guidance. External providers must hold [CREST / CHECK / equivalent recognised] accreditation, and lead testers must hold [named certifications] or demonstrate equivalent experience.
• For UK government and critical national infrastructure systems, [Organisation] should use providers assured under the NCSC CHECK scheme where applicable.
• Annual external tests must be performed by a party independent of the team that built or operates the system. Internal teams may perform additional tests.
• External providers must be vetted to [Organisation]'s supplier standard, sign a confidentiality agreement and a data processing agreement where personal data may be accessed, and hold professional indemnity insurance of at least [amount].
• Providers should be rotated or the testing team changed at least every [three years] to bring fresh perspective.

4.4 Conduct of testing

• Testers must use only accounts and credentials issued for the test. Test accounts must be created for the engagement, time-limited, monitored and disabled within [24 hours] of test end. Production credentials found during testing must be reported, not reused beyond what the test plan permits, and rotated by the system owner.
• Testers must stop and notify the emergency contact immediately if they find evidence of a prior compromise, cause service degradation, or access data outside scope.
• Critical findings (for example remote code execution, authentication bypass or exposed secrets on internet-facing systems) must be reported to [Head of Security Testing] within [24 hours], not held for the final report.
• Tools, payloads and implants must be removed after testing and their removal confirmed in the report.
• Test data, including screenshots, credentials and extracted records, must be encrypted in transit and at rest, kept only as long as needed, and securely deleted by the provider within [30 days] of report acceptance, with written confirmation.

4.5 Sensitive and operational systems

• Testing of production OT, safety systems, medical devices or fragile legacy systems must be approved by the system owner and operations lead, use passive or low-impact methods where possible, and take place in agreed windows with engineers present. See the OT Penetration Testing Guide.
• Where a test environment is used instead of production, it must match production configuration closely enough for results to be valid, and the report must state the difference.

4.6 Reporting

• Reports must include an executive summary, scope and methodology, each finding with evidence, risk rating, affected assets and remediation advice, and an opinion on how accurate [Organisation]'s own vulnerability assessment was.
• Findings must be rated using [the provider's scale aligned to Critical, High, Medium, Low, Informational] and CVSS where applicable. Deviations from standard ratings must be justified.
• Risk decisions remain with [Organisation]. Provider ratings may be adjusted only with documented justification and must not be used to downplay issues.
• Reports are classified [Confidential] and shared only with named recipients.

4.7 Remediation, retesting and validation

• Every finding must be logged in [ticketing system] with an owner within [5 working days] of the report, and remediated within the following service levels:

• Critical and High findings are closed only after a successful retest or equivalent technical verification, not on the owner's confirmation alone.
• After each test, [Security operations] must validate whether the techniques used were detected and, where needed, update detection rules and controls, as described in CIS Safeguard 18.4.
• Recurring findings across tests must be treated as a process failure and raised with [CISO], because they show the underlying cause has not been fixed.
• Findings that cannot be fixed in time require an exception under section 5.

5. Exceptions

• Exceptions to testing frequency or remediation timelines must be requested by the system owner, recorded in [risk register] with compensating controls and an expiry date, and approved by [CISO] for Critical and High findings.
• Exceptions must not exceed [90 days] for Critical and High findings and must be re-approved, not rolled over.
• No exception may permit testing without written authorisation.

See the Security Exceptions and Risk Acceptance Guide.

6. Compliance and monitoring

Compliance will be checked by [internal audit]. Breaches of section 4.2 may lead to action under [disciplinary procedure] or termination of a provider contract.

7. Review and approval

• Policy owner: [CISO]. Approved by: [risk committee / executive board] on [date].
• Review at least annually and after any incident caused or missed by testing, a major change in the estate, or new regulatory requirements.
• Version history: [version], [date], [summary of change], [approver].
• Related documents: [Information Security Policy], [Vulnerability Management Policy], [Vulnerability Disclosure Policy], [Supplier Security Policy], [Incident Response Plan].

Implementation guidance

Rolling out the policy

1. Map obligations: list every contractual and regulatory testing requirement and set the frequency table to the strictest one for each asset group.
2. Build the plan from the inventory: rank systems by exposure and impact, and schedule tests so the highest-risk systems are not all in the same quarter.
3. Standardise paperwork: create one authorisation letter, one rules of engagement template and one report template, and require providers to use them. The Penetration Testing Services RFP Template helps when buying.
4. Agree findings routing before the first test: set up the ticket workflow and SLA clock so reports do not stall.
5. Pilot on one system, including a retest and a detection validation session, then apply organisation-wide.

Decisions for small and large organisations

• Small organisations: one annual external test of internet-facing systems and the main application, using an accredited provider, plus retests of Critical and High findings. CIS places Safeguards 18.1 to 18.3 in Implementation Group 2, so a formal programme is expected once you reach that size.
• Large organisations: a rolling programme across asset groups, internal testers for continuous work, external independent tests annually, and periodic threat-led or red team exercises. See the Threat-Led Penetration Testing Guide.
• Penetration test or red team: a penetration test finds as many exploitable weaknesses as possible in a defined scope; a red team tests detection and response against a goal. Choose a red team only once regular testing and remediation work.

Common failure patterns

• Annual test as the only assurance: NCSC notes tests can be a year or more apart, so issues introduced between tests go unseen without regular scanning and control testing.
• Scope written around known-good systems: legacy, acquired and shadow systems left out because they might fail.
• Test accounts left behind: privileged test accounts or service credentials remain active months after the engagement.
• Cloud rules ignored: testing prohibited activities on a provider's infrastructure, risking account suspension.
• Reports filed, not fixed: the same findings reappear year after year because no one owned the root cause.

Framework mapping

For method and depth see the Penetration Testing Guide, the CIS Control 18 Penetration Testing Guide and Reading and Acting on a Penetration Test Report Guide. Sources: NCSC: Penetration testing, CIS: Control 18 Penetration Testing, CIS: Controls Assessment Specification, Control 18, NIST: SP 800-115 Technical Guide to Information Security Testing and Assessment, AWS: Penetration Testing policy, Microsoft: Security Testing Rules of Engagement and NCSC: CHECK penetration testing.

This template is provided for guidance and must be adapted to your organisation. It is not legal advice. Related NHI Mgmt Group resources: Penetration Test Scoping Checklist · Penetration Testing Provider Buyer's Guide · Red Teaming Guide · Vulnerability Disclosure Policy Template