Preparing for a penetration test: what to get ready and what to hand the tester

Before you write an inquiry and choose a vendor for the test, it pays to settle three things: what is in scope and what is not, what you want the test to check, and how much the tester gets to know up front. These three drive the price and the duration, and they are harder to change once the engagement is running. The term itself, that is what a penetration test is and how it runs, belongs in the glossary.

The scope is the list of what gets tested, and its opposite matters just as much: what is off-limits. Name the domains, IP ranges, and applications that belong in the test, and separately the ones nobody may touch, typically third-party systems or production that can’t take an outage. The goal of the test is the second decision: one application checked before it goes live, or a picture of how far an attacker gets from an ordinary workstation.

The third decision is how much the tester knows in advance: from nothing, through accounts and documentation, up to access to the source code. The difference changes how much time goes into reconnaissance and how much into finding flaws, and the glossary entry on how much knowledge to give the tester (black, gray, white box) works through it. What the test itself involves is on the penetration testing page.

This is where delay starts most easily. Prepare access before the start, not on the first day: until the tester has an account or connectivity, there is nothing to test and the time goes into waiting. Five things, specifically:

• A test account for every user role the application knows. The biggest findings sit between roles, so an ordinary user account on its own isn’t enough.
• Connectivity into the environment: a VPN or dedicated access to the internal network for an internal test, and for an external one only confirmation of which addresses are yours.
• Allowlisting of the tester’s source IP addresses wherever a firewall or rate limiting would otherwise block them and the test would measure only how well we get around the protection.
• Agreed exceptions in the web application firewall (WAF) or in endpoint detection and response (EDR), depending on the scenario, so the time doesn’t go into bypassing a filter instead of finding flaws in the application.
• A contact who can fix an account or access quickly when it stops working during the test.

Whether the exceptions in the WAF and EDR get made depends on what you want to measure. A section below covers it separately.

Two documents are non-negotiable: written authorization to test from someone who can give it, and an NDA. Without the authorization there is no start, because it would be unauthorized access, not a test. The rest are rules of engagement, agreed in advance so nobody has to improvise during the test.

• Contact people on both sides, reachable for the whole duration of the test, not just during business hours.
• The time window: when testing is allowed and when it is not, especially for systems that can’t take load during operations.
• The escalation path: whom we call and how fast when we find an actively exploitable way in or when something breaks.
• Rules for risky techniques: what is off-limits entirely, what we call about before running it, and whether social engineering is in scope.

For a web application or an API, most of the preparation is accounts and data. Prepare an account for every role, test data close to production, and a short description of the business logic, meaning what the application is for and what must not be possible in it. Preparation for a web application test sums it up in more detail.

For internal infrastructure and Active Directory (AD), it comes down to access and scope. The tester needs a way into the network, an ordinary domain account as a starting point, and a list of the IP ranges in play. What such a test checks is described under preparation for an internal network test.

For the cloud, specifically AWS, prepare read-only access to the account, a list of the services to be checked, and consent to the provider’s rules for testing. AWS has its own list of what may be tested without approval, and we describe what testing in AWS involves on the service page itself.

For Wi-Fi, what matters is access to the site and the extent of the wireless network. The tester has to be within range of the signal, on site or connected from nearby, so prepare access to the site, a list of the SSIDs in scope, a contact who knows the network, and a window in which we may briefly disrupt operations with deauthentication. More on what to get ready before a wireless network test is on the Wi-Fi test page.

For a mobile application, the build and the test accounts are what count. Prepare the installation package, an APK for Android and an IPA for iOS, or access to a test version, an account for every role, and a short description of the features. If the app has a backend of its own, say which servers may be touched. The full list, that is what to have ready for a mobile application test, is part of the service description.

For industrial control systems (OT/ICS), the two things that matter most are cooperation from the operations team and a safe window. Prepare a network diagram with the split into zones, a list of the main devices and protocols, a contact for the technician responsible for operations, reachable for the whole test, and an agreed maintenance window for active steps. The details, including what to get ready before a test of an OT environment, are on the OT and ICS test page.

Four things take most of the value out of a test: an undisclosed system outside the scope, a change of environment in the middle of the test, a missing retest in the brief, and testing in production without a backup. Each of those four either delays the start or makes the result invalid.

The trap with an undisclosed system is that the attacker finds it and the test doesn’t. When a subdomain or an application nobody knew about is missing from the scope, it stays untested even though it is reachable from outside. A change of environment during the test, meaning a new version deployed mid-work, devalues what has already been done. And without an agreed retest, that is a repeat check that the findings really are fixed, you document only what was broken, not what has been repaired.

Testing in production isn’t forbidden, but it comes with a backup and a window outside peak hours. The question of production versus a test environment, that is whether to test live or in staging and what that choice changes, is covered on the web application testing page. The pricing page sets out what drives the size of the engagement.

Before the start, the tester needs five things: written authorization to test, a defined scope with what is in scope and what is not, access into the environment, a test account for every role, and a contact who can fix access quickly. With those, the test gets going on day one. Without them, everyone waits.

It depends on the type of test and on the number of roles and systems in scope. For a single application with two roles, it is a matter of a few accounts and access into the environment; for an internal network, setting up connectivity and a domain account gets added. What stretches the preparation most is a scope still being clarified after the start. The sooner it is clear what is in scope, the shorter the start.

It depends on what you want to measure. If the test is meant to check how well your defense works, the WAF and EDR stay on, because they are part of what is being assessed. If you mainly want the application itself checked, the tester’s source IP address can be allowlisted on the WAF so the time doesn’t go into bypassing the filter instead of finding flaws. The decision belongs in the rules of engagement and is made in advance, not when the test hits a block.

Only for an internal test. An external test of the perimeter works with what you have exposed to the internet, so a list of domains and IP addresses is enough and no network access is needed. An internal test starts from the inside, from the position of someone who is already on the network, so you prepare connectivity over VPN or dedicated access and an ordinary account as a starting point.