What to include in a pentest scope before requesting quotes

Two pentest quotes can differ by thousands and both can be reasonable. The problem is often not the day rate. It is what each provider thinks you asked them to test.

Tell three firms, “Please quote for a pentest of our customer portal.” One may price the public-facing web application. Another may include the APIs and administration interface. A third may assume several authenticated roles, SSO, a staging environment and a retest. On the spreadsheet, you have three prices. In reality, you have three different tests.

A practical penetration testing scope template gives every provider the same starting point, exposes important assumptions before they turn into change requests, and makes it easier to compare coverage and evidence rather than just the headline number. In practical terms, a pentest scope should define the business objective, exact assets, environments, user roles, access level, exclusions, testing constraints, reporting requirements and retest expectations before a quote is finalized.

What is a penetration testing scope?

A penetration testing scope is the documented boundary of an authorised security assessment. It states what will and will not be tested, which environments and user roles are included, what access the tester receives, any operational restrictions, how urgent findings are escalated, what the report must contain and whether remediation verification is included.

For buyers, the scope is primarily a commercial and assurance control: it lets multiple providers price the same work. It is related to, but not identical to, the final Statement of Work or Rules of Engagement. Those documents usually add contractual terms, authorisation, detailed operating rules and delivery responsibilities once a provider has been selected.

This is not about writing the final Rules of Engagement before you choose a provider. NIST SP 800-115 treats planning as part of the assessment itself, covering goals, scope, requirements, limitations, roles, timeline and deliverables. PTES places the same discipline in its pre-engagement phase. The practical point is simple: give a testing firm enough context to understand the job it is pricing.

How to scope a penetration test: start with the business objective

“Improve security” is a valid reason to test, but it is not yet a useful scope. The provider needs to know what decision or assurance need sits behind the engagement.

A customer-facing platform that is about to launch may need deep authenticated web application penetration testing covering user roles, business logic and APIs. An external infrastructure assessment may be concerned with realistic internet-facing attack paths. A PCI DSS engagement may need specific internal, external or segmentation testing. An assumed-breach exercise starts from a different position again, and threat-led testing should not be treated as another name for an ordinary penetration test.

Before asking what, a penetration test costs, decide what you expect the assessment to tell you. Once that is clear, the technical scope becomes much easier to describe.

Define the in-scope assets, attack surface and user roles

Internal product names rarely tell a tester enough. “Our customer portal” may make perfect sense inside the business, but it immediately raises questions. Is there a separate administration interface? Is there a REST or GraphQL API? Are customers separated into tenants? Does sign-in use Microsoft Entra ID, Okta or another identity provider? How many meaningful privilege levels exist?

For web applications, the number of workflows and user roles can matter more than the number of URLs. For APIs, provide an approximate endpoint count where known, the authentication mechanism, any OpenAPI or similar specification, and whether the API is being assessed on its own or as part of an application. For complex API environments, API penetration testing should be scoped separately where deeper endpoint, authorization and business-logic testing is required.

For internal infrastructure, give the relevant network ranges or host counts, Active Directory context where applicable, important trust boundaries and the access the testers will receive. For cloud work, “our AWS environment” or “our Azure tenant” is rarely enough. Identify the accounts, subscriptions, projects and major services that are actually expected to be assessed.

Penetration testing scope checklist: what to include before a quote

The aim is not to answer every technical question in advance. It is to stop different suppliers from pricing different versions of the job. If a field is genuinely unknown, say so. That uncertainty is useful information during scoping.

Quick pre-quote pentest scope checklist

Before you send an RFP or ask for a fixed price, make sure the same brief gives every provider the following information:

• Business objective and compliance or customer-assurance driver.
• Exact applications, APIs, domains, IP ranges, cloud accounts, networks or mobile apps in scope.
• Production, staging, UAT or other environment to be tested.
• Authentication method and each meaningful user or privilege role to test.
• Approximate application complexity, API endpoint count, host count or cloud-service footprint where known.
• Third-party systems, explicit exclusions and any required testing permissions.
• Testing windows, rate limits, prohibited techniques and other operational constraints.
• Critical-finding escalation contact and secure communication route.
• Required report format, compliance mapping, remediation guidance and retest expectations.
• Desired testing and reporting dates.

Black-box vs grey-box vs white-box: define the access, not just the label

Black-box, grey-box and white-box are useful shorthand, but they should not replace a description of the access being provided.

A black-box assessment generally starts with little or no internal knowledge. A grey-box assessment provides selected information or access. In an application test, that may mean accounts for several roles so the available time can be spent on authenticated functionality, privilege boundaries and business logic. A white-box assessment provides extensive internal knowledge or access and may include architecture information, credentials, configuration detail or source code depending on the engagement.

None of the three is universally better. For a business-critical application, controlled access to several roles can provide far more assurance over authorisation and business logic than spending much of the test window trying to obtain an initial foothold. Describe the access. Do not rely solely on the colour of the box.

Scope vs Statement of Work vs Rules of Engagement

A penetration testing scope answers the buyer-side question: what exactly are we asking the provider to assess? A Statement of Work normally turns that agreed scope into contracted services, effort, dates, deliverables and commercial assumptions. Rules of Engagement define how authorised testing may be performed in practice, including testing windows, prohibited techniques, stop conditions, communication routes and emergency contacts.

Keeping these concepts separate helps procurement teams avoid two common mistakes: treating a one-line asset list as a complete engagement specification, or trying to write detailed operating rules before the provider has helped validate the technical scope.

Define out-of-scope assets, third-party systems and testing constraints

A good scope is just as clear about what must not be tested. There may be fragile legacy systems, customer datasets that are off limits, production payment functions that need special handling, or techniques such as denial-of-service testing that are prohibited. Those constraints can change the way the engagement is delivered, so the provider should know about them before pricing the work.

Third-party systems need the same care. Modern applications routinely depend on public cloud platforms, managed hosting, SaaS products and partner services. Technical reachability is not permission. If a third-party asset is expected to be tested, establish whether your organisation can authorise that activity and whether the provider has its own penetration-testing policy. If permission cannot be established, exclude the asset or agree an alternative approach before testing begins.

The pre-quote scope still does not replace the formal Rules of Engagement. It simply prevents important restrictions from appearing for the first time on day one.

PCI DSS, SOC 2 and ISO 27001: compliance requirements still need a defined scope

“PCI pentest” is not enough information for a useful quote. PCI DSS v4.0.1 contains explicit penetration-testing requirements in PCI DSS Requirement 11.4. If segmentation is used to isolate the cardholder data environment and reduce PCI DSS scope, the segmentation controls also need to be tested to confirm that they are operational and effective.

So, state what is actually required: internal testing, external testing, segmentation validation, or a defined combination. Identify the boundaries being relied upon and tell the provider what evidence the assessor or customer expects to see.

Other assurance programs should not be treated as interchangeable with PCI DSS. SOC 2, ISO/IEC 27001, customer contracts, insurer requirements and internal risk programs may use penetration testing as evidence of control effectiveness or assurance without prescribing the same methodology. The useful question is not simply “Which framework are we under?” It is “What must this test demonstrate, and who needs to rely on the report afterwards?”

Agree what happens if the test finds something serious

A critical internet-facing vulnerability should not sit quietly in a report draft until the engagement ends. The scope should identify a named contact and an agreed escalation process for high-impact findings.

That may mean immediate notification through a secure channel, enough evidence for the security team to contain the issue, and an agreement on whether testing should pause or continue. This is a small part of the scope document, but it can become the most important line in it when something genuinely serious is found.

Define penetration test deliverables, reporting and retesting

The lasting output of a penetration test is usually the report, so it should not be treated as an afterthought. Senior management may need a concise view of material risk and remediation priorities. Engineering teams need enough technical evidence to reproduce and fix findings safely. Security teams may want attack-path context and severity rationale. Compliance teams may need evidence that defined assets, controls or boundaries were actually tested.

If remediation verification is required, define that too. Ask whether a retest is included in the original price, how long the retest window remains available and whether it covers only the original findings. Two providers can propose similar testing effort while offering very different reporting and retesting arrangements. Those differences belong in the comparison.

How to compare penetration testing quotes fairly

Once the scope is ready, send the same version to every provider you are considering. Then look past the total price and ask:

• Are the same applications, environments, user roles and infrastructure actually included?
• What assumptions or exclusions remain?
• How much authenticated and manual testing is expected?
• How will urgent findings be communicated?
• What will the final report contain, and what evidence is included?
• Is remediation verification included, and on what terms?
• Does the proposed methodology match the business and compliance objective?

Material differences in interpretation are useful information. If one provider identifies an important area the others missed, ask why. If another excludes something central to the objective, clarify it before signing. Good penetration testing still requires professional judgement. The scope simply makes sure that judgement is being applied to the same problem.

The cheapest quote is only the cheapest if it is buying the same thing.

Penetration testing scope FAQs

Q1: What should be included in a penetration testing scope?

Ans: Include the business objective, exact assets and environments, user roles and credentials, testing approach, third-party dependencies, exclusions, operational restrictions, sensitive-data considerations, escalation contacts, deliverables, retesting expectations and target dates.

Q2: How do you scope a penetration test for a web application?

Ans: List the application URLs, environments, authentication method, meaningful user roles, major workflows, administration interfaces, APIs, tenant boundaries, third-party integrations and any functions or datasets that must not be tested. For quote accuracy, include approximate application or API size where it is known.

Q3: What is out of scope in a penetration test?

Ans: Anything not explicitly authorised should be treated as out of scope. Common examples include third-party services without permission, fragile legacy systems, production payment functions, live customer datasets, denial-of-service techniques and environments that are not part of the agreed assessment.

Q4: Does a penetration testing scope replace the Rules of Engagement?

Ans: No. A pre-quote scope is used to define and price the work. The Rules of Engagement add the detailed operational and safety rules for the authorised test, including timing, stop conditions, escalation and prohibited techniques.

Q5: Why do penetration testing quotes vary so much?

Ans: Quotes often vary because providers have made different assumptions about the number of assets, user roles, APIs, environments, testing depth, reporting and retesting. Sending the same structured scope to every provider makes those differences visible before you compare price.

Scope, complexity, testing type, reporting requirements and retesting can all affect the final price. See our guide to penetration testing costs for a deeper breakdown.

Ready to Scope Your Penetration Test?

A well-defined scope helps you compare providers on coverage, testing depth, assumptions, reporting and retesting not just price.

If you already know what needs to be tested, use the RedSecLabs Penetration Testing Estimator to structure your requirements and get an initial estimate.

If your environment is more complex such as a multi-role application, API ecosystem, multi-cloud environment, PCI DSS segmentation assessment or multi-discipline engagement a technical scoping discussion is usually the better starting point.

Get Your Pentest Estimate → https://www.redseclabs.com/services/penetration-testing-estimator

Tell us what you need tested. We'll help turn your requirements into a clear, defensible testing scope.

www.redseclabs.com

Media enquiries
[email protected]
+44 20 3996 1505