Most ISO/IEC 27001:2022 ISMS scope statements describe an organisation that existed three infrastructure migrations ago. The scope covers a named office and a data centre. Meanwhile, production workloads run in AWS, customer data transits through a SaaS processor, and a subsidiary in another jurisdiction holds domain admin credentials to the same Active Directory.
Clause 4.3 of ISO/IEC 27001:2022 requires organisations to determine ISMS boundaries by considering external and internal issues, interested party requirements, and β critically β interfaces and dependencies between their activities and those performed by other organisations. That third element is where most scope documents fail. Not because organisations forget it exists, but because they define it away.
What ISO 27001 Clause 4.3 Actually Requires
ISO/IEC 27001:2022 Clause 4.3 scope determination rests on three inputs: internal and external issues from Clause 4.1, interested party requirements from Clause 4.2, and interfaces and dependencies with external organisations. The third input is the one that separates a defensible ISMS scope from a convenient one.
A scope statement naming a business unit and a physical location but omitting the cloud tenants processing that unit’s data, the SaaS platforms staff access daily, and third-party providers holding administrative access to its systems has not satisfied Clause 4.3. It has documented an organisational boundary, not an information-flow boundary. That distinction matters at Stage 2.
Clauses 4 through 10 cannot be excluded from the ISMS. Only Annex A controls can be excluded β and only with justified rationale documented in the Statement of Applicability under Clause 6.1.3. The scope document must be available as documented information, and auditors will test it against what the organisation actually operates.
Where the ISMS Scope Boundary Breaks Down
The failure pattern is consistent. Organisations draw ISMS scope boundaries to minimise certification effort β fewer assets in scope means a smaller risk register, fewer controls to implement, and a shorter audit. The problem surfaces at Stage 2, when auditors cross-reference the scope statement against the live asset inventory, network diagrams, and contract schedules.
Three exclusion patterns trigger findings most frequently.
Cloud infrastructure appears in the operational environment β production workloads, data storage, customer-facing applications β but the scope statement references only on-premises systems. Auditors testing Clause 4.3(c) identify the missing interface documentation. Annex A control A.5.23, Information security for use of cloud services, turns up excluded from the SoA with a rationale of “not applicable.” But that non-applicability is manufactured by the scope boundary, not derived from an honest risk assessment.
Third-party processing agreements sit outside the declared ISMS boundary. Supplier relationship controls A.5.19 through A.5.22 β covering information security in supplier relationships, ICT supply chain security, and monitoring of supplier services β are excluded because the processing environments are “out of scope.” Auditors trained on ISO/IEC 27001:2022’s restructured Annex A recognise this pattern: the SoA excludes controls that the organisation’s own contract register proves are operationally relevant.
Multi-entity structures create the most severe findings. A parent company certifies one legal entity while subsidiaries, shared-service centres, or joint ventures access the same information systems, directory services, and data repositories. Information flows cross the declared boundary without documented controls. When auditors find cross-entity access rights the scope statement does not account for, the finding is a Clause 4.3 major nonconformity.
The Downstream Failure Chain
A narrow ISMS scope does not just affect the scope document. It breaks the risk register, the SoA, and every control implementation built on top of them.
Clause 6.1.2 requires the organisation to identify information security risks within the ISMS scope. Risk identification begins at the asset boundary Clause 4.3 establishes. Assets and interfaces excluded from scope are structurally outside the risk assessment process β not because the risk assessor overlooked them, but because the scope definition removed them before the process started.
The result is a risk register that cannot identify cloud misconfiguration risks, supply chain compromise scenarios, or cross-entity lateral movement. The assets involved do not exist in the scope feeding the register. An auditor finding credible threat scenarios involving out-of-scope assets will trace the root cause back to Clause 4.3, not Clause 6.1.2. The risk assessment followed its inputs correctly. The inputs were wrong.
This creates a circular SoA problem. Controls are excluded as “not applicable” because the risk assessment identified no risks requiring them. The risk assessment found nothing because the assets were out of scope. The assets were out of scope because the boundary was drawn to minimise effort. Formally complete. Substantively hollow.
How to Define an ISMS Scope That Survives Stage 2
1. Map information flows before writing the scope statement. Document where information is created, stored, processed, and transmitted β including every cloud tenant, SaaS platform, co-processor, and subsidiary access point. The scope boundary must follow the information flow, not the organisational chart.
Build a dependency register first. Write the scope statement second.
2. Stress-test the draft scope against real threat scenarios. Before finalising, run the draft scope against the actual threat model: cloud misconfiguration, supply chain compromise, cross-entity lateral movement, third-party data exfiltration. If any credible threat involves assets or interfaces outside the draft boundary, the boundary is wrong. Each exclusion must pass one test: does the organisation’s own incident history, access log, or threat model reference this asset? If yes, it cannot be excluded without documented risk acceptance by senior management β with a defined review date.
3. Reconcile scope, risk register, and SoA before the audit. Every in-scope asset should appear in the risk register. Every risk treatment decision should map to an SoA control inclusion or a justified exclusion. Every Annex A control excluded from the SoA must have a rationale derived from the risk assessment β not from the scope boundary. A.5.23, A.5.19 through A.5.22, and A.5.9 are the highest-risk exclusions to check. Any circular justification β “this control is not applicable because the asset is out of scope” β is the pattern auditors are trained to find.
The Real Test
A scope exclusion is defensible when the excluded asset demonstrably does not process, store, or transmit information governed by the ISMS, the exclusion carries a risk-based rationale (not just an operational one), and the SoA reflects it consistently. An exclusion becomes a Stage 2 finding when the organisation’s own risk register, incident logs, or access control records reference the excluded asset. At that point, the scope document contradicts the operational evidence β and the auditor has documentary proof that the certified ISMS does not cover the material risk surface.
IAF MD 26:2022 governs transition audit mechanics for the 2022 edition but does not define scope adequacy thresholds. No published IAF, UKAS, or ANAB guidance establishes minimum criteria for when a cloud or multi-entity exclusion crosses from permissible limitation to material risk gap. The line between defensible and indefensible remains an auditor judgment call at Stage 2. Get the ISMS scope right before the audit β not narrow.
Clause mapping reflects common audit practice. Verify with your certification body for specific expectations.
Frequently Asked Questions
Q: Can I exclude cloud infrastructure from my ISMS scope? A: Only if the cloud environment demonstrably does not process, store, or transmit information governed by the ISMS. If production workloads or customer data reside in cloud tenants, excluding them will create a Clause 4.3 finding at Stage 2.
Q: What is a Clause 4.3 major nonconformity? A: It occurs when auditors find that the declared ISMS boundary does not account for interfaces and dependencies the organisation actually operates β such as cross-entity access rights or undocumented cloud processing environments.
Q: How often should I review my ISMS scope statement? A: Review whenever infrastructure changes materially β cloud migrations, new SaaS platforms, subsidiary integrations, or changes to third-party processing. At minimum, review before each surveillance or recertification audit.
Q: What is the circular SoA problem? A: Controls are excluded as “not applicable” because the risk assessment found no risks requiring them, but the risk assessment found nothing because the relevant assets were excluded from scope. The exclusion creates a self-reinforcing gap that auditors are trained to identify.
About AEC International
AEC International provides ISO certification, training, and consultancy services at the intersection of information security, risk management, and operational resilience. We support organisations across industries in achieving and maintaining ISO certification β from gap analysis and implementation through audit preparation and continual improvement.
Learn more: www.aec.llc