Preparation guide

What should you prepare for a penetration test?

Have the request or business reason, the likely systems, the intended report recipient, and any deadline. That is enough to begin a useful conversation. The detailed scope, test accounts, access, restrictions, approvals, and evidence-handling plan can be developed during the engagement process.

Do not delay initial contact while trying to assemble every technical detail. Do not send passwords, keys, source code, vulnerability evidence, regulated records, production data, or other secrets through ordinary email or the request form.

Published by Trespass Security

Prepare in three stages

You need only a few details to start. The rest comes later.

Helpful before initial contact

Enough to understand your situation and identify the next questions.

The requirement or business reason
Who asked and how they are involved
Likely systems or products
Who expects to receive the report
Any stated deadline
Known restrictions or dependencies

Needed during scoping

Information used to define what can be tested and who is responsible.

System and environment inventory
Application modules, APIs, networks, and integrations
User roles, tenant models, and access paths
Third-party boundaries and ownership
Production and safety constraints
Report, communication, and retest expectations

Required before testing

The exact preparation depends on the approved scope.

Completed agreements, written authorization, and Rules of Engagement
Approved test accounts, access, allowlisting, or VPN setup
Primary and escalation contacts
Backups, monitoring, and internal change coordination
Third-party permissions
Confirmed restrictions, stop conditions, and data-handling controls

Choose the test environment

Decide whether the test will use production or a non-production environment.

Production shows current behavior and controls. A non-production environment may lower operational risk, but its configuration, data, integrations, or monitoring may differ.

Document important differences between environments.
Confirm whether the requester expects a particular environment to be tested.
List data-changing actions, fragile workflows, and prohibited activity.
Make stop conditions and escalation contacts easy to use.

Test access

Coverage depends on reaching the paths the scope says are included.

Account, role, tenant, and network-access problems can prevent meaningful testing. Validate access before the scheduled work and disclose paths that cannot be made available.

Access and accounts

Representative accounts for each authorized role and tenant context
Working authentication, recovery, federation, and administrative paths
API access and documentation where included
Allowlisting, VPN, bastion, or other network controls
Secure credential-transfer method agreed during the engagement
Sufficient test data and application states without unnecessary sensitive data

Internal coordination

Testing should not surprise the people responsible for the system.

Primary contact
Owns routine engagement questions and can coordinate system context or access.
Escalation contact
Can respond promptly to a material finding, instability, or stop condition.
Operations and monitoring
Know the authorized timing and how expected activity will be recognized without disabling useful controls.
Engineering
Can clarify intended behavior and later own remediation decisions.
Legal or system owners
Confirm permission where assets, providers, or data responsibilities cross organizational boundaries.

Schedule

Work backward from the customer or audit deadline.

Allow time for scoping, authorization, access setup, testing, reporting, remediation, and consolidated retesting.

Plan beyond the report date. Your team may need time to review the findings, fix them, and complete retesting.

Next step

Start with the context you already have.

Send who asked, what they said, which systems may be involved, and any deadline. The detailed preparation follows after the engagement is defined.

Get a pentest