A design change record has to reopen the risk file

A design change record too often reads like an approval log: what changed, who asked for it, who signed off, done. ISO 13485:2016 Clause 7.3.9 — the clause that now governs this under FDA's QMSR as much as under CE marking, since QMSR's February 2, 2026 compliance date incorporated the standard directly — asks for something closer to a second design review than a signature line. Not just whether the change works, but what it touches on its way through a file that was already closed.

The clause after the file is closed

Verification and validation and then transfer close out a design file's first pass through Clause 7.3 — the output is confirmed against the input, confirmed against the user's actual needs, and handed to manufacturing as a production specification. Clause 7.3.9 governs what happens when that closed file has to reopen: a component substitution forced by a supplier, a software patch, a labeling correction, a tolerance tightened after a field complaint. The clause doesn't treat this as a lighter-weight process than the original design effort. It treats it as the same kind of review, scoped to what actually changed.

Identified, reviewed, verified, approved — before, not after

The sequence in 7.3.9 matters as much as its contents: changes are to be identified, documented, and as appropriate reviewed, verified, validated, and approved before their implementation. “Before implementation” is the phrase doing the real work. A change record written after the revised part is already on the line documents a decision that's already been made, not a review that could have stopped it. A record that shows the review, verification, and approval dates all trailing the effective date of the change hasn't satisfied the clause — it's kept the paperwork the clause requires without doing the thing the paperwork is supposed to prove happened.

What the review actually has to weigh

Before any of that sequencing, the organization has to determine the significance of the change — to function, performance, usability, safety, and applicable regulatory requirements for the device and its intended use. That determination sets how much of the rest of 7.3.9 applies: a change significant enough to affect performance or safety earns the full review, verification, and validation cycle; a change that clearly doesn't still has to be documented and reasoned through, not waved past. The review itself has to evaluate the effect of the change on constituent parts and on product already delivered — not just the next unit off the line, but the units already in the field under the specification being replaced.

The risk file reopens too

The part of 7.3.9 most often skipped is its own explicit line: the review has to evaluate the effect of the change on the inputs or outputs of risk management. A design change control record that never touches the risk management file has skipped exactly the analysis the clause names outright, not some adjacent good practice. A component substitution can shift a failure mode's probability without touching its severity; a software patch can close one hazard while opening another the original risk analysis never considered. Where the change is significant enough to move a hazard's numbers, it can force the file back to the question Clause 8 of ISO 14971 already asks about overall residual risk — not just whether this one hazard is still acceptable, but whether the device's overall risk-benefit balance still is, now that one input to it has moved.

A different question than a new 510(k)

7.3.9's review and FDA's own question — whether a given change requires a new premarket submission under 21 CFR 807.81(a)(3) — are related but not the same decision, and a change record that only answers one has left the other unanswered. The 807.81 test asks whether the change could significantly affect safety or effectiveness enough to require FDA's review before the changed device ships. 7.3.9's test runs regardless of the answer to that question: even a change that clearly doesn't need a new 510(k) still has to be identified, reviewed against risk management, and approved before implementation under the QMS. A checklist built for this record has to carry both questions as separate rows, not one asked in place of the other — which is the shape of the design-change template previewed in the launch catalog. A team that's built a cleaner version of that trace is exactly who the contribution page is for.