How to Prepare for a Penetration Test

Effective penetration testing requires planning. Preparing your organisation, systems and people before the assessment ensures that testers can focus on uncovering meaningful vulnerabilities rather than spending time on avoidable missteps. This guide summarises best practices drawn from industry standards and professional testing firms.

1. Understand your environment

Before the engagement, compile an accurate inventory of your systems. Schellman recommends ensuring you know your internet‑facing hosts, internal assets and cloud resources. Penetration testers will perform reconnaissance, but they cannot discover every hidden asset. Providing a clear scope helps them prioritise effectively.

• Create up‑to‑date network diagrams showing all segments and connections.
• Identify critical systems, business applications and any cardholder data environment (CDE) or other sensitive areas.
• Include cloud services and software as a service (SaaS) platforms. For third‑party hosted environments, verify whether you need approval from the provider before testing.

2. Conduct vulnerability scans and remediate low‑hanging fruit

Running your own vulnerability scans before the test helps you fix obvious issues and allows testers to spend time on deeper flaws. Schellman advises using commercial vulnerability scanners with all plugins enabled and performing authenticated scans on internal networks. For web applications, automated scanners may struggle with business logic, but they still provide useful coverage. Addressing easy fixes (e.g., missing patches, default credentials) before the pentest improves the value of the engagement.

3. Define the scope and gather documentation

Scope determines what the testers are authorised to attack. The PCI guidance states that the organisation being assessed is responsible for defining the CDE and any critical systems. Work with the tester (and your assessor, if applicable) to ensure nothing is overlooked. Provide documentation such as:

• Network diagrams for all in‑scope segments.
• Data flow diagrams showing how cardholder or sensitive data moves through the environment.
• Lists of expected services and ports exposed at the CDE perimeter.
• Details of how authorised users access the CDE and which network segments are isolated.

This information helps testers identify unexpected attack vectors and confirm segmentation is effective.

4. Establish rules of engagement

Document and agree the conditions under which testing will be performed. PCI guidance recommends agreeing on rules of engagement that cover topics such as testing windows, communication channels and how sensitive data should be handled. Consider:

• When testing should occur (e.g., outside business hours or during maintenance windows).
• How testers should communicate findings during the engagement.
• Whether legacy systems require special handling because of known issues with automated scanning.
• Which security controls (e.g., intrusion detection systems) should be disabled or tuned to avoid interfering with testing.
• How compromised credentials or sensitive data discovered during the test will be handled.
• What steps testers and incident responders should take if they detect evidence of a real compromise.

Agreeing these details reduces uncertainty and prevents accidental disruption or misinterpretation of test results.

5. Prepare test environments for web applications

When your test includes web applications, provide a dedicated test environment that mirrors production. Populate it with representative data and ensure it is fully operational before the engagement begins. This allows testers to conduct a thorough assessment without affecting real customers or sensitive data.

6. Communicate and schedule internally

Inform relevant teams (IT operations, security operations, help desk and management) about the upcoming test. Schellman notes that effective communication ensures the test is scheduled to avoid change freezes or critical releases. Alerting your SOC prevents unnecessary incident response activity and ensures that testers are not blocked by well‑intentioned defenders.

7. Plan ahead and allocate sufficient time

Do not leave penetration testing to the last minute. Schellman advises starting discussions with testing firms at least three months before you need the final report. A typical authenticated web application assessment can take two weeks, and report finalisation may take another week. Contract negotiation and legal review can also introduce delays. Early planning avoids rush fees and scheduling conflicts.

8. Define success criteria and test boundaries

Agree on what constitutes a successful test. PCI guidance suggests documenting the point at which testers should stop—for example, when they have demonstrated unauthorised access to restricted data or compromised an intermediary device. Clear success criteria prevent testers from exceeding agreed boundaries and help you measure the test's effectiveness.

9. After the test: review and remediate

Preparation does not end when the test starts. Ensure you allocate time and resources to review the findings, remediate vulnerabilities and verify fixes. Testing is only effective if it leads to measurable improvements in your security posture.

Frequently asked questions

Should we tell our IT team when the test is happening?
For internal penetration tests, yes. Coordinating with IT ensures the test does not conflict with change freezes or maintenance windows and prevents security controls from blocking the testers. However, consider keeping test dates secret for social engineering exercises to assess user awareness.

Do we need to disable security controls?
Not necessarily. Agree with the testers which controls should remain active. In some cases, you may disable automated blocking to allow the test to proceed, but monitoring controls should remain to capture events. Document this in the rules of engagement.

Can we include third‑party systems?
If part of your environment is hosted by a third party (e.g., a cloud provider), you may need written approval before testing. Consult your service agreements and involve the provider early in the planning process.

How do we ensure sensitive data isn't exposed during testing?
Agree procedures for handling sensitive data. For example, testers may redact passwords from reports or provide proof‑of‑concept examples without disclosing full data sets. Use test accounts and anonymised data in web application environments.

Preparing thoroughly helps penetration testers focus on uncovering genuine weaknesses, saving time and money and ultimately strengthening your security posture.