No testing before the signature
The authorisation letter is an approval step assigned to a named system owner. The open approval makes it obvious to everyone that testing is not yet cleared, and the record shows who signed and when.
Penetration Test Checklist Template
Most pen test problems are not found by the testers. They are a missing authorisation letter, a scope that left out the new API, a SOC that called the incident line on day one, and a report whose findings were still open when the auditor asked a year later.
You can hire excellent testers and still get poor value from a penetration test. The value depends on the work your own team does before the first packet is sent and after the report arrives. This free penetration test checklist covers that work from start to finish. Before the test, it covers scope, tester selection, rules of engagement, written authorisation and the cloud providers’ testing policies. During the test, it covers daily check-ins, stop conditions and critical findings raised mid-engagement. Afterwards, it covers report triage, remediation with owners and dates, a retest when one is needed, and an evidence pack ready for PCI DSS, SOC 2 or ISO 27001 auditors.
The Tester’s Job vs Your Job: Where Pen Tests Succeed or Stall
A penetration test is a short, intense engagement wrapped in weeks of internal work. The testing firm brings skill and tooling for a fixed window. Everything either side of that window belongs to you: deciding what is worth testing, proving the testers have permission, keeping operations informed, and turning a PDF of findings into fixed systems. When that internal work is done informally, the same failures recur every year. Scope is copied from last year, retests are never booked and nobody can find the signed authorisation.
Unlike an automated scan, a pen test shows whether weaknesses can actually be chained into access. Its findings should flow into the same queue, deadlines and exception rules as your scanner output, so run them through your vulnerability management cycle rather than a separate spreadsheet.
The testing firm
Delivers the engagement
Brings: methodology, qualified testers, tooling and exploitation skill.
Window: usually days to a few weeks.
Output: a report with findings, severity ratings and reproduction steps.
Cannot do: authorise itself, decide your risk appetite or fix anything.
Your security team
Owns everything around it
Brings: scope, permission, context, internal contacts and remediation owners.
Window: weeks before the test and months after it.
Output: signed authorisation, triaged findings, verified fixes and an evidence pack.
Tooling: a checklist with owners, approvals and attached records.
Cloud-hosted targets have their own rules. AWS does not require pre-approval for a published list of services, including EC2, RDS, Lambda and CloudFront, but it prohibits denial-of-service testing and requires prior approval for any testing that includes command and control. Red team exercises and other simulated events go through its request form at least two weeks ahead. Microsoft has not required pre-approval for Azure testing since 15 June 2017, provided testers follow its Unified Penetration Testing Rules of Engagement, which also ban denial-of-service testing. Google Cloud does not need to be contacted, as long as tests follow its Acceptable Use Policy and terms and affect only your own projects. SaaS and managed hosting providers set their own terms, so check each contract.
What the Penetration Test Checklist Covers
Six phases run from the first scoping conversation to a closed engagement with its evidence filed. Retest and segmentation tasks stay hidden unless the engagement needs them.
Phase 1
Phase 1: Scope & Tester Selection
Owned by the security lead, starting six to eight weeks before the planned test window.
- Record why this test is happening — annual requirement, significant change, customer contract or a new application; the reason shapes the scope
- List in-scope targets and explicit exclusions — address ranges, hostnames, applications, APIs and cloud accounts, each with an owner, noting any hosted by a third party
- Choose the test types — external, internal, web application, API, cloud configuration or segmentation
- Review last year’s report and what has changed since — aim effort at new and altered systems, and confirm old findings stayed fixed
- Select a qualified, independent tester — CREST accreditation, or NCSC CHECK status where UK public sector work requires it, and no role in running the systems under test
- Sign the contract and data handling terms — how the tester stores evidence and credentials, and when both are destroyed
Phase 2
Phase 2: Rules of Engagement & Authorisation
The authorisation is an approval step assigned to someone with authority over every in-scope system.
- Agree testing windows and blackout dates — avoid month-end, major releases and peak trading
- Agree stop conditions and emergency contacts — service degradation, signs of a genuine earlier compromise, or a critical finding that needs reporting at once
- Check hosting and cloud provider rules — shown when a target is hosted by a third party; file any approval or form submitted
- Decide who is told — brief the SOC or MSSP, or leave them unaware to test detection, with a named person who can vouch for the tester’s source addresses
- Provision test accounts with an expiry date — least privilege, disabled automatically when the window closes
- Approve the authorisation letter — signed before any traffic is sent; the tester keeps a copy
Phase 3
Phase 3: During the Test
Assigned to an internal coordinator who can reach system owners quickly.
- Hold the kick-off call — confirm scope, contacts, windows and how critical findings will be reported
- Check in daily — service health, alerts raised and any access problems blocking the tester
- Act on critical findings reported mid-test — send them straight to the owning team rather than waiting for the report
- Record any pause, stop or scope change in writing — with who agreed it and why
- Confirm the end of testing — disable test accounts and remove tools and files the tester left behind
Phase 4
Phase 4: Report Triage
- Review the draft report with the tester — correct factual errors and missing context before it is issued as final
- Validate every finding — confirm it, or record a false positive with the evidence
- Re-rate severity for your environment — exposure, data at risk and compensating controls
- Assign an owner and a due date to each finding — logged in the same tracker as scanner findings
- Decide whether a retest is required — yes for any finding rated high or critical, or where an auditor or customer expects proof
Phase 5
Phase 5: Remediate & Retest
Retest tasks appear only when a retest is required. The segmentation task appears only when segmentation was in scope.
- Fix findings in priority order — tracked against each due date, with fixes going through change control
- Record accepted risks with approval — reason, compensating control and expiry, approved by the risk owner
- Book the retest — ideally with the same tester, limited to the original findings
- Confirm the retest results — an updated report or retest letter showing the status of each finding
- Confirm segmentation still isolates the restricted environment — any failure is treated as a critical finding
Phase 6
Phase 6: Close & Evidence
Signed off by the head of security once every finding is fixed, retested or formally accepted.
- File the evidence pack — scope, authorisation, final report, retest letter and remediation records kept together
- Write the auditor summary — test dates, scope, tester, findings by severity and the status of each
- Review what detection saw — did monitoring spot the test, and what should the SOC tune as a result?
- Set the next test date — within 12 months, brought forward if a major release or migration is coming
- Approve and close the engagement — the sign-off records who closed it and when
What PCI DSS, SOC 2, ISO 27001 and CIS Expect From a Pen Test
PCI DSS is the only common framework that sets a hard penetration testing schedule. SOC 2 and ISO 27001 treat testing as strong evidence rather than a named obligation, and auditors routinely ask for it. Versions used: PCI DSS v4.0.1, SOC 2’s 2017 Trust Services Criteria (2022 points of focus), ISO/IEC 27001:2022 and CIS Controls v8.1. Adapt it to your own obligations; it is not legal or audit advice.
| Framework | Control | What it expects | Evidenced in |
|---|---|---|---|
| PCI DSS v4.0.1 | 11.4.1 | A documented methodology covering the CDE perimeter and critical systems from inside and outside, with results and remediation kept for at least 12 months | Phases 1 and 6 |
| PCI DSS v4.0.1 | 11.4.2 and 11.4.3 | Internal and external tests at least once every 12 months and after significant change, by a qualified tester with organisational independence | Phases 1 and 6 |
| PCI DSS v4.0.1 | 11.4.4 | Exploitable findings corrected in line with the 6.3.1 risk ranking, with testing repeated to verify | Phases 4–5 |
| PCI DSS v4.0.1 | 11.4.5 (11.4.6 for service providers) | Segmentation checked by penetration test annually and whenever segmentation changes; service providers every six months | Phase 5 |
| SOC 2 | CC4.1 | Ongoing and separate evaluations of controls; the points of focus name penetration testing as one type | Phase 6 |
| ISO/IEC 27001:2022 | A.8.8 and A.8.29 | Technical vulnerability management (ISO/IEC 27002 guidance includes penetration tests) and security testing in development and acceptance | Phases 1, 4 and 5 |
| CIS Controls v8.1 | Control 18 | A testing programme, external and internal tests no less than annually, remediation and validation of security measures | Phases 1, 5 and 6 |
For methodology, NIST SP 800-115, the Technical Guide to Information Security Testing and Assessment (September 2008), is still the current NIST publication and a common reference in statements of work. The PCI DSS 4.0 Compliance Checklist and the SOC 2 Readiness Checklist place the test within the wider framework programme.
Why Run Your Penetration Tests in CheckFlow?
Retests that actually get booked
Answer “yes” to the retest question and the booking and results tasks appear with owners and due dates. Mark segmentation as in scope and its check appears too. Tests that need neither stay short.
One evidence pack per engagement
Scope documents, the signed letter, reports and retest letters are attached to the tasks they relate to. If an auditor wants to see the previous engagement, you export one record instead of searching inboxes.
CheckFlow does not run penetration tests or replace your testing firm. It runs the preparation, decisions and sign-off around the engagement. If the test supports a SOC 2 report, the same recurring, evidenced approach can cover the rest of your control set with CheckFlow for SOC 2 compliance.
If a stop condition is triggered by signs of a real compromise, hand over to the Cybersecurity Incident Response Checklist. For the configuration side of your estate between tests, use the Network Security Audit Checklist and the Cloud Security Review Checklist.
A penetration test report is one input to the annual IT Security Audit Checklist. Findings fixed by a software update go through the Patch Management Checklist, and if a stop condition turns into a real incident, run the Incident Postmortem Template once it is closed.
Frequently Asked Questions
What should a penetration test checklist include?
It should cover three stages. Before the test: scope, exclusions, tester selection, rules of engagement, stop conditions and signed authorisation. During the test: a kick-off, daily contact and fast handling of critical findings. After the test: report review, validation, remediation with owners and deadlines, a retest where needed and a filed evidence pack. Most checklists only cover the testing itself, which is the part your supplier already manages.
How often do we need a penetration test?
PCI DSS v4.0.1 requires internal and external tests at least once every 12 months and after any significant infrastructure or application change, with segmentation tested every six months for service providers. CIS Controls v8.1 also asks for external and internal tests no less than annually. SOC 2 and ISO 27001 do not fix a frequency, but an annual test is what most auditors and enterprise customers expect to see.
Do we need permission from AWS, Azure or Google Cloud?
For standard testing of your own resources, generally no. AWS allows testing of its listed services without pre-approval, Azure dropped its pre-approval requirement in 2017, and Google Cloud says you do not need to contact it. Each provider still publishes rules you must follow, and AWS and Azure both prohibit denial-of-service testing. AWS requires approval for command-and-control testing and for simulated events such as red team exercises. Always check the current policy before the test starts.
Who should sign the authorisation letter?
Someone with genuine authority over every system in scope, typically the CISO, CIO or a director who owns the relevant services. The letter names the testing firm, the targets, the dates and the permitted techniques. Where a third party hosts or operates a target, you may need its written consent as well, because your authority does not extend to infrastructure you do not control.
Is a retest always required?
Not always, but PCI DSS 11.4.4 requires testing to be repeated to verify that exploitable vulnerabilities were corrected, and auditors elsewhere increasingly ask for the same proof. A sensible rule is to retest every high and critical finding. Lower-rated issues can often be verified internally with a rescan or configuration check, recorded against the finding.
Is CheckFlow free for this template?
14-day free trial, no card required. The Business plan is $10 per user per month after the trial. Full details at checkflow.io/pricing.