Connect981 – Content Dev

RSC Sphere: Data Integration, Security and Trust

The Data Integration, Security and Trust Sphere establishes the governance layer that makes everything else credible. It focuses on system interoperability, data mapping, version control, audit trails, and security alignment for regulated environments. The content makes clear how execution data can move safely across ERP, MES, QMS, PLM, and supplier systems without compromising control. This sphere proves that interoperability and security can coexist in aerospace ecosystems.

  • asset hierarchy

    Core meaning

    An **asset hierarchy** is a structured representation of physical assets and related locations, organized into levels that show how equipment, systems, and areas relate to each other in a facility or across multiple sites.

    In industrial and manufacturing environments, an asset hierarchy commonly:

    – Starts at top levels such as enterprise, site, area, and line or system
    – Breaks down into equipment, sub-equipment, and sometimes component or tag level
    – Includes logical or functional groupings (e.g., utilities system, packaging line) and physical locations (e.g., room, suite, zone)

    The hierarchy provides a consistent “map” for where assets live in the organization and how they are related.

    Use in operational and maintenance systems

    Asset hierarchies are implemented in systems such as:

    – **CMMS / EAM**: to structure equipment records, preventive maintenance plans, work orders, and spare parts associations
    – **MES and SCADA/OT systems**: to align process data, equipment states, and production contexts with specific assets or asset groups
    – **ERP**: to align cost centers, asset accounting records, and sometimes plant maintenance structures with physical assets

    In daily workflows, people use the asset hierarchy to:

    – Log and track maintenance work against the correct equipment and location
    – Analyze reliability or downtime by line, system, or component
    – Associate production events, alarms, or quality issues with specific equipment or areas
    – Control access or responsibilities (e.g., maintenance teams by area or system)

    Structure and levels

    There is no single mandatory structure, but common patterns include levels such as:

    – **Enterprise / company**
    – **Site / plant**
    – **Area / department / building**
    – **Line / system / unit**
    – **Equipment / asset**
    – **Sub-equipment / component / instrument**

    Some organizations implement parallel hierarchies (e.g., functional vs physical vs location-based) when supported by their systems.

    Boundaries and what it is not

    An asset hierarchy:

    – **Is**
    – A structural model of how assets and locations are organized and related
    – A reference used by multiple systems for consistent asset identification
    – **Is not**
    – A maintenance plan, work-order schedule, or spare parts list (these reference the hierarchy but are separate)
    – A process model or recipe definition, although it may align with them
    – A pure accounting fixed-asset list, though it may be reconciled with accounting records

    Common confusion and variations

    – **Versus equipment hierarchy**: Many organizations use the terms interchangeably. “Equipment hierarchy” is often a subset focused strictly on maintainable equipment, while “asset hierarchy” may also include rooms, lines, utilities, or infrastructure.
    – **Versus process hierarchy (e.g., ISA-95 / ISA-88 models)**: Process models describe production activities, units, and recipes. Asset hierarchies focus on physical equipment and locations, though modern systems often align these models.
    – **Across disciplines**: Engineering, maintenance, and finance may maintain different hierarchies (functional, location-based, financial). In integrated manufacturing environments, these are often mapped or partially harmonized rather than fully merged.

    Site context: relation to MES and maintenance integration

    When MES integrates with **CMMS** or **EAM** systems, the asset hierarchy is a key reference point. Typical uses include:

    – Mapping MES equipment models (lines, cells, units) to CMMS/EAM asset records
    – Triggering maintenance work orders from MES events (e.g., downtime, condition limits) against the correct asset
    – Consolidating reliability and production data by line, area, or equipment, based on a shared hierarchy

    Consistent, well-governed asset hierarchies help MES, maintenance, and ERP systems refer to the same physical assets, even when they use different level structures internally.

  • interface specification

    An interface specification is a formal document or definition that describes how two or more systems, software components, or devices interact with each other. It defines the structure, format, behavior, and constraints of the information exchanged, as well as the rules that each side must follow for the integration to work reliably.

    What an interface specification typically includes

    In industrial operations and manufacturing IT/OT environments, an interface specification commonly covers:

    • Scope and purpose: Which systems or components are connected (for example, ERP to MES, MES to SCADA, L3 to L2) and what business or operational processes the interface supports.
    • Data model: Definitions of messages, records, tags, and fields, including names, data types, units of measure, valid values, and cardinality.
    • Protocols and transport: How data moves between systems, such as REST/HTTP APIs, OPC UA, message queues, file drops, or database links.
    • Interaction patterns: Whether communication is request/response, publish/subscribe, event-driven, or batch, and the timing or frequency of exchanges.
    • Directionality and responsibilities: Which system is the source of truth for each data element, which initiates transactions, and how conflicts are handled.
    • Error handling and retries: Expected responses to failures, timeouts, invalid data, and how retries or compensating actions are performed.
    • Security and access: Authentication, authorization, encryption, and logging expectations related to the interface.
    • Versioning and change control: How changes to the interface are introduced, versioned, and validated so that connected systems remain compatible.

    Role in manufacturing and regulated environments

    In manufacturing, interface specifications commonly describe the integration boundaries defined in models such as ISA-95. They document how enterprise systems (for example ERP, PLM, LIMS, QMS) and operations systems (for example MES, SCADA, historians, equipment controllers) exchange:

    • Master data (materials, recipes, routings, specifications)
    • Production orders, schedules, and dispatch lists
    • Production results, quality records, and traceability data
    • Equipment states, alarms, and performance metrics

    In regulated or audit-sensitive environments, interface specifications are often controlled documents. They help support validation, impact assessment, change management, and troubleshooting by clearly stating what each system is expected to send, receive, and do.

    What an interface specification is not

    An interface specification is:

    • Not the implementation itself: It describes behavior and data, but does not replace the actual code, configuration, or middleware that realizes the interface.
    • Not a general system design: It focuses on the boundary between systems and how they communicate, not on all internal logic or architecture details.
    • Not a guarantee of interoperability: Systems still require correct implementation, mapping, testing, and validation against the specification.

    Common confusion

    • Interface specification vs. API documentation: API documentation usually describes a specific technical API (for example REST endpoints). An interface specification may reference one or more APIs and also capture higher-level business rules, responsibilities, and sequencing.
    • Interface specification vs. data mapping: A data mapping document focuses on how fields in one system correspond to fields in another. An interface specification is broader and includes protocol, timing, error handling, and behavior.
    • Interface specification vs. ISA-95 models: ISA-95 provides generic models and categories for information exchange between levels. An interface specification applies those concepts to a concrete implementation between specific systems.

    Use in practice

    Operationally, interface specifications are used by architects, integrators, and validation teams to design, implement, test, and maintain system integrations. They serve as a reference during:

    • Integration design and vendor selection
    • System configuration and custom development
    • Factory acceptance testing, site acceptance testing, and regression testing
    • Incident investigation and root cause analysis for interface-related issues
    • Change control and impact assessment when either connected system is upgraded

  • Manufacturing Information Portal

    A Manufacturing Information Portal is a web-based interface that provides centralized access to manufacturing data, reports, and selected applications from across shop-floor and enterprise systems. It typically acts as a single entry point for users to view, query, and navigate production-related information without needing to log directly into each underlying system.

    Key characteristics

    While implementations vary by organization, a Manufacturing Information Portal commonly:

    • Aggregates data from multiple systems such as MES, SCADA, LIMS, historians, quality systems, and ERP
    • Provides role-based dashboards, KPIs, and reports for operations, quality, maintenance, and management users
    • Offers secure, browser-based access to manufacturing information, often inside the corporate intranet
    • Uses a common navigation structure so users can find production, quality, and asset data in one place
    • Integrates with identity and access management to control who can see which data

    In regulated manufacturing environments, the portal is typically positioned as a read-only or limited-interaction layer on top of validated systems, so that core data and workflows remain controlled in the source applications. The portal may show data such as batch status, deviations, equipment status, OEE, material usage, and genealogy, while write actions (such as releasing batches or changing master data) continue to occur within MES, ERP, or other transactional systems.

    Operational role

    Operationally, a Manufacturing Information Portal often functions as the front-end to an integration or data access layer. It may sit on top of a data warehouse, data lake, historian, or a manufacturing integration platform. Typical uses include:

    • Real-time or near real-time production monitoring dashboards
    • Self-service access to manufacturing reports and trend charts
    • Consolidated quality and deviation overviews across sites or lines
    • Access points to digital documents such as work instructions, SOPs, and batch records (often via links into controlled systems)
    • Role-specific homepages for operators, supervisors, engineers, and quality staff

    In multi-site or multi-system environments, the portal can provide a standardized way to view information even when underlying systems differ by site or business unit. In such cases, data harmonization, governance, and clear ownership are needed outside the portal itself.

    What it is not

    A Manufacturing Information Portal is not:

    • A replacement for core transactional systems such as MES, ERP, SCADA, LIMS, or CMMS
    • Automatically a data warehouse or historian, although it may rely on these as data sources
    • In itself a guarantee of data integrity, regulatory compliance, or audit readiness

    Instead, it is a presentation and access layer that depends on the design, validation, and governance of the systems and integrations underneath it.

    Common confusion

    The term Manufacturing Information Portal is sometimes confused with related concepts:

    • Manufacturing Integration Platform (MIP): Focuses on moving, transforming, and orchestrating data and messages between systems. It is typically middleware or an integration layer. A Manufacturing Information Portal, by contrast, is a user-facing web interface that may sit on top of such a platform.
    • Manufacturing Execution System (MES): Manages and records execution of production processes. A Manufacturing Information Portal may display MES data but does not usually manage workflows, enforce sequencing, or execute shop-floor transactions.

    Use in regulated environments

    In regulated industries, a Manufacturing Information Portal is commonly configured to respect data ownership and traceability boundaries. Examples include:

    • Viewing batch and lot status consolidated from multiple validated systems
    • Displaying audit-relevant metrics and reports generated by underlying applications
    • Providing read-only access to key production indicators for auditors or stakeholders through controlled, role-based views

    Any use of the portal for actions that affect product release, quality decisions, or regulated records usually relies on the validated behavior and controls of the underlying systems rather than the portal itself.

  • ESB

    Core meaning

    ESB (Enterprise Service Bus) is a middleware architecture and software platform used to connect multiple enterprise applications by routing, transforming, and orchestrating messages between them.

    In manufacturing and other industrial environments, an ESB commonly sits between business systems (such as ERP), operations systems (such as MES, LIMS, WMS), and sometimes plant-level applications, providing a standardized way for them to exchange data.

    How an ESB operates

    An ESB typically provides:

    – **Message routing:** Directs messages from a producer (e.g., MES) to one or more consumers (e.g., ERP, quality system) based on configurable rules.
    – **Message transformation:** Converts data formats or structures (for example, from a plant-specific schema to a standardized enterprise schema).
    – **Protocol mediation:** Bridges different communication protocols or technologies (e.g., HTTP/SOAP, REST, JMS, file, database adapters).
    – **Orchestration and workflow:** Coordinates multi-step exchanges across several systems (e.g., create production order in MES, then update ERP when order is closed).
    – **Centralized integration logic:** Holds routing and transformation rules in one place instead of duplicating them in every connected application.

    ESBs are usually implemented as a combination of a runtime engine (message bus) and configuration or development tools used to define integration flows.

    Use in MES–ERP and industrial integrations

    In industrial and regulated manufacturing environments, an ESB is commonly used to:

    – Mediate **MES–ERP** exchanges for production orders, material master data, equipment states, and confirmations.
    – Integrate **quality and laboratory systems** (e.g., LIMS, QMS) with MES and ERP for test results and release status.
    – Connect **warehouse and logistics** systems (WMS/TMS) to production and planning systems.
    – Apply **validation-sensitive transformations** in a controlled, versioned layer when integration logic must be traceable and testable.

    In these settings, the ESB often coexists with other patterns (file transfers, database views, APIs, queues). It can serve as the hub that standardizes and governs integrations across heterogeneous OT and IT landscapes.

    Boundaries and what ESB is not

    – **Not a single protocol or standard:** ESB is an architectural style and product category, not a specific protocol like OPC UA or MQTT.
    – **Not an MES or ERP:** It does not manage production execution or business transactions; it transports and transforms messages about those activities.
    – **Not just a message queue:** While it may use message queues underneath, an ESB adds routing, transformation, and orchestration on top of basic queuing.
    – **Not inherently cloud or on-premises only:** ESBs can be deployed on-premises, in the cloud, or in hybrid forms.

    Common confusion and related concepts

    – **ESB vs. message broker/queue:** A message broker (e.g., a JMS broker or simple queue) focuses on reliable message transport and buffering. An ESB usually includes a broker plus mapping, routing, protocol mediation, and sometimes process orchestration.
    – **ESB vs. iPaaS:** An integration Platform as a Service (iPaaS) is a cloud-based integration platform. Many iPaaS offerings provide ESB-like capabilities, but the term iPaaS emphasizes delivery model (cloud) while ESB emphasizes architecture and functionality.
    – **ESB vs. API gateway:** An API gateway fronts and manages APIs (security, rate limiting, routing for API calls). An ESB can call or host APIs but focuses on back-end message flows across multiple systems.

    Site-context application

    Within MES–ERP integration, an ESB commonly:

    – Exposes standardized integration endpoints for MES and ERP rather than point-to-point custom interfaces.
    – Transforms MES-specific data models into ERP structures (and vice versa) while preserving auditability.
    – Implements routing rules for events like order release, production reporting, material consumption, and quality results.
    – Acts as the central place to manage and version integration logic when plants or sites have different system versions or validation requirements.

    This use aligns with broader enterprise integration patterns, while addressing the additional traceability and change-control needs typical of regulated manufacturing.

  • shared-responsibility model

    A shared-responsibility model is a documented understanding of how responsibilities for security, compliance, and operational controls are divided between a service provider and a customer. In industrial and manufacturing environments, it is commonly used for cloud platforms, industrial software, and managed services that are part of the OT/IT stack.

    What it includes

    The shared-responsibility model usually describes:

    • Provider responsibilities, such as platform security features, infrastructure hardening, built-in logging, availability controls, and default configurations.
    • Customer responsibilities, such as user and role management, network segmentation, configuration of security settings, procedure documentation, and local validation or testing.
    • Joint or conditional responsibilities, where both parties contribute (for example, applying patches provided by the vendor, or configuring audit logging features in line with plant policy).

    In regulated manufacturing environments, the model is often aligned with control frameworks such as NIST 800-53 or ISO-style information security controls. The provider may map its capabilities to specific controls, while the customer must show how those capabilities are deployed, configured, and governed in the plant context.

    Operational meaning in industrial settings

    Practically, a shared-responsibility model helps clarify:

    • Who maintains system configurations and access controls for MES, historians, or industrial data platforms.
    • Who provides evidence of control operation during audits, such as change records, validation reports, or network diagrams.
    • Which party owns incident response steps for security events affecting OT and connected IT systems.
    • How responsibilities may differ between on-premises, hybrid, and cloud-hosted components.

    The model is typically captured in security or quality documentation, supplier agreements, or platform reference architectures, and should be kept under change control as the system or scope evolves.

    Common confusion

    • Not the same as a service-level agreement (SLA): An SLA focuses on performance and availability targets. A shared-responsibility model focuses on who does what for controls and operations.
    • Not a compliance certificate: The model explains role boundaries. It does not, by itself, prove that controls are effectively implemented or validated in a specific plant.

    Link to the NIST 800-53 context

    When industrial platforms describe alignment with NIST 800-53, a shared-responsibility model helps show which controls the provider supports directly and which remain the customer’s responsibility. This allows manufacturers to design their own control environment, gather appropriate evidence, and avoid assuming that platform capabilities alone meet all framework expectations.

  • SL 1

    SL 1 is a cybersecurity security level commonly used in industrial control system standards to describe protection against casual or accidental misuse, rather than deliberate, well-resourced attacks.

    Core meaning

    In industrial and OT cybersecurity, Security Level 1 (SL 1) usually refers to the lowest defined level of protection in a multi-level scheme (often SL 1 through SL 4). It typically includes:

    • Basic user authentication (for example, unique logins, simple password policies)
    • Foundational network protections (for example, simple firewalls or access lists)
    • Basic hardening and configuration control (for example, disabling unused accounts or services)
    • Protections mainly aimed at preventing inadvertent changes and casual probing

    SL 1 generally assumes that an attacker has limited motivation, limited skills, and limited resources. It is not intended to address targeted, sophisticated, or persistent cyber attacks.

    Use in industrial and regulated environments

    In regulated manufacturing and critical infrastructure, SL 1 is often applied to:

    • Non-safety-critical support systems that still connect to OT networks
    • Legacy equipment that cannot be upgraded to higher security levels
    • Zones where risk assessments show low impact to safety, quality, or regulatory outcomes

    Risk-based architectures may mix different SLs across zones and conduits. Some systems or zones may appropriately target SL 1, while others require SL 2, SL 3, or higher, depending on criticality and risk.

    Relationship to standards

    Security levels, including SL 1, are commonly associated with industrial cybersecurity frameworks and standards. These schemes define capability requirements for each level in areas such as access control, data integrity, system availability, and change management. The detailed criteria vary by standard, but the intent of SL 1 remains a baseline of protection against non-targeted threats.

    Operational implications

    In practice, specifying SL 1 for a system or zone typically means:

    • Documenting the target security level in design and risk assessments
    • Implementing minimum controls aligned with that level
    • Recognizing that the system is not designed to withstand focused, skilled attackers

    For OT, MES, and integrated IT/OT systems, SL 1 serves as a reference point for scoping security controls and for explaining why some systems should not be expected to meet higher levels such as SL 3 or SL 4.

    Common confusion

    • Not the same as “no security”: SL 1 includes basic, documented protections and is more than an unmanaged or open system.
    • Not a maturity level: SL 1 describes targeted technical capability against defined threat types, not organizational process maturity.
    • Not universally required: Some assets may intentionally remain outside formal SL classification, depending on risk and architecture.

    Tie to the risk-based context

    When deciding whether a system should aim for SL 1, SL 2, or higher, organizations typically consider:

    • Impact on safety, product quality, and regulatory compliance if compromised
    • Feasibility of implementing stronger controls on existing OT and legacy equipment
    • Availability of compensating controls at the network or procedural level

    Within a risk-based security program, SL 1 is a deliberate design choice for low-risk environments, rather than a default for all systems.

  • What is the IEC 62443 standard about?

    IEC 62443 is a family of international standards focused on cybersecurity for industrial automation and control systems (IACS). It provides a structured way to define, design, implement, operate, and maintain security for OT environments such as manufacturing plants, utilities, and process facilities.

    Core purpose

    The standard is intended to:

    In practice, this connects to industrial security evidence when teams need to turn the answer into repeatable execution habits.

    • Provide a common language for asset owners, integrators, and product suppliers to discuss and specify security needs.
    • Define security requirements for systems and components, not just IT networks.
    • Support risk-based, defense-in-depth approaches rather than one-size-fits-all controls.
    • Cover the full lifecycle of industrial systems, including design, integration, operation, and maintenance.

    IEC 62443 does not guarantee security, compliance, or successful audits. It is a framework for specifying and assessing requirements. The outcome depends on how rigorously it is applied, integrated, validated, and maintained.

    Scope: what IEC 62443 covers

    IEC 62443 addresses cybersecurity for:

    • Control systems and their networks (DCS, SCADA, PLCs, safety systems, IIoT gateways).
    • Engineering workstations, HMIs, historians, and related OT infrastructure.
    • Associated processes and governance, including suppliers and integrators.

    It is designed for mixed, brownfield environments where multiple vendors, protocols, and generations of equipment coexist. It explicitly recognizes layered architectures, zones and conduits, and long asset lifecycles.

    Structure of the IEC 62443 series

    The standard is divided into parts grouped by audience and focus. Commonly cited examples include:

    • General (e.g., 62443-1-x): terminology, models, and high-level concepts such as security levels and risk assessment frameworks.
    • Policies & procedures (e.g., 62443-2-x): requirements for security programs and operations, including management systems for IACS cybersecurity.
    • System requirements (e.g., 62443-3-x): security requirements for system design and integration, zones and conduits, and defense-in-depth architectures.
    • Component requirements (e.g., 62443-4-x): secure development lifecycle practices for vendors and technical requirements for components (e.g., embedded devices, applications).

    Not every part will be relevant to every plant. Asset owners, integrators, and suppliers typically focus on different subsets depending on their role.

    Security levels and risk-based approach

    IEC 62443 introduces Security Levels (SLs) from SL 1 to SL 4, which roughly map to increasing attacker capability (from casual to highly resourced and targeted). These are applied to zones and conduits rather than the entire site.

    Key implications for industrial operations:

    • Security controls are chosen based on risk and required SL, not a generic checklist.
    • Different zones (e.g., safety systems vs. office networks) can and usually should have different target SLs.
    • Legacy systems may not be able to meet target SLs directly and may require compensating controls such as segmentation, jump hosts, or procedural constraints.

    Roles and responsibilities

    The standard distinguishes between:

    • Asset owners: plants, operators, manufacturers that operate the IACS.
    • System integrators: parties that design and integrate systems, networks, and controls.
    • Product suppliers: vendors of hardware, firmware, and software components.

    Requirements are assigned differently to each role. In practice, many manufacturers act as both asset owner and integrator, and sometimes as solution builder, which can blur responsibilities and complicate implementation and validation.

    How IEC 62443 fits into existing OT/IT environments

    Most regulated plants have long-lived assets and brownfield systems. IEC 62443 is explicitly designed to coexist with:

    • Existing DCS/SCADA/PLC platforms from multiple vendors.
    • MES, historian, and ERP systems that cannot be easily replaced.
    • Legacy protocols and devices that were not originally built with cybersecurity in mind.

    In these environments, IEC 62443 is typically used to:

    • Define zones and conduits around existing systems instead of replacing them outright.
    • Introduce compensating controls where devices cannot meet requirements (for example, network segmentation, strict remote access procedures, or additional monitoring).
    • Inform selection and qualification of new equipment so that, over time, the installed base moves closer to the target security levels.

    Full, big-bang replacement of legacy systems to “be IEC 62443 compliant” is rarely realistic in regulated, high-availability manufacturing. Qualification burden, downtime risk, interface complexity, and the need to maintain continuity of validated processes usually force incremental, zone-by-zone improvements instead.

    Regulated and validated environments

    For plants operating under regulatory oversight, IEC 62443 can provide a structured reference for cybersecurity expectations, but:

    • It does not replace regulatory requirements or industry-specific guidance (for example, from aviation, pharma, or nuclear regulators).
    • Controls derived from IEC 62443 may need to be validated, documented, and justified in the context of product quality and safety.
    • Change control, traceability, and configuration management are critical when applying new security controls to validated systems.

    Any adoption should be accompanied by clear documentation of scoping, risk assessments, chosen target security levels, and the rationale for compensating controls where full implementation is not technically or operationally feasible.

    What IEC 62443 is not

    It is important to be explicit about the limits:

    • It is not a guarantee of compliance, safety, or security outcomes.
    • It is not a single checklist or certification that instantly makes a plant secure.
    • It is not limited to IT security; it focuses on industrial automation systems and their full lifecycle.
    • It is not prescriptive about specific vendors or technologies; it sets requirements, not product selections.

    Successful use of IEC 62443 depends on realistic scoping, prioritization based on risk, integration with existing OT/IT processes, and disciplined change and configuration management.

  • How do IEC 62443 zones relate to IT network segments and VLANs?

    IEC 62443 security zones are logical groupings of assets with similar security requirements and risk profiles. IT network segments and VLANs are implementation mechanisms. They are related, but they are not the same thing and rarely map 1:1 in brownfield industrial environments.

    What an IEC 62443 zone actually is

    Under IEC 62443, a zone is defined by:

    In practice, this connects to industrial security evidence when teams need to turn the answer into repeatable execution habits.

    • Common security requirements (e.g., SL 1 vs SL 3)
    • Similar risk exposure and impact if compromised
    • Functional roles (e.g., safety systems, basic control, historian)
    • Trust level and required degree of isolation

    Zones are therefore an abstract, risk- and function-based construct. They exist before you decide how to implement them in IP addressing, VLANs, firewalls, or ACLs.

    How zones relate to IP subnets and VLANs

    Network segments and VLANs are common ways to enforce separation between zones, but the relationship is flexible:

    • 1 zone ↔ many VLANs / subnets: A safety zone might span several VLANs (e.g., geographically separate units) that share identical security requirements and policies.
    • Many zones ↔ 1 VLAN / subnet: In legacy plants, different systems with different risk levels may coexist in one flat VLAN, but you can still logically define multiple zones inside it and enforce separation with host firewalls, ACLs, or gateway devices.
    • Nested/logical zones inside a segment: A DMZ or jump host segment might host assets that support multiple zones, separated by firewall rules and strict access policies, not by VLAN alone.

    In a greenfield design, you will often align “one major zone per subnet or VLAN” for simplicity and traceability. In brownfield environments, especially with long qualification cycles, you frequently end up with zones that do not neatly align with existing network boundaries.

    Conduits vs VLANs and routing

    IEC 62443 defines conduits as controlled communication paths between zones. In implementation terms, conduits usually map to:

    • Firewall rulesets and security policies between IP networks
    • Access control lists on routers and layer 3 switches
    • VPNs, jump hosts, or application proxies between trust levels

    A conduit is about the policy set and trust boundary, not the specific technology. A single physical link or trunk carrying multiple VLANs might include traffic for several conduits; equally, a single logical conduit (e.g., OT-to-historian traffic) might be implemented by several paths and devices.

    Practical patterns in regulated, brownfield plants

    In real industrial environments you will commonly see:

    • Legacy flat OT networks: One large VLAN or subnet spanning many controllers and HMIs, where you define zones conceptually first and then progressively enforce isolation through firewalls, switch ACLs, and endpoint controls during upgrades.
    • Segmented core, flat cells: Each production line or cell sits in its own VLAN, but that VLAN still contains multiple logical zones (basic control, safety, engineering workstations). Here, you often introduce internal firewalls, access controls, or strict host hardening to separate zones.
    • Shared infrastructure zones: Historians, jump servers, antivirus servers, and backup systems may serve several zones. They often live in their own zone (e.g., OT services zone) with defined conduits to production zones and to the IT network.

    In aerospace and other highly regulated sectors, fully refactoring the network to make zones perfectly align with VLANs is often not feasible due to:

    • Validation and qualification burden for critical systems
    • Downtime constraints on high-utilization assets
    • Integration complexity with existing MES/ERP/QMS stacks
    • Long lifecycles of PLCs, safety systems, and test stands

    As a result, you typically layer zoning on top of existing segments, then converge gradually as equipment is refreshed.

    Key design and documentation considerations

    When relating zones to network segments and VLANs, it is important to:

    • Start with the logical zone model: Define zones based on risk, function, and security requirements before deciding on VLAN boundaries.
    • Create an explicit mapping: Maintain diagrams and configuration references that show how each zone maps to subnets, VLAN IDs, firewall interfaces, and conduits. This is critical for traceability and audits.
    • Be clear about shared segments: Where multiple zones share a VLAN or subnet, document the compensating controls (host firewalls, ACLs, jump hosts, strict hardening) and their limits.
    • Align with change control and validation: Changes to VLANs, routing, or firewall rules that affect zones should follow formal change control, with impact assessment on validated systems and associated documentation.
    • Plan for stepwise migration: For legacy OT networks, define a roadmap to progressively align critical zones with dedicated VLANs or network segments as assets are replaced or revalidated.

    Typical pitfalls

    Common mistakes when equating zones with VLANs include:

    • Assuming “one VLAN = one zone” without verifying that all assets in the VLAN share the same security level and risk profile.
    • Relying solely on VLANs for security, without proper L3/L4 controls, monitoring, and hardening.
    • Ignoring non-IP paths (serial, fieldbus, vendor remote access tools) that create cross-zone connections outside VLAN boundaries.
    • Failing to update zone-to-VLAN mapping when network changes are made, breaking traceability for audits and incident response.

    How this plays with IT/OT coexistence

    In mixed IT/OT environments, you will usually end up with:

    • Distinct IEC 62443 zones for enterprise IT, DMZ/bridge, and multiple OT levels (e.g., site, area, cell)
    • Multiple IT subnets and VLANs mapping into a single high-level “IT zone” from an OT perspective
    • Dedicated conduits between IT and specific OT zones, implemented as firewall policies, application proxies, or tightly controlled data diodes

    The key is to treat VLANs and network segments as tools used to implement the zone and conduit model, not as the model itself. The zone definition should remain stable even if you later refactor the underlying network, as long as the security characteristics and trust boundaries are preserved.

  • 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.