An ISO 27001 scope statement needs to be detailed enough that a competent external party can clearly understand what is covered by your Information Security Management System (ISMS) and what is not. It does not need to be a full asset inventory, but it does need to be unambiguous about boundaries, responsibilities, and key dependencies.
Minimum expectations for scope statement detail
For most regulated industrial and manufacturing environments, a defensible scope statement should at least cover:
- Legal entity and business units: Clearly state which legal entity or entities, and which business units or functions, are in scope. If your company has multiple plants or subsidiaries, specify which ones are included.
- Physical locations: Identify each in-scope site (e.g., Plant A, Plant B, corporate HQ, data center regions). If you include only offices and not production areas, that limitation must be explicit.
- Core processes and services: Describe the main processes and services covered, such as design engineering, production planning, MES administration, quality data management, or outsourced IT operations. This should align with what you present to customers and regulators.
- Information types: Indicate the main categories of information (e.g., product design data, NC programs, manufacturing records, quality data, customer specifications, export-controlled technical data, personal data related to employees or visitors) that the ISMS is intended to protect.
- Technical scope anchors: Name the major information systems and platforms that are clearly in scope, such as ERP, MES, PLM, QMS, core network segments, cloud services, and key OT/ICS environments where applicable. You do not need to list every server, but you should anchor the scope to identifiable systems and environments.
- Exclusions: Explicitly list significant exclusions that a reader might reasonably assume are included. For example, a specific plant, a legacy OT network, R&D labs, or third-party logistics systems. Exclusions must be justified in terms of risk and business context, not just convenience.
- Interfaces and dependencies: Highlight important dependencies on external providers (cloud services, managed service providers, outsourced manufacturing, logistics, contractors) and high-impact internal systems that are out of scope but closely interfaced. This is critical in brownfield environments with many legacy or third-party systems.
If someone outside your organization can still argue about whether a given plant, system, or data flow is in scope after reading the statement, it is probably not detailed enough.
What does not belong in the scope statement
The scope statement should be concise. You should avoid:
- Listing all individual assets, devices, or user groups. That level of detail belongs in the asset register, network diagrams, and supporting ISMS documentation.
- Describing detailed controls or procedures. Controls belong in the Statement of Applicability and supporting policies, not in the scope statement.
- Overly broad wording such as “all information” or “all systems” when you know there are major exclusions (e.g., some plants, legacy OT, R&D test rigs). This creates misalignment and audit risk.
- Marketing language about security posture or compliance guarantees. The scope statement is descriptive, not promotional.
Balancing breadth and practicality in industrial environments
In regulated manufacturing, it is common that not all plants, OT networks, or legacy applications can be brought into scope at once due to qualification burden, validation cost, and downtime constraints. A practical scope statement will:
- Admit that only certain sites, lines, or environments are currently in scope, rather than implying a full enterprise or global scope.
- Describe how in-scope environments interact with out-of-scope ones (for example, MES in scope, but some machine controllers or legacy SCADA out of scope).
- Avoid tying the ISMS scope so tightly to a specific application or vendor that any change (e.g., MES replacement) forces a major scope rewrite and potential re-audit.
Full, enterprise-wide scope is often aspirational in brownfield plants that run mixed vendor stacks and legacy OT. It is more realistic to define a clear, contained scope you can actually manage, secure, and maintain under change control.
How specific should site and system boundaries be?
For a realistic level of detail:
- Sites: Name sites individually, especially if they host different classes of systems (e.g., production plants vs. offices vs. data centers).
- Networks: Use meaningful descriptions such as “corporate IT network for in-scope sites” or “OT network segments directly hosting in-scope MES and historian systems.” High-level network scoping helps auditors understand interfaces and reachable assets.
- Systems and services: Identify major systems and services by type and, if needed, by name (e.g., “the validated QMS for GMP products” or “cloud-based PLM used for aerospace programs”). Avoid vague phrases like “all business applications” if this is not true.
The goal is for an auditor to be able to trace from the scope statement to concrete assets and environments through your supporting documentation, without guessing.
Dependencies and shared environments
Many plants share IT and OT infrastructure across in-scope and out-of-scope operations. Your scope statement should acknowledge this reality, but the detailed segregation measures will live elsewhere. At minimum, your statement should:
- Flag that some shared infrastructure (e.g., identity management, network core, backup systems) supports both in-scope and out-of-scope systems.
- Indicate that such shared components are addressed in the risk assessment and control design, even if some consuming environments are out of scope.
- Avoid the impression that shared platforms are fully out of scope if they can materially impact the confidentiality, integrity, or availability of in-scope information.
Traceability and change control expectations
In regulated and long-lifecycle environments, the scope statement must be stable enough to survive normal system evolution, but flexible enough to reflect major changes. Practically, this means:
- Defining scope based on enduring business processes, sites, and information types rather than specific product versions or point solutions where possible.
- Maintaining clear traceability from the scope statement to your asset inventory, network zoning, and Statement of Applicability, so changes in one area can be evaluated for scope impact.
- Putting scope changes under formal change control, with re-assessment of risk, evidence, and (if applicable) validation impacts, especially when adding or removing plants, OT networks, or critical systems.
Practical litmus tests for scope detail
Your ISO 27001 scope statement is probably detailed enough if:
- An external auditor can determine, without further clarification, whether a specific plant, application, or process is in or out of scope.
- IT, OT, engineering, and quality leaders all give the same answer when asked what is covered.
- It is feasible to maintain and apply consistently under your current configuration management and change control practices.
If these conditions are not met, you likely need to add more specificity around entities, sites, processes, and systems, or make exclusions and interfaces more explicit.
