Connect981 – Content Dev

FAQ Category: cross-plant standardization

  • How does digital maturity in FAI relate to broader smart factory initiatives?

    Digital maturity in First Article Inspection (FAI) is closely linked to broader smart factory initiatives because it exercises many of the same capabilities on a smaller, high-consequence slice of the process. In aerospace and other regulated environments, FAI is often where digital thread, data integrity, and traceability requirements show up first and most acutely.

    Why FAI is a bellwether for smart factory maturity

    Digitally mature FAI typically requires:

    In practice, this connects to digital AS9102 FAI when teams need to turn the answer into repeatable execution habits.

    • Reliable access to current design data (CAD, drawings, specifications) from PLM or document control.
    • Structured, traceable characteristic data (ballooning, numbering, feature definitions) instead of free text.
    • Integrated routings, work instructions, and measurement plans connected to MES or travelers.
    • Electronic records, approvals, and audit trails that align with AS9102 and internal QMS expectations.
    • Stable revision control and change management across engineering, operations, and quality.

    These are also foundational elements of any serious smart factory program. If an organization cannot keep engineering data, process definitions, and inspection records synchronized for a single high-visibility job, it will struggle to scale more advanced automation, analytics, or closed-loop control.

    How FAI digitization supports smart factory capabilities

    When done carefully, raising digital maturity in FAI directly enables core smart factory capabilities:

    • Digital thread and genealogy: FAI forces you to tie design requirements to as-built and as-inspected data at the part/serial level. This is essentially a small-scale digital thread implementation.
    • Model-based workflows: Using digital ballooning and characteristic extraction from 3D models or drawings is a first step toward model-based definition and downstream automation.
    • Data quality and standardization: Structured characteristic libraries, consistent units, and controlled measurement methods improve data quality for later analytics (capability, yield, variation analysis).
    • Evidence for automation and AI: Clean, labeled FAI datasets become training and validation inputs for future statistical tolerancing, risk-based sampling, or AI-assisted inspection planning.
    • Cross-functional governance: Coordinating engineering, quality, and operations around FAI workflows tests the organization’s ability to manage cross-system change, which is essential for any smart factory roadmap.

    Dependencies and common constraints

    The value of digital FAI as a smart factory lever depends heavily on existing system and process maturity:

    • PLM and document control: If design and spec data are not under disciplined revision control, digital FAI will inherit that instability. Any smart factory initiative built on this data will also be brittle.
    • MES/ERP/QMS integration: In brownfield environments, FAI tools must coexist with legacy systems. Weak or manual integrations can create parallel data sets and extra reconciliation work instead of real maturity.
    • Measurement systems maturity: Without robust gage management and MSA, more digital FAI just creates inaccurate data faster, limiting the usefulness of analytics or automation built on it.
    • Validation and change control: In regulated plants, any new digital FAI workflow must be validated and brought under formal change control. Aggressive iteration without this discipline can create compliance risk.

    These constraints apply even more strongly when moving beyond FAI to plant-wide smart factory platforms. FAI is often the first place these weaknesses become visible.

    FAI as a practical pilot for smart factory building blocks

    Because FAI is scoped and episodic, it can be a controlled pilot area for capabilities that will later be used more broadly:

    • Digital work instructions and travelers: Building FAI-specific digital instructions and tying them to travelers can act as a low-risk proving ground before rolling similar patterns across all work orders.
    • Electronic approvals and e-signatures: Implementing e-signature and role-based approvals in FAI is a manageable way to test governance models before extending them across NCR, CAPA, or batch release.
    • Standard data models: Defining standard fields for characteristics, tools, and methods in FAI can become the template for broader standardization in inspection and process control.
    • Operator and inspector adoption: FAI teams are usually experienced and close to the customer. Their feedback on digital workflows is valuable before deploying similar tools over hundreds of operators.

    However, this only contributes to smart factory maturity if FAI is intentionally tied into a broader architecture. A standalone FAI application with its own numbering, routing, and file store can be efficient locally but does little for enterprise-level digitization.

    Coexistence with existing systems in brownfield plants

    In most aerospace and defense plants, MES, ERP, PLM, and QMS are already in place, often with weak interoperability. Digital FAI must coexist with these systems rather than replace them:

    • MES/ERP: FAI status should reference actual work orders and part/master data from MES or ERP, not maintain a separate shadow list. Simple integrations (IDs, revisions, disposition status) are usually more realistic than full bidirectional sync initially.
    • PLM and document management: Ballooning and characteristic extraction should use approved engineering releases. Where direct PLM integration is not feasible, disciplined export and reference processes are required to avoid mismatch.
    • QMS: Nonconformances found during FAI still need to feed the existing NCR and CAPA workflows. Trying to run a separate FAI-only quality loop usually creates confusion and audit risk.

    Attempts to use a digital FAI project as a fast path to replace MES or QMS entirely often fail in regulated environments. The validation burden, downtime for cutover, and integration complexity across hundreds of existing interfaces typically exceed the organization’s appetite for risk. Using FAI to harden integrations and governance is more sustainable than treating it as a gateway to wholesale system replacement.

    Tradeoffs and realistic expectations

    It is important to set realistic expectations for what digital FAI can and cannot do for smart factory goals:

    • Depth vs. breadth: FAI may be highly digitized while routine production inspection and in-process control remain manual. This yields excellent evidence for first builds but limited impact on ongoing yield and flow until patterns are replicated.
    • Compliance vs. optimization: Early FAI digitization efforts often focus on compliance (correct forms, signatures, attachments) rather than true process optimization. That is still useful, but it should not be confused with end-to-end smart factory capability.
    • Local efficiency vs. global interoperability: A feature-rich FAI solution tailored to one site or customer may actually increase complexity at the enterprise level if it diverges from common data models and integrations.
    • Automation risk: Automating FAI planning or sampling without solid data governance and clear engineering ownership can amplify configuration and interpretation errors, potentially affecting product acceptance.

    In other words, digital FAI is a strong but narrow lens on maturity. It can demonstrate that foundational capabilities exist, but it does not guarantee that they are consistently applied across the factory.

    Using FAI maturity to guide the smart factory roadmap

    FAI performance can serve as a diagnostic for smart factory readiness:

    • If ballooning, characteristic management, and digital records work well for complex FAIs, the organization is likely ready to scale similar patterns to serial production.
    • If FAI still relies on email, Excel, and shared drives, broader smart factory claims are probably overstated, especially regarding digital thread and traceability.
    • If cross-system changes (drawing revisions, routing updates, inspection plan adjustments) propagate cleanly into FAI, the underlying change control is strong enough to support further automation.

    Conversely, persistent FAI pain points often point directly to architectural gaps that will block smart factory progress, such as missing PLM integration, inconsistent part and revision identifiers, or weak QMS linkages.

    In summary, digital maturity in FAI is not the entirety of a smart factory, but it is a practical, high-signal area. Treating FAI as a structured pilot for data models, integrations, and governance can de-risk broader initiatives while staying within realistic constraints on downtime, validation, and change control.

  • What is ISA-95?

    Overview

    ISA-95 (also known as ANSI/ISA-95 and IEC 62264) is an international standard that describes how information should flow between enterprise systems and manufacturing systems. It defines a common set of models, terminology, and integration patterns for connecting business planning and logistics with plant operations. In practice, it is used as a reference framework rather than a detailed implementation blueprint, and its value depends heavily on how consistently it is interpreted and applied across systems and sites.

    Core purpose

    The primary purpose of ISA-95 is to reduce ambiguity and integration risk when connecting different classes of systems. This includes enterprise systems at Level 4 such as ERP, SCM, finance, and order management, manufacturing operations systems at Level 3 such as MES/MOM, LIMS, WMS, and quality systems, and control and field systems at Levels 0–2 such as DCS, PLCs, SCADA, historians, and instrumentation. By describing the information that should move between these levels, ISA-95 helps organizations reduce ad hoc interfaces and clarify what data should originate where.

    In practice, this connects to data mapping and system interoperability when teams need to turn the answer into repeatable execution habits.

    Key elements of ISA-95

    A well-known part of ISA-95 is the functional hierarchy, which defines Levels 0–4 and clarifies responsibilities from physical process control up through business planning and logistics. The standard also defines information models for production orders, schedules, materials, equipment, personnel, and process segments, which can be used to structure master data and integration payloads. In addition, it provides activity models for production, quality, maintenance, and inventory operations, and describes the types and directions of information exchanges between enterprise and manufacturing systems.

    Why ISA-95 matters in regulated, brownfield environments

    In regulated manufacturing, ISA-95 is often used to establish a shared language between IT, OT, engineering, quality, and vendors when discussing system responsibilities and data flows. It can help reduce custom, point-to-point integrations that become fragile under change control and validation pressure, especially when multiple vendors are involved. Plants use ISA-95 concepts to clarify boundaries between ERP and MES/MOM, avoid functional overlap or gaps, and support more consistent data structures needed for traceability and regulated reporting.

    Limitations and risks to consider

    ISA-95 is not a complete implementation guide and does not prescribe specific architectures, technologies, or products, so design decisions still require local engineering judgment. Vendors and integrators frequently claim ISA-95 alignment but interpret models differently, leading to mismatches unless data definitions, responsibilities, and message structures are specified in detail. The standard focuses on integration and information models, not on detailed control strategies, functional safety, or cybersecurity, which must be addressed using additional standards, internal procedures, and validation approaches.

    Impact on existing systems and change management

    Aligning existing ERP, MES, SCADA, and custom applications to ISA-95 in a brownfield plant can require significant changes to data structures, interfaces, and even organizational responsibilities. Because most regulated facilities already operate with validated systems and established integrations, adopting ISA-95 is usually an incremental refactoring of models and interfaces, not a wholesale replacement of current platforms. Any ISA-95-driven changes must pass through formal change control, regression testing, and, where applicable, revalidation, which can limit how far and how fast organizations can standardize.

    How ISA-95 is typically used

    Organizations commonly use ISA-95 to define system roles and boundaries (for example, what resides in ERP versus MES versus LIMS), especially when planning upgrades or integrating new equipment or plants. It is also used to specify integration requirements in RFPs and project documents, giving a structured way to describe production orders, material flows, and equipment capabilities. Many teams adopt ISA-95 information and activity models as a reference when designing master data, production models, and standard-based interfaces for MOM/MES implementations, while still tailoring details to local regulatory, product, and integration constraints.

  • 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?”

  • What is the relationship between configuration control and engineering change management?

    Configuration control and engineering change management are tightly coupled disciplines, but they address different parts of the same problem: how to define, change, and prove what you built over time.

    Core relationship

    Configuration control focuses on what the current approved configuration is for a product, assembly, or system at any point in time. It governs:

    In practice, this connects to data integrity, version control and audit when teams need to turn the answer into repeatable execution habits.

    • Defined baselines (design, production, as-built, as-maintained)
    • Approved part numbers, revisions, and BOMs
    • Approved process plans, routings, and work instructions
    • Traceability between requirements, design, and realized product

    Engineering change management (ECM or ECN/ECR processes) governs how configurations are allowed to change. It covers:

    • Initiating and documenting a change request or change notice
    • Impact analysis (technical, quality, cost, schedule, regulatory)
    • Formal approval, rejection, or deferral of the change
    • Planning and executing implementation (effectivity, cut-in, rework or use-as-is)
    • Updating affected artifacts (drawings, specs, routings, programs, inspection plans)

    Put simply: configuration control defines and preserves the baseline; engineering change management is the governed path for modifying that baseline.

    How they work together in practice

    In a regulated industrial environment, configuration control and ECM should operate as a closed loop:

    1. Configuration is baselined: A product or process configuration (design and associated manufacturing data) is released and baselined in PLM/ERP/MES.
    2. A change is proposed: A nonconformance, field issue, cost-down idea, obsolescence, supplier change, or regulatory update triggers an engineering change request.
    3. Change is evaluated: Engineering, quality, operations, supply chain, and sometimes customers or authorities review the impact against the existing controlled configuration.
    4. Decision and effectivity: If approved, the change is assigned effectivity (serial numbers, date, lot, or configuration-specific criteria) and implementation responsibilities.
    5. Configuration records are updated: BOMs, routings, NC programs, work instructions, inspection plans, and reference data are revised and re-baselined. Old and new configurations must both remain traceable.
    6. Execution and verification: Shop floor systems, suppliers, and MRO partners execute to the new configuration; as-built and as-maintained records demonstrate that the correct configuration was actually produced or serviced.

    If configuration control is the “source of truth” for what is approved, ECM is the “only legal door” through which that truth is allowed to change.

    Where responsibilities typically sit

    Roles often split as follows, although exact ownership varies by company and program:

    • Configuration management teams define the configuration item structure, control baselines, and ensure traceable records across life cycle phases.
    • Engineering creates and assesses proposed changes and owns technical validation.
    • Quality assesses compliance and risk impact, and ensures EC workflows align with QMS and regulatory commitments.
    • Operations and supply chain validate implementability, capacity, tooling, supplier readiness, and logistics effectivity.
    • IT / systems owners maintain the PLM/ERP/MES/QMS integrations that keep configuration records and EC workflows synchronized.

    The relationship is most effective when configuration management and ECM governance are aligned under a common policy, even if execution is distributed.

    Dependencies and failure modes in real plants

    The relationship between configuration control and ECM is only as strong as the systems and data flows connecting them. In brownfield, mixed-vendor environments, typical issues include:

    • PLM "approved" but MES still old: Engineering approves an EC, but routings, digital work instructions, or NC programs in MES or machine controllers are not updated or validated in sync. The configuration record and the shop floor reality diverge.
    • ERP effectivity vs. physical reality: ERP may show effectivity at a date or lot, but actual WIP, rework, and repair activities create mixed configurations that are not cleanly represented by system cut-in rules.
    • Manual workarounds: Paper redlines, tribal knowledge, and email approvals bypass the formal EC workflow. Configuration records in PLM/QMS look clean, but the as-built condition is uncertain.
    • Incomplete impact analysis: Changes are assessed only at drawing/BOM level, and not against test procedures, inspection plans, special processes, tooling, MRO documentation, or regulatory approvals.
    • Lack of as-maintained linkage: For long-life assets, line and depot maintenance may implement changes through service bulletins or field orders that are not tightly linked back to the design configuration and original EC records.

    In regulated environments, these failure modes do not just create scrap or delays; they undermine evidence of conformity, traceability, and airworthiness or safety justifications.

    Why you cannot treat them as separate concerns

    Some organizations treat configuration control as mainly documentation control and treat engineering change as a project management function. That separation rarely holds up for complex, regulated products. Common consequences are:

    • Un-clearable audit findings: You can show an EC log or a configuration baseline, but not a seamless story linking requirement, design, EC, implementation, and as-built/as-maintained configurations.
    • Version mismatches across systems: Drawing revs, ERP BOM revs, MES routing versions, and QMS-controlled work instructions drift out of alignment with each other.
    • High rework and MRB load: Lack of clear effectivity and configuration visibility increases mis-builds, concessions, and use-as-is decisions.

    Practically, configuration control should define what objects and relationships are under control and how they are baselined, while engineering change management should be the governed mechanism by which those controlled objects are created, revised, superseded, or retired.

    System coexistence and long-lifecycle constraints

    In aerospace and other long-lifecycle, regulated sectors, fully replacing PLM, ERP, MES, or QMS to “fix” configuration control and EC is rarely feasible. Reasons include:

    • Qualification and validation burden for any system that touches configuration or EC records.
    • Downtime risk for production and MRO if core systems are taken offline or replaced abruptly.
    • Integration complexity across OEMs, Tier suppliers, MROs, and authorities with different tools and data models.
    • Long asset lifecycles where historical configurations and legacy systems must remain accessible for decades.

    Most plants instead incrementally strengthen the relationship between configuration control and ECM by:

    • Clarifying which system is authoritative for which type of configuration data (PLM vs. ERP vs. MES vs. QMS).
    • Implementing controlled, traceable integrations and handoffs between these systems.
    • Reducing manual redlines and uncontrolled changes in favor of digital, workflow-driven EC processes.
    • Linking as-built and as-maintained records to specific configuration baselines and EC identifiers.

    Key takeaways

    • Configuration control defines and protects the product and process baselines.
    • Engineering change management is the formal, traceable process for changing those baselines.
    • They are interdependent: effective configuration control is impossible without disciplined change management, and EC has no value if it does not reliably update controlled configurations across systems.
    • In regulated, long-lifecycle environments, the relationship must be implemented across PLM, ERP, MES, and QMS with strong traceability, validation, and change control, rather than relying on a single “magic” replacement system.

  • Do I need new software to adopt ISO 22400 KPI definitions?

    You usually do not need new software to adopt ISO 22400 KPI definitions. In most regulated manufacturing environments, the critical work is in data modeling, integration, and governance, not in replacing tools.

    What ISO 22400 requires in practice

    Adopting ISO 22400 is primarily about standardizing how you define and calculate KPIs such as OEE, availability, performance, and quality rate. That means you need to:

    In practice, this connects to ISO 22400 KPI governance when teams need to turn the answer into repeatable execution habits.

    • Map existing metrics and naming conventions to ISO 22400 terms and structures.
    • Standardize KPI formulas and calculation rules across lines, plants, and systems.
    • Ensure your source data (events, counts, time states) is complete, time-synchronized, and traceable.
    • Document and control the calculation logic under your change control and validation processes.

    All of this can usually be done on top of existing MES, historians, SCADA, data warehouses, and BI tools.

    When you probably do not need new software

    You can typically implement ISO 22400 with your current stack if:

    • Your MES or historian can record core production events (start/stop, order, equipment state, counts, scrap).
    • You have some form of analytics or reporting layer (BI, data warehouse, MES reports) that lets you define calculations.
    • You can configure or script KPI logic without breaking validated functions or vendor support terms.
    • You can place KPI definitions and changes under formal configuration management and, where required, validation.

    In these cases, adopting ISO 22400 is mostly an internal project: aligning definitions, updating reports, retraining users, and adjusting interfaces and documentation.

    When you might need new or upgraded components

    New software or modules may be justified if one or more of the following are true:

    • Data is missing or incomplete: Your current systems cannot capture the necessary time states, counts, or contextual data at the required granularity.
    • Rigid or opaque KPI logic: KPI formulas are hard-coded in a vendor module that you cannot reconfigure without a major upgrade or revalidation effort.
    • Poor interoperability: You cannot reliably integrate data from multiple plants, lines, or systems into a common KPI model.
    • Weak governance and traceability: Existing tools do not adequately support versioning of KPI logic, audit trails, or documentation that your quality and validation teams require.

    Even then, wholesale system replacement is usually high risk in regulated, long-lifecycle environments. It often triggers extensive revalidation, complicated cutover plans, and integration work that can stall or fail. In many cases, a lighter approach is more realistic:

    • Add a data integration or analytics layer that can implement ISO 22400 definitions on top of existing systems.
    • Extend current MES or historian via configurable modules, not full replacement.
    • Use pilot areas to prove the model and integration before any broader rollout.

    Key dependencies and constraints

    Whether you need new software depends on your specific environment:

    • System configuration: Some MES products support flexible KPI modeling; others require vendor involvement for changes.
    • Process maturity: Plants with disciplined data governance and clear equipment state models can adopt ISO 22400 faster with existing tools.
    • Integration quality: If each line or plant has a different way of logging events or downtime, harmonizing to ISO 22400 may require integration and normalization work.
    • Regulatory expectations: In highly regulated environments, even report logic changes may require formal impact assessment, documentation, and possibly validation.

    Pragmatic adoption path without major new software

    A common path in brownfield environments looks like this:

    1. Baseline: Catalog existing KPIs, data sources, and calculation logic for a few representative lines.
    2. Map to ISO 22400: Align current metrics to ISO 22400 definitions and identify gaps in data or logic.
    3. Prototype: Implement ISO 22400-compliant KPIs in your existing reporting or analytics layer for a pilot area.
    4. Validate and document: Put KPI formulas, data mappings, and test evidence under configuration and change control.
    5. Scale selectively: Roll out to additional lines/plants, addressing data collection or tooling gaps case by case.

    This approach respects existing validated systems and minimizes downtime, while still moving you toward standardized performance metrics.

    If you are in a heavily regulated, long-lifecycle environment

    Be cautious about full replacement strategies justified only by ISO 22400 adoption. Replacing a MES or historian solely to standardize KPIs typically:

    • Introduces substantial qualification and validation burden.
    • Creates downtime and cutover risks for production.
    • Requires re-implementing integrations to ERP, QMS, PLM, and other systems.
    • Can disrupt established traceability, audit trails, and change histories.

    In most cases, it is more realistic to treat ISO 22400 as a data and governance initiative layered onto current systems, only adding or upgrading components where clear gaps exist.

  • What role do non-conformance records play in incident or AOG investigations?

    Non-conformance records (NCRs) are a core evidence stream in incident and AOG investigations, but they are not a complete picture on their own. Their usefulness depends on data quality, traceability, and integration with maintenance, operations, and engineering systems.

    How NCRs are used in incident and AOG investigations

    Investigators and internal teams typically use NCRs to:

    In practice, this connects to non-conformance management when teams need to turn the answer into repeatable execution habits.

    • Map the as-built / as-maintained condition: Link specific serialized parts, assemblies, and repairs to any known deviations, concessions, or rework that may be relevant to the event.
    • Identify prior signals and weak warnings: See whether similar non-conformances, escapes, or recurring failure modes were already known but not fully contained or mitigated.
    • Reconstruct decision history: Review MRB decisions, concessions, repairs, and risk justifications that allowed a non-conforming condition to be accepted and released to service.
    • Support structured root cause analysis: Feed factual data (who, what, when, where, detection method) into 8D, RCCA, 5-Whys or other formal investigation methods.
    • Assess fleet or population risk: Use NCR trends and genealogy to locate other aircraft, engines, or components potentially exposed to the same defect or process drift.
    • Validate containment actions: Show whether interim fixes, inspections, or service bulletins were applied to affected units and whether escapes continued afterward.

    Specific contributions during an AOG or major incident

    In an AOG or significant safety/airworthiness event, NCRs help to:

    • Accelerate initial triage: Rapidly answer questions like “Has this configuration or part number had prior non-conformances?” or “Did this tail/engine/serial number have past repairs in the affected area?”
    • Narrow the investigation scope: Focus on specific suppliers, cells, programs, or time windows that show clustered non-conformance patterns tied to the suspect failure.
    • Support go/no-go and RTS decisions: Provide documented risk assessments and MRB dispositions that inform whether the aircraft can safely return to service after inspection or repair.
    • Inform emergency inspection campaigns: Use NCR and genealogy data to build lists of suspect serial numbers and define what must be inspected, where, and with what criteria.

    Dependencies and limits of NCR usefulness

    The practical value of NCR records in investigations is highly dependent on:

    • Data completeness and discipline: If operators routinely “work around” issues without opening NCRs, or if coding is inconsistent, the record set will under-represent true risk and failure precursors.
    • Traceability to parts and maintenance: NCRs must be reliably linked to work orders, serial numbers, configuration records, and maintenance logs. In brownfield environments, gaps between MES, MRO, and ERP/QMS data often slow or limit this linkage.
    • Change control and versioning: Investigations rely on knowing which revision of drawings, work instructions, and repairs applied when the non-conformances occurred. Weak document control reduces evidentiary value.
    • MRB and CAPA quality: If MRB justifications are thin, or CAPAs are superficial, NCRs will show that “something was done” without clarifying whether underlying causes were truly addressed.
    • System integration and searchability: When NCR data is buried in local spreadsheets, unstructured PDFs, or multiple disconnected QMS/MES/MRO tools, investigators may not be able to retrieve or correlate it quickly enough during an AOG event.

    Because of these constraints, NCRs support, but do not determine, regulatory or legal outcomes. They provide traceable evidence of decisions taken, not guarantees that those decisions were correct.

    Role in root cause, systemic risk, and fleet-wide actions

    Beyond the immediate incident, robust NCR data shapes longer-term risk reduction:

    • Feeding systemic root cause analysis: Cross-plant and cross-program NCR analytics can reveal design, process, or supplier issues that only become obvious when viewed as a pattern.
    • Prioritizing engineering and process changes: High-frequency or high-severity NCR types help justify design updates, new inspections, tooling changes, or automation investments.
    • Supporting reliability and safety cases: NCR trends inform hazard analyses and risk registers, highlighting where controls are weak or detection is occurring too late in the lifecycle.
    • Informing supplier and MRO oversight: The NCR record is often central to supplier scorecards, targeted audits, and corrective action demands after an incident.

    Coexistence with legacy and mixed systems

    In many aerospace and MRO environments, NCRs are scattered across:

    • Legacy QMS modules in ERP
    • Standalone NCR tools or shared drives
    • Paper-based forms scanned into archives
    • MES / MRO systems with limited synchronization

    Full replacement of these systems just to improve incident-readiness for NCRs is rarely feasible, due to qualification effort, validation cost, and downtime risk. More realistic strategies include:

    • Incremental digitization: Digitize NCR capture at the point of use while maintaining validated back-end systems, then synchronize data through controlled interfaces.
    • Linking, not duplicating, records: Use identifiers and integrations to connect NCRs to work orders, travelers, maintenance events, and configuration records instead of re-keying data.
    • Improved coding and standardization: Harmonize defect codes, cause codes, and dispositions across plants and systems to enable cross-site analysis during investigations.
    • Audit trails and evidence management: Ensure that integrations and data transformations are traceable and validated so NCR records retain evidentiary weight.

    Tradeoffs and operational implications

    Relying on NCRs as a critical input to incident and AOG investigations involves balancing:

    • Raising more NCRs vs. operational friction: Encouraging thorough reporting improves investigation readiness but can slow flow if workflows are not streamlined for operators.
    • Detail vs. usability: Highly detailed NCR forms capture better evidence but can reduce completion quality and consistency if they are too burdensome.
    • Local flexibility vs. global comparability: Site-specific codes and practices may fit local reality but limit fleet-level or program-level pattern detection after a major event.
    • Speed vs. rigor in MRB/CAPA: Fast AOG recovery pressures can drive quick dispositions; without disciplined follow-on RCA and CAPA, the organization may carry latent risk into the fleet.

    In practice, organizations that get the most value from NCRs in incidents and AOG situations treat them as a structured, integrated evidence backbone across design, production, and MRO, supported by strong traceability, validation, and change control.

  • Do I need lawyers involved when interpreting PT controls?

    In most regulated industrial environments, you do not need a lawyer for every question about PT (export) controls, but you do need a structured way to decide when legal review is required.

    When you typically do not need a lawyer

    You can usually rely on internal procedures and prior legal guidance when:

    In practice, this connects to export controls and technical data handling when teams need to turn the answer into repeatable execution habits.

    • The situation matches a documented internal precedent (e.g., previously reviewed product classification or country list).
    • You are following an approved, version-controlled procedure that was already cleared by counsel.
    • You are configuring systems or workflows strictly within clearly documented rules (e.g., blocking certain destinations, users, or data types based on an approved matrix).
    • You are not changing the underlying interpretation of regulations, only implementing controls already defined by policy.

    In these cases, the risk is usually around execution quality, validation, and evidence, not legal interpretation. The focus should be on traceability, change control, and ensuring the digital implementation matches the approved policy.

    When you should involve legal counsel

    Legal or specialized trade-compliance counsel should be involved when any of the following apply:

    • New or ambiguous interpretation: The regulation, control list entry, or license condition is unclear, and there is no internal precedent.
    • Cross-border data and cloud decisions: You are deciding what technical data can be stored, processed, or accessed in specific regions or by specific roles (especially for export-controlled or defense-related work).
    • System-wide design choices: You are defining role-based access, data segregation, or integration rules that will be embedded in MES/PLM/ERP/QMS for years.
    • New product lines or technologies: Classification or control status is not yet established, or technologies span multiple regimes or agencies.
    • High enforcement risk: Sensitive programs, embargoed destinations, complex multi-party collaborations, or prior enforcement history.
    • Disagreement among stakeholders: Engineering, operations, and IT do not align on how to map regulations into system behavior or process steps.

    In these scenarios, your long-lived decisions on PT controls will drive how systems are configured, audited, and defended if challenged. Having documented legal interpretation is part of risk management.

    Practical approach in brownfield environments

    In typical brownfield plants with mixed legacy and modern systems, a practical approach is:

    1. Centralize interpretations: Maintain a controlled repository (often owned by Trade Compliance or Legal) of approved interpretations, classifications, and data-handling rules.
    2. Translate into rules: Operations, IT, and engineering convert these interpretations into concrete system rules (role matrices, data labels, export flags, routing rules) with clear traceability back to the source decision.
    3. Use change control: Treat any change to PT control logic like a significant process or configuration change: documented rationale, impact assessment, testing, and approvals.
    4. Escalate exceptions: If a scenario does not match the existing repository, pause implementation and escalate to Trade Compliance or Legal rather than improvising a new interpretation.

    Full replacement of legacy systems purely to “solve” PT controls is rarely justified. Qualification burden, validation cost, and downtime risk often exceed any compliance benefit. It is usually more realistic to:

    • Layer PT controls on top of existing PLM/MES/ERP/QMS via classification fields, access rules, and middleware.
    • Strengthen evidence generation and reporting across the mixed stack.
    • Limit legal review to the rules that drive these configurations, not every technical change.

    How to formalize who decides what

    To avoid ad hoc legal involvement, many organizations define a simple RACI (or similar) model for PT controls:

    • Legal / Trade Compliance: Own regulatory interpretations, product and data classifications, and country/program-level rules.
    • Quality / Compliance: Own procedures, training, audit readiness, and ensuring changes follow controlled processes.
    • IT / OT / Systems Owners: Own technical implementation in MES/PLM/ERP/QMS and integrations, and ensure configuration matches approved rules.
    • Operations / Engineering: Own how PT controls affect workflows, routings, and work instructions.

    With this structure, lawyers are involved when interpretations or classifications change, not for every daily decision or configuration ticket.

    Key takeaway

    You do not need lawyers involved in every step of interpreting and applying PT controls, but you do need:

    • Clear criteria for when legal review is mandatory.
    • Documented, version-controlled interpretations that others can implement.
    • Traceability from legal decisions to system rules and plant procedures.
    • Change control so that PT-related logic in long-lived systems is updated consistently and defensibly.

    This balance keeps legal involvement focused on high-impact interpretation and classification decisions, while enabling operations, engineering, and IT to execute within an agreed, controlled framework.

  • How can NIST 800-53 support software supply chain security?

    NIST SP 800-53 supports software supply chain security by giving you a structured set of controls to govern how software is acquired, developed, integrated, operated, and retired across your supplier and integrator ecosystem. It does not remove supply chain risk on its own, but it can anchor policies, contracts, and technical controls in a way that is auditable and repeatable.

    What NIST 800-53 actually provides

    NIST 800-53 is a catalog of security and privacy controls. It is not specific to manufacturing or to software supply chains, but multiple control families map directly to software and vendor risk, for example:

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

    • SA – System and Services Acquisition: Requirements for secure software development, supplier due diligence, tamper resistance, and independent testing.
    • SR – Supply Chain Risk Management: Controls for supplier vetting, trusted channels, counterfeit detection, and contractual requirements.
    • CM – Configuration Management: Version control, baseline management, approved software lists, and change tracking.
    • SI – System and Information Integrity: Vulnerability management, malware defenses, code integrity, and monitoring.
    • RA – Risk Assessment: Formal analysis of software and supplier risk, including OT and MES platforms.
    • AU, IR, MP, PE, PL: Logging, incident response, media protection, physical access, and overarching security planning that all affect how software is handled through its lifecycle.

    These controls can be tailored to your environment and then used to design and assess your software supply chain practices.

    Ways it supports software supply chain security in industrial environments

    In a regulated, brownfield manufacturing setting, NIST 800-53 is most useful as a reference framework to tighten specific activities rather than as a one-time implementation project.

    1. Setting clear requirements for software and vendors

    Controls in the SA and SR families can be translated into concrete requirements for any software that touches your manufacturing stack, including MES, historians, engineering tools, firmware, and vendor-supplied utilities. For example:

    • Requiring suppliers to follow secure development practices and provide vulnerability disclosure processes (SA-15, SA-12).
    • Specifying expectations for SBOMs or equivalent component transparency, to the extent your vendors can support it (aligned with SA and SR controls).
    • Building contract clauses around tamper-resistant packaging, chain-of-custody for media, and secure update channels for devices and control systems.

    The effectiveness of this step depends heavily on your commercial leverage, existing contracts, and how much legacy software you must keep in place for qualification or validation reasons.

    2. Governance for acquiring and approving software

    NIST 800-53 supports a structured approval process for software entering your environment:

    • Using SA and CM controls to define who can request, evaluate, and approve new software, including tools used on the shop floor or for programming PLCs and CNCs.
    • Requiring documented risk assessments (RA) before introducing new third-party components into validated processes or GxP-relevant systems.
    • Maintaining an inventory of authorized software, linked to specific assets and lines, and tied to change control.

    In brownfield plants, this usually coexists with legacy “shadow IT” and local tools. 800-53 helps you justify a risk-based cleanup and prioritization rather than an unrealistic full replacement.

    3. Strengthening change control and configuration management

    Software supply chain issues often show up as unapproved updates, untracked patches, or unverified third-party components. Controls in the CM family help you:

    • Maintain baselines for critical OT assets, MES nodes, and engineering workstations, with explicit lists of approved software and versions.
    • Require documented change requests, impact analysis, and rollback plans when introducing new versions or vendor patches, especially for validated systems.
    • Link configuration items to test and validation evidence, which is important when regulators or customers expect traceability from requirement to deployment.

    In long-lifecycle equipment, you often cannot update to current software versions quickly. 800-53 supports a defensible, risk-based approach where you document known deviations, compensating controls, and monitoring rather than forcing immediate replacement.

    4. Monitoring, detection, and response around third-party software

    Controls in the SI, AU, and IR families can be tuned to detect and respond to supply chain issues:

    • Logging and monitoring activity on systems that run vendor software, including MES, SCADA, data collection, and quality systems.
    • Implementing processes for handling alerts about compromised libraries or vendor backdoors, and mapping these alerts to the systems and lines they affect.
    • Defining incident response playbooks that include coordination with software suppliers and integrators, and clear rules for emergency changes on validated systems.

    In mixed-vendor environments, your technical visibility will vary. NIST 800-53 gives you a structure for documenting monitoring gaps and justifying compensating controls where full telemetry is not available.

    5. Integrating software supply chain risk into broader SCRM

    NIST 800-53’s SR controls help you treat software suppliers as part of overall supply chain risk management, instead of handling them as isolated IT issues. This can include:

    • Risk-tiering vendors that provide MES, PLC programming tools, analytics platforms, and cloud services used in production.
    • Embedding cybersecurity and lifecycle support requirements into supplier qualification, scorecards, and periodic reviews.
    • Coordinating with procurement and quality to ensure that software supplier risks are evaluated alongside material and process risks.

    Here, integration with existing QMS, ERP, and supplier management processes is usually the hard part. 800-53 provides the control language but not the integration glue, which you must tailor to how your organization actually runs supplier management.

    6. Supporting auditability and evidence generation

    Although NIST 800-53 does not guarantee compliance or certification, it gives you a common language to:

    • Show auditors and customers how your controls for software selection, updates, and vendor management are designed.
    • Trace specific software-related risks (for example, open-source components in MES extensions) to documented controls and testing.
    • Organize evidence such as test reports, supplier contracts, change records, and vulnerability scan logs under a consistent control framework.

    In regulated environments, this mapping improves consistency across sites and vendors, even where technical implementations differ because of equipment age or qualification constraints.

    Important limitations and tradeoffs

    There are several practical limits to what NIST 800-53 can do for software supply chain security in manufacturing:

    • It is a control catalog, not a product or tool. You must interpret and implement the controls in your specific environment, which requires security, operations, and quality teams to work together.
    • Brownfield constraints are real. Legacy MES, PLCs, and engineering tools may not support modern controls such as code signing, robust logging, or secure update mechanisms. Replacing them may be infeasible due to validation burden, downtime risk, and integration complexity.
    • Vendor cooperation varies. Some suppliers will provide SBOMs, vulnerability notifications, and update guidance; others will not. 800-53 helps you document expectations and gaps, but it cannot force vendor behavior.
    • No compliance guarantee. Aligning with NIST 800-53 does not guarantee specific certifications or positive audit outcomes. Regulators and customers typically look at how your control design and evidence align with your stated policies and applicable standards.
    • Integration with existing systems is non-trivial. Mapping 800-53 controls into existing MES, QMS, ERP, and PLM workflows usually requires incremental change, not full replacement, to avoid disruption to validated processes.

    How to use NIST 800-53 effectively for software supply chain security

    To make practical use of NIST 800-53 in this area:

    1. Define scope. Identify which systems and suppliers are in scope: MES, OT assets, engineering tools, integration partners, cloud services, and key software vendors.
    2. Select relevant controls. Focus on SA, SR, CM, SI, RA, AU, and IR controls that directly relate to software acquisition, development, distribution, and operation.
    3. Map to existing processes. Tie chosen controls to current change management, supplier qualification, validation, and incident response processes instead of creating parallel structures.
    4. Prioritize high-impact gaps. Given limited downtime and validation capacity, start with controls that reduce the most risk on critical lines and systems, such as better control over patching and supplier communication.
    5. Iterate and document. Expect partial alignment and exceptions, especially with legacy systems. Document these explicitly, including compensating controls and plans for future remediation.

    Used this way, NIST 800-53 becomes a practical backbone for software supply chain governance instead of an abstract checklist, and it can coexist with existing standards you may already reference, such as IEC 62443 for OT security.

  • How to determine ISO 27001 scope?

    Determining ISO 27001 scope is about drawing a defensible, risk-based boundary around the information security management system (ISMS). In industrial and regulated environments, the scope must reflect real data flows across IT, OT, and external parties, not just an abstract list of systems.

    1. Start from business objectives, not systems

    Begin with why you want ISO 27001:

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

    • Which products, programs, or services are driving the need (e.g., aerospace customer contracts, regulated data handling, IP protection)?
    • Which regulatory or contractual requirements are in play (e.g., export controls, data protection laws, customer security requirements)?
    • Which sites, business units, and partners are actually involved in delivering those products or services?

    Your scope must at least cover the processes, locations, and information assets necessary to meet those objectives. If they are left out, the scope will appear artificial and can be challenged by auditors or customers.

    2. Map information and data flows

    In brownfield industrial environments, the real scope boundary is where information flows, not where organization charts end. Map:

    • Key information types: design data, process parameters, batch records, maintenance logs, quality records, supplier data, and customer technical data.
    • Systems handling this information: ERP, MES, QMS, PLM, historian, SCADA/DCS, LIMS, file shares, collaboration tools, cloud services.
    • Interfaces and integrations: data replication between MES and historian, engineering-to-operations handoff from PLM, links to supplier portals, remote access for OEMs.
    • People and roles: operators, engineers, maintenance, quality, IT/OT admins, external contractors, and managed service providers.

    This mapping will show where in practice your ISMS controls must apply to protect in-scope information. If information crosses a boundary, that boundary is likely in scope or must be tightly controlled and justified as out of scope.

    3. Define scope by business process, location, and asset

    An ISO 27001 scope statement typically describes:

    • Processes: e.g., “Design, manufacturing, testing, and aftermarket support for Product Line X” or “Operation of Plant Y, including production, maintenance, and quality management”.
    • Locations: specific plants, offices, data centers, and cloud regions. In industrial settings, clearly state whether shop floor OT environments are in scope.
    • Assets and systems: high-level categories such as “IT and OT systems supporting in-scope processes, including MES, historian, SCADA, ERP, PLM, QMS, and supporting network infrastructure”.

    You do not need to list every device by name in the scope statement, but you must be able to show, in supporting documentation, what is covered and how it is kept current.

    4. Decide how to treat OT environments

    For manufacturing and regulated operations, the main scoping challenge is OT:

    • Full inclusion: All OT systems related to in-scope processes are within the ISMS. This is more complete, but increases complexity and the effort needed to align controls with legacy equipment and safety constraints.
    • Partial inclusion: Only certain OT zones (e.g., the lines making Product X) are in scope, with clear network segregation and documented justification.
    • Out-of-scope OT with strong interfaces: OT is out of scope, but interfaces to in-scope IT are strongly controlled and documented. This is often challenged if OT holds or processes in-scope information (e.g., recipes, quality data).

    In practice, if OT systems store or control in-scope information (or if their compromise would materially affect confidentiality, integrity, or availability of that information), they should be considered at least partially in scope, even if controls are tailored to technical and safety realities.

    5. Handle multi-site and multi-system brownfield realities

    Few organizations can feasibly place every site and system into scope at once, especially with legacy stacks and tight downtime constraints. Typical approaches include:

    • Phased scoping: Start with a small but meaningful subset of sites, products, or customers, then expand. Ensure the initial scope is not so narrow that it appears like compliance theater.
    • Functional scoping: Include all locations for certain functions (e.g., design and central IT), but only specific manufacturing sites. Be explicit about which sites are excluded and why.
    • System-centric justification: When leaving legacy systems out of scope, you must show how they are segregated, monitored, or otherwise controlled so that they do not undermine the ISMS.

    Full replacement of legacy MES/ERP/OT stacks solely to simplify ISO 27001 scope is rarely practical due to qualification burden, validation cost, downtime risk, and integration complexity. Scoping must work with the existing environment.

    6. Include relevant third parties and cloud services

    Third parties handling in-scope information are usually within scope for ISO 27001 control coverage, even if they are outside your organizational boundary. Consider:

    • Cloud platforms hosting PLM, QMS, data lakes, or analytics.
    • Managed service providers, including remote OT maintenance and monitoring.
    • Suppliers accessing your portals or receiving controlled technical data.

    The scope statement should clarify that these relationships are covered by the ISMS via supplier management, contracts, and technical controls, even if the suppliers themselves are not part of your certification boundary.

    7. Document inclusions, exclusions, and justifications

    An auditor will pay close attention to how clearly and honestly you describe boundaries. Your scope definition and supporting documentation should include:

    • In-scope items: sites, processes, information types, systems, and roles.
    • Explicit exclusions: sites, business units, or system categories that are out of scope.
    • Justifications: why exclusions do not materially affect the confidentiality, integrity, or availability of in-scope information.
    • Interfaces: how interfaces across the boundary are controlled, monitored, and governed.

    Vague or overly optimistic exclusions are a common source of findings. If in doubt, make the dependency explicit and treat it as part of your risk treatment plan.

    8. Align scope with risk assessment and Statement of Applicability

    Your scope drives which assets are assessed and which controls are considered. To be coherent:

    • Perform a risk assessment only on assets within the defined scope.
    • Ensure the Statement of Applicability (SoA) explains control inclusions and exclusions in the context of the declared scope.
    • Make sure operational realities (e.g., shared networks between in-scope and out-of-scope areas) are visible in the risk register.

    If the SoA or risk assessment implicitly covers things that are “out of scope” on paper, your scoping will appear inconsistent.

    9. Validate with stakeholders and keep under change control

    Before finalizing the scope:

    • Review with operations, engineering, quality, and IT/OT leaders to ensure it matches real-world responsibilities and constraints.
    • Verify that the scope is sustainable given long equipment lifecycles, validation obligations, and expected plant changes.
    • Place the scope document under formal change control. Any major organizational, process, or technology change should trigger a scope review.

    This is especially important where validated systems or regulated production processes are involved, as changes to scope may require updates to validation, procedures, and training.

    10. Signs your ISO 27001 scope is likely too narrow or weak

    You should reconsider the scope if:

    • It excludes critical sites or lines that produce the same products the scope claims to cover.
    • It omits OT even though key recipes, batch records, or process parameters are stored on OT systems.
    • It excludes central IT or networks that clearly process or route in-scope information.
    • It relies on assumptions like “no sensitive data is stored here” without evidence.

    Conversely, a scope that tries to cover the entire global enterprise from day one often fails due to complexity and the need to harmonize controls across very different plants and legacy stacks.

    In summary, determining ISO 27001 scope in an industrial, regulated environment is a structured exercise in matching business objectives, information flows, and practical constraints. The outcome should be a clear, justified boundary that can withstand audit scrutiny and can be maintained over the long life of your equipment, systems, and customer commitments.