ISO 27001 Clause 4.3 Determining The Scope Of The Information Security Management System (ISMS)

What is ISO 27001 Clause 4.3 Determining The Scope Of The Information Security Management System (ISMS)?

ISO 27001 Clause 4.3 Determining the scope of the ISMS is a governance control that defines the precise boundaries of security management. It requires identifying physical and logical perimeters while considering business interfaces. This documented statement ensures your security efforts apply to the correct assets and personnel.

Control Guidance

From a physical guidance perspective, your scope must define every office location, data centre, and remote working region included in the ISMS. In my experience, organisations often fail by leaving out secondary sites or storage facilities. You must document the physical addresses and the nature of the activities performed there. If a site handles sensitive data, it must stay within your defined boundaries. I look for floor plans and site lists stored in your native document management system.

The technical guidance focuses on the logical perimeters of your digital environment. This involves mapping every cloud region, VPC, and SaaS application that interacts with your primary data sets. I often find that companies ignore third-party dependencies during the scoping phase. You must explicitly state which logical assets are under your direct control. Use your internal asset register in Jira to track these boundaries. This ensures that your security controls cover the entire technical stack used by the business.

Regarding behavioural guidance, the scope must identify the specific business units and personnel groups included. I look for evidence that you have considered how different teams interact with sensitive information. If you exclude a department, you must provide a clear, logical justification. Staff needs to know if the ISMS policies apply to their daily tasks. I often see confusion when the scope is too vague about employee inclusion. Clear communication through your internal wiki helps maintain this cultural boundary.

In my 20 years of auditing, I find that a poorly defined scope is the fastest way to earn a major non-conformity. I do not want to see a generic statement that says “all company data.” I look for a logical map of your business interfaces. During a Stage 1 audit, I will perform Log Reviews of your asset discovery tools to find hidden sites. If I find an unlisted office or a forgotten AWS bucket, your management system has failed. I prefer seeing your scope statement within your native SharePoint environment. This proves you have manual control over your boundaries rather than relying on a black-box SaaS portal.

10 Step Implementation Guide

1. Review Internal and External Issues: Start by examining the issues identified in Clause 4.1. Your scope must address the specific challenges facing your organisation. I look for a clear link between these issues and your defined boundaries. If your business operates in high-risk regions, those locations must be included. Use SharePoint version history to prove this analysis occurred. This step ensures your security perimeters align with your actual business environment.
2. Assess Stakeholder Requirements: Evaluate the needs of interested parties from Clause 4.2. Clients often mandate that specific projects or data sets stay within the certified scope. I frequently find that contractual obligations dictate the boundaries of an ISMS. Document these requirements in your Confluence wiki to maintain a central record. This ensures you satisfy legal and client expectations regarding security management. Failure to align with these needs often results in audit friction.
3. Map Physical Locations and Assets: List every physical site where your organisation processes information. This includes main offices, satellite branches, and home-working setups. I look for a master site list with clearly defined security perimeters. Use your asset management tool to link hardware to these physical locations. This provides a tangible map of your physical security footprint. Documenting these locations is essential for site-based audits and physical walkthroughs.
4. Define Logical and Network Boundaries: Identify the logical limits of your information systems. This involves documenting your primary networks, cloud environments, and external interfaces. I expect to see diagrams that show where your control ends and third-party responsibility begins. Use Lucidchart or native tools to create these visual boundaries. This prevents “shadow IT” from existing outside your security oversight. A clear logical scope helps technical teams implement consistent firewall and access rules.
5. Identify Business Unit Inclusion: Clearly state which departments or business functions are within the ISMS. I often see organisations include IT but exclude Sales or HR. You must explain how these functions interact with the information within the scope. Document these inclusions in your ISMS Manual to ensure all staff understand their role. This helps in targeting awareness training to the correct personnel. Excluding high-risk departments without justification is a common failure point I watch for.
6. Address Organisational Interfaces: Examine the points where your organisation interacts with external entities. This includes suppliers, partners, and clients. I look for a list of these interfaces and the security rules governing them. Use your vendor management system to track these third-party touchpoints. Defining these interfaces prevents security gaps at the edge of your organisation. It ensures that data remains protected even when moving between different management systems.
7. Document Exclusions and Justifications: If you exclude any area of the business, you must provide a valid reason. I check if exclusions create security holes in your primary workflows. Justifications should be stored in your SharePoint governance folder. I often reject exclusions if the excluded unit still accesses the primary database. This step proves that you have considered the risk of excluding specific business segments. Honest justifications show a mature understanding of your operational limits.
8. Draft the Formal Scope Statement: Write a concise statement that defines the physical, logical, and organisational boundaries. Avoid using vague language like “as far as possible” or “selected assets.” I look for a document that an external auditor can read and understand in five minutes. Publish this statement on your Confluence security hub for all employees to see. A clear statement serves as the foundation for your Statement of Applicability. It provides the “where and what” of your entire security project.
9. Secure Management Approval: Top management must review and sign off on the defined scope. I look for meeting minutes or digital signatures in your DMS as evidence. This ensures that leadership agrees with the boundaries of the security investment. Management approval provides the authority needed to enforce policies within those boundaries. Without this, the scope lacks the weight required for successful implementation. I verify this during executive interviews to ensure they own the decision.
10. Establish an Annual Review Cycle: The business environment changes, so your scope must stay current. Set a recurring task in Jira to review the scope every twelve months. I check the version history of your scope document to see if it reflects business growth. If you have opened new offices but the scope is old, I will issue a non-conformity. A living scope document proves that your ISMS is an active management system. It shows that you are constantly adapting to new physical and logical changes.

10 Step Audit Guide

1. Verify the Scope Statement: Confirm that a documented scope exists in SharePoint and is accessible to relevant staff.
2. Check Context Alignment: Ensure the scope addresses the internal and external issues found in Clause 4.1.
3. Validate Stakeholder Needs: Review if the scope covers the requirements of interested parties listed in Clause 4.2.
4. Perform a Site Walkthrough: Check if every physical location mentioned in the scope actually exists and is secure.
5. Inspect Asset Inventories: Match the assets in your Jira register against the logical boundaries defined in the scope.
6. Challenge Exclusions: Ask the CISO for the logical reason behind any excluded business units or locations.
7. Review Network Diagrams: Verify that logical perimeters on your diagrams match the text in the scope statement.
8. Examine Interface Controls: Check how security is managed at the points where data leaves the ISMS boundary.
9. Verify Management Sign-off: Look for digital signatures or meeting minutes that prove the Board approved the scope.
10. Check Version History: Ensure the scope has been updated following any recent business mergers or office moves.

Requirements by Environment

• Office Environment: Must define physical perimeters, server rooms, and visitor access zones within the scope statement.
• Home Working: Must specify how remote endpoints and domestic networks interface with the primary ISMS boundaries.
• Cloud Environment: Must list all cloud hosting regions, third-party SaaS tools, and the shared responsibility boundaries between you and the provider.

The “Checkbox Compliance” Trap

Audit Evidence Checklist

Required Policy Content

• Identification Section: Must clearly list all physical addresses and logical network identifiers (e.g., VPC IDs).
• Business Unit Matrix: Detailed list of which departments are included and which are excluded.
• Justification Clause: Each exclusion must achieve a risk-based explanation for why it is not part of the management system.
• External Dependency List: Must define the interfaces with suppliers and partners that impact the security of the scope.
• Review Frequency: Must state that the scope is reviewed annually or after any significant organisational change.

What to Teach Employees

• ISMS Boundaries: Explain which physical and logical areas the security rules apply to during daily work.
• Interface Security: Teach staff how to handle information when it moves outside the defined ISMS perimeter.
• Reporting Scope Changes: Instruct employees on how to alert the security team when new tools or offices are added.

Common Implementation Challenges

Sample Statement of Applicability (SoA) Entry

“ISO 27001 Clause 4.3 is a mandatory requirement. We satisfy this by maintaining a ‘Scope Statement’ document in SharePoint. This record defines our physical offices, AWS regions, and specific business units. It considers all issues and stakeholder needs. We review and approve this statement annually to ensure it reflects our current operational environment.”

Changes from ISO 27001:2013

How to Measure Effectiveness (KPIs)

• Scope Review Accuracy: Percentage of new office locations added to the scope within 30 days of opening.
• Asset Alignment Score: Number of assets found in discovery scans that are not covered by the existing scope statement.
• Internal Audit Pass Rate: Percentage of internal audits that find the scope to be accurate and fully representative of the business.

Related ISO 27001 Controls

• ISO 27001 Clause 4.1: Your understanding of the organisation provides the necessary context for defining your ISMS boundaries.
  Read the Clause 4.1 guide.
  
• ISO 27001 Clause 4.2: Stakeholder needs often dictate specific inclusions or exclusions within your certified scope.
  Learn more about Clause 4.2.
  
• ISO 27001 Annex A 5.1: Once your scope is defined, you must implement policies that cover every asset and person within those limits.
  Explore Annex A 5.1 requirements.
  

ISO 27001:2022 Attributes

Implementation Difficulty & Cost

ISO 27001 Clause 4.3 FAQ