ISO 27001 Determining the Scope of the Information Security Management System | Clause 4.3 | The Lead Auditor’s Implementation and Audit Guide

ISO 27001 Clause 4.3 Determining The Scope Of The Information Security Management System is a security control that dictates how organizations define their ISMS boundaries. Analyzing internal and external issues provides clear demarcations, delivering the Business Benefit of reduced compliance costs and streamlined audits.

In this guide, I will show you exactly how to implement ISO 27001 Clause 4.3 and ensure you pass your audit. You will get a complete walkthrough of the control, practical implementation examples, and access to the ISO 27001 templates and toolkit that make compliance easy.

I am Stuart Barker, an ISO 27001 Lead Auditor with over 30 years of experience conducting hundreds of audits. I will cut through the jargon to show you exactly what changed in the 2022 update and provide you with plain-English advice to get you certified.

Key Takeaways

• The scope should reflect what you want to be shown on your ISO 27001 certificate
• Narrowing scope will remove undue cost and bureaucracy
• Getting the scope wrong can cost a lot of time and lot of money

What is ISO 27001 Clause 4.3?

ISO 27001 Clause 4.3 Determining The Scope Of The Information Security Management System is an ISO 27001 clause that requires you to define the scope of your information security management system.

Purpose and Definition

The purpose of ISO 27001 Clause 4.3 Determining The Scope Of The Information Security Management is to ensure a clear and well-defined scope for your Information Security Management System (ISMS) and your subsequent ISO 27001 certification. This clarity helps establish:

• Which parts of the organisation are included within the boundaries of the ISMS.
• The specific areas that will be assessed during the ISO 27001 certification audit.

By defining the scope, you can ensure that your ISMS is focused on the most critical areas and that your certification accurately reflects the extent of your information security efforts.

The ISO 27001 standard defines ISO 27001 Clause 4.3 Determining The Scope Of The Information Security Management as:

The organization shall determine the boundaries and applicability of the information security
management system to establish its scope.
When determining this scope, the organization shall consider:
a) the external and internal issues referred to in 4.1;
b) the requirements referred to in 4.2;
c) interfaces and dependencies between activities performed by the organization, and those that are
performed by other organizations.
The scope shall be available as documented information.

ISO27001:2022 Clause 4.3 Determining The Scope Of The Information Security Management System

1. Establish scope by determining the boundaries and applicability of the information security management system: There is a cost in time, resource and money to implement ISO 27001 so it makes sense to concentrate on protecting the things that your clients are expecting to you to protect and the things that represent the biggest risk to you. I will show you how to do this later in the article.
2. Consider your internal and external issues: When you set the scope you are making sure that you have addressed the internal and external issues that we covered in ISO 27001 Clause 4.1 Understanding the Organisation and It’s Context.
3. Consider the needs an expectations of interested parties: The interested parties and their requirements which we covered in ISO 27001 clause 4.2 Understanding the Needs and Expectations of Interested Parties will be reviewed on if, and how, they affect the scope you are setting.
4. Consider what you do verses what other people do for you: Third parties will be used a lot and those third parties will be responsible for the areas that they control so you will define the interfaces and dependencies between activities you do and activities that they do.

The Golden Thread: Linking Context to Scope

In ISO 27001, we talk about the “Golden Thread.” This is the logical link that must exist between your Context (Clause 4.1), your Interested Parties (Clause 4.2), and your Scope (Clause 4.3). If a risk appears in your context, the auditor expects to see a corresponding boundary in your scope.

Consider these real-world examples of how context dictates your scope boundary:

• The Pandemic Effect: If your context identifies “Remote Working” as a permanent internal issue, your scope boundary can no longer stop at the office front door. It must extend to include remote endpoints and home-working environments.
• New Legislation (e.g., DORA or NIS2): If a new law is identified in your external issues, your scope must be widened to include every ICT system and supply chain partner mandated by that regulation.
• Cloud Migration: If your strategic context is “Cloud First,” your scope must explicitly define the interface between your internal team and the CSP (Cloud Service Provider).

ISO 27001 Clause 4.3 Free Training Video Tutorial

In the video ISO 27001 Determining Scope Of The ISMS Explained – ISO27001:2022 Clause 4.3 I show you how to implement it and how to pass the audit.

If you want to understand how to define your ISMS boundaries without the corporate jargon, watch this free training video. I walk you through the exact process we use with our consultancy clients to ensure their scope is audit-ready in record time.

In this session: Defining boundaries, managing third-party interfaces, and avoiding the “Over-Scoping” trap.

ISO 27001 Clause 4.3 Explainer Video

In this strategic implementation briefing for ISO 27001:2022 Clause 4.3 Determining The Scope Of The Information Security Management System, ISO 27001 Lead Auditor Stuart Barker and his team talk you through what it is, how to implement in and how to pass the audit.

ISO 27001 Clause 4.3 Podcast

Getting the Scope wrong is the single most expensive mistake you can make in ISO 27001. In this episode of The Lead Auditor Podcast, Stuart Barker (Principal Architect & Former Lead Auditor) deconstructs ISO 27001:2022 Clause 4.3. We move beyond the textbook definition to reveal the strategic architecture of scoping.

How Clause 4.3 Applies to Different Business Models

Business Type	Applicability	Why it is Important	Clause 4.3 Scope Examples (Boundaries & Exclusions)
Small Businesses	High / Essential	Small businesses often have limited budgets; a tightly defined scope ensures you aren’t paying to secure non-critical parts of the business.	Boundaries: All physical offices and remote staff. Exclusions: Shared building facilities or outsourced payroll processing.
Tech Startups	Strategic / Scalable	A clear scope allows startups to scale fast. It demonstrates to investors exactly which assets (usually the core IP and customer data) are protected.	Boundaries: SaaS platform infrastructure, DevOps environments, and source code. Exclusions: Third-party marketing agencies or co-working spaces.
AI Companies	Complex / Critical	Defining the scope is vital to ensure the entire data lifecycle—from ingestion to model training—is covered under the ISMS security controls.	Boundaries: Data lakes, GPU compute clusters, and proprietary algorithm repositories. Exclusions: Publicly available datasets used for general pre-training.

How to Define Your ISMS Scope: A Step-by-Step Guide

Scope is vitally important for your ISO 27001 Certification. It clearly sets out what we are going to apply our information security management system to and more importantly it defines what will go on our ISO 27001 certificate.

Determining your scope effectively can be challenging. To assist you, we’ve created a comprehensive guide: How To Define ISO 27001 Scope.This guide provides clear, step-by-step instructions to help you establish a well-defined scope.

We’ve included an ISO 27001 Scope Statement Template within our ISO 27001 Toolkit. This template can be used as a valuable resource to assist in the development of your official scope statement.

Based on practical, real world implementations and experience this is how to implement ISO 27001 Clause 4.3 Determining The Scope Of The Information Security Management System (ISMS):

Step 1: Define Organisational Boundaries

Clearly identify where the organisation’s boundaries lie, especially in complex or multi-national organisations.

• Utilise organisational charts, legal documents, and stakeholder interviews to define the organisational structure.
• Consider third-party relationships and their impact on information security.

Step 2: List all your products and services

List out all of the products and services that you have and document them.

• Conduct workshops with key interested parties (e.g., management, product owners, sales) to identify and document core offerings.
• Utilise process mapping and data flow diagrams to visualise the flow of products and services.

Step 3: Ask your customers which products and services they expect to be in scope

From your list of products and services ask your customers which of them they expect to be in scope. Review current contracts for any scope requirements.

Step 4: Ask your leadership team which products and services they expect to be in scope

From your list of products and services ask your leadership team which of them they expect to be in scope.

Step 5: Ask the list of interested parties which products and services they expect to be in scope

From your list of products and services ask your interested parties which of them they expect to be in scope.

Step 6: Document the list of products and services that are in scope

Taking the input from customers, leadership and interested parties document the list of products and services that are in scope.

Step 7: Review your internal and external issues

Review the products and services that are in scope against the list of internal and external issues to determine if their are any direct issues or changes to issues.

Step 8: Confirm the list of of products and services that are in scope

Agree and sign off the scope with the senior leadership team and document the agreement.

Step 9: Identify Supporting Functions

Determine which departments and functions are critical to the delivery of core products and services.

• Analyse organisational structure and identify departments that directly or indirectly support core business functions.
• Consider departments like IT, HR, finance, legal, and facilities.

Step 10: Determine Scope Exclusions

Identify activities, departments, or systems that will be explicitly excluded from the scope of the ISMS.

• Clearly document the rationale for any exclusions.
• Ensure that excluded areas do not pose significant risks to the organisation’s information security.

Step 11: Document and understand the ISO 27001 Scope Boundaries

Identifying the people, premises, technology, and suppliers that directly support the in-scope products and services and understand the interfaces between in scope entities and out of scope entities as well as with third party organisations.

Step 13: Write your ISO 27001 Scope Statement

Summarise your scope in the required ISO 27001 scope statement.

• Use clear and concise language.
• Obtain input and approval from key interested parties.
• Regularly review and update the scope statement to reflect changes in the organisation or its environment.

Step 14: Communicate Scope to Stakeholders

Ensure that all relevant stakeholders understand the scope of the ISMS and their roles and responsibilities within it.

• Conduct training sessions and awareness campaigns.
• Distribute the scope statement to all employees.
• Include the scope statement in relevant policies and procedures.

Step 15: Obtain Management Approval

Secure management approval for the defined scope of the ISMS.

• Present the proposed scope to management and address any concerns or questions.
• Obtain formal approval from top management.

Step 16: Verify the scope statement with the certification body (optional)

Share your ISO 27001 scope statement with the external ISO 27001 certification for feedback and confirmation.

How to define interactions with third parties

Clause 4.3 explicitly mandates that you consider the ‘interfaces and dependencies’ between what you do and what others do for you. This is the “Handshake.” You must document exactly where your security responsibility ends and your supplier’s begins. If you simply say ‘We use the Cloud,’ you will fail. I need to see the demarcation line.

To define these interactions for your audit, you must map three specific areas:

• Logical Interfaces: How does data flow between you and the third party? Is it an API? An SFTP site? A manual upload?
• Physical Interfaces: Who has access to your premises? Do you have contractors on-site? How is their access managed at the perimeter?
• Operational Dependencies: If your ISP goes down, does your ISMS stop functioning? These dependencies must be identified here so they can be addressed in your Risk Assessment (Clause 6.1).

The Shared Responsibility Matrix (The Handshake)

In a modern ISMS, you are rarely 100% responsible for every control. Use this table to define your interfaces within your Clause 4.3 documentation. This is exactly what I look for during a Stage 2 audit to prove you understand your boundaries.

Control Area	Your Responsibility	Third Party Responsibility
Physical Security	Office access and desk policy.	Data centre perimeter and rack security (e.g., AWS/Azure).
Application Security	Secure coding and user permissions.	Patching of the underlying OS or PaaS platform.
Data Protection	Classification and encryption keys.	Durability and physical storage media disposal.

What an Auditor Looks For: Supplier Boundaries

When I review your Clause 4.3 evidence, I am checking for “Supply Chain Blindness.” If you have a critical dependency that isn’t mentioned in your scope, your risk management is flawed. Here is my Lead Auditor checklist:

• The Contractual Hook: Do your contracts with third parties reflect the boundaries you’ve set in Clause 4.3? If you say they are responsible for backups, does the contract actually say that?
• The “Out of Scope” Trap: Don’t exclude a supplier just because they are “Big” (like Microsoft). They are still an interface. You must define what you consume from them.
• Right to Audit: For high-risk interfaces, do you have the right to verify their security? If the interface is critical, I expect to see a SOC2 report or an ISO 27001 certificate from them.

Lead Auditor Pro Tip: Your scope statement should include a sentence like: “The ISMS includes the management of interfaces with key third-party service providers as defined in the Supplier Inventory.” This one sentence saves you ten minutes of arguing with an auditor.

How to document Scope

Your scope statement is the heart of your certification. It is the text that will eventually be printed on your ISO 27001 certificate. If it is poorly documented, you risk misleading your customers or, worse, failing your Stage 1 audit because the auditor cannot identify what they are supposed to be testing.

A professionally documented scope statement must include four key elements:

• The Legal Entity: Clearly state the name of the company or the specific business unit being certified.
• The Services/Products: Define exactly what the ISMS protects (e.g., “The provision of cloud-based payroll services”).
• The Physical and Logical Boundaries: Mention your primary locations and your core infrastructure (e.g., “Operating from the Leeds head office and utilizing AWS Dublin regions”).
• The Exclusions: If you are excluding a department or a location, you must document the justification. “We just didn’t want to include them” is not a valid justification.

The Auditor’s Requirement: Version Control

Clause 4.3 is not a one time document. It is a living record. When I audit your documentation, I look for the “Evidence of Governance.” If your scope statement is a random Word file on a desktop with no version history, you have a problem with Clause 7.5 (Documented Information).

Requirement	Stuart Barker’s “Pass” Criteria
Identification	The document has a clear title, date, and unique reference number.
Review & Approval	Evidence that the scope has been reviewed by the CISO and approved by the CEO.
Accessibility	The scope is available to all employees who need to know the ISMS boundaries.

What an Auditor Looks For: The “Reality Gap”

When I review your documented scope, I am looking for the “Reality Gap.” This is the space between what your document says and what your staff actually do. Here is my Lead Auditor checklist for your documentation:

• Consistency Check: Does the scope on your website match the scope in your internal manual? If they differ, your documentation is out of control.
• The “Everything” Trap: Avoid using the word “Everything.” It is impossible to secure “everything.” Be specific about your assets and processes.
• Language Clarity: Is the scope written in plain English? If it is full of marketing fluff, the auditor will dig deeper to find out what you are hiding.

Lead Auditor Pro Tip: Keep your documented scope statement to under 100 words. The shorter it is, the less room there is for an auditor to find a contradiction. If you need to explain the detail, do that in your “Context of the Organisation” document, not the Scope Statement.

How to Approve Your ISO 27001 Scope

Approval is not just a signature on a page; it is the moment your leadership team accepts the risk and responsibility for the boundaries you have drawn. Under Clause 5.1 (Leadership and Commitment), top management must demonstrate they are ‘all in.’ If they haven’t formally approved the scope defined in Clause 4.3, your certification will fail at the first hurdle.

To get your scope approved correctly, follow these three non-negotiable steps:

• The Scoping Workshop: Present the draft boundaries to the board or senior leadership. Explain exactly what is IN and what is OUT. If they don’t understand the exclusions, they can’t approve them.
• Formal Minute Recording: Approval should happen during a Management Review Meeting or a dedicated Security Steering Group. Ensure the decision is recorded in the minutes. An auditor will ask to see these.
• The Versioned Sign-Off: Your Scope Statement should have a version history and an approval block. I expect to see a name, a role (typically the CEO or CISO), and a date.

What an Auditor Looks For: Approval Evidence

When I sit down for a Stage 1 audit, I am looking for the ‘Paper Trail of Authority.’ I want to see that the scope wasn’t just made up by the IT Manager in a vacuum. Here is my audit checklist for scope approval:

Evidence Point	The Lead Auditor’s Verdict
Board Minutes	Does the minute state “The Board reviewed and approved the ISMS Scope v1.2”? If not, it didn’t happen.
Policy Alignment	Does your Information Security Policy reference the approved scope? The two must be in total sync.
Resource Allocation	If management approved a global scope but only gave you a local budget, they haven’t actually approved the scope. They’ve set you up for failure.

The Golden Thread: Why Approval Cannot Be Delegated

In my 30 years of auditing, the ‘Empty Suit’ syndrome is the most common cause of failure. This happens when a CEO signs a scope statement they haven’t read. During the audit, I will interview ‘Top Management.’ If I ask the CEO to describe the ISMS boundaries and they point at the IT guy, they have failed the leadership requirements of Clause 5.1.

Lead Auditor Pro Tip: Approval is a two-way street. Leadership must approve the scope, but the ISO 27001 Lead must ensure that scope is actually achievable with the resources provided. Don’t let management approve a ‘Gold Plated’ scope if they are only providing ‘Bronze’ level funding.

ISO 27001 Scope Statement Example

An example ISO 27001 Scope Statement:

The scope of this Information Security Management System (ISMS) encompasses all products and services offered by [Organisation Name], as outlined in [link to product/service catalogue or relevant document]. The implementation of controls is detailed within the Statement of Applicability, version [version number].

In practice:

A practical example, taken directly from our ISO 27001 certification, is:

Information security consultancy and virtual chief information security officer services in accordance with the statement of applicability version 2.1

High Table ISO 27001 Scope Statement

10 Real-World ISO 27001 Scope Statement Examples

To help you draft your own documented information, here are 10 examples of scope statements across various industries. Remember, clarity is the priority.

1. Software as a Service (SaaS): “The scope of the ISMS includes the development, maintenance, and hosting of the [Product Name] platform, including all customer data stored within the AWS Production Environment.”
2. Professional Services: “Provision of legal and consultancy services, including all supporting IT infrastructure and physical offices located at [Address].”
3. Managed Service Provider (MSP): “Management and monitoring of client infrastructure, including the helpdesk operations, remote management tools, and onsite support staff.”
4. FinTech Startup: “The ISMS encompasses the [App Name] mobile application, the underlying API architecture, and the payment processing gateway interfaces.”
5. E-commerce: “Security of the online retail platform, including the checkout process, warehouse management systems, and customer database.”
6. Healthcare Provider: “Protection of patient records and diagnostic data within the [System Name], including all medical devices connected to the internal hospital network.”
7. Manufacturing: “The ISMS covers the design and production of [Product], specifically protecting the intellectual property on the CAD servers and the PLC controllers on the factory floor.”
8. Education: “The administration of student records and the delivery of online learning modules via the University Virtual Learning Environment (VLE).”
9. AI Development: “The lifecycle of AI model training, including data ingestion pipelines, GPU compute clusters, and the proprietary algorithm repository.”
10. HR & Payroll Outsourcing: “Processing of employee payroll data and benefits administration, including the secure transfer of data to HMRC and third-party pension providers.”

How to Legally De-scope to Reduce Audit Costs

One of the biggest secrets in ISO 27001 implementation is that a smaller scope usually leads to a more effective system and a significantly lower audit fee. As a Lead Auditor, I see many organisations pay for five days of auditing when they only needed three. Strategic de-scoping is the art of removing non-critical business units without compromising your security posture.

Lead Auditor Rules for De-scoping

You can legally exclude parts of your organisation if you can prove to me that they do not impact the security of the primary in-scope assets. Use these three strategies to lean out your ISMS:

Lead Auditor Pro Tip: If you de-scope a department, you must ensure there is a “Logical Firewall” between them and your in-scope data. If the excluded Marketing team has access to the Production SQL database, your de-scoping will be rejected as a Major Non-Conformity.

Stuart Barker, Lead Auditor

Scoping the “Grey Areas”: BYOD, Slack, and Shadow IT

In 2026, the boundary of an organisation is rarely a physical wall. To satisfy Clause 4.3, you must address the three “Invisible Boundaries” that most companies miss:

• Shared Client Environments: If your team works inside a client’s AWS tenant or Jira board, is that in your scope?
  
  The Answer: The activity of your staff is in scope, but the infrastructure is an external interface. Document this specifically to avoid being held responsible for the client’s security failures.
• Shadow AI (ChatGPT/Claude): If your developers use AI to write code, those tools are now part of your logical boundary. You must define the interface with these LLMs or explicitly exclude them via a “Blocked Service” policy.
• Hybrid Work / Home Offices: Do not scope the employee’s house. Instead, scope the Endpoint and the VPN Tunnel. This moves the boundary from a physical location you cannot control to a logical asset you can.

ISO 27001 Scope Template

The ISO 27001 Scope Template provides a structured framework for defining the scope of your Information Security Management System (ISMS), fully meeting the requirements of ISO 27001 Clause 4.3.

It was designed and built with these key features:

• Pre-filled with common scope examples: Provides a solid foundation and saves you time.
• Available as an individual download: Offers flexibility for specific needs.
• Included in the internationally acclaimed ISO 27001 Toolkit: Access a comprehensive suite of templates and resources to streamline your entire implementation process.

Why Climate Change Matters for ISO 27001 Clause 4.3

As an ISO 27001 Lead Auditor, I see too many organisations treating Clause 4.3 as a “set and forget” exercise. That is a mistake that will lead to a minor non-conformity in your next audit. Following the February 2024 Amendment 1, you are now mandated to consider climate change when determining your scope.

If your Clause 4.1 context identifies climate risks but your Clause 4.3 scope statement ignores them, your Management System is disconnected. You cannot claim to have an effective ISMS if the boundaries of your security do not account for the very real physical and transition risks posed by a changing climate.

The standard now requires you to determine if climate change is a relevant issue. If it is, that relevance must flow directly into your scope. You are defining the “where” and the “what” of your security. If your “where” is a flood zone or an area with an unstable power grid due to extreme heat, your scope must reflect that reality.

Strategic Impact of Climate Change on ISMS Boundaries

Climate Factor	Impact on Clause 4.3 Scope	Auditor’s Expectation
Physical Risk (Flooding/Fire)	Mandatory inclusion of specific geographic locations or data centres in high risk zones.	I want to see that your “Premises” boundary includes the specific physical protections for those sites.
Resource Scarcity (Power/Water)	Scope must extend to include backup power systems and cooling infrastructure for server rooms.	You cannot exclude “Facilities Management” from your scope if climate change threatens your server uptime.
Supply Chain Volatility	Expanded “Interface” boundaries to include alternative SaaS or hosting providers in different regions.	Your scope statement must acknowledge the dependencies on third parties that are themselves at risk.
Regulatory Shifts	Inclusion of “Legal and Regulatory Compliance” as a primary driver for the ISMS boundary.	If new green laws require data residency changes, your scope must adjust to those new territories.

---

How to Update Your Scope for Amendment 1

To pass your audit, you must demonstrate that you have performed a “Climate Sanity Check” on your boundaries. Use the following list to verify your Clause 4.3 documentation is compliant.

• Review your Clause 4.1 Output: Look at the internal and external issues you identified regarding climate.
• Identify Geographic Vulnerabilities: If you have shifted to “Remote First” because your main office is in a high risk heatwave zone, your scope must now focus on the “Endpoint” rather than the “Office.”
• Adjust Interface Definitions: Clearly define the boundary between your organisation and your utilities providers if climate change makes power or connectivity a high risk dependency.
• Document the Decision: Even if you decide climate change does not affect your scope, you must document that you considered it. Silence is not a defence during a Stage 2 audit.
• Update the Scope Statement: Ensure the final version of your documented information mentions that climate considerations have been factored into the boundary definitions.

Lead Auditor Pro Tip: When I look at your Scope Statement, I am looking for the “Golden Thread.” If Clause 4.1 says “Climate change is a risk to our data centre,” but Clause 4.3 says “The scope is just our office,” you have failed. The scope must encompass the locations where your risks are managed.

Scoping Clause 4.3 for AI-Driven Organisations: Intersection with ISO 42001

By 2026, the question for tech companies has shifted from “How do we secure our data?” to “How do we govern our AI?” If your organisation develops, deploys, or heavily utilises Artificial Intelligence, your Clause 4.3 scope statement is no longer complete without addressing ISO 42001 (the AI Management System). As a Lead Auditor, I am seeing a massive surge in “Dual-Certification” audits where the boundaries between information security and AI governance must be perfectly aligned to avoid a major non-conformity.

The Dual-Boundary Strategy: 27001 vs. 42001

While ISO 27001 focuses on the security of information, ISO 42001 focuses on the trustworthiness and ethical lifecycle of the AI system. To pass an audit in 2026, you must define where your traditional IT infrastructure ends and your AI system boundary begins. This is particularly critical for Clause 4.3.c, which mandates the identification of interfaces and dependencies.

How to Document AI Scoping for Clause 4.3

To satisfy an auditor that you have considered the “Context of the Organisation” in an AI world, your documented scope statement should follow these three rules:

• Identify the AI Lifecycle: Explicitly state if the scope includes model design, data collection, training, deployment, or just the end-use of an AI tool.
• Define the “Model Weights” as an Asset: In modern audits, we look for model weights as a specific asset. If your model is your IP, it must be logically inside your Clause 4.3 boundary.
• Map the Prompt Interface: If your staff use third-party LLMs (like OpenAI or Anthropic), the point where your data leaves your logical control is a critical interface that must be documented.

Auditor’s AI Scoping Checklist

When I review your Clause 4.3 evidence for an AI-driven business, I will ask these specific questions:

1. Does your scope statement distinguish between your production environment and your AI training environment?
2. Have you documented the dependencies on third-party GPU compute providers (e.g. Nvidia, AWS Bedrock)?
3. Is the “Human-in-the-loop” process defined as an organisational boundary for data validation?
4. Does your scope account for the output of the AI (the generated content) and who owns the security of that data?

Lead Auditor Pro Tip: Do not fall into the trap of “AI Blindness.” If you tell me your scope is just your SaaS platform but you use an unmanaged API to process customer data via an external LLM, your scope is a work of fiction. In 2026, the boundary follows the data flow, not just the server rack.

Stuart Barker, Lead Auditor

The Lead Auditor’s Logic Tree

Use the following table as a logic tree to determine the applicability of assets and scenarios under Clause 4.3. This structured approach is exactly what I look for during a Stage 1 audit to ensure you have a firm grip on your organisational boundaries.

How to use this Logic Tree for your Audit

To pass your audit, you should be able to justify every “No” in your matrix. When I audit a client, I don’t just look at what is included; I look at the Exclusions. If you follow this logic, you will satisfy the auditor’s requirement for a “reasoned and documented” boundary definition.

• Document the Rationale: For every excluded item, ensure your “Documented Scope” includes a sentence explaining why it does not impact your security posture.
• Map the Handshake: For items where you answered “No” but have a dependency, document the Interface. This is a mandatory requirement of Clause 4.3.c.
• Review Quarterly: Business models change, especially with the rise of remote work and AI. Re-run this decision matrix every three months to ensure your certificate still reflects reality.

Lead Auditor Pro Tip: If you are unsure, ask yourself: “If this thing fails, does it stop us from protecting our customer data?” If the answer is yes, it is in scope. If the answer is “It is annoying but the data is still safe,” you can likely de-scope it and save yourself a mountain of paperwork.

Stuart Barker, Lead Auditor

How to audit ISO 27001 Clause 4.3

Follow the ISO 27001 Leader Auditor Guidance on How to audit ISO 27001 Clause 4.3

ISO 27001 Clause 4.3 Audit Checklist

The ISO 27001 Lead Auditor ISO 27001 Clause 4.3 Audit Checklist

How to pass the ISO 27001 Clause 4.3 audit

To successfully pass an audit of ISO 27001 Clause 4.3, a crucial step in achieving ISO 27001 Certification, you must ensure you have implemented the mandatory ISO 27001 documents and ISO 27001 polices. You are going to need to put in place ISO 27001 controls to:

• Document an ISO 27001 Scope Statement
• Implement the ISO 27001 standard

Real-World Failure Case Studies: Why Organisations Fail Clause 4.3

In my 30 years as a Lead Auditor, I have found that organisations often learn more from a failure than a “perfect” implementation. While most guides focus on how to pass, I want to show you exactly how to fail. “How to fail ISO 27001” is a high-intent search for a reason: it reveals the hidden traps auditors set. Here are three specific reasons I have issued a Major Non-Conformity (MNC) on Clause 4.3 in recent audits.

1. The “Hidden Developer” Trap

One of the most common MNCs occurs when an organisation defines its organisational boundary too narrowly. I recently audited a fintech firm that claimed its entire development team was “In Scope.” However, during the technical walkthrough, I discovered a team of 15 offshore contractors in Eastern Europe who had full access to the production environment.

• The Failure: The company excluded these developers from the scope because “they are contractors, not employees.”
• The Auditor’s Verdict: Under Clause 4.3.c, you must consider interfaces and dependencies. Because these contractors performed activities on your data, they are a critical logical interface. By excluding them, the organisation had no controls over their access or vetting, resulting in a Major Non-Conformity.
• The Fix: Ensure your scope statement includes “all internal and third-party personnel with logical access to the ISMS environment.”

2. The “Empty Office” Syndrome

Document control is the silent killer of Clause 4.3. I performed a Stage 2 audit for a global logistics company that had listed four physical offices in their scope statement. When I asked for the physical security logs for the Manchester branch, the CISO looked confused.

• The Failure: The company had moved out of that office three months prior but had not updated their documented scope.
• The Auditor’s Verdict: A scope statement must reflect current reality. If you claim to be securing a location that you no longer occupy, your entire management system is “out of control.” It suggests that your Management Review process (Clause 9.3) is not identifying organisational changes.
• The Fix: Review your Clause 4.3 documentation as part of your “Change Management” process. If you move a desk, move a server, or close an office, update the scope immediately.

3. The “API Blindspot”

This is the most frequent technical failure I see in 2026. An e-commerce platform scoped their “Web Application and Hosting Infrastructure” but completely ignored their payment gateway integration.

• The Failure: They assumed that because a “Big Brand” handled the payments, it was “out of scope.”
• The Auditor’s Verdict: You cannot outsource your risk. While you don’t secure the payment provider’s servers, the logical interface (the API connection and the data passed through it) is a fundamental dependency. If that interface is compromised, your customer data is at risk.
• The Fix: Your scope statement must explicitly acknowledge dependencies. Use the phrase: “The scope includes the management of secure interfaces with third-party service providers for payment processing and data analytics.”

Summary Table: Failure vs. Success

Lead Auditor Pro Tip: Most organisations fail because they try to make their scope look “clean” for marketing. My advice? Be honest. An auditor would rather see a complex scope with well-managed interfaces than a simple scope that is clearly missing half of the business reality.

Stuart Barker, Lead Auditor

What an auditor looks for in Clause 4.3

When I am conducting a Stage 1 or Stage 2 audit, I am looking for “Scope Integrity.” I want to know if you are telling the truth about where your data is. Here is exactly what I check:

Audit Checkpoint	The Lead Auditor’s Question
Documented Information	“Show me your scope statement. Is it available to me right now?”
Exclusion Justification	“You have excluded your R&D department. Why? Prove to me that no customer data ever touches that department.”
Boundary Proof	“You say your scope is ‘London Office only.’ How do you secure the data when your staff work from a train?”
Interface Clarity	“Where does your responsibility end and your cloud provider’s begin? Show me the RACI or contract.”

• That you have documented your ISO 27001 scope: You must have a documented scope for your Information Security Management System (ISMS). The auditor will check for the existence of a documented scope statement. Utilising the ISO 27001 Scope Template can simplify this process.
• That you have implemented the scope: You must have implemented the ISO 27001 standard within the defined scope. The auditor will assess whether the requirements of the ISO 27001 standard have been applied effectively to the identified products, services, and areas included within the scope.
• That the scope was approved: Your documented scope must be formally approved. The auditor will check for evidence of scope approval, such as documented approvals and signatures from relevant management personnel.

Top 3 ISO 27001 Clause 4.3 Mistakes and How to Fix Them

These are the top 3 mistakes people make for ISO 27001 Scope:

• Defining an Overly Broad Scope: Including unnecessary areas within the scope of your ISMS can lead to wasted time, resources, and unnecessary costs. Carefully consider and document the specific products, services, and areas that require information security controls.
• Neglecting Client Expectations: Failing to consider client expectations and requirements within the scope of your ISMS can diminish the value of your certification. Involve clients in the scope definition process to ensure your ISMS addresses their specific needs and concerns.
• Poor Scope Management: Inadequate documentation, version control, and review of the scope statement can lead to confusion and non-compliance. Maintain accurate and up-to-date records of the scope statement, implement a robust version control system and regularly review and update the scope statement to reflect changes in the organisation or its environment.

How can an ISO 27001 toolkit help with ISO 27001 Clause 4.3?

An ISO 27001 toolkit gives you the tools you need to meet the rules in Clause 4.3 quickly and correctly.

Feature	High Table ISO 27001 Toolkit	Online SaaS / GRC Platforms
Ownership	Permanent Assets: Once you download the Scope Statement template, it is yours. You hold the master copy of your ISMS boundaries on your own secure servers forever.	Rented Access: Your scope definition is hosted on someone else’s infrastructure. If you stop paying the monthly fee, you lose access to the “source of truth” for your audit boundaries.
Simplicity	Familiar Formats: Defining scope is a narrative exercise. The Toolkit uses professional Word templates that everyone knows how to edit, requiring zero technical training.	Technical Complexity: Users must learn proprietary “wizards” or configuration modules just to document where their business starts and ends.
Cost	One-Off Payment: You pay once for the toolkit. Since the scope rarely changes significantly once set, a one-off fee is the most logical financial choice.	Eternal Subscription: You are charged every month to “host” a static document. Over a 3-year certification cycle, you pay thousands for what is essentially a text-based definition.
Freedom	Zero Vendor Lock-In: You are free to move your documentation between internal systems (SharePoint, Google Drive, etc.) without losing formatting or data integrity.	Proprietary Silos: Exporting a complex scope and its associated boundaries from a SaaS tool is often messy, making it difficult to switch providers or go “manual” later.

The ISMS Onion Model: Why Layered Scoping is Non-Negotiable

In my 30 years of auditing, the biggest mistake I see is “Flat Scoping.” This is where an organisation tells me their scope is “The London Office” or “The AWS Environment.” That is a rookie error. Information security does not exist in a vacuum; it exists to support a Business Process. If you do not understand the layers of your scope, you will miss the risks, and I will find them during your Stage 2 audit.

Think of your scope like an onion. You cannot secure the outer skin without protecting the core. When I audit your Clause 4.3 implementation, I am looking for this “Layered Logic”:

• The Core (Business Process): What is the money-making activity? (e.g. “Processing Payroll”).
• Layer 2 (The Data): What information supports that process? (e.g. PII, Bank details).
• Layer 3 (The Applications): Which software touches that data? (e.g. Your SaaS platform, SQL databases).
• Layer 4 (The Infrastructure): Where does that software live? (e.g. AWS, Azure, On-prem servers).
• Layer 5 (The People & Places): Who manages it and from where? (e.g. DevOps team, remote workers).

Lead Auditor Pro Tip: If the Business Process is in scope, every layer beneath it is automatically in scope. You cannot claim to secure a “Payroll Service” while excluding the database it runs on. If you try, I will issue a Major Non-Conformity for “Incomplete Boundary Definition.”

Scoping for the Integrated Management System: ISO 27001, 9001, and 42001

By 2026, the days of running separate “silos” for different ISO standards are over. If you are a mid-to-large enterprise, you are likely running an Integrated Management System (IMS). Scoping Clause 4.3 for an IMS is about efficiency. Why write three scope statements when you can write one “Unified Scope” that satisfies the Lead Auditor for Security, Quality, and AI Governance?

Standard	Focus Area	The Unified Boundary Requirement
ISO 9001	Quality & Customer Satisfaction	The entire value chain from “Order to Cash.”
ISO 27001	Information Security	The protection of the data within that value chain.
ISO 42001	AI Governance	The ethical use of AI models within those processes.

The Strategy: One Document, Multiple Badges

To pass a multi-standard audit, your Clause 4.3 documentation must show a common set of Interested Parties and Internal Issues. If your ISO 9001 scope says you are a “Manufacturer” but your ISO 27001 scope says you are a “Software Developer,” you have a governance conflict. A Unified Scope ensures that your “Context of the Organisation” remains consistent across the entire business, saving you thousands in audit fees and weeks of redundant paperwork.

The M&A Scoping Nightmare: The “Quarantine Strategy”

What happens when your ISO 27001 certified company buys another business that has the security posture of a wet paper bag? If you immediately bring them into your scope, you risk losing your own certification during the next surveillance audit. You cannot be responsible for boundaries you haven’t yet secured.

How to Legally De-scope an Acquisition

To protect your “Gold Standard” certificate, you must use the Quarantine Strategy. This is a formal, documented method of keeping the new entity out of your ISMS audit boundaries while you perform the “security uplift.” To satisfy a Lead Auditor, you must prove three things:

1. Zero Logical Connectivity: The acquired company must not have access to your primary production environment or AD forest. They are an “Untrusted Third Party” until proven otherwise.
2. Documented Exclusion: Your Clause 4.3 statement must explicitly state: “The ISMS excludes the recently acquired entity [Company Name] for a transition period of X months.”
3. The Roadmap: I want to see a project plan. You cannot exclude them forever. Show me the timeline for when they will be “on-boarded” into the ISMS.

Lead Auditor Pro Tip: If you allow the new company’s staff to use your corporate email or VPN before they are “In Scope,” you have created a Scope Seep. During an audit, I will follow that VPN tunnel straight into the acquired company’s messy servers, and I will fail your entire ISMS for failing to manage its boundaries.

Technical Scoping: The “Air-Gap” versus The “Firewall”

One of the most common questions I get as an ISO 27001 Lead Auditor is: “Can I use a firewall to define my scope boundary?” The answer is usually a firm “No.” You are confusing a security control with a scope boundary. In my 30 years of auditing, this is where most technical teams trip up and earn themselves a major non-conformity.

The Auditor’s Reality: Control versus Boundary

To “Legally De-scope” a network segment or a department, you must prove Logical Isolation. If your “Out-of-Scope” marketing team can still ping the “In-Scope” SQL server, or worse, if they share the same administrator credentials, then your marketing team is 100% in scope. You cannot just draw a line on a network diagram and hope I do not notice the cables connecting them.

Scenario	The Lead Auditor’s Verdict	Why it Passes or Fails
The Pass: Separate VPC / VLAN	PASS	A separate Virtual Private Cloud (VPC) or a strictly controlled VLAN where zero routing exists between “In-Scope” and “Out-of-Scope” segments.
The Fail: Shared Active Directory	FAIL	If “Out-of-Scope” users can browse “In-Scope” file shares or authenticate via the same AD forest, they are inside your boundary.
The Pass: Physical Air-Gap	PASS	The gold standard. Hardware that is physically disconnected from the corporate network is legally de-scoped.
The Fail: “Management” Bypass	FAIL	If your IT team manages “In-Scope” servers from “Out-of-Scope” laptops without a secure jump box, those laptops are now in scope.

How to prove isolation during the audit

When I sit down for your Stage 2 technical walkthrough, I am going to ask your network lead to show me the routing tables and the firewall rules. If I see “Allow All” or a shared management subnet, your de-scoping argument will fall apart. To pass, you must demonstrate that the Logical Handshake between environments is governed by the “Principle of Least Privilege.”

Lead Auditor Pro Tip: If you want to de-scope a segment, treat it like an external third party. If you would not trust a random person on the internet with that level of access, do not give it to your “Out-of-Scope” departments. If they can see the data, they are in the scope. Period.

Stuart Barker, Lead Auditor

Related ISO 27001 Controls and Further Reading

Related ISO 27001 Control	Lead Auditor Relationship Description
What is ISO 27001 Clause 4.3?	This is the direct implementation guide for the control. It moves beyond the theory and tells you exactly what the auditor is looking for when they ask you to prove your ISMS boundaries. It is the tactical blueprint for satisfying the Clause 4.3 requirement.
What is ISO 27001 Scope?	You cannot comply with a control if you do not understand the terminology. This page defines the physical and logical boundaries required by Clause 4.3. It acts as the foundational definition that prevents scope creep during a Stage 1 audit.
What is ISO 27001 Audit Scope?	While the ISMS scope is your internal boundary, the audit scope is what the certification body will actually test. This page explains the “bricks and mortar” limits that an auditor will verify against your Clause 4.3 documentation.
How to Define ISO 27001 Scope	This is a step by step walk-through of the implementation process. It provides the practical methodology for identifying people, technology, and premises. It is the “how to” guide that bridges the gap between the standard’s text and a finished scope document.
ISO 27001 Scope Statement Guide	The scope statement is the mandatory documented information required by Clause 4.3. This page focuses on crafting the specific wording that will appear on your certificate. It ensures your public declaration of security matches your internal technical reality.
ISO 27001 Clause 4.1: Context of the Organisation	You cannot define your scope in a vacuum. Clause 4.1 provides the internal and external issues that serve as a direct input to your Clause 4.3 scope. If you ignore your context, your scope will be fundamentally flawed and the auditor will fail you.
ISO 27001 Clause 4.2: Interested Parties	Your customers and regulators dictate what must be in scope. This page explains how to identify stakeholder requirements which then mandate the boundaries you set in Clause 4.3. It is about meeting the needs of those who actually care about your security.
ISO 27001 Clause 4.4: The ISMS	Once you have drawn the line around your business in Clause 4.3, Clause 4.4 is the requirement to actually run the management system within those lines. It is the “living” version of the boundaries you have established.
ISO 27001 Certification Cost	Scope is the primary driver of your audit fees. This page explores how the boundaries you define under Clause 4.3 directly impact the number of audit days you are quoted. A tighter scope leads to a leaner and cheaper certification process.
ISO 27001 Clauses: Complete Guide	This is the master index for all mandatory requirements. It places Clause 4.3 within the wider framework of the Annex SL structure. Use this to understand how scoping interacts with risk assessment and continual improvement.

Related ISO 27001 Control	Lead Auditor Relationship Description
ISO 27001 Annex A 5.9: Inventory of Information and Other Associated Assets	This is the reality check for your scope. If you tell me an asset is out of scope under Clause 4.3 but it appears in this inventory, you are asking for a major non-conformity. This control identifies what exists, and Clause 4.3 identifies what you are actually protecting.
ISO 27001 Annex A 5.31: Legal, Statutory, Regulatory and Contractual Requirements	Your legal obligations are the non-negotiable drivers for Clause 4.3. If a law says you must protect a specific data type, that data type and the systems touching it are automatically dragged into your scope. You don’t get to choose your boundaries if the law has already chosen them for you.
ISO 27001 Annex A 5.1: Policies for Information Security	Policies are the rules of the game within the lines you drew in Clause 4.3. An auditor will check if your policies align with your scope. If your policy covers cloud security but your scope says you are 100 percent on-premise, your management system is a work of fiction.
ISO 27001 Annex A 5.37: Compliance with Policies, Rules and Standards	This control is the enforcement of the boundaries set in Clause 4.3. It requires you to prove that you are actually following your own rules within the defined scope. If you cannot prove compliance within those boundaries, your scope statement is a lie.
ISO 27001 Annex A 8.1: User Endpoint Devices	Endpoints are the most common point of scope failure. Clause 4.3 must define whether BYOD or remote devices are in scope. This control then applies the technical hammer to those devices. If you exclude endpoints from Clause 4.3, you leave a massive hole in your security posture that no auditor will ignore.
ISO 27001 Annex A 5.36: Compliance with Policies and Standards	This control provides the review mechanism to ensure the scope defined in Clause 4.3 remains accurate over time. Businesses change, and if your compliance reviews show that new systems have been added but Clause 4.3 hasn’t been updated, your certification is at risk.
ISO 27001 Annex A 5.2: Information Security Roles and Responsibilities	People are a core component of Clause 4.3. This control identifies who is responsible for the assets and processes within the scope. If you haven’t assigned a role to a process within your scope, that process is unmanaged and out of control.

ISO 27001 Clause 4.3 Applicable Laws and Related Standards

Standard / Law / Regulation	The Auditor’s View: Relationship to Clause 4.3 Scoping
NIST CSF 2.0 (Identity: Asset Management & Governance)	NIST requires you to identify the assets and systems that support your mission. This is a direct mirror of Clause 4.3. You cannot apply NIST controls until you have defined the “Organizational Context” and the “Scope” of what is being managed.
NIS2 Directive (EU)	NIS2 focuses on “Essential” and “Important” entities. Clause 4.3 is the tool you use to map your critical services to these legal categories. If your Clause 4.3 scope excludes a critical service defined under NIS2, you are in breach of EU law.
DORA (Digital Operational Resilience Act)	DORA demands a strict definition of the “ICT Risk Management Framework.” For financial entities, Clause 4.3 is the mechanism used to draw the boundary around ICT systems and third-party providers that support critical financial functions.
SOC2 (Trust Services Criteria)	SOC2 relies on the “Description of the System.” This is effectively your Clause 4.3 scope statement under a different name. It defines the boundaries of the system, the people, and the data that the auditor will test for security and availability.
EU AI Act	This law requires you to classify AI systems as high-risk or limited-risk. Clause 4.3 is how you document which AI systems are within your management boundary. If you miss an AI tool in your scope, you cannot demonstrate the mandatory transparency and risk oversight required by the Act.
ISO 42001 (Artificial Intelligence Management System)	This is the AI-specific twin of ISO 27001. Clause 4.3 in ISO 42001 is identical in intent: you must define the scope of the AI system, including whether you are a provider or a deployer. The two scopes must be synchronized.
UK Data (Use and Access) Act 2025	The UK’s evolution of GDPR simplifies administration but doubles down on knowing where your data lives. Clause 4.3 allows you to define a “Reduced Burden Scope” while maintaining high security thresholds for high-risk processing activities.
UK Cyber Security and Resilience Bill	This bill expands the UK’s version of NIS2 to include Managed Service Providers (MSPs). Clause 4.3 is vital here: you must define your supply chain boundaries clearly to ensure your “Managed Services” are inside the scope of mandatory reporting.
GDPR / UK GDPR (Article 30 ROPA)	The Record of Processing Activities (ROPA) is effectively the “Data Scope” of your business. Clause 4.3 provides the organizational boundary that dictates which data processing activities are included in your privacy management system.
CIRCIA (USA: Cyber Incident Reporting for Critical Infrastructure Act)	CIRCIA requires 72-hour reporting for “Covered Entities.” Clause 4.3 is the exercise of determining if your organization, or a specific business unit, falls into one of the 16 critical infrastructure sectors mandated by the US government.
EU Product Liability Directive (PLD) Update	The updated PLD treats software as a product. Clause 4.3 is used to define the “Development Scope.” If you develop software, your ISMS scope must include the SDLC (Software Development Life Cycle) to mitigate strict liability for cybersecurity flaws.
ECCF (European Cybersecurity Certification Framework)	ECCF introduces harmonized security labels. Clause 4.3 is the process of defining the “Target of Evaluation” (TOE). You must match your ISMS scope to the specific product or service you are seeking an EU-wide security label for.
HIPAA (Security Rule 45 CFR § 164.306)	HIPAA requires Covered Entities to protect Electronic Protected Health Information (ePHI). Clause 4.3 is the boundary-setting exercise that identifies every system and person that creates, receives, maintains, or transmits ePHI.
California Data Laws (CCPA / CPRA)	CCPA/CPRA focus on the “Business” and “Service Provider” relationship. Clause 4.3 maps these relationships. It defines whether a specific business unit or legal entity is the “Controller” or “Processor” of Californian resident data.

ISO 27001 Clause 4.3 FAQ

About the author