ISO 27001 Across Multiple Locations: How to Get the Scope Right

An ISO 27001 scope should define the parts of the organisation covered by the information security management system. For a business operating across several locations or legal entities, that normally means being clear about the services, information, people, technology, suppliers and interfaces included, rather than simply listing office addresses.

This is one of the earliest decisions in an ISO 27001 programme, and one of the easiest to underestimate.

A scope that is too broad can make the management system difficult to implement and maintain. A scope that is too narrow can leave out dependencies that the certified service relies on. Either problem makes the resulting assurance less useful to leadership, customers and operational teams.

Last week's guide looked at what a board should expect from cyber security and compliance advice. One of the central points was that evidence needs a visible boundary. ISO 27001 scope is where that boundary becomes explicit.

What does ISO 27001 scope mean?

The scope describes the boundary and applicability of the information security management system, or ISMS.

It tells readers which parts of the organisation are managed through that system. Depending on the organisation, it may refer to:

• specific services or business activities;
• legal entities or business units;
• physical and remote locations;
• people and teams;
• information and supporting processes;
• systems, cloud platforms and infrastructure;
• outsourced services and supplier dependencies;
• interfaces with parts of the business outside the scope.

ISO describes ISO/IEC 27001 as a standard for establishing, implementing, maintaining and continually improving an information security management system. The scope therefore concerns a working management system, not just the wording printed on a certificate.

The certification body independently assesses the agreed scope and decides whether certification can be awarded. A consultant can help the organisation define and implement its ISMS, but does not award certification.

Start with the service you need to protect

For a multi-site organisation, the simplest starting point is rarely a map of every office.

Begin with the products, services or business activities that matter to customers and stakeholders. Then identify the information and operational dependencies needed to deliver them.

For example, a professional services group may want the scope to cover delivery of a particular regulated service across its UK, European and North American teams. That service may depend on:

• a central identity platform;
• a shared customer relationship system;
• local laptops and mobile devices;
• a cloud document platform;
• a finance process run by another entity;
• outsourced support or security monitoring;
• home workers and temporary project locations.

The scope should make those relationships understandable. Listing three office addresses while ignoring the shared cloud services and remote workforce would describe only part of the operating reality.

Decide which legal entities and locations are included

An international brand may contain several legal entities with different leadership structures, contracts, employees and local obligations.

Ask:

1. Which entity owns or delivers the in-scope service?
2. Which other entities process its information or operate supporting controls?
3. Which locations perform activities that affect the service?
4. Who has authority to approve policy, risk treatment and accepted risk?
5. Can the organisation demonstrate consistent oversight across the proposed boundary?

One ISMS can cover multiple sites when they operate within a common management system. However, that does not mean every site is automatically identical. Local processes, technology, suppliers and obligations still need to be understood.

The International Accreditation Forum publishes mandatory requirements used by certification bodies for management systems operated by multi-site organisations. The detailed audit and sampling approach belongs with the chosen accredited certification body. Engage that body early where the proposed structure is complex.

Follow shared services across the boundary

Some of the most important scope decisions concern services that sit outside the neat organisational chart.

Consider central IT, human resources, finance, facilities, legal support, cloud platforms and outsourced providers. If an in-scope service depends on one of them, the relationship needs to be addressed even when the supporting team or supplier is not wholly inside the ISMS boundary.

This does not always mean expanding the scope to include the entire supplier or department. It does mean documenting the dependency, defining responsibilities and managing the associated risk.

For example, a subsidiary may be in scope while group IT operates Microsoft 365 and identity services. The subsidiary cannot credibly treat identity as somebody else's issue. The ISMS needs a clear way to specify requirements, obtain evidence, manage changes and escalate failures with group IT.

The same applies to a managed service provider, data centre, payroll provider or specialist software platform. Outsourcing an activity does not remove the need to manage the information security risk.

Avoid an artificially narrow scope

A smaller scope can be a sensible way to begin, particularly when an organisation has several services or entities at different levels of maturity.

The problem comes when the boundary is designed mainly to avoid difficult controls while the certified service still depends on what was excluded.

Warning signs include:

• an office-only scope for a workforce that mainly works remotely;
• a service scope that excludes the shared identity platform;
• excluding a supplier that processes critical information without describing the interface;
• leaving senior decision-makers outside the governance process;
• stating that one entity is covered while marketing implies that the entire group is certified;
• describing a technology platform without the people and processes that operate it.

A defensible scope can be limited. It still needs to be honest about dependencies and exclusions.

Avoid making the first scope impossible to operate

The opposite mistake is to include every company, system, office and activity before the organisation has the resources to manage them consistently.

That can create a programme dominated by document collection and exceptions. Teams may spend months trying to make unrelated processes look identical, even where a risk-based common framework with controlled local variation would be more practical.

Before approving a broad scope, test whether the organisation can:

• assign accountable leadership across it;
• maintain a usable asset and information view;
• apply a consistent risk method;
• implement and monitor the selected controls;
• obtain evidence from each relevant team and supplier;
• run internal audits across the complete boundary;
• complete management reviews with the right decision-makers;
• correct problems and demonstrate continual improvement.

The best scope is not necessarily the largest. It is the boundary that serves the commercial objective and can be governed properly.

Build common controls with visible local differences

Multi-site organisations usually need a common policy and control framework. They also need a controlled way to record differences.

One location may use a separate access-control system. One entity may retain information for longer because of a contractual obligation. A country may use a local supplier or require specialist legal advice. One team may operate a legacy application that needs a temporary treatment plan.

Do not hide these differences inside generic policy wording.

Use a clear control owner, local implementer, evidence source and review point. Record exceptions through the risk and change processes. This gives leadership a consistent view without pretending every location is technically identical.

A simple responsibility structure might show:

This is also where co-managed IT can help. Internal teams, local providers and specialist partners can share delivery, provided ownership and escalation remain explicit.

Write a scope statement people can understand

The final scope statement needs to be precise enough for audit and clear enough for customers and colleagues.

It should identify the in-scope activity and relevant organisational boundary. Supporting ISMS documentation can then explain the locations, systems, dependencies, interfaces and justified exclusions in more detail.

Avoid vague statements such as “all information security activities”. They do not help a reader understand which services or entities are covered.

Also avoid turning the public wording into a long technical inventory. The detailed boundary belongs in controlled documentation. The public description and certificate wording should accurately represent it without implying broader coverage.

Before agreeing the wording, ask:

• Would a customer understand what is covered?
• Could an internal manager identify whether their activity is included?
• Does the wording match the way the service is actually delivered?
• Are central and outsourced dependencies addressed?
• Could marketing accidentally overstate the certification?

Treat scope as a living decision

Scope should be reviewed when the organisation changes.

Triggers include acquisitions, disposals, new offices, cloud migrations, material supplier changes, new products, reorganisations and expansion into another country. The change-management and risk processes should identify when the ISMS boundary, controls, evidence or certification arrangements need attention.

An acquisition is a good example. The new company does not become certified merely because the parent organisation holds a certificate. Leadership needs to decide when and how it enters the ISMS, what needs to change and how external statements will describe coverage during the transition.

This is why the scope belongs in board and management conversations. It determines what the organisation is claiming, what teams must operate and what evidence leaders can rely on.

A practical scoping workshop

A useful scoping workshop should leave the organisation with more than a sentence.

It should produce:

1. The business objective for certification or assurance.
2. A view of the in-scope services, entities and locations.
3. Key information, systems and supplier dependencies.
4. Interfaces with people or activities outside the boundary.
5. Leadership roles and risk decision authority.
6. Known local differences and specialist advice required.
7. A draft scope statement and assumptions to validate.
8. A plan for confirming the approach with the certification body.

Cloud Agile supports ISO 27001 readiness and implementation for organisations operating across locations. We help define a workable scope, build the management system, implement supporting controls and prepare evidence for an independent certification audit.

Define the boundary before you build the programme. Discuss your ISO 27001 requirements with Cloud Agile.

Frequently asked questions

Can ISO 27001 cover several offices or countries?

Yes. An ISMS can cover defined activities across multiple locations or countries. The organisation needs a clear common management system, visible local differences and evidence that the relevant controls operate across the full scope.

Can one ISO 27001 certificate cover several legal entities?

It can, depending on the organisational structure and agreed certification scope. Define which entities and activities are included, how leadership authority works and how shared services are managed. Confirm the proposed certification arrangement with the accredited certification body.

Does every location need identical security controls?

The organisation needs a consistent way to manage risk and control requirements. Implementation can vary where the context justifies it. Differences should be recorded, owned and supported by appropriate evidence.

Can we certify one service before the rest of the business?

Potentially. A service-based scope can be appropriate if its boundary, dependencies and interfaces are clear. Public claims must accurately describe the limited scope and should not imply that the whole organisation is certified.

Are suppliers outside the ISO 27001 scope?

A supplier may sit outside the organisational boundary, but the risks and responsibilities associated with its service still need to be managed where it supports the in-scope activity.

Who decides the ISO 27001 certification scope?

The organisation proposes and operates the ISMS scope. Its certification body reviews the scope as part of the independent certification process. A consultant can advise on practicality, implementation and readiness but does not award certification.