How to prepare for your first penetration test

A penetration test is a fixed number of tester-days pointed at your product. Every hour lost to a broken test account, a blocked IP address or an argument about scope comes out of coverage, and coverage is what you are buying. Teams that prepare get findings about tenant isolation, payment logic and privilege escalation. Teams that skip preparation tend to get a report padded with missing security headers. If you only want the list, print the pre-pentest checklist.

Decide what the report is for

Before you think about hostnames, decide which decision the report will support. 'Find vulnerabilities' is not an objective; it describes the activity. The objective shapes the scope, the depth and even who should read the result.

If you already run vulnerability scanners, hand the latest results to the testers at the scoping stage, as the UK's National Cyber Security Centre recommends. Every known issue you disclose up front frees tester time for the problems scanners cannot see.

Choosing a scope you can defend

A good scope is a list of things an attacker could reach, not a list of things you are proud of. Start with an inventory, then cut deliberately and write down why.

1. 1

   Inventory every entry point

   Domains and subdomains, web applications, public and private APIs, mobile backends, webhooks, admin panels, and the forgotten staging host that is still on the internet. Include the third-party integrations that receive your data.

2. 2

   Name the crown jewels

   The data or capability whose loss would genuinely hurt: customer records, payment flows, signing keys, the admin console. The scope has to reach them, or the report cannot say whether they are safe.

3. 3

   Describe user flows and roles as well as hosts

   Sign-up, login, password reset, inviting a teammate, changing a role, exporting data, billing and deleting an account. Testers find authorisation flaws by walking each user flow as each role.

4. 4

   Mark what is out of scope, and why

   Third-party SaaS you do not own needs its owner's permission, so payment processors and identity providers usually stay out. Your integration with them stays in.

5. 5

   Check your cloud provider's rules

   AWS lets customers test a published list of services without prior approval but prohibits denial-of-service and request flooding. Google Cloud does not need to be contacted, but tests must follow its Acceptable Use Policy and affect only your own projects. Microsoft confines testing to your own tenant and prohibits denial-of-service testing.

6. 6

   Write it down on one page

   Targets, exclusions, testing windows, the accounts provided and the escalation contacts. If it is not written down, it is not in scope.

If you are unsure where the boundaries should sit, that is what a scoping call is for: walking your architecture usually settles it. A 45-minute scoping call ends with a fixed quote and a proposed start date; the written scope follows by email.

Staging or production?

Both are defensible; what matters is choosing deliberately and knowing what each leaves out. Our default is production wherever it is safe, because staging rarely reproduces the real access-control model, real data volumes or real third-party integrations. Where production is off-limits we test staging and state explicitly which findings could not be validated in production.

If staging is the answer, make it worth testing:

• Deploy the same build as production, with the same authentication settings and feature flags.
• Seed at least two tenants with realistic objects: invoices, files, users and API keys. Authorisation bugs need something to point at.
• Put the same WAF rules and rate limits in front of it, or record in the scope that you have not.
• Snapshot it, and prove the snapshot restores before the first day of testing.
• Freeze redeployments for the test window. A refresh that wipes test accounts can cost a whole tester-day.

Test accounts, roles and access

Most serious findings in modern applications are authorisation failures: one tenant reading another's data, or a member doing an administrator's job. Testers can only find them if they hold accounts on both sides of every boundary. Provide:

• Two separate tenants or organisations, so cross-tenant access can be tested in both directions.
• Every role in each tenant: owner, administrator, standard member, read-only, billing, and any custom roles your customers actually use.
• API keys or tokens for each role, if your API issues them separately from user sessions.
• Multi-factor authentication enrolled the way customers enrol, with the factor shared securely, so the MFA flow itself stays in scope.
• A test identity-provider connection if you offer SAML or OIDC single sign-on.
• Sandbox payment credentials, and the feature flags that switch on paid features.
• Mobile builds for both platforms, in the form you ship to the app stores.

Then log in as every account yourself the day before testing starts. Expired invitations, unverified email addresses and accounts stuck in onboarding are a common reason a first morning is wasted, and each one is a five-minute fix if you find it first.

What to tell your team

A penetration test looks like an attack because it is one, with permission. Decide in advance who knows, and write it down.

Every request we send carries an identifier your team can filter on, so separating test traffic from everything else is a search, not a guess. Two habits protect the test itself. Do not quietly fix findings mid-test without telling the tester: it moves their baseline and makes the retest ambiguous. And if something looks like a real intrusion rather than test traffic, say so at once. Testers sometimes find signs that someone else got there first, and that turns a test into incident response.

The first day, and how to read daily updates

On a well-run engagement nothing on the first day should surprise you. It usually runs like this:

1. 1

   Kick-off

   A short call to confirm scope, accounts, testing windows and escalation contacts. Anything unresolved here becomes a blocker by lunchtime.

2. 2

   Access checks

   The tester logs in as every role, confirms network reachability and reports anything that does not work.

3. 3

   Mapping

   Crawling the application, reading the API schema, enumerating endpoints and roles. Automated tools help with coverage; they are not the assessment.

4. 4

   First manual testing

   Usually authentication and session handling, because every later test depends on understanding them.

5. 5

   The first written update

   What was covered, what is blocked, provisional findings and questions for you.

We send a short written update at the end of every testing day, and a critical finding is escalated the moment it is confirmed rather than saved for the report. Read each update the same day, in this order:

1. Blocked: anything waiting on you. A blocker answered within the hour costs nothing; one answered tomorrow costs a day of coverage.
2. Coverage: which user flows and roles were exercised. Compare against the scope, and if something important is untouched by the midpoint, ask why.
3. Provisional findings: severity can still move as the tester learns more. Note them, but do not ship a fix that changes the system under test without saying so.
4. Questions: answer them in writing, so the answer becomes part of the record.

What to do with the report

In the week the report arrives, do six things:

• Read the executive summary first, then the findings by severity, then the scope and limitations, which tell you what was not tested.
• Triage against your own context: the business impact the tester could not see, and controls they did not know about. Bring evidence to the walkthrough session; that is where severity disputes belong.
• Fix root causes, not instances. One insecure direct object reference usually means the authorisation pattern is wrong everywhere it is used.
• Put every finding in the engineering backlog with an owner and a date, or nothing will change.
• Book the retest while the context is fresh. Ours is a free retest of every fixed finding within 30 days of report delivery, followed by a reissued report with updated status and an attestation letter for customers.
• Share the attestation letter or the executive summary externally, never the full report: it is a map of how to attack you.

How to read a penetration test report covers the report itself, including how to argue about severity. If you are preparing a first test now, start with the pre-pentest checklist, then book a scoping call. For most SaaS products the right first engagement is an authenticated web application test.