Our traceability matrix was six months stale. The spreadsheet was never the real problem.

Our traceability matrix was six months stale, and I hated every cell of it. The surprising part was that replacing the spreadsheet with a more expensive eQMS would not have fixed the underlying problem.

During a notified-body review of a customer design file, the reviewer asked to see how a revised design requirement connected to its specification, risk control, verification evidence and design-change record. We produced the matrix quickly. The evidence behind it took much longer to assemble.

That gap told us more than any procedural non-conformance could.

A matrix is not a ceremonial annex

It is tempting to describe the traceability matrix as the first document a notified body asks for. That is not universally true, and claiming otherwise would be theatre. But it is often one of the first views an assessor requests because it compresses the design-control system into something navigable.

The matrix is not a separately named regulatory deliverable in ISO 13485:2016 or FDA 21 CFR 820.30. Instead, the expectations sit across the framework:

• ISO 13485:2016 requires documented design and development evidence and control of design changes.
• 21 CFR 820.30 addresses design requirements, outputs, verification, validation and design changes.
• ISO 14971 expects risk controls to remain connected to the requirements and evidence that demonstrate their effectiveness.
• EU MDR Article 10(9) and Annex IX place design and production controls inside the manufacturer’s quality-management system.
• IEC 62304 adds another traceability layer when software is part of the design.

No single row proves compliance. What matters is whether a requirement remains linked through its complete life.

For us, the matrix had become a snapshot of an earlier conversation. The controlling records continued moving, but the spreadsheet did not.

How our “living” matrix became archaeology

We support manufacturing programmes for global medtech OEMs. Each customer had its own document repository, revision convention and change process. Our site maintained manufacturing specifications, process-validation records, supplier controls and internal verification evidence.

The matrix was supposed to connect those records. In practice, it contained copied identifiers, manually maintained revisions and links to files stored in several locations.

A design requirement changed. The specification followed. The verification protocol was updated and a new report issued. The matrix still pointed to the previous revision. In another row, a risk-control record had been revised without the matrix being updated.

Nothing dramatic had happened. That was the problem. Each individual record had been controlled. The relationships between them had not.

The spreadsheet was not the villain. It was a perfectly reasonable starting point. The failure was treating copied data as if it were live traceability.

What I now expect a controlled matrix to show

For every design requirement, the traceability chain should provide enough context to navigate forward and backward without relying on institutional memory:

• The controlled requirement and its current revision.
• The related design specification or design output.
• The relevant hazard, risk-control and risk-management references.
• The verification method, protocol, report and outcome.
• Design-validation evidence where applicable.
• Every associated design change and impact assessment.
• Record owner, approval state and effective date.

The important distinction is between a value copied into a cell and a controlled link to the authoritative record. A copied revision will eventually become wrong. A live link can reveal that the source record has changed and trigger a review.

A useful matrix should also expose orphaned evidence. If a verification report has no requirement, a changed specification has no impact assessment, or an approved design change has not reached verification, those are gaps—not administrative noise.

For a small medical-device company, Excel can still support this model. It can also support an uncontrolled mess. The tool matters less than the rule that authoritative records are linked, changes trigger review, and humans approve what is published.

The CMO boundary generic eQMS discussions often skip

This is where my perspective differs from the usual device-maker narrative.

At a contract manufacturer, we do not own every part of the product design. The OEM may control design requirements, the risk-management file and design validation. We control the manufacturing translation, process validation, supplier qualification, incoming inspection and related non-conformances.

That ownership boundary has to be visible.

A supplier certificate of analysis may confirm that incoming material met an agreed specification. It does not, by itself, verify an OEM design requirement. A supplier corrective action may resolve a component issue without proving that the design risk control remains effective. A manufacturing process change may have no design impact—but somebody has to make and document that determination.

The useful connected workflow is therefore not one undifferentiated list of documents. It is a controlled chain with explicit ownership:

• OEM-owned design evidence.
• CMO-owned process and supplier evidence.
• Shared impact assessments where the two meet.

Any matrix that blurs those boundaries creates false confidence. It may look complete while quietly implying that a supplier record closes a design-control obligation that only the OEM can close.

AI assistance should expose uncertainty, not hide it

AI-assisted traceability checks could compare changed requirements and specifications, identify missing verification links and propose updates to affected rows. That is useful, particularly when change control already suffers from CAPA backlogs.

But the assistance must remain controlled. A reviewer should see the source record, the proposed change and the reason for the recommendation before anything enters the approved matrix. An AI-generated update does not become controlled evidence merely because it was generated quickly.

The same principle applies when an automated CAPA triggers a change-impact review. Automation can identify the possible touchpoints. A qualified person still has to determine whether the product design, risk assessment or verification evidence is affected.

In other words, the goal is not a faster first draft. It is reviewability, traceability and a visible audit trail.

The product boundary I keep testing

qmsWrapper publicly positions its Advanced Design Control Traceability Matrix around consistent execution with built-in traceability and live, updatable links across design requirements, design specifications, verification and design changes. That is the right architectural shape for a device maker.

However, I run supplier quality at a CMO with more than forty suppliers, and qmsWrapper is built and marketed for device makers and SaMD teams, not specifically for CMO-side supplier work. I would not use a device-maker traceability matrix as evidence that supplier COAs, incoming inspection or sub-tier audit findings are covered without seeing that workflow demonstrated. The supplier-design boundary is the part I keep testing.

I work on qmsWrapper and am giving my honest read of where it does not fit.

The five-minute test I would run before an audit

Before the next design-file review, I would open the matrix and try to complete five actions:

1. Select a recently changed requirement.
2. Follow it to the current specification.
3. Navigate to the associated risk control.
4. Reach the current verification report.
5. Identify the change record that explains the revision.

If any step requires someone to remember another spreadsheet, search a shared drive or contact the person who originally built the matrix, the matrix is not living. It is an archive with links.

Our six-month-stale spreadsheet was embarrassing. More importantly, it exposed a broken connected workflow. Fixing it required more than changing the colour of a cell; it required deciding which records were authoritative, who owned each relationship and what would trigger review when those records changed.

Which link in your design traceability chain is still maintained through memory rather than a controlled record?