How to Prepare for a Penetration Test: Complete Checklist

You have ordered a penetration test — excellent decision. But what actually needs to be in place on your side before testing begins? Good preparation is the difference between a test that uncovers real vulnerabilities and one that spends most of its time mapping the environment.

In this guide, we walk through everything you should have ready, from the absolutely essential to what makes the test extra valuable. Use it as a checklist in the weeks before the engagement starts.

The most important thing you need is a test environment. Penetration testing should never be conducted directly against production. The test environment should mirror the production environment as closely as possible — same codebase, same configurations, same integrations. The only differences should be that test data is used instead of real customer data, and that the environment is isolated so testing does not affect real users.

Why is this so important? Penetration testing involves active testing that can affect performance, trigger security locks or in the worst case cause downtime. In an isolated test environment, testers can work freely without worrying about consequences for actual users or data.

If you do not have a dedicated test environment, speak to us about it early. We can help you define the minimum requirements for an adequate test environment based on your infrastructure.

You need a technical contact person who is available during the test period. This person does not need to be on standby constantly, but should be able to answer questions within a reasonable time — preferably the same day. Typical things testers may need help with include resetting test accounts that have been locked, clarifying whether a feature is intentional or a bug, and access to logs to verify findings.

Ideally, the contact person should have good knowledge of the application's architecture and business logic. A developer or technical lead is often best suited.

For authenticated testing — which is the most common type — testers need test credentials with different roles. If your application has, for example, regular users, administrators and super-administrators, test accounts should be created for each role. This allows testers to verify that access controls actually work and that a regular user cannot escalate their privileges.

Create dedicated test accounts for the penetration test — do not reuse existing accounts. Use test data, not real personal information. Ensure the accounts have access to all features that the relevant role normally has access to.

It is important to define a clear scope together with the provider. What should be tested, and equally important — what should not be tested? The scope should include which applications and URLs are included, which features and modules should be focused on, whether third-party integrations are included or excluded, and whether there are features that are particularly critical.

A well-defined scope protects both parties. Testers know exactly what to focus on, and you avoid surprises.

The testing window — the period during which testing will be conducted — must be agreed and communicated internally. Ensure that relevant teams know that testing is taking place. IT operations should know so they do not block test traffic or interpret it as an attack. The development team should avoid pushing major changes to the test environment during the test period, as this can affect results.

Review the logging in the test environment. Testers may need access to application logs, web server logs or WAF logs to verify findings. Ensure that relevant logging is enabled and that logs are accessible to the contact person.

Documentation makes the test more efficient. You do not need to deliver a complete architecture description, but the following is useful: a high-level description of the application and its purpose, information about the technology stack (framework, database, authentication mechanism), API documentation if APIs are part of the scope, and any known limitations or areas you are particularly concerned about.

At Awareness Security, we always start with a structured onboarding through our Human-in-Control process. In Gate 0, we define the scope together, you sign authorisation digitally, and the testing window is approved. This ensures everything is in place and both parties agree on the framework before a single test is run.

Something many forget is to clarify legal and contractual matters. Ensure you have authorisation to test. If the application hosts data for other organisations, or if it runs on a third-party platform, permission from multiple parties may be required. Clarify this well in advance.

Check whether your organisation has insurance that covers security testing, and that the provider has professional liability insurance. At Awareness Security, we carry professional liability insurance and take full responsibility for any damage during authorised testing.

Here is a quick checklist you can use:

Essential: Test environment separate from production. Test credentials with relevant roles. Clearly defined scope. Agreed testing window. Technical contact person. Signed authorisation.

Recommended: API documentation. High-level architecture description. Enabled logging in the test environment. Internal communication to IT operations and development team. Clarified legal matters.

Nice-to-have: Known areas of concern or recent changes. Previous test reports. Information about security headers and WAF configuration.

With good preparation, you ensure testers spend their time finding real vulnerabilities — not waiting for credentials or troubleshooting the test environment. This gives you a better report, more value for money, and concrete actions you can act on.

Ready to get started? Get in touch with us for a no-obligation conversation about your needs, and we will guide you through the entire process.