How to Prepare for Penetration Testing: Complete Checklist

The difference between a penetration test that uncovers a critical finding worth the entire engagement fee and one that produces a generic report full of scanner output often comes down to preparation. Our team at SubRosa has conducted hundreds of penetration testing engagements, and the organizations that prepare well consistently get 3-5x more actionable findings than those that don't.

This guide walks through exactly what to do in the 2-4 weeks before your pen test starts, so your team and your testing vendor are set up for maximum impact.

Why Preparation Matters More Than You Think

A typical penetration test runs 5-15 business days. That's a fixed window of highly skilled tester time, and every hour a tester spends waiting for credentials, tracking down the right contact, or figuring out what's in scope is an hour they aren't finding vulnerabilities.

We've seen engagements where poor preparation cost the client 20-30% of usable testing time. On a $25,000 engagement, that's $5,000-$7,500 worth of tester time wasted on logistics instead of exploitation. Proper preparation ensures every dollar goes toward actual security findings.

Pre-Engagement Checklist: 10 Steps

1. Define Your Scope Clearly

Scope is the foundation of every pen test. Ambiguous scope leads to misaligned expectations, undertested systems, and wasted budget. Before the kickoff call, document the exact external IPs, CIDR blocks, and domain names to be tested. Identify specific application URLs and whether you're testing production or staging environments. List any API endpoints. Be explicit about exclusions: third-party hosted systems, fragile production databases, or anything else that's off-limits. Decide which types of penetration testing you need (network, web app, wireless, social engineering, physical) and whether the engagement should be black box, gray box, or white box.

If you're doing this for compliance (PCI DSS, HIPAA, SOC 2), confirm with your auditor or QSA exactly what systems must be included. Scoping errors here can invalidate the entire engagement for compliance purposes.

2. Gather Documentation

The more context you give your testing team, the more efficiently they work. Pull together network diagrams showing subnets, VLANs, firewalls, and external connectivity. Compile an asset inventory of servers, applications, databases, and cloud resources in scope. Dig up any previous test reports from prior pen tests or vulnerability scans so the new team can compare. For web application tests, include technology stack details, authentication flows, and API documentation. If cloud testing is in scope, have AWS account IDs, Azure subscription info, or GCP project IDs ready.

Don't worry about making documentation perfect. Even rough network diagrams and partial inventories are significantly better than nothing.

3. Create Test Accounts

For gray box and white box testing, create dedicated accounts the testing team will use. Don't share actual employee credentials. Set up a standard user account with normal employee-level permissions so testers can attempt privilege escalation. Add an admin or elevated account for testing whether admin controls can be bypassed from lower privilege levels. If your application has multiple user roles (viewer, editor, admin, billing), create one of each so testers can check for horizontal and vertical privilege escalation. If MFA is required, set up tokens or temporary bypass codes for the test accounts in advance.

Label accounts clearly (e.g., "subrosa-test-user", "subrosa-test-admin") so your team can easily identify test activity in logs.

4. Set Up Remote Access

If the testing team is working remotely (common for internal network penetration testing), they'll need a way into your network. VPN access is the most common approach; provide credentials and client configuration before testing starts. Alternatively, set up a dedicated jump box VM on your network that the tester connects to via SSH or RDP. For wireless or physical testing, coordinate on-site logistics including office access, visitor badges, and workspace.

Test the access method before the engagement starts. VPN issues on day one are the most common cause of lost testing time.

5. Establish Emergency Contacts

Pen testing is controlled, but unexpected things happen: a tester may trigger an alert that requires immediate verification, a production system might become unresponsive, or a critical finding might require immediate client notification.

Designate at least two contacts available during testing hours. The primary technical contact should be someone who can quickly verify system status, reset accounts, or whitelist tester IPs if needed. The executive sponsor should be a decision-maker who can authorize scope changes or approve testing of sensitive systems discovered during the engagement.

Share mobile numbers, not just email. When a tester discovers a critical vulnerability at 4:30 PM and needs to know whether to continue exploiting or stop, you want a fast response.

6. Notify Relevant Teams

Decide who needs to know the test is happening and when. For standard pen tests, IT operations needs a heads-up so they don't panic when they see unusual network traffic or login attempts. Coordinate with your security operations / SOC team on whether they should treat tester activity as real (to measure detection capability) or whitelist it (to avoid alert fatigue). Help desk staff need to know so they don't lock tester accounts or block tester IPs in response to automated alerts. If you're testing cloud infrastructure, remember that some providers (AWS, Azure, GCP) require advance notification or authorization.

For red team assessments, only the "white team" (typically 2-3 senior stakeholders) should be informed. The entire point is testing whether your security operations detect the activity.

7. Define Rules of Engagement

The rules of engagement (ROE) document is the legal and operational foundation of the pen test. Agree on the testing window (business hours only, after hours, or 24/7) and specify denied techniques such as denial-of-service attacks, physical access, or social engineering unless explicitly in scope. Define data handling procedures for sensitive data encountered during testing: how it will be stored, reported, and destroyed. Set expectations for critical finding notification, typically within 24 hours, and establish stop conditions that would require testing to immediately halt.

8. Review Change Freeze Windows

Pen testing should happen against a stable environment. If your IT team pushes a major infrastructure change, deploys a new application version, or migrates a database during testing, the results may be invalidated or the tester may encounter issues that waste time.

Coordinate with your change management process to ensure no significant changes happen during the testing window. If changes are unavoidable, notify the testing team immediately so they can adjust.

9. Prepare Your Incident Response Process

A pen test is an excellent opportunity to stress-test your incident response procedures. Before testing begins, review your IR playbook and confirm contact lists are current. Decide whether the SOC will actively attempt to detect the tester (recommended for measuring detection capability) or stand down. Make sure your IR team knows the escalation path if they detect activity they believe is a real attack rather than the pen test. Establish a code word or verification process to distinguish pen test activity from actual incidents during the testing window.

10. Confirm Deliverables and Timeline

Before the first packet is sent, align with your testing vendor on expectations. Report delivery typically takes 5-10 business days after testing concludes, and should include an executive summary, technical findings, risk ratings, and remediation guidance. Confirm that a debrief meeting with your technical team is included in the engagement. Agree on the retest window (typically 30-90 days after the initial report) for validating your fixes. If you need a compliance attestation letter for auditors, confirm the format and content upfront so there are no surprises.

Day-of Logistics

On the first day of testing, make sure VPN access, test accounts, and jump boxes are tested and working. If you're whitelisting tester source IPs, verify those are in your allowlist. Have a dedicated communication channel ready, whether that's a Slack channel, Teams group, or email thread, for real-time questions between your team and the testers. If you want to measure detection capability, ensure your SOC is operating normally rather than on reduced staffing.

Expect the first 2-4 hours to involve setup, access validation, and initial reconnaissance. Findings typically start flowing by end of day one.

After the Test: What to Expect

Once testing concludes, the engagement isn't over. Your vendor compiles findings into a structured draft report over 5-10 business days, followed by a debrief call where testers walk your technical team through each finding, answer questions, and discuss remediation approaches. Your team then enters a remediation period (typically 30-90 days) focused on critical and high-severity issues first. The vendor retests to validate that critical fixes are properly implemented, then delivers a final report showing original findings plus remediation status, suitable for auditors and leadership.

A virtual CISO can help prioritize remediation and present findings to your board in business-risk terms rather than technical jargon.

Common Preparation Mistakes

After hundreds of engagements, these are the preparation failures we see most often. Scoping too narrow is the biggest: testing only external IPs while ignoring the web application that processes customer payments. Attackers don't limit themselves to one attack surface. No test accounts ready is the most common time killer, where the testing team arrives and spends day one requesting credentials. VPN issues are a close second, with remote internal testing blocked by a firewall rule nobody documented. We regularly see change freezes that weren't communicated, causing deployments during testing that create false positives and crashes. And the SOC blocking the tester, because help desk locked accounts or the firewall team blocked IPs, is entirely preventable with a single notification email.

Every one of these failures is avoidable with the checklist above.

Key Takeaways

Proper preparation can increase the value of your pen test by 3-5x by maximizing actual testing time. Allow 2-4 weeks between contract signing and testing start date for documentation gathering and coordination. The three most critical items: clear scope definition, working access and credentials, and designated emergency contacts. Coordinate with IT ops, SOC, help desk, and cloud providers before testing begins, and plan for the full engagement lifecycle from preparation through retesting. Understanding why penetration testing is important helps get stakeholder buy-in for the preparation effort required.

Need help scoping and preparing for your next pen test? SubRosa's team handles the preparation logistics, provides clear documentation templates, and ensures your engagement delivers maximum value from day one.