A penetration test is only as useful as its scope. Defining pentest scope means agreeing in writing on what the testers may attack, what they may not touch, when they may work, how they will behave and what you will receive at the end. Get those five things right and the test produces findings you can act on. Get them wrong and you pay for a report that misses your riskiest systems or, worse, knocks over a production server on a Tuesday afternoon.
This guide walks managing partners, IT directors and compliance leads through the scoping decisions in the order they come up. It also covers the rules of engagement, the document that turns a scope into something both sides can sign.
TL;DR
- Scope is a written list of in-scope targets, explicit exclusions, test windows, permitted techniques and deliverables. If it is not written down, it is not agreed.
- The rules of engagement (ROE) and a signed authorization letter protect both you and the testers. Third-party and cloud assets need their own permission.
- Start from your sensitive data and your compliance obligations, not from a list of IP addresses.
- Grey-box testing usually gives regulated organizations more value per dollar than pure black-box testing.
- Agree on escalation of critical findings and on a retest before the test starts.
Table of Contents
- What scope and rules of engagement actually are
- Start with business risk, not with an IP list
- Choosing what goes in scope
- Write the exclusions as carefully as the targets
- Authorization and third-party permission
- Choose the testing approach: black, grey or white box
- Set the timing, communication and conduct rules
- Agree on deliverables and retesting up front
- A short worked example
- Common scoping mistakes
- Our perspective on scoping
- Get help scoping your next test
- FAQ
- Sources
What scope and rules of engagement actually are
People use "scope" and "rules of engagement" interchangeably, but they do different jobs.
Scope answers what is being tested: networks, applications, APIs, cloud tenants, user roles, physical locations, people (for social engineering). It also says what is excluded.
Rules of engagement answer how the testing is conducted. NIST's glossary describes the rules of engagement as detailed guidelines and constraints set before a security test begins, which give the test team the authority to carry out defined activities. NIST SP 800-115 includes a template for the ROE in its appendices, which is a sensible starting outline if you have never written one.
CISA's penetration testing service description says the same thing in plain terms: a rules of engagement document is drafted and signed by both parties, and it describes the scope of the engagement. In practice, one signed document often covers both.
Start with business risk, not with an IP list
The most common scoping mistake is starting from whatever inventory is easiest to export. Start from the questions a partner or board member would ask after a breach.
- What data would hurt us most if it left? For a law firm, that is privileged client files, matter management systems and document stores. For an oil and gas operator, it may be operational technology data, lease and bid information, and financial systems. For a healthcare-adjacent business, it is protected health information.
- Which systems touch that data? Trace the path: the user, the login, the application, the database, the backup, the vendor integration.
- Which obligations apply? SOC 2, HIPAA, PCI DSS and CMMC each shape what must be tested and how often. If you process card payments, our guide to PCI penetration test requirements explains how the cardholder data environment drives scope, and our PCI DSS readiness roadmap shows why confirming scope comes first.
- What changed recently? New cloud workloads, a merger, a client portal launch or a new remote access method all belong in scope more than a firewall that has not changed in three years.
The output is a ranked list of crown-jewel systems. Everything else in the scope document is built around it.
Choosing what goes in scope
CISA's guidance lists standard practices that distinguish in-scope targets, such as specific IP ranges, domains and APIs, from explicit exclusions. A workable scope table looks like this:
| Element | What to write down | Example |
|---|---|---|
| External network | IP ranges and domains, confirmed as owned by you | Public IP block, client portal domain |
| Internal network | Subnets, VLANs, and where the tester connects from | Corporate VLAN, remote tester VPN |
| Web applications | URLs, environments, user roles | Matter portal, staging excluded |
| APIs | Base URLs, documentation, authentication method | Mobile app API |
| Cloud | Accounts, subscriptions, regions | Production tenant only |
| People | Whether phishing or phone pretexting is allowed, and who is targeted | Email phishing of a named pilot group |
| Physical | Which offices, which hours | Houston office, business hours |
Two habits keep this table honest. First, write every target as something a tool can be pointed at: an address, a hostname, an account ID. "Our website" is not a target. Second, have someone other than the author verify ownership. Testing an address you do not control, such as an IP block still registered to a previous hosting provider, creates legal exposure for everyone.
Do not forget user roles
For application testing, scope includes who the tester logs in as. OWASP's DevSecOps guidance recommends providing at least two user accounts per role, so the tester can check whether one user can reach another's data. For a law firm, that is the difference between knowing the login page is solid and knowing that an associate on Matter A cannot open Matter B behind an ethical wall.
Write the exclusions as carefully as the targets
Exclusions are where operational risk lives. Typical entries:
- Fragile legacy systems. Old file servers, unpatched appliances and industrial controllers can fail under routine scanning. Exclude them, or test them only in a lab copy or a supervised window.
- Safety-related operational technology. For energy operators, any system tied to physical processes needs a separate conversation with operations staff before anything is touched.
- Third-party infrastructure. Your SaaS vendors, payment processor and managed service provider have not agreed to be tested because you hired a tester.
- Denial-of-service techniques. Unless you specifically want to test resilience, rule these out in writing.
- Real data destruction or exfiltration. Agree that testers prove access with a harmless marker file or a screenshot, not by copying client files.
CISA's description of standard practice notes that testing should be coordinated with the customer so operations continue. An exclusion list is how that coordination becomes enforceable.
Authorization and third-party permission
Before any active testing, an authorized executive must sign a letter that gives the testers legal authority to do what the scope describes. Testers often call it a "get out of jail free" letter. It should name the testers, the dates, the targets and the signer's authority to approve testing on those assets.
The signer matters. An IT manager may not have the authority to approve testing of a hosted platform that the firm leases rather than owns. Check contracts as well: some hosting and software agreements restrict security testing.
Cloud providers publish their own rules. Microsoft, for example, maintains security testing rules of engagement for its online assets, which spell out what customers and researchers may and may not do. Read the current rules for each provider hosting in-scope systems and cite them in your scope document. Where a provider requires notice or approval, get it before the testing window opens. If you want more on this topic, see our guide to cloud pentesting with audit-ready evidence.
Choose the testing approach: black, grey or white box
The knowledge you give the testers changes both cost and value. OWASP's table of test types describes black-box testing as an external attacker simulation with no prior knowledge, suited to assessing your external perimeter as an unauthenticated attacker would see it. Grey-box testing gives partial knowledge, such as credentials.
| Approach | What testers receive | Best for | Trade-off |
|---|---|---|---|
| Black-box | Nothing beyond the target name | Realistic view of the external perimeter | More hours spent on reconnaissance |
| Grey-box | Credentials, architecture diagrams | Business logic, authorization, high-value data paths | Less "realistic" as an attacker simulation |
| White-box | Source code, full documentation | Deep review of a critical application | Highest preparation effort |
Black-box requests are common because they sound realistic. For most regulated organizations, though, a fixed budget buys more insight when testers skip the guesswork and go straight to the paths that lead to sensitive data. Grey-box testing is typically the better default for a client portal, a matter system or a billing platform. Keep black-box for the external perimeter, where an unauthenticated view is the point.
Pentest or vulnerability scan?
Before you scope, confirm you need a penetration test at all. A scan finds known weaknesses automatically. A pentest has a human attempt to chain weaknesses into real access. This explanation of vulnerability assessment versus penetration testing helps decide which fits your goal, and many programs use both: scans continuously, pentests on a defined cycle. Our overview of vulnerability scanning for IT teams covers the scanning side.
Set the timing, communication and conduct rules
This is the core of the rules of engagement. SANS publishes a rules of engagement worksheet that walks a tester and client through the questions in order, and it warns that a poorly formed set of rules yields a low-value test at best. Whatever template you use, cover these points.
- Testing windows. Dates and hours, with time zone. Many firms permit external testing at any hour but restrict internal or authenticated testing to off-peak periods. Avoid month-end billing close, court filing deadlines, turn-arounds, or planned maintenance.
- Source addresses. The IP addresses testers will use, so your security monitoring can tell the test from a real attack.
- Points of contact. A named technical contact on each side, reachable during testing, with a backup. CISA's guidance stresses ongoing communication with the customer's technical point of contact.
- Stop conditions. What triggers an immediate pause: a system slowing down, a service outage, discovery of data that should not be seen.
- Escalation of critical findings. Define "critical" and say how fast testers must tell you. A remotely exploitable flaw on an internet-facing server should not wait for the final report.
- Data handling. Where test data and screenshots are stored, who can read them, how long they are kept and how they are destroyed. For law firms this is a confidentiality obligation, not a formality.
- Detection posture. Decide whether your security team is told in advance. Telling them is simpler. Not telling them tests detection and response but needs a trusted party who can call off an escalated incident response.
- Social engineering limits. Which staff, which methods, and what happens when an employee falls for it. Agree that results are reported by role, not used to discipline individuals.
If AI-assisted tools are part of the testing, add rules for them too. Our piece on guardrails for vCISO-managed AI penetration testing covers what to put in writing, and the approach to continuous penetration testing shows how scope changes when testing is ongoing rather than annual.
Agree on deliverables and retesting up front
A pentest that ends with an unread report is a check-the-box exercise. Put the end of the engagement in the scope document:
- Report contents. Executive summary for leadership, technical detail for engineers, reproducible steps, severity ratings and remediation advice. See what audit-ready pentest reports contain.
- Format. Machine-readable output lets findings flow into your ticketing system; our article on pentest reporting that gets fixed explains one approach.
- Delivery date and readout. A live walkthrough with the people who must fix things.
- Retest. State whether remediation retesting is included, how many rounds, and within what period. Auditors and clients often ask for proof that critical findings were fixed, not just found.
- Evidence for auditors. If the test supports SOC 2, say so, so the report is written to be handed over. Our SOC 2 audit readiness guide shows how testing evidence maps to controls.
A short worked example
Imagine a 60-attorney Houston firm that wants a test before renewing its cyber insurance and answering a corporate client's security questionnaire.
- Crown jewels: the document management system, the client portal and email.
- In scope: the public IP range, the portal and its API, the firm's Microsoft 365 tenant (after reviewing the provider's testing rules), and the internal network from one conference-room jack.
- Excluded: the third-party billing SaaS, the building's access control system, and any denial-of-service testing.
- Approach: black-box on the external range, grey-box on the portal with two accounts for each role (attorney, paralegal, client).
- Window: external testing any time, internal testing after 7 p.m. Central, none during the last week of the month.
- Contacts: the IT director and the outsourced security lead, both on call.
- Escalation: critical findings reported within one business day.
- Deliverables: report, executive readout, one retest within 60 days.
That is one page. It is also enough for the testers to price the work accurately, which is the quiet benefit of good scoping: it reduces change orders and surprises.
Common scoping mistakes
- Scoping to what passes. Leaving out the messy system because you know it is weak defeats the purpose.
- Scoping too wide. Listing everything makes the test thin everywhere. Prioritize.
- Forgetting people and process. Many real breaches begin with a stolen credential or a convincing email, not a software flaw.
- Ignoring ownership. Shared hosting, contractor-managed networks and acquired subsidiaries blur who can authorize testing.
- No retest. Findings that are never verified as fixed stay on the risk register indefinitely.
- One scope, forever. Revisit scope after every significant change to systems, vendors or regulations.
Our perspective on scoping
We review a lot of scope documents, and the pattern is consistent: the weak ones describe technology, the strong ones describe risk. A scope that begins with "these are the matters, patient records or operational data we cannot afford to lose" almost always produces a better test than one that begins with a subnet list.
We also believe scoping is a leadership decision, not an IT chore. A managing partner or executive sponsor should sign the authorization, accept the exclusions and own the question of what happens to the findings. When that ownership is missing, the report ends up in a folder.
Our approach combines vCISO oversight with an AI-assisted platform that automates parts of testing, intake and reporting. We treat automation as a way to spend human time where it counts: on the business logic, authorization paths and judgment calls that decide whether a test finds something that matters. Scope is where that judgment starts, and it is why a vCISO should be in the room before the testers are.
— vCISO
Get help scoping your next test
If you are preparing a pentest for a law firm, an energy operator or another regulated organization, we can help you define the targets, exclusions and rules of engagement, line them up with the frameworks you answer to, and make sure the results feed a remediation plan. Our vCISO, risk assessment and audit readiness services are built for teams that need senior security leadership without a full-time hire.
FAQ
Who should sign off on the scope?
An executive with authority over every in-scope asset, such as a managing partner, CEO or COO, should sign alongside the testing provider. Your IT or security lead should review the technical details, but should not be the only approver. Third parties that host in-scope systems may need to approve separately.
How often should the scope be reviewed?
Review it before every test and after any major change to your environment, such as a cloud migration, new client portal, acquisition or vendor switch. Frameworks like PCI DSS and SOC 2 also expect testing on a recurring basis, so confirm your current obligations with your auditor.
Should we tell our IT staff about the test?
Usually yes, at least the people who approve changes and respond to alerts. Telling them avoids a real incident response for a planned activity. If you want to test detection, designate one trusted person who knows and can stop an escalation.
What is the difference between scope and rules of engagement?
Scope lists what may be tested and what is excluded. Rules of engagement describe how testing is done: timing, techniques, contacts, escalation and data handling. They are often written as one signed document.
Can a pentest cover third-party SaaS and cloud services?
Only with permission. Your authorization does not extend to assets another company runs, so check the provider's published testing rules and contract terms and obtain any required approval first.
Sources
- NIST SP 800-115, Technical Guide to Information Security Testing and Assessment
- NIST CSRC Glossary: Rules of Engagement
- CISA: Penetration Testing
- OWASP DevSecOps Guideline: Penetration Testing
- SANS Institute: Pen Test Rules of Engagement Worksheet
- Microsoft Security Testing Rules of Engagement