Penetration Testing Scope: What Should a Pen Test Include?

A penetration test is only as effective as its scope.

Before security testing begins, organizations need to define what can be tested, how it can be tested, and what should remain outside the assessment.

A clear penetration testing scope prevents misunderstandings between the security team and the organization.

It also helps testers focus their efforts on the systems that matter most.

A poorly defined scope can leave critical assets untested.

It can also create unnecessary testing against systems that were never intended to be assessed.

This guide explains what penetration testing scope includes, how scope is defined, and which technical areas organizations should consider before starting a test.

What Is Penetration Testing Scope?

Penetration testing scope defines the boundaries of a security assessment.

It identifies the applications, networks, systems, APIs, cloud environments, domains, and other assets that testers are authorized to assess.

The scope can also define testing methods, testing windows, restrictions, and acceptable attack techniques.

For example, a company may want to test:

• Public-facing web applications
• Internal corporate networks
• APIs
• Cloud infrastructure
• Authentication systems
• Mobile applications
• External IP addresses
• Specific production systems

Another organization may require a much narrower assessment.

The important point is that the scope should match the organization's security objectives.

Why Is Penetration Testing Scope Important?

Security teams often manage hundreds or thousands of digital assets.

Testing everything without a defined boundary is rarely practical.

A well-defined scope helps answer several important questions.

Which Assets Are Being Tested?

The first question is simple.

Which systems are actually part of the assessment?

This could include specific domains, IP addresses, applications, APIs, cloud resources, or network ranges.

What Testing Is Authorized?

Not every testing technique is appropriate for every environment.

The scope can specify which techniques are allowed.

For example, an organization may permit vulnerability exploitation but prohibit denial-of-service testing.

When Can Testing Take Place?

Production environments may have strict operational requirements.

The scope should therefore define testing windows when necessary.

Some organizations may allow testing only during specific hours.

Others may require testing to continue continuously across several days.

What Is Excluded?

Exclusions are just as important as included assets.

Third-party systems, shared infrastructure, production databases, or specific applications may need to remain outside the assessment.

Documenting exclusions prevents accidental testing of unauthorized systems.

What Should Be Included in a Penetration Testing Scope?

A comprehensive scope usually contains several categories.

The exact structure depends on the organization's environment and testing objectives.

1. Target Assets

The first section should identify the assets being tested.

This can include:

• Domains
• Subdomains
• IP addresses
• Network ranges
• Web applications
• APIs
• Mobile applications
• Cloud resources
• VPN infrastructure
• Authentication systems
• Internal applications

Asset identification should be as specific as possible.

Instead of saying "test our website," the scope should identify the exact application or environment.

This makes authorization and reporting much clearer.

2. Testing Type

The scope should identify the type of penetration test being performed.

Different environments require different approaches.

For example:

External penetration testing focuses on assets exposed to the public internet.

Internal penetration testing evaluates security from inside the organization's network.

Web application penetration testing focuses on web applications and their underlying functionality.

API penetration testing evaluates APIs, authentication mechanisms, authorization controls, and exposed endpoints.

Network penetration testing examines network infrastructure and exposed services.

Cloud environments may require a dedicated cloud-focused assessment.

Organizations should select the testing type based on their actual attack surface.

3. Testing Perspective

The tester's starting position also matters.

A penetration test can be performed from different perspectives.

Black Box Testing

The tester receives limited information about the target.

This approach can simulate an external attacker with minimal knowledge.

Gray Box Testing

The tester receives some information about the environment.

This can provide a balance between realistic attack simulation and deeper coverage.

White Box Testing

The tester receives extensive information about the target.

This may include architecture information, source code, credentials, or technical documentation.

Each approach provides different testing coverage.

The selected approach should be documented before testing starts.

4. Testing Methodology

A strong scope should explain the expected penetration testing methodology.

The methodology determines how testers approach the assessment.

A typical penetration testing process may include:

• Reconnaissance
• Asset discovery
• Enumeration
• Vulnerability identification
• Exploitation
• Privilege escalation
• Lateral movement
• Post-exploitation analysis
• Risk validation
• Reporting
• Remediation support
• Retesting

The exact methodology can vary based on the environment.

Web applications may require application-specific testing.

Networks may require infrastructure and service enumeration.

Cloud environments may require configuration and identity testing.

OWASP Penetration Testing

Web applications require a structured approach to security testing.

The OWASP penetration testing methodology is commonly associated with testing web application security risks.

Testing can examine areas such as:

• Authentication
• Authorization
• Session management
• Input validation
• Access control
• Injection vulnerabilities
• Security configuration
• Business logic
• API security
• Sensitive data exposure

The testing approach should reflect the application's architecture and business functionality.

A simple vulnerability scan is not the same as a full penetration test.

Manual testing can identify security weaknesses that automated tools may not understand.

NIST 800-115 Penetration Testing

Organizations may also reference established security testing guidance such as NIST 800-115 penetration testing.

NIST Special Publication 800-115 provides technical guidance for planning and conducting information security testing.

It can help organizations structure activities around:

• Planning
• Discovery
• Attack and penetration
• Reporting

Using a recognized methodology can make the testing process more consistent.

It can also help organizations communicate expectations between security teams, management, and testing providers.

5. Credentials and Access

Some penetration tests require credentials.

For example, authenticated application testing may require test accounts.

Internal assessments may require network access.

Cloud assessments may require specific identities or permissions.

The scope should document:

• Test accounts
• User roles
• Authentication requirements
• VPN access
• API credentials
• Cloud permissions
• Administrative access where applicable

Credentials should be provided through secure channels.

They should also be limited to the permissions necessary for the assessment.

6. Testing Restrictions

Every assessment should define activities that are restricted or prohibited.

Examples may include:

• Denial-of-service testing
• Destructive exploitation
• Data deletion
• Production database modification
• Social engineering
• Physical security testing
• Malware deployment
• Persistence mechanisms

These restrictions protect business operations during testing.

They also help testers understand the organization's risk tolerance.

7. Production Versus Staging

Organizations should clearly identify the environment being tested.

Testing a staging environment is different from testing production.

Production testing may provide a more realistic assessment.

However, it also carries greater operational risk.

The scope should clearly identify:

• Production systems
• Staging systems
• Development environments
• Test environments

If production testing is authorized, the testing rules should be documented carefully.

8. Cloud Penetration Testing Scope

Cloud environments introduce additional considerations.

AWS, Azure, and other cloud platforms contain infrastructure, identities, storage, applications, and networking components.

A cloud penetration testing scope may include:

• Cloud workloads
• Virtual machines
• Containers
• Storage services
• IAM configurations
• Network security controls
• APIs
• Public-facing resources
• Application infrastructure

Cloud testing should account for the architecture of the specific environment.

Organizations should also establish clear authorization before testing cloud resources.

9. API Penetration Testing Scope

Modern applications often depend heavily on APIs.

APIs can expose sensitive functionality and data.

An API penetration testing scope may include:

• API endpoints
• Authentication
• Authorization
• Token handling
• Input validation
• Rate limiting
• Object-level access controls
• Business logic
• Error handling
• Sensitive data exposure

API testing should consider how endpoints interact with the underlying application.

Testing only individual endpoints may not reveal workflow or business logic vulnerabilities.

10. Web Application Penetration Testing Scope

Web applications often contain complex business functionality.

A web application penetration testing scope should identify the application and its major functionality.

Testing may cover:

• Login systems
• Registration
• Password recovery
• User roles
• Account management
• Payment functionality
• File uploads
• Administrative panels
• APIs
• Business workflows

The scope should also identify important user roles.

For example, a customer account may have very different permissions from an administrator account.

How Scope Affects Penetration Testing Cost

Scope directly affects the effort required for a penetration test.

A small web application with limited functionality may require significantly less testing effort than a large enterprise environment.

Factors that can influence pricing include:

• Number of applications
• Number of IP addresses
• Number of APIs
• Network size
• Cloud infrastructure
• Authentication requirements
• Number of user roles
• Testing duration
• Testing methodology
• Manual testing requirements
• Compliance requirements
• Reporting requirements

Organizations should therefore define scope before comparing penetration testing pricing.

A clear scope makes proposals easier to compare.

It also reduces the risk of receiving estimates based on different assumptions.

What Happens When the Scope Is Too Narrow?

A narrow scope is not automatically a problem.

The issue occurs when important attack paths are excluded unintentionally.

For example, testing a web application without testing its supporting APIs may leave important functionality unassessed.

Similarly, testing an internet-facing application without considering authentication or administrative functionality may limit the assessment.

The scope should therefore reflect realistic attack paths.

What Happens When the Scope Is Too Broad?

An unnecessarily broad scope can create its own challenges.

It may increase testing time and cost.

It can also make prioritization difficult.

Organizations should focus on assets that create meaningful security exposure.

The objective is not simply to test the largest possible number of assets.

The objective is to test the right assets with enough depth.

Penetration Testing Scope and Compliance

Compliance requirements can influence the scope of an assessment.

Organizations may need testing for specific systems or environments.

For example, payment environments may have PCI DSS requirements.

Healthcare organizations may have requirements related to protected health information.

SaaS companies may need testing evidence for customer security assessments.

The compliance objective should therefore be documented before testing begins.

This ensures that the assessment produces useful evidence for the organization's security and compliance process.

What Should a Penetration Testing Report Include?

After testing, organizations should receive a structured penetration testing report.

A useful report should explain what was tested and what was discovered.

Typical report sections may include:

• Executive summary
• Scope
• Testing methodology
• Assets tested
• Findings
• Severity
• Technical evidence
• Business impact
• Remediation recommendations
• Testing limitations
• Retest results

The report should make technical findings understandable to both security teams and business stakeholders.

Scope Should Match the Business Risk

A penetration test should not be treated as a generic checklist.

Every organization has a different technology environment.

A SaaS company may prioritize APIs and authentication.

A financial organization may prioritize external infrastructure and sensitive transaction systems.

An ecommerce company may focus heavily on payment workflows and customer accounts.

The scope should therefore start with the organization's highest-value assets and realistic attack paths.

How to Prepare a Penetration Testing Scope

Before contacting a testing provider, organizations can prepare several pieces of information.

Start by listing:

• Public domains
• IP addresses
• Applications
• APIs
• Cloud environments
• Internal networks
• User roles
• Authentication requirements
• Compliance requirements
• Testing restrictions

Then identify the primary security objective.

For example:

• Validate external exposure
• Test application security
• Validate network controls
• Prepare for an audit
• Assess cloud security
• Validate remediation
• Support customer security requirements

This information creates a stronger foundation for the assessment.

Choosing a Penetration Testing Provider

The provider should understand the environment being tested.

Organizations should evaluate whether the provider can support the required testing types, methodology, reporting, and remediation process.

A provider may offer specialized penetration testing services covering applications, networks, APIs, cloud environments, and other attack surfaces.

The scope should be agreed upon before testing begins.

This helps ensure that both sides understand the assessment boundaries.

Frequently Asked Questions About Penetration Testing Scope

What is penetration testing scope?

Penetration testing scope defines the systems, applications, networks, APIs, cloud resources, and other assets that are authorized for security testing.

It can also define testing methods, restrictions, testing windows, and excluded systems.

Why is penetration testing scope important?

A clear scope establishes testing boundaries and helps prevent unauthorized testing.

It also ensures that the security team and testing provider understand which assets and attack paths should be assessed.

What should be included in a penetration testing scope?

A scope should typically include target assets, testing types, testing perspective, methodology, credentials, testing restrictions, environments, exclusions, and reporting requirements.

How does penetration testing scope affect cost?

Larger or more complex scopes generally require more testing effort.

The number of applications, IP addresses, APIs, user roles, cloud resources, testing duration, and reporting requirements can all affect the overall effort and pricing.

What is the difference between external and internal penetration testing?

External penetration testing focuses on assets exposed outside the organization's network.

Internal penetration testing evaluates systems and security controls from within the organization's internal environment.

Should APIs be included in a penetration test?

If an application depends on APIs, they should be considered when defining the testing scope.

API testing can evaluate authentication, authorization, access controls, input handling, business logic, and sensitive data exposure.

Should cloud infrastructure be included in penetration testing?

Cloud infrastructure should be included when it forms part of the organization's relevant attack surface.

The scope should clearly identify the cloud resources and environments that are authorized for testing.

What methodology is used for penetration testing?

Penetration testing can use established methodologies and guidance depending on the environment.

OWASP guidance can support web application testing, while NIST 800-115 provides guidance for planning and conducting information security testing.

How often should a penetration test be performed?

Testing frequency depends on the organization's risk profile, technology changes, compliance requirements, and security objectives.

Organizations may also perform additional testing after major infrastructure or application changes.

What should a penetration testing report include?

A penetration testing report typically includes the assessment scope, methodology, findings, severity, technical evidence, business impact, remediation recommendations, limitations, and retest results.

Final Thoughts

A well-defined penetration testing scope creates clarity before security testing begins.

It establishes which assets are authorized, which techniques can be used, which systems are excluded, and what the final assessment should deliver.

The strongest scopes are specific enough to prevent ambiguity while broad enough to represent realistic attack paths.

Organizations should consider applications, APIs, networks, cloud infrastructure, authentication, compliance requirements, testing restrictions, and reporting expectations.

Most importantly, scope should be based on actual business risk.

When the right assets are tested with the right methodology, penetration testing can provide much more useful security insight than a simple vulnerability scan.

Book a Strategy Call →