ISO 27001 Scope Examples 2026: Define Your Information Security Perimeter

ISO 27001 Scope Examples 2026: Define Your Information Security Perimeter

Defining the scope of your Information Security Management System (ISMS) is one of the most consequential decisions you'll make during ISO 27001 certification. A poorly defined scope can lead to audit findings, leave critical assets unprotected, or create unnecessary overhead by including systems that don't require formal controls. This guide walks through real-world scope scenarios to help you establish boundaries that are both defensible and practical.

What Does "Scope" Mean in ISO 27001?

Scope is the boundary of your ISMS—it defines which assets, processes, locations, and stakeholders fall under your formal information security program. The standard requires organizations to establish the scope in clause 4.3 and communicate it clearly to all relevant parties. Scope determines which assets you assess for risk, which controls you must implement, and what your auditor will evaluate.

Your scope should be proportionate to your organization's structure, regulatory obligations, and risk profile. It doesn't have to cover everything you do—but whatever sits inside the boundary must be properly managed.

Real-World Scope Examples by Organizational Type

Example 1: Mid-Sized Professional Services Firm

In scope:

• Corporate office network and all workstations
• Cloud-hosted project management platform (SaaS)
• Email and document storage systems
• Client-facing consulting portal
• All employees and contractors working on client projects

Out of scope:

• Marketing website (managed by third-party vendor; contractual security requirements apply separately)
• Break-room Wi-Fi guest network
• Disaster recovery site at secondary location (managed by external DR provider with SLA)

Rationale: The firm's core business depends on protecting client data and intellectual property. The boundary includes all systems that handle sensitive information; the website and guest network are isolated from client work, and the DR provider operates under a separate agreement with defined responsibilities.

Example 2: Retail Organization with Multiple Locations

In scope:

• Corporate head office and its IT infrastructure
• Point-of-sale (POS) systems at all 30 retail outlets
• Payment card data processor (integrated with POS)
• Central inventory and HR systems
• Remote managers accessing systems via VPN

Out of scope:

• HVAC and physical access control systems (managed by facilities contractor; physical security handled via separate process)
• Customers' personal devices connecting to store Wi-Fi (only organizational devices and guest network terms apply)

Rationale: Payment card industry compliance and inventory integrity are critical. Remote work is included because managers access production systems. Facilities systems don't process sensitive data and are managed by a specialist contractor, so they're excluded with appropriate contractual controls.

Example 3: SaaS Startup

In scope:

• Cloud infrastructure hosting the SaaS application (AWS/Azure)
• Customer databases and all data pipelines
• API endpoints and authentication systems
• Development, staging, and production environments
• All engineering and operations staff
• Third-party integrations that access customer data

Out of scope:

• GitHub repositories (version control platform managed by GitHub; access controls and audit logging enforced by policy)
• Email and HR systems (supporting functions; covered by separate vendor security agreements)

Rationale: The SaaS product and its infrastructure are the organization's only material asset. All environments and integrations handling customer data must be in scope. Development tools and supporting functions are excluded but governed through vendor contracts and access policies.

Example 4: Healthcare Provider

In scope:

• Electronic health record (EHR) system and database
• Medical imaging and laboratory systems that feed into EHR
• Telemedicine platform and associated video conferencing
• Patient scheduling and billing systems
• All clinical and administrative staff with system access
• Off-site telehealth clinics (connected via secure network)

Out of scope:

• Paper-based patient records held in clinic storage (physical security and retention covered by separate document management policy)
• Call center outsourced to third party (scope limited to inbound call routing; third party certified separately; data handling governed by Business Associate Agreement)

Rationale: Protected health information (PHI) is highly regulated. All systems and staff that access PHI must be in scope. Telemedicine expansion is explicitly included to address remote clinical workflows. Paper records and outsourced call centers are managed under specific agreements with documented controls.

Third-Party and Cloud Boundaries

One of the most common scope challenges involves determining what to include when you rely on external vendors or cloud services.

The Shared Responsibility Model

Cloud providers (AWS, Azure, Google Cloud) publish shared responsibility matrices that show which security controls they provide and which you must implement. Your scope should include the infrastructure and configurations under your responsibility, but not the provider's physical data center, hypervisor, or network backbone. Instead, document the provider's responsibilities in your risk assessment and contractual agreements.

For SaaS applications (Salesforce, HubSpot, Slack), the provider typically handles security operations. Your scope should include your organization's configuration, access controls, and data handling practices—not the application's underlying architecture.

Contractor and Remote Work Scope

If contractors or remote employees access in-scope systems, they must be included in your ISMS scope. This means:

• Device security requirements apply to their machines
• Access control policies govern what they can reach
• Security awareness training is mandatory
• Audit trails include their activity

The geographic location of remote staff (home office, coffee shop, international location) doesn't exclude them—but it may affect risk assessments and control implementation.

Common Scope Mistakes and How to Avoid Them

Mistake 1: Scope Too Narrow – Including only IT systems but excluding business processes that handle sensitive information. Many organizations forget to include facilities access, physical security, or third-party data handling. Auditors will identify unmanaged risks and issue findings.

Mistake 2: Scope Too Broad – Including everything "just to be safe." This inflates the control burden and makes certification unmanageable. Scope creep often happens when organizations don't clearly separate in-scope systems from those managed under different programs (e.g., separate PCI DSS scope for payments).

Mistake 3: Failing to Document Exclusions – Simply excluding something without documented justification. The standard requires you to clearly state what's out of scope and explain why. If an auditor finds an unmanaged risk that should have been scoped, it's a non-conformity.

Mistake 4: Ignoring Changes – Scope defined during initial certification but not updated as the business evolves. New cloud services, remote work arrangements, third-party integrations, and M&A activity all affect scope. Review scope annually and update it formally before the next audit.

How to Document Your Scope

Create a scope statement that includes:

• Assets in scope: Systems, applications, data types, locations
• People in scope: Employees, contractors, partners with system access
• Assets explicitly out of scope: List these clearly with rationale
• Boundary diagram: Visual representation of what's included
• Third-party responsibilities: Table showing shared controls and owner
• Approval and sign-off: By management and relevant stakeholders

This document becomes your baseline. During internal audits and management reviews, use it to verify that all in-scope assets are receiving controls, and that excluded assets are properly justified.

Scope and Risk Assessment

Your scope directly drives your risk assessment. Once boundaries are set, you must identify all assets within scope, list potential threats, and evaluate likelihood and impact. Assets outside scope are not formally assessed—but they may influence residual risk decisions or regulatory compliance obligations.

When implementing ISO 27001, scope and risk assessment are iterative. You may discover during risk assessment that you need to adjust scope, or that a system initially considered low-risk actually requires inclusion. Document these decisions and maintain traceability.

Scope Considerations for 2026

Several trends are reshaping how organizations define ISMS scope:

• AI and automation tools: Many organizations are rapidly adopting AI for business processes. If these tools process, store, or transmit sensitive data, they must be in scope.
• Hybrid and multi-cloud: Data spanning multiple cloud providers and on-premises infrastructure requires careful boundary definition and shared responsibility mapping.
• Supply chain scrutiny: Regulators and customers increasingly demand visibility into third-party security. Scope often needs to expand to include vendor risk management and integration monitoring.
• Remote work permanence: Most organizations now accept that remote and hybrid work is permanent. Scope must reflect ongoing distributed access patterns.

Next Steps: Defining or Refining Your Scope

Before beginning your ISO 27001 journey or audit cycle, convene stakeholders from IT, operations, compliance, and business leadership to map your current environment. Identify all systems that process, store, or transmit sensitive information, and clearly document what's in and out of scope.

If you're uncertain about scope boundaries, or if a previous audit identified scope-related findings, now is the time to clarify. The scope statement should be approved by management and communicated to all staff involved in the ISMS.

We can help you define, validate, or refine your ISMS scope as part of a certification or audit-readiness engagement. Contact us to discuss your environment and receive a proposal tailored to your organization's size, complexity, and regulatory requirements.

Frequently asked questions

Can I change my ISMS scope after certification?

Yes. Scope changes are normal as organizations grow or evolve. Any significant change should be documented, approved by management, and communicated to your auditor in advance of the next audit. Minor changes (e.g., adding a server to an existing network) can be captured in management review; major additions (e.g., opening a new office or acquiring a company) require formal scope revision and risk reassessment.

Does ISO 27001 require me to include all remote workers in my ISMS scope?

If remote workers access in-scope systems or process in-scope data, yes—they are part of your ISMS scope. This means their devices, access credentials, and working environment are subject to your security policies. However, you don't need to physically secure their home offices; instead, you implement controls appropriate to remote access (VPN, encryption, screen privacy, clean desk policies).

Is a third-party SaaS tool automatically out of scope?

Not necessarily. A third-party SaaS platform is out of scope only if it doesn't process or store your in-scope data, and if the vendor's security obligations are clearly documented in a contract. If you use SaaS to manage customer data, financial records, or intellectual property, your use of that SaaS instance is in scope—even if the vendor's infrastructure is not.

What happens if an auditor finds an asset I didn't include in my scope?

If an auditor identifies an asset that handles sensitive data but was not included in your scope, it's typically cited as a non-conformity. You'll be asked to either (a) formally expand your scope and implement controls, or (b) provide documented justification for exclusion. Either way, the risk must be addressed. This is why a thorough asset inventory and clear scope documentation are critical.