How to prepare for your first penetration test

Most of the value in a penetration test is decided before testing starts. A well-scoped test with the right access finds the issues that matter. A rushed one spends half its budget on login problems and firewall blocks. Here is how to prepare for your first penetration test so the days you pay for go into actual testing.

Decide what question you are answering

“We need a pentest” is not a scope. Start with why:

• A customer or tender requires evidence of testing.
• You are launching a new product or major feature.
• You want assurance before a certification such as ISO 27001.
• Something changed: a new cloud environment, an acquisition, a new API.

The reason shapes the scope. A customer requirement might need an external infrastructure test and a web application test. A product launch needs deep application and API coverage.

Write down the scope precisely

List every target explicitly:

• Domains and subdomains, including staging if it is in scope.
• IP ranges, and who owns them. You can only authorise testing of systems you control or have permission to test, so check with hosting providers and SaaS vendors.
• Application roles to test, for example customer, admin and support.
• API documentation or an OpenAPI file, if you have one.
• Anything explicitly out of scope, such as payment providers or third-party widgets.

Choose the right environment

Testing production gives the most realistic results but carries more risk. Testing staging is safer but only useful if staging genuinely matches production. Whichever you choose:

• Take backups before the window.
• Make sure test data cannot trigger real emails, payments or SMS messages.
• Tell your hosting provider if their terms require it.

Prepare accounts and access

Create dedicated test accounts for each role, ideally two per role so horizontal access control can be tested (can user A see user B’s data?). If the test is grey box, share credentials securely, never over plain email.

If you use IP allow-lists, a WAF or rate limiting, decide in advance whether the tester should be allow-listed. Allow-listing tests the application itself; leaving controls on tests your defences. Both are valid, but mixing them unintentionally wastes time.

Agree the rules of engagement

A short document signed by both sides should cover:

• Testing dates, times and time zone.
• Tester source IP addresses.
• Emergency contacts on both sides, with phone numbers.
• What happens if a critical issue is found mid-test. Most teams want an immediate call, not a surprise in the final report.
• Whether denial-of-service or social engineering is permitted. It usually is not, unless explicitly requested.

Tell the right people

Your operations team, managed service provider and anyone watching alerts should know the test is happening. Otherwise the first finding is a panicked incident call. Equally, if you want to test detection and response, agree that with a small group in advance.

Plan for the report

Book time with your engineers for the week after the report arrives, and agree a retest window. Findings lose urgency quickly, and a retest gives you evidence that issues are fixed. We cover what a good report should look like in What a good penetration test report should contain.

A short checklist

1. Purpose of the test agreed.
2. Targets and exclusions listed.
3. Permission confirmed for every target.
4. Environment chosen, backups taken.
5. Test accounts created for each role.
6. Rules of engagement signed.
7. Internal teams informed.
8. Remediation and retest time booked.

Planning your first test? Talk to us and we will help you scope it before you commit to anything.