Supply Chain Traceability: What to Send Suppliers and What to Get Back

In February 2026, a United Kingdom court sentenced the director of AOG Technics to four years and eight months in prison. Between January 2019 and July 2023 his company sold over 60,000 aircraft engine parts, most of them for the CFM56, with forged Authorised Release Certificates. Groundings cost airlines and manufacturers an estimated £39.3 million. Every buyer in that chain took a release certificate at face value. The fraud came to light when an airline checked a certificate with the engine manufacturer.

Traceability holds up inside one company and breaks where two companies meet. No file format carries everything the receiving side needs, and the contracts and change notifications meant to cover the difference are agreed before anyone knows which attributes will move. Supplier audit reports lost their exemption from a United States device inspection on February 2, 2026, and defense electronics suppliers came under a new record-retention standard in November 2025.

This guide covers what medical device and aerospace inspectors now expect of supplier controls, how requirements cross the original equipment manufacturer (OEM) to supplier boundary, and where the chain breaks.

What Supply Chain Traceability Means for Requirements

In regulated product development, supply chain traceability is an engineering question about whether the thing a supplier delivered satisfies the requirement allocated to it, and whether anyone verified that it did. Product traceability in regulated industries answers the unit-level question of where a lot or serial number went, and this guide answers the requirements question that runs alongside it.

Forward and Backward Links Across the Chain

Forward links run from every requirement to its implementation, including the design element and component that satisfy it, and then to the applicable test. ISO/IEC/IEEE 29148 prescribes that chain, a requirements engineering standard published jointly by the International Organization for Standardization (ISO), the International Electrotechnical Commission (IEC) and the Institute of Electrical and Electronics Engineers (IEEE). Backward traceability links connect each artifact to the source requirement that justifies it.

Four Kinds of Artifact the Chain Covers

For a regulated product with suppliers, the chain covers four kinds of artifact:

• Requirements: User needs flowed down through system and subsystem layers to components, with the allocation recorded on both sides.

• Parts and lots: Records cover physical components and material certifications, and they are what survives a counterfeit-part inquiry.

• Software components: Software of Unknown Provenance (SOUP), commercial off-the-shelf (COTS) code and open-source libraries are identified by name, version and manufacturer.

• Test evidence: Verification and validation records that link back to the specific requirement and version they verified.

Which Standards Require Traceable Links

Software Considerations in Airborne Systems and Equipment Certification (DO-178C) requires bidirectional traceability across requirements and source code, with links to test evidence. Design Assurance Guidance for Airborne Electronic Hardware (DO-254) carries the same obligation on the hardware side.

ISO 26262, the road-vehicle functional safety standard, expects traceable links running from safety goals through technical safety requirements to verification. Under IEC 62304, the medical device software lifecycle standard, and the Quality Management System Regulation (QMSR) that now governs United States device manufacturers, software requirements and risk analysis need traceable links to design outputs.

What Inspectors and Auditors Now Expect From Supplier Controls

Records that used to sit outside a United States device inspection are now inside it, and in aerospace and defense the duty to prove where a part came from reaches every tier by contract. Both changes landed within the last two years.

Medical Devices Under the QMSR

The QMSR took effect on February 2, 2026, and amends Title 21 of the Code of Federal Regulations Part 820 by incorporating ISO 13485:2016 by reference. ISO 13485:2016 Clause 7.4 now carries the supplier duties. It requires documented selection and re-evaluation criteria, verification proportionate to risk, and a written agreement that the supplier notify the manufacturer of changes affecting the purchased product before implementing them.

A one-time qualification record doesn’t satisfy the ongoing monitoring obligation, and approval needs reassessment when enforcement action, an ownership change, or new critical subcontracting alters the supplier’s risk profile. Between them, those requirements pull a supplier inside the manufacturer’s own change management process.

FDA retired the Quality System Inspection Technique on the same date and replaced it with Compliance Program 7382.850. Investigators review a manufacturer’s risk management documentation throughout an inspection to understand product risks and controls. The QMSR also removed the exemption at 820.180(c) that used to keep supplier audit reports, quality audits and management reviews out of an FDA inspection.

Aerospace and Defense Part Provenance

AS9100 Rev D’s purchasing flow-down clause requires primes to pass counterfeit-part prevention, nonconformance and change notification, and right-of-access terms down to every tier of the supply chain. For electronic parts on defense contracts, Defense Federal Acquisition Regulation Supplement (DFARS clause 252.246-7007) requires a detection and avoidance system that tracks electronic parts from the original manufacturer to government acceptance. The requirement flows down to subcontractor tiers that buy, sell or authenticate electronic parts or assemblies containing them.

SAE International AS5553E, current since November 2025, extends the same flow-down to companies that procure and integrate electrical, electronic, and electromechanical parts and adds record retention requirements. A provenance chain connects the received part to its manufacturer and purchasing records, and links the inspection or authentication evidence to the assembly the part went into.

How Requirements and Evidence Cross the OEM-to-Supplier Boundary

An interface agreement between the two companies defines which requirements and evidence the OEM sends and which the supplier returns.

Interface Agreements Assign the Work Products

The Development Interface Agreement (DIA) in ISO 26262 assigns responsibility for each work product exchanged between customer and supplier. When the OEM allocates safety requirements, the supplier’s verification evidence needs to trace through a shared or linked requirements traceability matrix to the OEM’s safety goals. ISO/SAE 21434 does the same for cybersecurity with the Cybersecurity Interface Agreement (CIA). A useful CIA names the allocated activities, the evidence, the responsibilities and the contacts.

A supplier test report that cites a requirement identifier without the revision cannot be matched to the baseline it verified. The OEM has no way to tell whether the test predates the last change. Naming the identifier and the revision on returned evidence is part of what the agreement assigns.

ReqIF Mechanics and Where They Fail

Requirements Interchange Format (ReqIF) is the usual file format for OEM-to-supplier exchanges when the two companies run different requirements tools. ReqIF carries requirement text and attributes while preserving the document hierarchy, and identifies each item with a globally unique identifier so the same item can be recognized across rounds.

Two companies working in separate repositories have no shared state to fall back on, so a reliable round trip depends on two controls both sides agree before the first file changes hands. Attribute mapping settles the common data model, covering attribute types, link types, allowed values and formatting, before the first exchange. Baseline and write-back control comes next, with each exchange recording the approved baseline and the recipient confirming the revision before continuing work. The write-back rule names the attributes the supplier may edit, then filters returned data so OEM-controlled fields cannot be changed unintentionally.

Miss either control and the failure is quiet. The supplier works from a superseded baseline, or an attribute the OEM owns comes back overwritten. Neither shows up until someone reconciles the two repositories. Automotive SPICE 4.0 merged traceability and consistency into a single base practice. On programs running Automotive Software Process Improvement and Capability Determination (Automotive SPICE or ASPICE) alongside ISO 26262, a trace matrix whose links nobody has read for meaning no longer satisfies an assessment.

Inherited Software Components: SOUP and Software Bill of Materials (SBOM) Obligations

IEC 62304 requires manufacturers to identify each SOUP item by name, version and manufacturer, and to document its requirements and prerequisites. Published anomaly lists have to feed into risk analysis, and monitoring has to continue after release for new anomalies and security vulnerabilities. The depth of that work scales with the software safety class, Class A through Class C.

SBOM regimes ask for much of the same inventory in a different form. A useful component record covers commercial, open-source and off-the-shelf software, and stays connected to risk, anomaly, vulnerability and release information.

The European Union (EU) Cyber Resilience Act begins applying Article 14 vulnerability and incident reporting on September 11, 2026, including to products already on the market. From December 11, 2027, the same regulation requires a machine-readable SBOM covering at least the product’s top-level dependencies, kept current through the support period. A team selling a connected device in multiple regulated markets can hold one governed component inventory that supplies SOUP records, SBOM output and vulnerability monitoring evidence without reconciling separate lists by hand.

Where Supply Chain Traceability Breaks in Practice

Traceability breakdowns appear first in documentation, and audit sampling is what finds them. Under the EU Medical Device Regulation (EU MDR), notified bodies apply stricter documentation scrutiny than the directives it replaced required. An audit can follow a sampled product back through its design and post-market record. One broken chain there reduces confidence in every chain outside the sample.

The four patterns below each start somewhere ordinary:

• Quality agreement as the monitoring record: The signed agreement gets filed as if it proves that supplier monitoring occurred, while current performance and risk evidence remain absent.

• Retroactive matrix assembly: A traceability matrix assembled at the end of a design program leaves the intervening changes undocumented, and unexplained holes suggest a program-wide problem.

• Stale procedure references: Supplier procedures that still cite superseded regulatory provisions after a transition tell an investigator the document hasn’t been reviewed.

• Identification failures at recall: If component records do not connect affected lots or serial numbers to finished products, the manufacturer cannot reliably define the recall population.

The first pattern is what made AOG Technics possible. Buyers held release certificates that had nothing connected back to the engine manufacturer named on them, and the certificate was the only evidence anyone asked for.

The last pattern can create the largest bill because uncertain identification expands the population that must be investigated, contained, notified, or recalled. Connecting supplier records and received material to production history and the final product identifier has to happen before a field event.

How Jama Connect Supports Supply Chain Traceability

In Jama Connect®, the Traceability Information Model defines which relationships a program requires between requirements, design elements, code, tests and verification results. Enforced relationships flag a required downstream item that does not exist. When an upstream requirement changes, Live Traceability™ spreads a suspect flag across every degree of separation downstream, and the engineer either updates the affected item or clears the flag. Each of those actions leaves the auditable decision trail ISO 13485 Clause 7.4 and the DIA described on paper.

Requirements and verification evidence in the chain sit inside that model. Parts, lots and software components stay in the systems that own them, with trace links pointing outward to those records instead of duplicating them. Pre-built frameworks for medical device and Aerospace and Defense development arrive with the item types, relationship rules and review workflows each regime expects, so supplier controls start from a structure aligned to ISO 13485, DO-178C and DO-254 rather than a blank project. Out-of-the-box export templates then build the traceability matrix and the audit artifacts a submission needs out of live project data, which is the evidence an inspector asks to see. Cloud and self-hosted deployments carry the same trace structure, which matters for programs under data sovereignty or air-gapped constraints.

Why One Supplier Baseline Beats an Audit Readiness Review

One supplier baseline, taken through a complete change cycle, tells you more than an audit readiness review does. Follow it from the change notification arriving to the returned verification evidence landing against the revised requirement, and see whether anyone had to rebuild anything by hand. A baseline that comes through intact shows the process can carry a change without manual reconstruction, and one that stalls shows you where.

Jama Connect supports that cycle by keeping the trace links between supplier requirements, changes and verification evidence current as work moves, so the audit reads an existing record. If your supplier evidence only comes together in the week before an inspection, you can start a free 30-day trial today.

Frequently Asked Questions About Supply Chain Traceability

Who owns traceability when the OEM and the supplier use different requirements tools?

The OEM owns the trace to its own safety goals and cannot delegate it, which is why the interface agreement names a responsible party for each exchanged work product. On the supplier side, ownership covers the evidence it produces and the attributes the agreement lets it edit. Where the two tools disagree, the agreed baseline decides, not whichever repository was written to last. In Jama Connect, the agreed baseline and its trace links sit in one repository, so both sides read the same revision.

Do suppliers need their own cybersecurity certification under United Nations Regulation No. 155 (UN R155)?

Tier-1 and Tier-2 suppliers do not need their own certificate. UN R155 puts the Cybersecurity Management System certificate on the vehicle manufacturer, and that certificate stays valid for a maximum of three years before it has to be renewed. The manufacturer does have to demonstrate how its management system handles the dependencies it carries with contracted suppliers, service providers and its own in-house teams. ISO/SAE 21434 is the standard that puts the supplier assessment itself on the customer, covering management system maturity, past threat analysis work and vulnerability handling.

How long do aerospace suppliers have to keep traceability records?

Retention periods are set by the prime contractor’s supplier quality requirements and the contract, and they differ by record type. Check both of those before you design a retention schedule. Custody is the harder problem, because a record that outlives the company holding it needs a named owner and a plan for staying accessible through an ownership change or a closure. Without that, a component’s provenance cannot be reconstructed for an audit, an investigation or a continued-airworthiness decision years later.

This article was authored by Mario Maldari and published on September 14, 2026.