How to scope a penetration test: a seven-step buyer checklist

To scope a penetration test, write down why you are testing and list every asset in and out of scope. Count the pages, endpoints, roles and hosts that drive effort. Choose the approach and environment, agree rules of engagement, then fix deliverables and retest terms. Sorami confirms all seven in writing before testing starts.

Each step below changes the quote. Skip one and two firms will price two different tests, so the cheaper one is usually the smaller test. The free penetration test scope builder turns the same steps into a draft scope in your browser.

Step 1: Write down why you are testing

The reason decides the scope. A customer security questionnaire usually names one product. An ISO 27001 or SOC 2 audit wants evidence for the systems inside the audit boundary. A tender may name a standard or a deadline. Write the driver and the date you need the report by, and send the requester's exact wording if you have it.

Step 2: List the assets in and out of scope

Name every target by URL or IP address. Include cloud accounts and app store listings. Then name what is excluded, such as a third-party payment page or a shared identity provider. An asset nobody listed is an asset nobody tested. If a supplier hosts part of the system, check their testing policy before you add it.

Step 3: Count what drives the effort

Penetration testing firms size work by counts, not by company size. These are the counts we ask for:

• Web applications: dynamic pages or screens, forms and multi-step workflows.
• APIs: endpoint count, REST or GraphQL, and an OpenAPI or Postman file.
• Roles: each user role, with two test accounts per role.
• Tenants: whether customers share one deployment, plus two tenant accounts.
• Mobile: iOS or Android apps and the test builds.
• Infrastructure: external IP addresses or hosts.
• Cloud: accounts or subscriptions in scope.

Each surface is tested differently. See web application penetration testing, API penetration testing and cloud penetration testing for what each one covers. For APIs, our OWASP API Security Top 10 testing checklist shows what a tester checks in each category.

Step 4: Choose the testing approach

Black box means the tester starts with no credentials. Grey box means test accounts are provided. White box adds source code or architecture documents. Most buyer and audit requests are best served by grey box. It spends the time on authorisation and tenant boundaries instead of guessing passwords.

A scanner export is not a manual test. A useful report shows a person reproduced each finding, which our illustrative report (PDF) demonstrates. It is built from synthetic findings and is not a client report.

Step 5: Pick the environment and access

Staging is safer when it matches production. Record any difference between the two, because that difference limits what the result proves. Agree the testing window and whether a WAF or IP allow-list needs the tester's addresses. Say whether login uses MFA or SSO, and how test accounts will get past it.

Step 6: Agree the rules of engagement

Rules of engagement are the written permission and limits for the test. They name the stop-test contact and the hours testing may run. They also say what is off limits, such as denial of service or social engineering. Written authorisation from the system owner comes before any testing.

Step 7: Fix deliverables and retest terms

Agree what the report contains before the work starts. Ask for an executive summary, reproduction steps and a reasoned severity for each finding. Ask for specific remediation too. Agree the retest window and which findings it covers, because the retest record is often what an auditor reads. Our guide to what a penetration test report should contain lists the nine parts.

Pre-engagement checklist

Copy this before kickoff so test hours go on finding issues, not fixing credentials.

================================================================================
SORAMI: PENTEST SCOPING AND PRE-ENGAGEMENT CHECKLIST
================================================================================

1. DRIVER AND DEADLINE
   [ ] Reason for testing recorded (customer, audit, tender, release).
   [ ] Report needed by: ____________

2. ASSETS AND COUNTS
   [ ] URLs, domains, IP addresses, cloud accounts and apps listed.
   [ ] Exclusions listed (third-party services, shared identity provider).
   [ ] Page, endpoint, role, tenant and host counts recorded.

3. ENVIRONMENT & DATA
   [ ] Staging environment has parity with production code and configuration.
   [ ] Outbound email and SMS notifications redirected to test sinks.
   [ ] Production database sanitised (no raw customer PII in staging).

4. ACCESS & TEST ACCOUNTS
   [ ] Two accounts per role, and two tenants if multi-tenant.
   [ ] Test authentication and MFA approach agreed. Do not share production secrets.
   [ ] OpenAPI spec, GraphQL schema, or Postman collection provided.

5. NETWORK & WAF
   [ ] Tester egress IP addresses allowlisted in WAF and firewalls.

6. RULES OF ENGAGEMENT
   [ ] Written authorisation signed by the system owner.
   [ ] Stop-test contact and testing hours agreed.
   [ ] Out-of-bounds activities agreed (denial of service, social engineering).

7. DELIVERABLES
   [ ] Report contents and retest window agreed in writing.
================================================================================

Sorami’s view

This section is opinion. It is how we scope our own work.

The scoping gap we see most is roles. A test with one account per role cannot show that one customer is unable to read another customer's data. That is usually the question the buyer asked. Ask for two accounts per role and two tenants first. If the budget is tight, cut assets before you cut roles. Send the seven answers and our penetration testing team returns a fixed scope and fee in writing.

Related guides

• OWASP API Security Top 10 testing checklist
• Cloud security review checklist for AWS and Azure
• Cloud security review vs penetration test
• Every guide is in the guides index.