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.
ISO 27001:2022 Attributes
| Attribute |
Classification |
| Control Type |
Governance / Strategic |
| CIA Properties |
Confidentiality, Integrity, Availability |
| Cybersecurity Concepts |
Identify |
| Operational Capabilities |
Governance, Risk Management |
Implementation Difficulty & Cost
| Factor |
Details |
| Difficulty Rating |
3/5 (Requires deep business knowledge) |
| Implementation Cost |
Low (Primarily staff time for analysis) |
| Control Owner |
CISO / Compliance Manager |
| Accountability |
Board of Directors / Top Management |
ISO 27002 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 Steps to Implement Clause 4.3
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
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
| Requirement |
SaaS Tool Trap |
Auditor Reality |
| Boundary Definition |
Tool provides a generic “all-company” template. |
I want to see specific addresses and VPC IDs unique to your business. |
| Exclusion Logic |
Checking a “N/A” box without an attached reason. |
I look for documented management debate regarding why an area was left out. |
| Interface Mapping |
Software assumes all interfaces are standard API links. |
I check for manual entries regarding human interfaces and physical data transfers. |
10 Steps to Audit Clause 4.3 (Internal Audit Guide)
- Verify the Scope Statement: Confirm that a documented scope exists in SharePoint and is accessible to relevant staff.
- Check Context Alignment: Ensure the scope addresses the internal and external issues found in Clause 4.1.
- Validate Stakeholder Needs: Review if the scope covers the requirements of interested parties listed in Clause 4.2.
- Perform a Site Walkthrough: Check if every physical location mentioned in the scope actually exists and is secure.
- Inspect Asset Inventories: Match the assets in your Jira register against the logical boundaries defined in the scope.
- Challenge Exclusions: Ask the CISO for the logical reason behind any excluded business units or locations.
- Review Network Diagrams: Verify that logical perimeters on your diagrams match the text in the scope statement.
- Examine Interface Controls: Check how security is managed at the points where data leaves the ISMS boundary.
- Verify Management Sign-off: Look for digital signatures or meeting minutes that prove the Board approved the scope.
- Check Version History: Ensure the scope has been updated following any recent business mergers or office moves.
Clause 4.3 Audit Evidence Checklist
| Evidence Item |
Pass/Fail Criteria |
Owner |
| Formal Scope Statement |
Must be documented, concise, and approved by senior management. |
CISO |
| Site List & Floor Plans |
Must match the physical addresses listed in the scope document. |
Facilities Manager |
| Interface Register |
Must list all third-party dependencies and logical touchpoints. |
IT Manager |
| Justification Record |
Detailed explanation for any business area excluded from the ISMS. |
Compliance Lead |
Required Policy Content: A Lead Auditor’s Checklist
- 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.
Enforcement and Consequences
Failure to accurately define your scope is a breach of the ISMS governance framework. If I find that you have deliberately hidden high-risk areas to simplify the audit, I will issue a Major Non-Conformity. I follow a clear path: Verbal Warning for minor omissions, Written Minor NC for stale documentation, and Major NC for intentional scope manipulation or lack of Board oversight.
Common Implementation Challenges
| Challenge |
Root Cause |
Solution |
| Scope Creep |
Failing to define clear logical boundaries early on. |
Use network diagrams to lock down the perimeter before writing the policy. |
| Shadow IT |
Departments using SaaS tools without alerting the CISO. |
Conduct regular automated scans to find unlisted logical assets. |
| Vague Language |
Writing the scope as a marketing statement rather than a technical one. |
Focus on specific sites, IDs, and business functions in plain English. |
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
| ISO 27001:2013 |
ISO 27001:2022 |
| Basic requirement to determine boundaries. |
Enhanced focus on defining organisational interfaces and third-party dependencies. |
| Implicit link to context clauses. |
Explicit requirement to base the scope on Clause 4.1 and Clause 4.2 findings. |
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
Clause 4.3 FAQ
Can I exclude certain departments from the ISMS scope?
Yes, but you must provide a logical justification. If the department handles sensitive data within the ISMS perimeter, an exclusion will likely fail the audit.
How detailed does the physical scope need to be?
It should list the full address of every site. For large organisations, a reference to a master site list in SharePoint is acceptable.
Do I need to include remote workers in the scope?
Generally, yes. If they access or process information within the scope, their activities and hardware must be included in the management system.
What is a logical boundary?
A logical boundary defines the digital limit of your systems, such as a specific cloud account (AWS/Azure) or a network segment.
How often should I change my scope?
You should review it annually. However, you must update it immediately after major changes like office moves, mergers, or significant new tech deployments.