Last month, one of our sub-tier suppliers shortened the drying time on a sterilization pouch. We knew before they did — the change request was complete, the impact assessment ran to three lines, and the risk file had been updated the same afternoon.

The new drying time was running in production for eleven days before our incoming inspection criteria were revised to check the new seal strength.

Nothing in that sequence is illegal on its face. It becomes a finding the moment an auditor asks which revision of the incoming inspection instruction was in force on day one — and finds the change record says otherwise.

Planning gets the attention; documentation absorbs the delay

I have spent five years in software QA in IT services and the last decade inside a contract manufacturing organisation in Bangalore, where we make components for three global medtech OEMs. Across that time, the change requests I have reviewed have been technically sound more often than not. Planning is not where this breaks.

What I have learned to look for is where the calendar pressure lands. The change request has a due date. The impact assessment is a form with fields. Both are visible, both are auditable, and both get attention before release. The downstream documentation — revised work instruction, updated inspection criteria, superseded revision archived, retraining records, updated supplier agreement, risk file entry — is treated as aftercare. Aftercare has no release date attached, so it drifts to the next cycle.

On the shop floor, revising the work instruction after the batch has already run is treated as sīṭi vēlaik (சீடி வேலை) — effort that produces nothing useful. The standard treats it as the control.

The clause that settles the argument

I quote ISO 13485:2016 clause 7.3.7 more often than any other:

Changes shall be reviewed, verified, validated (as appropriate) and relevant documentation updated before implementation.

The load sits in before implementation. The clause does not ask you to be thorough; it asks you to be in order.

The rest of the system says the same thing in different language:

  • 7.4 and 7.4.2 push the discipline onto supplier-side changes. If your supplier changed the process, you must verify the purchased product still meets your acceptance criteria — the obligation does not stop at your supplier's gate.
  • 7.3.9 covers design and development changes, and ISO 14971 expects risk to be managed across the lifecycle rather than refreshed once at release.
  • 4.2.4 and 4.2.5 cover documents and records, including keeping superseded revisions retrievable. A document you cannot produce by date is not controlled.
  • 21 CFR 820.30 and 820.70 carry the equivalent expectations for design and production/process changes in the US, and the QMSR rewrite folds ISO 13485 into Part 820 by reference — a fair signal that these expectations are not going away.
  • EU MDR 2017/745, Article 10(9) requires changes to the QMS that affect compliance to be communicated to the notified body. "It is only a supplier process tweak" is not a regulatory category.

Be honest about the limits: no standard tells you to build a documentation impact list or gives it a lead time. That is where our practice fills the gap — and where our practice has been weak.

Four places the work actually slips

  • Verification evidence arrives after release. The new parameter runs, then the verification protocol is approved and signed. The data is real and the sequence is backwards.
  • The superseded revision disappears. The old work instruction is overwritten rather than archived. You now have no evidence of what was in force on the day of the batch.
  • The risk update lands in the CAPA file. CAPA-driven risk assessment is good practice, but if the change record does not link to the risk management file, the evidence is split across two systems and neither is complete on its own.
  • The impact list stops at our four walls. A change at a sub-tier supplier changes what we inspect on receipt, not just what the supplier documents internally. If our incoming inspection plan is not reissued, we are accepting product against criteria we stopped believing in.

Why approving faster makes it worse

This is the part I still cannot fully explain. Teams are not trying to cheat; they are trying to hit a ship date. So the approval gets compressed, and the approval becomes a formality — the approver reviews the plan, signs, and the work starts. The signature then stands in for a control that never happened.

If your QA function is two people and your notified body audit is a quarter out, that arrangement is not sustainable in either direction. You will not absorb the backlog later, because the audit does not move.

The principle I have started applying: approvals should guide work, not block it. A gate that only adds waiting gets routed around; the queue gets longer and the control gets thinner. The approver's job is not to hold up the change — it is to look hard at what will exist on release day and make sure it is right.

What I would run tomorrow

  • Attach documentation to the change request itself. The request carries a mandatory list of controlled documents, records, inspection criteria, supplier agreements and training items affected, each with a target date before release. An empty impact list means the request is incomplete, so it cannot be approved yet.
  • Treat "no evidence before first use" as a deviation, not a nit. If verification or validation cannot be completed before the change goes live, classify it through the deviation process and make that visible. Silently swapping the order is how the audit trail breaks.
  • Keep change, CAPA, risk and document control in one connected workflow. When those live in separate systems, documentation is always the first casualty — because nobody owns the join. Traceability should come from the link, not from memory at audit time.
  • Automate the chase, not the judgement. Automated reminders on overdue documentation and AI-assisted drafting of impact assessments are useful. Controlled assistance with human review is useful. What is not useful is letting a model decide residual risk or sign the approval — reviewability is the entire point.
  • Test retrieval, quarterly. Pick a date, a product, a change reference, and try to produce the exact revision in force that day. If you cannot, you do not have a document control problem. You have a records problem, and it is cheaper to fix now.

Where I would start

The last document. Before release, name the single controlled document that must be current on day one and write down who owns it. If the team cannot name it, the impact assessment was not an impact assessment — it was a summary.

I would also measure documentation completion latency separately from change approval cycle time. Cycle time can improve while control gets worse, and that is exactly the trade that feels like progress.

Does your organisation measure how long the paperwork takes — or only how fast the change can be approved?