How to Scope an Enterprise Penetration Test: Free Scope-of-Work Template

A penetration testing scope defines the assurance an enterprise needs, not just the assets a vendor will touch. Start with the business or compliance objective, then map the system boundary before counting assets. List applications, APIs, infrastructure, roles and integrations separately, specify authenticated and unauthenticated testing, and clarify whether production, staging or both will be tested. Establish written rules of engagement before testing begins, document prohibited techniques and escalation contacts, and require clear methodology, evidence, reporting and retesting. Build in a process for newly discovered assets, and confirm every shortlisted vendor is pricing the same scope.

Why Two Vendors Can Quote the Same Pentest and Deliver Different Coverage

Many penetration tests get scoped as a number. One application, twenty IP addresses, or ten testing days. Those numbers help a vendor build a quote, but they do not explain what the enterprise actually needs the test to prove. Two vendors can quote the same application and deliver entirely different coverage: one unauthenticated user journey versus several roles, supporting APIs, administrative functionality, cloud infrastructure, internal trust paths, and business logic testing all included. A well-defined penetration testing scope closes that gap before either vendor writes a line of the statement of work.

This guide walks through a step-by-step scoping process, gives asset-specific guidance for every environment type an enterprise security team is likely to test, and ends with a complete, free scope-of-work template you can copy directly into your next procurement cycle.

What is a penetration testing scope?

A penetration testing scope is the documented agreement describing what gets tested, how it gets tested, and what the enterprise receives at the end. It covers testing objectives, systems and assets, environments, user roles, attack perspectives, techniques, restrictions, dates, communications, deliverables and retesting. Scope answers three fundamental questions: what must be tested, what may testers do, and what evidence must the enterprise receive.

NIST SP 800-115 provides the technical guide most enterprise security teams reference when planning and conducting these assessments, and its rules-of-engagement concept covers the detailed permissions and constraints established before a security test begins. Synack’s enterprise penetration testing services cover internal and external targets across web, mobile, host, API, and AI applications, which is exactly the range a modern scope document needs to account for.

Start with the objective, not the asset count

An enterprise cannot define a useful scope without knowing why the test is being conducted. That objective might be validating a customer-facing application before release, meeting PCI DSS testing requirements, supporting SOC 2 control evidence, assessing a cloud migration, testing a newly acquired environment, evaluating a critical supplier, or establishing a continuous testing program. Each of those objectives shapes test type, depth, tester expertise, environment, deliverables, timeline and retesting differently.

The table below shows how a simple worksheet can force this thinking before anyone drafts an asset list.

Scoping question	Example answer
Why is testing required?	Validate a new enterprise SaaS platform before launch
What risk matters most?	Cross-tenant access and administrative compromise
Who will use the results?	Security, engineering, executives, and SOC 2 auditors
What decision will the test support?	Production launch approval
What evidence is required?	Technical findings, executive report and retest evidence
What deadline applies?	Four weeks before general availability

Filling this worksheet out with real answers, rather than generic ones, gives the rest of the scoping process a clear target. When the driver is compliance-led, penetration testing for compliance becomes a useful reference point, since audit evidence has its own reporting requirements that a generic scope document often misses.

Define the system boundary

The system boundary identifies the technology, data flows and trust relationships relevant to the objective. Gathering it means pulling together architecture diagrams, data-flow diagrams, asset inventories, cloud accounts, domains and subdomains, IP ranges, application components, APIs, mobile applications, identity providers, administrative systems, third-party integrations, security controls, network connections and environments. Enterprises with large or fast-changing footprints often lean on asset discovery tooling to keep this boundary current rather than rebuilding it by hand for every engagement.

A useful boundary exercise asks where sensitive data enters, where it gets processed, where it gets stored, which systems can access it, which systems administer the environment, which identities carry elevated privileges, which third parties connect to it, and which assets could provide an indirect attack path. A system can be relevant to the boundary without directly storing sensitive data at all. Identity providers, domain controllers, jump servers, CI/CD systems, cloud control planes, secrets managers, monitoring systems, administrative portals, and support tools all fall into this category, since compromising any one of them can open a path to the systems that do hold sensitive data.

Create the penetration testing asset inventory

Separating assets by type produces a far more useful inventory than one undifferentiated list of URLs and IP addresses. Each asset type carries its own scoping questions, and skipping that separation is one of the fastest ways to end up with a scope that looks complete but leaves gaps a vendor never flagged.

Web applications need a record of application name, production URL, staging URL, supporting domains, technology stack, hosting model, authentication method, user roles, administrative interfaces, sensitive workflows, and third-party components. APIs need base URLs, API version, documentation, authentication method, test credentials, user or service roles, rate limits, webhooks, partner integrations, and both production and test endpoints listed separately. The OWASP API Security Top 10 is a useful reference here, since it catalogs the access-control and authorization risks that make API inventories worth building separately from the rest of the application.

External infrastructure requires public IP addresses, CIDR ranges, domains, VPNs, remote-access services, email services, firewalls, exposed cloud resources and ownership verification. Internal infrastructure needs network ranges, segments, Active Directory domains, the agreed test entry point, user accounts, privileged accounts, critical systems, segmentation boundaries and restricted systems. Cloud environments need the provider, account or subscription identifier, regions, workloads, identity roles, public services, storage, containers, Kubernetes clusters, serverless services, control-plane access and any testing-policy restrictions the provider enforces.

Mobile applications need operating system, application version, build source, supporting APIs, test accounts, authentication method, deep links, local data storage, and device requirements. AI and LLM applications need the model or provider, user interface, APIs, retrieval systems, data sources, tools or agents, permissions, user roles, sensitive-data handling, external integrations, and logging and retention practices. These assets typically need AI-specific penetration testing rather than a standard web application methodology, since agent behavior and tool-calling chains do not map cleanly onto a traditional asset record. Recording each category separately makes it far easier to spot the asset type a draft scope has quietly left out.

Scope applications by functionality, not URL count

A single application URL can contain many distinct attack surfaces, so scope should identify public functionality, authenticated functionality, and the full range of roles that touch it: standard users, privileged users, administrators, support agents, tenant administrators, internal employees and partner roles. It should also name specific workflows, including anonymous journeys, password resets, account recovery, file handling, payment or checkout processes, data exports, reporting, user invitations, access provisioning and administrative configuration.

A role matrix makes this concrete and gives both sides of the engagement a shared reference point.

Role	Credentials supplied?	Main permissions	Included in testing?
Anonymous visitor	Not applicable	Public functions	Yes
Standard user	Yes	Own account and records	Yes
Manager	Yes	Team-level access	Yes
Tenant administrator	Yes	Tenant configuration	Yes
Platform administrator	Controlled access	Cross-tenant administration	Limited
Support user	Yes	Customer support workflows	Yes

Several accounts are usually needed for horizontal access-control testing, cross-tenant testing, invitation workflows, user-to-user interaction, privilege escalation and shared resources. A test running on a single account cannot reliably evaluate every authorization boundary an application actually exposes, which is one reason enterprises with frequent releases often move role coverage into ongoing role-based testing programs rather than re-negotiating account access for every engagement.

Should you test production or staging?

There is no universally correct answer here, and a scope that assumes one environment is always superior tends to create disputes later. Production reflects the real environment, includes real integrations and controls, and reveals production-specific configuration, but it requires tighter rules of engagement and may expose sensitive information. Staging reduces operational risk and allows broader or more aggressive testing, but it may differ from the live deployment and lack realistic data and traffic.

Production	Staging
Reflects the real environment	Reduces operational risk
Includes real integrations and controls	Allows broader or more aggressive testing
Reveals production-specific configuration	May differ from live deployment
Requires tighter rules of engagement	May lack realistic data and traffic
May expose sensitive information	Easier to reset and isolate

Production testing makes sense when production differs materially from staging, when real authentication and integrations need validation, when the application is already live, when compliance evidence must represent the production environment, and when safety controls permit meaningful testing. 

Staging testing makes sense when destructive or invasive techniques are needed, when production availability is highly sensitive, when suitable production test data cannot be created, or when the staging environment accurately mirrors production. 

Many enterprises land on a hybrid approach: broad and invasive testing in a production-equivalent environment, carefully controlled validation in production, and a separate review of production-specific configuration. Synack’s production-safe testing engagements are built around exactly this kind of tiered approach. Document every environmental difference and its impact on assurance, and never assume a staging test automatically represents production.

Define the testing perspective

Scope must state where the tester begins and what knowledge or access they receive; labels alone are not enough. The scope should say exactly what testers get.

Black-box testing

The tester receives limited information and approaches the target as an external attacker would. This perspective works well for external exposure, discovery and unauthenticated attack paths, though testers can spend real time rediscovering information the organization already has on hand.

Grey-box testing

The tester receives selected information, credentials or architecture context. Grey-box testing suits authenticated applications, APIs, cloud environments and efficient enterprise assessments where full discovery time would be wasted effort.

White-box testing

The tester receives extensive technical access or knowledge, which may include source code, architecture diagrams, administrative credentials, cloud permissions and configuration information. This perspective delivers deeper coverage under a limited testing window, since testers spend less time mapping the environment and more time testing it. Enterprises running regulated testing engagements often default to grey-box or white-box access, since auditors generally want evidence that meaningful depth was achieved rather than a black-box discovery exercise alone.

Balance breadth and depth

Every scope sits somewhere on a triangle of asset count, testing depth and available time or capacity, and a fixed engagement cannot increase all three indefinitely. A broad but shallow scope covers many assets, checks common vulnerability classes, and offers limited authenticated analysis or attack chaining. This is roughly where automated vulnerability scanning and penetration testing start to diverge, since a scan can cover breadth quickly but cannot replicate what a human tester finds by chaining low-severity issues together.

A narrow but deep scope focuses on one critical application, multiple roles, APIs, business logic, attack chaining, and detailed remediation evidence. An ongoing program mixes broad discovery with prioritized deep testing, continuous or repeated coverage, and retesting after changes ship.

Before signing off on a scope, ask the provider how much active testing each asset will actually receive, how many user roles are included, whether APIs are tested separately, whether business logic is in scope, whether low-severity issues can be chained together, and what happens if discovery reveals more assets than the original inventory listed. A wider scope can paradoxically reduce assurance if the testing capacity behind it stays fixed.

Define permitted testing techniques

The scope should state which activities are authorized, and there is no single universal list. Potentially permitted activities include network discovery, service enumeration, authenticated testing, controlled exploitation, privilege escalation, lateral movement, password spraying within approved limits, file upload testing, API manipulation, access-control testing, cloud permission testing, segmentation testing and AI prompt and tool testing. The OWASP Web Security Testing Guide documents many of these techniques in detail and is a reasonable baseline for enterprises drafting their first permitted-techniques list.

Potentially prohibited or separately approved activities include denial-of-service testing, destructive data modification, unrestricted brute force, malware deployment, persistence, uncontrolled data exfiltration, physical intrusion, social engineering, testing third-party systems, and testing assets outside the approved environment. The right list for any given engagement depends on business risk, environment, test objective, regulatory constraints, and asset-owner approval, which is why copying another company’s permitted-techniques list rarely fits.

Create the rules of engagement

The rules of engagement convert the approved scope into operating instructions. NIST defines rules of engagement as the detailed guidelines and constraints established before a test, providing authority for defined activities without requiring new permission for each individual action.

A complete set of rules of engagement covers the authorizing organization, asset owner, testing provider, in-scope assets, testing window, permitted and prohibited techniques, test accounts, source IP addresses, rate limits, data-handling requirements, communication channels, critical-finding escalation, emergency contacts, stop conditions, test resumption authority, evidence requirements, and any legal or third-party restrictions. 

Enterprises running frequent engagements often manage this through centralized rules-of-engagement management rather than rewriting the document from scratch each time. Stop conditions typically cover service instability, unexpected access to sensitive production data, patient-safety or critical-infrastructure risk, impact outside the authorized scope, detection of active compromise, an unexpected third-party dependency, or a direct request from an authorized stakeholder.

“Do not disrupt production” is not a complete safety instruction on its own. The rules need to define what disruption actually means, who decides that it has occurred, and how testing gets stopped once someone makes that call.

Define communications and critical-finding escalation

The scope should identify a primary security contact, secondary contact, engineering contact, executive escalation contact, vendor contact, after-hours contact and the approved communication channels for each. Critical-finding expectations should specify which severity triggers immediate escalation, how quickly notification should occur, the minimum evidence required, whether testing pauses when a critical finding surfaces, who authorizes continued exploitation, and whether incident response gets activated.

Nobody should learn about a confirmed critical vulnerability for the first time when the final report lands. That expectation belongs in the scope document itself, not in an assumption either side made and never wrote down, and it becomes even more important where testing feeds into compliance-grade escalation records that an auditor will eventually review.

Define data handling

Penetration testing evidence can include credentials, tokens, screenshots, personal information, customer data, source details, architecture information, exploit evidence and documentation of unpatched vulnerabilities. That is a meaningful amount of sensitive material moving between two organisations, which is why data handling needs its own section rather than a single throwaway line.

The scope or associated agreement should define what data testers may access, what they may retain, whether evidence can be downloaded, encryption requirements, storage location, named access, redaction practices, retention period, secure deletion requirements, incident procedures, AI data use, model-provider access, and any restrictions on real production data. AI-focused engagements need particularly clear AI data-handling controls, since agent transcripts and tool-calling logs can carry sensitive information that a standard web application report never touches. For regulated environments, legal, privacy, compliance, data owners, and vendor management should all have a say in this section before it gets finalized.

Define deliverables before testing starts

Require the vendor to specify the complete output up front, not partway through the engagement. Live or interim deliverables typically include critical-finding notifications, live finding access, testing-status updates, coverage updates and scope-change notifications. The technical report should cover objective, scope, dates, methodology, assets tested, roles tested, exclusions, findings, evidence, reproduction steps, severity, business impact, remediation guidance and testing limitations, while the executive report distills that into material exposure, critical findings, business impact, coverage summary, risk themes and remediation priorities.

Where a compliance driver applies, the compliance report needs framework mapping, tester qualification information, independence statements, scope and dates, remediation status, retest evidence and audit-ready exports. Synack’s audit-ready penetration testing reports are built around exactly this kind of documented evidence, which matters most once an auditor starts asking where a finding came from and how it was closed. The retest report should carry a finding identifier, original evidence, remediation status, retest date, retest result, residual risk and closure evidence, so a finding’s full lifecycle stays traceable from discovery to closure.

Include remediation and retesting in the scope

The scope should define what happens after the report lands, not just what happens during active testing. Specify whether remediation advice is included, whether developers can communicate directly with testers, ticketing-system integration, number of retests, retest deadline, the failed-retest process, patch verification, reopened findings, updated reports and closure evidence.

A retest confirms whether a known finding was actually corrected. A new penetration test searches for broader or newly introduced weaknesses. Those are two different activities, and a contract that treats them interchangeably tends to leave one side disappointed about what they paid for.

Plan for newly discovered assets and scope changes

Enterprise environments rarely stay static for the full duration of a testing engagement. A new subdomain gets discovered, an undocumented API surfaces, an IP address changes, a new cloud workload deploys, an application version updates, an acquisition adds assets, a critical dependency comes to light, or testing itself reveals an indirect attack path nobody had mapped.

Possible approaches include automatically including assets that meet predefined criteria, pausing to request approval, using a reserved testing allowance, replacing lower-priority assets, creating a formal change order, or queuing newly found assets for a future test. Synack’s penetration testing platform uses AI-assisted scoping to evaluate asset reachability, firewall blockage, and discovered login pages before launch, and its cloud integrations can update asset inventories as cloud IPs get added or removed. That kind of dynamic scoping helps close gaps a static asset list misses, though the enterprise still needs a defined process for approving what gets added.

How to scope AI penetration testing

AI and LLM applications need their own scoping section, since the assets involved, the permitted actions, and the escalation paths all differ from a standard web application. The scope should define which assets the AI may access, which credentials it may use, permitted and prohibited attack actions, exploitation depth, data-access restrictions, stop controls, action logging, human escalation, human validation, reporting accountability, and retesting.

Before approving an AI-focused engagement, ask whether the AI can discover related assets, whether discovery automatically expands the testing scope, who approves discovered assets, whether authenticated workflows and multiple user roles are included, whether APIs are tested, whether controlled exploitation is permitted, how unsafe actions get prevented, whether the test can be stopped immediately, whether all actions are logged, which findings receive human validation, and who attests to the final report.

Sara AI Pentesting can map external web and host assets from known seed assets, support automated scoping, and launch testing across approved targets, and human researchers from the Synack Red Team then validate the findings that represent real, exploitable risk. Synack’s documented Sara workflow moves from attack-surface mapping into autonomous scoping and test launch, with human validation built into the process rather than added as an afterthought.

Common penetration testing scoping mistakes

A handful of mistakes show up in nearly every rushed scope document, and most of them are easy to avoid once you know to look for them. Scoping only by URL or IP count ignores roles, APIs, functions, integrations, and attack perspectives entirely. Assuming APIs are automatically included is a costly assumption, since many providers scope APIs separately and price them separately too.

Providing only one user account prevents meaningful horizontal and cross-tenant access testing. Testing staging without comparing it against production means the result may not represent the live environment at all. Including too many assets for the available testing capacity leaves coverage thin and checkbox-shaped rather than genuinely thorough, and excluding administrative functionality is particularly risky, since the highest-impact attack paths often sit inside privileged workflows.

Omitting third-party restrictions can lead a test to accidentally touch infrastructure the enterprise does not own. Using vague safety language, such as “do not break anything,” fails to define rate limits, stop conditions or prohibited techniques. Failing to define retesting leaves the enterprise holding findings with no clear route to verified closure, and treating automated discovery as automatic authorisation ignores the fact that discovered assets still need ownership verification. Freezing scope too early stops the test from adapting when relevant attack paths appear, and leaving deliverables until the end almost guarantees the provider and the customer walk in with very different definitions of a complete report.

How scope affects penetration testing price

Cost gets influenced by asset count, asset complexity, number of user roles, API size, testing depth, environment count, cloud scope, internal access, compliance requirements, testing duration, specialist skills, reporting and retesting, and whether the engagement includes continuous coverage. There is no single universal price for an enterprise penetration test, which is exactly why buyers need to compare proposals using identical assumptions rather than comparing dollar figures alone.

Scope element	Vendor A	Vendor B	Vendor C
Web applications
APIs
Authenticated roles
Cloud testing
Internal testing
Active testing duration
Reports
Retesting
Platform fees
Additional asset cost

Filling this worksheet out for every vendor on a shortlist tends to surface the differences a quote comparison alone would hide. Synack’s penetration testing pricing page explains how methodology, duration, and asset count shape the commercial scope of an engagement, and that same logic applies regardless of which vendor an enterprise ultimately selects.

How Synack supports enterprise pentest scoping

Synack’s platform combines AI-assisted asset scoping with reachability and firewall checks, identification of login pages, and external attack-surface discovery, covering web, API, mobile, host and AI application types alongside traditional human-led testing. That AI-enabled scoping process helps customers launch testing through a self-service workflow while assessing asset reachability, firewall blockage and discovered login pages before the engagement begins.

Synack’s penetration testing as a service combines the Synack Red Team with a platform for asset management, findings, reports, and analytics across web applications, APIs, hosts, and other targets, supporting both on-demand and continuous testing programs. This is not a claim that AI scoping replaces enterprise approval or that Synack guarantees complete attack-surface coverage. It helps streamline scoping, identify reachable assets, support dynamic enterprise environments, combine AI-assisted scoping with human expertise, support point-in-time and continuous programs, and provide validated findings and retesting workflows.

Scope your next penetration test around the risks that actually matter.

Get a personalized walkthrough of Synack’s AI-assisted scoping, Sara AI Pentesting, Synack Red Team testing, and enterprise reporting workflows. Request a Demo

Free penetration testing scope-of-work template

Copy the sections below directly into your next enterprise engagement. Every field is meant to be filled in and adjusted for the specific application, environment, or program being tested.

1. Engagement overview

Start the template by recording the core facts of the engagement, since every other section builds on this baseline information. 

Organization: [Organization name]
Engagement name: [Application, environment or program name]
Testing objective: [Describe what the test must evaluate or prove]
Business or compliance driver: [Release, audit, risk assessment, significant change or other driver]
Testing provider: [Provider name]
Target start date: [Date]
Target completion date: [Date]
Report deadline: [Date]

With the engagement details captured, the next section defines which test types and testing perspectives apply. 

Here’s the full template, sections 2 through 18, each with a prose lead-in and closing sentence, all in US English.

1. Test type

Identify every test type the engagement covers, since a scope that leaves this ambiguous tends to produce a mismatched quote later.

Select all that apply: external network penetration test, internal network penetration test, web application penetration test, API penetration test, mobile application penetration test, cloud penetration test, wireless penetration test, segmentation test, AI or LLM application penetration test, social engineering assessment, red-team assessment, or other [describe].

Once the test types are confirmed, the next section defines the perspective testers will operate from.

1. Testing perspective

Testing perspective determines how much the tester already knows going in, which directly shapes both cost and depth.

Select all that apply: black box, grey box, white box, authenticated, unauthenticated, internal attacker, external attacker, privileged insider, or other [describe].

Information supplied to testers: [Credentials, architecture, source code, API documentation, cloud roles or other information]

With the perspective set, the template moves into the actual asset inventory.

1. In-scope assets

List every asset the engagement will touch, broken out individually rather than folded into a single line item.

Asset ID	Asset type	URL, IP, account or identifier	Environment	Owner	Notes
1	Web application	Production
2	API	Production
3	Cloud account	Production
4	Internal network	Corporate

Add rows as needed for larger environments, since a short table here almost always undercounts the real footprint.

1. Application user roles

Application roles need their own table, since a scope that only names “authenticated users” tends to leave privileged and administrative paths untested.

Role	Number of accounts	Main permissions	Included workflows
Anonymous	N/A	Public access
Standard user	2	User-level access
Manager	2	Team-level access
Tenant administrator	1	Tenant configuration
Platform administrator	1	Global administration

Confirm each role actually has a working test account before testing starts, not after.

1. Critical workflows

Name the specific business processes that need dedicated attention, rather than relying on the asset and role lists to cover them implicitly.

List business processes requiring specific testing: authentication, password reset, account recovery, user registration, user invitations, role changes, tenant separation, administrative access, file uploads, data exports, payments, API access, support workflows, or other [describe].

These workflows often cut across multiple roles and assets, so cross-check this list against sections 4 and 5 before finalizing the scope.

1. Supporting integrations

Third-party integrations extend the attack surface well past the core application, so they need their own record of what’s included and what isn’t.

Integration	Purpose	Data exchanged	Included in scope?	Owner approval
Identity provider	Authentication	Identity claims	Yes
Payment provider	Payments	Payment data	Limited
CRM	Customer records	Customer data	No

Any integration marked “no” or “limited” should have a documented reason, since silent exclusions are a common source of scope disputes.

1. Permitted testing activities

Spell out exactly which techniques testers may use, since a vague permission tends to get interpreted differently by each side.

Asset discovery, service enumeration, authenticated testing, controlled exploitation, privilege escalation, lateral movement, access-control testing, API manipulation, file upload testing, cloud permission testing, segmentation testing, or other [describe].

Pair this list directly with the prohibited activities in the next section so testers have a complete picture of the boundary.

1. Prohibited or restricted activities

Just as important as what’s allowed is what’s explicitly off-limits, and this list should be treated as non-negotiable during testing.

Denial-of-service testing, destructive data modification, unrestricted brute forcing, malware deployment, persistence, uncontrolled data exfiltration, social engineering, physical testing, testing third-party assets, or other [describe].

Any activity not listed as permitted or prohibited should default to requiring explicit approval before a tester attempts it.

1. Rules of engagement

The rules of engagement turn the scope into day-to-day operating instructions, and they need enough detail that nobody has to improvise mid-test.

Approved testing window: [Dates and times]
Approved testing source addresses: [IP addresses]
Rate limits: [Requests, login attempts or other restrictions]
Test accounts: [Account-management process]
Sensitive-data restrictions: [Instructions]
Production safety requirements: [Instructions]
Stop conditions: [List conditions]
Authority to stop testing: [Names or roles]
Authority to resume testing: [Names or roles]

Every field here should have a named owner, not a department, so there’s no ambiguity about who makes the call during an active test.

1. Communication and escalation

Communication channels and escalation paths need to be agreed before testing starts, especially for anything that might qualify as a critical finding.

Primary security contact: [Name, role, contact]
Backup contact: [Name, role, contact]
Engineering contact: [Name, role, contact]
After-hours contact: [Name, role, contact]
Critical-finding notification method: [Method]
Critical-finding notification SLA: [Time]

Test these contact details before the engagement kicks off, since an outdated phone number discovered mid-crisis defeats the purpose of this section entirely.

1. Data handling

Data handling deserves explicit terms, since testing evidence can include credentials, personal information, and other sensitive material that outlives the engagement itself.

Approved evidence storage: [Location]
Encryption requirements: [Requirements]
Who may access evidence: [Roles or named individuals]
Retention period: [Period]
Secure deletion requirements: [Requirements]
AI data-use restrictions: [Requirements]
Regulated-data requirements: [Requirements]

Loop in legal, privacy or compliance stakeholders here if the environment touches regulated data, since this section is where those obligations get documented.

1. Deliverables

Confirm the full set of deliverables up front, so there’s no confusion at the end of the engagement about what “done” actually means.

Live critical-finding notifications, live or interim findings, technical penetration testing report, executive summary, compliance report, asset and coverage summary, remediation guidance, retest report, updated final report, raw evidence where approved, or other [describe].

Match each deliverable against the objective from section 1 to confirm the evidence will actually support the decision the test is meant to inform.

1. Retesting

Retesting terms belong in the original agreement, not negotiated after the first report lands.

Number of included retests: [Number]
Retest request window: [Period]
Expected retest turnaround: [Period]
Failed-retest process: [Describe]
Updated report included: [Yes or no]

Clarify whether a failed retest counts against the included total, since this detail affects both cost and timeline planning.

1. Scope-change process

Enterprise environments change during testing more often than not, so this section defines how new assets or findings get folded into the engagement.

Define how discovered assets are handled, who approves additional assets, whether assets may be substituted, the commercial impact, the testing-capacity impact, and documentation requirements.

Scope-change approver: [Name or role]

Route every scope change through this approver, even minor ones, to keep the audit trail clean for compliance purposes.

1. Exclusions and assumptions

Document what’s explicitly out of scope and what the provider is assuming, since unstated assumptions are one of the most common sources of post-engagement disputes.

Explicit exclusions: [List]
Known limitations: [List]
Customer dependencies: [List]
Provider assumptions: [List]

Review this section with the provider directly rather than assuming both sides read it the same way.

1. Acceptance criteria

Acceptance criteria define when the engagement is considered complete, which protects both sides from an open-ended close-out process.

The engagement is complete when agreed assets have been tested, agreed roles and workflows have been assessed, scope changes have been documented, critical findings have been escalated, required reports have been delivered, testing limitations have been documented, retesting obligations have been completed or scheduled, and evidence has been transferred or retained according to the agreement.

Sign off against this list explicitly rather than treating report delivery alone as the finish line.

1. Approval

The final section captures formal sign-off from everyone with a stake in the engagement before testing begins.

Security owner: [Name, signature and date]
System owner: [Name, signature and date]
Testing provider: [Name, signature and date]
Legal or compliance approval, where required: [Name, signature and date]

Once all approvals are in place, the scope-of-work document is ready to move into scheduling and kickoff.

Penetration testing scoping checklist

Use this checklist alongside the template above to confirm nothing got missed before a scope goes final.

Under objective, confirm you have defined why the test is required, identified the decision it must support, confirmed compliance or audit requirements, identified the required evidence, and set the deadline. Under assets, confirm asset ownership and list applications, APIs, infrastructure, cloud environments, mobile applications, AI systems, and relevant integrations.

Under access, define the attack perspective, provide appropriate user roles, provide multiple test accounts, supply API documentation, supply architecture context where appropriate, and define privileged access. Under safety, create rules of engagement, define permitted and prohibited techniques, establish rate limits and stop conditions, confirm emergency contacts, and address sensitive-data handling.

Under deliverables, define critical escalation, require technical evidence, require executive reporting, define compliance reporting, include remediation guidance and retesting, and define closure evidence. Under commercial scope, confirm testing duration, included assets, reporting fees, retest fees, scope-change fees, platform costs, and that you are comparing equivalent vendor assumptions across every proposal on your shortlist.

Conclusion

Scoping an enterprise penetration test well means defining the outcome, mapping the system boundary, inventorying assets by type, including roles and workflows, selecting the testing perspective, balancing breadth and depth, establishing rules of engagement, protecting sensitive data and production availability, defining reports and retesting, and creating a controlled process for scope changes. Get those ten pieces right, and two vendors quoting the same application will finally be quoting the same thing.

A well-scoped test gives security teams more than findings. It provides confidence that the right systems, attack paths, and business risks were actually evaluated. See how Synack combines AI-assisted scoping, Sara AI Pentesting and human expertise from the Synack Red Team to launch and manage enterprise security testing at scale.

Request a Demo

This article is for informational purposes only and does not constitute legal advice.