Process
How to prepare for a penetration test
Published Updated 5 min read
The short answer
To prepare for a penetration test, agree on what you want to learn, write down exactly which systems are in scope, give the testers working accounts and a safe environment, and name who to call if something breaks. Most of the value of a test is decided before it starts: a vague scope or a missing test account can waste days of paid testing time. The checklist below covers the decisions to make in the two to four weeks before kickoff.
Why does preparation change the outcome of a test?
A penetration test is time-boxed. Every hour the testers spend waiting for VPN access, chasing an expired password or asking whether a subdomain belongs to you is an hour not spent finding real weaknesses. Good preparation moves those questions to before the clock starts.
Preparation also protects you. A clear scope and written authorization keep testing pointed at systems you own or control, backups make an unexpected outage recoverable, and named contacts mean a real incident and a test can be told apart quickly.
What should you decide first: goals or scope?
Goals first, because they drive scope. "Find everything" is not a goal a fixed budget can meet. Useful goals are specific and tied to a decision you need to make:
- Can a logged-in customer see or change another customer's data?
- Could someone on the internet reach our admin panel, cloud console or source code?
- Do we meet the penetration testing requirement of a framework or a customer contract?
- Did last quarter's fixes actually close the issues found before?
Once goals are set, scope follows: the applications, APIs, IP ranges, cloud accounts and identity systems that answer those questions. Write down what is out of scope just as clearly, such as third-party payment pages, shared hosting you do not control, or production databases you cannot risk. The rules of engagement document is where both lists end up.
Penetration test preparation checklist
| Item | What to prepare | Why it matters |
|---|---|---|
| Goals | Two to five questions the test must answer | Keeps a fixed budget focused on the risks you care about |
| Scope | Exact URLs, API base paths, IP ranges, cloud account IDs, tenants | Testers only touch what you have authorized |
| Out of scope | Systems, techniques and data that must not be touched | Prevents surprises with third parties and fragile systems |
| Asset inventory | Owners, environments and tech stack for each in-scope asset | Speeds discovery and routes findings to the right team |
| Test accounts | At least two accounts per role, including two separate tenants or customers | Needed to test access control between users and tenants |
| Environment | Production or a staging copy that matches production | Findings in a stale staging build may not exist in production |
| Backups | Recent, restorable backups of in-scope data and configuration | Makes accidental data changes recoverable |
| Change freeze | Agreed limits on deploys to in-scope systems during the test | Stops moving targets and makes results reproducible |
| Provider policies | Current pentest policy of each cloud and hosting provider | Some activities are restricted or need a request first |
| Allowlisting decision | Whether tester IPs bypass the WAF, rate limits or bot protection | Decides whether you are testing the app or the perimeter control |
| Contacts | Technical lead, escalation contact and out-of-hours number on both sides | Lets either side stop or pause testing quickly |
| Timing | Start and end dates, testing hours, blackout dates | Avoids launches, peak trading and holidays |
What accounts and environments do testers need?
For anything behind a login, provide credentials. Some of the most damaging findings, such as broken access control and IDOR, only appear when a tester holds one account and tries to reach another account's data. That needs at least two users per role and, in a multi-tenant product, two separate tenants. This is why gray box testing is often the efficient choice.
- Create dedicated test accounts, never shared staff accounts, so activity is easy to tell apart in logs and easy to disable afterwards.
- Include each privilege level that matters: regular user, team admin, billing owner, support or internal staff roles if they are in scope.
- Seed realistic but synthetic data. Avoid real customer records in test tenants.
- If multi-factor authentication (MFA) is required, agree how testers will receive codes so it does not block them mid-test.
On environments: staging is safer, production is truer. A staging copy that lags production by months produces findings that may already be fixed, and misses ones that are new. Many teams test production for external and identity work and a current staging copy for destructive or high-volume application testing.
Do you need to tell your cloud provider before a penetration test?
It depends on the provider and the activity, and the policies change, so check the current version before each test. As of October 2026:
- Amazon Web Services (AWS) allows customers to test a published list of permitted services without prior approval. Denial of service and flooding are prohibited, and simulated events such as red team exercises or phishing simulations need a separate request submitted in advance.
- Microsoft Azure publishes Microsoft Cloud penetration testing rules of engagement. Testing must stay within your own tenant and assets, and denial of service testing is prohibited.
- Google Cloud states that customers do not need to contact Google before testing their own projects, but tests must follow the acceptable use policy and terms of service and must not affect other customers.
How should you handle backups, deploys and timing?
Professional testing is designed to avoid damage, but testing a form that sends emails or an API that writes records will create data. Confirm backups of in-scope data and configuration are recent and that a restore has actually been tried. A backup nobody has restored is an assumption, not a safety net.
Agree a light change freeze for in-scope systems. You do not need to stop shipping, but major releases or infrastructure migrations during a test make findings hard to reproduce. If a deploy must go out, tell the testers what changed.
Pick dates around your calendar: avoid product launches, peak sales periods, audits and holidays when the people who can approve a fix are away. Allow time after the test for remediation and a retest before any compliance or customer deadline.
Who needs to be involved?
- A technical owner who can answer questions about the systems and grant access quickly.
- An escalation contact with authority to pause testing or approve an urgent fix.
- Operations or on-call staff, so an alert during testing is checked against the test schedule before anyone panics.
- Fix owners for each in-scope area, so findings land with someone who can act on them.
Decide in advance what happens if testers find something critical mid-engagement, such as exposed customer data. Most teams want an immediate call rather than waiting for the final report. Knowing how to read the report when it arrives is the last piece of preparation.
How Brexa approaches this
Brexa does not test anything without a signed scope and rules of engagement, and the Discover stage of its method starts by mapping what an attacker can see so the scope reflects reality. Every action during testing is recorded, and findings in the client portal are routed to the owner of each fix.
Frequently asked questions
How far in advance should we start preparing for a penetration test?
Two to four weeks is typical. That leaves time to agree scope, create accounts, check provider policies and line up contacts without rushing.
Should we fix known issues before the penetration test?
Fix what you already know about if you can, because paying testers to rediscover known issues wastes budget. If you cannot, tell the testers so they can confirm and move on.
Should we allowlist the testers' IP addresses?
It depends on the goal. Allowlisting lets testers reach the application itself instead of spending time on the web application firewall, while leaving protections on shows how the perimeter holds up. Many tests do both in separate phases.
Do we need to tell our employees about the test?
Tell the people who need to know, such as on-call staff and fix owners. If the goal is to test detection and response, a small group may be told while others are not, which should be written into the rules of engagement.
Sources
Written and reviewed by the Brexa team. Educational information, not legal or compliance advice. See our editorial policy.
Keep reading
Find out what an attacker could do with your systems.
Book a short scoping call. Nothing is tested until scope and rules of engagement are signed, and every finding comes with proof.