Your first penetration test can feel like a leap into the unknown. You’re inviting outsiders to attack your systems, and you’re not sure what they’ll need, what they’ll find or how disruptive it will be.
The good news is that most of what makes a test go well is preparation, and preparation is in your hands. Teams that arrive at kickoff with a clear scope, working accounts and a named contact get far more out of the same number of test days than teams that spend the first morning chasing passwords.
This guide walks through what to prepare, in roughly the order you’ll need it. It applies whether you’re testing a web app, an API, a mobile app or your network.
Start with why you’re testing
Before you think about URLs and accounts, be clear about the reason for the test. The reason shapes almost every other decision.
Common drivers include:
- An audit, such as SOC 2 or ISO 27001, where the report becomes evidence
- A customer security review, where an enterprise buyer asks for a recent pentest
- A major release, such as a new product, a rebuilt authentication system or a move to new infrastructure
- Peace of mind, when you simply want to know where you stand
Each driver changes what a good outcome looks like. An auditor will care about scope, dates, methodology and retest status. A customer will want a summary they can read in five minutes. Your engineers will want reproduction steps and clear fixes.
Write down the driver in one or two sentences and share it with your testing provider. It helps them recommend the right scope and shape the report for the people who will read it.
Define the scope
Scope is the list of what the testers are allowed to test, and what they are not. A clear scope protects your users, your business and the testers, and it makes the report meaningful.
What to list
For each system in scope, gather:
- Web applications: the URLs, the main features and the user roles
- APIs: the base URLs, documentation or a Postman/OpenAPI collection, and how authentication works
- Mobile apps: the platforms (iOS, Android or both), the app builds and the backend APIs they call
- Networks: IP addresses or ranges, hostnames and any network segments that matter
- Cloud: the accounts, subscriptions or projects in scope, and which services they use
What to exclude
Be just as explicit about what is out of scope:
- Third-party services you don’t control, such as payment providers or email platforms
- Features or environments that are being retired
- Anything fragile that could be affected by testing, unless you’ve agreed how to handle it
If you’re unsure whether something should be included, raise it during scoping. It’s far better to settle it up front than to discover a grey area halfway through testing.
Think about user roles
For most applications, the riskiest flaws involve one user reaching data or actions that belong to someone else. To test this properly, the testers need to understand your roles and how they relate.
Make a simple list of roles, such as admin, manager, member and read-only, and note what each should and shouldn’t be able to do. If your product serves multiple customer organisations, note how tenants are separated. This list alone often saves hours of testing time.
Prepare test accounts
Test accounts are the single most important thing to have ready. Without them, testers can only see what an anonymous visitor sees, and most serious issues sit behind the login.
Prepare:
- One account per role, so testers can compare what each role can do
- Two separate tenants or organisations, if your product is multi-tenant, so cross-tenant access can be tested
- Realistic sample data in each account, such as projects, invoices or records, so features behave as they would for real users
- MFA arrangements, such as test numbers, authenticator setup or a temporary exception, agreed in advance
Check that every account works before kickoff. Log in as each role and try a few key actions. Broken or locked accounts on day one are a common and avoidable delay.
Choose and prepare the environment
You’ll need to decide where testing happens. There are two main options.
A production-like staging environment is usually the best choice. Testers can try more aggressive techniques without risk to real users, and you can reset data if something breaks. It should run the same code and configuration as production, with realistic data.
Production is sometimes the only option, for example when staging is very different or doesn’t exist. Production testing is common and can be done safely, but it needs clearer rules of engagement and more care around anything that changes data.
Whichever you choose:
- Make sure the environment is stable and won’t be redeployed or reset mid-test without warning
- Turn off anything that would block testing entirely, such as an IP allow-list, or add the testers’ source IPs to it
- Decide how your web application firewall or rate limiting should behave. Testing behind it shows real-world exposure. Allow-listing the testers shows what’s underneath. Both are valid, so choose deliberately.
- For internal network tests, arrange VPN access or a jump host, and confirm it works from the testers’ side
- For mobile tests, provide app builds (IPA and APK files) that run on test devices, ideally without debug restrictions that would block analysis
What to prepare for each type of test
Different tests need different things. Use this table as a starting point and confirm the details during scoping.
| Test type | What to have ready | Who to involve |
|---|---|---|
| Web application | URLs, accounts for each role, two tenants if multi-tenant, a short product walkthrough | Product owner, lead engineer |
| API | Base URLs, API docs or Postman/OpenAPI collection, API keys or tokens per role | Backend lead |
| Mobile app | iOS and/or Android builds, test accounts, backend API details | Mobile lead, backend lead |
| Internal network and AD | VPN or jump host, IP ranges, a standard domain user account for assumed-breach testing | IT or infrastructure lead |
| External network | IP addresses and hostnames, details of any hosting or CDN providers | Infrastructure lead |
| Cloud | Read-only audit role in each account, list of accounts and key services | Cloud or platform lead |
Paperwork and permissions
Before any testing starts, you’ll sign a few things. They exist to protect both sides, so don’t treat them as a formality.
- A non-disclosure agreement, so everything the testers see and find stays confidential
- A contract or statement of work, covering scope, timing and deliverables
- Written authorisation to test, signed by someone with the authority to approve it for every system in scope
Authorisation matters most when systems are hosted or owned by others. If part of your stack is run by a third party, check that you’re allowed to authorise testing of it, or exclude it.
You can read how this fits into the wider process on our how we work page.
Contacts and communication
During testing, questions come up. A login breaks, a feature behaves oddly, or the testers find something serious. Decide in advance who handles these.
Name at least:
- A technical contact, who can answer questions about the system and fix access issues quickly
- An escalation contact, who can make decisions if testing needs to pause or a critical issue is found
- A backup, in case either is unavailable during the testing window
Then agree how you’ll communicate:
- The channel, such as a shared chat channel or email thread, kept separate from customer-facing tools
- Critical findings, which should reach you immediately rather than waiting for the report
- Status updates, such as a short daily note or a check-in at the start and end of testing
- How to pause, so anyone on your side can ask the testers to stop at once if something looks wrong
Tell the people who need to know that testing is happening, such as on-call engineers and whoever watches your alerts. Otherwise testing traffic may be treated as a real attack, which wastes time on both sides.
Rules of engagement
Rules of engagement set out how testing will be done safely. Your provider should propose them, but you should review them carefully. They typically cover:
- Testing windows: the dates and hours when testing is allowed
- Source IPs: where testing traffic will come from, so you can recognise it
- Destructive or risky actions: what needs explicit approval first, such as anything that could delete data or affect availability
- Data handling: how evidence is stored and when it is deleted
- Stop conditions: when and how testing pauses
If there are busy periods, release freezes or fragile systems, say so now.
Plan for after the test
The report is not the finish line. Plan what happens next before testing begins.
- Book a walkthrough call so your engineers can ask questions about the findings
- Assign owners for fixing findings, ideally before the report arrives
- Reserve engineering time for fixes, especially for anything rated critical or high
- Schedule the retest once fixes are in place, so you have confirmation for auditors and customers
- Decide who receives what: the full report for engineers, the executive summary or attestation letter for customers and auditors
Your preparation checklist
Use this as a final check in the week before kickoff.
- The reason for the test is written down and shared
- Scope is agreed in writing, including what’s out of scope
- User roles are listed, with what each should and shouldn’t be able to do
- Test accounts exist for every role, and every one has been checked
- Sample data is in place in each account
- The environment is chosen, stable and reachable from the testers’ side
- VPN, jump host or allow-list access is arranged and tested, if needed
- API docs, collections or app builds are shared, if relevant
- NDA, contract and written authorisation are signed
- Technical, escalation and backup contacts are named
- A communication channel is set up and critical-finding alerts are agreed
- Internal teams who watch alerts know testing is happening
- Time for fixes and a retest is in the plan
Ready to start?
Preparation turns a pentest from a stressful week into a useful one. You get more coverage, fewer delays and a report that’s ready for the people who need it.
If you’re planning your first test, tell us what you need tested. We’ll help you shape the scope on a short call, and you’ll get a proposal with tester-days and timeline stated. If you want to see what you’ll receive at the end, you can also request our sample report.
Frequently asked questions
How far in advance should we start preparing?
Start two to four weeks before you want testing to begin. That leaves time to agree scope, sign the paperwork, create test accounts and arrange access without rushing. If an audit date is fixed, work back from it and leave room for fixes and a retest.
Do we need to tell our hosting or cloud provider?
Most major cloud providers no longer require advance notice for testing your own resources, but each has a policy on what is allowed. Some managed hosts and third-party services still expect notice or forbid certain tests. Check the terms for every provider in scope, and tell us about anything unusual during scoping.
Should we fix known issues before the test?
Yes, where you reasonably can. A pentest is most valuable when it finds what you don't already know. Fix the obvious items, and tell the testers about anything known but not yet fixed so they don't spend time rediscovering it.
Should we warn our engineering or security team?
Usually yes. Tell the people who need to know, such as on-call engineers and anyone who monitors alerts, so testing traffic isn't treated as a real incident. If you want to test whether your monitoring detects an attack, agree that explicitly with the testers instead of keeping it secret.
What if we're not sure what should be in scope?
That is normal for a first test. Describe what you have, why you need the test and who will read the report, and we will suggest a scope during the scoping call. Starting with your most important customer-facing system is often the right call.