Pentest engagement — proposal and scoping

TL;DR: Scoping is the load-bearing phase of a pentest — get it wrong and you ship a useless report or, worse, break something you were never authorised to touch. This note walks through kickoff discovery, scope boundaries, threat-model framing, SOW structure, pricing models, legal authorisation, and compliance overlays. Companion to responsible-disclosure-across-jurisdictions and report-writing-for-pentesters.

Why it matters

A pentest proposal is a contract, a project plan, and a threat model rolled into one. It defines what “done” looks like, who is liable when something breaks, and how findings are graded. Sloppy scoping leads to:

Testers wasting days on assets the client doesn’t actually care about.
Findings that miss the real risk because the threat model was never agreed.
Legal exposure when a test touches a third-party SaaS or a production database without written authorisation.
Disputes over deliverables, retests, and payment.

Compliance-driven engagements (PCI DSS, HIPAA, SOC2, NIS2) add a second layer: the scope must satisfy an external assessor as well as the client. See pci-dss-4-implementation and soc2-vs-iso27001 for the regulatory side.

Client kickoff — discovery questions

Before you write a single line of the proposal, run a 45-60 minute discovery call. Bring a checklist; do not freestyle.

Business context

What triggered this test? (Annual audit, new product launch, board request, post-incident, M&A due diligence.)
Who is the executive sponsor and who signs the SOW?
What is the worst-case scenario the business wants to avoid? (Data breach, regulatory fine, downtime, reputation.)
Are there compliance frameworks driving the requirement? (PCI, HIPAA, SOC2, ISO 27001, DORA, NIS2.)
When is the report needed and why? (Audit deadlines change the schedule and the deliverable format.)

Technical context

What assets are in scope? (URLs, IP ranges, mobile apps, APIs, source code, cloud accounts, AD domains.)
What is the architecture at a high level? (Monolith vs microservices, cloud provider, identity provider.)
Are there assets explicitly out of scope? (Third-party SaaS, payment processors, legacy systems pending decommission.)
What environments are available? (Production, staging, dedicated test tenant.)
Are there fragile systems we must avoid? (SCADA, medical devices, legacy mainframes.)
What testing has been done before? (Last report, known issues, remediation status.)

Operational context

Who is the technical point of contact during testing?
What hours are testing allowed? (24/7, business hours only, change-freeze windows.)
What is the escalation path if we find a critical issue or accidentally cause an outage?
Are SOC/blue team aware? (Announced vs unannounced — see red-team-vs-pentest-engagement-shape.)
Are credentials provided? (Black-box, grey-box, white-box.)

Scope definition

In-scope assets

Be explicit. Vague scope (“the web app”) creates disputes. List:

Fully-qualified domain names and subdomains.
IP ranges in CIDR notation.
API endpoints with base URLs and OpenAPI/Swagger references.
Mobile app bundle IDs and store links.
Cloud accounts (AWS account IDs, Azure tenant IDs, GCP project IDs).
Source code repositories if doing white-box review.
User roles to test against (admin, regular user, anonymous).

Out-of-scope assets

Equally explicit. Common exclusions:

Third-party SaaS (Salesforce, Workday, Stripe) — the client cannot authorise testing.
Shared infrastructure (CDN edges, DNS providers) — see domain-fronting-and-cdn-abuse.
Physical security and social engineering unless separately scoped.
DoS/DDoS testing unless explicitly requested with a maintenance window.
Production data exfiltration beyond proof-of-concept volumes.

Testing techniques in/out of scope

Automated scanning allowed? Which tools?
Exploitation depth — proof-of-concept only, or full post-exploitation?
Lateral movement permitted? Across which network boundaries?
Persistence mechanisms — allowed during the test, must be removed before report.
Credential cracking — allowed offline only, never against live auth endpoints.

Threat-model framing

A pentest without a threat model is a checklist exercise. Spend an hour with the client mapping:

Assets — what is valuable? (PII, PHI, cardholder data, IP, source code, customer trust.)
Adversaries — who would attack? (Opportunistic criminals, organised ransomware, nation-state, insider, competitor.) Reference apt-tradecraft-russian-svr-fsb or ransomware-affiliate-playbook if the client has specific concerns.
Attack surface — how would they get in? (Internet-facing apps, phishing, supply chain, physical.)
Existing controls — what stops them today? (WAF, EDR, MFA, network segmentation.)
Test objectives — which of the above does this engagement validate?

Document the chosen threat model in the SOW. It justifies the scope and grounds the findings.

Statement of Work sections

A defensible SOW includes, at minimum:

Parties and effective dates — legal entities, signatories, start/end dates.
Background and objectives — why the test, what it validates.
Scope — assets, techniques, environments, exclusions.
Methodology — frameworks referenced (PTES, OWASP WSTG, NIST SP 800-115, MITRE ATT&CK).
Rules of Engagement — testing hours, escalation, blue team awareness, evidence handling.
Deliverables — executive summary, technical report, raw findings, retest letter, attestation.
Acceptance criteria — what triggers payment, what triggers a retest.
Schedule and milestones — kickoff, testing window, report draft, readout, retest.
Pricing and payment terms — see below.
Confidentiality and data handling — NDA references, evidence retention, destruction.
Liability and indemnification — caps, carve-outs for gross negligence.
Change control — how scope changes are approved.
Signatures.

Pricing models

Time and materials (T&M)

Daily or hourly rate × estimated days.
Client pays for actual time, capped at not-to-exceed.
Best for exploratory engagements, red team, research-heavy work.
Risk to consultant: scope creep eats margin if cap is hit.
Risk to client: cost uncertainty.

Fixed price

Lump sum for defined scope and deliverables.
Best for repeatable engagements (annual web app test, PCI ASV-style scope).
Risk to consultant: under-estimation eats margin.
Risk to client: change orders for anything outside the original scope.

Hybrid

Fixed price for core scope, T&M for add-ons (extra apps, retests beyond first, social engineering bolt-on).
Common in mid-market consulting.

Retainer

Monthly or quarterly fee for a block of testing hours.
Best for clients with continuous deployment who need rolling assessment.
Pairs well with purple-team-feedback-loop arrangements.

Legal authorisation

Engagement letter

Signed before any testing begins. Must reference:

Specific assets the client owns or controls (no third-party assets without their separate authorisation).
Named individuals authorised to approve scope changes.
Indemnification for testing activities performed within scope.
Data handling clauses — what testers may extract, store, and for how long.

Rules of Engagement (RoE)

Operational document, often appended to the SOW. Covers:

Testing windows and blackout periods.
IP addresses testers will originate from (for SOC allowlisting if announced).
Communication channels (Signal, encrypted email, Slack shared channel).
Stop conditions — what causes the test to pause (critical finding, production impact, incident).
Evidence handling — screenshots, packet captures, exfiltrated data samples.
Cleanup obligations — remove implants, rotate credentials used, delete test accounts.

Third-party authorisation

If the client uses cloud (AWS, Azure, GCP), check the provider’s pentest policy. Most allow customer-initiated testing of customer-owned resources without prior approval, but explicit categories (DoS, social engineering of provider staff) remain prohibited.

Compliance overlay

PCI DSS 4.0

Annual external and internal pentest required for CDE.
Segmentation testing required if scope reduction relies on network segmentation.
Methodology must follow industry-accepted approach (NIST SP 800-115, OWASP, OSSTMM).
See pci-dss-4-implementation.

HIPAA

No explicit pentest mandate, but Security Rule risk analysis often requires it.
BAA must be in place before tester accesses PHI.
See hipaa-security-rule.

SOC 2

Type II reports often cite pentest as a control.
Auditor wants evidence of scope, methodology, findings, and remediation.
See soc2-vs-iso27001.

NIS2 / DORA

EU operators of essential services and financial entities face mandatory testing regimes.
TLPT (Threat-Led Penetration Testing) under DORA has specific scope and tester qualification rules.
See nis2-implementation.

Workflow to study

Read the PTES Technical Guidelines and the OWASP WSTG scoping sections.
Collect three sanitised SOWs from prior engagements; diff their scope and RoE language.
Draft a discovery questionnaire and run it against a willing internal team as a dry run.
Practise translating ambiguous client asks (“test our cloud”) into concrete asset lists.
Read the AWS, Azure, and GCP pentest policies end-to-end so you can advise clients in real time.
Build a pricing model spreadsheet — days per asset class, rate card, contingency.
Shadow a senior consultant on a kickoff call before leading one solo.

References

PTES — Penetration Testing Execution Standard, Pre-engagement Interactions: https://web.archive.org/web/2024/http://www.pentest-standard.org/index.php/Pre-engagement
NIST SP 800-115, Technical Guide to Information Security Testing and Assessment: https://csrc.nist.gov/publications/detail/sp/800-115/final
OWASP Web Security Testing Guide, Scoping chapter: https://owasp.org/www-project-web-security-testing-guide/
PCI SSC, Penetration Testing Guidance: https://www.pcisecuritystandards.org/documents/Penetration-Testing-Guidance-v1_1.pdf
AWS Customer Support Policy for Penetration Testing: https://aws.amazon.com/security/penetration-testing/
CREST, Guide to Procuring Penetration Testing Services: https://www.crest-approved.org/buying-cyber-security-services/