Penetration testing scope: template, example and price impact
Penetration testing scope is the written agreement on what will be tested, how deeply, and what is off-limits. It sets your price, your timeline and whether your customer or auditor can use the report. A scope describes the job. It is not permission to test; that takes explicit written authorization for the exact targets.
Below is a brief you can copy, a filled-in example, and what each scope choice does to a published price. At one provider, every signed-in user role you add is another $900.
Prices and policies on this page were checked October 8, 2026.
Penetration testing scope template: copy this brief
Use this brief to hand every provider the same description of the job. It works the way a job spec works for builders: same question to each supplier, so the answers line up. Fill in what you know. Write "Unknown" where you don't, and ask each provider what they assumed.
A few terms first. A penetration test (pentest) is an attempt, by people or software, to break into a system the way an attacker would. A vulnerability scan is an automated check for known weaknesses. A retest is a second look to confirm your fixes worked.
Penetration testing scope brief
Draft for scoping and quotes. This brief does not authorize testing. Never put passwords, keys or customer data in it.
| Field | Fill in, or write Unknown |
|---|---|
| 1. Purpose and report reader | Why do you need the test? Who will read the report, and what will they decide from it? Paste their original request if you have one. |
| 2. What the test must show | List each must-have. Mark it Mandatory, Preferred or Assumed, and say where it came from. |
| 3. Targets and size | Name each application, API, network or cloud account. Give rough counts and say how you counted. |
| 4. Environment | Production, staging or something else? Note how it differs from production. |
| 5. Access and roles | How users sign in. Which user roles to test. Whether you will supply test accounts, documentation or source code. |
| 6. Workflows that matter | The actions that would hurt if broken: payments, exports, permission changes, invitations. |
| 7. How the work is done | Ask the provider to describe the work, how much is done by people and how much by software, and what evidence you get. |
| 8. What is out, and who owns what | Each excluded system or activity, why it is out, and what that leaves untested. Name outside services and who can approve testing near them. |
| 9. Limits during testing | Dates, hours and time zone. Traffic limits. Rules for sensitive data. Who to call, and who can stop the test. |
| 10. Report and dates | What the report must contain, who gets it, and the date you need it. |
| 11. Retest and changes | How many retests, what gets rechecked, the deadline to ask and what starts that clock, any extra charge. Who approves a change of scope. |
| 12. What you already have | Any current provider, included test or past report. Then every open question, who should answer it, and by when. |
Ask each provider to reply like this: "Please answer this same brief. Say what your proposal includes, excludes or assumes, and list anything that would change the scope, the price or the schedule."
Prepared with The PenTest Index: https://thepentestindex.com/penetration-testing-scope/
What does a completed scope look like?
A completed scope turns "test our app" into named targets, roles, limits and proof. Here is one for a made-up company, so you can see how much a short phrase leaves out.
Fictional example. Larkfield is not a real company. These are not real offers or a real test.
Say you run Larkfield, a 30-person software company with one web app and a public API. A large customer wants proof that the app and the API were tested, that user roles are enforced, and that one customer cannot see another's data.
| Scope item | Larkfield's answer |
|---|---|
| Targets | One web app and one API, both in staging. The API must be tested directly, including calls the browser never makes. Endpoint count: Unknown. Engineering owes a list. |
| Roles | Viewer, Editor and Admin. Two test customer workspaces with made-up records. |
| What should be blocked | A Viewer cannot edit. An Editor cannot manage members. Nobody can reach the other workspace. |
| Accounts | Enough to compare different roles, two users with the same role, and the two workspaces. |
| Workflows | Sign-in, password reset, document edits, exports, invitations, role changes. |
| Environment | Staging is proposed. The customer has not yet said staging is enough. Unknown. |
| Out of scope | The payment and sign-in providers' own systems, the office network, and a review of cloud settings. |
| Report | Scope, limits, findings with evidence, and fix advice, by the customer's deadline. |
| Retest | Wanted. Deadline, cost and what gets rechecked are open questions. |
This site may contain affiliate or referral links. If you buy through one, we may be compensated. How we make money
Why three kinds of accounts? OWASP's testing guide checks two things: whether one user can reach another user's data at the same level, and whether a user can reach a higher role's functions (OWASP WSTG-ATHZ-02). The first needs two users with the same rights. The second needs two different roles.
Which proposal covers this scope?
Proposal B is the one worth a closer look, and it still has two open conditions. Here is the check. Both proposals are invented for this example.
Proposal A says: "Signed-in test of the staging web app. Direct API testing is excluded. Technical report included. Retesting to be agreed."
Proposal B says: "Test of the staging web app and public API, including direct API requests, the three roles and the boundary between the two workspaces. Report includes scope, limits, findings, evidence and fix advice. Report date and retest terms to be agreed."
| Larkfield's condition | How much it matters | Proposal A | Proposal B |
|---|---|---|---|
| Direct API testing | Mandatory | Mismatch: excluded | Supported: stated |
| Roles and workspace separation | Mandatory | Unresolved: not mentioned | Supported: stated |
| Report shows scope, limits and evidence | Mandatory | Unresolved: "technical report" is too vague | Supported: contents named |
| Report by the customer's deadline | Mandatory | Unresolved | Unresolved |
| Retest of fixes | Preferred | Unresolved | Unresolved |
| Staging is enough for the customer | Assumed | Unresolved | Unresolved |
"Supported" here means the proposal's words cover that one condition. It says nothing about how good the testing will be.
Proposal A fails a must-have as written, so it is out unless the provider revises it. Proposal B covers the API, the roles and the workspace boundary. It still needs a written report date, and Larkfield still needs an answer from its customer.
That answer comes from one question, sent to the customer and not to the provider:
"Will a test of our staging environment, with these listed differences from production, meet your request? If not, what production coverage or extra evidence do you need?"
If the customer says yes, write that into the brief. If they need production, the scope and the permissions change. If the answer is fuzzy, the condition stays open.
Already have a provider you like? Send them the same brief. You don't need a second opinion to use it.
How does scope change the price?
Among the prices we could check, user roles and API coverage move the number most. In Pentest-Tools.com's published offers, the cheapest scope is the one with no signed-in testing, and for most apps it is the wrong place to save, because that is where one user reaching another user's data gets caught.
We took four providers' published pricing pages and changed one scope line at a time. All prices are in US dollars, provider-published, checked October 8, 2026. A starting price is not a total, and no provider has quoted for this example.
| Scope choice | What the provider publishes | What that means |
|---|---|---|
| Test 2 signed-in user roles | Pentest-Tools.com grey box: "Starting from" $3,400 plus $900 per user role | $3,400 + (2 × $900) = $5,200 starting amount |
| Test 4 roles instead | Same formula | $3,400 + (4 × $900) = $7,000 starting amount. Each role adds $900. |
| Skip signed-in testing | Pentest-Tools.com black box: fixed price $3,400, 3 working days on a best-effort basis, anonymous attacker | $3,400. That is $1,800 less than the starting amount for two roles, and the listed scenario is an anonymous attacker. |
| Is the API part of the app? | Astra Pentest Expert: $5,999 per year, shown for one target. A web or SaaS app counts as one target "including all APIs consumed." Standalone APIs are one target each. | App plus the API it calls: one target. A separate API the app does not call: another target. Astra says some assets can be grouped, priced on a call. |
| Signed in or not, again | Synack Standard Pentest: starts at $10,283 for up to 25 unauthenticated web apps, or 1 low complexity authenticated web app, or 100 host IPs. The Synack Platform is a separate, required line item. | Signing in turns "up to 25 apps" into "1 app" at the same starting price. The page does not define "low complexity." Total: incomplete until the platform charge is known. |
| Give source-code access | Intruder same-day AI pentest: $4,000 per test, or $3,500 for platform subscribers, described as white-box, with "Connect your codebase" as step one and "No lead times or scoping" | If your scope says "no source-code access," ask whether this offer still applies. You still supply entry points, credentials and context, so check that the coverage matches yours. |
What to do with this:
- Settle roles first. Count the roles that see different things, not every job title.
- Say plainly whether each API is part of the app or separate. One sentence can change the target count.
- Ask what is not priced. The Pentest-Tools.com page says nothing about APIs or retesting. Ask: "For this app, its API and two roles, what is the complete price, including one retest?"
- Treat an unknown required charge as unknown. It is not zero.
Some offers we track have no published price. For them, your scope is what you send to get one. See published prices and terms side by side.
What should be in scope for my systems?
For Cobalt-specific coverage, see what a Cobalt web test covers.
Start from what the test has to prove, then list the real parts involved. A web address or product name does not tell a provider which roles, APIs or accounts are included.
| What you have | Put this in the brief | Don't assume |
|---|---|---|
| Web application | The app and environment, admin screens, how users sign in, roles, key workflows, which APIs are included | That one web address covers every role, workflow and API behind it |
| API | Versions, endpoint list, documentation, how clients sign in, user and service accounts, who can reach whose data | That testing the website exercises calls used only by partners or mobile apps |
| Network | Address ranges and known hosts, how you counted, where the tester starts, what is excluded | That an outside test includes the inside network |
| Cloud account | Which provider, which accounts you control, which services, and whether you want settings reviewed | That testing an app hosted in the cloud includes a review of the cloud setup |
| Mobile or specialist system | Build and version, platform, the APIs behind it, any device or site needs | That a web-app provider is the right fit |
For APIs, name who should be able to reach which records. OWASP separates two failures: reaching a function you should not have, and reaching a record you should not have by changing its ID (OWASP API1:2023). A scope that lists endpoints but not roles and records leaves the second one to chance.
If you are still deciding which parts of your system to include, Find My PenTest Match gives you the questions for each kind of test and a scope checklist to copy or print. It is free and asks for no contact details. It does not pick a provider for you.
Do testers need source code, accounts or just a URL?
Describe the access you will give instead of leaning on a label. Accounts, documentation and source code are three separate choices.
The labels are shorthand. Black box means the tester starts with little or no inside knowledge. Gray box means some, usually test accounts and documentation. White box means a lot, often including source code. Providers draw these lines in different places, so write down what you will hand over.
Less access is not automatically cheaper or more realistic. The PCI Security Standards Council's guidance says a black-box assessment "may require more time, money, and resources" to produce what a card-data assessment needs, and that gray-box and white-box tests give more accurate results (PCI SSC Penetration Testing Guidance v1.1, section 2). That is written for card data, but the logic travels.
One caution. Handing over test accounts is preparation. It does not prove each role was tested. Ask the provider which roles and workflows the quoted effort covers.
Should the test run in production or staging?
Pick the environment that answers the question your report reader is asking, then check the risk. Staging is safer to test and can still miss things.
NIST's testing guide puts it this way: "There are usually inconsistencies between the test and production environments, which can result in missed vulnerabilities" (NIST SP 800-115, section 6.3). The same section suggests a non-production system when a technique could knock a service over or expose personal data.
| Your situation | Sensible route | Settle this first |
|---|---|---|
| Staging behaves like production and your report reader agrees | Test staging and list the differences | Which production-only settings or connections stay untested? |
| The request is about production itself | Test the needed parts of production, with limits | Exact targets, hours, traffic limits and who can stop the test |
| Nobody knows if staging is enough | Ask the report reader before you request quotes | The question in the example above |
Two things people miss. Staging is often still wired to real email, real payments or real webhooks, so list those before testing starts. And switching a feature off to keep testing safe also means that feature was not tested. Write both into the scope.
What is out of scope, and who can authorize testing?
Leave out anything you lack authority or permission to test, and anything you are not willing to see disrupted. Then say what each exclusion leaves untested. Nothing in a scope brief gives permission; the people who own the systems have to give that in writing.
An exclusion and a limit are different things. "Do not test our payment provider's systems" is an exclusion. "Test our checkout using the provider's sandbox, after 9 p.m." is in-scope work with limits. Common exclusions are outside services you only subscribe to, other customers' data, attempts to overload a system, real payments, and tricking staff by email or phone unless you agreed to that separately.
Does my cloud provider need to approve the test?
Mostly no, within each provider's rules. Here is what the three official pages say, checked October 8, 2026.
| Cloud | Approval needed? | Key limits |
|---|---|---|
| AWS | No prior approval for the services on its permitted list. Other services need AWS Support. Tests using command-and-control need approval. Required Simulated Events requests must be submitted at least two weeks ahead. | Denial-of-service attacks, request or protocol flooding, and testing AWS's own infrastructure are prohibited under this policy. Controlled DDoS simulations follow a separate policy. |
| Microsoft Azure | No pre-approval or notice. An outside tester needs "explicit written authorization from the resource owner," and Microsoft says it does not give that on your behalf. | Denial-of-service testing is prohibited under the penetration-testing rules. Controlled DDoS simulations must use Microsoft-approved partners under its separate policy. |
| Google Cloud | "You are not required to contact us." You must follow its usage policy and terms. | Tests that affect anyone's projects but your own |
These are summaries. Read the page for the services and activities in your own scope.
Scope, statement of work, rules of engagement, authorization
They do four different jobs, and they can live in one signed agreement.
| Document | What it settles |
|---|---|
| Scope | What gets tested and what does not |
| Statement of work | The work bought, the deliverables, the dates and the price |
| Rules of engagement | How testing runs: hours, limits, contacts, when to stop |
| Authorization | Written permission from whoever owns each target |
The PCI SSC guidance lists what rules of engagement usually cover, including the time window, how to treat fragile systems, and what happens if the tester finds signs of a real break-in (section 4.1.3). NIST SP 800-115 includes a rules of engagement template in its Appendix B. Use the originals; we have not copied them here.
If any target is hosted or run by another company, have a lawyer look at the authorization and the contract before testing starts.
What report and retest terms belong in the scope?
Agree what the report must show and when it lands before you sign. If you need proof that fixes worked, put the retest terms in the original proposal too. They are much harder to add after the findings arrive.
| Topic | Ask this |
|---|---|
| Report contents | "Will the report state what was tested, what was excluded, the limits, each finding with evidence, and how to fix it?" |
| Report reader | "What does our customer or auditor need beyond that? Is a summary letter enough?" |
| Date | "What is the final report date, and what does it depend on from us?" |
| Retest coverage | "Which findings get rechecked, and by a person or a tool?" |
| Retest deadline | "By what date must we ask for the retest, what starts that clock, and does our contract end cut it short?" |
| Retest cost | "How many rounds are included, what costs extra, and do we get an updated report?" |
A word on names. A retest and a "rescan" may or may not be the same work. Ask what is rechecked, who does it, and what you receive.
Fix times matter here. The PCI SSC guidance notes that if fixes drag on long after the first test, a new test may be needed to reflect the system as it now stands (section 4.3.2).
Who decides the scope: you, the tester or your auditor?
You decide, the provider checks it, and whoever relies on the report can reject it. So ask the report reader before you ask for quotes.
You know the business reason and the system. The provider knows what is feasible and what it costs. Neither of you decides whether the report is accepted. That is the customer, auditor or assessor.
For a PCI DSS penetration test, the PCI SSC guidance is specific. It says the scope "includes the entire CDE perimeter and any critical systems," where CDE means the cardholder data environment (section 2.2). If the custom app in scope needs sign-in, testing should cover all roles (section 2.3.1). If you rely on network separation to shrink the scope, that separation has to be tested (section 2.2.3). And the organization being assessed is the one responsible for defining the environment (section 4.1.1). This guidance is supplemental and dated September 2017. It uses an earlier version's numbering, so confirm the boundary against the current standard with your assessor.
For anything else, such as a SOC 2 audit or a customer questionnaire, we have not read a rule we can quote here, so we won't guess. Ask the reader three things: which systems must be covered, how recent the test must be, and whether a software-only test is acceptable.
What happens if the scope changes mid-test?
Anything not written into the scope stays out until both sides agree in writing to add it. Decide now who can approve a change and what it does to the price and the date.
The PCI SSC guidance has a good example. During a test of an online shop, the tester found a backup site nobody had listed. The tester took it to the client, the client confirmed it, and only then was it added (section 6.1). That is the pattern to ask for: found, reported, approved, then tested.
Questions before you send the brief
Can I ask for a quote if I don't know every endpoint or host?
Yes. Mark your estimates and unknowns, and ask each provider what they assumed. Agree up front how a surprise will change the work and the price.
Do I need a new test if one is already included with something I pay for?
Only if the existing one leaves a gap. Check its real scope, date, limits and report against your brief, then ask your report reader if it will do. Ask your current provider for the missing piece before you buy a second test.
Is a vulnerability scan in scope the same as a penetration test?
No. The PCI SSC guidance describes a scan as mostly automated tools with some manual checking, and a penetration test as "a manual process that may include the use of vulnerability scanning or other automated tools" (section 2.1). If your reader asked for a penetration test, say so in field 2 of the brief and ask each provider how much of the work is done by people.
What does penetration testing scope look like for a small business?
Short. Often one app or one office network, a few roles and one report reader. Keep it small by naming the one system that matters most. Don't keep it small by cutting the signed-in roles.
Sources
All checked October 8, 2026. Provider facts are provider-published. We read the pages; we did not buy or run any test.
- Pentest-Tools.com: web app penetration testing services: black box and grey box prices, timing
- Astra: plans and pricing: Pentest Expert price and target definition
- Synack: pricing: Standard Pentest starting price, scope and platform line item
- Intruder: pentest pricing: same-day pentest price and workflow; setup instructions: buyer-supplied scope inputs
- AWS: penetration testing policy
- Microsoft: penetration testing in Azure
- Google Cloud: security FAQ
- PCI Security Standards Council: Penetration Testing Guidance v1.1, September 2017: sections 2, 2.1, 2.2, 2.3.1, 4.1, 4.3.2 and 6.1. Supplemental guidance, not the standard itself.
- NIST SP 800-115, September 2008: sections 6.3 and 6.5; Appendix B
- OWASP Web Security Testing Guide v4.2, WSTG-ATHZ-02
- OWASP API Security Top 10 2023, API1
The findings in the example use our Purchase Check: one condition, one offer, one finding. How to read a Purchase Check. None of these organizations endorses this site, and this page is not legal or compliance advice.