Quality-assurance records review for avionics and equipment suppliers

When this review is needed

• The package is going for review and the QA records have to show each planned audit actually ran.
• Findings from internal audits closed on paper but the corrective-action evidence behind them is missing.
• A process changed mid-program and no one confirmed the audits still check against the current plan.
• A reviewer wants to see that process assurance was independent of the engineering it audited.

The problem

Process assurance is what tells a reviewer the lifecycle was carried out the way the plans committed to. It is also the evidence that gets reconstructed last. Audits are scheduled and then skipped under pressure, findings get closed with a note instead of a record, and the corrective action lives in someone's memory. When the QA trail thins out, the package can show the work was done but not that it was done under control.

What gets reviewed

• The quality assurance plan and the audits and reviews it commits the program to
• Software and hardware quality assurance records against the activities they cover
• The audit history and whether each planned audit produced a recorded result
• Audit findings, their dispositions, and the evidence behind each closure
• The corrective-action trail from a finding to its verified resolution
• The independence of process assurance from the engineering it audits

What gets validated

• Each audit named in the QA plan has a recorded result, not just a schedule entry
• Audit results reference the plan revision and process they were checking against
• Every finding has a disposition and the evidence that supports its closure
• Corrective actions trace from the finding to a verified resolution
• QA records cover the lifecycle activities the assurance plan claims they do
• Process assurance is recorded as independent of the work it audits
• Open findings are visible rather than absorbed silently into a later baseline

Evidence normally required

• The quality assurance plan and the audit schedule it defines
• Software and hardware quality assurance records assembled so far
• The audit findings log with dispositions and closure notes
• The corrective-action records and any verification of resolution
• The lifecycle plans the audits were meant to check process against

Common discrepancies

• Audits listed in the plan with no recorded result behind them
• Findings closed with a disposition but no evidence of the corrective action
• Audit results that check against a plan revision the program has since replaced
• Corrective actions that close without verifying the fix held
• Process-assurance activity that is not recorded as independent of the engineering
• QA coverage gaps where a committed lifecycle activity was never audited

What is at stake

Records that cannot demonstrate the process was followed reopen the question of whether the technical evidence can be trusted at all. A thin QA trail can stall a review that the engineering itself would have passed, because the assurance the engineering depends on is not there to point to.

How the work runs

What the buyer receives

• An assessment of process-assurance coverage against the QA plan
• A list of audits, findings, and corrective actions that are open or unevidenced
• A finding-to-closure trace showing where the corrective-action evidence stops
• A prioritized closure list ordered by the assurance gap each item leaves

Who uses the output

• Quality assurance leads reconstructing the process-assurance trail
• Certification leads confirming the lifecycle was carried out under control
• Engineering teams closing the corrective actions the findings left open

How the work fits into the transaction or program

The review checks the assurance layer that sits over the technical evidence. It pairs with a configuration-management evidence review when the question is which build the data describes, and with a compliance-checklist review when the team needs the objectives themselves checked rather than the process behind them.

Jurisdiction-specific considerations

FAA and EASA both expect process assurance to be evidenced, but the home for it differs. FAA programs lean on the quality assurance records the lifecycle plans commit to, while EASA Part-21 frames process assurance through the design organization's quality system. The audit content overlaps, so the review checks the records against the framework the program submits under rather than assuming the two are interchangeable.

Regulatory limits

Endeavor Elements checks the applicant's quality-assurance records for completeness, consistency, and traceability. It does not audit on the authority's behalf, make compliance findings, or issue any approval. The applicant's quality system and the authority keep their roles.

What this review does not cover

• Acting as the authority or making official compliance findings
• Running the supplier's internal audits or operating its quality system
• Generating the corrective-action evidence the records are missing

Specific to this review

• Process assurance is the evidence most often reconstructed last, which is why skipped audits and undocumented closures are the dominant finding.
• A finding closed without corrective-action evidence is indistinguishable from a finding ignored, so disposition notes alone do not survive review.
• Audits that check against a superseded plan revision give false assurance: the process they confirmed is no longer the process the program runs.
• Independence is a record, not an assumption; assurance that cannot show separation from the engineering it audits carries little weight in review.

Sources

Frequently asked questions

Relevant glossary terms

Related pages

Where this fits