The "minor change" paradox — when one-line fixes turn into three days of change control

Last March I caught a typo in an IFU. One word, wrong, on a single page. I knew it would take five minutes to fix in InDesign and ten minutes to get re-approval. Total elapsed time, including the coffee break I planned to take after: half an hour.

It took me three days.

That is the minor-change paradox. The change is trivial; the documentation around it is not. And if you skip the documentation, you will discover why at your next audit.

Let me show you what those three days actually contained.

What "one line of work" expanded into

The typo was on page 7 of an instruction for use for a Class IIb device. The word was "subcutaneuous". My morning looked like this in the end:

• Pulled the document from the controlled documents register and confirmed revision status
• Confirmed the typo was not already captured by an open change request (it was not)
• Checked whether the same typo existed in any other language version — five were in scope
• Opened a change request, described the change, classified it under the change control SOP
• Risk-graded the change: low severity, low probability, no clinical impact — but still documented
• Checked impact on linked documents: the Declaration of Conformity references the IFU revision, the labelling matrix references the IFU, the PMCF plan references the IFU. None changed in substance, but the version pointer needed an update in two of them.
• Got the change reviewed by QA, by the SME for the device, and by the original IFU content owner
• Got QA approval, raised the IFU revision, re-released to the controlled library
• Updated the version pointers in the two linked documents (separate change request, separate approvals)
• Closed both change requests, logged the audit trail, filed evidence in the Technical File

The actual word change took the five minutes I expected. The rest is what change control is.

What the standards actually ask for

This is not bureaucracy invented by my SOP writer. It is what the framework requires, across three overlapping instruments.

ISO 13485:2016 Section 8.5.6 requires the organisation to evaluate changes, determine their significance, perform a risk-based review, and approve changes before implementation. The standard does not say "unless it is small". The phrase "any change" is doing real work in that clause.

FDA 21 CFR 820.70 covers design changes and explicitly requires written procedures, review and approval before implementation, and evaluation of the change's effect on the product. The expectation is documentation proportionate to risk — but documented is the operative word.

Under EU MDR, the manufacturer's general obligations in Article 10 include keeping the Technical File up to date. Annex II paragraph 6.1 requires a documented change control procedure. MDR does not have a "trivial change" carve-out either. Granted, Article 120 gives some breathing room on legacy devices, but the change control obligation itself is unchanged.

To be fair, all three frameworks allow you to scale the rigour. A one-character typo in an IFU is not a design change. It is a document control change. But it still has to be a document control change, not a person quietly editing a PDF and pushing it to the print queue.

Why "just fix it" is the dangerous instinct

I have watched junior engineers do this. They see a small error, they fix it, they push the new revision to manufacturing. The audit trail shows the wrong word for fourteen months, then the right word, with no change record. The first time a notified body auditor asks "what happened between revision 4 and revision 5?", the answer is silence and the finding is a major non-conformity.

This is the bit I think gets lost in change-control-fatigue conversations. The audit trail is not there to annoy you. It is the evidence you need when, three years from now, a competent authority asks you to demonstrate continuous control of your Technical File. Without it, "minor" becomes "major" very fast.

What I would do differently next time

Three things, with hindsight:

1. Treat the typo-fix path as a pre-baked change template. Not a free-form change request — a pre-filled record with the impact analysis, the linked documents, the approvals. Halves the elapsed time on the second iteration onwards.
2. Stop pretending "version pointer update" is the same change as the substantive fix. Separate change request, separate approval, separate audit trail. Combined, it looks faster and breaks traceability later.
3. Capture the rationale at submission time, not at audit-prep time. Six months on, you will not remember why revision 7 of the IFU does not equal revision 6 plus a typo.

The three days was not wasted. It was the cost of having evidence. I would just like the next three days to be shorter.

Open question

For anyone running a CE-marked device portfolio: where is the line for you between "this is a routine document correction, route it under a lighter change class" and "this is a change that needs full Annex II treatment"? I am interested in how the cut-offs actually work in practice — five-line edits to an IFU, single-character fixes in a Declaration of Conformity, version-number-only updates in a Technical File. How are you drawing the line?