Connect981 – Content Dev

RSC Content Type: FAQ

Direct answers to common technical or compliance questions.

  • Can you reuse data from a previous FAIR when performing a delta FAI?

    Yes, you can usually reuse data from a previous FAIR when performing a delta FAI, but only under controlled conditions. A delta FAI is intended to demonstrate conformity for the changed characteristics while maintaining traceability to the original, full FAI. Reuse is permitted where the original evidence is still valid and clearly linked.

    What you can typically reuse

    Subject to your customer, contract, and internal procedures, you can often reuse:

    • Unchanged characteristics where the design requirement (drawing, model, spec rev) has not changed.
    • Unchanged manufacturing process steps (same routing, methods, tooling, NC programs, and work instructions) that are still qualified and under control.
    • Previously approved measurement methods (same gages, CMM programs, fixtures, MSA status) that remain valid and calibrated.
    • Document references such as certificates, material lots, or process approvals, if they are still applicable and traceable to the parts being delivered.

    In practice, this often means you can carry forward much of Forms 1 and 2 from the baseline FAI and reuse some Form 3 entries for characteristics not affected by the change, provided your procedure and customer allow it.

    Where you must generate new data

    New inspection data is usually required for:

    • All characteristics impacted by the change (drawing revision, model change, spec change, NC program change, process change, or new supplier).
    • Any operation or tooling that has changed, even if the drawing requirement did not change, where the process change could reasonably affect the result.
    • Characteristics previously accepted by similarity or sampling if the basis for that acceptance is no longer valid.
    • Characteristics that had past nonconformances or escapes where the risk assessment or RCCA calls for renewed verification.

    Even when some values are numerically identical to previous results, a delta FAI is expected to show that you verified the changed condition under the current configuration.

    AS9102 and customer-specific constraints

    AS9102 (especially Rev C) allows delta FAIs focused on changes, but does not guarantee that reuse of prior data will be accepted in all cases. Common constraints include:

    • Customer flowdowns that require full or partial re-FAI at each drawing revision, regardless of internal risk assessment.
    • Prime- or Tier-1-specific FAI procedures that restrict reuse of historical data or require fresh measurements at defined triggers (e.g., time since last build, supplier change, NC program change).
    • Contractual clauses that override your internal criteria for when a delta vs full FAI is allowed.

    Your ability to reuse data ultimately depends on your approved FAI procedure, the purchase order, and any customer FAI specifications. You should be prepared to justify where and why prior data was reused.

    Traceability and documentation expectations

    When you reuse data in a delta FAI, you should make the reuse explicit:

    • Link to the baseline FAI (FAI number, date, revision, and part configuration) in your forms and QMS records.
    • Clearly distinguish characteristics with new data from those that rely on previous FAI evidence (e.g., note “verified in baseline FAI #1234” where allowed by your form format or digital system).
    • Maintain configuration control to show that the reused data corresponds to the same design revision and process definition as currently authorized, or that your risk assessment confirms continued validity.
    • Ensure calibration and approval status of any reused measurement methods or special processes over the time period involved.

    In a brownfield environment with multiple systems (MES, ERP, PLM, QMS, and tools like Net-Inspect), gaps in integration and version control are a common failure mode. If your systems do not reliably link drawings, NC programs, work instructions, and FAIs, aggressive reuse of data can create traceability and audit issues.

    Operational and risk tradeoffs

    Reusing prior data has clear benefits and risks:

    • Benefits: less inspection time, reduced CMM and gage load, shorter lead time to restart production after a change, and lower cost of quality effort for stable characteristics.
    • Risks: using obsolete requirements, missing hidden process changes, or failing to demonstrate adequate verification to a customer or auditor because the linkage between old data and the current configuration is weak.

    In regulated, long-lifecycle aerospace environments, full replacement of existing FAI records and systems every time you update a design or process is rarely practical due to validation cost, downtime risk, and integration complexity. Delta FAI with selective data reuse is a common compromise, but it only works if your change control, configuration management, and digital traceability are strong.

    Practical guidance

    To use prior FAIR data safely in a delta FAI:

    1. Start with change analysis: identify exactly which characteristics and processes are affected by the change.
    2. Define reuse criteria: align with AS9102, customer requirements, and your internal FAI/PPAP procedures.
    3. Verify data validity: check drawing revision, process routing, NC program rev, gage status, and supplier approvals.
    4. Document your rationale: record why specific characteristics used prior data and why that is acceptable from a risk and compliance standpoint.
    5. Use digital tools carefully: if you rely on Net-Inspect or in-house FAI software, ensure that reused entries are correctly linked and that audit trails reflect what changed versus what carried over.

    If there is any doubt about the validity of previous data, or if customer instructions are unclear, it is safer to generate new inspection results for the affected characteristics and, when necessary, to extend that to additional features.

  • Is ISO 27001 a legal requirement?

    In most jurisdictions, ISO 27001 is not a legal requirement. It is a voluntary international standard for information security management systems (ISMS). However, the kind of controls ISO 27001 describes are often required by law, regulation, or contract, even if the standard itself is not named.

    When ISO 27001 is not legally required

    In regulated industrial and manufacturing environments, laws and regulations typically require you to protect data, systems, and networks, but they usually do not say “you must be ISO 27001 certified.” Examples:

    • Data protection and privacy laws (for example, GDPR-like regimes) require “appropriate technical and organizational measures,” but rarely specify ISO 27001.
    • Sector-specific rules (for example, export controls, critical infrastructure, healthcare device regulations) require strong cybersecurity and access control, but normally do not mandate one named standard.
    • OSHA, FAA, EASA, FDA, and similar regulators generally focus on safety and product quality; they expect robust information security around production and quality records, but not a specific ISO 27001 certificate.

    In these cases, ISO 27001 is one recognized way to structure and evidence your information security program, not a legal obligation.

    Where ISO 27001 becomes a de facto requirement

    Even if the law does not require ISO 27001, it can still be effectively mandatory because of business and contractual drivers:

    • Customer contracts: Aerospace, defense, and high-reliability OEMs often require suppliers to be ISO 27001 certified or “equivalent” as a condition to handle design data, NC programs, or quality records.
    • Corporate policies: A global parent company may mandate ISO 27001 for all plants and R&D centers as part of a group security strategy, even if local law does not.
    • Third-party risk programs: Major customers or partners may treat ISO 27001 as the default assurance mechanism in their vendor risk assessments. Absence of certification can limit business or trigger additional audits.

    In these cases, ISO 27001 is still not a law, but it can be a practical requirement if you want to do certain types of business.

    Relationship to other cybersecurity requirements

    For industrial operations, ISO 27001 typically coexists with other security expectations rather than replacing them:

    • IEC 62443 for industrial control system and OT security. This is often more directly aligned with plant-floor risk than ISO 27001 alone.
    • NIST-based requirements (for example, NIST SP 800-53, NIST CSF, or NIST 800-171 in defense contexts). These can be referenced explicitly in contracts and government rules.
    • Data protection regulations, which may require breach notification, data minimization, and specific safeguards for personal data used in HR, training, or remote support platforms.

    ISO 27001 can provide a unifying management framework across IT, OT, MES, ERP, PLM, and QMS environments, but it does not eliminate the need to satisfy more detailed or sector-specific control sets.

    Brownfield and lifecycle realities

    In brownfield manufacturing environments, fully “ISO 27001-compliant from scratch” programs often run into practical constraints:

    • Legacy systems: Old MES, SCADA, PLCs, and machine controllers may not support modern access controls or logging, so some Annex A controls must be adapted or partially accepted as risk.
    • Qualification and validation: Hardening validated systems or changing access models can trigger revalidation and requalification efforts, which are expensive and slow.
    • Downtime risk: Aggressive security changes to OT networks can affect availability and may conflict with production commitments and safety analyses.

    Because of this, plants often implement ISO 27001 in phases, focusing first on information assets and systems where change is feasible, then progressively extending controls to OT and legacy environments under structured change control.

    How to decide what you actually need

    Instead of starting from “Do we need ISO 27001?”, the more practical questions are:

    • Which laws and regulations apply to our data (export-controlled technical data, personal data, defense information, critical infrastructure)?
    • What do our key customer contracts and framework agreements actually require or strongly prefer?
    • How do we currently demonstrate due care and due diligence in information security across IT and OT?
    • Would an ISO 27001 certification materially reduce audit burden or unlock business we cannot win today?

    From there, you can decide whether:

    • You need full ISO 27001 certification across the organization.
    • You implement an ISO 27001-aligned ISMS for critical scopes (for example, engineering and production systems handling customer IP) without certifying everything.
    • You rely on another framework (for example, NIST, IEC 62443) and only map selectively to ISO 27001.

    In all cases, the obligation comes from the underlying laws and contracts, not from ISO 27001 itself.

    Key takeaway

    ISO 27001 is usually not a legal requirement for industrial and manufacturing organizations, but laws, regulators, and customers do expect ISO 27001-level discipline in how you manage information security risk. Whether you pursue certification, adopt the framework without certifying, or rely on another standard, you still need traceable controls, documented risk management, and change control that fit your brownfield reality.

  • Can Connect 981 support multiple facilities and shared analytics?

    Yes, Connect 981 can support multiple facilities and shared analytics, but that does not automatically mean every site will behave like a single, standardized system from day one.

    In practice, multi-facility support usually depends on how the implementation handles site hierarchy, common data definitions, user permissions, workflow variation, and integration with existing ERP, MES, PLM, QMS, and shop floor systems. If those pieces are inconsistent across plants, shared analytics may be technically possible but operationally misleading.

    What multi-facility support usually means

    A workable multi-site setup often includes:

    • separate facilities, lines, cells, or programs managed within one platform structure

    • site-specific workflows, approvals, or forms where local process differences are real and must be preserved

    • shared reporting across sites for common metrics

    • role-based access controls so users see only the data they are authorized to see

    • traceable configuration and change control when templates or workflows are reused across facilities

    Whether that works cleanly depends on governance. If one plant defines downtime, scrap, rework, nonconformance, or completion differently from another, a shared dashboard can create false comparability.

    Shared analytics are possible, with conditions

    Shared analytics are generally feasible if the underlying data is mapped consistently. The main constraint is not the dashboard layer. It is the quality and consistency of the source data.

    Common dependencies include:

    • standardized master data for parts, work centers, operations, reason codes, and personnel or role structures

    • consistent event timing and transaction discipline across facilities

    • clear rules for local versus enterprise KPIs

    • integration quality with incumbent systems

    • security segmentation, especially where export-controlled, customer-restricted, or program-specific data must not be broadly exposed

    If those conditions are weak, shared analytics can still be delivered, but they usually require qualification of metrics, local data cleansing, and explicit caveats about comparability.

    Brownfield reality

    Most regulated manufacturers do not start with a clean slate. One facility may have a mature MES, another may rely on ERP transactions and spreadsheets, and a third may have custom quality workflows. Connect 981 can coexist with that reality, but the rollout approach matters.

    Full replacement across all facilities is often the wrong first move in regulated, long-lifecycle environments. It can fail because of qualification burden, validation cost, downtime risk, integration complexity, and the need to preserve traceability and change history on long-lived assets and programs.

    A more practical approach is usually phased coexistence:

    • connect to incumbent systems where replacement risk is high

    • standardize a limited set of shared data objects and KPIs first

    • allow controlled local variation where processes genuinely differ

    • expand enterprise reporting only after data definitions are stable

    Key tradeoffs

    • More standardization improves cross-site analytics, but can slow adoption where local processes are materially different.

    • More local flexibility improves fit at each plant, but makes enterprise reporting harder to trust.

    • Centralized templates reduce duplication, but require stronger change control and regression testing.

    • Broader data visibility improves leadership insight, but increases security, segregation, and governance requirements.

    So the short answer is yes, but only with deliberate data governance, integration discipline, and a rollout model that respects existing systems and validation constraints.

  • What are the four main groups in the IEC 62443 standard family?

    The IEC 62443 standard family is organized into four main groups, each addressing a different level of industrial automation and control systems (IACS) cybersecurity:

    1. General (IEC 62443-1-x)
      High-level concepts and vocabulary for the entire 62443 series. This group defines common terms, conceptual models, and general guidance used across all other parts. It provides the foundation needed to interpret the more detailed requirements correctly.

    2. Policies & Procedures (IEC 62443-2-x)
      Requirements and guidance for cybersecurity management at the organizational and site level. This includes security program management, patch and account management, incident response processes, and lifecycle governance. It is primarily aimed at asset owners and service providers responsible for operating and maintaining IACS environments.

    3. System (IEC 62443-3-x)
      Requirements for securing IACS at the system level, including zones and conduits, defense-in-depth concepts, and security levels for complete systems. This group is particularly relevant to system integrators and asset owners who design, integrate, and validate end-to-end architectures in brownfield environments where new and legacy equipment must coexist.

    4. Component (IEC 62443-4-x)
      Technical requirements and processes for individual components, such as PLCs, controllers, engineering workstations, HMIs, and network devices. These parts focus on secure product development lifecycles and detailed security capabilities components should provide. They are primarily targeted at product suppliers and vendors but impact how asset owners specify and qualify equipment.

    How this applies in regulated, brownfield environments

    In most regulated manufacturing environments, different parts of IEC 62443 end up applying simultaneously to different stakeholders and layers:

    • The General group provides shared language for operations, engineering, IT, and quality when defining security requirements and evaluating vendors.
    • The Policies & Procedures group must be reconciled with existing quality systems, change control processes, and validation practices. Adoption is usually incremental and constrained by existing SOPs and regulatory commitments.
    • The System group has to be interpreted within mixed-vendor MES/SCADA/DCS networks that cannot be fully redesigned without major downtime and requalification. Zoning and conduits are often implemented stepwise, around existing architectures.
    • The Component group is limited by what current suppliers actually support and what can be changed without triggering long requalification cycles. Legacy devices that predate 62443 typically remain in service for years, so controls at the system and procedural levels are needed to compensate.

    Because of these constraints, organizations rarely adopt all four groups uniformly. Instead, they typically prioritize specific parts that align with current risk drivers, existing governance maturity, and what is feasible within downtime, validation, and integration limits.

  • How can I estimate the scrap reduction potential of AI before a pilot?

    You can estimate it, but only as a range. Before a pilot, the practical question is not whether AI can reduce scrap in theory. It is how much of your current scrap is actually addressable given your data, process stability, response time, and ability to change operator or process behavior without creating validation and traceability problems.

    A defensible estimate usually starts with a loss decomposition, then applies conservative assumptions to only the scrap mechanisms AI could realistically influence.

    Use a bounded estimation method

    1. Establish the current baseline. Use at least 6 to 12 months of scrap and rework history if volume allows. Segment by product family, part number, line, machine, shift, supplier lot, defect code, operation, and material class. If the defect coding is weak or inconsistent, say so. That uncertainty should widen the estimate range.

    2. Separate controllable from non-controllable scrap. AI is more likely to help with process drift, parameter interactions, early defect prediction, machine condition signals, visual inspection support, or abnormal pattern detection. It is less likely to eliminate scrap driven by engineering changes, incoming material escapes with no usable signal, one-off handling damage, chronic fixture wear that is already obvious, or policy-driven rejection thresholds.

    3. Identify the intervention point. Ask where AI would change an outcome: before processing, during the operation, at inspection, or after nonconformance occurs. Scrap reduction is highest when the system can intervene before value is added. If AI only flags defects at final inspection, the likely result may be better sorting or rework routing, not major scrap reduction.

    4. Measure signal readiness. Check whether the needed inputs actually exist and are time-aligned: machine parameters, SPC data, operator entries, environmental data, images, tooling history, genealogy, maintenance events, and inspection results. Many plants have data, but not in a form suitable for model training or real-time decisions. Missing timestamps, weak master data, and poor defect labels can cut expected gains sharply.

    5. Estimate the addressable scrap pool. For each scrap category, assign an addressability factor. Example: if 40% of scrap comes from a process family where usable signals exist, operators can act in time, and the cause is reasonably repeatable, that 40% is the candidate pool. The rest is not automatically addressable just because it appears in the data.

    6. Apply effectiveness scenarios. Use a low, medium, and high scenario rather than one number. A simple formula is:

      Estimated scrap reduction = total scrap cost x addressable scrap share x expected model effectiveness x intervention adoption rate

      This keeps the estimate grounded in operational reality rather than model performance alone.

    7. Add implementation friction explicitly. Reduce the estimate for false positives, operator overrides, workflow delays, integration gaps, qualification limits, and cases where recommendations cannot be acted on within takt or cycle constraints.

    What ranges are realistic?

    There is no universal number. In some plants, a realistic pre-pilot estimate might be in the low single digits of total scrap reduction because only a narrow set of defects is both predictable and preventable. In other cases, where scrap is concentrated in a stable process with rich data and fast intervention, the estimate may be materially higher.

    If someone is projecting a large plant-wide reduction before proving defect labels, signal quality, and workflow adoption, that estimate is probably not reliable.

    What drives the estimate up or down

    • Process repeatability: Stable, repeatable processes are easier to model than highly variable high-mix low-volume work.

    • Defect concentration: If a few defect modes drive most scrap, the opportunity is easier to target.

    • Data quality: Clean defect codes, genealogy, timestamps, and parameter history matter more than model choice at this stage.

    • Intervention timing: Predicting failure before value-added steps has more impact than detecting it late.

    • Human and system response: Alerts that cannot be trusted or acted on will not reduce scrap much.

    • Integration maturity: If MES, QMS, historians, vision systems, and ERP are loosely connected, analysis may be possible while closed-loop action is not.

    • Validation burden: In regulated environments, even beneficial model outputs may require controlled rollout, documentation, and evidence before they influence product acceptance or process settings.

    A practical pre-pilot sizing example

    Suppose annual scrap cost is $2 million. Analysis shows 35% is tied to recurring process defects on a machining and inspection flow with usable machine, tooling, and measurement data. You judge that AI could meaningfully detect or predict half of that addressable pool, but only 70% of alerts would be actionable in time after considering workflow realities.

    The rough estimate is:

    $2,000,000 x 0.35 x 0.50 x 0.70 = $245,000 annual reduction

    Then stress-test it with a lower case. If data labeling is poor or interventions are slower than expected, the realized number might be much lower. That lower case is often more useful for decision-making than the optimistic case.

    Do not ignore brownfield constraints

    In most regulated plants, AI does not arrive in a clean environment. It has to coexist with legacy MES, ERP, PLM, QMS, historians, spreadsheets, and machine interfaces from multiple vendors. That affects estimate quality and achievable benefit.

    Full replacement strategies often fail here because qualification burden, validation cost, downtime risk, integration complexity, and long equipment lifecycles are real constraints. A pre-pilot estimate should therefore assume coexistence first: limited integrations, selective data extraction, advisory outputs, and tightly scoped workflow changes. If your estimate depends on replacing core systems or rewriting validated processes, it is probably overstated.

    What a credible pre-pilot output should look like

    • A baseline scrap cost by defect family and process step

    • An explicit addressable scrap percentage

    • Low, medium, and high benefit scenarios

    • Named dependencies such as data completeness, operator response, and system integration

    • Expected false positive and false negative impacts

    • A statement of what the model will and will not be allowed to influence initially

    If you cannot produce those items, the honest answer is that you are not ready to estimate scrap reduction with much confidence yet.

  • Who is considered the asset owner in a contract manufacturing arrangement?

    In a contract manufacturing arrangement there is no single, universal “asset owner.” Ownership depends on the type of asset, the commercial structure, and what is explicitly defined in the contracts and quality/technical agreements. In regulated and long-lifecycle environments, you should assume that different parties may own different asset classes and that this must be documented clearly.

    Major asset types and typical ownership

    Common asset categories in contract manufacturing include:

    • Production equipment and facilities: CNC machines, assembly lines, HVAC, building infrastructure.
    • Tooling and fixtures: Dedicated tools, jigs, test fixtures, molds.
    • IT/OT systems: MES, SCADA, historians, QMS, LIMS, local databases, and their configurations.
    • Product definition: Drawings, BOMs, routings, specifications, software/firmware, control plans.
    • Process knowledge & validation: Work instructions, validated parameters, recipes, test methods.
    • Data & records: Batch records, genealogy, deviations, CAPA records, equipment maintenance logs.

    In practice:

    • Physical equipment and facilities are usually owned by the contract manufacturer (CM). The CM is typically the asset owner for maintenance, calibration, qualification, and lifecycle management, except where the sponsor funds and retains title to specific equipment.
    • Customer-funded dedicated equipment or tooling may be owned by the brand owner/sponsor even though it is operated by the CM. Contracts often specify that the sponsor owns the tooling, while the CM is the “custodian” with defined responsibilities for care, use, and change control.
    • IT/OT systems (MES, SCADA, local QMS, etc.) are usually owned and administered by the CM. The sponsor rarely owns these systems in a brownfield plant, but may own specific interfaces, templates, or reports provided to the CM.
    • Product definition and IP (drawings, specifications, software, process requirements) are normally owned by the sponsor/brand owner. The CM is granted limited rights to use this information to manufacture and support the product.
    • Process knowledge, recipes, and work instructions may be jointly developed. Ownership is often split: the sponsor may own product-specific methods, while the CM retains rights to generic process know-how. “Joint ownership” is a legal construct and must be defined in the contract, not assumed.
    • Data and quality records (batch records, device history records, test results) are frequently created and controlled by the CM, but the sponsor typically has rights to full access, copies, and retention for regulatory, traceability, and customer support purposes.

    Contractual definition of asset ownership

    Because these arrangements vary, the contract and associated quality/technical agreements should:

    • List asset categories explicitly: equipment, tooling, IT/OT systems, product definition, data, and records.
    • Assign legal ownership for each category (who holds title), and where relevant, who is the custodian or operator.
    • Define control and decision rights: who can approve process changes, who can decommission equipment, who defines data retention and access requirements.
    • Specify validation and change control responsibilities: who funds and performs qualification/validation when equipment, systems, or processes change, and how this is documented.
    • Clarify data and record rights: who owns the underlying data vs. who is responsible for storage, retrieval, and providing evidence for audits and investigations.
    • Address end-of-life and exit: what happens to sponsor-owned tooling, data copies, and configuration baselines if the relationship ends.

    In regulated industries, these allocations must be consistent with applicable regulations and your own quality system. The sponsor may not be the IT system owner at the CM site, but remains responsible for product quality and regulatory compliance for its products.

    Impact on systems and integration in brownfield environments

    In a typical brownfield contract manufacturing environment:

    • The CM owns and operates its MES/SCADA/ERP/QMS stack, with existing validation, integrations, and workarounds that cannot be easily replaced without major disruption.
    • The sponsor owns the product definition and regulatory responsibilities, but depends on data generated in the CM systems for traceability, genealogy, and compliance evidence.
    • Data interfaces and integration configurations (e.g., between sponsor PLM and CM MES) are often treated as shared assets: the sponsor may own the specification and some middleware, while the CM owns the runtime systems where integrations terminate.

    This means that a full replacement of the CM’s core systems by the sponsor is rarely viable. Qualification burden, downtime risk, and integration complexity usually make it impractical. Instead, the contract should clarify who owns:

    • The interface specifications and mappings.
    • The middleware or integration platform, if used.
    • Test evidence and validation documentation for those interfaces.

    These clarifications reduce ambiguity when systems change, when audits occur, or when the relationship transitions to another CM.

    Practical way to determine the asset owner

    If the current contracts are unclear, a pragmatic approach is:

    1. Inventory asset types: list specific equipment, tooling, software systems, data repositories, and key documents used to produce and release the product.
    2. Check legal title and purchase history: who bought and capitalized what, and how is it recorded in each organization’s asset register.
    3. Review the manufacturing, quality, and technical agreements: look for explicit clauses on ownership, IP, data rights, and records management.
    4. Map operational control vs. legal ownership: it is common for the CM to control assets day to day while the sponsor owns the IP and has audit rights and data access.
    5. Update agreements where ambiguous: if uncertainty exists, formally clarify ownership, control rights, and responsibilities under change control.

    Ultimately, in a contract manufacturing arrangement, the “asset owner” is whoever the contracts and supporting quality/technical agreements designate for each specific asset class. When this is not explicit, it becomes a risk area for compliance, traceability, and operational continuity, and should be corrected.

  • Who should own ISO 27001 in organizations with both IT and OT teams?

    ISO 27001 should be owned at the enterprise risk and governance level, not by a single technical team. In organizations with both IT and OT, the usual pattern is:

    • A single business owner for the ISMS (often CISO, CIO, or central Risk/Compliance) accountable for the management system, scope, risk methodology, and interfaces to regulators and auditors.
    • IT leadership responsible for implementing and operating controls on corporate IT and cloud systems.
    • OT leadership (often an OT/plant digital lead or engineering leader) responsible for implementing and operating controls on plant-floor and industrial control systems.

    This separation recognizes that ISO 27001 is a management system standard, not a pure technology standard. The accountable owner must be able to balance risk, cost, and operational impact across both IT and OT, and must sit high enough to resolve conflicts between them.

    Practical ownership model in IT/OT environments

    In regulated, brownfield manufacturing environments, a workable pattern is:

    • ISMS Owner (Accountable): CISO, CIO, or VP Risk/Compliance.
      • Owns the ISO 27001 scope, policy framework, risk assessment methodology, statement of applicability, internal audit program, and management review.
      • Ensures interfaces with quality systems, safety processes, and change control are defined and followed.
    • IT Owner (Responsible for IT scope): Head of IT / Infrastructure / Enterprise Applications.
      • Implements and maintains controls for enterprise networks, servers, workstations, business apps, identity and access management, and cloud services in scope.
      • Coordinates with OT on shared infrastructure (e.g., identity, backup, logging, DMZs).
    • OT Owner (Responsible for OT scope): OT leader / Automation engineering lead / Plant digitalization lead.
      • Implements and maintains controls on ICS/SCADA, DCS, PLCs, historians, MES, and plant networks, with explicit alignment to safety, quality, and validation constraints.
      • Ensures changes respect process safety, qualification, validation, and downtime limits.
    • Supporting functions: Quality, EHS, Legal, HR, and Procurement.
      • Contribute to risk assessment, supplier requirements, training, incident response, and alignment with existing QMS and safety processes.

    Formally, this is usually documented via a RACI that shows who is accountable for the ISMS overall, and who is responsible for each control area across IT and OT.

    Why not let OT or IT “own” ISO 27001 alone?

    Assigning ISO 27001 ownership solely to IT or OT usually fails for at least one of these reasons:

    • Scope gaps: An IT-only owner may under-scope OT networks, vendor remote access, or plant data flows. An OT-only owner may under-scope corporate identity, remote workstations, or cloud services that touch OT data.
    • Conflicting priorities: OT optimizes for uptime and safety; IT often optimizes for standardization and strong technical controls. Neither side alone can reliably balance the tradeoffs at the IT/OT boundary.
    • Regulated change control: Many OT changes require engineering review, validation, or requalification. An IT-only owner may push control changes that are not feasible within existing change-control workflows or shutdown windows.
    • Supplier and lifecycle realities: OT systems have long lifecycles and limited patchability. An OT-only view may under-leverage corporate capabilities (e.g., central logging, vulnerability management), while an IT-only view may set expectations that current OT assets cannot safely meet.

    A central risk or security function is usually better positioned to arbitrate these tradeoffs and decide where risk is accepted, mitigated, or transferred.

    Key design points for shared ownership

    Regardless of where the ISMS owner sits, you will need to make the following explicit:

    • Scope definition: Exactly which plants, networks, systems, and data are in the ISO 27001 scope, including shared IT/OT components (e.g., plant domain controllers, DMZ firewalls, data diodes, VPNs, cloud historians).
    • Interfaces with other management systems: How ISO 27001 interacts with the QMS, safety management, validation/qualification, and change-control processes. In many regulated plants, ISO 27001 controls cannot override quality or safety requirements.
    • Control ownership by domain: For each relevant Annex A control, who is responsible for implementation on IT systems, on OT systems, and for shared infrastructure.
    • Change and downtime constraints: How OT downtime windows, turnaround schedules, and qualification testing are considered when planning security controls like patching, segmentation, or MFA rollouts.
    • Incident response integration: How cyber incidents in OT are triaged, escalated, and resolved, including coordination with safety, operations, and quality incident processes.

    Brownfield and long-lifecycle considerations

    In brownfield plants with legacy MES, SCADA, and control systems, full “replacement” of existing practices with ISO 27001-style controls is rarely realistic. The ISMS owner should focus on:

    • Mapping, not replacing, controls: Identify where existing QMS, safety, and engineering controls already meet or partially meet ISO 27001 requirements, and document equivalence instead of forcing new parallel processes.
    • Risk-based prioritization: Concentrate on high-risk interfaces (e.g., remote access into OT, cross-plant connectivity, vendor support routes) rather than trying to standardize every legacy asset at once.
    • Change-control alignment: Ensure that any new security controls go through established change-control, validation, and qualification gates for regulated equipment.

    This is another reason why ownership at the enterprise risk/security level is important: they can negotiate realistic timelines and risk acceptances that respect operational and regulatory constraints.

    How to decide in your organization

    When you formalize ISO 27001 ownership:

    1. Place accountability with the function that already owns enterprise risk or information security policy (commonly CISO/CIO or central risk/compliance), not within a single plant or a single IT/OT team.
    2. Form an ISMS steering group with IT, OT, Quality, and operations leadership to agree on scope, priorities, and risk criteria.
    3. Document a RACI that clearly distinguishes ISMS-level accountability from domain-level responsibility for control implementation in IT and OT.
    4. Align with existing management systems (QMS, safety, validation) to avoid duplicate processes and to ensure security changes do not disrupt qualified and validated operations.

    The result is a single accountable ISO 27001 owner, with shared responsibility across IT and OT that reflects how your plants actually run.

  • Which KPIs best reflect supplier collaboration performance in aerospace?

    No single KPI is enough. In aerospace, supplier collaboration performance is best measured with a small balanced set that covers delivery, quality, responsiveness, engineering alignment, and traceability. If you only track on-time delivery, you can hide expediting, partial shipments, paperwork defects, recurring nonconformances, and late engineering responses.

    The most useful KPI groups are:

    • Delivery reliability: on-time delivery to committed date, request date adherence, lead-time stability, and schedule change frequency. Distinguish original commit versus last promise date, or the metric can be gamed.
    • Receipt quality: incoming defect rate, supplier NCR rate, repeat escape rate, defect severity mix, and cost of poor quality tied to the supplier. In aerospace, recurrence often matters more than isolated defect count.
    • Response and closure speed: time to acknowledge issues, time to containment, time to corrective action submission, and time to verified closure. These show whether the supplier can work problems in a controlled way, not just ship parts.
    • Engineering and change execution: ECO or revision adoption lag, document package completeness, FAI resubmission cycle time where applicable, and deviation or concession turnaround. This is critical when parts are configuration-sensitive.
    • Traceability completeness: percentage of receipts with complete certs, lot or serial linkage, required test records, and approved documentation at receipt. A part that arrives physically on time but cannot be released is not truly on time.
    • Recovery and resilience: shortage recovery time, premium freight incidence, supplier-driven line-stop events, and performance on critical parts. These show whether collaboration works under disruption, which is usually where scorecards fail.

    If you need a practical shortlist, many teams start with 6 to 8 KPIs:

    1. On-time delivery to original commit date
    2. On-time delivery to need date for critical parts
    3. Supplier NCR rate
    4. Repeat nonconformance rate
    5. Corrective action closure cycle time
    6. Documentation and cert completeness at receipt
    7. Engineering change adoption lag
    8. Shortage recovery time

    What makes these KPIs credible

    The KPI set only reflects collaboration performance if definitions are strict and data sources are aligned. In brownfield aerospace environments, supplier performance data is often split across ERP, receiving, quality, email, portal tools, spreadsheets, and sometimes MES or PLM. If promise dates are overwritten, NCR coding is inconsistent, or cert review is manual and disconnected, the scorecard can look precise while being operationally weak.

    Common dependencies include:

    • consistent part criticality and supplier segmentation
    • clear event timestamps across PO, ASN, receipt, inspection, NCR, and closure workflows
    • stable master data and revision control
    • agreement on whether partials, split lots, and held receipts count as on time
    • documented ownership for corrective action and engineering response metrics

    Tradeoffs and failure modes

    There are real tradeoffs. A scorecard weighted too heavily toward delivery can drive expedites and paperwork shortcuts. A scorecard weighted too heavily toward defect counts can punish suppliers who report transparently while hiding low-visibility process drift elsewhere. Very detailed KPI stacks also create reporting burden and disputes over data rather than improvement.

    Failure modes to watch for include:

    • measuring last-promise delivery instead of original commitment reliability
    • ignoring first-pass document completeness
    • combining minor paperwork defects with major product escapes into one quality number
    • failing to separate supplier-caused delays from buyer-driven schedule churn
    • using one scorecard for all commodities despite very different risk profiles

    In regulated, long-lifecycle aerospace programs, this usually means you should improve data linkage and workflow discipline before attempting a full supplier system replacement. Full replacement often fails because qualification burden, integration complexity, validation effort, and downtime risk are high, while legacy ERP, QMS, PLM, and portal processes still carry records needed for traceability and change control. Coexistence with existing systems is usually the safer path.

    The best answer, then, is: use a balanced KPI set anchored in delivery, quality, responsiveness, change execution, and traceability, and make sure the underlying definitions and integrations are trustworthy. Otherwise you are measuring reporting behavior more than supplier collaboration.

  • Should non-conformance be hyphenated?

    In regulated manufacturing and quality management contexts, the safest approach is to treat this as a style and consistency question, not a compliance question.

    In common usage:

    • “Nonconformity” (one word, no hyphen) is the term used in many standards (for example, ISO 9001 uses “nonconformity”).
    • “Non-conformance” (hyphenated) is widely used in industry documents, QMS procedures, and NC/CAPA systems.
    • “Non conformance” (with a space and no hyphen) is rarely preferred and is usually treated as inconsistent or informal.

    For your QMS and operational documentation, the key point is consistency:

    • Pick a primary term (for example, “nonconformity” to align with ISO language, or “non-conformance” if that is already used in your NC forms and MES/MRP fields).
    • Document the choice in your controlled style guide or document control procedure.
    • Apply it consistently across SOPs, work instructions, forms, and electronic system fields to avoid confusion in audits, investigations, and data analysis.

    If your systems already mix terms (for example, legacy MES uses “Non-Conformance” and newer QMS uses “Nonconformity”), change control and validation requirements may make it impractical to force a full cleanup. In that case, define a clear mapping in your procedures so it is obvious to auditors and users that these labels refer to the same underlying concept.

    So, “non-conformance” may be hyphenated, but it does not have to be. Choose one convention, align it with the main standards you follow where practical, and keep it consistent across your documentation and systems.

  • What is the difference between OEEA and OEEB in ISO 22400?

    ISO 22400 distinguishes multiple standardized forms of Overall Equipment Effectiveness (OEE). “OEEA” and “OEEB” are two of these variants, designed to separate different time bases and loss categories. They are not different KPIs conceptually, but different calculation models and scopes for the same family of metrics.

    Core idea: why ISO 22400 has OEE variants

    In practice, plants calculate OEE in many inconsistent ways: shifts vs 24/7, including or excluding planned maintenance, treating changeovers differently, and so on. ISO 22400 introduces variants such as OEEA and OEEB to:

    • Make the underlying time base explicit.
    • Clarify which losses are in or out of scope.
    • Allow more apples-to-apples comparisons across lines or plants.

    Each variant is a specific, defined way to slice the same operating time and production data. Which one is appropriate depends on your operating model and the questions you are trying to answer.

    Typical difference between OEEA and OEEB

    The exact definitions and formulas are in the ISO 22400 standard itself and should be treated as the authoritative source. In broad terms used by many practitioners who follow ISO 22400 guidance:

    • OEEA is usually defined on a narrower, more “pure equipment” time base, often focusing on periods when the machine is expected to run and excluding certain planned non-production times.
    • OEEB is usually defined on a broader time base that includes more categories of loss (for example, some planned stops) so that the number reflects more of the “real-world” utilization picture.

    The intent is to separate a metric that primarily reflects equipment performance during scheduled running time (often closer to OEEA) from one that reflects overall effectiveness across a wider slice of calendar or shift time (often closer to OEEB). The precise categorization of losses (availability, performance, quality and their sub-losses) and the associated formulas are defined in detail in ISO 22400 and can vary by part of the series (e.g. 22400-2, 22400-5).

    Because individual companies and software vendors use the labels “OEEA” and “OEEB” inconsistently, you should:

    • Refer directly to the current ISO 22400 text used in your organization.
    • Document your chosen interpretation unambiguously in your data model, work instructions, and system configuration.
    • Ensure the naming in dashboards and reports matches that documented interpretation.

    Implications for regulated and brownfield environments

    In aerospace, defense, and other regulated manufacturing, the distinction between OEEA and OEEB matters because:

    • Traceability and auditability: If you use OEE for management decisions, capacity planning, or continuous improvement justifications, auditors and customers may expect you to show how it is calculated and which time and loss categories are included.
    • Mixed system reality: Legacy MES, SCADA, historians, and spreadsheets may already be computing a homegrown “OEE” that does not map cleanly to OEEA or OEEB. Forcing a hard switch to a single ISO variant without a mapping plan often breaks historical trend analysis and confuses stakeholders.
    • Validation burden: If OEE feeds any validated planning, scheduling, or cost models, changing from an OEE-like metric to strict OEEA or OEEB is a change that must be impact-assessed, tested, and documented under your change control process.

    Full replacement of all existing OEE calculations with a single ISO 22400 variant across a brownfield landscape frequently fails, not because the standard is wrong, but because:

    • Different lines or value streams genuinely need different time bases (e.g., batch vs continuous, 5×8 vs 24/7).
    • Re-implementing every dashboard, report, and integration to align with a single variant can be disruptive and costly, especially when systems are validated.
    • Historical benchmarks, targets, and contractual KPIs are often tied to legacy definitions that cannot be abandoned quickly.

    A pragmatic pattern is to map existing metrics to the closest ISO 22400 variants, label them clearly, and gradually converge where the cost and risk are justified.

    Practical steps if you want to use OEEA and OEEB

    To apply OEEA and OEEB meaningfully in your plant:

    1. Obtain and freeze the reference: Make the specific ISO 22400 edition(s) you follow part of your controlled documents. Do not rely on secondary summaries.
    2. Define loss categories precisely: Create a plant-level loss model that maps your actual events (planned maintenance, changeover, setups, standby, micro-stops, speed loss, scrap, rework) to the availability, performance, and quality buckets as defined for OEEA and OEEB.
    3. Map existing data sources: For each line, identify which systems provide run/stop signals, counts, scrap data, and planned stops. Verify that your MES/SCADA tags and event codes can be unambiguously mapped to the ISO categories; if not, plan a staggered clean-up and re-coding.
    4. Implement side-by-side calculations: Before retiring any legacy OEE definition, run OEEA and/or OEEB in parallel for a period. Document differences and agree with stakeholders on how targets will be revised.
    5. Validate and document: In regulated environments, treat the OEE calculation logic as configuration that must be version-controlled, change-controlled, and testable. Keep calculation examples and test cases as evidence.

    Ultimately, the difference between OEEA and OEEB in ISO 22400 comes down to which time you count, which losses you include, and how you want to use the metric. The standard provides the structure, but it is your responsibility to implement and document a consistent interpretation that fits your systems, products, and regulatory context.