Validation documentation and requirements traceability for medical software

What is a validation record for?

It is an argument that the software does what its requirements say, written so that somebody who was not there can check it. The documents are the structure of that argument: what was required, how it was going to be shown, what happened when it was shown, and what was decided about each step that did not go as written.

Two defects in that argument survive a run in which everything passes. The first is a requirement that no test covers, which has been asserted and never demonstrated. The second is a test that traces to no requirement, which demonstrates something nobody asked for against a criterion nobody agreed. A test runner reports neither, because a runner knows only about the tests that exist and has never read your requirements.

The requirements traceability matrix is the artefact that makes both of them visible, and the only one that makes both visible at the same time. Read down the requirement column and the empty cells are the first defect. Read up from the executed runs and the rows that join to nothing are the second. Every other document in a validation file describes work that was done. The matrix is the document that describes work that was not.

Regulators write the same instrument into their documentation requirements without calling it a matrix. MDR Annex II Section 4 requires the technical documentation to give "the precise identity of the controlled documents offering evidence of conformity with each harmonised standard, CS or other method applied", and to incorporate "a cross-reference to the location of such evidence within the full technical documentation". A requirement, the method that answers it, and the exact place the evidence sits: that is a trace under another name. The rest of what that Annex asks for is set out on EU MDR software requirements.

Why does it matter when the documents were written?

Because a record made during the work and a summary written after it are different kinds of evidence, and a reader can tell them apart. Reconstruction is where records start to disagree with what happened: the build that was actually exercised, the step repeated after somebody changed a setting, the environment that moved mid-week, the failure that was fixed and never re-run. None of that is dishonesty. That is memory behaving normally, and replacing memory is the whole function of a validation file.

21 CFR Part 11 is the clearest published statement of what makes a record hold up, and it is the one to read even where it does not bind you. section 11.1(a) says the part sets the criteria under which FDA considers electronic records and signatures "trustworthy, reliable, and generally equivalent to paper records and handwritten signatures executed on paper". The controls that follow are about the record's own history rather than about the software under test. section 11.10(e) requires "secure, computer-generated, time-stamped audit trails" that independently record the date and time of operator entries and actions creating, modifying or deleting a record, and states that "record changes shall not obscure previously recorded information". section 11.50(a) requires a signed record to carry the printed name of the signer, the date and time the signature was executed, and the meaning of the signature, "such as review, approval, responsibility, or authorship". section 11.10(k)(2) puts revision and change control on the documentation itself, so that it maintains "an audit trail that documents time-sequenced development and modification of systems documentation".

None of that decides whether a document has to exist. Part 11 only sets conditions on records that some other requirement already obliges you to keep, and FDA's 2003 guidance states that records not required to be retained under a predicate rule, and merely kept in electronic form, are outside the part. The obligation to hold a validation record comes from the quality system your market asks for; Part 11 says what that record has to survive once it lives in a system. Which of its ten sections reach a given system is worked through on FDA 21 CFR Part 11 validation testing.

Which products does this work sit on?

The ones whose records are read by somebody outside the company. Three shapes of product carry that reading, and the file looks different in each.

For software that is itself the device, the test records sit inside the regulatory file rather than beside it, so the documentation is part of the object being assessed. For a record system, what gets read is the certification evidence and the material around the audit trail, which is a record the system has to protect as well as produce. For health software placed on the market without dedicated hardware, IEC 82304-1 names a validation plan at clause 6.1 and a validation report at clause 6.3, and its subclause 1.3 settles conformity by reading: "Compliance with this document is determined by inspection of all documentation required by this document."

Which standards ask for these documents?

Each one below names either an artefact or a trace, and the differences decide how far a single file can answer several of them at once.

Documentation obligations from ISO 14971, IEC 62304, ISO 13485, IEC 82304-1, EU MDR and 21 CFR Part 11, and the file content each produces.

Where the obligation comes from	What it names	What that becomes in the file
ISO 14971	Traceability for each identified hazard through the risk analysis, the risk evaluation, the implementation and verification of risk control measures, and the evaluation of residual risk, as ISO/TR 24971 subclause 4.5 restates it	The hazard axis of the trace, with two separate results per control, because clause 7.2 treats implementation and effectiveness as different questions
IEC 62304	Records at the depth the assigned software safety class binds, decided per software item	The classification record, which is what justifies every clause the file does not answer
ISO 13485	Design validation and design output verification records, which the MDSAP audit approach maps to clause 7.3.7 and clause 7.3.4, with design change at clause 7.3.9	The plan, the executed records and the change history, controlled as quality records under clause 4.2.5
IEC 82304-1	A validation plan at clause 6.1, the performance of validation at clause 6.2 and a validation report at clause 6.3	Three documents the standard titles outright, plus re-validation after a post-market change at clause 8.3
EU MDR	The precise identity of the controlled documents evidencing conformity and a cross-reference to where each sits, at Annex II Section 4(d)	The evidence index, which is where an assessor enters the rest of the file
21 CFR Part 11	Audit trail, signature manifestation and change control over the documentation itself, for records kept electronically under some other requirement	The conditions the file has to meet once it lives in a system rather than in a binder

The two traces that most often get merged are the risk trace and the requirements trace. They run over different populations: one starts from hazards, the other from requirements, and a control that reduces a risk is rarely worded the way the requirement implementing it is worded. Keeping them in one table usually means one of the two populations is incomplete. What the risk side has to carry is set out on ISO 14971 risk management and software testing, and the class that decides the depth of the software side on IEC 62304 software testing requirements.

Which document does an assessor open first?

The index, then the plan, then a sample of executed records that they choose rather than ones you offer. That order matters because it is the order the file has to survive.

The index or the matrix goes first because it is the only document in the set that claims completeness; everything else claims something about one requirement or one run. The plan follows, read for its acceptance criteria and its scope, with its approval date checked against the execution dates. Then the sampling: rows are picked, usually the least convenient ones, and each is followed through to the executed record, to the deviation if there was one, and to the retest.

A file built in that order reads in that order. A file assembled at the end reads as a pile with an index fitted over it, and step three is where it separates, because the row an assessor picks is the row whose evidence was hardest to find.

Where does a validation file come apart on the desk?

• The matrix is generated from the test management tool, so every test traces to something and no requirement can appear without a test. It reports the tool's own contents, and the two gaps the matrix exists to expose cannot appear in it.
• Requirements were edited after the runs and the matrix points at their current text, so a row claims coverage of a sentence that did not exist when the test was written.
• Test records name a feature and the risk file is organised by hazard, so joining the two is a conversation with the engineer who wrote both.
• A step failed, the defect was fixed, and the record carries only the second run, which removes the evidence that the fix was verified against the condition that broke.
• The protocol, the executed record and the report are one document with three headings, so nothing on file separates what was planned from what happened.
• Screenshots are the evidence, and a screenshot shows a result without the build identifier, the environment or the account that produced it.
• The validation set carries no revision history of its own, so a reviewer cannot tell whether the copy in front of them is the copy that was approved.
• Every requirement is covered exactly once, which usually means coverage was declared rather than designed.

How does this fit a team that ships every sprint?

By deciding before the release train starts which classes of change reopen which parts of the file, and by writing that decision where a reviewer can find it. IEC 82304-1 gives re-validation after a post-market change its own subclause, clause 8.3, separate from software maintenance at clause 8.2, so a changelog entry does not close it. That decision is cheaper to make once, in advance, than to defend at each release.

The documents are versioned the way the code is. A protocol references requirement identifiers at a revision, an executed record references the build it ran against, and the matrix references both, so a requirement change produces a visible list of rows to revisit instead of a silent one.

Where an outside team writes the records, the records still answer to you. FDA's 2024 guidance on electronic systems in clinical investigations addresses that case directly: a regulated entity may review its service provider's processes for developing and managing the system, its validation processes, its functional testing and its change control procedures and tracking logs, and it remains the regulated entity's responsibility to ensure that documentation is available if FDA asks for it, including documentation the provider created and maintains. That guidance is written for clinical investigations, and the structure it describes holds wherever the work is contracted out.

What we do is write the protocols against your requirement identifiers as they stand on the day and build the trace while the runs happen, so the file is assembled in the order it will later be read. Test execution itself is covered under medical device software testing, and the sequence for a file that has to be ready by a fixed date under healthcare software audit preparation. What we can accept as test data, and on what terms, is its own matter, raised under working with protected health information.

The clause and section numbers on this page were checked against the primary text of each standard on 2 September 2026. Where a statement comes from a guidance document rather than from a standard or a regulation, the sentence says which document it is.