Connect981 – Content Dev

RSC Topic: Cybersecurity & Regulatory Alignment

Practical handling of CMMC, NIST 800-171, DFARS, ITAR contexts.

  • What is the IEC 62443 in a nutshell?

    IEC 62443 is a family of international standards for cybersecurity of industrial automation and control systems (IACS). It provides a common reference for how asset owners, system integrators, and product suppliers should define, design, implement, and maintain cybersecurity for operational technology (OT).

    Core idea in one sentence

    IEC 62443 breaks OT cybersecurity into roles, zones/conduits, and security levels, then defines requirements for each role and level across the system lifecycle, from product development through integration and plant operation.

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

    What IEC 62443 covers

    The standard is organized as a series of parts. In practice, organizations use them as a framework for requirements, design, and assessment, not as a checklist that guarantees security.

    • Foundations and concepts (e.g. IEC 62443-1-x): terminology, risk concepts, and the idea of security zones and conduits.
    • Policies and procedures for asset owners (e.g. IEC 62443-2-x): how to manage cybersecurity programs, incident response, patching, and lifecycle management at the site or enterprise level.
    • System-level requirements (e.g. IEC 62443-3-x): how to architect and engineer secure control systems, including network segmentation, access control, and monitoring.
    • Component and product requirements (e.g. IEC 62443-4-x): secure product development practices and technical requirements for devices and applications.

    Key concepts relevant to regulated manufacturing

    • Security levels (SL 1 to 4): describe protection against increasingly capable threat actors. They help you specify and justify how much protection a given zone needs, instead of treating all assets the same.
    • Zones and conduits: group assets with similar risk and trust requirements into zones, and define controlled conduits between them. This fits brownfield plants where you cannot redesign everything, but can segment and harden critical paths.
    • Role-based responsibilities: separates expectations for asset owners, system integrators, and product suppliers. In mixed-vendor environments, this is important for contract language and integration planning.
    • Lifecycle focus: emphasizes secure design, deployment, operation, maintenance, and decommissioning. This aligns with long equipment lifecycles and change control realities common in regulated plants.

    How it fits into brownfield, regulated environments

    Most plants already run legacy DCS/PLC/MES/ERP stacks, often with limited downtime windows and complex validation or qualification burdens. IEC 62443 is usually applied incrementally rather than via a full system replacement.

    • Incremental hardening: segment legacy networks into zones, restrict remote access, and improve account management using IEC 62443 concepts without replacing all hardware.
    • Procurement and integration criteria: use IEC 62443 parts and security levels in RFQs and integration specs so new equipment and software are more secure and easier to integrate with existing stacks.
    • Change control and validation: map cybersecurity changes (patching, configuration baselines, new appliances) to formal change-control workflows and, where applicable, validation or qualification activities.
    • Coexistence with IT frameworks: IEC 62443 can sit alongside ISO 27001, NIST CSF, or corporate IT policies. Typically, corporate IT sets enterprise policies, while IEC 62443 provides OT-specific requirements and design patterns.

    What IEC 62443 does not guarantee

    IEC 62443 is a guidance and requirements framework, not a security guarantee. In particular:

    • Conformance to parts of IEC 62443 does not ensure regulatory compliance, safe operation, or specific audit outcomes.
    • Security posture still depends heavily on site-specific design, vendor implementations, integration quality, and ongoing maintenance.
    • In long-lifecycle plants, many legacy components will never fully meet current technical requirements; risk must be managed with compensating controls.

    For most industrial organizations, “using IEC 62443” means aligning policies, architectures, and procurement with its concepts, then applying it pragmatically given brownfield constraints, rather than attempting a wholesale rebuild of control systems.

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

  • What is the difference between 62443 and 27001?

    IEC 62443 and ISO/IEC 27001 address related but different aspects of cybersecurity. In regulated industrial environments they are usually applied together rather than one replacing the other.

    Core focus of each standard

    IEC 62443:

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

    • Scope: Industrial automation and control systems (IACS), including PLCs, DCS, SCADA, HMIs, safety systems, network infrastructure, and associated software/services.
    • Focus: Technical and lifecycle security of operational technology (OT) and control systems.
    • Perspective: System and component level security, zones and conduits, security levels for specific use cases.
    • Target audience: Control system vendors, integrators, plant engineering, operations, and OT security teams.

    ISO/IEC 27001:

    • Scope: Organization-wide information security management system (ISMS) for information assets (digital and sometimes physical), usually IT-centric.
    • Focus: Governance, risk management, and controls for confidentiality, integrity, and availability of information.
    • Perspective: Management system, policies, processes, and high-level control objectives (e.g., access control, incident management, supplier management).
    • Target audience: Corporate IT, security governance, risk and compliance (GRC), and business leadership.

    What each standard is designed to achieve

    IEC 62443 is intended to:

    • Reduce cybersecurity risk to industrial processes and equipment, including safety and availability impacts.
    • Guide secure design, integration, operation, and maintenance of control systems.
    • Define specific security requirements for components, systems, and service providers.
    • Support risk-based segmentation (zones and conduits) and defense-in-depth in plants.

    ISO/IEC 27001 is intended to:

    • Establish, implement, maintain, and continually improve an ISMS.
    • Ensure information security risks are identified, assessed, and treated in a structured way.
    • Provide a framework for policies, procedures, and controls (defined in Annex A and related standards).
    • Support auditability and organizational accountability for information security.

    Key differences in regulated industrial environments

    • Object of protection:
      • 62443: Protects industrial processes, physical equipment, and control system integrity/availability, with safety and production continuity as primary concerns.
      • 27001: Protects information assets and supporting services, typically with confidentiality as a major driver.
    • Level of detail:
      • 62443: More prescriptive for industrial networks and devices (e.g., segmentation, hardening, secure remote access, patching constraints).
      • 27001: Higher-level management system requirements with flexible choice of specific technical controls.
    • Lifecycles and change control:
      • 62443: Recognizes long equipment lifecycles, constrained downtime, and strict change control around validated/qualified systems.
      • 27001: Addresses change management at a policy and process level, but not the detailed reality of OT validation, requalification risk, or multi-decade assets.
    • Brownfield integration:
      • 62443: Explicitly deals with mixed-vendor, legacy control systems and segmentation strategies to manage inherent weaknesses.
      • 27001: Treats legacy systems as part of the risk landscape but does not give OT-specific design patterns.
    • Regulatory linkage:
      • 62443: Often referenced in industrial cybersecurity guidance (e.g., for critical infrastructure, process industries, and safety-related systems), but does not guarantee compliance outcomes.
      • 27001: Sometimes used to demonstrate due diligence around information security governance; still no guarantee of passing any specific regulator or customer audit.

    How they usually coexist in a plant

    In most manufacturing and industrial operations, IEC 62443 and ISO/IEC 27001 are complementary:

    • ISO/IEC 27001 sets the overarching governance, risk, and policy framework for information security across the organization.
    • IEC 62443 provides OT-specific methods and requirements for securing control systems within that broader framework.

    Common coexistence patterns include:

    • Risk management alignment: The ISMS risk assessment (27001) treats OT as a critical domain. Detailed OT risk assessments, zone/conduit designs, and security levels follow IEC 62443 guidance.
    • Policy vs. implementation: Corporate policies (acceptable use, remote access, supplier security) are owned under 27001, while the technical implementation for plants (jump hosts, engineering workstations, segmented networks) is designed around 62443.
    • Supplier and integrator management: Supplier security requirements are governed by 27001 processes, but the technical requirements in RFQs and contracts for control systems often refer to specific IEC 62443 parts.
    • Incident management: The incident process and reporting are defined under the ISMS, but playbooks, containment, and recovery for OT follow 62443-informed constraints (e.g., limited reboot/patch windows, safety risks).

    How well they integrate in reality depends heavily on:

    • Quality of interfaces between IT security governance and OT engineering/operations.
    • Maturity of asset inventory and network visibility across plants.
    • Constraints from validation, qualification, and regulatory change control.
    • Legacy vendor support and the feasibility of applying 62443 controls to older equipment.

    Certification and audit considerations

    ISO/IEC 27001 is widely used as a certifiable standard for an ISMS. Many organizations seek formal certification from accredited bodies for specific scopes (e.g., corporate IT, data centers).

    IEC 62443 includes requirements that vendors, integrators, and service providers can be assessed against, and there are conformity assessment schemes in the market. However, using IEC 62443 or ISO/IEC 27001 does not guarantee any specific regulatory, customer, or safety audit outcome.

    In regulated and long-lifecycle environments, attempts to “rebuild” security from scratch around a single standard often fail because of:

    • Downtime and requalification risk for validated production lines.
    • Integration complexity across mixed OT/IT stacks and legacy MES/ERP/QMS systems.
    • Vendor limitations on modifying control systems without impacting warranties, certifications, or safety cases.

    When to apply which standard

    In practice:

    • Use ISO/IEC 27001 to structure your overall information security governance, risk management, and organizational controls.
    • Use IEC 62443 to drive design, procurement, hardening, and operation of industrial control systems and OT networks.

    For plants with established systems and limited change windows, incremental alignment is usually more realistic than full, rapid implementation of either standard. Focus efforts where process, safety, and regulatory impacts are highest, and ensure changes are properly documented, tested, and controlled within existing quality and validation frameworks.

  • privacy baseline

    A privacy baseline is a documented set of minimum, organization-wide requirements for how personal or otherwise sensitive data must be collected, processed, stored, shared, and retained across systems and processes. In industrial and manufacturing environments, it provides a consistent reference for designing and operating OT, IT, MES, ERP, and quality systems so that handling of identifiable or sensitive data aligns with applicable privacy expectations and regulations.

    The privacy baseline typically defines what types of data are considered in scope (for example, employee identifiers, operator performance records, visitor logs, or customer-related production data), what purposes are allowed for using that data, who may access it, and what protections must be in place. It is expressed at a level that can be traced into system requirements, configurations, and procedures.

    Typical elements of a privacy baseline

    Although content varies by organization, a privacy baseline commonly includes:

    • Data classification rules for personal, sensitive, and non-personal data used in operations, quality, maintenance, and engineering systems.
    • Collection and use constraints describing what data may be collected from workers, suppliers, and customers, and for which defined purposes.
    • Access control principles that specify which roles may see identifiable data, under what conditions, and how role changes are handled.
    • Data minimization and pseudonymization requirements, such as using operator IDs instead of names in certain reports or dashboards.
    • Logging and monitoring expectations that balance traceability and audit needs with limits on exposure of identifiers and sensitive attributes.
    • Retention and deletion rules for operational logs, production history, audit trails, video, badge records, and training or competency data.
    • Data sharing constraints for transfers to third parties, cloud services, analytics platforms, and cross-site data lakes.
    • Change control and documentation expectations, ensuring updates to systems, interfaces, and analytics respect the baseline.

    Operational role in manufacturing environments

    In regulated manufacturing, the privacy baseline is used as a design and validation input for both new and legacy systems. It influences how MES and ERP are configured, how quality and deviation records store operator and patient-related data, and how shop floor intelligence tools log events and performance metrics. The baseline is typically referenced when:

    • Designing or updating user roles, access matrices, and identity integration between OT and IT systems.
    • Configuring security tools such as SIEM, endpoint monitoring, and audit logging so that collected events do not exceed allowed identifiers or retention limits.
    • Defining interfaces between plant-level systems and corporate or cloud analytics, including which fields are masked, aggregated, or removed.
    • Planning data retention and archival behavior for production records, training data, and maintenance logs, especially where people are identifiable.
    • Executing change control, to confirm that new features, devices, or data flows still comply with documented privacy requirements.

    Relationship to security baselines

    A privacy baseline is related to, but distinct from, security baselines. Security baselines specify minimum technical and procedural controls to protect systems and data from unauthorized access, modification, or loss. The privacy baseline defines which data is permitted to exist in those systems, for what purposes, in what form, and who may see it.

    In practice, the privacy baseline constrains how security controls are implemented. For example, it can define what identifiers may appear in logs, how long logs containing personal data may be retained, and under what conditions monitoring tools may capture screens or keystrokes. Both baselines are typically developed and maintained together, with traceability to system-level requirements and configurations.

    Common confusion

    • Privacy baseline vs. security baseline: A security baseline focuses on protecting systems and data (for example, authentication, patching, network segmentation). A privacy baseline focuses on which personal or sensitive data may be present and how it may be used and exposed. They are interdependent but not interchangeable.
    • Privacy baseline vs. privacy policy: A privacy policy is often an external-facing statement describing how an organization handles personal data. A privacy baseline is generally an internal, operational specification that engineers, system owners, and process owners use to configure and run systems consistently.

    Use in brownfield and legacy environments

    When applied to long-lived equipment and legacy MES or ERP systems, a privacy baseline helps identify where existing data handling does not align with current expectations. This can drive compensating controls such as masking identifiers in reports, restricting access to certain screens, adjusting logging configurations, or introducing data brokers that filter or anonymize data before it is stored or exported.

  • How should OT security responsibilities be distributed between IT and operations?

    OT security works only as a joint responsibility between IT and operations. In regulated, brownfield environments, neither group can safely own it alone. The right model is a shared, explicitly documented split of responsibilities, with clear escalation paths and change control.

    Core principle: joint accountability, clear ownership

    Both IT and operations are accountable for OT security outcomes, but they own different layers:

    • IT typically leads on enterprise security capabilities (networking, identity, monitoring, incident response tooling).
    • Operations typically leads on process safety, availability, and equipment behavior (what can be changed, when, and how).

    Trying to centralize everything in IT usually breaks on process and availability constraints. Pushing everything to operations usually breaks on security depth, tooling, and regulatory expectations for cyber controls.

    Typical IT-owned responsibilities

    The exact split varies by site and vendor stack, but in most industrial environments IT should own:

    • Network and perimeter security
      • Design and maintenance of firewalls, VLANs, DMZs, and remote access solutions that segment OT from corporate IT.
      • Standard configurations for VPNs, jump hosts, and secure vendor access, in coordination with operations schedules.
    • Core identity and access management
      • Corporate directory services (e.g., AD) and single sign-on where feasible.
      • Policies for authentication, password complexity, MFA, and account lifecycle for users who access OT systems.
    • Enterprise security monitoring
      • Security information and event management (SIEM) platforms, log aggregation, and correlation rules.
      • Threat intelligence and detection engineering, including use cases that include OT events where supported.
    • Baseline security services (where technically and operationally feasible)
      • Endpoint protection on engineering workstations, HMIs, and OT servers that can support it and have been tested.
      • Central patch infrastructure for systems under IT change control, with operations governing timing.
    • Incident response leadership for cyber aspects
      • Coordinating triage, forensics, and external notifications for cyber incidents.
      • Driving standard incident playbooks that include OT-specific steps agreed with operations.

    All of this must respect plant constraints. Many OT assets cannot be scanned, patched, or instrumented like office IT due to vendor qualification limits, obsolete OS versions, and validation burdens. IT should own the tooling and methods, but must implement them only where operations accepts the impact and risk tradeoffs.

    Typical operations-owned responsibilities

    Operations (often with engineering and maintenance) must own any security decision that can affect plant safety, product quality, or availability. Typical responsibilities include:

    • Asset inventory and criticality ranking
      • Maintaining the authoritative list of OT assets (PLCs, DCS, HMIs, sensors, drives, historian servers, OT applications).
      • Classifying assets by safety, regulatory, and production criticality to drive risk-based security controls.
    • Process constraints for security changes
      • Defining what downtime windows exist and what kinds of intervention (scans, patches, firmware updates) are acceptable for each asset class.
      • Approving or rejecting changes based on impact to process safety, product quality, and validated state.
    • Configuration control for OT systems
      • Managing PLC, DCS, HMI, MES, and SCADA configuration changes under documented change control.
      • Reviewing and approving any security hardening, patching, or vendor updates that alter control logic or validated parameters.
    • Physical and local access control
      • Controlling who can physically access panels, cabinets, OT server rooms, and shop-floor engineering workstations.
      • Managing day-to-day enforcement of badge, key, and escort policies on the floor.
    • First-level response in the plant
      • Recognizing and reporting abnormal behavior in equipment and systems that might be security-related.
      • Executing plant-side steps during incidents (e.g., isolating a cell, switching to manual mode) consistent with safety and quality procedures.

    Operations must ensure that any mandated cyber controls (for example from a corporate policy or external standard) are checked against process, safety, and regulatory needs before implementation.

    Responsibilities that should be explicitly shared

    Some areas are inherently cross-functional and cannot be safely assigned to just one group. These should be handled via joint governance and documented RACI:

    • OT security architecture and zoning
      • Designing network zones and conduits for OT in line with frameworks such as IEC 62443.
      • Agreeing which traffic is allowed between OT and enterprise networks, and which technologies are approved for bridging.
    • Vendor and system lifecycle decisions
      • Choosing OT security products (e.g., industrial firewalls, OT monitoring) and integrating them with existing MES/SCADA/QMS stacks.
      • Planning migrations or replacements for obsolete systems where security risk is no longer tolerable, including validation and downtime planning.
    • Risk assessments and controls selection
      • Performing OT-specific threat and risk assessments jointly, with IT providing cyber risk expertise and operations providing process and safety context.
      • Agreeing risk acceptance criteria and compensating controls when direct fixes are not feasible on legacy equipment.
    • Policy and standard development
      • Writing OT security standards that are technically enforceable and operationally realistic.
      • Ensuring that corporate security policies explicitly account for regulated manufacturing, validation, and long asset lifecycles.
    • Incident response playbooks
      • Defining procedures that combine IT tasks (containment, forensics) with plant tasks (safe shutdown, line clearance, batch segregation, documentation).
      • Rehearsing joint exercises and updating playbooks based on lessons learned.

    Working in brownfield, regulated environments

    Most plants already run a mix of legacy and modern systems. Full replacement of OT platforms purely for security reasons rarely succeeds because of:

    • Qualification and validation burden for control systems, MES, and related infrastructure.
    • Downtime risk and limited outage windows for critical assets.
    • Integration complexity with existing ERP, QMS, PLM, and historian systems.
    • Long equipment lifecycles where OEM support is limited or conditional.

    IT and operations therefore need a shared strategy that emphasizes:

    • Compensating controls (network segmentation, jump hosts, controlled media handling) when direct patching is not possible.
    • Documented risk acceptance where legacy constraints prevent meeting corporate standards fully.
    • Incremental, risk-based hardening aligned to planned outages and validation cycles.

    Practical way to formalize the split

    A workable structure in many organizations is:

    1. Define joint OT security governance
      • Create an OT security steering group with IT security, operations, engineering, and quality representation.
      • Give it authority to set standards, approve exceptions, and prioritize remediation work.
    2. Establish a written RACI
      • List key activities such as asset inventory, patching, firewall rule changes, new vendor connectivity, and incident response.
      • Assign who is Responsible, Accountable, Consulted, and Informed for each, at site and corporate levels.
    3. Integrate with existing change control
      • Ensure all OT security changes pass through established engineering and quality change processes.
      • Include impact assessments for safety, quality, validation status, and uptime, not just security.
    4. Align on minimum baselines
      • Define a baseline set of OT controls (e.g., segmentation, backups, access control, logging) that every site must meet, with room for local adaptation.
      • Explicitly document where legacy or vendor constraints require deviations.
    5. Test and iterate
      • Run tabletop exercises and small pilots to validate that responsibility splits work in practice.
      • Adjust the RACI and procedures based on actual incidents, near misses, and audit findings.

    Key tradeoffs to acknowledge

    When distributing OT security responsibilities, it helps to make tradeoffs explicit:

    • Security vs. availability: aggressive scanning, patching, or endpoint controls may reduce cyber risk but increase unplanned downtime risk on sensitive OT assets.
    • Standardization vs. local realities: uniform corporate policies simplify governance but may be impossible on older equipment without major retrofits.
    • Speed vs. assurance: fast rollout of new tools can conflict with qualification, validation, and operator training requirements.

    Documenting who owns which decision in each of these tradeoffs, and under what conditions, is more important than achieving a theoretically perfect split.

  • What is the ISO for security management system?

    The primary ISO standard for an information security management system (ISMS) is ISO/IEC 27001. It specifies the requirements for establishing, implementing, maintaining, and continually improving a documented ISMS.

    Core standard

    ISO/IEC 27001 defines how to:

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

    • Identify and assess information security risks
    • Select and implement security controls
    • Operate an ISMS within a management system framework (policy, roles, objectives, internal audit, management review, continual improvement)

    On its own, it does not guarantee cybersecurity or regulatory compliance. It provides a structured framework that must be tailored to your actual risk profile, systems, and processes.

    Supporting standards commonly used with ISO/IEC 27001

    In practice, organizations rarely use ISO/IEC 27001 alone. Frequently used companion standards include:

    • ISO/IEC 27002: Guidance on specific security controls (e.g., access control, logging, backup, supplier security).
    • ISO/IEC 27019: Information security controls for the energy utility industry (relevant for some industrial control contexts).
    • ISO/IEC 62443 (series): Not an ISO/IEC 27000-family standard, but widely referenced for industrial control system (ICS) and OT security. Often mapped into an ISMS for plants.

    Which of these you can actually implement depends on your brownfield landscape, vendor capabilities, network architecture, and available operational downtime.

    How this fits industrial and regulated environments

    In manufacturing and other regulated operations, ISO/IEC 27001 is typically integrated with existing management systems, for example:

    • Quality: ISO 9001, AS9100, IATF 16949
    • Environment/health & safety: ISO 14001, ISO 45001

    Instead of replacing existing processes or systems (MES, ERP, QMS, PLM), an ISMS usually overlays and coordinates them. Trying to fully replace legacy platforms just to align with ISO/IEC 27001 is rarely practical in regulated, long-lifecycle plants because of:

    • Qualification and validation burden for new systems and interfaces
    • Downtime risk when changing core production or quality systems
    • Integration complexity with mixed vendors and bespoke interfaces
    • Traceability and change control requirements that slow large-scale system swaps

    Most plants instead incrementally harden and govern existing systems under the ISMS, focusing on documented risk assessments, access control, monitoring, and change management.

    Limits and dependencies

    Being aligned with or certified to ISO/IEC 27001 does not guarantee:

    • Regulatory compliance (e.g., export controls, sector-specific cyber rules)
    • Freedom from security incidents or data breaches
    • Specific audit outcomes from customers or regulators

    Outcomes depend heavily on:

    • The scope of the ISMS (which sites, systems, and processes are truly included)
    • Data classification and realistic threat modeling for OT/ICS and IT
    • Integration quality with existing MES/ERP/QMS/PLM and plant networks
    • How well changes are documented, tested, and validated before deployment

    For an industrial operation, the practical question is usually not “Are we ISO/IEC 27001?” but “Which parts of our environment are in scope, how does the ISMS connect to our brownfield systems, and where are the residual risks?”