How to prepare for a penetration test: a checklist

Preparation decides how much the tester can do in the time you pay for. Each hour the tester waits for an account or an answer is an hour not spent testing. Most of the work is simple: write the scope, create accounts, load test data, pick the environment and name contacts. The sections follow the order most teams work in.

What should you decide first?#

Decide what you want to learn. A pentest can serve a customer review, a launch gate, an audit, or a general check. The goal sets the scope, the depth and the report you need.

Then decide the test type. The choice between black, grey and white box changes what you must prepare. See black box, grey box and white box testing. For web app, API and SaaS tests, grey box (test accounts and documentation) lets the tester spend the agreed time on testing instead of discovery.

How do you define the scope?#

The scope is a written list of what the tester may test and what is off limits. List each item exactly: domains, subdomains, API base URLs, app versions and environments. Also list what is out of scope, such as third-party services, payment processors, other customers' systems and anything you do not own.

Write one line for each of these:

• Assets in scope (host names and URLs).
• Assets out of scope.
• Roles and tenants to test.
• Known issues the tester should skip.
• Special worries, such as "billing" or "file import".

A tester can only test what you list, and an asset missing from the list gives you false confidence in coverage. For the full authorization and scope structure, read penetration testing rules of engagement.

You also need written authorization from the system owner. If you do not own the system, for example a customer-hosted instance or a third-party platform, get permission from the owner. A client's permission does not always cover its hosting or software providers. Check each provider's testing policy.

What accounts does the tester need?#

Give the tester at least two accounts for every role, and put them in at least two separate tenants if your app is multi-tenant. One account cannot prove that user A can read user B's data.

A good set for a SaaS product:

Use strong, unique passwords. Share them through a secrets manager or an encrypted channel, not by plain email. If you use MFA, give the tester a way to pass it: a test seed, a bypass for test accounts, or a mailbox they can reach. Check that every account can sign in before the test starts.

What data should you load?#

Use test data only. Create records in each tenant so the tester has something to try to reach: notes, invoices, files, users. Mark them as test data, for example with a name prefix.

Do not load real customer data. If you must test production, use test-owned accounts and records. Destructive proofs should only touch records the tester created.

If your app sends emails, texts or calls paid APIs, say how many the tester may trigger. Tests of uploads, password guessing, email sending and paid third-party APIs should be bounded and their cost stated.

Which environment should you use?#

Choose staging if it matches production in code, configuration, integrations and roles. Choose production if staging differs in ways that matter, and apply stricter rules there.

Whichever you pick, freeze the environment (see the freeze window section).

What documents should you share?#

Share what helps the tester aim:

• An OpenAPI file, GraphQL schema, or Postman collection.
• A short description of main user flows and roles.
• A diagram of the main components and third-party services.
• A list of known issues and past findings.
• For white box tests: a code archive or repository access, and who to ask.

You do not need a polished document. A rough note is fine. For APIs, a collection that works end to end saves the most time. See API penetration testing for what we ask for.

How do you handle allowlists and security tools?#

Decide whether to allowlist the tester's source IPs in your WAF, rate limiter and bot protection. Two common choices:

1. Allowlist: the tester spends time on the app, not on the WAF. You may miss flaws that the WAF would hide anyway.
2. No allowlist: the test shows how the WAF behaves. The tester may be blocked and lose time.

A common pattern is to allowlist for the main test and then run a short extra check without it. Write the choice in the scope.

Tell your security team and any managed monitoring provider about the test window, the source IPs and the contact. This prevents a false incident. Check your cloud and hosting providers' penetration testing policies, and send notice if they ask.

Who are your contacts?#

Name two people who can answer questions during the test: a technical contact and a backup. Add an escalation contact who can stop the test, and give phone numbers or a chat channel. If the tester finds a serious issue, they need someone to tell right away. Agree how fast the tester reports a serious finding, and put that rule in the rules of engagement.

What is a freeze window and why use one?#

A freeze window is a period when you do not deploy changes to the tested environment. If code changes during the test, results may no longer match: the tester may report a flaw you already removed, or miss a new one.

Freeze changes to the in-scope environment for the test window. Allow emergency fixes, and tell the tester when they happen. Plan the freeze around your release calendar.

The preparation checklist#

Copy this list into your ticket system.

Scope and authorization#

• Goal of the test written down
• Assets in scope listed exactly
• Out-of-scope assets listed
• Written authorization from the system owner
• Hosting and cloud provider policies checked

Access#

• Accounts for each role and at least two tenants
• Credentials shared through a secure channel
• MFA path for test accounts
• Each account tested by sign-in before the start

Data and environment#

• Environment chosen and matches production
• Test data loaded and marked
• Limits set for emails, uploads and paid APIs
• Backups or a restore plan in place

Documents#

• API docs or collection
• Flow notes and architecture sketch
• Known issues list

People and time#

• Technical contact and backup named
• Escalation contact who can stop the test
• Security team and monitoring provider told
• Allowlist decision made
• Freeze window set

If you are preparing for a launch, read pre-launch security testing. To start a conversation about a scope, use the contact page.

Need a pentest you can act on?

Tell us what you need tested and why. We reply to agree scope, and testing starts only after written authorization.

Request a testSee the sample report