Your version control just failed the audit. Here’s why.

Written by HATEM RABEH, MD, MSc Ing

Your Clinical Evaluation Expert And Partner

in
S

Most companies believe they have document control under control. They use version numbers. They date their documents. They archive old versions. But when the audit comes, the system collapses under scrutiny.

The problem is not that you lack version numbers. The problem is that your version management cannot prove its own integrity.

What MDR Annex II Actually Requires

MDR Annex II Section 4 requires that the technical documentation be kept up to date. It must reflect the current state of the device. It must show changes over time. It must allow reconstruction of the regulatory history.

This sounds simple. But notice what it implies: not just that you track versions, but that you can demonstrate the evolution of your clinical evidence, risk assessments, and device modifications in a way that is verifiable.

The documentation must allow a reviewer to understand what changed, when, and why. Not just in theory. In practice. Under scrutiny.

Most version control systems I see during audits cannot do this reliably.

Why Standard Practices Fail Under Audit

Let me show you where systems break down.

A company maintains clinical evaluation reports in Word. Each version is saved with a new filename: CER_v1.0.docx, CER_v2.0.docx, CER_v2.1.docx. The version history table inside the document lists the changes. Everything seems organized.

Then the auditor asks: “Show me that version 2.0 was never modified after approval.”

You cannot. The file properties show it was last modified two months after the approval date in the document. Someone opened it. Maybe they just looked. Maybe they corrected a typo. Maybe they changed a conclusion. There is no way to know.

The version control just failed. Not because you did something wrong intentionally. But because the system itself lacks integrity.

The Problem With File-Based Version Control

When you manage versions as separate files in folders, you rely on discipline. You rely on everyone following the naming convention. You rely on no one overwriting files. You rely on backups being consistent.

This works until it does not.

I have seen version 3.0 with an older date than version 2.5. I have seen the same version number on two different files with different content. I have seen approved documents with tracked changes still visible. I have seen final versions that were clearly edited after signature.

None of this was malicious. It was confusion, poor process, human error. But under audit, it looks like manipulation. And you cannot prove otherwise.

What Auditors Actually Check

When an auditor reviews your document control, they are not checking if you have a procedure. They assume you do. They are checking if your procedure works as a verification system.

Here is what they look for:

Traceability of changes. Can you show exactly what changed between versions? Not just a summary in a table. The actual differences. If version 2.1 revised the risk assessment, can you prove which risks were reclassified and which mitigation measures were added?

Approval integrity. Is there evidence that the approved version is locked? Can it be demonstrated that no one altered the document after the authorized person signed it? Does the electronic signature apply to the exact file you are showing?

Consistency across the technical file. If the clinical evaluation report references PMCF Protocol version 3.2, does that version exist? Is it the correct one? Does the date match? Do all cross-references align?

Reconstruction capability. If the auditor asks to see the technical file as it existed on a specific date two years ago, can you reconstruct it? Not approximately. Exactly. Every document at the version that was current on that date.

Most companies fail at least one of these checks.

\h3>The Metadata Problem

File metadata betrays poor version control.

The document says it was approved on March 15. The file properties show it was last modified on April 3. This creates doubt. Was it reopened to add a signature? Was content changed after approval? Was the date inside the document wrong?

You might have a reasonable explanation. But now you are defending your system instead of demonstrating compliance. The burden of proof has shifted.

This happens more often than companies realize. Someone exports to PDF on a different date. Someone updates the footer. Someone converts the format. Each action changes metadata.

If your version control relies on files, you must control metadata. Otherwise, every file tells a story you cannot verify.

What Survives Audit: The Three Requirements

After reviewing dozens of document control systems under regulatory scrutiny, I see three elements that consistently survive audit.

1. Immutability After Approval

Once a document is approved, it must become immutable. Not just protected. Immutable. The system must make it technically impossible to alter the content without leaving evidence.

This is why serious systems use checksums, digital signatures applied to file hashes, or document management platforms with audit trails at the database level.

It is not enough to say “we do not modify approved documents.” You must demonstrate that the system prevents it or records every attempt.

2. Automatic Audit Trail

Manual tracking does not survive audit. If the version history table is maintained by hand, it is just a claim. If the change log is written by the author, it is subjective.

The system must generate the audit trail automatically. Who accessed the document. When. What actions were taken. What changed between versions. This must be independent of the user.

I see companies using document management systems that log every action but never review the logs. The logs exist, but they are not used as verification. This is better than nothing, but it is not enough. The audit trail must be actively monitored and used to verify version integrity.

3. Snapshot Capability

You must be able to recreate the technical file as it existed at any point in regulatory history.

When you submitted the device for certification, the clinical evaluation report was version 2.3, the risk management file was version 4.0, the PMCF plan was version 1.2. If the Notified Body asks three years later what the technical file looked like at submission, you must be able to reconstruct that exact state.

Not close. Exact. Every document. Every version. Every cross-reference consistent.

This requires a system where versions are not just saved, but linked in time. Where each document carries a clear timestamp, and the relationships between documents are preserved.

The Cross-Reference Trap

Here is a failure mode that appears only under detailed review.

Your clinical evaluation report references the PMCF plan. The PMCF plan is currently version 3.1. But when you wrote section 7.2 of the CER, the PMCF plan was version 2.0. The CER was updated later, but that section was not revised. So now your CER version 4.0 contains references to documents that existed in a different version when that section was written.

This creates a hidden inconsistency. If the auditor cross-checks the references, the trail breaks. The versions do not align. The history does not make sense.

To prevent this, every reference must carry a version number and a date. And when you update a document, you must verify that all internal references are still valid or intentionally updated.

This sounds tedious. It is. But it is the only way to maintain consistency across a complex technical file with multiple interdependent documents.

Document Relationships As Version Control

One practice that works well: treat document relationships as part of version control.

When you approve a clinical evaluation report, you explicitly declare which versions of supporting documents it relies on. Risk management file version 4.2. PMCF protocol version 3.0. Literature review version 2.1.

This creates a snapshot of dependencies. If someone updates the risk file later, the CER does not automatically reference the new version. It still points to version 4.2 until the CER itself is revised and the reference is updated deliberately.

This prevents accidental desynchronization. It makes cross-checking possible. It allows reconstruction of the file as it existed when each document was approved.

It also makes updates more deliberate. You cannot just revise one document and assume everything else adjusts. You must trace the impact and update references accordingly.

What This Means For Your Next Submission

Before your next submission or audit, test your version control by asking these questions:

Can you prove that your approved CER was not modified after the authorized signature? Not by policy. By technical evidence.

Can you reconstruct your technical file exactly as it existed on the date of your last submission? Every document. Every version. Every cross-reference.

If you compare two consecutive versions of a document, can you show precisely what changed? Not just a summary. The actual differences.

If an auditor selects a random reference in your CER and asks to see that specific version of the referenced document, can you produce it immediately and prove it is the correct one?

If the answer to any of these is “probably” or “we would need to check,” your version control will not survive a detailed audit.

The Cost Of Poor Version Control

When version control fails during audit, the consequences are not minor.

The Notified Body may question the integrity of your entire technical file. If you cannot prove that documents were not altered after approval, they cannot trust any of the content. This can delay certification. It can trigger re-review of documents you thought were already accepted. It can require re-approval of the entire technical documentation.

I have seen submissions delayed by six months because version control could not be verified. Not because the clinical data was insufficient. Not because the risk analysis had gaps. But because the auditor could not trust that the documents represented what the company claimed they represented.

This is avoidable. But it requires treating version control as a verification system, not as an administrative task.

Final Thought

Version control is not about file naming or folders. It is about proving that your technical documentation has integrity over time.

The system must demonstrate that approved documents were not altered. That changes are traceable. That the regulatory history can be reconstructed. That cross-references are consistent.

If your version control cannot prove these things under scrutiny, it will fail when you need it most.

The time to fix this is not during the audit. It is now. Before the next submission. Before the next major update to your clinical evaluation.

Because the auditor will ask. And the question will not be whether you have version numbers. It will be whether your version control can prove its own integrity.

Peace,
Hatem
Clinical Evaluation Expert for Medical Devices
Follow me for more insights and practical advice.