No Credit Card Required
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.
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.
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.
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.
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.
Owned by the security lead, starting six to eight weeks before the planned test window.
The authorisation is an approval step assigned to someone with authority over every in-scope system.
Assigned to an internal coordinator who can reach system owners quickly.
Retest tasks appear only when a retest is required. The segmentation task appears only when segmentation was in scope.
Signed off by the head of security once every finding is fixed, retested or formally accepted.
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.
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.
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.
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.
Describe the process in a sentence and the AI checklist generator drafts the phases and tasks for you.
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.
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.
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.
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.
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.
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.
14-day free trial, no credit cardFull refund in your first 30 daysUS hosting, EU on request
