Connect981 – Content Dev

RSC Content Type: FAQ

Direct answers to common technical or compliance questions.

  • What is the difference between ISO 27001 and GDPR?

    ISO 27001 and GDPR are related but fundamentally different. They interact, but one does not replace or guarantee the other.

    Core difference

    ISO 27001 is an international information security management standard. It describes how to set up and run an Information Security Management System (ISMS) to manage risks to information assets.

    GDPR is a law (the EU General Data Protection Regulation). It defines legal requirements for how organizations process, store, transfer, and protect personal data of individuals in the EU/EEA.

    Scope and focus

    • ISO 27001 scope:
      • Covers all information assets in scope (not just personal data): engineering data, process recipes, machine logs, MES/ERP databases, supplier documents, etc.
      • Focuses on risk management, controls, and continuous improvement of information security.
      • In a plant context, this includes OT networks, historian data, backups, remote access to equipment, vendor connectivity, and cloud services tied into MES/ERP/QMS.
    • GDPR scope:
      • Only covers personal data of identified or identifiable natural persons in the EU/EEA (employees, suppliers’ staff, customers, visitors, candidates).
      • Focuses on lawful basis, transparency, data subject rights, and cross-border transfers, in addition to security.
      • In industrial environments, this is often HR systems, access control logs, training records, QMS deviations linked to individuals, system audit logs, and support tickets.

    Legal status vs management standard

    • ISO 27001:
      • Voluntary standard (unless made mandatory by contracts or regulators).
      • You can be certified by an accredited body to show that your ISMS conforms to the standard within a defined scope.
      • Certification is based on an audit of your documented system and implemented controls.
    • GDPR:
      • Legal requirement in the EU/EEA for organizations that process personal data of individuals in that region.
      • No simple “GDPR certificate” that proves full compliance. Some schemes or codes of conduct exist, but regulators evaluate compliance case by case.
      • Non-compliance can lead to enforcement actions, including fines and mandatory remediation.

    How they relate in practice

    ISO 27001 can support GDPR, but it does not make you GDPR-compliant by itself.

    • ISO 27001 helps you systematically manage confidentiality, integrity, and availability of information, including personal data.
    • Its controls (e.g. access control, logging, encryption, secure development, supplier management) are useful for meeting GDPR’s requirement to implement “appropriate technical and organisational measures”.
    • However, GDPR includes many areas that ISO 27001 does not fully cover, such as:
      • Lawful basis for processing (consent, contract, legal obligation, etc.).
      • Data subject rights (access, deletion, portability, objection, restriction).
      • Data minimisation, purpose limitation, and storage limitation.
      • Data Protection Impact Assessments (DPIAs) for high-risk processing.
      • Rules for international data transfers.

    Because of this, you can have a well-implemented ISO 27001 ISMS and still be non-compliant with GDPR on topics like retention schedules, HR data handling, or response to subject access requests.

    Implications for industrial and regulated environments

    In brownfield manufacturing environments, both ISO 27001 and GDPR run into the same practical constraints:

    • Legacy systems: Old MES, historians, SCADA, access control systems, and data loggers often have limited security and data protection controls. Retrofitting them for least-privilege access, proper logging, or granular data retention can be complex and may require vendor cooperation and re-validation.
    • Long equipment lifecycles: Production equipment and control systems may remain in use for decades. Achieving ISO 27001-aligned controls and GDPR-aligned retention or pseudonymisation often involves compensating controls rather than full replacement.
    • Integration debt: Personal data may be replicated across HR, training, QMS, MES, and physical security systems. Mapping data flows and implementing GDPR requirements (like right to erasure or restriction) often requires significant integration work and change control.
    • Validation and qualification burden: In regulated industries, changing security controls, identity management, or logging in validated systems may trigger re-validation. This slows the rollout of ISO 27001 controls and GDPR-related changes and must be planned into the change control process.

    Misconceptions to avoid

    • “If we get ISO 27001 certified, we are GDPR compliant”: No. Certification can be evidence of a structured approach to security, but GDPR compliance depends on how you manage personal data specifically, across technical and legal dimensions.
    • “GDPR is only an IT issue”: No. GDPR affects HR policies, supplier contracts, shop-floor CCTV, badge access logs, training records, and paper records just as much as cloud or IT systems.
    • “We can fix GDPR with a new system”: Replacing legacy systems might help, but in regulated, long-lifecycle environments full replacement often fails or overruns due to downtime risk, integration complexity, and qualification/validation cost. A more realistic approach is usually incremental hardening, better governance, and precise scoping of personal data flows.

    How to use ISO 27001 to strengthen GDPR posture

    If you operate in a regulated manufacturing environment, a practical approach is:

    1. Define ISMS scope carefully: Include key systems that process personal data (HR, QMS, access control, service desk, MES user accounts, remote access gateways) and critical OT interfaces.
    2. Map personal data flows: As part of risk assessment, identify which systems hold personal data, how it moves between them, and where it is logged or backed up.
    3. Align controls with GDPR risks: Prioritise ISO 27001 controls that directly reduce GDPR risk, such as identity and access management, logging and monitoring, backup protection, and supplier security requirements.
    4. Integrate with change control and validation: Ensure ISMS-driven changes (e.g. new logging, network segmentation, or encryption) go through existing change control, qualification, and validation processes to avoid unintended compliance or availability impacts.
    5. Close non-security gaps separately: Address GDPR topics not covered by ISO 27001 (lawful basis, notices, DPIAs, data subject rights) through privacy governance, not just technical controls.

    In summary, ISO 27001 is a structured framework to manage information security risks, while GDPR is a binding legal regime for personal data protection. In industrial settings, combining both requires pragmatic integration with legacy systems, validation constraints, and existing governance processes.

  • What is the role of the execution layer in supporting AS9100 traceability requirements?

    The execution layer is where most AS9100 traceability evidence is actually created and connected. In practice this is usually an MES or execution control system, digital travelers, and related shop-floor applications that sit between ERP, PLM and QMS on one side and machines, tooling and operators on the other.

    Core role: creating & linking traceability records

    AS9100 requires you to demonstrate what was built, how it was built, with what, by whom, and under which controlled conditions. The execution layer supports this by:

    • Capturing “as-built” history for each part, assembly, or lot at the time work is done, not after the fact.
    • Enforcing routing and operation sequence so that required steps are recorded instead of skipped or bypassed.
    • Linking identifiers (part/serial numbers, batch/lot numbers, work orders, NCs, tools, gages) into a coherent genealogy.
    • Generating time-stamped records with user IDs, workstation IDs, and status codes that can be queried during audits and investigations.

    Material & component traceability

    AS9100 expects you to demonstrate control of materials and components used in production. The execution layer typically supports this by:

    • Recording material consumption at the operation or work-center level, associating specific lots/serials to the parent assembly or serialized product.
    • Verifying material status (released from receiving inspection, shelf-life valid, special storage requirements met) at the point of use.
    • Maintaining forward and backward genealogy so you can answer both “what went into this serial number?” and “where else did this lot go?”

    How deep this goes (full unit-level genealogy vs. lot-level only) depends on product risk, contract requirements, system configuration, and operator discipline.

    Process, equipment & tooling traceability

    AS9100 focuses on controlled and repeatable processes. The execution layer supports this by:

    • Enforcing approved routings and revisions that originate in PLM/engineering and are released via document control.
    • Recording process parameters or key results (where integrated) from machines, test stands, or manual input for special processes and critical operations.
    • Associating equipment and tooling (machine IDs, fixture IDs, program numbers) with the work being performed.
    • Blocking or warning on out-of-calibration tools or equipment, when integrated with calibration/asset systems.

    The strength of this traceability depends on how completely equipment and tooling data are digitized and whether those systems are integrated or still paper-based.

    Operator, training & authorization traceability

    AS9100 requires you to control who is authorized and competent to perform specific work. Execution systems can support this by:

    • Capturing operator IDs for each operation, inspection, or sign-off.
    • Enforcing authorization rules (e.g., only qualified welders can start certain operations) when integrated with training records or HR/QMS.
    • Maintaining an audit trail of overrides and dual sign-offs for special characteristics or critical steps.

    These controls only hold if the execution layer is actually used as the system of record at the station, rather than work being done off-system and back-entered later.

    Nonconformance, rework & disposition traceability

    AS9100 emphasizes control and documentation of nonconforming outputs. The execution layer is often where nonconformance events are first detected and where the “as-built” trace is updated by:

    • Flagging nonconforming parts or operations at the point of detection and routing them into the NCR/MRB process.
    • Linking NCR IDs and dispositions (use-as-is, repair, scrap, rework) to specific serial numbers, work orders, and batches.
    • Recording rework operations and re-inspections so the final history shows the real path of the product, not just the ideal route.

    Whether this lives fully inside MES or is split across MES and a separate QMS/NCR tool is a design choice. The key for AS9100 traceability is consistent identifiers and reliable integration between systems.

    Documented information & revision control at the point of use

    AS9100 requires control of documented information (work instructions, drawings, specifications). The execution layer helps by:

    • Presenting only current, approved versions of work instructions and drawings at the station.
    • Linking the revision actually used to each operation or work order, creating evidence that work was done to the correct issue.
    • Preventing work start when a routing, spec, or WI has been superseded but not properly released into production.

    This relies on disciplined version governance in PLM/engineering and robust change control. If design and process changes are poorly managed, the execution system cannot protect traceability on its own.

    Auditability, searchability & evidence retrieval

    AS9100 auditors expect you to retrieve traceability evidence quickly and consistently. The execution layer is central to that by:

    • Providing queryable histories by serial number, lot, work order, date range, or operation.
    • Maintaining system audit trails that show who changed what, when, and under which approval.
    • Feeding structured data to QMS and reporting tools to support internal audits, customer audits, and investigations.

    The value here depends on data quality, master data discipline, and how well the execution layer is integrated with QMS/ERP. Poor configuration or inconsistent shop-floor use will still result in slow, manual evidence gathering.

    Coexistence with ERP, PLM and QMS in brownfield environments

    In most aerospace plants, the execution layer does not replace ERP, PLM, or QMS. Instead, it sits between them and the shop floor:

    • ERP remains the commercial and high-level manufacturing record system (orders, financial inventory, planning).
    • PLM/engineering remains the design and configuration authority (BOMs, routings, specifications).
    • QMS remains the home for procedures, audits, CAPA, and higher-level quality management.
    • Execution systems create the detailed as-built history and genealogy and push key data back up.

    Full replacement of legacy MES or homegrown travelers is often unrealistic in aerospace due to validation cost, qualification of new systems, downtime constraints, and the risk of disrupting established, audited processes. Incremental deployment, focused on high-risk or high-visibility product families, is more typical, with interfaces that keep traceability coherent across old and new systems.

    Limits & dependencies

    The execution layer is necessary for robust, scalable traceability in complex aerospace operations, but it is not sufficient by itself to “achieve AS9100 compliance.” Its effectiveness is constrained by:

    • Configuration and master data quality (BOM/routing correctness, identifier discipline, clear linking rules).
    • Integration with ERP, PLM, QMS, calibration, and NCR systems so traceability is end-to-end rather than siloed.
    • Process maturity and change control, ensuring engineering changes and procedure updates are reflected before work starts.
    • Operator adoption and training, avoiding backfilling and workarounds that undermine the record.
    • Validation and qualification of the system where required by customers or regulators.

    Used correctly, the execution layer becomes the backbone of AS9100 traceability, but outcomes will vary significantly between plants based on how these dependencies are handled.

  • Can custom KPIs later be standardized across our sites?

    Yes, custom KPIs can often be standardized across sites, but only if you invest in common definitions, data structures, and governance. In regulated, brownfield environments this is a structured change program, not a simple reporting change.

    What “standardizing” KPIs actually means

    Standardization is more than reusing the same label on dashboards. It typically requires:

    • Harmonized definitions: Clear and approved definitions for numerator, denominator, scope, and exclusions (e.g., what counts as planned vs unplanned downtime).
    • Aligned data model: Consistent event types, status codes, and work-center hierarchies so that KPI calculations mean the same thing at each site.
    • Common calculation logic: Implemented consistently in MES, data warehouse, reporting tools, and Excel extracts, not just in one analytics layer.
    • Governed change control: Any KPI definition change is versioned, impact-assessed, and communicated across all sites.

    Typical path from local custom KPI to network standard

    In practice, standardization usually proceeds in stages:

    1. Inventory existing KPIs: Document how each site currently calculates its custom KPIs, including data sources, filters, and purpose.
    2. Consolidate to candidate standards: Group similar KPIs and define a proposed standard per category (e.g., a standard defect rate, a standard rework KPI).
    3. Negotiate edge cases: Resolve differences in operating context (e.g., continuous vs batch processes, manual vs automated inspection) and document allowed site-specific modifiers.
    4. Define the data contract: Specify required fields, event codes, time-bucketing rules, and system-of-record expectations for each standard KPI.
    5. Implement in systems: Update MES/MOM, data integrations, and reporting logic so the standard KPI is computed the same way across plants.
    6. Validate and baseline: Parallel-run old vs new KPI definitions, understand deltas, and agree a cutover date for formal reporting.

    Key constraints and dependencies

    Whether standardization is realistic depends on several factors:

    • System heterogeneity: Mixed MES/ERP/QMS stacks and homegrown systems make it harder to implement identical logic everywhere. Interfaces and data models may not support all desired KPIs without modification.
    • Data quality and completeness: If some sites do not reliably capture the underlying events (e.g., manual downtime coding, partial genealogy data), you cannot truly standardize; at best you approximate and state limitations.
    • Regulatory and customer constraints: Some sites may have certifier or customer-specific reporting definitions that cannot be changed without requalification or contract updates.
    • Operational diversity: Different product mixes, routings, batch sizes, and automation levels mean some KPIs can be global, others only comparable within process families.
    • Validation burden: In regulated environments, changing KPI definitions inside validated systems may require formal validation, documentation, and, in some cases, impact assessments on procedures and quality records.

    Why you cannot just “roll up” site-specific KPIs

    Simply aggregating existing KPIs from different sites almost always fails for cross-site comparison:

    • Different denominators: One site uses hours, another uses scheduled time, another uses available time for utilization or OEE components.
    • Different inclusion rules: Some sites include engineering trials, rework, or quarantine time; others exclude them.
    • Different event taxonomies: Loss categories and defect codes do not match, so root causes are not comparable.

    Without harmonizing these details, any “network average” KPI is at best an internal trend tool, not a reliable comparison across plants.

    Coexistence with existing systems and KPIs

    In a brownfield environment, standardization almost always requires KPI coexistence for some period:

    • Dual reporting period: Sites often maintain legacy KPIs for local use (and historical continuity) while introducing standardized KPIs for corporate reporting.
    • Bridging logic: You may need mapping rules to translate historic KPI values into the new definition for trend analysis, with clear caveats.
    • System limits: If some legacy systems cannot be economically changed, the standardized KPI may be implemented in a central data platform while the plant still uses old logic locally.
    • No “big bang” replacement: Replacing all local metrics and systems at once is risky and rarely necessary; incremental rollout by process family or region is usually safer.

    Tradeoffs you should expect

    Standardizing custom KPIs involves clear tradeoffs:

    • Comparability vs local relevance: A strong global definition may reduce sensitivity to some site-specific nuances; local metrics may still be needed.
    • Speed vs rigor: Rapid standardization without proper definition, validation, and change control can create false confidence and audit exposure.
    • Detail vs maintainability: Highly complex KPI logic can capture every exception but becomes difficult to operate, train, and validate across many sites.

    Governance and lifecycle considerations

    In regulated industries with long equipment lifecycles, KPI standardization must be treated as an ongoing governance topic, not a one-time project:

    • Metric ownership: Assign process owners for each standard KPI, responsible for definition, documentation, and change requests.
    • Versioning: Maintain version histories of KPI definitions and ensure reports clearly indicate which version is used.
    • Change control: Route KPI definition changes through existing change control boards, especially if they affect validated systems or quality reporting.
    • Training and procedures: Update SOPs, work instructions, and training materials where KPIs are referenced in decision-making or regulatory documentation.

    With this discipline, many locally developed KPIs can evolve into robust network standards, but the work is in the definitions, data foundations, and governance, not in the dashboards.

  • Can I be certified to NIST 800-53?

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

    What NIST 800-53 actually is

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

    What you can realistically claim

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

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

    How this fits in regulated industrial environments

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

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

    Evidence and assurance instead of certification

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

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

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

    How to position this in your organization

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

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

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

  • What is an appropriate level of concession volume for a mature program?

    There is no single acceptable concession volume that applies across all mature programs.

    In general, a mature program should not rely on concessions as a routine operating mechanism. Concession volume should be low, stable, and trending downward or at least remaining within a clearly understood control band. If concessions become a normal path to ship product, that usually indicates unresolved process capability issues, design tolerance problems, supplier variation, inspection escape patterns, or weak change control.

    That said, the right threshold depends on context, including:

    • product criticality and risk tolerance
    • customer and contractual requirements
    • whether the program is production, sustainment, repair, or spares-heavy
    • process capability and measurement system quality
    • supplier quality performance
    • how a concession is defined, classified, and counted in your quality system

    So the practical answer is not a benchmark percentage by itself. The better question is whether concession volume is expected, exceptional, and explainable.

    What good looks like

    For a mature program, concession activity is usually appropriate when all of the following are true:

    • most concessions are isolated rather than repetitive
    • repeat concessions on the same part family, operation, tool, or supplier are rare
    • each concession has clear technical rationale and disposition traceability
    • there is visible linkage to corrective action when recurrence crosses a defined threshold
    • the business is not using concessions to mask chronic scrap, rework, planning instability, or schedule pressure

    If recurring concessions are common, the program may still be shipping product, but it is not operating in a mature state in any meaningful quality or execution sense.

    What to measure instead of asking for a single number

    A raw concession count can be misleading. A better assessment uses a small set of normalized measures such as:

    • concessions per 100 units, lot, or work orders
    • concessions by defect type, process step, and part family
    • repeat concession rate within a defined time window
    • concessions tied to supplier-caused versus internal-caused nonconformances
    • cost, cycle time, and queue impact of concession processing
    • share of concessions closed with permanent corrective action versus administrative closure only

    This matters because a low count can still hide significant risk if the same issue recurs on critical hardware, while a higher count in a complex sustainment environment may be understandable if tightly controlled and non-repetitive.

    When concession volume is too high

    Concession volume is probably too high for a mature program if any of these patterns appear:

    • the rate is flat or increasing after process stabilization
    • the same dimensions, features, documents, or suppliers drive repeated concessions
    • MRB capacity is overloaded and becomes a production bottleneck
    • engineering spends material time reviewing predictable issues that should have been designed out or controlled out
    • operators or supervisors expect concessions as part of normal completion
    • schedule recovery depends on concession approval speed

    At that point, the issue is not just quality. It is also capacity, cost of poor quality, and evidence that process learning is not being converted into standard work, tooling changes, supplier controls, or design updates.

    Brownfield reality

    In many regulated plants, concession volume is distorted by system fragmentation. The same event may touch MES, ERP, QMS, and MRB workflows differently, and some plants still carry part of the record in paper or spreadsheets. That means your concession baseline may be unreliable until definitions, data capture, and workflow ownership are cleaned up.

    Because of that, full system replacement is usually not the first answer. In long lifecycle, qualified environments, replacement programs often fail or stall due to validation effort, downtime risk, integration complexity, and the burden of preserving traceability across legacy records. A more realistic path is often to standardize definitions, improve routing and evidence capture, and integrate existing systems well enough to separate true concession demand from administrative noise.

    Practical guidance

    An appropriate level for a mature program is the lowest level that is sustainable without pushing risk downstream, while keeping each concession exceptional, justified, and traceable.

    If you need a management rule, use this one: concessions in a mature program should be rare enough that recurrence stands out quickly, not common enough that people stop noticing. Set internal thresholds by product family and risk class, then review trend, recurrence, and operational impact together rather than relying on a generic industry target.

    No single concession percentage can tell you whether the program is healthy. Recurrence, concentration, and dependence on concessions for routine output are usually the more important signals.

  • What traceability data does MES typically store for aerospace parts?

    Core part and lot identity

    In most aerospace environments, MES is configured to store a stable identity for each part, lot, or serialized unit, but the depth varies by site and by program. At minimum, this usually includes internal part number, revision or configuration identifier, and some form of lot or serial number. Many systems also store build-to configuration links, such as references to specific work orders, routers, or effectivity-controlled build standards. Where MES is integrated with PLM or ERP, it may also hold cross-references to engineering part numbers, customer part numbers, or contract identifiers, but these references can be incomplete or inconsistent on older programs. You should not assume that every MES instance holds the same identity model; it depends heavily on how it was implemented and validated.

    Genealogy and component traceability

    Aerospace MES implementations typically aim to store forward and backward genealogy for assemblies, but how reliably this works depends on discipline at data entry and the maturity of integrations. At the assembly level, MES often records which child parts, subassemblies, and consumables were used to build each parent unit, typically via scan or manual entry at specific operations. For serialized components, MES may store individual serial numbers and lot codes, while for bulk materials it may only store lot or batch IDs. Rework and replacement events can fragment genealogy if the process is not well controlled and validated, leaving gaps in parent-child links. Legacy or mixed-vendor cells sometimes track genealogy partly in MES and partly in spreadsheets or paper travelers, which weakens end-to-end traceability.

    Process history and routing execution

    MES usually maintains a detailed execution history for each part as it moves through its routing or traveler, but how granular that history is can vary greatly. Typical data includes which operations were performed, in what sequence, and when each was started and completed. Many systems also store which standard work or revision of the routing was active at the time, but that linkage often depends on integration with PLM or routing masters in ERP. Deviations, rework routes, and non-standard operations may be logged, yet the level of structure (coded rework operations versus free-text comments) is often inconsistent. In partial or staged MES rollouts, only selected work centers may be tracked in detail, leaving upstream or downstream steps effectively dark from a system-traceability standpoint.

    Equipment, tooling, and fixture traceability

    For special processes and critical operations, MES is often configured to record which machines, ovens, test stands, or other equipment were used on each part. This may include equipment IDs, software or parameter set identifiers, and sometimes environment data captured from connected systems. Tooling and fixture traceability is more uneven: some plants log fixture IDs, torque tool IDs, and calibration status at each use; others only track calibration in a separate system and rely on procedure discipline rather than tight MES linkage. When equipment data comes from interfaces with SCADA, historians, or local controllers, communication failures and mismatched asset IDs can create blind spots. As a result, tracing a part back to exact equipment conditions can be straightforward in some cells and nearly impossible in others without manual reconstruction.

    Materials, batches, and special processes

    MES in aerospace typically stores which raw material lots, chemical batches, and special process batches (heat treat, plating, composites cure, etc.) were applied to each part or lot. At a minimum, this often includes batch or lot number, process type, and basic run identifiers; more mature implementations may also tie in furnace or autoclave run IDs, recipe names, and critical parameter summaries. However, much of the detailed parameter data (temperature profiles, pressures, times) may live primarily in specialized process systems or data historians rather than directly in MES. When these systems are not tightly integrated, MES may only store a reference to an external batch record, weakening unified digital traceability. You should verify exactly which material and process links are enforced and which are optional or manual in your environment.

    Operator actions, approvals, and qualifications

    Most MES configurations for aerospace store who performed, verified, or approved each significant step, typically via user logins, electronic signatures, or badge scans. Records often capture operator ID, inspector or supervisor ID, timestamps, and sometimes role or authority level. In more integrated setups, MES may verify operator qualifications or training status by referencing a separate learning or qualification management system, but this linkage is not universal and may degrade over time if not maintained. When shared accounts, badge sharing, or offline operations occur, the integrity of operator traceability is weakened even if the MES schema technically supports it. You should treat operator traceability as only as strong as the site’s access control discipline and e-signature validation practices.

    Nonconformances, defects, and concessions

    Where MES overlaps with or integrates into QMS functions, it may store nonconformance records tied directly to part IDs, operations, and work orders. Typical data includes defect codes, severity, location on part, suspected cause, and the associated disposition or concession decision. However, many aerospace organizations still manage detailed nonconformance, MRB, and concession processes in a dedicated QMS or PLM tool, with MES only carrying a reference number or high-level status. This split can create partial traceability in MES: it knows that a part had a nonconformance and that it was dispositioned, but the full technical rationale and risk assessment may sit elsewhere. For root cause analysis and field investigations, teams often have to correlate MES data with QMS and PLM records manually.

    Test, inspection, and measurement data

    MES implementations usually record whether required inspections and tests were completed and whether they passed or failed, along with who performed them and when. Some systems also capture key measurement values directly, especially for in-process checks and critical dimensions, but large or complex data sets from CMMs, NDT systems, or functional tests are often stored in separate systems or files. In many brownfield aerospace plants, MES stores only summary results or links to external test reports rather than full raw data. This can be adequate for routine traceability but limiting for deep investigations or statistical analysis. Any assumption that “all test data is in MES” should be validated against actual interfaces and historical practices.

    Document, configuration, and revision references

    MES usually stores references to the work instructions, drawings, specifications, and configuration baselines that applied at the time of production, but how precise this is depends on change control and integration quality. Some sites link operations directly to specific document IDs and revisions and enforce effectivity by date, lot, or serial number through integration with PLM and document control systems. Others rely on manual selection of documents by operators or static links that are not updated reliably when engineering changes occur. In the latter case, MES may show which document was nominally used, but that may not match what operators actually referenced on the floor. When investigating configuration issues, teams often need to reconcile MES records with independent document management logs.

    Data retention, gaps, and brownfield realities

    Even when MES is designed to hold rich traceability data, what is actually present for a specific program or era may be constrained by project scope, cutover decisions, and retention policies. Older parts may have incomplete data if they span a time before MES rollout, during partial implementation, or through major system migrations. Interfaces with ERP, PLM, QMS, and process systems are common failure points, leading to missing genealogy links, orphaned nonconformance references, or equipment data that was never actually captured. Long equipment and program lifecycles in aerospace mean that multiple generations of systems and schemas often coexist, and some traceability still relies on scanned paper, local databases, or operator logs. Anyone relying on MES for regulatory or customer traceability needs to verify the real content and quality of records for the specific timeframes and product families in scope.

    Connecting this to your own environment

    To determine what traceability data your MES actually stores for aerospace parts, you will need to look beyond vendor documentation and check configured fields, interfaces, and validated use cases. Start by sampling records for several representative programs and time periods, and see which of the categories above are fully populated, partially filled, or missing. Compare MES records with external sources like QMS, PLM, and process systems to identify where traceability chains break or rely on manual steps. In many plants, extending traceability means tightening barcode or RFID use, hardening integrations, and bringing some QMS or special-process data closer to MES rather than expecting a complete replacement of existing systems. Any change to traceability scope should go through proper change control and validation, especially where electronic records are used to support certifications or customer audits.

  • How do I integrate AI-related risks into existing aerospace FMEA processes?

    In most aerospace environments, you should not create a separate, standalone AI risk method if an established FMEA process already exists. Instead, extend the current FMEA so the AI-enabled function, model, data pipeline, and human decision points are treated as potential contributors to failure modes.

    The practical answer is to analyze AI as part of the system that can fail, degrade, mislead, or become invalid outside its intended operating conditions. That means your existing product, process, design, or software FMEA structure can usually remain in place, but the failure modes, causes, controls, and detection methods need to expand.

    What to add to the FMEA

    • AI-specific failure causes: incorrect training data, incomplete edge-case coverage, label quality issues, feature extraction errors, model drift, threshold misconfiguration, poor calibration, integration defects, latency, and bad handoff logic to MES, QMS, ERP, inspection, or operator workflows.

    • Assumption failures: the model may only be valid for certain part families, machine states, environmental conditions, sensor quality levels, or process windows. If those assumptions are violated, the output may still look plausible while being wrong.

    • Human factors: overreliance on recommendations, weak review criteria, unclear override authority, poor alert design, or inconsistent operator response to AI-generated guidance.

    • Data lineage and version risks: model version, input data version, rules version, and deployment configuration can all affect outcome quality. If these are not traceable, the FMEA is incomplete.

    • Monitoring and degradation: the system can perform well during validation and then degrade in production because the process, equipment, material mix, or usage context changed.

    How to structure it

    A workable pattern is to keep the item or process step from the current FMEA, then add AI-related entries where the AI influences detection, recommendation, classification, prioritization, or control actions.

    For each relevant FMEA line, ask:

    • What function is the AI supporting?

    • What happens if the AI output is wrong, missing, delayed, biased, stale, or used outside intended scope?

    • Does the failure create a product risk, process escape risk, maintenance risk, quality system risk, or only an efficiency loss?

    • What independent controls exist if the AI fails silently?

    • How would you detect degraded performance before a nonconformance, scrap event, or escape occurs?

    • What evidence shows the model is still operating within validated limits?

    If the AI is advisory only, your FMEA should state that clearly and identify the human review control. If the AI triggers or suppresses actions automatically, the scrutiny should be higher because the consequence and detectability profiles change.

    Scoring considerations

    You can usually retain your existing severity, occurrence, and detection scoring method. What changes is how you assign the scores.

    • Severity: score the business and operational effect of the resulting failure, not the novelty of AI.

    • Occurrence: estimate based on actual model behavior, data quality history, known edge cases, process variability, and integration reliability. Early pilots often have less stable occurrence estimates than mature deterministic logic.

    • Detection: many AI risks are hard to detect because outputs may appear credible. If there is no independent verification, detection may be weaker than teams first assume.

    Be careful not to under-score occurrence or over-score detection simply because a model performed well in a test set. Production reality in aerospace is often more varied than qualification datasets.

    Controls that usually matter

    • Defined intended use and operating boundaries

    • Approved training and test data management

    • Version control for models, prompts, rules, and interfaces

    • Deployment approval and change control

    • Fallback procedures if the AI is unavailable or questionable

    • Human review criteria and override logging

    • Performance monitoring, drift checks, and revalidation triggers

    • Traceable links to NCR, CAPA, deviation, and investigation workflows when errors occur

    Those controls belong in the FMEA as prevention or detection controls only if they are actually implemented and maintained. Planned controls are not the same as effective controls.

    What not to do

    • Do not treat AI risk as only a cybersecurity issue. Some risks are data, model, process, and human-use issues rather than malicious threats.

    • Do not assume a vendor’s validation package maps cleanly to your plant, part mix, or quality system.

    • Do not separate the AI review from normal change control, configuration management, and traceability expectations.

    • Do not replace existing FMEA, control plan, software assurance, or engineering review methods unless you have a strong, validated reason. In regulated aerospace environments, replacement adds qualification burden, integration risk, retraining effort, and evidence gaps.

    Brownfield reality

    In practice, AI-related risk integration usually fails when teams try to bolt a new model onto a fragmented stack without clarifying system boundaries. If the AI consumes data from legacy MES, ERP, historians, inspection systems, or spreadsheets with inconsistent semantics, your FMEA should reflect that dependency explicitly.

    Most plants will need coexistence, not full replacement. The AI layer often sits on top of existing workflows, and that means failure modes can originate in master data, routing revisions, sensor quality, interface timing, or operator workarounds in older systems. Ignoring those brownfield dependencies makes the FMEA look cleaner than reality.

    Minimum implementation approach

    If you need a practical starting point, identify the top few process steps where AI affects acceptance, prioritization, anomaly detection, maintenance decisions, or operator instruction. Add AI-related causes, controls, and detection methods to those existing FMEA lines first. Then connect them to traceability, monitoring, and change control before scaling further.

    That approach is usually more durable than launching a parallel AI risk register with no link to shop-floor execution or quality evidence.

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

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

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

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

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

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

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

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

    How ISA-88 defines batch process control

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

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

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

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

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

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

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

    What ISA-88 does and does not do

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

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

    Common failure modes include:

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

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

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

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

    How it fits in brownfield plants

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

    A more practical approach is usually incremental:

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

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

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

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

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

    Why operations and quality teams care

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

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

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

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

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

    Core difference

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

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

    Where they come from in the IEC 62443 series

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

    How SL-T is determined

    SL-T is driven by:

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

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

    How SL-C is determined

    SL-C is typically established by:

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

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

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

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

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

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

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

    Brownfield and regulated environment realities

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

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

    As a result, many programs focus on:

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

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

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

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

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