ISO 27001 Clause 4.3: Defining ISMS Scope

Clause 4.3 requires you to define the boundaries and applicability of your ISMS - what is in scope, what is out, and why. Your scope statement drives everything that follows: risk assessments, control selection, audit boundaries, and certification decisions. A scope that is too narrow leaves gaps. Too broad and you will burn resources on areas that do not matter.

What the clause requires

ISO 27001:2022 Clause 4.3 asks you to:

1. Determine the boundaries and applicability of your ISMS
2. Consider external and internal issues identified in your context analysis (Clause 4.1)
3. Consider the requirements of interested parties (Clause 4.2)
4. Consider interfaces and dependencies between your activities and those performed by other organizations
5. Document the scope and make it available as documented information

The 2022 revision kept Clause 4.3 largely unchanged from the 2013 version. But the strengthened notes in Clauses 4.1 and 4.2 - particularly around legal, regulatory, and contractual obligations - mean the inputs to your scope definition now carry more weight during audits.

How to define your ISMS scope

Start with the outputs from your context analysis and interested party register. These tell you what environment you operate in and what stakeholders expect from your information security. From there, work through four questions.

What services and processes handle information?

List the products, services, and business processes that create, store, process, or transmit information. For a SaaS company, this typically includes your core application, customer support workflows, and development pipeline. For a professional services firm, it might be client project delivery and internal knowledge management.

What systems and locations support those services?

Map the technology and physical infrastructure behind your services. This includes cloud platforms, internal networks, development environments, offices, and remote worker setups. If your team works across three countries using AWS eu-west-1, that is all potentially within scope.

Where do your responsibilities end?

Identify interfaces with other organizations. Your cloud provider manages the underlying infrastructure (their scope), while you manage the configuration and data (your scope). Payment processing happens through Stripe (their scope) but you control what data you send them (your scope). These boundaries need to be explicit.

What is excluded and why?

Document what falls outside your ISMS and justify each exclusion. Valid exclusions have clear reasoning - a static marketing website with no customer data, office building maintenance handled by a landlord, or a legacy product that is being decommissioned. Convenience is not a valid reason for exclusion.

Writing the scope statement

Your scope statement should be clear enough that an auditor can understand it in under a minute. Here is what a practical scope statement looks like for a 30-person SaaS company:

“The ISMS applies to the development, operation, and support of [product name], including cloud infrastructure hosted on AWS EU regions, the development and support teams working remotely across the EU, and all customer data processed through the platform. Excluded: corporate marketing website (static site, no customer data processed), office facilities management (managed by landlord under separate contract).”

A scope statement for a 200-person financial services firm would be broader, covering specific departments, regulatory obligations, and multiple office locations. The principle remains the same: clear boundaries, explicit exclusions, documented justifications.

Connecting 4.3 to the rest of your ISMS

Clause 4.3 sits between context analysis and ISMS establishment. It takes inputs from Clauses 4.1 and 4.2 and sets the boundaries for everything that follows.

Clause 4.1 connection. Your organizational context identifies the environment you operate in - legal requirements, industry dynamics, internal capabilities. If your context analysis shows you process healthcare data under specific regulations, that shapes which systems must be in scope. If you operate across EU member states, NIS2 obligations may expand your scope beyond what you initially planned.

Clause 4.2 connection. Your interested party analysis identifies specific requirements from customers, regulators, and partners. A key customer requiring that all their data stays within the EU means your US development environment is either excluded from scope (if it never touches customer data) or must be brought into scope with appropriate controls.

Clause 4.4 connection. Your scope defines what the ISMS covers when you establish and maintain it (Clause 4.4). Every process, procedure, and control in your ISMS operates within the boundaries you set here.

Clause 6.1 connection. Risk assessment happens within your defined scope. Risks outside scope boundaries do not need formal treatment through the ISMS - but excluding an area specifically to avoid addressing known risks is something auditors will challenge.

Statement of Applicability. Your SoA maps Annex A controls to the scope you have defined. If you exclude a process from scope, the controls that would apply to that process can be legitimately excluded from your SoA - provided the exclusion itself is justified.

What auditors check

Auditors treat Clause 4.3 as a foundational check that validates the rest of your ISMS. Here is what they look for:

Documented scope statement. This must exist as formal documented information. A verbal explanation or an informal wiki page is not sufficient for certification.

Alignment with 4.1 and 4.2 outputs. Auditors cross-reference your scope against your context analysis and interested party register. If your context analysis identifies GDPR as a relevant external issue but your scope excludes the systems that process personal data, they will flag the inconsistency.

Justified exclusions. Every area excluded from scope needs a documented reason. Auditors are trained to look for exclusions that conveniently avoid difficult controls. Excluding your development environment because “developers do not handle customer data” only works if that is demonstrably true.

Operational reality. Auditors walk the scope during certification. If your scope says “Berlin office” but half your team works from home, they will question whether remote work should be in scope. The scope statement must match how the organization actually operates.

Third-party interfaces. Auditors check that you have identified where your responsibilities end and third-party responsibilities begin. This is particularly important for cloud-hosted implementations where the shared responsibility model needs clear documentation.

Common mistakes to avoid

Scoping too narrowly to pass easily. Some organizations scope their ISMS to a single team or product to minimize the certification effort. This works initially, but customers and regulators expect the ISMS to cover the services they actually use. A certificate covering only your HR department does not satisfy a customer asking about the security of your SaaS platform.

Scoping too broadly without resources. Declaring that your entire organization is in scope sounds thorough, but if you cannot resource the controls, training, and audit program across that entire scope, you will fail during surveillance audits when auditors find gaps in areas you claimed to cover.

Forgetting remote workers. If your team works remotely - even partially - remote work environments are likely in scope. This includes home networks, personal devices (if used for work), and the VPN or zero-trust architecture that connects remote workers to company systems.

Not updating scope after changes. Business changes trigger scope reviews. New offices, acquisitions, new products, changes in cloud providers, or entering new markets all potentially affect your ISMS scope. Build scope review into your management review agenda and your PDCA cycle.

Ambiguous language. A scope statement that says “IT systems supporting the business” is too vague. Auditors and customers need to know exactly which systems, which locations, and which services are covered. Specificity avoids disputes during audits and builds customer confidence.

How 27kay can help

We help organizations define their ISMS scope as part of ISO 27001 implementation - working through the context analysis, interested party requirements, and system boundaries to arrive at a scope that is defensible, practical, and aligned with your business objectives. For more on the full standard, see our ISO 27001 knowledge hub.

Not sure whether your scope is right? Get in touch - we will review your scope statement and tell you whether it holds up under audit scrutiny.