Penetration Testing Checklist: What to Confirm Before You Start

The most common reason a penetration test produces disappointing results is not inadequate testing. It is an inadequate setup. Scope gaps discovered after testing begins, missing credentials that prevent authenticated surface testing, unclear escalation contacts that delay decisions when something unexpected occurs, and legal authorisation that does not cover all the systems that should be tested, these are pre-engagement failures that produce post-engagement regret.

Most penetration testing checklists are written for the tester: OWASP test cases, methodology phases, exploitation techniques. This checklist is written for the buyer. It covers everything to confirm, prepare, and communicate before a single payload is fired, because getting these items right determines whether the engagement produces security improvement or a compliance artifact.

Section 1: Scope confirmation

The scope defines the boundary of the engagement. Everything inside scope is tested. Everything outside scope is untested and therefore carries an unknown risk profile at the end of the engagement. Scope gaps are the most consequential pre-engagement failure.

Checklist items:

• All systems to be tested are explicitly listed by URL, IP range, or system name: no ambiguous "and associated infrastructure" language
• All user roles to be tested are listed with at least one set of credentials for each role
• All APIs to be tested are included, including undocumented internal APIs if they handle sensitive data
• Third-party integrations that process sensitive data are either in scope or explicitly excluded with documented rationale
• Mobile applications are scoped as a separate engagement or explicitly included
• Cloud infrastructure is in scope if it hosts in-scope applications
• Staging versus production is clearly specified: most engagements test staging to avoid production disruption, but confirm which environment reflects the actual production configuration
• Any systems that are off-limits are documented (legacy systems too fragile for active testing, third-party vendor systems outside your control, regulated infrastructure requiring separate authorization)

Why this matters: a web application with a public interface and an internal API that also handles customer data presents two distinct attack surfaces. Testing only the public interface and leaving the API out of scope produces a clean report on half the attack surface. What a real web application penetration test should cover maps the twelve dimensions that comprehensive scoping requires.

Section 2: Rules of engagement

Rules of engagement define what the tester is and is not permitted to do. They protect both the organisation and the tester, and they determine how realistic the assessment is.

Checklist items:

• Permitted testing techniques are specified (active exploitation, automated scanning, social engineering, physical intrusion)
• Social engineering is explicitly in or out of scope: ambiguity here has operational consequences
• Denial-of-service testing is addressed: most engagements exclude it from production environments
• Destructive testing is addressed: whether testers can delete, modify, or exfiltrate real data or only demonstrate that they could
• Testing hours are defined if there are windows when testing could affect production (some organisations restrict testing to off-hours)
• Source IP addresses of testing infrastructure are provided to the networking team if they need to avoid blocking testing traffic
• The "halt" procedure is defined: what happens if the tester discovers an active breach, a critical vulnerability with potential for significant damage, or a system that was not supposed to be in scope

Red team vs. penetration testing: what's the real difference covers how rules of engagement differ across testing types. A penetration test with explicit defined scope and documented rules differs significantly from a red team exercise, and the rules of engagement document should reflect which type of assessment is being conducted.

Section 3: Legal and contractual authorisation

Penetration testing without proper legal authorisation is a criminal offense in most jurisdictions. The Computer Fraud and Abuse Act (CFAA) in the US, the Computer Misuse Act in the UK, and equivalent legislation in other jurisdictions make unauthorised access to computer systems illegal, and "I was hired to do it" is not a defence without proper documentation.

Checklist items:

• A written authorisation document exists that specifies the scope and permits testing
• The authorisation is signed by someone with legal authority to grant it: not just the project manager who commissioned the engagement
• Third-party hosted systems are covered: if your application runs on AWS or a managed hosting provider, confirm that testing these systems complies with the provider's terms of service and that your own authorisation covers them
• Cloud provider testing policies are confirmed: AWS, Azure, and GCP have specific policies about penetration testing. Most are permissive for customer-hosted systems but have specific notification or approval requirements
• Non-disclosure agreements are in place covering the tester's access to your systems and data
• Data handling procedures are confirmed: what happens to any data (credentials, customer records, session tokens) that the tester accesses during testing
• The engagement agreement specifies what happens if testing discovers evidence of a prior breach or active attacker

Section 4: Credential and access provisioning

Authentication testing requires test accounts. Authorization testing requires multiple test accounts at different privilege levels. Without proper credential provisioning before testing starts, these test phases are either skipped or delayed while the tester waits for access.

Checklist items:

• Test accounts exist for each user role in scope: at minimum: standard user, privileged user, administrator (if testing admin surfaces)
• Test accounts have realistic permissions, not artificially elevated ones: the goal is to test real authorization enforcement
• Test accounts are confirmed to work before testing starts: nothing wastes engagement time like discovering on day one that test credentials are broken
• MFA is handled: if the application uses multi-factor authentication, there is either a test account with MFA configured and accessible, or MFA bypass is documented in the rules of engagement for testing purposes
• API authentication tokens or API keys are provisioned if API testing is in scope
• VPN or network access credentials are provisioned if internal network testing is in scope
• Environment-specific configuration (staging API endpoints, test environment URLs) is documented

Section 5: Technical access and infrastructure preparation

Some testing requires technical access beyond credentials. Internal network testing requires a foothold inside the network. Certain testing configurations require firewall rule modifications or monitoring exceptions.

Checklist items:

• VPN access is provisioned for internal network testing (or alternative access method is agreed)
• Network monitoring teams are briefed: decide whether they should be told testing is occurring (which allows them to review whether they detect it) or kept unaware (which tests real detection capability, closer to a red team model)
• Web Application Firewall (WAF) handling is agreed: some engagements whitelist the tester's IP to bypass the WAF (testing the application directly), others leave the WAF in place (testing through the WAF as an attacker would)
• DDoS protection bypassing is addressed: services like Cloudflare rate-limit aggressive scanning; confirm whether to whitelist testing IPs or accept scanning rate limits
• Monitoring and SIEM alerting is addressed: will testing traffic be flagged, blocked, and investigated? Does the security team need to know to avoid disrupting the engagement?
• Source code access is provisioned if white-box testing is in scope

Section 6: Communication and escalation contacts

During an engagement, situations arise that require real-time decisions: discovering a critical vulnerability that warrants immediate notification, accidentally disrupting a system, finding evidence of a prior breach, or encountering a system that was not expected. Without pre-established contacts, these decisions get delayed or made incorrectly.

Checklist items:

• Primary technical contact on the client side is identified and reachable during testing hours
• Escalation contact is identified for decisions that exceed the primary contact's authority
• Emergency halt contact is identified: someone reachable 24/7 if testing must stop immediately
• Notification procedure is agreed for critical findings: does the tester notify immediately, batch findings, or only report at the end?
• Active breach protocol is agreed: what should the tester do if they discover evidence of a real attacker in the environment during testing?
• Reporting format and delivery method are agreed in advance

Section 7: Compliance and evidence requirements

If the penetration test will serve as compliance evidence (SOC 2, PCI DSS, ISO 27001, HIPAA, GDPR, MAS TRM), the engagement must be designed to produce the specific documentation those frameworks require.

Checklist items:

• Compliance framework requirements are communicated to the vendor before the engagement starts: not discovered when the report is delivered
• Report format matches what auditors expect: some frameworks have specific expectations about what the report must contain
• Testing methodology documentation is requested if the compliance framework requires it
• Tester independence is documented if the compliance framework requires external third-party testing
• Tester qualifications are documented if required (OSCP, CREST, relevant certifications)
• Remediation and retest procedures are confirmed if the compliance framework requires closure evidence

For specific compliance framework requirements: SOC 2 penetration testing: what auditors actually require and PCI DSS penetration testing requirements explained cover the evidence standards each framework expects.

Section 8: Budget and timeline confirmation

Scope creep and timeline slippage are the two most common causes of strained vendor relationships in penetration testing engagements.

Checklist items:

• Engagement duration is agreed and sufficient for the scope: a complex web application with extensive API surface and multiple user roles cannot be thoroughly tested in three days
• Report delivery timeline is agreed
• Retesting is included and the timeline for retesting after remediation is agreed
• Out-of-scope discovery procedure is agreed: what happens when the tester discovers adjacent systems that should be in scope but were not listed
• Additional testing cost is agreed in advance if scope increases
• Budget approval for any additional cost is identified

How much does penetration testing cost? covers realistic ranges for each engagement type, which helps confirm that the quoted timeline is realistic for the agreed scope.

Section 9: Post-engagement planning

The engagement does not end when the report is delivered. Confirming what happens after delivery before testing starts prevents the finding-that-never-gets-fixed pattern.

Checklist items:

• Remediation ownership is assigned: which team or individuals are responsible for addressing findings
• Remediation SLAs are defined: target timeline for critical, high, medium, and low findings
• Retest scheduling process is agreed: how are retest requests submitted and how quickly does confirmation arrive
• Compliance evidence packaging process is agreed: who compiles the report, remediation record, and retest confirmation into the auditor evidence package
• Next engagement is planned if continuous coverage is not in place: the gap between the current engagement and the next represents unvalidated changes in production

For organisations considering whether periodic engagements are adequate for their deployment cadence, continuous penetration testing and how it differs from annual pentests covers when continuous testing becomes the more appropriate model. Agentic pentesting and continuous security validation covers how continuous testing operates as the always-on security validation layer.

Pre-engagement checklist summary

Print or save this summary as the sign-off document before authorising testing to begin. Every item should be confirmed before the engagement start date.

Scope:

• All in-scope systems explicitly listed
• All user roles listed with credentials
• APIs in scope confirmed
• Out-of-scope systems documented

Rules of engagement:

• Permitted techniques defined
• Social engineering and DoS positions confirmed
• Halt procedure agreed

Legal:

• Written authorisation signed by authorised party
• Third-party and cloud provider policies confirmed
• NDA and data handling in place

Access:

• Test accounts for all roles provisioned and tested
• MFA handling agreed
• Network access provisioned

Infrastructure:

• Monitoring team briefed per agreed approach
• WAF and DDoS protection handling confirmed
• Testing IP addresses provided if needed

Contacts:

• Primary contact identified
• Escalation contact identified
• Emergency halt contact confirmed
• Notification procedure agreed

Compliance:

• Framework requirements communicated to vendor
• Tester qualifications documented

Post-engagement:

• Remediation ownership assigned
• Remediation SLAs defined
• Retest process agreed

For penetration testing services in the US or VAPT services where the vendor handles the pre-engagement setup process systematically, or PTaaS where continuous testing eliminates most of the per-engagement coordination overhead entirely, the 10x Pentest platform covers the delivery model. See pricing for engagement options or get in touch to discuss how the pre-engagement process works for your specific environment.

Frequently asked questions

Q1. What is a penetration testing checklist?

A penetration testing checklist covers the items that must be confirmed, prepared, and agreed before a penetration testing engagement starts. There are two distinct types: a tester's checklist covering methodology, test cases, and OWASP categories, which guides what a tester does during the engagement; and a buyer's checklist covering scope, legal authorisation, credential provisioning, rules of engagement, and post-engagement planning, which guides what the organisation commissioning the test must confirm before testing begins. This checklist is the second type. Most published penetration testing checklists are the first type.

Q2. What should be in a penetration testing scope document?

A penetration testing scope document should explicitly list every system to be tested (URLs, IP ranges, application names), every user role to be tested with confirmed credentials, APIs and integrations in scope, systems explicitly excluded from scope with reasons, the testing environment (staging or production), testing window restrictions, and rules of engagement covering permitted techniques, social engineering, denial-of-service, and escalation contacts. Vague scope language like "the web application and associated infrastructure" is not sufficient.

Q3. Do you need written authorisation for penetration testing?

Yes. Penetration testing without explicit written authorisation from someone with legal authority to grant it is a criminal offense under computer misuse legislation in most jurisdictions. Written authorisation should specify the scope, the authorised testing period, and the party granting authorisation. For cloud-hosted systems, additional authorisation from the cloud provider (or confirmation that your customer agreement covers testing) is also required.

Q4. Should your security team know a penetration test is happening?

It depends on what you are trying to learn. If the goal is comprehensive vulnerability discovery with maximum coverage, briefing the security team and disabling WAF rate-limiting for the tester's IP range produces the most thorough results. If the goal includes testing whether your security team would detect a real attack, keeping them unaware (closer to a red team model) produces more realistic detection capability evidence. Decide which objective is primary before the engagement starts and document the decision in the rules of engagement.

Q5. What should happen after a penetration test is complete?

After report delivery: share the executive summary with leadership and assign remediation ownership for each finding category. Distribute technical findings to the relevant engineering teams. Begin remediation in priority order (critical findings first). Schedule retesting for each finding as it is remediated rather than waiting for a full retest cycle. Compile the report, remediation record, and retest confirmations into the compliance evidence package if the engagement was compliance-driven. Plan the next engagement or move to a continuous testing model if your deployment cadence has outpaced the annual testing cycle.