Connect981 – Content Dev

RSC Topic: Audit Readiness & Evidence Management

Ongoing audit-proof documentation, approvals, and revision histories.

  • layered process audit

    A layered process audit commonly refers to a structured, recurring check of whether defined process steps, standard work, and key controls are being followed on the shop floor or in operational support processes. The “layered” part means the audit is performed by different levels of the organization, such as team leads, supervisors, managers, and sometimes quality or plant leadership, using aligned audit questions at different frequencies.

    In manufacturing, the term usually applies to routine verification of process discipline rather than a one-time system audit. It focuses on whether critical operating conditions are present and sustained, for example whether the right work instruction is in use, required checks are completed, tools are set correctly, materials are identified properly, and escalation steps are followed when something is out of condition.

    What it includes

    • Brief, repeated audits tied to a process, line, cell, area, or support function

    • Standardized questions or check points based on process risks or known failure modes

    • Participation by multiple management layers with defined cadence

    • Documentation of findings, follow-up actions, and closure status

    • Use as an operational control to detect drift from standard work

    It does not usually mean a financial audit, a certification audit, or a full quality management system audit. It is narrower and more operational than those activities.

    How it appears in workflows and systems

    Layered process audits may be managed on paper, in spreadsheets, or in MES, QMS, mobile audit, or digital work instruction platforms. In digital environments, an LPA program often includes scheduled audit tasks, role-based assignments, evidence capture, timestamps, exception logging, and action tracking. Results may also be reviewed alongside nonconformance, CAPA, scrap, rework, or training records to identify recurring process weaknesses.

    Common confusion

    Layered process audit is often confused with product inspection. They are related but not the same. Product inspection checks whether the output meets requirements. A layered process audit checks whether the process conditions and behaviors intended to produce conforming output are actually being followed.

    It is also commonly confused with an internal quality audit. An internal audit typically reviews broader system conformance, procedures, or compliance against an audit scope. A layered process audit is usually shorter, more frequent, and focused on day-to-day execution at the point of use.

    Manufacturing example

    On an assembly line, an operator lead might verify each shift that the current work instruction revision is posted and torque checks are recorded. A supervisor might review the same area daily for material identification and reaction-plan compliance. A manager might audit weekly for sustained adherence and closure of prior findings. Together, those checks form the layered approach.

  • Delta FAI

    Delta FAI commonly refers to a partial or incremental First Article Inspection (FAI) that documents and verifies only the changes from a prior, approved baseline FAI. It is typically used in aerospace and other regulated manufacturing environments that follow AS9102 or similar requirements.

    Instead of repeating a full FAI on an unchanged part, a Delta FAI focuses on characteristics, features, or process steps that are affected by a design change, process change, tooling change, supplier change, or other defined trigger. The intent is to show objective evidence that the impact of the change has been understood and that the affected characteristics still meet requirements.

    What Delta FAI includes

    In practice, a Delta FAI usually includes:

    • Reference to the original, full FAI report used as the baseline
    • Identification of the specific change drivers (for example, engineering change order, revised drawing, new machine or program)
    • Updated ballooned drawings or characteristic listings limited to affected features
    • Measurement results and inspection records only for the affected characteristics
    • Updated process or routing references when manufacturing steps have changed
    • Signoff and date stamps that clearly differentiate Delta FAI from the original submission

    Delta FAIs can be recorded using the same forms or digital tools as a full FAI, with the scope and coverage clearly marked as incremental to an earlier report.

    What Delta FAI is not

    • It is not a full, start-to-finish First Article Inspection on every feature of the part.
    • It is not intended to bypass FAI triggers that would require a full re-FAI, as defined by customer or standard-specific rules.
    • It is not a generic in-process inspection; it is tied to configuration-controlled changes relative to a known baseline.

    Operational use in manufacturing

    On the shop floor and in quality systems, a Delta FAI typically appears as:

    • An additional FAI package linked to the same part number and revision, but associated with a new change notice or revision level
    • A focused inspection plan generated by MES, QMS, or FAI software containing only the impacted characteristics
    • A referenced attachment in customer portals or FAI management tools (for example, a new Delta FAI submission in Net-Inspect that points back to an earlier FAI record)

    Digital workflows often manage Delta FAI by versioning FAI records, preserving traceability between the original FAI and each incremental update so that auditors and customers can reconstruct the complete inspection history of a part or assembly.

    Common confusion

    • Delta FAI vs. full FAI: A full FAI covers all drawing characteristics and applicable requirements. A Delta FAI limits coverage to characteristics impacted by a defined change, with the original FAI serving as the baseline for everything else.
    • Delta FAI vs. routine inspection: Routine in-process or final inspection may occur on every lot or shipment, but a Delta FAI is a formal, documented event tied to configuration changes and often controlled by customer or standard-driven criteria.

    Context in AS9102 and aerospace

    In aerospace, customer specifications or quality agreements often define when a new full FAI is required versus when a Delta FAI is acceptable. Organizations typically maintain procedures that:

    • Define change events that trigger a Delta FAI (for example, drawing revision that affects only certain dimensions)
    • Describe how to identify and document affected characteristics
    • Ensure that both the original and Delta FAI records are retained and traceable for audits and customer review

    Although the exact term “Delta FAI” may not be formally defined in every standard, it is widely used in industry practice to describe this incremental FAI approach.

  • electronic audit trail

    An electronic audit trail is a system-generated, time-stamped record of activities that occur within a digital application or data set. In industrial and regulated manufacturing environments, it commonly refers to the detailed logging of user actions and system events that affect product records, procedures, and quality or compliance data.

    What an electronic audit trail typically includes

    In manufacturing, an electronic audit trail usually captures:

    • Who performed the action (user ID, role, or system account)
    • What was done (create, view, modify, approve, reject, delete, or execute a step)
    • When it happened (date and precise time, often with time zone)
    • Where it occurred (workstation, device, line, site, or IP address, when available)
    • Which record was affected (e.g., work order, batch, DHR, FAI, NCR, or work instruction revision)
    • Before/after values or a reference to versions, so changes can be reconstructed

    These logs are usually write-once and protected from casual editing, so they provide durable evidence of how electronic records have been created, used, and changed over time.

    How electronic audit trails appear in operations

    Electronic audit trails are embedded in many industrial and enterprise systems, such as:

    • MES and digital travelers tracking operator logins, step completions, overrides, and rework routing
    • QMS and CAPA systems logging approvals, status changes, and document revisions
    • PLM and document control recording work instruction changes, redlines, and effective dates
    • ERP and inventory systems capturing material movements, lot allocations, and adjustments
    • Electronic DHR or batch records tracking data entry, sign-offs, and parameter changes

    During internal or external audits, these trails are commonly queried to show which revision was active on a given date, who approved a deviation, or how a nonconformance was processed.

    What it is not

    An electronic audit trail is not the same as the business record itself. For example, the work instruction, batch record, or inspection report is the primary record; the audit trail documents the lifecycle of that record. It is also not the same as general IT system logs that capture low-level technical events with no clear link to regulated records or shop floor actions.

    Common confusion

    Electronic audit trail vs. traceability: An audit trail focuses on who did what to a record over time, while traceability focuses on how materials, components, and process steps link across lots, units, and operations. Audit trails often support traceability, but the terms are not interchangeable.

    Electronic audit trail vs. version history: Version history shows discrete revisions of a document or configuration. The audit trail may include those version changes plus additional events such as access, approvals, or attempted edits.

    Link to digital work instructions and revision control

    In digital work instruction systems, the electronic audit trail commonly records who authored or edited instructions, who reviewed and approved them, when a revision was released or retired, and which operators accessed which revision on the shop floor. This supports controlled deployment, reduces the risk of obsolete instructions being used, and provides evidence of document control practices during audits.

  • How do supplier scorecards relate to the approved supplier list in AS9100?

    They are related, but they are not the same thing.

    In an AS9100 quality management system, the approved supplier list (ASL) is the controlled record of suppliers your organization has determined are acceptable for specified scopes of supply or services. Supplier scorecards are one way to monitor and evaluate ongoing supplier performance. In other words, the scorecard is typically an input to supplier approval and re-evaluation, while the ASL is the formal output of that process.

    In practice, this connects to AS9100 compliance when teams need to turn the answer into repeatable execution habits.

    A supplier can be on the ASL without having a sophisticated scorecard, especially in smaller organizations or lower-volume categories, if the organization has another documented and effective method for evaluation and re-evaluation. Likewise, a supplier can have scorecard data and still remain only conditionally approved, limited by commodity, limited by program, or subject to additional controls. AS9100 does not require a specific scorecard format, threshold, or software tool.

    How they usually connect

    • Initial approval: Qualification evidence, risk review, certifications where relevant, capability assessments, trial orders, or first article results may be used before a supplier is placed on the ASL.

    • Ongoing monitoring: Scorecards often track on-time delivery, quality performance, escapes, responsiveness, corrective action closure, and other metrics defined by the organization.

    • Periodic re-evaluation: The organization reviews the evidence, including scorecard trends, and decides whether the supplier remains approved, becomes conditional, requires development, or should be removed for a given scope.

    • Controls and actions: Poor scorecard performance should trigger defined actions such as increased inspection, source inspection, CAPA, limited approval status, or sourcing restrictions, if that is what your procedure requires.

    The key point is traceability between the data you collect and the supplier status you assign. If scorecards exist but do not drive any documented review or decision-making, they add little control value.

    What AS9100 generally expects

    AS9100 is concerned with externally provided processes, products, and services being controlled using defined criteria. That usually means your organization should be able to show:

    • how suppliers are approved

    • how performance is monitored

    • how often re-evaluation occurs or what event triggers it

    • what thresholds or risk factors matter

    • who can change supplier status on the ASL

    • what records are retained as objective evidence

    A scorecard can support all of that, but it does not replace the need for a controlled supplier approval process.

    Common failure modes

    • No defined decision rule: Teams collect metrics, but no one knows what score requires escalation, conditional approval, or removal from the ASL.

    • Poor master data: Supplier names, sites, legal entities, and commodity scopes do not match across ERP, QMS, receiving, and procurement systems, so scorecard results are unreliable.

    • Scope ambiguity: A supplier may be acceptable for one process or part family but not another. A single yes or no ASL status can hide this.

    • Manual lag: Quality issues are known in NCR or receiving records, but the ASL is updated late, so buyers continue placing orders.

    • Metric distortion: A supplier meets delivery metrics by shipping partial quantities or low-risk work first, while quality performance deteriorates.

    • No change control: Supplier status changes happen by email or spreadsheet without review history, approval traceability, or effective dates.

    These problems are common in brownfield environments because supplier data and performance signals often live across ERP, QMS, supplier portals, spreadsheets, and email. If those systems are not aligned, scorecards can look precise while the ASL process remains weak.

    Brownfield system reality

    In many regulated plants, the ASL is maintained in one system, purchasing transacts in ERP, supplier NCRs sit in QMS, and delivery performance is calculated from receiving or planning data. That coexistence can work, but only if ownership, data mapping, and update timing are explicit.

    Trying to replace all supplier, quality, and ERP workflows at once is often a bad strategy in long-lifecycle regulated environments. The qualification burden, validation cost, downtime risk, and integration complexity are usually high, and the result can be weaker traceability during transition. A more practical approach is often to preserve the system of record for the ASL, connect scorecard inputs from adjacent systems, and put formal review and change control around status decisions.

    So the practical answer is: supplier scorecards should inform the approved supplier list, but your documented process must define exactly how. If that linkage is vague, manual, or inconsistent across systems, you should not assume the scorecard by itself demonstrates effective supplier control.

  • What documentation should we collect from critical suppliers for SR controls?

    For critical suppliers that affect safety, product quality, or regulated data, SR control documentation should be driven by a risk-based supplier tiering model and mapped to your own security and quality management systems. You will not collect the same depth from every vendor, and some evidence will only be available under NDA or on-site review.

    1. Governance and contractual documentation

    At a minimum for critical suppliers, you should expect:

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

    • Master supply / service agreement with security and confidentiality clauses that reference applicable standards or frameworks.
    • Data processing and protection terms covering regulated data (e.g., export-controlled, PHI, PII, customer proprietary), including roles, subprocessors, and data location.
    • Service level and availability commitments for systems that impact production scheduling, quality release, or maintenance windows.
    • Change notification requirements (e.g., infrastructure changes, hosting moves, key personnel changes, material subcontracting, EOL announcements).
    • Right-to-audit / right-to-assess language so you can review evidence without assuming compliance or certification.

    2. Information security and SR control documentation

    For SR-related controls (for example, in the sense of IEC 62443 or similar frameworks), useful supplier documentation typically includes:

    • Information security policy overview (high-level, not full internal manuals), showing scope, governance, and alignment to any named standards.
    • Network and system security approach for the product or service you use, including segmentation assumptions, remote access mechanisms, and customer responsibilities.
    • Access control model (how accounts, roles, and privileges are provisioned, reviewed, and revoked for your environment and for their support staff).
    • Remote support procedures (how remote sessions are initiated, authenticated, logged, and approved, and what emergency access looks like).
    • Backup and recovery strategy for hosted or managed systems that affect manufacturing operations or quality data.

    The depth of what you request should be proportional to supplier impact and the maturity of their own security program. Many OT and equipment vendors will only provide summaries rather than detailed diagrams.

    3. Secure development, configuration, and change control

    Because SR controls are easily broken by uncontrolled changes, you should ask critical suppliers for documentation that shows how they manage change:

    • Secure development practices at a summary level (code review, dependency management, static/dynamic testing) for software, firmware, or configuration packages.
    • Configuration management of delivered systems (how versions of PLC logic, recipes, or application configurations are controlled and identified).
    • Formal release notes for software/firmware/patches that clearly state:
      • Version identifiers and release dates
      • Security-related fixes and known issues
      • Upgrade prerequisites and rollback options
    • Change notification process for security-relevant changes affecting network ports, authentication methods, encryption, or logging.
    • End-of-life and end-of-support policies for hardware, OS versions, and major software releases.

    4. Vulnerability, patch, and incident handling documentation

    For systems connected to your OT/IT networks or handling regulated data, you should collect evidence of how the supplier manages vulnerabilities and incidents:

    • Vulnerability management process overview including intake, triage, remediation targets, and communication methods with customers.
    • Patch management policy and typical release cadence for security fixes, including how they differentiate security vs functionality updates.
    • Public advisory practices (e.g., product advisories, security bulletins) and how you can subscribe or be notified.
    • Security incident response process at a summary level: detection, containment, investigation, customer communication; including RACI on who does what.
    • Notification commitments for breaches, compromised credentials, or issues that may affect integrity, availability, or confidentiality of your data or operations.

    5. Audit, certification, and assurance evidence

    Independent assurance is useful but not a guarantee of compliance or security performance in your specific context. For critical suppliers, you can reasonably request:

    • Relevant certifications or attestations (e.g., SOC 2 type II reports, ISO 27001 certificates, IEC 62443 component/system certificates where applicable), understanding they may be scoped.
    • Summary of audit scope and exclusions so you know which products, sites, and services were actually assessed.
    • High-level remediation status for significant findings that could affect your SR controls, where the supplier is willing to share this.

    In heavily regulated environments, do not rely solely on third-party certifications. Combine them with your own technical validation, supplier assessments, and change control.

    6. Product lifecycle and integration assumptions

    Because industrial and regulated assets often run for decades, SR controls must be evaluated across the full product lifecycle and in coexistence with legacy systems:

    • Product lifecycle roadmap summaries indicating planned support horizons for major versions that you depend on.
    • Supported environment matrices (OS, database, browser, PLC/drive firmware) to avoid unplanned upgrades just to keep vendor support.
    • Integration responsibility matrix clarifying which party is responsible for:
      • Network segmentation, firewall rules, and zoning
      • Identity and access management integration
      • Log collection and monitoring
      • Backup and disaster recovery implementation
    • Known limitations or constraints of SR-relevant features when used with legacy or multi-vendor stacks.

    This is especially important where a full system replacement is unrealistic due to validation effort, qualification burden, or downtime risk. In such cases, documentation needs to be explicit about residual risks and compensating controls you must implement around the supplier’s product.

    7. What to formalize internally

    To keep this manageable and auditable, define an internal standard for SR documentation from critical suppliers:

    • Supplier tiering and SR impact criteria (e.g., Tier 1: network-connected OT equipment; Tier 2: SaaS managing batch or device history records).
    • Minimum evidence list per tier referencing the categories above.
    • Document control rules for how you store, review, and periodically refresh supplier evidence.
    • Validation and change control linkage so that new supplier evidence (e.g., major patch policies, new remote access methods) triggers impact assessment on validated systems.

    Ultimately, the specific documents you can obtain will depend on the supplier’s maturity, your contractual leverage, and your regulatory context. Focus on obtaining enough documented evidence to:

    • Understand how their SR controls actually work.
    • Identify which responsibilities fall to you vs the supplier.
    • Support your own risk assessments, validation, and audits without implying guaranteed compliance.

  • How do I document human accountability when AI is involved in decisions?

    Document it as a controlled decision record, not as a vague statement that a person was “in the loop.” The record should show what the AI recommended or generated, who had authority to review it, what information that person considered, what decision they made, and where that action was captured in the system of record.

    In practice, human accountability is documented when you can trace five things for each consequential decision:

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

    • Decision context: the workflow, batch, work order, deviation, inspection, scheduling event, or other business event involved.
    • AI contribution: the model output, confidence or ranking if available, input data version, prompt or ruleset where applicable, and timestamp.
    • Human reviewer: the named role and identified individual who reviewed the output, including their approval authority.
    • Human action: approve, reject, modify, escalate, or request more evidence.
    • Reason and evidence: the basis for the decision, especially when the human overrides the AI or accepts a high impact recommendation.

    If you cannot reconstruct those elements later, accountability is weak even if someone technically clicked an approval button.

    What the documentation should include

    For regulated manufacturing and operations, a useful minimum record usually includes:

    • Unique record ID linked to the governed process record, such as MES transaction, NCR, CAPA, DHR, routing step, maintenance event, or planning exception.
    • Version of the AI model, rule set, or service used at the time.
    • Source data references and whether the data was complete, missing, stale, or manually entered.
    • The exact output shown to the user, not a later summary.
    • The human decision maker and, if different, the person who executed the resulting transaction.
    • Approval limits or decision thresholds that determine when escalation is required.
    • Any override reason code and free-text rationale.
    • Electronic signature or equivalent controlled approval mechanism where required by your process.
    • Audit trail showing creation, review, change, and final disposition.

    This is less about proving that AI was correct and more about proving who was responsible for dispositioning the outcome and under what controlled conditions.

    What not to do

    Do not rely on policy language alone, such as “users remain responsible for all AI-assisted decisions,” if the systems and records do not support that claim. That kind of statement does not establish accountability by itself.

    Also avoid designs where AI outputs are copied into email, chat, or spreadsheets and then acted on outside the validated workflow. In brownfield plants, this is common, but it breaks traceability, fragments evidence, and makes later review difficult.

    How to assign accountability clearly

    The most reliable approach is to define accountability by decision type, not by tool. For each decision class, specify:

    • Who may review AI output
    • Who may approve or reject it
    • What evidence is mandatory before approval
    • When a second review is required
    • When AI output is advisory only and cannot auto-disposition the event

    That matters because “human accountability” means different things for different use cases. A planner accepting a low risk schedule suggestion is not the same as an engineer approving a quality disposition or a supervisor releasing production after an exception.

    Where the impact is high, documentation should show that the human exercised independent judgment rather than rubber-stamping the recommendation. If your process does not require any rationale for acceptance or override, that may be a control gap.

    System design matters

    Documentation quality depends heavily on system integration. If AI sits outside MES, ERP, QMS, PLM, or document control and writes back only a final answer, you may lose key evidence about what was reviewed and why. In many plants, the practical answer is coexistence: keep the approval and governed record in the existing system of record, and store the AI interaction metadata in a linked evidence trail.

    That usually means:

    • AI service generates recommendation or draft
    • Existing workflow system remains the authoritative approval point
    • Identifiers, timestamps, versions, and reviewer actions are synchronized across systems
    • Change control defines what happens when the model, prompt logic, or source data mapping changes

    Full replacement strategies often fail here because they expand validation scope, disrupt qualified workflows, and introduce downtime and integration risk across long-lived assets and legacy applications. In regulated environments, it is usually safer to add controlled AI-assisted steps around existing decision records than to replace every approval path at once.

    Limits and failure modes

    Documenting accountability does not remove the underlying risks. Common failure modes include:

    • Users approving recommendations they do not understand
    • Poor source data quality leading to misleading outputs
    • Model or prompt changes that are not versioned or reviewed
    • Shadow use outside approved workflows
    • Approval records that identify the user but not the reasoning
    • Overstated assumptions that a signature means the reviewer saw the same output later investigators can see

    If your plant cannot reliably version data, model behavior, and workflow configuration, your accountability record will be incomplete no matter how good the policy looks.

    A practical documentation pattern

    A workable pattern is to require a decision log entry for each AI-assisted action above a defined risk threshold. The log can be embedded in your existing workflow if the platform supports it, or linked as a companion record if it does not. The key is that it is controlled, attributable, time-stamped, reviewable, and retained under the same record governance rules as the underlying process.

    So yes, you can document human accountability when AI is involved, but only if the accountability is designed into the workflow, authority model, audit trail, and change control process. If AI recommendations are informal, unversioned, or disconnected from the governed record, the documentation will not hold up well under internal review.

  • What non-conformance records might FAA or EASA request during an audit?

    FAA and EASA do not work from a fixed, universal checklist of non-conformance records. Instead, they sample evidence that shows your approved processes are being followed and that safety and airworthiness risks are being controlled. In practice, that typically includes the following categories of non-conformance (NC) records and related evidence.

    1. Non-conformance reports and defect records

    Auditors commonly request examples of:

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

    • Internal non-conformance reports (NCRs) / nonconformance documents raised on parts, assemblies, software, tooling, or processes.
    • External / supplier non-conformance reports and incoming inspection rejections.
    • Concessions, deviations, or waivers raised against design or process requirements.
    • Rework and repair records tied to specific NCs, including re-inspection evidence.
    • Scrap records where material was dispositioned as scrap due to non-conformity.

    They will usually trace from a part, lot, or order back into at least one NC case to confirm that detection and documentation are functioning as defined in your procedures.

    2. Disposition, MRB, and engineering decision records

    Authorities typically focus on how non-conformances were evaluated and dispositioned, not just that they were logged. Expect requests such as:

    • Material Review Board (MRB) records, including documented dispositions (use-as-is, repair, rework, scrap, return to supplier) and justification.
    • Engineering dispositions and approvals for deviations from type design or approved data.
    • Evidence that required signatories (e.g., DER, DOA, delegated engineering, quality) were involved where your procedures require it.
    • Records showing that limits of authority were respected (what shop, MRB, and quality are allowed to decide vs. what must go to design or the approval holder).

    Inadequate justification, missing approvals, or unclear authority boundaries are common audit findings.

    3. Corrective and preventive action (CAPA) records

    For systemic or repeated non-conformances, FAA or EASA will usually expect to see how you addressed root cause. They may request:

    • Corrective action requests linked to significant NCs, escapes, or customer complaints.
    • Root cause analysis records (e.g., 5-Why, fishbone diagrams, FMEA updates) demonstrating structured investigation.
    • Implementation evidence for corrective actions (procedure changes, tooling updates, software changes, training, etc.).
    • Verification of effectiveness (data trends, reduced recurrence, audit or inspection results).
    • Preventive actions where risks were addressed before recurrence or escape.

    Authorities often test whether you escalate appropriately: which non-conformances stay local and which trigger formal CAPA under your quality system.

    4. Traceability and genealogy related to non-conformances

    Beyond isolated NC records, auditors will usually test how you contain and trace issues. They may ask for:

    • Traceability from an NC to affected lots, serial numbers, batches, and delivered products.
    • Evidence of containment actions: holds, quarantines, stock sweeps, and recall decisions.
    • Configuration and revision status of the affected products and processes at the time of non-conformance.
    • Linkage between NC records and associated work orders, travelers, inspection plans, and as-built/as-maintained records.

    Weak linkage between NCs and product genealogy is a significant risk area, especially in brownfield environments where ERP, MES, and QMS are not fully integrated.

    5. Supplier-related non-conformance records

    Regulators pay close attention to how you control and react to supplier issues. They often request:

    • Supplier non-conformance reports, including delivery rejections and quality notifications.
    • Records of supplier corrective actions, including verification of effectiveness.
    • Evidence of flow-down of airworthiness or criticality requirements to suppliers.
    • Supplier performance metrics or trend reports where NCs are aggregated and analyzed.

    In complex supply chains, they may trace a single NC from your shop floor back through multiple tiers to understand systemic risk.

    6. Concessions, deviations, and repairs to approved data

    Where non-conformances affect airworthiness or type design, auditors often sample:

    • Deviation permits, concessions, or waivers, including justification and scope limitations.
    • Repair approvals, references to approved repair data, and evidence that approved instructions were followed.
    • Evidence of feedback to the design organization (e.g., DOA, TC/PC holder) for recurring deviations.
    • Records showing that any deviation from approved data was appropriately controlled and not applied outside its scope.

    Here, traceability to approved design or repair data and clear boundaries of authorization are critical.

    7. Rework, re-inspection, and re-release records

    Authorities may want to see that once a part or assembly is found nonconforming, it does not re-enter the system without proper control. Typical evidence includes:

    • Rework instructions and routing changes linked to the original NC.
    • Post-rework inspection and test results.
    • Updated as-built, as-repaired, or maintenance records reflecting the work performed.
    • Final acceptance and release records indicating the basis for restoring conformity.

    Audit findings often arise where rework is done informally or not fully captured in the traceable record.

    8. Trending, analysis, and management review inputs

    At the quality system level, FAA and EASA may request evidence that you analyze NC data and act on trends. Examples include:

    • Non-conformance trend reports by part family, line, process, or supplier.
    • Risk assessments where recurring NCs affect safety, reliability, or continued airworthiness.
    • Inputs to management review that summarize NC performance and CAPA status.
    • Decisions and actions recorded from management review meetings.

    Authorities are looking for a closed loop: detection, correction, analysis, and prevention.

    9. How system coexistence affects what you can show

    In brownfield environments, non-conformance information is usually scattered across QMS, MES, ERP, and sometimes spreadsheets. This affects what you can readily provide during an audit:

    • If systems are not integrated, be prepared to manually demonstrate linkage (e.g., NCR number to work order to serial number).
    • Interfaces and data transfers should themselves be under change control and validation where your procedures require it.
    • Replacing legacy systems solely to “look better” in audits is risky; regulators care more about control, traceability, and evidence than about specific tools.

    Weak integration does not automatically mean non-compliance, but it raises the burden on local procedures, training, and evidence retrieval during audits.

    10. Constraints and variations you should account for

    The exact non-conformance records requested will depend on:

    • Your approval basis (e.g., Part 21, Part 145, Part 145 approval in Europe, POA/DOA arrangements, production vs. maintenance).
    • The scope of the audit (system-level vs. product-specific, initial approval vs. continued oversight).
    • Your own documented procedures and how you define and categorize NCs, CAPA, and MRB.
    • Past findings, occurrences, or incidents that may trigger targeted sampling.

    There is no guarantee that a specific set of records will satisfy an auditor; what matters is consistency with your approved system, clear traceability, and evidence that non-conformances are controlled, analyzed, and fed back into continuous improvement.