Penetration Testing Checklist: What to Do Before, During and After the Test

A penetration testing checklist covers five phases: pre-engagement and scoping, reconnaissance and vulnerability analysis, exploitation, cleanup, and reporting with remediation. Before testing, your team signs off the scope and prepares test accounts and backups. After testing, it confirms cleanup and works through the report; a retest is available after fixes. Pentestica’s certified pentesters (OSCP, OSCE, CISSP) handle the testing in between, with critical findings reported during the test.

Use this penetration test checklist as a run sheet. Testing typically runs one to three weeks plus a few days for the report (see how long a penetration test takes).

1. Pre-engagement and scoping

Start with written authorization, an agreed scope and a testing window.

• Written authorization: Get sign-off from each in-scope system’s owner and agree the penetration testing rules of engagement in writing. PCI SSC guidance says testing “should only be conducted as defined by the rules of engagement agreed upon by both parties.”
• Scope: Agree targets and exclusions in writing; here’s what belongs in a penetration test scope. If the target is an API, the API pentest checklist lists what to prepare, from the specification to two accounts per role. Decide early whether testers start with nothing or with accounts; our guide to black box penetration testing compares black, grey and white box.
• Cloud accounts: AWS allows testing of permitted services without prior approval, and Microsoft hasn’t required Azure pre-approval since 2017. Both prohibit denial-of-service testing, and Microsoft’s rules of engagement limit testing to your own tenant or assets you’re explicitly authorized to test, so plan cloud penetration testing on AWS or Azure accordingly.
• Window and contacts: Agree dates, hours, production or staging, and take fresh backups. The NCSC says you “should ensure that a technical point of contact is available at all times” during testing; add an emergency contact. Agree what happens if testers find an existing compromise, a rules-of-engagement question PCI SSC lists.

2. Reconnaissance and vulnerability analysis

Testers map what’s exposed, then look for weaknesses. On your side of the pentest checklist, the job is working access: accounts, IP ranges and allowlisting.

• Attack surface mapping: Share domains and IP ranges for your internet-facing systems and decide on allowlisting tester IPs.
• Test accounts: Create one per user role and test it before day one. Under PCI SSC guidance, the organization “is strongly encouraged to supply credentials.”
• Vulnerability analysis: Web application and API testing is aligned with OWASP Top 10 and OWASP WSTG.

3. Exploitation and lateral movement

Testers exploit confirmed vulnerabilities and check how far access reaches.

• Lateral movement: For testing inside your network, provide a standard domain account as a foothold.
• Critical findings: Critical vulnerabilities are reported during the test, so keep your technical contact ready. Decide whether to tell your monitoring team, and pause major changes to in-scope systems.

4. Post-exploitation and cleanup

Afterwards, restore the pre-test state.

• Artifact removal: PCI SSC recommends removing accounts created for the assessment, and testing tools “should be removed at the end of the testing.”
• Access reset: Confirm test accounts are disabled, remove allowlisting and change passwords used during testing.

5. Reporting and remediation

This last phase of the pen test checklist turns findings into fixes.

• Executive summary: An overview of the main risks for management.
• Technical report: Vulnerabilities, exploitation evidence and step-by-step remediation for IT; see our sample penetration test report.
• Remediation plan: Fix findings by severity; keep the report as audit evidence for penetration testing requirements such as PCI DSS 11.4.
• Retest: A retest is available after fixes. PCI SSC guidance also says the tester “should perform a retest” to confirm new controls mitigate the original risk. Effort is quoted in tester-days with no hidden fees (penetration testing pricing).

Sources: PCI SSC Penetration Testing Guidance v1.1 (§2.2, §4.1.3, §4.2.1, §4.3.2, §4.3.3); NCSC Penetration testing; AWS Penetration Testing policy; Microsoft Learn: Azure penetration testing; Microsoft Cloud Penetration Testing Rules of Engagement.