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.

  • Can I be certified to NIST 800-53?

    No. You cannot be formally “certified” to NIST Special Publication 800-53 in the same way that organizations are certified to standards like ISO 27001 or ISO 9001.

    What NIST 800-53 actually is

    NIST SP 800-53 is a catalog of security and privacy controls used primarily within U.S. federal and defense-related risk management frameworks (for example, the NIST Risk Management Framework and FedRAMP). It defines what types of controls should exist, not a certifiable management system standard.

    What you can realistically claim

    • You can design and operate your controls to be aligned with NIST 800-53.
    • You can undergo a third-party assessment or internal audit that evaluates your implementation of selected 800-53 controls.
    • You can show that your environment meets a specific overlay or profile derived from NIST 800-53 (for example, as part of a customer, government, or prime contractor requirement).

    But those activities result in attestations, assessment reports, or audit opinions, not an official NIST 800-53 “certificate.” Any certificate you receive will be issued by a commercial assessor and reflects their opinion, not a NIST or government certification to 800-53 itself.

    How this fits in regulated industrial environments

    In industrial and OT-heavy plants, NIST 800-53 is often used alongside or underneath other frameworks and customer requirements. Typical patterns include:

    • Mapping controls: Mapping NIST 800-53 controls to your existing cybersecurity framework (for example, NIST CSF, IEC 62443, ISO 27001) and to internal policies. This is especially common where you already have validated, long-lived systems on the plant floor.
    • Brownfield constraints: Many legacy MES, DCS, and OT assets cannot easily meet all 800-53 controls without major redesign, revalidation, or downtime. In practice, you may implement compensating controls and document residual risk instead of strict one-to-one conformance.
    • Control-by-control approach: For regulated manufacturing, you typically prioritize controls tied to system integrity, access management, incident response, and configuration/change control, then build a roadmap for the rest.

    Evidence and assurance instead of certification

    Because there is no NIST 800-53 certification, external stakeholders (regulators, primes, auditors, internal risk committees) will look for:

    • Documented mappings from NIST 800-53 controls to your policies, standards, and procedures.
    • Risk assessments that show how you evaluated each relevant control and justified scope and exclusions.
    • Implementation evidence such as configurations, network diagrams, access reviews, and monitoring logs, especially around OT/IT boundaries.
    • Change control and validation records for security-relevant changes in MES, SCADA, PLCs, and supporting infrastructure.

    Independent assessors can review this material and issue reports, but those reports remain assessments of your control posture, not NIST 800-53 certifications.

    How to position this in your organization

    When communicating with management, customers, or auditors, it is more accurate to say:

    • “Our cybersecurity control set is aligned with NIST SP 800-53, subject to documented scoping and compensating controls,” or
    • “We undergo periodic independent assessment against selected NIST SP 800-53 control families relevant to our OT and IT environment.”

    This framing avoids implying a certification that does not exist while still showing serious engagement with the NIST 800-53 control framework.

  • Feature store

    A feature store is a data management layer used in machine learning to create, organize, store, version, and serve features, which are the input variables used by models. It commonly provides a consistent way to use the same feature definitions in model development and in live or near-real-time scoring.

    In industrial and manufacturing settings, a feature store may hold engineered inputs derived from historians, MES, ERP, quality systems, lab systems, sensors, and maintenance records. Examples include rolling average temperature, cycle-time variance, recent alarm counts, supplier defect rate, or the number of nonconformances for a part family over a defined period.

    What it includes

    A feature store commonly includes:

    • Feature definitions, including business logic or transformation rules used to derive model inputs
    • Storage for historical features used in training and validation
    • Serving capabilities for operational use, such as batch or online retrieval for inference
    • Metadata and governance, such as lineage, versioning, ownership, freshness, and data quality information

    It is not the same thing as a general data lake, historian, or data warehouse, although it often depends on those systems as upstream sources.

    Operational meaning

    Operationally, a feature store helps teams avoid recreating the same feature logic in multiple notebooks, scripts, or applications. In a manufacturing workflow, this can support repeatable model inputs for use cases such as predictive maintenance, quality prediction, yield analysis, anomaly detection, or schedule risk scoring.

    For example, a plant may define a feature such as the last 12-hour vibration trend for a machine, or the count of rework events for a work order. The feature store can make that definition available both for model training on past production data and for current scoring in a monitoring or decision-support workflow.

    Common confusion

    Feature store vs. data lake: a data lake stores broad raw or curated datasets, while a feature store is focused on model-ready inputs and their reuse.

    Feature store vs. model registry: a model registry tracks models and their versions, while a feature store tracks and serves the input features used by those models.

    Feature store vs. ETL pipeline: ETL pipelines move and transform data, but a feature store adds a reusable layer for feature management, serving, and governance.

    Boundary note

    The term usually refers to infrastructure for machine learning operations rather than a user-facing application. Some platforms bundle feature store functions with broader MLOps, analytics, or data engineering tools, so the exact product boundary can vary.

  • What is the ISA-88 standard and how does it define batch process control?

    ISA-88, commonly called S88, is a standard for batch process control. In practice, it provides a consistent way to model batch operations, equipment, recipes, and procedural execution so that batch processes are easier to design, automate, maintain, and transfer across lines or sites.

    At a high level, ISA-88 defines batch control through a few core ideas:

    • A physical model that describes the manufacturing assets involved in batch production, typically from enterprise and site down to area, process cell, unit, equipment module, and control module.

    • A procedural model that describes how a batch runs, usually as process, process stage, operation, and phase.

    • A recipe model that separates product-specific instructions from equipment-specific control logic.

    • States and modes that define how equipment and batch procedures behave during execution, hold, restart, stop, and exception conditions.

    The most important practical point is that ISA-88 separates what needs to be made from how the equipment performs it. Product intent is captured in recipes, while reusable equipment capabilities are implemented in control strategies and modular automation. That separation is why S88 is often used to improve consistency, recipe portability, and lifecycle maintainability.

    How ISA-88 defines batch process control

    Under ISA-88, batch process control is not just a sequence of machine commands. It is a structured combination of:

    • Recipe management, including formulas, parameters, inputs, outputs, and required process steps

    • Equipment management, including which units and modules can perform which actions

    • Procedural execution, including ordered phases, branching, holds, and restarts where the process design allows them

    • Batch records and data capture, which are essential for traceability, review, and investigation in regulated operations

    In that framework, a batch is executed by applying a recipe to suitable equipment using a defined procedural structure. For example, a recipe may specify material quantities, setpoints, timing, and process parameters, while the unit phases handle actions such as charge, mix, heat, hold, or transfer. The standard helps make those phases reusable across products where the equipment capability is genuinely common.

    ISA-88 also distinguishes different recipe types, such as general, site, master, and control recipes. That matters because recipe detail and approval context often differ across development, site deployment, and runtime execution. In regulated environments, those distinctions can support traceability and controlled change, but only if the implementation is disciplined and integrated into the site’s validation and governance practices.

    What ISA-88 does and does not do

    ISA-88 does not mandate one vendor architecture, one control platform, or one software product. It is a model and terminology standard. A plant can align well with S88 using different combinations of DCS, PLC, SCADA, batch engines, MES, historian, and ERP systems.

    It also does not guarantee interoperability, easier validation, or successful recipe transfer by itself. Those outcomes depend on how consistently the models are applied, how cleanly interfaces are designed, and how much variation exists in equipment, instrumentation, and site procedures.

    Common failure modes include:

    • using S88 terms loosely without enforcing a real equipment and recipe model

    • embedding product-specific logic deep in PLC or DCS code, which defeats recipe portability

    • assuming two lines are interchangeable when instrumentation, sequencing, or material handling details differ

    • treating batch records as an afterthought instead of designing for review, exception handling, and genealogy from the start

    How it fits in brownfield plants

    In brownfield environments, ISA-88 is often most useful as a structuring approach rather than a full replacement program. Many plants already have a mix of legacy automation, vendor batch packages, MES workflows, ERP integrations, local historian setups, and manual or semi-digital records. In those conditions, trying to replace everything to become “fully S88 compliant” often fails for predictable reasons: qualification burden, validation cost, downtime risk, integration complexity, and the reality of long-lived production assets.

    A more practical approach is usually incremental:

    • standardize recipe and equipment models for new products or new cells first

    • wrap legacy control with clearer procedural and data interfaces where replacement is not justified

    • align MES, historian, and batch record structures to the S88 model over time

    • apply change control carefully so recipe, automation, and record changes remain traceable

    That coexistence model is slower, but it is often more realistic in regulated manufacturing where downtime windows are constrained and validation effort is material.

    Why operations and quality teams care

    When implemented well, ISA-88 can help organizations reduce ambiguity in batch execution, improve repeatability, and make recipe changes more controlled. It can also make cross-functional communication clearer between process engineering, automation, MES, quality, and IT.

    But the tradeoff is governance overhead. Modular recipe design, reusable phases, exception handling, and record integration require sustained discipline. If master data is inconsistent, equipment capabilities are poorly defined, or recipe ownership is fragmented across departments, the standard will not fix those problems on its own.

    So the short answer is: ISA-88 is the standard that defines a structured model for batch process control by separating recipes, equipment, and procedures into reusable, governable elements. Its practical value is real, but it depends heavily on implementation quality, data discipline, and how well it is adapted to existing plant systems.

  • What is the difference between SL-T and SL-C in IEC 62443?

    In IEC 62443, SL-T and SL-C represent different but related concepts in how you plan and implement cybersecurity for industrial control systems.

    Core difference

    • SL-T (Target Security Level): The security level you need for a specific zone or conduit based on risk assessment and overall system requirements.
    • SL-C (Capability Security Level): The security level a specific component or product is technically able to support, as demonstrated by design, testing, and (where applicable) certification.

    In practice: SL-T is defined top-down from risk and system context; SL-C is defined bottom-up from what equipment, software, and systems can actually do.

    Where they come from in the IEC 62443 series

    • SL-T is set during system and risk engineering activities (e.g., IEC 62443-3-2 and -3-3) when you define zones, conduits, and required protections.
    • SL-C is established in the product and component context (e.g., IEC 62443-4-1 and -4-2), focusing on individual devices, applications, or systems and what they can demonstrably support.

    How SL-T is determined

    SL-T is driven by:

    • Risk assessment for safety, quality, production continuity, IP protection, and regulatory exposure.
    • Zone and conduit definition: which assets are grouped and how they communicate.
    • Threat environment: expected adversary capability, motivation, and potential impact.
    • Organizational policies and industry norms (for example, typical expectations for safety-critical or GxP-related systems).

    SL-T is not a property of a device. It is a requirement placed on a zone or conduit that may consist of many devices, networks, and applications.

    How SL-C is determined

    SL-C is typically established by:

    • Vendor design and documentation for a controller, PLC, gateway, MES, DCS, or network component.
    • Testing and evaluation against IEC 62443-4-2 (for components) or related parts of the standard.
    • Sometimes third-party evaluations or certificates that show capability up to a particular security level for specific requirement families.

    SL-C is a technical capability. It does not guarantee that a deployed system actually achieves that level in your plant. That depends on configuration, integration, and operational discipline.

    How SL-T and SL-C interact in real projects

    In a realistic industrial deployment, you will see these patterns:

    • SL-C >= SL-T: Components can meet or exceed the required target. You may still need correct configuration, hardening, and procedures to actually reach SL-T.
    • SL-C < SL-T: The component is not capable of meeting the target on its own. This is common in legacy or vendor-locked systems.

    When SL-C is lower than SL-T, you usually have to:

    • Add compensating controls (for example, firewalls, one-way gateways, network segmentation, enhanced monitoring).
    • Adjust zone boundaries so that lower capability components are isolated and protected by higher capability infrastructure.
    • Apply procedural and administrative controls where technical controls are not feasible.
    • Document residual risk acceptance when you cannot practically close the gap, especially in highly regulated environments.

    Brownfield and regulated environment realities

    In brownfield plants with long-lived assets, it is normal for existing controllers, HMIs, or legacy MES to have SL-C values that lag the SL-T you would choose on a clean sheet. Full replacement to close the gap is often not viable due to:

    • Validation and qualification burden for safety, quality, and regulatory approval.
    • Downtime constraints and production risk when replacing core control or execution systems.
    • Integration complexity with MES, ERP, historians, QMS, and vendor-specific tools.
    • Traceability and change control requirements that slow major platform changes.

    As a result, many programs focus on:

    • Using SL-T to prioritize zones and conduits where higher security is most critical.
    • Mapping current assets to their SL-C and identifying gaps by requirement family (e.g., identification & authentication, use control, data integrity).
    • Designing architectural and procedural compensating controls rather than trying to immediately replace non-compliant components.
    • Maintaining traceable documentation of SL-T, SL-C, compensating controls, and residual risks for internal governance and external audits, without implying that this guarantees compliance outcomes.

    How to use SL-T and SL-C in your program

    For a typical industrial or manufacturing organization, a practical workflow is:

    1. Define zones and conduits and perform risk assessment to establish SL-T for each.
    2. Inventory components and determine SL-C per component or per group of similar components, using available vendor information and internal testing where needed.
    3. Compare SL-T vs SL-C for each zone/conduit and requirement family to identify gaps.
    4. Plan mitigations: architecture changes, network controls, system hardening, and procedures to help the overall zone reach its SL-T, even if individual components have limited SL-C.
    5. Implement under change control and document assumptions, dependencies, and known limitations as part of your cybersecurity management and quality systems.

    IEC 62443 is structured so that SL-T drives what you need, and SL-C describes what you have. Effective programs manage the gap deliberately instead of assuming they will match by default.

  • Can we support both real-time and historical KPI views from the same calculation layer?

    Yes, in many cases you can support both real-time and historical KPI views from the same calculation layer, but not by treating them as identical workloads.

    The practical answer is that you need one governed KPI logic layer, with different execution patterns for live and historical use. Real-time views usually need low-latency calculations over incomplete, still-changing data. Historical views usually need stable, reconciled calculations over closed periods, corrected events, and approved master data. If you force both into a single processing pattern, accuracy or responsiveness usually suffers.

    What has to be true

    • The KPI definition has to be version-controlled and unambiguous.

    • You need clear handling for late-arriving events, duplicated events, missing tags, unit conversions, and timestamp quality.

    • You need rules for when a number is considered provisional versus finalized.

    • You need traceability back to source events, transactions, or production records.

    • You need a process for recalculation when routing, product structure, reason codes, or other master data changes.

    Without those controls, a shared calculation layer often produces one of the most common failure modes in manufacturing analytics: the live dashboard says one thing, month-end reporting says another, and no one trusts either.

    Why this is harder than it sounds

    Real-time KPI calculation and historical KPI calculation solve different problems.

    • Real-time views prioritize speed, operational usefulness, and tolerance for data that is not yet complete.

    • Historical views prioritize consistency, auditability, period closure, and reproducibility.

    That means the same KPI formula may be shared, while the surrounding logic is not. For example, a real-time OEE-style calculation may use current machine states and in-process counts, while the historical version may need reconciled production declarations, approved scrap dispositions, downtime reason normalization, and shift-close corrections.

    So the right pattern is usually a shared semantic layer or rules layer, not necessarily one identical runtime path or one physical data store.

    Common architecture pattern

    In practice, mature implementations often use:

    • One governed KPI definition layer

    • One streaming or near-real-time processing path for operational visibility

    • One batch or incremental reconciliation path for historical reporting

    • One traceable data model that preserves source lineage and calculation version

    That still counts as the same calculation layer if the business logic is centrally governed and consistently applied. It does not require one database, one refresh cadence, or one tool.

    Brownfield reality

    In brownfield environments, the answer depends heavily on integration quality. MES, SCADA, historians, ERP, QMS, manual production logs, and maintenance systems often disagree on timestamps, event granularity, asset hierarchies, and reason codes. A single KPI layer can sit above them, but only if you invest in mapping, normalization, and data quality controls.

    If those systems are poorly aligned, trying to replace them all just to get one KPI model is usually a high-risk strategy. Full replacement often fails in regulated, long-lifecycle environments because qualification effort, validation cost, downtime risk, interface rewiring, and traceability obligations are much larger than expected. A coexistence approach is usually more realistic: keep source systems in place, standardize KPI logic centrally, and phase improvements over time.

    Key tradeoffs

    • Speed versus stability: faster numbers are usually less final.

    • Uniformity versus source fidelity: heavy normalization improves comparability but can hide source-specific nuance.

    • Recalculation flexibility versus auditability: if historical KPIs can be recomputed freely, you need strict versioning and change control.

    • Centralization versus local plant reality: a global KPI model helps standardization, but local equipment models and workflows still matter.

    What to validate before committing

    • Whether the KPI can be computed from event data alone or requires contextual business data from ERP, MES, QMS, or maintenance systems

    • Whether source timestamps are trustworthy enough for real-time and historical alignment

    • Whether backfilled and corrected records trigger controlled recalculation

    • Whether users can see the calculation version, data freshness, and source lineage

    • Whether closed-period reporting is protected from uncontrolled logic changes

    So yes, you can support both from the same calculation layer, but only if that layer is governed as a controlled KPI logic service, not just a dashboard formula library. In regulated operations, the difference matters because trust depends less on visualization and more on traceability, reconciliation rules, and change discipline.

  • Where should KPI formulas live: ERP, MES, data warehouse, or another platform?

    Usually, not in just one place.

    In most regulated manufacturing environments, KPI formulas should be split by purpose rather than forced into ERP, MES, or a data warehouse by default. A practical pattern is:

    • System of record keeps the source facts, such as orders in ERP, execution events in MES, and quality events in QMS.
    • Operational calculations live close to the process when people need them during execution, for example shift performance, queue aging, downtime response, or first-pass yield at a work center.
    • Enterprise KPI definitions are governed centrally in a semantic layer, analytics platform, or well-controlled data model so finance, operations, and quality are not all reporting different versions of the same metric.

    So the short answer is: put KPI formulas where they can be executed reliably and governed consistently, which is often a combination of MES plus a governed analytics layer, not ERP alone.

    How to decide where a formula belongs

    A KPI formula usually belongs in the platform that best matches these constraints:

    • Decision timing: If the metric drives action during the shift, calculation often belongs in MES, SCADA, historian, or an operations intelligence layer close to the line.
    • Data ownership: If the required facts are authored in ERP, such as standard cost, booked labor, or customer delivery promise, ERP may own part of the calculation or at least the source inputs.
    • Cross-system logic: If the KPI combines ERP, MES, QMS, maintenance, and manual data, a data warehouse or semantic layer is usually the safer place for the official enterprise version.
    • Traceability and change control: If the formula affects regulated reporting, management review, or quality decision-making, you need version control, approval, test evidence, and clear lineage from source data to reported result.
    • Latency tolerance: If next-day reporting is acceptable, a warehouse or lakehouse is often enough. If operators need the value in seconds or minutes, batch analytics is too late.

    What each platform is good at

    ERP is usually best for commercial and planning-oriented metrics tied to orders, inventory valuation, purchasing, financials, and promised dates. It is usually a poor place for high-frequency shop floor calculations because ERP data is often delayed, aggregated, or not granular enough.

    MES is usually best for execution KPIs that depend on real production events, routing status, labor booking, machine states, genealogy, or in-process quality checks. MES can support immediate action, but it often becomes a problem if every site builds local KPI logic differently and no one governs definitions across plants.

    Data warehouse, lakehouse, or semantic layer is usually best for enterprise reporting, cross-functional reconciliation, and a governed “official” KPI definition. This works well for board reporting, plant comparisons, and trend analysis. The tradeoff is that it depends heavily on integration quality, timestamp alignment, master data consistency, and stable mappings across ERP, MES, QMS, and other systems.

    Another platform, such as a historian, industrial analytics tool, or event-processing layer, may be the right place for machine-derived KPIs, condition-based metrics, or near-real-time operational alerts. But these tools still need alignment with enterprise definitions if the same KPI appears in management reports.

    What usually goes wrong

    • Different systems calculate the same KPI differently, often because of different filters, calendars, routing assumptions, or treatment of rework and scrap.
    • ERP becomes the reporting source for metrics it does not actually observe at the needed level of detail.
    • MES dashboards become site-specific and cannot be compared across plants without manual interpretation.
    • The warehouse becomes the “truth” layer before source data is stable, so teams spend more time reconciling data than improving performance.
    • Formula changes are made informally, without approval, regression testing, or documentation of effective dates.

    In regulated and long-lifecycle environments, these failures matter because once a KPI is used for quality escalation, release decisions, supplier management, or executive review, undocumented formula drift creates avoidable audit and trust problems even if no regulation explicitly prescribes that KPI.

    A practical operating model

    For most brownfield environments, a layered approach is more realistic than choosing a single system:

    1. Define KPI semantics once with clear numerator, denominator, exclusions, time basis, data sources, and effective dates.
    2. Keep source events in the originating systems and avoid copying business logic into every downstream tool if you can avoid it.
    3. Allow local operational calculations close to execution where latency matters.
    4. Publish one governed enterprise definition in the analytics layer for cross-site and cross-functional reporting.
    5. Put formula changes under change control with documented rationale, validation, and backward-compatibility decisions.

    This is not as simple as centralizing everything in one stack, but full replacement strategies often fail in brownfield aerospace and similarly regulated environments. The qualification burden, downtime risk, integration complexity, validation effort, and long asset lifecycles usually make wholesale KPI standardization inside a single replacement platform slower and riskier than teams expect.

    Bottom line

    If you need one rule: ERP should rarely be the only home for KPI formulas, MES should not be the uncontrolled home for enterprise definitions, and the data warehouse should not invent metrics without disciplined source-system lineage.

    The most robust answer is usually:

    • MES or operations systems for real-time, action-driving KPIs
    • ERP for financial and planning context
    • A governed analytics or semantic layer for the official cross-functional KPI definition

    That approach is less elegant than a single-system answer, but in mixed-vendor plants it is usually more maintainable and more credible.

  • How is an ISMS different from general IT security in a factory?

    An Information Security Management System (ISMS) is a formal management framework for information security. General IT security in a factory is usually a collection of technical and procedural controls. The ISMS defines how those controls are selected, governed, audited, and improved over time.

    Scope: information vs. just IT assets

    General IT security in a plant typically focuses on:

    • Protecting networks, servers, endpoints, and user accounts
    • Perimeter defenses, VPNs, and remote access rules
    • Malware protection, patching, and backups

    An ISMS has a broader scope: it is about information risks across the business, which may include:

    • Production recipes, NC programs, and process parameters
    • Inspection plans, quality records, and batch genealogy data
    • Supplier data, customer drawings, and export-controlled technical data
    • Both IT and OT environments (MES, SCADA, PLCs, historians) where that information is created or used

    In a factory, this means the ISMS should explicitly address risks at the boundary of ERP, MES, QMS, PLM, and shop-floor control systems, not just the corporate IT network.

    Governance and risk management vs. isolated controls

    General IT security often grows organically: a firewall here, an MFA project there, antivirus everywhere. Controls may be sound, but not consistently linked to a documented risk picture.

    An ISMS typically introduces:

    • Formal risk assessment for information assets, including OT data flows
    • Defined scope (sites, systems, processes) and documented risk acceptance
    • Policies and standards that apply across plants and functions
    • Roles and responsibilities (e.g., asset owners, risk owners, ISMS steering group)
    • Planned controls mapped to risks and to requirements (for example ISO 27001, IEC 62443, customer contracts)

    In practice, this means that firewall rules, access models in MES, and backup strategies for historians are not just “good ideas” but are traceably linked to risks, policies, and approvals.

    Lifecycle and change control vs. one-off projects

    General IT security is often project-based: deploy a new NAC solution, upgrade antivirus, implement a SOC. In regulated manufacturing environments, these projects may not be tightly integrated with validation, configuration control, or long equipment lifecycles.

    An ISMS emphasizes:

    • Change control for security-relevant changes in IT and OT (for example new remote access path to a PLC vendor)
    • Configuration management for security baselines across multiple plants
    • Incident management and lessons learned, feeding back into risk and controls
    • Continual improvement using internal audits, metrics, and management review

    In a brownfield factory with decades-old lines, the ISMS should explicitly account for systems that cannot be patched frequently, complex vendor dependencies, and validation constraints. It will not remove these constraints, but it forces them into a managed decision process rather than ad hoc exceptions.

    Integration with OT and long-lifecycle assets

    General IT security often stops at the IT/OT boundary: security teams may treat OT as a separate domain owned by engineering, especially where proprietary fieldbuses, legacy Windows versions, and vendor-managed appliances exist.

    An effective ISMS in a factory environment needs to:

    • Recognize OT systems as information assets with explicit risk owners
    • Integrate with safety, quality, and validation processes without overriding them
    • Respect long qualification and downtime constraints, especially in aerospace, pharma, and similar sectors
    • Describe how cyber controls (network segmentation, hardening, monitoring) will coexist with vendor requirements and existing MES/SCADA/PLC stacks

    This usually rules out simplistic “rip-and-replace” strategies. Replacing a validated MES or SCADA purely for security reasons can create more risk than it removes due to requalification, integration work, and potential new failure modes.

    Documentation, evidence, and auditability

    General IT security may be strong technically but weak on documentation. In regulated factories, that is often not acceptable.

    An ISMS normally requires:

    • Documented policies, procedures, and control descriptions
    • Asset and risk registers with traceability to implemented controls
    • Records of approvals, exceptions, and periodic reviews
    • Internal audit plans and documented outcomes

    This documentation does not guarantee external audit outcomes, but it provides structured evidence that decisions were made deliberately and follow a defined process. This is important where quality, regulatory, or customer audits increasingly extend into cybersecurity posture.

    What an ISMS does not do

    It is important to be explicit about limits. An ISMS:

    • Does not guarantee security or compliance; it structures how you manage risk
    • Does not automatically make legacy OT systems secure; it makes their risk explicit and managed
    • Will not succeed without alignment across IT, OT, quality, engineering, and plant management
    • Can become a paperwork exercise if controls are not enforced in real systems and processes

    Effectiveness will depend heavily on the quality of integration with existing MES/ERP/QMS, the maturity of change control, and how realistically plant constraints are handled.

    How they coexist in a real factory

    In practice, you do not replace IT security with an ISMS. Instead, the ISMS provides the governance layer around existing and future controls. Typical coexistence in a brownfield plant looks like:

    • Keeping current firewalls, antivirus, SOC, and OT segmentation as-is
    • Documenting them as controls in the ISMS, linked to assets and risks
    • Adding missing process elements: risk assessments, formal access reviews, vendor remote access rules, incident handling playbooks
    • Aligning security changes with existing validation, quality, and change control processes rather than bypassing them

    This approach fits better with long equipment lifecycles and minimizes disruption while still raising the overall level of control and auditability.

  • When should we reference ISO 27002 in our procedures?

    ISO 27002 is a catalog of information security controls and guidance, not a regulation. In a regulated industrial environment, you reference it in procedures when it clarifies how you manage information security risks, but you still need site-specific definitions, ownership, and validation.

    Situations where referencing ISO 27002 makes sense

    It is usually appropriate to reference ISO 27002 when your procedure is:

    • Defining the information security management framework
      For example, an “Information Security Policy” or “Information Security Management” procedure that sets the overall structure of controls, roles, and governance. Here you can state that your control set is aligned with ISO 27002 and then map specific controls into your internal standards.
    • Describing specific security controls
      Procedures or standards for topics such as:
      • Access control to MES, DCS, historians, QMS, ERP, or PLM
      • Account and credential management for OT and IT systems
      • Logging, monitoring, and incident detection
      • Backup, restore, and disaster recovery of production and quality systems
      • Change and configuration management of servers, applications, and network devices
      • Supplier and third-party access to plant systems and technical data

      In these cases, referencing the relevant ISO 27002 control(s) can help justify the control design and align with common practice.

    • Documenting risk assessment and treatment
      Procedures that define how you perform and document information security risk assessments and select treatments. ISO 27002 can be referenced as the catalog for potential controls you consider during risk treatment, but you still need your own risk criteria and acceptance rules.
    • Defining information security requirements for projects and changes
      Change control, system implementation, or project lifecycle procedures that require security reviews for new MES, QMS, SCADA, or data integration projects. Here you can require that designers consider applicable ISO 27002 controls and document which ones are implemented, not implemented, or compensated.
    • Setting requirements for suppliers and service providers
      Procedures for vendor qualification, managed services, or cloud usage may reference ISO 27002 as a baseline for security expectations (for example, logging, access control, incident response). This must be translated into concrete contractual and technical requirements, not left as a vague citation.

    How to reference ISO 27002 without creating problems

    In regulated manufacturing environments, vague or absolute references to ISO standards often create audit and validation issues. Be specific and bounded:

    • Reference specific clauses or controls
      Instead of we comply with ISO 27002, use wording like this procedure implements controls aligned with ISO 27002:2022, sections 5.15 and 8.2, adapted to site risk and system constraints.
    • Make your internal control descriptions primary
      Describe what you actually do in clear, testable terms. Use ISO 27002 as a source of practice, not as the main body of the procedure. Auditors and regulators will test what you wrote and implemented, not the standard.
    • Include version and scope
      If you reference ISO 27002, state the edition (for example, ISO/IEC 27002:2022) and where it applies (for example, Information assets classified as Confidential and above in IT and OT networks). This limits re-interpretation when the standard is updated.
    • Document your tailoring
      Many ISO 27002 controls are not practical for all OT, legacy, or safety-critical systems. Procedures should allow for risk-based tailoring and require documented justification when a control is not applied or is applied via a compensating measure.
    • Avoid implying certification or guarantees
      Do not state or imply that referencing ISO 27002 makes you compliant or certified. Use language like aligned, based on, or informed by, and make clear that actual implementation is defined in local work instructions, configurations, and validated controls.

    Interactions with existing OT, MES, ERP, and QMS environments

    In brownfield plants, you rarely implement ISO 27002 controls uniformly across all systems. Your procedures should:

    • Recognize legacy constraints
      Many production and test systems cannot support modern security controls without requalification or downtime. For example, you may not be able to enforce strong authentication on an older MES without a disruptive upgrade.
    • Separate baseline from exceptions
      Use ISO 27002 to define a baseline control set for new or modernized systems. Document controlled exceptions for legacy or validated systems where changes could impact product quality, regulatory filings, or validated states.
    • Integrate with change control and validation
      Any change derived from an ISO 27002 recommendation (for example, hardening an OS, segmenting a network, tightening access) must go through your established change control, risk assessment, and validation processes, especially where GMP, airworthiness, or safety-critical functions are impacted.
    • Clarify roles and system boundaries
      Procedures should specify where responsibility lies among IT, OT, quality, and operations for implementing and monitoring each control category. ISO 27002 itself does not define organizational boundaries; you must.

    Where you should be cautious about referencing ISO 27002

    There are cases where referencing ISO 27002 is unhelpful or risky:

    • Core manufacturing, test, or quality procedures
      Work instructions for machining, assembly, test, batch release, or deviation handling should not rely on ISO 27002 for technical content. At most, you may reference your information security procedure that is itself aligned to ISO 27002.
    • Validation documentation as a substitute for requirements
      Do not use compliance with ISO 27002 as a stand-in for specific system requirements in user requirement specifications or validation protocols. Requirements must be explicit and testable in your context.
    • Audit response documents
      A strong response explains your risk assessment, decisions, and controls. Overstating ISO 27002 alignment without evidence can increase audit exposure rather than reduce it.

    Practical wording examples

    Examples of bounded references that typically work better in regulated environments:

    • This procedure defines the information security control framework for OT and IT systems supporting manufacturing and quality. Control categories are aligned with ISO/IEC 27002:2022 and tailored based on documented risk assessment and system constraints.
    • For new or significantly modified systems, security requirements shall be defined with reference to applicable control categories in ISO/IEC 27002:2022. Selected controls and any deviations shall be documented in the project risk assessment and change records.
    • Supplier information security controls shall, at minimum, cover access control, incident management, and backup/restore processes consistent with the intent of ISO/IEC 27002:2022 for the contracted services. Specific requirements are defined in the supplier security schedule.

    Key tradeoffs to recognize

    When deciding how heavily to reference ISO 27002, balance:

    • Clarity vs. flexibility
      Detailed mapping to ISO 27002 can improve clarity for security teams but may reduce flexibility for plants with different legacy systems and risk profiles.
    • Standard alignment vs. lifecycle reality
      Full alignment with ISO 27002 across all systems is rarely realistic in aerospace-grade or GMP environments because of qualification burden, downtime risk, and integration complexity. A risk-based, incremental approach is more sustainable.
    • External expectations vs. internal capability
      Referencing ISO 27002 may signal maturity, but if your actual processes, logging, and enforcement are immature or fragmented across sites, over-claiming can create regulatory or customer trust problems.

    In summary, reference ISO 27002 in procedures that govern how you design, select, and justify information security controls across IT and OT, but keep the standard as a guiding framework, not a substitute for concrete, validated, and site-specific requirements.