Requirements Traceability Matrix (Validation)

This is a ready-to-use requirements traceability matrix (RTM) for a computerized system validation. It carries the full specification chain, user requirement (URS) to functional specification (FS) to design specification (DS), then on to the risk that requirement carries, the test case that verifies it, and the result of that test. The point is to prove that every requirement is specified, built, risk-assessed, and tested, with no orphan requirements and no untraced tests. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, and route it through your normal document control, review, and approval. A worked filled specimen follows the template so you can see how a completed version reads. Confirm each cited regulation against the current source before you rely on it.

Document control header

1. Purpose

This matrix demonstrates that every user requirement for <<FILL: SYSTEM NAME>> is carried through the design, assessed for risk, and verified by test, and that the verification effort is proportionate to risk. It is the single index an author, a reviewer, and an inspector use to walk from any requirement to the evidence that it works, and back from any test to the requirement it satisfies. It is a living document, baselined at each validation milestone and updated through change control.

2. Scope

This matrix covers all in-scope requirements for <<FILL: SYSTEM NAME>> at <<FILL: site / area>>, across the specification layers and the test phases (installation, operational, and performance qualification, or the CSA-aligned equivalents) defined in the validation plan <<FILL: plan-ID>>. It does not redefine the requirements, the risk method, or the test scripts themselves; those live in their own controlled documents and are referenced here by unique identifier.

3. Responsibilities

4. Definitions

• URS (user requirement specification): what the business needs the system to do, written in user terms, each line uniquely numbered.
• FS (functional specification): what the system does to meet a requirement, from the supplier or configured by the project.
• DS (design / configuration specification): how the function is built or configured, including parameters, code units, or configuration values.
• Risk classification: the priority assigned to a requirement (commonly High, Medium, Low) from severity, probability, and detectability, which sets how much testing it needs.
• Test case: the uniquely identified script or step that verifies a requirement, mapped to a qualification phase (IQ, OQ, PQ) or its CSA equivalent (scripted, unscripted, ad hoc).
• Forward trace: from URS down to test result, proving every requirement is built and verified.
• Backward trace: from test or design back up to a URS, proving nothing was built or tested that no requirement asked for.
• Orphan: a requirement with no downstream coverage, or a test or design element with no upstream requirement. Both are findings.
• Coverage: the proportion of in-scope requirements that have a passing, dispositioned verification result.

5. The matrix

5.1 Column definitions

Each row is one atomic, testable requirement. Split compound requirements so a single row never carries two distinct testable behaviors. Use the columns below; add a column only if it earns its place.

5.2 Trace table

A requirement marked GxP impact No still belongs in the matrix; it is traced and shown as out of scope for validation evidence, with the rationale recorded, so the decision not to test it is visible rather than silent.

6. Risk-to-test logic

Test rigor follows risk, and the matrix is where that proportionality is shown. State your rule once, then apply it on every row, so a reviewer can see that a High-risk requirement was not verified by an ad hoc check. A common, defensible rule:

Requirements that are not GxP-relevant may be verified by the supplier or by demonstration, with that decision recorded in the matrix. The risk classification in column 4 must match the rigor of the test phase and result in the later columns; a mismatch is exactly what a reviewer looks for.

7. Coverage and gap analysis

Run this analysis before any review or release decision, and re-run it after every change. Record the counts in the summary block below; an empty or all-zero exception list is the target.

7.1 Coverage summary

7.2 Gap checks (each must resolve to zero or be justified)

A non-zero count is not automatically a stop; it is an item that must carry a written disposition (closed, deferred with rationale, or accepted as residual risk by QA) before the matrix can support a release decision.

8. Using the matrix for release

The matrix is a release gate, not a checkbox. Before recommending release of <<FILL: SYSTEM NAME>>, confirm all of the following and record the conclusion in the validation report <<FILL: report-ID>>:

1. Every GxP-impact requirement traces forward to at least one executed test case with a Pass or a Pass-with-deviation that has an accepted deviation.
2. Every executed test case and every design element traces backward to a URS line (no orphans), or carries a recorded justification.
3. Test rigor matches risk for every High and Medium requirement per section 6.
4. All Fail and Pass-with-deviation results have a closed or formally accepted deviation, and any residual risk is signed by QA.
5. The coverage and gap analysis in section 7 resolves to zero exceptions or to fully dispositioned exceptions.
6. The matrix version is baselined, dated, and referenced by the validation report, so the released state is reconstructable.

Items that remain open at release are listed explicitly as known limitations with a target closure date and an interim control, not left blank. An inspector accepts a documented, controlled open item far more readily than a gap they discover themselves.

9. Maintenance through change control

After release, any change to the requirements, the configuration, or the system version is assessed against this matrix. Add, retire, or re-test the affected rows, re-run the section 7 analysis for the impacted scope, increment the matrix version, and reference the change record <<FILL: change SOP-ID>>. The matrix is retired only when the system is decommissioned, and is retained per the records retention schedule for not less than <<FILL: retention period>>.

10. References

21 CFR Part 11 (electronic records and signatures). 21 CFR 211.68 (automatic, mechanical, and electronic equipment). EU GMP Annex 11 (Computerised Systems), sections 4 (validation) and 4.4 (specifications and traceability). EU GMP Annex 15 (Qualification and Validation), 2015 revision. FDA Computer Software Assurance for Production and Quality Management System Software (final guidance issued 3 February 2026, superseding the 24 September 2025 version). GAMP 5 (A Risk-Based Approach to Compliant GxP Computerized Systems), Second Edition. ICH Q9, Quality Risk Management (for the risk classification that drives test rigor). PIC/S PI 011, Good Practices for Computerised Systems in Regulated GxP Environments.

Confirm the current version and clause numbers of each reference before issue.

11. Revision history

12. Approvals

Filled specimen

The following shows a slice of the matrix completed for an example temperature-monitoring system used to store GxP material, so you can see the level of detail an inspector expects. The system, IDs, and results are illustrative; replace them with your own.

Trace rows

Coverage summary

Gap checks

In this example the team caught two things the matrix is built to catch. A High-risk e-signature requirement (URS-015) failed its first run because the acknowledgement stamped local time instead of UTC; that became a deviation, was corrected and re-tested, and the row closed as Pass-with-deviation with the deviation referenced. Separately, a backward trace found an orphan test (TC-047) that no longer mapped to any requirement; it was tied to a retired requirement, pulled from the execution set, and the removal was recorded rather than ignored. Forward coverage to 100 percent plus a clean backward trace is exactly what a reviewer is expected to demonstrate before release.

Common inspection findings this matrix prevents

• A requirement in the URS that has no test case behind it, so the system was released against a requirement nobody verified.
• High-risk requirements verified by the same light-touch check as low-risk ones, with no link from risk to test rigor.
• Test scripts in the executed package that map to no requirement, suggesting scope crept or requirements were dropped without control.
• A Pass recorded for a requirement whose test actually failed, with no deviation and no linked correction.
• FS or DS elements that implement behavior no requirement asked for, never assessed for GxP impact.
• A matrix that was true at the start of the project but never updated after configuration changes, so it no longer matches the released system.
• Coverage claimed as complete with no documented gap analysis showing the orphan and open-deviation checks were actually run.

How to adapt this matrix

1. Set your document number, owner, system, GAMP category, and linked document IDs in the header.
2. If your project uses a CSA-aligned approach, relabel the test phase column from IQ/OQ/PQ to scripted/unscripted/ad hoc and keep the same risk-to-rigor rule in section 6.
3. If you have a single combined specification rather than separate URS, FS, and DS documents, collapse those columns but keep one column for the requirement and one for the design or configuration reference; do not lose the build-to evidence.
4. Set your risk-to-test rule in section 6 to match your validation plan and risk SOP, then enforce it on every row.
5. Point the cross-references in sections 8 and 9 to your real validation report, deviation, and change control procedures.
6. Re-run the coverage and gap analysis in section 7 at every milestone and after every change, and baseline the matrix version each time.
7. Confirm every regulation in section 10 against the current published version before issue.