In ISO 27001, the scope is the formal, written definition of what parts of your organization the Information Security Management System (ISMS) applies to. It sets the physical, organizational, and technical boundaries within which you manage information security risks according to the standard.
What the ISO 27001 scope must cover
The scope statement should clearly identify:
- Organizational boundaries: Business units, legal entities, and functions covered (for example: corporate IT only, or corporate IT plus selected plants).
- Physical locations: Sites, offices, data centers, and plants that are in scope, including remote or hosted environments.
- Information and processes: Types of information and the processes that create, process, store, or transmit it (for example: production planning, quality records, engineering data, supplier data).
- Systems and technologies: Applications, infrastructure, OT/ICS, and cloud services governed by the ISMS.
- Interfaces and dependencies: How in-scope systems interact with out-of-scope systems, partners, and suppliers.
The scope must be consistent with your context, risk assessment, and interested parties. ISO 27001 does not dictate a single “correct” scope, but the scope cannot be defined in a way that hides or ignores significant information security risks.
How scope works in complex manufacturing environments
In regulated, brownfield operations, the scope decision has practical constraints:
- Legacy and OT systems: Many plants have SCADA, PLCs, and legacy MES that are difficult to patch or monitor. You must explicitly decide whether these are in or out of scope, and document the rationale and compensating controls if excluded.
- Mixed vendor stacks: ERP, MES, PLM, QMS, and data historians from multiple vendors typically span IT and OT. If you include one layer in scope (for example, MES), interfaces to out-of-scope layers must still be risk-assessed and controlled.
- Downtime and change windows: A wider scope can increase the operational impact of required controls (for example, change control for firewall rules on production cells), so scope must be realistic about what can be governed without jeopardizing uptime.
- Long lifecycle equipment: Some assets will not support modern controls. The scope statement should acknowledge these limitations and point to risk acceptance, isolation, or layered controls instead of implying full technical conformity.
Typical scope patterns
In practice, organizations in industrial and regulated environments often choose one of these patterns:
- Corporate IT only: The ISMS covers corporate networks, business applications, and central services. OT and shop-floor systems are explicitly out of scope, but are recognized as interfaces or dependencies.
- Selected plants or value streams: The ISMS covers specific sites, lines, or programs, usually where regulatory or customer pressure is highest, with a plan to expand over time.
- Integrated IT/OT scope: The ISMS covers both corporate IT and defined OT environments (for example, all lines producing a certain regulated product), with explicit recognition of legacy constraints and tailored controls.
A full “everything, everywhere” scope can be attractive on paper but frequently fails in long-lifecycle environments because it becomes too costly to implement, validate, and maintain controls across all assets and sites, especially where downtime and change control are heavily constrained.
Key tradeoffs when defining ISO 27001 scope
- Coverage vs. implementability: A broad scope provides better risk coverage but is harder to operationalize and maintain, especially across multiple plants and vendors.
- IT vs. OT inclusion: Including OT increases relevance to real production risk, but also increases complexity, integration challenges, and the need for OT-specific controls and competencies.
- Regulatory & customer expectations: A narrow scope may meet the letter of ISO 27001 but may not satisfy aerospace, defense, or pharma customers if critical production or technical data environments are excluded without a clear rationale.
- Evidence and traceability burden: A wider scope multiplies the volume of assets, changes, and records you must control and evidence. In environments with strict validation and change control, this can be a major operational load.
Practical considerations for defining scope
When you draft your ISO 27001 scope in an industrial context:
- Base it on a documented understanding of your business processes and information flows, not just org charts.
- Describe boundaries in terms of processes, sites, and systems so it is clear what is included and excluded.
- Identify critical interfaces to other systems and partners, and show how those risks are addressed even if the external systems are out of scope.
- Ensure the scope is stable enough to be maintained over the life of your assets, but flexible enough to extend as you modernize.
- Keep the scope statement aligned with your risk assessment and Statement of Applicability so auditors and customers can trace your logic.
The result should be a scope that is realistic for your brownfield environment, transparent about constraints, and supportable over time without implying guarantees you cannot operationally sustain.