The change request was 40 words. Its impact touched six files, the risk file, and a validation protocol.

The email was one paragraph, sent on a Friday afternoon by a supplier I had never spoken to.

They were changing the polypropylene resin in the sterile barrier pouch we used for our surgical sets. "Nothing about the device is changing," they wrote. Also true, and also not true.

What was actually changing: whether our validated packaging process remained validated, whether the risk file still described the pouch, what the DHF claimed about packaging, whether the sealing validation had to be repeated, and whether the sterilisation instruction in the IFU still matched the process. In our QMS, that email became an attachment to a change request that sat in someone's inbox for eleven months. We found it during a surveillance audit, because the auditor did not ask for the change form. They asked what had changed since the last audit and wanted the evidence.

The change that was not a change

Every manufacturer has a version of this: a supplier's resin, a second source for a component, a firmware patch, a label artwork revision, a contract cleanroom's new oven.

The trap is the phrase "the device is unchanged". It is usually true at the level of the device specification and false at every level the standards care about. A material in a sterile barrier is part of packaging validation (ISO 11607-1 and -2); the sealing process sits under ISO 13485:2016 clause 7.5.6, not under a general "supplier housekeeping" exemption. A software patch that touches a risk control is a design change the moment it alters intended performance, whatever the release note calls it.

The other trap is quieter: deciding that nothing significant happened is itself a regulated decision. If you make it, you need a record saying so, with the reasoning attached at the time. Silence is not a finding.

What the standards actually ask for

When I strip our change process back to what is genuinely required, the list is shorter than most templates assume:

• ISO 13485:2016, clause 4.2.3 — a medical device file (DHF) per device type, including the risk management documentation. It is not a deliverable produced at the end of a project; it is a maintained set of records.
• Clause 7.3.9 — design and development changes shall be identified, documented, reviewed, verified and validated as appropriate, and relevant documents amended. "As appropriate" is where auditors live, so the justification belongs in the record, not in the reviewer's head.
• Clause 8.5.6 — changes to production and service provision are controlled with the same rigour. Our resin change lived here, not in 7.3.9.
• Clauses 7.5.1 and 7.5.6 — where output cannot be fully verified by subsequent monitoring, the process is validated, and a change to its inputs is a trigger to revisit that validation.
• Clause 7.1 — risk management runs through product realisation, not only at design freeze. A supplier substitution is a risk file event.
• Clause 4.2.5 — records legible, readily retrievable, retained at least for the lifetime of the device as the organisation defines it, and in any case not less than two years from release.
• FDA QMSR (21 CFR Part 820, effective 2 February 2026) — Part 820 now incorporates ISO 13485:2016 by reference (§ 820.7). The old QSR's design-change clause (§ 820.70) is gone; that content sits inside ISO 13485's 7.3.9 and 8.5.6. FDA-specific record duties remain in § 820.35, with UDI (21 CFR Part 830) and corrections and removals (Part 806) alongside.
• EU MDR 2017/745 — the DHF equivalent is the Technical Documentation under Annexes II and III, and the same change assessment feeds the significant-change classification that notified bodies apply (MDCG 2020-3).

Not one of those clauses asks for a form with checkboxes. They ask for evidence that a change was understood everywhere it mattered, and that the decisions were documented when they were made.

What we tried, and what it cost

We started with a spreadsheet change log. Version names in cell A1, a second sheet for impact, a third for approvals. It worked until two people were in it at once, at which point the truth was whichever copy you opened last.

Then we tried an "impact assessment matrix": design, manufacturing, supplier, regulatory, each with a yes/no/no-impact checkbox. Six reviewers, six interpretations, one recurring argument about what "no impact" meant. The language was too coarse to carry a decision, and the decision was the whole point.

Then an annual DHF refresh. A tidy, indexed set of PDFs, current on the day it was printed and stale within a sprint, because the PDFs had no connection to the live engineering records. Legacy links rotted quietly, and nobody noticed until an auditor did.

Each attempt treated traceability as a document to maintain. It is not. It is a relationship between events and records, and it only works if the relationships are live.

What event-driven actually means in practice

The phrase gets used loosely. For me it means one thing: an event generates mandatory downstream actions, and those actions are connected to the records they touch, rather than relying on someone to remember the list.

Concretely, that means:

• Every event type has defined destinations. An approved material change, a supplier change, a complaint, a non-conformance, a CAPA — each one obliges a defined set of records to be reviewed and updated.
• The impact list is derived from the change itself. Design inputs, drawings, BOM, supplier specifications, the ISO 14971 risk file, process validations, V&V protocols, the DHF or Technical Documentation, UDI, registration and declaration records. The list is generated by what the change touches, not by what the requester remembered.
• The decision rationale attaches at the time. Who decided, on what evidence, with which validation outcome behind it. Reconstructing that a year later is archaeology, and it does not survive an audit.
• The relationship runs both ways. From any DHF record to the change that justified it, and from any change to every record it moved.

That is what a single source of truth has to mean for traceability: one place where change, CAPA, risk, document control and suppliers are connected, not five places that export to each other overnight.

Where AI helps, and where it does not

I have watched teams adopt AI-assisted impact mapping with real enthusiasm, and the enthusiasm is warranted in one narrow place: candidate generation from precedent. If we have 300 closed change records with consistent impact data, a model can propose a plausible impact list in seconds. That is real time saved on the mechanical part.

The boundary is the decision. Whether a change is significant, whether existing validation remains adequate, whether risk acceptability still holds — those stay human, signed, and traceable to evidence.

Reviewability is the test I now use. If an assistant proposes an impact and I cannot see which records it based that on, the proposal is a rumour. If generated text can enter the DHF unreviewed, the traceability gains are imaginary. To be fair, assisted mapping also needs a curated precedent library and disciplined record quality; without them it just produces plausible-sounding guesswork faster, which is worse than a blank form because people trust it.

What I would do differently

• Write the event-to-destination matrix before buying anything or writing any software. Until you can name, for each event type, exactly which records must be revisited, you cannot automate anything sensibly.
• Treat "no change" as a finding. Record it, justify it, sign it, and date it.
• Put revalidation triggers on supplier changes explicitly: material, site, process, sub-tier, and any change to the supplier's own change notification terms.
• Design for the audit you will actually get. Pull three random changes and walk both directions — event to record, record to event — in minutes. If that takes an afternoon, the traceability is documentation rather than a system.
• Keep the decision with the person who owns the process, and keep the record close enough to the event that nobody has to reconstruct it.

We are still, to this day, a hybrid: a controlled electronic system for the workflow and records, plus a great deal of professional judgement in the gaps. The difference is that the gaps are now visible and reviewable rather than invisible and permanent.

Which single event type — change, CAPA, complaint, or supplier — would you fix first in your own traceability, and what would "fixed" actually look like when an auditor asks you to demonstrate it?