A document without a trustworthy birth certificate is just a file — fixing the lifecycle before audit finds it

Every document in our QMS has three birthdays — and for the first eighteen months of my current role, we were only tracking one of them.

That changed after a notified body audit in 2023. The auditor pulled a work instruction for an incoming inspection step — the one that verifies surface roughness on the titanium spinal implant blanks we make for an OEM. Three PDFs sat in front of us. The audit trail was supposed to show me which was current, which was approved, and which was retired.

What we actually had: filenames like WI-047_v2_FINAL.pdf, WI-047_v3_FINAL.pdf, and WI-047_v3_FINAL_FINAL.pdf. Two of them shared the same approval date. One had been edited through a Word comment that nobody had accepted. None had a proper supersession trail.

I passed that audit, mostly because the auditor was more interested in our process validation. But I came out knowing the document control problem would come back. It has, twice, since.

Then last week I came across a video walking through what a defensible document lifecycle actually looks like in a regulated environment — from the moment a document is born to the moment it is retired. It was a useful gut-check on the parts I had got wrong, and the parts I had accidentally got right. For any medtech team trying to keep their records trustworthy, the walkthrough is worth the time.

Here's how I now think about the lifecycle, in three stages.

Birth: the metadata that has to exist before the file exists

A document is not a document when someone types WI-048_v1.docx. It is a document when it has, at minimum:

• A unique identifier in a register
• A named owner who is accountable for the content
• A classification (work instruction, SOP, form, specification, external standard)
• A draft state that is visibly different from an approved state
• A revision history that captures why this version exists, not just that it exists

That last bullet is the one I keep coming back to. ISO 13485 §4.2.4 asks for changes to be reviewed, approved, and traceable, with change records showing who did what and when. EU MDR Article 10 expects technical documentation that allows the conformity assessment to be understood. 21 CFR Part 11 expects an audit trail that captures the who, what, when, and why of each action on a record.

Most of the time we only capture the what. The why is the part the auditor actually asks about.

Active life: change control is the connective tissue

A living document gets touched. Version control is not an archive problem — it is a workflow problem.

Three things have to be true during the active life:

• Every edit produces a new revision. There are no in-place edits on an approved document.
• Every revision goes through the same review-and-approval loop as the original. No informal sign-offs.
• The current revision is the only revision available at the point of use. A floor operator should never be reading v2 while v5 is the approved one.

That third point is where I see the most pain at small and mid-sized manufacturers. The current revision lives somewhere; the historical revisions live somewhere else; and the gap between those two places is where the non-conformances breed. When a CAPA references a work instruction, the CAPA owner has to be able to answer: which revision were we actually following when the deviation occurred?

If you cannot answer that, the CAPA is built on sand. Change control is the connected workflow that holds the rest of the system together — without it, traceability collapses.

Audit trail integrity: the boring bits that decide the audit

Audit trail integrity is unglamorous work. It is also the difference between a minor observation and a major non-conformance.

The bits that matter, in order of how often they bite us:

• Time stamps in one timezone. Pick UTC or pick IST — but pick one, and make sure your system stores what the user sees and what the audit trail records.
• User identity tied to a real person. Shared logins break the entire model. If two engineers share qa.team@, your audit trail is unreliable by design.
• No deletion of records. Obsoletion is fine. Deletion is not. There is a meaningful difference.
• Retention that matches the device lifetime plus the regulatory minimum. For our OEM customers shipping into the EU, that means records for at least ten years after the last device was placed on the market, or longer if the contract says so.

A video walkthrough is useful here precisely because it shows the texture of an audit trail — what it looks like line by line, not what the SOP says it should look like. The SOP and the reality drift apart over time, and the drift is where the auditor lives.

Retirement: obsolete should actually mean obsolete

This is the part the video covered best, and the part I had been laziest about. When a document is retired, four things need to happen:

• The retired version is moved to a clearly labelled archive state.
• The current version is unambiguously the one in active circulation.
• The retirement reason is captured (superseded, withdrawn, consolidated into another document).
• The retired version is still retrievable for the duration of the retention period.

The graveyard — the folder full of OLD_, OBSOLETE_, ARCHIVED_DO_NOT_USE_ files — is not retirement. It is entropy. Every one of those files is a future non-conformance waiting to be read by the wrong person at the wrong time.

What I would do differently

If I were rebuilding from scratch, I would do three things:

1. Treat the document register as the source of truth, not the file share. The folder is downstream of the register, never the other way round.
2. Make the "why this revision exists" field mandatory at the change-control level, not optional at the draft level.
3. Audit the graveyard once a quarter. Anything that is supposed to be in archive but is sitting in a working folder is a finding-in-waiting.

A document without a trustworthy birth certificate is just a file with an extension. The lifecycle is what makes it a controlled record, and a controlled record is what survives the next audit.

How do you handle the superseded graveyard at your shop? Every contract manufacturer I have worked in has one — that folder full of OLD_ and _FINAL_FINAL files that somebody is going to read at 2am six months from now. What does yours look like, and how often do you clean it?