The scope of a penetration test defines what will be assessed, how far the assessment may go, and which testing activities are explicitly excluded. Scope is often understood mainly as a technical list: specific domains, IP addresses, web applications, APIs, and endpoints.
That definition is too narrow.
A meaningful scope must focus primarily on the customer’s actual business risks. Even a technically comprehensive assessment creates value only if it covers the systems, data, and business processes whose compromise would genuinely matter to the customer.
The scope of a web or API penetration test should therefore always be defined through direct coordination between the customer and the penetration tester.
Scope Is More Than a List of URLs
The technical scope may include:
- Domains, subdomains, and IP addresses
- Web applications and customer portals
- API endpoints and API versions
- Mobile or external API clients
- User roles and privilege levels
- Connected third parties and identity services
This still does not describe the complete scope.
It is also necessary to define which data, business processes, and attack methods will be considered. Organizational and operational restrictions belong in the scope as well. An application may be technically in scope while specific functions or testing methods remain expressly excluded.
For example, a customer portal may be tested while sending real orders, modifying production customer data, or placing load on a connected payment system is prohibited.
Business Risk Is the Starting Point
The most important starting point for defining scope is not the technical architecture, but this question:
What would be particularly damaging to the customer if an attacker compromised it?
The classic information security model distinguishes confidentiality, integrity, and availability. This model is useful, but it does not automatically capture the full business impact.
A vulnerability may technically affect only confidentiality while still creating a significant financial risk.
One real-world example involved a price list that was intended to be available only to registered customers who had subsequently been verified by the company. The prices were deliberately not public. The company wanted to prevent competitors from viewing its pricing structure and using it for their own offers or sales strategies.
Protecting this price list was particularly important to the customer’s business.
A previous penetration tester had only noted the issue in passing. From a purely technical perspective, it was an unintended disclosure of information. The integrity of the data remained unchanged, and system availability was unaffected. The vulnerability might therefore have received only a medium severity rating.
From the customer’s perspective, however, uncontrolled access to the price list would have been a critical failure. The vulnerability could have directly threatened the company’s competitive position and pricing strategy.
This example demonstrates why a technical severity rating alone is insufficient. Methods such as CVSS can support an assessment, but they cannot replace consideration of the specific business damage.
Identify Critical Data and Business Processes
Before the penetration test begins, the customer and tester should jointly determine which systems access particularly sensitive data and which endpoints participate in critical business processes.
It is not enough to consider only obvious functions such as login, registration, or password reset. Relevant endpoints may also:
- Provide price lists, contracts, or internal documents
- Return personal or confidential customer data
- Change roles and privileges
- Trigger orders, bookings, or payments
- Generate exports or reports
- Upload or process files
- Perform administrative actions
With APIs in particular, an endpoint’s significance is not always apparent from its URL or technical name. An inconspicuous endpoint may provide access to highly sensitive information or control a central business process.
The customer understands the commercial significance of its data and processes. The penetration tester understands common attack paths and technical dependencies. Only by combining both perspectives can they define a meaningful scope.
User Roles Also Belong in the Scope
For web applications and APIs, the scope must define which roles and privilege levels will be used during testing.
Testing solely without authentication may reveal vulnerabilities on publicly accessible surfaces, but it cannot identify flaws within protected customer or administrative areas.
Depending on the application, relevant perspectives may include:
- An unauthenticated user
- A registered but not yet verified user
- A regular customer
- A privileged customer or business partner
- An employee
- An administrator
- A technical API client
Access control failures can often be identified only by comparing multiple user accounts. A penetration tester may need to determine whether one customer can access another customer’s data or whether a user can invoke functions belonging to a more privileged role.
Suitable test accounts, roles, and sample data must be provided for this purpose. Otherwise, a significant portion of the actual attack surface may remain untested.
The Scope Also Defines Which Vulnerabilities Are Tested
A scope describes more than systems and endpoints. It can also define which types of vulnerabilities will be assessed.
A comprehensive web and API penetration test typically covers flaws in areas including:
- Authentication and session management
- Authorization and access control
- Input validation and injection vulnerabilities
- Business logic
- File uploads and file processing
- Information disclosure
- Server-side requests and integrations
- Cryptographic methods and transport encryption
- Security configuration and error messages
Depending on the objective, however, the engagement may be narrower. A test might focus exclusively on a new API, a payment process, or tenant separation.
The vulnerability classes included and excluded should be documented unambiguously. The phrase “conduct a penetration test” is not sufficiently precise on its own.
Testing Methods Must Be Explicitly Agreed
Not every possible testing method may be used automatically. Certain methods can disrupt operations, deceive users, or create legal and organizational consequences.
The parties must therefore define whether methods such as the following are permitted:
- Social engineering and phishing
- Brute-force attacks or password spraying
- Rate-limit testing
- Denial-of-service or load testing
- Automated vulnerability scanners
- Uploading potentially dangerous files
- Modifying or deleting data
- Testing connected third parties
A standard web penetration test does not automatically include social engineering or phishing. A denial-of-service test should likewise never be conducted without explicit approval.
The decision depends on factors including the customer’s risk tolerance, existing safeguards, and operational circumstances.
Existing Safeguards Affect Testing Depth
If a customer states that effective rate limits and protections against automated login attempts are in place, a controlled brute-force test may be appropriate. This verifies not only that a safeguard exists, but that it works under realistic conditions.
The same applies to cautious load or denial-of-service tests. Such tests may be useful when the engagement explicitly assesses system resilience and suitable safeguards are expected.
If the customer already knows that no rate limits exist, however, an extensive brute-force test is usually unnecessary. The penetration tester would merely exploit a known weakness in practice, potentially locking accounts, placing load on systems, or disrupting production processes.
In this case, documenting the missing safeguard and assessing the resulting risk is often sufficient. A limited, non-destructive demonstration may still be useful if needed to make the finding reproducible.
A penetration test should provide new insights. It should not cause unnecessary harm merely to demonstrate a known weakness at length.
Why Production Systems Are Sometimes Excluded
Business-critical systems or endpoints may intentionally be excluded from active testing. This can initially appear contradictory: Important systems, in particular, should be assessed thoroughly.
In practice, however, active testing can create risks for ongoing business processes. An endpoint might immediately trigger orders, modify production data, contact external service providers, or initiate legally relevant transactions.
Complete exclusion should nevertheless not be the default response. Alternative approaches may be agreed, including:
- Testing in a production-like environment
- Testing during a maintenance window
- Restricting tests to non-modifying requests
- Using specially prepared test data
- Approving only specific test cases
- Joint monitoring by operations or development teams
If an area is genuinely not tested, the final report must state this limitation clearly. Otherwise, readers may incorrectly assume that the entire application was assessed.
Scope and Rules of Engagement Belong Together
Binding testing rules should supplement the technical scope. These are commonly known as the rules of engagement.
They should define permitted testing times, contacts, stopping criteria, and reporting channels. They should also specify how critical vulnerabilities discovered during testing will be handled.
A practical scope should answer at least the following questions:
- Which systems, applications, APIs, and endpoints will be tested?
- Which user roles and test accounts are available?
- Which data and business processes are particularly critical?
- Which vulnerability classes will be assessed?
- Which testing methods are permitted or prohibited?
- Which operational restrictions and stopping criteria apply?
- Which third parties or connected systems are excluded?
- How will critical findings be reported and assessed?
These points should be agreed in writing before testing begins. Changes made during the penetration test must also be documented and approved by the customer.
A Good Scope Also Improves the Final Report
A clearly defined scope makes both testing and the assessment of results easier.
The penetration tester can place identified vulnerabilities in the correct business context. Instead of receiving a purely technical list of findings, the customer receives a comprehensible account of the actual risks.
The technical severity of a vulnerability should be distinguished from its significance to the business.
A technically severe vulnerability in an isolated, non-critical system may create only limited business risk. Conversely, a technically simple information disclosure may be particularly critical if it concerns confidential prices, business strategies, customer data, or other competitively sensitive information.
This classification is possible only if the business context was already considered when defining the scope.
Conclusion
The scope of a web or API penetration test should never consist solely of a list of domains, URLs, and IP addresses.
It must define the systems, user roles, data, business processes, vulnerability classes, and testing methods to be considered. Operational restrictions and explicitly prohibited actions must also be documented.
The customer’s business risk is decisive. A penetration tester can identify technical vulnerabilities and assess whether they are exploitable. The consequences for the business, however, can be determined only together with the customer.
A good scope therefore connects technical attack surfaces with business priorities. Only then does a general security assessment become a penetration test focused on the risks that genuinely matter to the customer.