How to Prepare for a Penetration Test: A Practical Checklist (2026)

A well-prepared penetration test delivers significantly better results than one that starts with unclear scope and missing documentation. Whether this is your first pen test or your tenth, proper preparation ensures testers spend their time finding real vulnerabilities rather than troubleshooting access issues. Here is a practical checklist to follow.

Phase 1: Before You Engage a Provider

Identify what needs testing. Start by listing your critical assets: customer-facing web applications, internal networks, cloud infrastructure, APIs, and mobile apps. Prioritise based on business risk, compliance requirements, and how recently each asset was last tested.

Determine your compliance requirements. Different frameworks have specific testing requirements. PCI DSS mandates annual penetration testing and retesting after significant changes. ISO 27001 requires regular security assessments. SOC 2 expects evidence of ongoing security testing. Know what your auditors or regulators expect before scoping the engagement.

Set a realistic budget. Penetration testing costs vary widely based on scope and provider tier. A basic web application test might cost $4,000 to $10,000, while a comprehensive red team engagement can exceed $100,000. Having a budget range helps providers propose appropriate scopes.

Gather two to three quotes. Request proposals from providers with relevant accreditations and experience. Compare not just price, but methodology, tester qualifications, reporting approach, and whether retesting is included.

Phase 2: Scoping the Engagement

Good scoping is the most important step in the entire process. Clearly define what is in scope and what is out of scope. Be specific: list URLs, IP addresses, environments, and user roles. Ambiguity here leads to gaps in testing or unexpected costs.

Choose the right test type. Are you looking for a black box test (testers have no prior knowledge), grey box (testers have some information, like user credentials), or white box (testers have full access to source code and architecture documentation)? Grey box testing typically offers the best balance of realism and thoroughness for most organisations.

Define the testing window. When can testing occur? Are there blackout periods to avoid, such as peak trading times or scheduled maintenance? Will testing happen during business hours only, or can testers work evenings and weekends?

Set rules of engagement. Document what testers are and are not allowed to do. Can they attempt social engineering? Are denial-of-service tests permitted? Should they stop if they gain access to particularly sensitive data? Clear rules prevent misunderstandings.

Phase 3: Technical Preparation

Prepare test accounts. If you are doing grey box or white box testing, create dedicated test accounts at each privilege level (standard user, admin, etc.). Do not use real employee accounts. Document the credentials and have them ready for the testers.

Provide documentation. The more context testers have, the more efficiently they work. Useful documentation includes network diagrams, application architecture overviews, API documentation, a list of known technologies and frameworks, and details of any recent security changes.

Whitelist testing IPs. If your infrastructure uses IP-based blocking or rate limiting, get the testing provider's IP ranges in advance and whitelist them. This prevents the security infrastructure from blocking the test.

Notify your hosting provider or cloud provider. Some hosting providers and cloud platforms (particularly AWS) have specific policies about penetration testing. AWS requires notification for certain test types. Azure and GCP have their own policies. Ensure you have the necessary authorisation to avoid service disruptions.

Back up your systems. While professional testers are careful, it is good practice to ensure recent backups exist before testing begins. This is especially important for production environment testing.

Phase 4: Stakeholder Communication

Inform your IT and security teams. They need to know testing is happening so they do not mistake test activity for a real attack and trigger incident response procedures unnecessarily. At the same time, if part of the test objective is to evaluate your detection and response capabilities, you may choose to inform only senior leadership.

Brief relevant management. Ensure the business understands what is happening, why, and what the potential outcomes are. Set expectations that the test will likely find vulnerabilities, and that this is the point.

Prepare your incident response team. If the pen test will include testing detection capabilities, brief your incident response team leader confidentially. Otherwise, simply let the SOC know that authorised testing is occurring.

Phase 5: During the Test

Designate a point of contact. One person on your side should be available to answer questions, provide access if needed, and make decisions about scope adjustments. Testers will sometimes need quick clarifications.

Monitor for issues. Keep an eye on system stability during the test. If testers accidentally cause service disruption, you want to catch it quickly. Most professional testers will flag any concerns immediately, but monitoring is still good practice.

Do not fix issues mid-test. If the provider flags a critical vulnerability partway through the engagement, resist the urge to patch it immediately. Wait until the test is complete to get the full picture. Patching mid-test can affect other test results.

Phase 6: After the Test

Review the report thoroughly. Schedule a debrief call with the testing team to walk through findings. Good providers will explain findings in context and answer questions. Ensure your technical team understands each vulnerability and the proposed remediation.

Prioritise remediation. Not every finding needs immediate action. Focus on critical and high-severity issues first, particularly those that are exploitable and provide access to sensitive data. Create a remediation plan with clear ownership and deadlines.

Schedule retesting. Once you have remediated the key findings, arrange a retest to verify the fixes are effective. Many providers include a retest window in their original engagement, so check your contract.

Document lessons learned. What did the test reveal about your security posture? Are there systemic issues (like insecure coding practices or misconfigured defaults) that need process-level fixes rather than point fixes?

Browse our provider directory to find accredited penetration testing companies, or read our guide on what to look for when choosing a provider.