How to scope a penetration test

Scope a penetration test with a written asset list, testing objective, authorized access, operating limits, and required deliverables. Give providers the same brief so a lower quote does not conceal a narrower test.

NIST SP 800-115 covers planning, conducting, and evaluating security testing. Use that process as a starting point, then agree the approach with the provider for your application and business constraints.

Define the decision the test should support

Start with why you need the work: evaluating a new application, understanding a particular attack path, checking remediation, or responding to a customer request. Share the exact customer wording where relevant. A request for an application test may not be satisfied by an automated network scan.

Describe what the resulting report needs to help your team decide. For example, you may want to know whether one customer can access another customer's data, whether a role can perform unauthorized actions, or whether an external system exposes a sensitive workflow. Ask the provider to explain how those questions affect the proposed method.

Describe the assets and access

List applications, API endpoints, domains, environments, account roles, and integrations. Identify ownership and separate production from staging. Record meaningful differences between environments so a test of staging is not mistakenly described as a test of all production conditions.

• Application: key workflows, authentication, tenant model, and role boundaries.
• API: endpoints, documentation, tokens, and representative test data.
• Infrastructure: agreed hosts, networks, accounts, and cloud boundaries.
• Access: provided accounts, privileges, and any source or architecture information.
• Exclusions: third-party systems, prohibited actions, and features outside scope.

Ask which manual techniques the provider proposes and what automated tools contribute. Describe rate limits, fragile systems, and business-critical workflows. Resolve permissions for third-party assets before including them.

Agree the rules of engagement

Set rules of engagement before testing begins: written authorization, timing, allowed and prohibited actions, escalation contacts, stop conditions, and sensitive-data handling. Decide how the team will distinguish authorized testing from an incident.

Specify who can pause work and how an urgent finding is communicated. Agree retention and deletion of test data, evidence, and credentials. If a test could affect service availability, make the operational owner part of the approval process and document the limits.

Specify the deliverables

Request both a summary useful to decision-makers and technical detail useful to engineers. Ask for the tested assets, dates, methods, limitations, finding evidence, business context, and remediation guidance. Have the provider explain how severity is assigned and how disputed findings are reviewed.

Agree what a retest covers, when it can happen, and whether it produces an updated report or a separate closure record. Confirm whether new findings or substantial application changes require a different engagement. A report that lists weaknesses without a route to verify fixes is harder to use operationally.

Compare proposals on the same work

Record asset coverage, roles, manual work, test duration, staffing, report format, urgent notifications, retesting, exclusions, and fees. Ask each firm to explain any assumptions about your asset inventory. Compare the quoted work rather than the number of certificates or logos on a sales page.

For a short proposal, ask what it leaves out. For a larger engagement, ask what additional work supports your objective. Avoid treating a clean report as a guarantee that every vulnerability has been found.

Start with a written brief

Assign an internal technical owner, prepare the asset list, and resolve the operational constraints. Browse penetration testing providers and request scoped proposals. After the test, assign owners and dates for findings and agree how completed remediation will be verified.

Download the editable penetration-test brief. Fill in your scope and verified answers before sharing it with a provider.

Build your penetration test scope and compare provider proposals using the same scope.

After delivery, use the penetration-test report review guide to assign remediation, verify fixes, and prepare customer evidence.