To scope a penetration test, decide in writing, before any testing starts, what the test must prove, which assets and environments it covers, who has the authority to permit testing of each asset, and the rules the testers work under: test accounts per role, allowed techniques, test windows, stop conditions and data handling. Those decisions set what the test can find. In Stingrai's 2026 dataset, broken access control and IDOR made up 17.8% of the 768 findings from 40 web application tests, and none of those flaws can be found without knowing what each role is supposed to be allowed to do (The State of Penetration Testing 2026).
This guide covers the decisions one at a time, with a default answer for each and the published rule behind it. It is not the contract: the penetration testing statement of work template turns these decisions into signed clauses, and the pentest and red team RFP question bank is for choosing the firm. The rules come from the documents testers and assessors cite: the Penetration Testing Execution Standard (PTES), NIST SP 800-115, the OWASP Web Security Testing Guide (WSTG), PCI DSS v4.0.1, and the current AWS, Microsoft and Google Cloud testing policies. A worked example near the end applies every decision to one SaaS product with a web app, its API, an AWS account and an LLM assistant.
The eight scoping decisions at a glance
Decision | Default answer | Where the rule comes from |
|---|---|---|
1. What must the test prove? | One written objective: audit evidence, a specific risk question, or both | PTES goals; PCI DSS v4.0.1 Requirement 11.4 for card data |
2. What is in scope? | Every asset by identifier, environment and count, plus an exclude list | PTES target definition; NIST SP 800-115 Appendix B |
3. Who can authorize each asset? | The owner of each asset, plus the provider wherever its policy requires | PTES third parties; AWS, Microsoft and Google Cloud policies |
4. Production or staging? | Decided per test type, never once for the whole engagement | NIST SP 800-115 section 6.3; PCI penetration testing guidance |
5. What access, and how many accounts? | Grey box, with at least two users per role and two tenants for multi-tenant products | OWASP WSTG-ATHZ-04 and WSTG-IDNT-01 |
6. Which techniques, when, and from where? | Written allowed and prohibited lists, windows with a time zone, declared source IPs | NIST SP 800-115 section 6.5; PTES rules of engagement |
7. When does testing stop? | Named triggers, who can stop the test, and the one person who can restart it | NIST SP 800-115 section 6.5 and Appendix B |
8. How is data handled? | Prove access without taking data; agreed storage, retention and destruction | NIST SP 800-115 section 7.4; PTES |
Scope, rules of engagement and statement of work: three questions
PTES draws the line in one sentence: "While the scope defines what will be tested, the rules of engagement defines how that testing is to occur." The statement of work answers a third question, what is being bought, and carries the commercial terms: deliverables, retest, acceptance criteria, schedule, price and change control.
Document | Question it answers | What it contains | Who signs |
|---|---|---|---|
Scope | What will be tested? | The objective, assets with identifiers and counts, environments, the exclude list | The asset owner and the testing firm |
Rules of engagement | How will testing happen? | Authorization, allowed and prohibited techniques, windows, source IPs, contacts, stop conditions, data handling | At minimum the test team leader and senior management (CSO, CISO or CIO), per NIST SP 800-115 Appendix B |
Statement of work | What is being bought? | Deliverables, retest terms, acceptance criteria, schedule, price, change control | The commercial signatories under the master agreement |
The three can live in one signed document. What matters is that each question is answered once and the answers agree, because contradictory terms spread across several documents are how the scoping failure documented below began.
NIST SP 800-115 places the scope and the rules of engagement in the planning phase of a penetration test, in which "rules are identified, management approval is finalized and documented, and testing goals are set", and "No actual testing occurs in this phase." Its Appendix B is a rules-of-engagement template with sections for scope, schedule, test site, incident handling, target systems, testing execution, data handling, reporting and a signature page.
Where does OWASP fit? The WSTG, whose current stable release is v4.2 with v5.0 still in development, defines what to test, down to individual test cases such as WSTG-ATHZ-04 for insecure direct object references. It does not publish a rules-of-engagement template: its methodology chapter points to PTES, whose first phase is pre-engagement interactions, and to NIST SP 800-115 for assessment planning. The penetration testing methodology guide explains what each of these standards governs.
Decision 1: What does the test have to prove?
Write one objective before anything else, because the objective decides depth, access and environment. PTES is direct about it: "Every penetration test should be goal-oriented."
Most objectives are one of two kinds, and many engagements need both:
Audit evidence. The framework sets the floor. For card data, PCI DSS v4.0.1 Requirement 11.4.1 requires a penetration testing methodology that covers the entire cardholder data environment (CDE) perimeter and critical systems, tests from both inside and outside the network, tests any segmentation and scope-reduction controls, and includes application-layer and network-layer testing. Where segmentation isolates the CDE, Requirement 11.4.5 adds segmentation tests at least once every 12 months and after any change to segmentation controls, and Requirement 11.4.6 raises that to at least once every six months for service providers.
A risk question. Whether one customer can read another customer's invoices is a scope in itself. It tells the testers which roles, tenants and data paths matter, and when the work is done. The PCI Security Standards Council's penetration testing guidance makes the same point about success criteria: defining them "allows the entity to set limits on the depth of the penetration test."
A good objective fits in one sentence and names both, for example: produce penetration testing evidence for the SOC 2 Type 2 audit, and establish whether any customer role can read or change another customer's data.
Decision 2: What is in scope, by identifier and count?
List every asset by an identifier a tester can act on (a URL, hostname, IP range, API specification, cloud account ID or repository) and by the environment it lives in. PTES: "Before starting a penetration test, all targets must be identified." It also asks a question many scopes skip: "It is important to define if systems like firewalls and IDS/IPS or networking equipment that are between the tester and the final target are also part of the scope." A web application firewall or CDN in front of the application is either in scope or a declared blocker, never silently both.
Counts matter as much as names. The number of applications, API endpoints, user roles, hosts and cloud accounts is what effort and price are built on, which is why a scope written in adjectives produces a quote that changes mid-engagement.
Three more lines belong in this part of the scope:
An ownership check. PTES tells testers to "validate that they are in fact owned by the customer you are performing the test against" before attacking anything. Run the check yourself first: forgotten DNS records and inherited IP ranges are common.
The exclude list. NIST SP 800-115 Appendix B asks for authorized and unauthorized addresses and calls it "crucial to identify any system not authorized for testing", which it names the exclude list. Give each excluded system a reason, so the report can say why it was not tested.
Discovered assets. Decide in advance that assets found during testing are reported, not attacked, until someone with authority adds them to scope.
Decision 3: Who can authorize testing of each asset?
Authorization comes from whoever owns or controls each asset, and a client cannot grant it for infrastructure that belongs to someone else. PTES: "while permission may have been granted by the client, they do not speak for their third party providers. Thus, permission must be obtained from them as well in order to test the hosted systems." Microsoft states the same rule from the provider's side: third parties may test Azure resources only with explicit written authorization from the resource owner, and "Microsoft doesn't grant authorization on the customer's behalf."
What changes over time is what each provider requires, so read the provider's current page rather than an old standard. The PTES pre-engagement page, last edited in August 2014, still says Amazon has an online request form that "must be approved before scanning any hosts on their cloud". That is no longer AWS policy. The current rules:
Provider | Standard testing of your own resources | Gated or prohibited |
|---|---|---|
No prior approval for the 16 permitted services, which include EC2, RDS, Aurora, CloudFront, API Gateway, AppSync, Lambda, ECS, Fargate, OpenSearch, Amazon Bedrock AgentCore and AWS Global Accelerator | Testing that includes command and control needs prior approval; simulated phishing, malware testing and covert red team exercises go through a Simulated Events form at least two weeks ahead; DoS, simulated DoS, port, protocol and request flooding, Route 53 zone walking, S3 bucket takeover and subdomain takeover are prohibited; API Gateway and Bedrock AgentCore are prohibited services for outbound penetration testing; DDoS simulation and stress tests follow separate AWS policies; assessments of AWS infrastructure or AWS services themselves are not permitted | |
No pre-approval since June 15, 2017, for Azure only, under the Microsoft Cloud Unified Penetration Testing Rules of Engagement | DoS of any kind, network-intensive fuzzing, using credentials that are not your own (including leaked ones), post-exploit actions against Microsoft services beyond a proof of concept, and phishing Microsoft employees | |
No contact required | Tests must only affect your own projects, under the Acceptable Use Policy and Terms of Service | |
Auth0, as an identity provider example | Tests that involve Auth0 infrastructure need a paid subscription, prior approval and at least 7 days' notice; tests isolated to your own infrastructure need no notice | No DoS or unauthorized volumetric attacks, no testing of the management dashboard, only approved tenants, nothing during change freeze periods, and request rates within the rate limit policy |
The cloud penetration testing rules of engagement guide works through each cloud provider's rules in more depth, and the AWS penetration testing guide covers AWS's policy and test plan.
Two more authority cases come up in almost every SaaS scope:
SaaS you use. A CRM, a support desk or a payment processor belongs to its vendor. Test your configuration of it and your integration with it, not the vendor's platform, unless the vendor agrees in writing. The right-to-test clause guide covers what to ask a vendor for, and what to offer when your own customers ask.
Multi-tenant providers in PCI scope. PCI DSS v4.0.1 Requirement 11.4.7 requires multi-tenant service providers to support their customers for external penetration testing, and its guidance says they "cannot forbid penetration testing because this would leave their customers' systems open to exploitation." A provider meets it either by giving customers prompt access to test or by giving them evidence that the testing was done on their subscribed infrastructure.
What an authority failure looks like
One of the best-documented public scoping failures is set out in the investigation report the Iowa Supreme Court published in October 2019. The State Court Administration (SCA) had hired Coalfire for a red team assessment that included physical testing at three buildings, and in the early morning hours of September 11, 2019, the Dallas County Sheriff's Office arrested two of the firm's testers inside the Dallas County courthouse. The report, prepared by the law firm Faegre Baker Daniels, found that:
The final rules of engagement said physical testing "Can be during the day or evening", while the same document said all penetration testing was expected to run "Monday through Friday between the hours of 6AM and 6PM Mountain time", for buildings in Iowa, which is on Central time.
The scoping questionnaire answered "No" to whether local law enforcement or security personnel would be told, and "nobody notified the sheriffs in either Polk or Dallas Counties."
Authority itself was in doubt: "it is unclear whether the SCA had the legal authority to grant Coalfire access to the county courthouses after hours."
One of the contact mobile numbers on the authorization letter was wrong, and no attorney had reviewed the contract.
The investigators did "not find that the SCA or Coalfire acted with deception or ill-intent." Their recommendations translate to any scope, digital or physical: define permitted and prohibited techniques more explicitly, have counsel review the agreement, and confer with the officials who could be affected before testing starts, because "safety should override any desire to conduct a stealthy assessment." In a digital scope, the equivalent parties are the hosting and SaaS providers and any managed security provider, which PTES says "may need to be notified of testing."
Decision 4: Production or staging?
Decide the environment test by test, not once for the whole engagement. NIST SP 800-115 section 6.3 names three factors: the possible impact on production ("if a particular test technique is likely to cause a denial of service, it should probably be used against a non-production system"), the presence of sensitive personal data, and how closely the environments match, because "there are usually inconsistencies between the test and production environments, which can result in missed vulnerabilities if non-production systems are used."
The PCI Security Standards Council's penetration testing guidance accepts a separate environment if it is identical to production: the tester has to ensure the same application-layer and network-layer controls exist there, the arrangement belongs in the rules of engagement, and exploitable findings must be corrected on production systems and retested.
Test type | Where it runs | Why |
|---|---|---|
Reconnaissance, login, session and authorization checks with dedicated test accounts | Production, inside test tenants | The real configuration is where access control actually lives |
State-changing tests: bulk deletes, payment and refund flows, account recovery, outbound email | Staging, or production test tenants with an agreed cleanup | Mistakes stay contained and reversible |
Anything that touches real personal or card data | Staging with synthetic data | NIST's personal data factor: there is nothing to expose if it is not there |
Availability: DoS, load, request flooding, LLM cost amplification | Outside the penetration test, as a separate load test under the provider's own policies | AWS and Azure prohibit DoS testing, and Auth0 runs load testing under a separate policy |
Record the staging build version and its known differences from production in the rules of engagement, so every finding, and every clean result, traces back to the code that was actually tested.
Decision 5: What access, and how many test accounts?
The access level decides how much of the authenticated application a test can reach, and the account matrix decides whether authorization flaws can be found at all. Black box gives no credentials or internal knowledge, grey box gives accounts and documentation such as an OpenAPI specification, and white box adds source code and architecture. For an application with roles and customer data, grey box is the useful default, and white box earns its cost where the logic is complex.
OWASP's test for insecure direct object references, WSTG-ATHZ-04, is specific: "The best way to test for direct object references would be by having at least two (often more) users to cover different owned objects and functions." Its role-definition test, WSTG-IDNT-01, starts by identifying and documenting the roles the application uses. PTES asks the same thing from the buyer's side: "Does the client want role-based testing performed against this application?" The OWASP Top 10:2025 keeps broken access control at number one and reports that "100% of the applications tested were found to have some form of broken access control."
Build the matrix before kickoff:
Two users per role, per tenant. Two users in the same role expose horizontal access flaws; users in different roles expose vertical ones.
Two tenants for any multi-tenant product. Cross-tenant access is the highest-impact question in most SaaS tests, and it needs a second tenant to answer.
Every privilege boundary. Support, admin and service accounts, plus API keys or tokens for each scope the API issues.
MFA and single sign-on handled up front. Test users with TOTP seeds shared through a vault, or a dedicated test factor, so testers are not locked out on day one.
Seeded data. Enough synthetic records in each tenant to prove access to an object that belongs to someone else.
Decision 6: Which techniques, when, and from where?
Write down which techniques are allowed and which are prohibited, when testing may run, and where the traffic comes from. Typical prohibitions are denial-of-service and volumetric testing (the cloud policies above prohibit them anyway), modifying or deleting production data beyond what is needed to show impact, persistence that outlives the test, pivoting into assets outside scope, and social engineering unless it is separately authorized.
Then the logistics, each written once:
Windows with a time zone. Days, hours, blackout dates and one stated time zone. The Iowa report shows what a mismatched time zone does. Include the providers' freezes too: Auth0 does not allow penetration tests during its change freeze periods.
Source IPs. NIST SP 800-115 section 6.5: "IP addresses of the machines from which assessment activities will be conducted should be identified in the assessment plan to enable administrators to differentiate assessment activities such as penetration testing attacks from actual malicious attacks."
Defensive controls. Decide whether the WAF and rate limiting stay enforcing, which makes the test partly a detection exercise, or allowlist the source IPs, which buys coverage. PTES treats blocking ("shunning") as acceptable or not depending on the spirit of the test.
Provider abuse handling. AWS forwards abuse reports about your security testing to you, and Microsoft "may, at our discretion, interrupt attacks in progress by you or your agents regardless of whether or not they are part of a valid test." Keep the signed authorization where the on-call engineer can find it.
Status cadence. PTES recommends status meetings held daily and "as short as possible", limited to plans, progress and problems.
Decision 7: When does testing stop, and who restarts it?
Write stop conditions as triggers, and name who can stop the test and who can restart it. NIST SP 800-115 Appendix B asks the rules of engagement for "Criteria for halting the information security testing", for the test team's course of action if a test procedure negatively impacts the network or an adversary attacks while testing is under way, and for "A process for reinstating the test team and resuming testing". Section 6.5 asks the hardest version directly: if the assessors discover "an actual intruder or an intruder's footprints within the network, should testing stop?" And if it stops, whose authority restarts it? PCI's guidance gives one answer: activate incident response procedures and stop the penetration test until the compromise is resolved.
Typical triggers, each written so that nobody has to make a judgment call mid-test:
Evidence of a prior or concurrent compromise.
Measurable service degradation on a production system, against a threshold agreed in advance.
Access to data outside the agreed handling rules, such as a real customer's records. Microsoft's rule is a good default: "If you accidentally access any data that you do not have rights to, stop immediately."
Any action that reached an asset outside scope.
An abuse notice or interruption from a provider.
Name who can call a stop (both sides), who must be told, and the one person who can authorize a restart. A critical finding is not a stop condition by default: it triggers immediate notification, on the timelines set in the statement of work.
Decision 8: How is data handled?
Agree before testing starts how evidence is gathered, stored, transmitted, retained and destroyed. NIST SP 800-115 Appendix B asks for guidelines on gathering, storing, transmitting and destroying test data, with "detailed, unambiguous requirements for data handling", because results "will identify vulnerabilities that an adversary can exploit, and should be considered sensitive." Four decisions cover most engagements:
Prove access without taking data. PTES: "There are ways to prove that the vault door was opened without taking any of the money." A screenshot of a schema, a record count or one redacted record proves impact.
Where evidence lives. An encrypted portal or an agreed encrypted channel, and never plaintext email or chat for credentials.
Retention that fits your audit. PCI DSS v4.0.1 Requirement 11.4.1 requires keeping penetration testing results and remediation activities results for at least 12 months, so a destruction clause shorter than that can conflict with your own obligation.
Credentials and transcripts. Credentials found during testing are used only against in-scope assets, reported, and never used after the test. LLM prompts and responses captured as evidence can contain customer data and need the same handling as any other evidence.
Worked example: a SaaS app, its API, an AWS account and an LLM assistant
Ledgerline is a fictional B2B invoicing product with a common 2026 shape:
a single-page web app at app.ledgerline.example and a REST API at api.ledgerline.example, about 140 endpoints with an OpenAPI specification;
three customer roles (owner, accountant and viewer) in a multi-tenant design, plus an internal support console at admin.ledgerline.example;
login through Auth0 on a paid plan, and card payments through Stripe;
one production AWS account running ECS on Fargate, Aurora PostgreSQL, S3 for invoice PDFs, Lambda jobs and API Gateway webhooks;
an LLM assistant built on Amazon Bedrock that answers questions over a tenant's invoices through retrieval, and can call a tool that drafts and sends payment-reminder emails.
Objective: produce penetration testing evidence for the SOC 2 Type 2 audit, and establish whether any customer role can read or change another customer's invoices, directly, through the API, or through the assistant.
Component | Decision | Environment | Authority and conditions |
|---|---|---|---|
Web app and API | In scope, grey box with the OpenAPI specification | Production test tenants for login, session and authorization checks; staging for state-changing tests | Ledgerline's CTO signs the authorization |
Auth0 login | Tested through Ledgerline's own login, MFA and account recovery flows | Production test tenants | No tests against Auth0's infrastructure this round; that would need Auth0's prior approval and at least 7 days' notice |
Stripe payments | Ledgerline's billing logic in scope; Stripe's platform out | Staging, against a Stripe sandbox | Stripe sandboxes simulate transactions without moving real money |
AWS account | Read-only configuration review, plus an assumed-breach test from the API's task role | Production, read-only; anything that changes state runs in staging | ECS, Fargate, Aurora, API Gateway and Lambda are on AWS's permitted list; S3 is not, so buckets are checked as configuration and anything more goes to AWS Support first; no command and control, no flooding, no bucket or subdomain takeover |
LLM assistant | Prompt injection, excessive agency through the reminder tool, hidden context exposure, cross-tenant retrieval | Staging with synthetic invoices; the email tool points at a test mailbox; a token spending cap | Prompts go through Ledgerline's own app; the Amazon Bedrock service itself is out of scope |
Support console | Out this round, scoped as its own application next quarter | Not tested | On the exclude list with the reason |
Corporate IT, offices and staff | Out; social engineering is a separate engagement | Not tested | Not authorized |
The assistant's tests map to the OWASP Top 10 for LLM Applications 2026, published in August 2026: prompt injection is LLM01:2026, excessive agency LLM03:2026 and hidden context exposure LLM08:2026. Unbounded consumption, LLM06:2026, is the reason for the spending cap: the 2026 list says traditional request-rate limiting alone is no longer sufficient and calls for "hard spending caps". Bedrock stays out because AWS does not permit assessments of AWS services themselves; if the assistant ran on Amazon Bedrock AgentCore instead, that service is on AWS's permitted list. The AI and LLM penetration test scope of work template covers model access, retrieval, agents and tools in more depth.
The account matrix follows Decision 5:
Tenant | Owner | Accountant | Viewer |
|---|---|---|---|
Tenant A | 2 users | 2 users | 2 users |
Tenant B | 2 users | 2 users | 2 users |
That is twelve customer accounts, each with a TOTP seed in a shared vault, plus an API token for each role and a set of synthetic invoices in each tenant.
The rules of engagement for the example:
Windows: production tests Monday to Friday, 09:00 to 17:00 America/Toronto, while Ledgerline's on-call engineer is working; staging at any time.
Source IPs: two fixed addresses, given to the security team and allowlisted on the WAF for the API tests only.
Techniques: no denial of service or request flooding; rate-limit checks capped at a short burst agreed in writing; no social engineering; no persistence.
Stop conditions: signs of a prior compromise; a sustained rise in production server errors above the agreed threshold; any real customer data in a response; any reminder email addressed outside the test mailbox; an AWS or Auth0 abuse notice.
Data handling: evidence held in the testing portal, redacted screenshots only, credentials rotated after the test, and assistant transcripts kept as evidence and destroyed with the rest of the engagement data after 12 months.
What the example leaves out matters as much as what it includes. The support console, Auth0's own platform and the corporate environment are each excluded with a reason, so the report can state exactly what was and was not tested.
Scoping questions to answer before the kickoff call
Each question maps to a decision above. The answers become the scope and the rules of engagement, and then the clauses of the statement of work.
Objective
What one sentence describes what the test must prove?
Which audit or customer will rely on the report, and what does it require?
Assets
Which URLs, hosts, IP ranges, API specifications, cloud accounts and repositories are in scope, and in which environment?
How many applications, endpoints, roles, hosts and accounts is that?
What sits between the tester and the target (WAF, CDN, API gateway), and is it in scope?
What is on the exclude list, and why?
Authority
Who owns each asset, and who signs for it?
Which providers host or process each asset, and what does each provider's current testing policy require?
Environment and access
Which tests run in production and which in staging, and how closely does staging match production?
Which roles exist, and are two users per role, per tenant, ready with MFA handled?
Is source code or architecture documentation available?
Rules
Which techniques are prohibited?
What are the windows, blackout dates and time zone?
Which source IPs will testers use, and will defensive controls allowlist them?
What stops the test, who can stop it, and who restarts it?
Where does evidence live, how long is it kept, and how is it destroyed?
How Stingrai scopes an engagement
Stingrai is a CREST-accredited penetration testing company, accredited for both Penetration Testing and AI-Enabled Penetration Testing, offering fully human-led and hybrid (human penetration testers plus AI agents) penetration tests, delivered by experienced penetration testers who are also world-class security researchers and bug bounty hunters, with OSCE³, OSWE, OSEP and CREST CRT certifications across the team. Founded in Toronto, Canada in 2021, it is trusted by companies from startups to enterprises to meet audit requirements for SOC 2, ISO 27001, CMMC, PCI DSS and HIPAA, with engagements across web, API, mobile, AI and LLM, cloud, network, Active Directory and social engineering penetration tests and red team engagements.
Scoping follows the decisions above. The Get a Quote form asks for the counts that drive effort for each service, such as the number of web applications and the approximate number of dynamic pages or API endpoints in each, or the cloud providers, accounts and environments in scope. Human-led engagements are staffed by two named penetration testers from a team holding OSCE³, OSWE, OSEP, CREST CRT and CISSP certifications, with 18 CVEs published by Stingrai's researchers. Findings are posted to the PTaaS portal as they are confirmed, each with a working proof of concept, clients can chat with the assigned testers during the test, retesting of remediated findings is included, and every human-led and hybrid report ships with an attestation letter.
For a single web application, the published packages fix the scope at One web application and associated APIs, with up to 200 API endpoints or dynamic pages and up to 3 user roles for authenticated testing. The Autonomous Pentest, run by Snipe, Stingrai's autonomous AI penetration testing agent for web applications and APIs, is US$3,000 per assessment. The Hybrid Pentest, in which Snipe and penetration testers test together throughout the engagement, is US$6,800 per assessment. Both are available as one-time engagements or continuous programs (pricing). In the worked example, the web app and its API fit within those limits, while the AWS account review and the LLM assistant testing are separate cloud and AI scopes, quoted through the Get a Quote form.
Frequently asked questions
How do you scope a penetration test?
Make eight decisions in writing before testing starts: what the test must prove, which assets are in scope by identifier and count, who has the authority to permit testing of each asset, which tests run in production and which in staging, what access and how many test accounts per role, which techniques are allowed and when, what stops the test, and how data is handled. The scope records what will be tested, the rules of engagement record how, and the statement of work turns both into contract terms. PTES, NIST SP 800-115 and the OWASP Web Security Testing Guide are the standard references.
What should the rules of engagement for a penetration test include?
They should include written authorization from the owner of each asset, the in-scope targets and the exclude list, allowed and prohibited techniques, test windows with a time zone, the testers' source IP addresses, contacts on both sides, stop conditions with the person who can resume testing, data handling rules, and reporting expectations. NIST SP 800-115 Appendix B is a ready template, and it ends with a signature page for the test team leader and the organization's senior management.
What is the difference between scope, rules of engagement and a statement of work?
The scope defines what will be tested, the rules of engagement define how testing happens, and the statement of work defines what is being bought: deliverables, retest terms, acceptance criteria, schedule and price. PTES treats scope and rules of engagement as separate questions to be handled independently. They can sit in one signed document, as long as each question is answered once and the answers agree.
Do you need permission from AWS, Azure or Google Cloud to run a penetration test?
Not for standard testing of your own resources. AWS allows testing of its permitted services without prior approval, but testing that includes command and control needs prior approval, and simulated phishing, malware testing and covert red team exercises need a Simulated Events request at least two weeks ahead. Microsoft dropped Azure pre-approval on June 15, 2017, and testing must follow its Unified Penetration Testing Rules of Engagement. Google Cloud does not require you to contact it, as long as tests only affect your own projects. AWS and Microsoft prohibit denial-of-service testing in a penetration test and handle DDoS resilience testing through separate simulation programs, and the written authorization for a third-party tester always comes from the resource owner.
Should a penetration test run in production or staging?
Decide per test type. Login, session and authorization checks with dedicated test accounts usually run in production, because that is where the real configuration lives. State-changing tests and anything that touches real personal data belong in staging, and denial-of-service testing belongs in neither. NIST SP 800-115 warns that test and production environments usually differ, which can hide vulnerabilities, so record the staging build version and its known differences in the rules of engagement.
How many test accounts does a penetration test need?
At least two users per role, and for a multi-tenant product, those users in at least two tenants. OWASP's test for insecure direct object references, WSTG-ATHZ-04, calls for at least two, and often more, users to cover different owned objects and functions. Add accounts for each privilege boundary, such as support and admin, an API token for each scope, and handle MFA before the test starts so testers are not locked out.
Can a penetration test include third-party SaaS, such as an identity provider or payment processor?
Only with the provider's permission. Your authorization covers what you own, so the test covers your configuration of a SaaS product and your integration with it, not the provider's platform. Some providers publish a process: Auth0 allows paid customers to test their application's use of its infrastructure with prior approval and at least 7 days' notice. Payment flows are usually tested against the processor's sandbox, and multi-tenant service providers in PCI scope must support customer testing under PCI DSS v4.0.1 Requirement 11.4.7.
What does OWASP say about penetration test scope and rules of engagement?
The OWASP Web Security Testing Guide, whose current stable version is 4.2, defines what to test rather than how to agree the engagement. Its methodology chapter points to PTES, which starts with pre-engagement interactions, and to NIST SP 800-115 for assessment planning, and its authorization tests set the account needs, such as at least two users for insecure direct object reference testing. For the engagement itself, use PTES pre-engagement and the NIST SP 800-115 Appendix B rules-of-engagement template.
Related reading
Anthropic's AI worm research: how to scope device and network testing
PCI DSS Compliance Audit (2026): Process, Requirements and How to Prepare
Internal Penetration Testing (2026): Scope, Delivery, Cost Drivers and Requirements
External Penetration Testing (2026): What an External Pen Test Covers, Scope and Cost
References
Penetration Testing Execution Standard, Pre-engagement, page last edited 16 August 2014.
National Institute of Standards and Technology, SP 800-115, Technical Guide to Information Security Testing and Assessment, September 2008: sections 5.2.1, 6.3, 6.5 and 7.4 and Appendix B.
OWASP Foundation, Web Security Testing Guide project page: stable v4.2, v5.0 in development.
OWASP Foundation, WSTG-ATHZ-04, Testing for Insecure Direct Object References, WSTG v4.2.
OWASP Foundation, WSTG-IDNT-01, Test Role Definitions, WSTG v4.2.
OWASP Foundation, Penetration Testing Methodologies, WSTG v4.2.
OWASP Foundation, OWASP Top 10:2025, A01 Broken Access Control.
OWASP GenAI Security Project, OWASP Top 10 for LLM Applications 2026, August 2026.
PCI Security Standards Council, document library: PCI DSS v4.0.1, Requirements and Testing Procedures, June 2024, Requirements 11.4.1 to 11.4.7.
PCI Security Standards Council, Request for Comments: PCI DSS v4.0.1, June 2026.
PCI Security Standards Council, Information Supplement: Penetration Testing Guidance, September 2017.
Amazon Web Services, AWS Customer Support Policy for Penetration Testing.
Microsoft, Penetration testing (Azure security fundamentals).
Microsoft Security Response Center, Microsoft Security Testing Rules of Engagement.
Google Cloud, Cloud Security FAQ: penetration testing.
Auth0, Penetration Testing Policy.
Stripe, Testing documentation.
Iowa Supreme Court, In the Matter of the Independent Investigation Into Judicial Branch Information Security Testing: order of 10 October 2019 and the Coalfire Investigation Report dated 9 October 2019.
Stingrai, The State of Penetration Testing 2026.
Stingrai, Pricing.
