An Information Security Management System (ISMS) does not have to be global. You can define the scope so it covers only specific plants, business units, processes, or systems. This is explicitly allowed in standards like ISO 27001, as long as the scope is clearly defined, justified, and consistently applied.
How scoping works in practice
For regulated manufacturing and industrial operations, common scope choices include:
- One or more specific plants (e.g., all aerospace machining sites in a region)
- Specific functions (e.g., OT networks and shop-floor systems only)
- Specific information types (e.g., export-controlled technical data or customer IP)
- Specific systems (e.g., MES, historians, and engineering workstations that handle regulated data)
The key requirement is that the scope statement is unambiguous and that all in-scope assets, processes, and interfaces are covered by ISMS controls, governance, and evidence.
Constraints and tradeoffs of a limited scope
Limiting scope to certain plants or systems can be practical, but it introduces non-trivial complications in a brownfield, multi-site environment:
- Shared infrastructure: Corporate Active Directory, networks, cloud services, and email often span plants. If only some plants are in scope, you must define and control how shared services meet security requirements for in-scope sites without implying coverage for out-of-scope ones.
- Cross-site data flows: Technical data, production records, and quality documentation frequently move between plants and corporate functions. You need documented controls at the interfaces where in-scope environments connect to out-of-scope ones, or you risk unprotected data paths.
- Vendor and integration dependencies: MES, ERP, PLM, and QMS are often shared or tightly integrated across plants. If a plant is in scope but depends on a shared system that is out of scope, you must clearly show how risks are managed and what controls apply to that shared system.
- Audit and certification perception: If you choose certification, auditors will test whether the scope statement is honest and whether you avoid implying that the entire organization is managed under the ISMS. Marketing or internal communications that blur the scope can create issues.
- Operational complexity: Running different security baselines and processes for in-scope vs. out-of-scope plants can increase confusion for IT/OT teams and complicate change control and incident response spanning multiple sites.
When a plant-level scope makes sense
A plant-only scope can be pragmatic when:
- The plant handles particularly sensitive or regulated data (e.g., defense, export-controlled, or high-ITAR-content work).
- The plant has distinct networks, systems, and local IT/OT management, making separation operationally realistic.
- You are piloting an ISMS before expanding to other plants and want to reduce initial validation and documentation effort.
- Other plants or corporate functions are not yet ready from a process maturity or tooling standpoint.
In aerospace-grade or similarly regulated contexts, a phased, plant-level rollout can also reduce the qualification and validation burden compared to a sudden, global change to security controls and processes.
Risks of keeping the scope too narrow
A very narrow scope can become a problem if:
- Critical security dependencies are outside the scope, but effectively determine the risk posture of in-scope plants (e.g., centralized identity, patching, or SOC services).
- Business users and customers assume broader coverage than actually exists, leading to misplaced trust or contractual misunderstandings.
- Incident handling, forensics, and evidence collection require cooperation from out-of-scope environments that are not subject to the same controls or documentation rigor.
- The complexity of managing exceptions and interfaces outweighs the savings from limiting the scope.
Key design points for a multi-plant ISMS scope
If you decide not to go global from day one, you should still:
- Write a precise scope statement: Identify plants, systems, and data types in scope, and explicitly mention what is out of scope. This includes outsourced or shared services.
- Map interfaces and data flows: Document how in-scope plants exchange information with out-of-scope plants, suppliers, and corporate IT, and assign responsibility for controls at each interface.
- Align with existing frameworks: If you use OT security standards such as IEC 62443, ensure the ISMS scope is consistent with your defined zones, conduits, and system boundaries.
- Integrate with change control: Make sure any infrastructure, MES/ERP/QMS changes, or plant expansions trigger a review of ISMS scope and risk assessments, rather than silently moving assets in or out of scope.
- Plan for future expansion: Design policies, procedures, and tooling so they can extend across additional plants without rework, even if the initial scope is limited.
Why “global by default” is not always realistic
In regulated, long-lifecycle manufacturing environments, a global ISMS covering all plants and systems can be ideal in theory but hard to implement in one step:
- Plants use different vintages of OT equipment and control systems that cannot be uniformly hardened or monitored without downtime and requalification.
- Centralizing controls across legacy MES, ERP, and PLM stacks may require significant integration work and validation, especially where production records and quality data are regulated.
- Rolling out standard security processes (e.g., access reviews, backup regimes, and incident response) globally can strain already-limited operational and IT resources.
Because of these realities, many organizations scope their ISMS to a subset of plants and then extend coverage in phases as systems, integrations, and process maturity improve.
Summary: An ISMS does not have to be global. You can scope it to specific plants, but you must define the boundaries clearly, manage interfaces to out-of-scope environments, and recognize the operational and audit tradeoffs in a brownfield, multi-plant manufacturing context.
