Can we exclude certain plants from our ISO 27001 scope?

Yes, it is possible to exclude specific plants from your ISO 27001 scope, but only if the scope boundaries are clearly defined, technically and organizationally credible, and not misleading to internal or external stakeholders.

What ISO 27001 actually allows

ISO 27001 allows you to define the scope of the information security management system (ISMS). This can be a subset of your organization, such as:

• Selected plants or business units
• Specific functions (for example, engineering or IT) that serve certain plants
• Specific products, contracts, or information types

In principle, you can leave some plants out of scope. In practice, this is acceptable only when the exclusions do not undermine the integrity of the ISMS or misrepresent how widely it applies.

Conditions for excluding plants

Excluding a plant usually passes auditor scrutiny only if:

• Scope is precisely defined in writing. The scope statement explicitly names which plants, functions, or locations are included and, by omission or wording, which are not.
• Shared services are treated consistently. If an out-of-scope plant uses in-scope systems (for example, corporate MES, ERP, PLM, QMS, Active Directory, cloud services), the ISMS must clearly cover those shared systems and the interfaces. You cannot claim those systems are secure for one plant but irrelevant for another if they are technically shared.
• Information flows are understood. Where information (design data, production data, quality records, OT data) moves between in-scope and out-of-scope plants, the risks at the interfaces are identified and controlled.
• The justification is risk-based, not cosmetic. Exclusions made just to simplify certification or avoid complex sites will be challenged, especially if the excluded plants handle sensitive data or critical production.
• There is no implication of enterprise-wide coverage. Your public and internal communications, certificates, and policies must not imply that all plants are ISO 27001 certified when only a subset is in scope.

Brownfield realities: shared IT/OT and legacy systems

In regulated, brownfield manufacturing environments, drawing a clean line around “in-scope” and “out-of-scope” plants is often harder than it looks:

• Centralized IT services. Active Directory, email, VPN, and sometimes MES/ERP are shared across plants. If an out-of-scope plant can access in-scope systems, its posture still matters for overall risk.
• Shared OT networks or remote access. Remote maintenance, IIoT gateways, or vendor tunnels may connect multiple plants. An out-of-scope plant can still be a point of compromise for in-scope operations.
• Common engineering, PLM, and QMS systems. Engineering or quality functions may be in one location but serve multiple plants. If the ISMS covers those functions, the plants that depend on them become relevant to scope design.
• Long-lived equipment and integrations. Legacy OT assets and long-validated integrations make segregation difficult. Creating “paper” scope boundaries that do not match technical reality usually fails under audit or incident review.

This does not mean you must include every plant. It does mean you need a defensible explanation of why excluded plants do not materially change the risk picture for the in-scope ISMS.

Risks and tradeoffs of excluding plants

Key tradeoffs when excluding plants include:

• Residual risk exposure. Out-of-scope plants can still be attack paths into corporate or shared systems. Exclusion does not remove the underlying risk; it only limits which controls are systematically governed by the ISMS.
• Audit and customer scrutiny. Customers, regulators, or auditors may ask why certain critical or high-volume plants are excluded. Weak justifications can damage credibility.
• Complexity of governance. Operating two classes of sites (in scope and out of scope) increases policy and control complexity, especially for shared services and global processes.
• Future expansion cost. Starting with a narrow scope may be pragmatic, but each later expansion requires additional risk assessment, control deployment, and sometimes re-validation of systems already tightly coupled across plants.

Practical steps if you decide to exclude some plants

If you want to keep certain plants outside the initial ISO 27001 scope:

1. Map systems and data flows. Identify which plants share IT/OT systems (MES, ERP, PLM, QMS, historians, networks, cloud services). This is essential to decide if exclusions are technically credible.
2. Define and document the scope statement. Clearly state which legal entities, locations, and plants are covered. Avoid vague phrases like “global” or “enterprise” if the scope is limited.
3. Align the Statement of Applicability (SoA). Ensure the SoA and risk assessment reflect the real boundaries. Controls that depend on plant-level implementation must reference only the in-scope plants.
4. Document justification for exclusions. Record why specific plants are excluded (for example, no handling of sensitive data, fully segregated networks, different legal entity, or phased rollout). This helps during audits and internal reviews.
5. Set minimum baselines for out-of-scope plants. Even if they are out of ISMS scope, define a minimum security baseline to reduce systemic risk, especially where plants connect to shared corporate services.
6. Plan for potential scope expansion. In long-lifecycle manufacturing, bringing additional plants into scope later is common. Design your ISMS so expansion is feasible without major rework.

Why “full replacement” or instant enterprise-wide scope often fails

Some organizations try to jump directly to an enterprise-wide ISO 27001 scope spanning all plants. In regulated and high-criticality manufacturing, this often stalls due to:

• Qualification and validation burden. Aligning all validated systems and OT assets at once with ISO 27001 controls can trigger heavy re-qualification efforts.
• Downtime risk. Rolling out new controls or network segmentation simultaneously across all plants may not be compatible with production and maintenance windows.
• Integration complexity. Legacy integrations across MES, ERP, PLM, and OT are difficult to change safely at scale.
• Traceability and change control requirements. Regulated environments need rigorous documentation and approvals for changes, which slows large-scope transformations.

This is why many organizations start with a limited scope (for example, a pilot plant or a critical product line) and then expand. Excluding some plants can be part of a phased strategy, provided that the limitations and residual risks are explicit.

Summary

You can exclude certain plants from your ISO 27001 scope, but not casually. The exclusions must be justified by real organizational and technical boundaries, clearly described in the scope statement, and supported by risk assessment. In brownfield, multi-plant environments with shared systems, drawing these boundaries correctly is often the hardest part of the work.