Traceability matrix template: requirement to test to result

A requirements traceability matrix is the index of a validation pack. Each user requirement gets one row, and the row names where the system meets it, which test proves it, how that test came out, and the deviation if it failed. Read across a row and you go from a promise in the URS to the executed evidence. Read the test column backwards and every test should land on a requirement.

The tool reads both directions at once and lists what would stop a clean validation report:

no test

A requirement with nothing linked. Either a test is missing or the requirement needs a written reason why it is not tested (a vendor document, a procedure).

no requirement

A test that proves nothing in the URS. Often a useful test that lost its requirement, sometimes scope creep that costs execution time.

unknown test

A requirement points to a test ID that is not in the test list: a typo, or a test that was renumbered.

failed

A failed test, with or without its deviation number. The requirements on it stay open until the deviation closes and the test passes.

not run

A test not executed yet, and the requirements still waiting on it.

ID

A blank or repeated requirement or test ID, which breaks the join.

our judgement

A high process risk requirement tested only by unscripted tests. Allowed, but worth a written reason.

The coverage line counts a requirement as traced when at least one existing test is linked to it. Traced is not the same as passed: in the example, 14 of 15 lines are traced but only 10 have passed.

The matrix sits between two documents you already have. The requirements come from the approved user requirement specification; the test IDs come from the executed IQ, OQ and PQ protocols. Build it when the protocols are drafted, not after execution, so a missing test shows up while it is still cheap to write.

For the risk column, the CSA validation scope planner makes the high or not high call per feature; carry its answer across. Where the matrix lives in your pack, and who approves it, is set by the validation master plan.

The tool opens on a cloud LIMS in a device maker's QC lab, part-way through validation: 15 URS lines, most of them the Part 11 controls a records system has to show, plus three QC functions (the out-of-specification flag, the assay calculation, the certificate of analysis). It reads 14 of 15 requirements traced, with 5 open items. Each one below is what a reviewer would circle, and the fix.

With those closed, the matrix reads 15 of 15 traced and every test lands on a requirement, which is the line the validation report can then quote. The Part 11 rows in the example follow the clauses one by one; Part 11 requirements, section by section explains each in plain words.

In practice nobody reads a validation pack front to back. A reviewer picks a requirement that matters (the signature, the audit trail, the calculation that releases product), asks for the test that proves it, then for the executed page with its result and signature. Or they start from a failed test and ask which requirement it protected and what happened next. The matrix is what lets you answer in a minute rather than an afternoon. It is worth being exact about which part of that is a rule:

FDA's 2003 scope guidance put Part 11's own validation clause under enforcement discretion. That does not make validation optional: FDA said it will “enforce all predicate rule requirements”, and for device makers the CSA guidance says the discretion “expressly does not apply” to software validation under ISO 13485 Subclauses 4.1.6, 7.5.6 and 7.6. The validation lifecycle for a small lab shows where the matrix sits; CSA vs CSV covers what the risk words changed. An EU-facing site should read Annex 11 for US labs, since § 4.4 is the GMP text that asks for traceable user requirements outright.

The clauses the example's URS lines restate, and the texts that ask for the trace. Paraphrased; the quoted wording above is verbatim.

§ 11.10(a)

Validate the system for accuracy, reliability, consistent intended performance and the ability to discern invalid or altered records.

§ 11.10(b)

Generate accurate and complete copies, human readable and electronic, for inspection.

§ 11.10(c)

Protect records so they can be retrieved accurately throughout the retention period.

§ 11.10(d), (g)

Limit access to authorised people, and check authority before anyone signs, alters a record or runs an operation.

§ 11.10(e)

Secure, computer-generated, time-stamped audit trail; changes never obscure what was recorded before; the trail is kept as long as the record.

§ 11.10(f)

Operational system checks that enforce the permitted sequence of steps and events (in the example, review before approval).

§ 11.50(a), (b)

A signed record shows the signer's printed name, the date and time, and the meaning, on screen and on any printout.

§ 11.70

Signatures are linked to their records so they cannot be excised, copied or transferred by ordinary means.

§ 11.200(a)(1)

Non-biometric signatures use at least two distinct components, such as an ID code and a password.

§ 11.300(d)

Transaction safeguards prevent unauthorised use of passwords or ID codes, and report any attempt urgently to the system security unit.

Annex 11, 4.2

Validation documentation includes change control records and reports on deviations seen during validation.

Annex 11, 4.4

User requirements describe the required functions, rest on a documented risk assessment, and stay traceable throughout the life-cycle.

Annex 11, 4.7

Show appropriate test methods and scenarios, including parameter limits, data limits and error handling.

GPSV 5.2.2, 5.2.5

Trace software requirements to and from system requirements and risk analysis; a traceability analysis checks test coverage.

CSA V.A(6)

The record holds the intended use, the risk result, the testing done, issues found (deviations, defects, failures), a conclusion, who and when.

General information, not regulatory advice.

1. 21 CFR Part 11, Electronic Records; Electronic Signatures (eCFR), National Archives, eCFRread 2026-10-22
2. EudraLex Volume 4, Annex 11: Computerised Systems (2011), European Commissionread 2026-10-22
3. General Principles of Software Validation (January 2002), FDAread 2026-10-22
4. Computer Software Assurance for Production and Quality Management System Software (February 3, 2026), FDAread 2026-10-22
5. Part 11, Electronic Records; Electronic Signatures: Scope and Application (2003), FDAread 2026-10-22