How to Scope a Pentest — A Checklist That Actually Survives Procurement

Published May 19, 2026 · By AxVeil Research · 14 min read

Most failed pentests fail at scoping, not at testing. The vendor finds the bugs they were paid to look for, the buyer wanted a different set of bugs found, and both sides spend the closeout meeting re-arguing the statement of work. This guide is the checklist we use at AxVeil with first-time pentest buyers — every line item on it has stopped a real engagement from going sideways. Treat it as a procurement document, not a marketing post. Print it, paste it into your RFP, and walk every shortlisted vendor through it before signing.

Phase 1 — Define why you are testing

Every other scoping decision flows from this question. The honest answers usually fall into one of five buckets, and the right test profile differs in each.

Compliance pass-through. SOC 2, ISO 27001, PCI DSS, RBI / SEBI / IRDAI — the auditor demands a recent pentest report. Scope: every system in audit scope, methodology mapped to the framework.
New release assurance. A major feature, an acquisition, or a re-platforming. Scope: the changed surface plus the integration points to the rest of the estate.
Incident-driven baseline. Something almost happened (or did happen) and the board asked for an independent view. Scope: broad, with a deliberate path-to-impact narrative in the report.
Customer-driven assurance. A prospect or enterprise customer is demanding a recent third-party pentest letter. Scope: their use case, their data flow, their controls.
Maturity ratchet. Your own programme decided it is time to up coverage. Scope: an under-tested surface (mobile, GraphQL, internal API mesh, OT).

Write the answer down, share it with the vendor, and let it drive every later trade-off. If "why" is "compliance", do not over-scope to find P1 bugs that have nowhere to go. If "why" is "incident response", do not under-scope to a single web app.

Phase 2 — Inventory the in-scope assets

The vendor can only test what you list. Build the inventory in writing before the kickoff call — sales scoping conversations are a notoriously unreliable source of truth.

Web & API assets

Every distinct hostname, including staging., uat., and customer-facing tenants.
API base URLs and the spec format you can share (OpenAPI 3.x, Postman collection, GraphQL introspection).
Authentication mechanism per surface (cookie, JWT, OAuth, mTLS, API key).
User roles to test (anonymous, free tier, paid tier, tenant admin, support, internal admin).
Tech stack disclosure: language, framework, ORM, queue, cache, WAF. Saves the tester a day of fingerprinting they would have billed you for.

Cloud & infrastructure

Account / subscription / project IDs in scope, with the regions deployed.
Read-only IAM role for configuration review (Prowler, ScoutSuite, CloudSploit run against this).
VPC topology summary — public ALBs, NAT egress, peering, transit gateway, on-prem links.
Whether the assessment includes the cloud control-plane (recommended) or workload-only.
Acceptable-use clauses for the relevant cloud provider — see the AWS pentesting methodology primer.

Mobile, thick client, OT

Mobile: build artefacts (AAB/IPA), test accounts, backend API surface, jailbroken/rooted device policy.
Thick client: installer, target OS version, license keys, server-side endpoint addresses.
OT / ICS: protocol list (Modbus, BACnet, DNP3, S7), allowed activity (read-only? active probing?), safety contact.

Excluded assets — equally important

Explicitly list anything out of scope. Production payment processors, third-party identity providers, customer data of named tenants, shared analytics services, partner integrations. The exclusion list protects you legally and the vendor operationally.

Phase 3 — Rules of engagement

The rules of engagement document is where the lawyers, the auditors, and the operators all need to agree. A solid RoE has at least the following sections:

Testing windows. Business hours only, or 24x7? Production allowed, or staging only? Date range, with explicit blackout days (releases, board events, end of quarter).
Allowed techniques. Active exploitation? Social engineering? Physical? Phishing scope (which addresses, which payloads, which landing pages).
Stop conditions. Anything that would force pause-and-notify: production data destruction, suspected real-world incident, customer impact above a defined threshold.
Notification matrix. Who gets paged in which scenario? Provide on-call rotations for the SOC, IR lead, legal, and the white cell.
Evidence handling. How is exfiltrated data stored? When is it destroyed? Hash list to prove non-retention.
Reporting flow. Critical findings disclosed within N hours of discovery (24 is the modern norm). Final report draft inside M days.
Re-test entitlement. One free re-test inside the next 60-90 days is standard; spell it out.

# Sample RoE excerpt (paste into your SoW)

Testing window:    2026-06-01 to 2026-06-19, weekdays 09:00-19:00 IST
Production:        Allowed, read-only assertions only above CRITICAL impact
Stop conditions:   (a) tester observes real customer data loss
                   (b) WAF alerts trip incident channel
                   (c) > 50 5xx/min sustained for > 5 min
Notify within 1h:  security-oncall@acme.example, +91-xxx-xxx-xxxx
Critical disclosure: 24 hours from confirmation via signed PGP email
Source IPs:        198.51.100.10/29 (rotation), 203.0.113.4/30 (fallback)
Out of scope:      *.salesforce.com, *.auth0.com, stripe.com, sendgrid.net

Phase 4 — Credentials & access

Black-box testing is rarely the right answer for a paid engagement. A tester spending three days guessing passwords is three days not spent on business logic flaws. Provision the following beforethe first day of testing:

Two accounts per role tier (so the tester can verify horizontal privilege boundaries between users at the same level).
One account with elevated privileges for vertical privilege boundary testing.
API keys / tokens with the same scope as production but tied to test accounts.
Read-only access to logs (CloudWatch / Stackdriver / Splunk) for the tester to verify which of their actions actually triggered alerts.
Read-only repo access for grey-box engagements, with secrets scrubbed.
VPN / bastion credentials for internal network tests, plus a sandbox VM the tester can pivot from.

Phase 5 — Third-party & sub-processor authorisation

Cloud providers, CDNs, and PaaS vendors publish their own pentest policies. Some require written notification, some forbid it altogether, and a few will silently null-route your tester's IPs the moment they trip a heuristic. The minimum due diligence:

AWS: most services no longer require approval; stress/DoS does. AWS Customer Support Policy.
Azure: file a Penetration Testing Notification if you plan high-risk activities.
GCP: customer-initiated testing of your own projects is allowed without notice.
CDN / WAF (Cloudflare, Akamai, Fastly): get written confirmation that your testing IPs will not be auto-banned, and that probing the WAF edge is allowed.
Identity providers (Auth0, Okta, Cognito): explicit no-go on multi-tenant control plane. Test only your tenant.
Payment processors (Stripe, Adyen, Razorpay): out of scope. Test your integration code, not their endpoints.

Phase 6 — Deliverables, severity model, and re-test

Most procurement issues we see happen because the buyer assumed certain artefacts would be in the final deliverable and the vendor never agreed to them. Be explicit:

Executive summary (2-3 pages, board-ready, no jargon).
Per-finding technical narrative with repro steps, screenshots, request/response pairs.
Severity using CVSS 4.0 (or CVSS 3.1 plus CVSS 4.0 dual-scored — see our CVSS 3.1 vs 4.0 comparison).
EPSS percentile and CISA KEV membership for any CVE-mapped finding.
Mapping to OWASP Top 10 2026, MITRE ATT&CK, and any framework you owe an auditor (PCI DSS, ISO 27001, SOC 2 CC-series).
Remediation guidance specific to your stack — not a generic OWASP cheat-sheet paste.
A re-test letter inside 60-90 days, confirming closure of all P1/P2 findings, suitable to share with customers and auditors.
Optional: machine-readable export (SARIF, CycloneDX VEX) for ingestion into Jira and your SIEM.

Severity calibration — agree upfront

Vendors often score the same bug differently. If your SLA says "close all Highs in 30 days", agree the severity model in the SoW. We default to CVSS 4.0 BTE plus a written remediation priority (P1-P4) that takes business context into account. Run new findings through the CVSS calculatorso both sides can audit the vector.

Phase 7 — The vendor questions you must ask

Ten questions that separate a real pentest from a Nuclei sweep with a PDF on top.

What is the named consultant's OSCP / OSWE / CRTO / CREST status and how many years on the tools?
Will the same consultant write the report, or does a junior do the test and a senior the words?
What percentage of findings each engagement are manual vs automated?
How do you handle critical findings between draft and final — disclosure window?
What does your re-test letter look like? Can you share a redacted example?
What is your stance on AI-assisted testing — model used, prompts logged, data retention?
Where is finding evidence stored, who has access, when is it destroyed?
How are your testers cleared (background check, NDA, country of residence)?
What is your insurance posture (errors & omissions, cyber liability, minimum cover)?
Will you accept our SoW redlines or are your templates the only path?

For a sector-specific lens, our BFSI and SaaS pages cover the additional regulatory asks for those verticals.

FAQ

How long should pentest scoping take?

For a single web application: 30-60 minutes of structured conversation plus 1-2 days for the buyer to gather the assets and credentials. For an enterprise estate (network + applications + cloud + mobile), allow 2-3 weeks of joint scoping including discovery scans and stakeholder interviews. If the vendor scopes in under 15 minutes from a sales call, expect surprises mid-engagement.

Should we share source code with the pentester?

Yes, for grey-box engagements. Source access typically uncovers 30-50% more authorisation and business logic flaws per day than black-box does, at the same price. NDA the engagement, share a read-only repo mirror, and make sure secrets are scrubbed before access. Black-box is reasonable only for first-time engagements where you want a true outsider view.

Do we need permission from AWS or Azure to pentest cloud workloads?

AWS removed prior-approval for most service categories in 2019 but still requires approval for stress/DoS testing. Azure publishes a Penetration Testing Notification process for high-risk activities. GCP allows testing your own projects without notification. Always document the cloud-provider acceptable-use clauses you are operating under in the rules of engagement.

How do we scope when our application uses third-party SaaS components?

Test only the components you own or for which you have written authorisation. Read the SaaS vendor's responsible disclosure or bug bounty terms before any probing — Cloudflare, Auth0, Stripe, and most identity providers explicitly prohibit pentesting their multi-tenant infrastructure. The pentest scope statement must list every excluded sub-processor by name.

What is the right pentest duration for a typical SaaS application?

Plan five testing days per major user role plus two days for reporting. A B2B SaaS with admin, tenant-admin, end-user, and unauthenticated surfaces typically needs 15-20 testing days. Stretching that across a 3-4 week calendar (so testers have time to follow leads between sessions) usually produces higher-impact findings than the same effort crammed into a single week.