Determining ISO 27001 scope is about drawing a defensible, risk-based boundary around the information security management system (ISMS). In industrial and regulated environments, the scope must reflect real data flows across IT, OT, and external parties, not just an abstract list of systems.
1. Start from business objectives, not systems
Begin with why you want ISO 27001:
- Which products, programs, or services are driving the need (e.g., aerospace customer contracts, regulated data handling, IP protection)?
- Which regulatory or contractual requirements are in play (e.g., export controls, data protection laws, customer security requirements)?
- Which sites, business units, and partners are actually involved in delivering those products or services?
Your scope must at least cover the processes, locations, and information assets necessary to meet those objectives. If they are left out, the scope will appear artificial and can be challenged by auditors or customers.
2. Map information and data flows
In brownfield industrial environments, the real scope boundary is where information flows, not where organization charts end. Map:
- Key information types: design data, process parameters, batch records, maintenance logs, quality records, supplier data, and customer technical data.
- Systems handling this information: ERP, MES, QMS, PLM, historian, SCADA/DCS, LIMS, file shares, collaboration tools, cloud services.
- Interfaces and integrations: data replication between MES and historian, engineering-to-operations handoff from PLM, links to supplier portals, remote access for OEMs.
- People and roles: operators, engineers, maintenance, quality, IT/OT admins, external contractors, and managed service providers.
This mapping will show where in practice your ISMS controls must apply to protect in-scope information. If information crosses a boundary, that boundary is likely in scope or must be tightly controlled and justified as out of scope.
3. Define scope by business process, location, and asset
An ISO 27001 scope statement typically describes:
- Processes: e.g., “Design, manufacturing, testing, and aftermarket support for Product Line X” or “Operation of Plant Y, including production, maintenance, and quality management”.
- Locations: specific plants, offices, data centers, and cloud regions. In industrial settings, clearly state whether shop floor OT environments are in scope.
- Assets and systems: high-level categories such as “IT and OT systems supporting in-scope processes, including MES, historian, SCADA, ERP, PLM, QMS, and supporting network infrastructure”.
You do not need to list every device by name in the scope statement, but you must be able to show, in supporting documentation, what is covered and how it is kept current.
4. Decide how to treat OT environments
For manufacturing and regulated operations, the main scoping challenge is OT:
- Full inclusion: All OT systems related to in-scope processes are within the ISMS. This is more complete, but increases complexity and the effort needed to align controls with legacy equipment and safety constraints.
- Partial inclusion: Only certain OT zones (e.g., the lines making Product X) are in scope, with clear network segregation and documented justification.
- Out-of-scope OT with strong interfaces: OT is out of scope, but interfaces to in-scope IT are strongly controlled and documented. This is often challenged if OT holds or processes in-scope information (e.g., recipes, quality data).
In practice, if OT systems store or control in-scope information (or if their compromise would materially affect confidentiality, integrity, or availability of that information), they should be considered at least partially in scope, even if controls are tailored to technical and safety realities.
5. Handle multi-site and multi-system brownfield realities
Few organizations can feasibly place every site and system into scope at once, especially with legacy stacks and tight downtime constraints. Typical approaches include:
- Phased scoping: Start with a small but meaningful subset of sites, products, or customers, then expand. Ensure the initial scope is not so narrow that it appears like compliance theater.
- Functional scoping: Include all locations for certain functions (e.g., design and central IT), but only specific manufacturing sites. Be explicit about which sites are excluded and why.
- System-centric justification: When leaving legacy systems out of scope, you must show how they are segregated, monitored, or otherwise controlled so that they do not undermine the ISMS.
Full replacement of legacy MES/ERP/OT stacks solely to simplify ISO 27001 scope is rarely practical due to qualification burden, validation cost, downtime risk, and integration complexity. Scoping must work with the existing environment.
6. Include relevant third parties and cloud services
Third parties handling in-scope information are usually within scope for ISO 27001 control coverage, even if they are outside your organizational boundary. Consider:
- Cloud platforms hosting PLM, QMS, data lakes, or analytics.
- Managed service providers, including remote OT maintenance and monitoring.
- Suppliers accessing your portals or receiving controlled technical data.
The scope statement should clarify that these relationships are covered by the ISMS via supplier management, contracts, and technical controls, even if the suppliers themselves are not part of your certification boundary.
7. Document inclusions, exclusions, and justifications
An auditor will pay close attention to how clearly and honestly you describe boundaries. Your scope definition and supporting documentation should include:
- In-scope items: sites, processes, information types, systems, and roles.
- Explicit exclusions: sites, business units, or system categories that are out of scope.
- Justifications: why exclusions do not materially affect the confidentiality, integrity, or availability of in-scope information.
- Interfaces: how interfaces across the boundary are controlled, monitored, and governed.
Vague or overly optimistic exclusions are a common source of findings. If in doubt, make the dependency explicit and treat it as part of your risk treatment plan.
8. Align scope with risk assessment and Statement of Applicability
Your scope drives which assets are assessed and which controls are considered. To be coherent:
- Perform a risk assessment only on assets within the defined scope.
- Ensure the Statement of Applicability (SoA) explains control inclusions and exclusions in the context of the declared scope.
- Make sure operational realities (e.g., shared networks between in-scope and out-of-scope areas) are visible in the risk register.
If the SoA or risk assessment implicitly covers things that are “out of scope” on paper, your scoping will appear inconsistent.
9. Validate with stakeholders and keep under change control
Before finalizing the scope:
- Review with operations, engineering, quality, and IT/OT leaders to ensure it matches real-world responsibilities and constraints.
- Verify that the scope is sustainable given long equipment lifecycles, validation obligations, and expected plant changes.
- Place the scope document under formal change control. Any major organizational, process, or technology change should trigger a scope review.
This is especially important where validated systems or regulated production processes are involved, as changes to scope may require updates to validation, procedures, and training.
10. Signs your ISO 27001 scope is likely too narrow or weak
You should reconsider the scope if:
- It excludes critical sites or lines that produce the same products the scope claims to cover.
- It omits OT even though key recipes, batch records, or process parameters are stored on OT systems.
- It excludes central IT or networks that clearly process or route in-scope information.
- It relies on assumptions like “no sensitive data is stored here” without evidence.
Conversely, a scope that tries to cover the entire global enterprise from day one often fails due to complexity and the need to harmonize controls across very different plants and legacy stacks.
In summary, determining ISO 27001 scope in an industrial, regulated environment is a structured exercise in matching business objectives, information flows, and practical constraints. The outcome should be a clear, justified boundary that can withstand audit scrutiny and can be maintained over the long life of your equipment, systems, and customer commitments.
