ISO 27001 VAPT Scope: What Systems, Applications, APIs, Cloud & Networks Should You Test?

An ISO 27001 VAPT scope defines which applications, APIs, infrastructure, networks, cloud environments, identities, and other authorized assets will be assessed during Vulnerability Assessment and Penetration Testing.

The important part is not the number of assets.

It is whether the scope represents the technology and attack paths that are relevant to the organization's information-security risks.

ISO/IEC 27001:2022 is a requirements standard for an Information Security Management System (ISMS). ISO describes the standard as a framework for managing risks related to the security of information through a systematic approach. It is therefore not a universal technical checklist that requires every organization to test exactly the same systems.

For one organization, the relevant scope may include a customer-facing web application, its APIs and AWS environment.

For another, it may include public infrastructure, VPN access, internal networks, Active Directory and critical enterprise applications.

A practical ISO 27001 VAPT scope should answer five questions:

• What are we testing?

• Why are we testing it?

• What attack surface does it expose?

• What is explicitly excluded?

• What evidence will the assessment produce?

That makes the scope useful to security teams, engineers, compliance teams and auditors rather than turning it into a simple asset list.

https://www.nuagesec.com/vapt-testing-services

A penetration test can be technically thorough and still leave an organization with unanswered security questions when important attack surfaces are outside the scope.

Consider a business with:

• A public web application

• A mobile application

• REST APIs

• An AWS production environment

• A corporate VPN

• Internal Active Directory

• A third-party payment integration

Testing only the public website does not automatically tell you whether the APIs are securely enforcing authorization, whether cloud identities can be abused, whether internal segmentation limits lateral movement, or whether the VPN exposes a path into critical systems.

This is why scope should be driven by relationships, not just asset counts.

NIST SP 800-115 recommends a structured approach to security testing that includes planning assessments, conducting tests, analysing findings and developing mitigation strategies. That planning stage is directly relevant to scoping because the usefulness of testing depends partly on clearly defined objectives and boundaries.

A good scope connects:
Business process → Information → Technology → Exposure → Attack path → Testing objective

For example:
A customer-ordering process may depend on a web application, API gateway, database, cloud identity and payment integration.

The business process is the starting point.

The technology stack shows where risk can materialize.

The VAPT scope then identifies which of those components need direct testing, which are dependencies, which require separate authorization, and which are intentionally excluded.

This is much stronger than handing a tester a spreadsheet containing 25 IP addresses and calling it a complete scope.

ISO/IEC 27001 does not prescribe one identical penetration-testing program for every organization.

The standard establishes requirements for an ISMS and a risk-management approach. The appropriate security measures and assessment activities depend on the organization's context, risks and defined ISMS scope.

That does not make VAPT irrelevant to ISO 27001.

VAPT can provide technical evidence that supports risk identification, vulnerability management, validation of selected security controls and continual improvement. Similarly distinguishes between ISO 27001 as a risk-based management-system standard and penetration testing as a technical activity that can provide evidence within that broader process.

The practical question is therefore not:

“Does ISO 27001 automatically force every company to run the same penetration test?”

It is:

“Which technical testing activities are appropriate for the risks, systems and controls within our ISMS?”

That distinction prevents a common mistake: treating a penetration testing report as the certificate itself.

A VAPT report does not create ISO 27001 conformity on its own.

Instead, testing can become one piece of an evidence-based security and risk-management process.

VAPT vs Vulnerability Assessment

A vulnerability assessment generally focuses on systematically identifying technical weaknesses.

Penetration testing goes further by attempting controlled exploitation of selected weaknesses to determine what can actually be achieved within the authorized scope.

NIST's testing guidance covers vulnerability scanning, security testing and penetration testing as related but distinct assessment techniques.

https://www.nuagesec.com/compliance

There is no single asset list that fits every organization.

A practical starting point is to review the technology supporting the information, services and processes covered by the ISMS.

Web applications

Consider:

• Customer portals

• Employee portals

• Administrative applications

• Partner portals

• Internal business applications

• Internet-facing applications

NuageSEC's web application penetration testing service covers application security areas including authentication, authorization, injection, sensitive-data exposure and business logic, combining manual testing with automated scanning.
https://www.nuagesec.com/services/web-application-security

APIs
Include APIs when they expose application functions, data, authentication, business workflows or integrations.

This may include:

• REST APIs

• GraphQL APIs

• SOAP APIs

• gRPC services

• Internal APIs

• Partner APIs

• Mobile application APIs

NuageSEC currently supports REST, GraphQL, SOAP, gRPC, internal and public API testing. NuageSEC

https://www.nuagesec.com/api-security-testing-services

Network infrastructure

Depending on the risk and objective, scope may include:

• Public IP ranges

• Internet-facing servers

• VPN gateways

• Firewalls

• Routers and switches

• Internal networks

• Wireless environments

• Domain controllers

• Active Directory

https://nuagesec.com/network-penetration-testing-services

Cloud environments

Cloud scope can extend beyond public endpoints.

Consider:

• AWS accounts

• Azure subscriptions

• Google Cloud environments

• IAM roles

• Cloud storage

• Security groups

• Virtual networks

• Kubernetes

• Containers

• Serverless services

• Cloud APIs

• Cross-account trust

NuageSEC's cloud penetration testing service covers AWS, Azure, GCP, Kubernetes, containers, IAM, storage, cloud networking, APIs and serverless environments. NuageSEC

https://www.nuagesec.com/cloud-penetration-testing-services

Mobile applications

If customers or employees access in-scope business functions through Android or iOS applications, the mobile attack surface should be considered explicitly.

The supporting APIs should also be identified rather than assuming the web application assessment covers them.

Identity and privileged access

Identity systems can become particularly important when compromise provides access to sensitive systems.

Depending on the environment, consider:

• SSO

• MFA workflows

• Privileged accounts

• Authentication services

• Active Directory

• Identity federation

• Administrative interfaces

The exact systems included should follow the engagement's objectives and authorization boundaries.

One of the most common scoping mistakes is treating an application as a single URL.

A modern application may actually contain several interconnected attack surfaces:

Browser interface → API → Authentication service → Cloud resources → Database → Third-party integrations

Each layer may introduce a different security question.

What should be considered for web applications?

The scope should identify the application itself, environments, authentication states and relevant user roles.

For example:

• Unauthenticated users

• Standard users

• Privileged users

• Administrators

• Support users

• Partner accounts

Role coverage matters because an application can behave securely for one user type while exposing sensitive functionality through another.

What should be considered for APIs?

APIs deserve explicit attention because they frequently expose application logic and sensitive data.

OWASP's API Security Top 10 includes risks such as Broken Object Level Authorization, Broken Authentication, Broken Object Property Level Authorization, unrestricted resource consumption, security misconfiguration and improper inventory management.

For example, an API may correctly authenticate a user but fail to verify whether that user is authorized to access the specific record requested.

OWASP describes this class of issue as Broken Object Level Authorization, where manipulating an object identifier can result in unauthorized access to another user's data or actions.

That is why a scope document should not simply say:

“Website included.”

It should be more precise:

Customer web application, administrative portal, authenticated REST API endpoints, user roles A/B/C, production environment, and associated authentication flows included.

That level of detail gives the tester a meaningful target and gives stakeholders a clearer understanding of what the assessment actually proves.

Cloud and infrastructure assessments require another level of scoping.

An attacker does not necessarily move from “public IP” directly to “database.”

They may move through a sequence:

Internet exposure → compromised account → cloud identity → excessive permission → internal service → sensitive resource

A useful VAPT scope considers whether those connections should be tested.

Cloud

A cloud assessment may need to consider:

• Identity and Access Management

• Storage exposure

• Network controls

• Security groups

• Cloud APIs

• Kubernetes

• Containers

• Serverless functions

• Secrets and credentials

• Cross-account relationships

NuageSEC's current cloud testing coverage includes IAM exploitation, cloud APIs, Kubernetes, containers, serverless environments and cross-account trust relationships. NuageSEC

External network

External testing may focus on:

• Internet-facing infrastructure

• Public IP ranges

• VPN gateways

• Firewall exposure

• Publicly available services

• Remote-access infrastructure

Internal network

Internal testing can address a different scenario: an attacker who has already obtained some level of access.

NIST describes internal penetration testing as an assessment where testers operate from the internal network and attempt to obtain greater access through techniques such as privilege escalation.

NuageSEC's current network testing coverage includes internal networks, external infrastructure, Active Directory, VPN access, firewalls, wireless networks, routers, switches and domain controllers. NuageSEC

This distinction is important because external testing and internal testing answer different questions.

External testing asks:

“What could an attacker reach from outside?”

Internal testing asks:

“What could an attacker do after gaining internal access?”

A strong VAPT scope does not only define what will be tested.

It clearly defines what will not be tested.

That prevents ambiguity during the engagement and avoids assumptions about systems that have not been authorized.

Typical exclusions may include:

• Third-party infrastructure not owned by the organization

• Production systems that cannot be safely tested

• Certain denial-of-service activities

• Social engineering, when not part of the engagement

• Physical security testing

• Systems awaiting separate authorization

• Legacy applications intentionally excluded from the current assessment

An exclusion does not automatically mean that the system is insecure.

It means the current assessment is not providing direct testing evidence for that asset.

That distinction should be documented.

Third-party systems

Suppose your application depends on:

• A payment gateway

• An external identity provider

• A cloud provider

• A partner API

Those services may be relevant to the attack path but may not be legally or technically available for direct penetration testing.

In that situation, document them as dependencies or third-party components, not silently treat them as tested assets.

Authorization matters

The final scope should identify:

In scope

Out of scope

Testing restrictions

Authorized environments

Testing windows

Third-party dependencies

Emergency contacts

Rules of engagement

A clearly bounded assessment is safer and more useful than an overly broad scope that creates operational uncertainty.

NIST's testing guidance places emphasis on planning, defined assessment activities and controlled execution, which supports this structured approach.

Before approving the scope, review every major asset against these eight questions.

1. Is the asset inside the ISMS scope?

If not, explain why it is being considered for testing or why it is excluded.

2. Does it process, store or provide access to sensitive information?

Data does not have to be directly stored on the system for the system to matter. An authentication service, for example, may provide access to systems that hold sensitive information.

3. Is it externally exposed?

Public exposure generally increases the importance of understanding how the asset can be attacked from outside.

4. Does it provide privileged access?

Administrative portals, identity systems and management interfaces may deserve separate attention because compromise can create broader access.

5. Can another compromised system reach it?

This identifies potential lateral movement and chained attack paths.

6. Is it business-critical?

Ask what happens if the system is compromised, unavailable or manipulated.

7. Has it materially changed?

Major application releases, new APIs, cloud migrations, infrastructure changes or authentication redesigns can change the appropriate testing scope.

8. Is testing authorized?

A technically relevant asset cannot simply be added to the scope without appropriate authorization.

Example

Imagine an organization with:

Customer portal + mobile app + REST API + AWS production environment + VPN + Active Directory + payment provider

A weak scope might be:

“Customer website — one domain.”

A more useful scope might state:

In scope: customer web application, administrative portal, mobile application, associated authenticated APIs, production cloud resources supporting the application, and authorized external infrastructure.

Conditional/internal scope: VPN and internal infrastructure based on agreed assessment objectives.

Third-party dependency: payment provider identified as an integration but excluded from direct testing without provider authorization.

The second scope gives everyone a much clearer picture of the assessment boundaries

Mistake 1: Testing only the public website

A website test does not automatically validate APIs, mobile applications, cloud infrastructure or internal attack paths.

Mistake 2: Treating a vulnerability scan as a complete penetration test

Automated scanning is useful for identifying potential weaknesses, but it does not replace controlled manual validation of application logic, permissions and attack paths.

NuageSEC describes its VAPT approach as combining automated vulnerability identification with expert manual penetration testing to validate real-world exploitability and business risk. NuageSEC

Mistake 3: Using asset count as the only scope metric

“100 IP addresses tested” tells you how many addresses were assessed.

It does not necessarily tell you whether the systems that matter most to the business were covered.

Mistake 4: Ignoring APIs

Modern applications often depend heavily on APIs. OWASP specifically identifies API authorization, authentication and inventory-related risks as important areas of API security.

Mistake 5: Ignoring internal attack paths

An external assessment may identify how an attacker enters.

An internal assessment can help determine what happens after that initial foothold.

Mistake 6: Treating cloud as traditional infrastructure

Cloud environments introduce identity, API, storage, workload and trust relationships that may require explicit consideration.

Mistake 7: Failing to document exclusions

An auditor, security team or management reviewer should be able to understand what was tested and what was deliberately left outside the engagement.

Mistake 8: Defining the scope before understanding the architecture

The scope should be informed by current architecture and business processes.

Otherwise, you risk testing the documented environment instead of the environment actually being operated.

Once the assets and objectives are understood, turn the scoping exercise into a documented assessment brief.

A practical scope document should include:

Assessment objective

State why the test is being performed.

Examples:

• Validate external exposure

• Assess application security

• Validate API authorization

• Assess internal attack paths

• Evaluate cloud security

• Support an ISO 27001 risk-management process

Scope inventory

Document:

• Domains

• Applications

• APIs

• IP ranges

• Cloud environments

• Network segments

• User roles

• Relevant infrastructure

• Critical integrations

Testing approach

Describe whether the engagement includes:

• Vulnerability assessment

• Manual penetration testing

• External testing

• Internal testing

• Authenticated testing

• Unauthenticated testing

• Application testing

• API testing

• Cloud testing

NIST SP 800-115 provides guidance for planning and conducting technical security testing and for analyzing and mitigating findings.

Restrictions and exclusions

Record prohibited techniques, unavailable systems, third-party dependencies, testing windows and other limitations.

Evidence and reporting expectations

The final reporting should make it possible to understand:

What was tested?

How was it tested?

What was found?

How serious is it?

What could the weakness affect?

How should it be fixed?

Was the fix validated?

NuageSEC's current VAPT service describes executive and technical reporting, risk matrices, proof-of-concept evidence, remediation guidance and retesting validation as part of its deliverables. NuageSEC

A simple scope statement

A good final scope could read:

The assessment will evaluate the organization's authorized web applications, APIs, external network infrastructure and production cloud resources that support the in-scope business service. Testing will cover authenticated and unauthenticated attack surfaces where authorized. Internal network infrastructure, third-party systems and activities outside the agreed rules of engagement are excluded unless explicitly added to the scope.

That one paragraph is far more useful than saying:

“Complete VAPT of the organization.”

Before the test starts, ask one final question:

“Could an attacker reach something important that our current scope does not test?”

If the answer is yes, revisit the scope before testing begins.

What is an ISO 27001 VAPT scope?

An ISO 27001 VAPT scope defines the applications, APIs, networks, cloud environments, infrastructure and other authorized assets that will be assessed as part of a security-testing engagement supporting the organization's ISMS and risk-management objectives.

Does ISO 27001 require penetration testing?

ISO/IEC 27001:2022 does not prescribe one universal penetration-testing scope for every organization. The appropriate security and assessment activities depend on the organization's context, risks, ISMS scope and applicable controls.

Should APIs be included in ISO 27001 VAPT?

APIs should be considered when they expose application functionality, sensitive information, authentication, authorization or business workflows. API testing should be explicitly scoped rather than assumed to be covered by a web application assessment.

Should cloud infrastructure be part of the VAPT scope?

Cloud resources should be considered when they host applications, identities, data, APIs or workloads relevant to the assessment. The exact scope depends on the cloud architecture and authorized testing boundaries.

Should internal networks be penetration tested?

Internal testing can be appropriate where internal systems, identity infrastructure, network segmentation or lateral movement create relevant security risk. It answers a different question from external penetration testing.

What happens when a critical system is excluded?

The exclusion should be documented. It means the VAPT does not provide direct testing evidence for that system during the engagement, and the organization should consider the resulting coverage gap within its wider risk-management process.

Is vulnerability scanning the same as VAPT?

No. Vulnerability scanning focuses primarily on identifying potential weaknesses. Penetration testing adds controlled exploitation and validation to determine whether weaknesses can be practically leveraged within the authorized scope.

How often should ISO 27001 VAPT be performed?

There is no single testing frequency that applies to every organization simply because it is ISO 27001 certified. Testing frequency should be determined using factors such as risk, technology changes, exposure, business criticality and the organization's testing program.

A VAPT assessment is only as useful as the environment it actually covers.

NuageSEC helps organizations assess web applications, APIs, networks, cloud environments and other critical attack surfaces through vulnerability assessment and expert-led penetration testing.

The focus is not simply on producing a list of vulnerabilities. It is on understanding what can actually be exploited, what the weakness could affect, how it should be remediated, and whether the fix has been successfully validated.

https://www.nuagesec.com/vapt-testing-services

https://www.nuagesec.com/contact

https://www.nuagesec.com/sample-reports

NuageSEC currently positions its VAPT services around applications, APIs, cloud, networks, mobile applications and infrastructure, with reporting and retesting support. NuageSEC