Requirements traceability matrix in pharma: what auditors check and how to keep one alive

Which test proves this requirement, and which requirement justifies this test? A requirements traceability matrix (RTM) answers both questions for every row, in both directions. If yours cannot, it is a spreadsheet, not evidence. This guide covers what an auditor expects to find in one, why hand-kept matrices break, and how to keep one alive through a real project.

What is a requirements traceability matrix?

A requirements traceability matrix is the table that links every user requirement of a system to the specifications that implement it and to the tests that verify it. In pharma validation it connects the URS to the functional and design specifications, and those to the IQ, OQ and PQ protocols, so that a reader can pick any requirement and follow it to a test result, or pick any test and follow it back to the requirement that asked for it.

It is called a matrix because it started life as a grid: requirements down the side, tests across the top, a mark where they meet. The grid is optional. The two questions are not:

Was every requirement verified? No requirement without a test that covers it.
Was every test justified? No test without a requirement or specification behind it.

Everything below follows from taking both questions seriously, in both directions, for every row.

What Annex 11, Annex 15 and GAMP 5 ask for

None of the guidelines asks for a document called "RTM". They ask that the link exists and can be shown:

EU GMP Annex 11 §4.4: user requirements "should be traceable throughout the life-cycle".
EU GMP Annex 15 §3.2: the user requirements specification "should be a point of reference throughout the validation life cycle".
GAMP 5 (2nd edition), Appendix D5: traceability links requirements to specifications and to verification, at a level of detail proportionate to risk.
21 CFR 211.68 and Part 11 do not name traceability, but an FDA investigator asking "how do you know this function was tested?" is asking for it.

What the matrix proves, in plain words:

The question the auditor is asking	What the matrix must show
Was every requirement verified?	A test against every requirement, at the right stage. No blanks.
Was every test justified?	A requirement or specification behind every test. No orphans.
Was it verified against the right thing?	The test checks the specification that decomposes the requirement, not a paraphrase of it.
Was it verified as worded?	The revision of the requirement each test was executed against.
Can it be walked both ways?	From any requirement down to a signed result; from any result up to a requirement.

The three matrices people confuse

"The RTM" is usually three different tables, and mixing them is the first mistake.

The V-model: URS, FS and DS down the left leg; IQ, OQ and PQ up the right leg; each protocol verifies the specification at its own height, and the three dashed links across the V are the requirement-to-test matrix — **The V-model.** Each protocol verifies the level at its own height. The matrix is the set of dashed links.

Matrix	Links	What it proves	Kept by
1 · Requirement → functional specification	URS-nnn → FS-nnn	Every requirement was designed for.	Engineering
2 · Functional → design specification	FS-nnn → DS-nnn	Every function has a physical or software design behind it.	Engineering, supplier
3 · Requirement → test	URS / FS / DS → IQ, OQ, PQ	Every requirement was verified, at the right stage.	Validation, QA

Three rules follow:

A test verifies the level it belongs to. IQ verifies the DS (installed as designed), OQ the FS (operates as specified), PQ the URS (performs in use). A single test rarely "covers" a URS line directly; it covers it through the chain.
Matrix 3 is the one QA signs. Matrices 1 and 2 are how it stays true: if the FS is not traced to the URS, an OQ test that verifies the FS proves nothing about what the process needed.
A direct URS → DS link, skipping the FS, is a smell. Either the FS is missing, or the requirement is really a design constraint and belongs in the DS.

A worked example: one requirement from URS to PQ

An aseptic vial filler. The process owner writes one line in the URS (one that can be tested); everything below it is traced to the line above.

One requirement of a vial filler traced from the URS to the PQ: fill volume 5.0 mL within 1 %, through FS-003 (gravimetric dosing), DS-007 (load cell WT-101), the signal in the I/O list, the loop check as IQ evidence, OQ-011 and PQ-002 — **From URS to PQ.** One requirement of an aseptic vial filler, and the trace stored at every hop. The matrix row is read from these links, never typed.

Read the chain from the top:

URS-001 states what the process needs, with a value and a tolerance: 5.0 mL, ± 1.0 %.
FS-003 states what the system does to deliver it: gravimetric dosing, the pump driven by the load-cell weight. Traced to URS-001 (matrix 1).
DS-007 states how it is built: load cell WT-101, 0–20 g, 4–20 mA, resolution 0.01 g, analogue input card 2, channel 3. Traced to FS-003 (matrix 2).
WT-101 is the row in the I/O list. The loop check is generated from it and is IQ evidence: it proves the signal is wired and scaled, not that the fill is accurate.
OQ-011 proves the function with tolerances: three set points, ten vials each, every vial within ± 1.0 %. Verifies FS-003 (matrix 3).
PQ-002 proves the requirement in use: three batches, thirty vials each, batch mean within ± 0.5 %. Verifies URS-001 (matrix 3).

Each hop is stored on the element that makes it: the test names the specification it verifies, the specification names the requirement it decomposes. The matrix row is read from those links, never typed. When the load cell is replaced and DS-007 is revised, LC-T001 and OQ-011 are flagged for re-execution, PQ-002 is reviewed, and the matrix keeps the revision each test ran against.

What an RTM looks like: the excerpt and the columns

Four requirements of the same filler, as the matrix shows them:

An RTM excerpt for the vial filler: four requirements with their FS, DS, IQ, OQ and PQ tests; URS-004 has no OQ test, and OQ-023 is an orphan test with no requirement behind it — **What an auditor sees in ten seconds.** A requirement with no test (URS-004 in OQ) and a test with no requirement (OQ-023). Both are findings.

Three things the excerpt shows that a flat list does not:

Not every requirement reaches PQ. URS-003 (every fill weight recorded with operator and time) is proven in OQ; a PQ test would be duplication.
Two requirements can share one test. URS-001 and URS-002 are both proven by PQ-002. Show both links, not one.
A gap and an orphan are both findings. URS-004 has no OQ test for its interlock; OQ-023 was added on site and no requirement asks for it. An orphan test is not "extra safety". It is a test nobody asked for, and the auditor will ask why it was run.

Whatever tool holds the matrix, these are the columns it needs. Use them as the template to ask your tool for:

Column	Why it is there
Requirement ID	Permanent, never reused. The row's identity.
Requirement text and revision	The wording the tests were written against.
GMP impact and criticality	Decides the depth of testing (Annex 11 §4.4, GAMP 5).
FS ID, DS ID	Matrices 1 and 2, so the chain can be walked.
IQ, OQ, PQ test IDs	Matrix 3: the tests, at the stage that verifies the level.
Result, and the revision executed against	Pass or fail, and the wording of the requirement at execution.
Discrepancy and re-test	What happened when it failed, and the run that closed it.

Why hand-maintained matrices fail

A matrix kept by hand is right on the day it is made. Then someone deletes a requirement from the URS, the list renumbers, and the matrix, kept on another sheet, does not move.

Deleting URS-002 from a numbered URS shifts the requirements up one row while the matrix, on another sheet, keeps its rows: the purge test now sits against the weight requirement and the interlock test has no requirement at all. With stable identifiers the retired number leaves a gap and every link holds — **Off by one.** URS-002 is deleted and the URS renumbers; the matrix, on another sheet, keeps its rows. The purge test now sits against the weight requirement and OQ-017 has no requirement at all. A retired identifier leaves a gap instead.

The same thing happens in slower ways:

Silent revision. A requirement's wording changes in the URS; the matrix keeps the old text, or none at all.
Tests added on site. A discrepancy leads to a new OQ test; it never reaches the matrix.
Three copies. The supplier has one, engineering has one, QA has one. They disagree.
No owner. The matrix is "produced" for the report, not maintained through the project.

The fix is not discipline. Store the link on the element itself: the test names the specification it verifies, the specification names its requirement. The matrix is then a view of those links, generated on demand, and nobody edits it.

How an auditor reads a traceability matrix

Auditors do not read matrices. They walk them. Two routes, and the matrix must survive both.

The auditor's two walks: down from a requirement through the FS and the DS to an executed, signed result; and up from a test to the specification and the requirement that justify it. Both end at a revision — **Two walks.** Down: is there a signed result for what was asked? Up: was this test ever asked for?

Down, from a requirement to a result

Pick a critical requirement: fill volume, sterility, data integrity.
Follow it to the specification that decomposes it. Does the FS say something more precise than the URS, or repeat it?
Follow it to the test. Is the acceptance criterion a number, a range or a state?
Open the executed test: result, evidence, executor, date, signature.
If it failed: the discrepancy, its closure, the re-test, and the design revision it ran against.

Up, from a test to a requirement

Pick a test that looks odd: an OQ test with no obvious purpose, or one added late.
Which specification does it verify? If none: why was it run?
Which requirement is behind that specification? If none: the test proves nothing anyone asked for.
Was the requirement still worded that way when the test was executed?

Both walks end at a revision. A matrix that cannot say which wording a test was executed against fails the walk even when every cell is filled.

Checklist: ten things an auditor checks in an RTM

Every requirement has a test. No blanks.
Every test has a requirement or specification behind it. No orphans.
Links go level by level: URS→FS→DS→IQ, not URS→IQ.
Tests verify the level they belong to: IQ against the DS, OQ against the FS, PQ against the URS.
Identifiers never renumber. A deleted requirement leaves a gap.
The matrix shows the revision of the requirement each test ran against.
Re-executed tests show the latest result; the history is kept.
Tests added during execution are in, with their reason.
Critical requirements are tested directly and in depth; the rest in proportion to risk.
One source, one owner, produced on demand. Nobody edits a spreadsheet first.

Download: the RTM audit checklist, on one page (PDF). The ten checks with what to look at for each, and the two walks, in the order an auditor takes them. Use it on your own matrix before the inspection does, or hand it to a supplier with their protocols. Download the checklist

How to keep the matrix alive through the project

Store the trace on the element, not in a table. When a test is written, it names the specification it verifies. When a specification is written, it names its requirement.
Identifiers never renumber. A deleted requirement leaves a gap; a retired number is never reused.
Every change to a requirement is a revision, dated, and the tests that verify it are flagged for review.
Generate the matrix, never edit it. On demand, as a page and as an export.
Generate it at three moments. Before the protocols are approved (gaps), before execution starts (completeness), for the summary report (evidence).

This is what MGTrace does by construction: a tag on the requirement, a trace from the test, and the RTM is a page you open, filtered by system, exported to CSV for the report. It is one of the things validation software has to do. The discipline above holds in any tool, as long as one person owns the matrix and it is regenerated, not patched.

Frequently asked questions

Is a traceability matrix mandatory in pharma?

No guideline names the document, but EU GMP Annex 11 §4.4 requires user requirements to be traceable throughout the life cycle, Annex 15 §3.2 makes the URS the point of reference for validation, and GAMP 5 builds its specification-and-verification model on the same links. The matrix is the accepted way to show them. An inspector who cannot walk from a requirement to a result will raise a finding whatever the document is called.

Who owns the RTM?

Validation or QA signs the requirement-to-test matrix. Engineering keeps the requirement-to-FS and FS-to-DS links true, since it writes those documents. The one rule that matters: one matrix, one owner, and supplier, engineering and QA looking at the same one.

Can one test cover several requirements?

Yes, and it is normal: a PQ batch run proves fill volume and headspace oxygen at once. The matrix must show every link, one row per requirement, so that each requirement can be walked to that test on its own.

Does every requirement need a PQ test?

No. A test verifies the level it belongs to. A data-logging requirement proven in OQ (record content, time stamp, audit trail) does not need a PQ test; forcing one is duplication. What every requirement needs is a test at the stage that proves it, and a link to it.

Is an Excel traceability matrix acceptable to an auditor?

A spreadsheet is accepted as a document like any other, and it is right on the day it is made. It fails on the walk: a deleted row shifts every link below it, a reworded requirement leaves the old text against an old result, and three copies disagree. If a spreadsheet is what you have, one person owns it, identifiers never renumber, and it is regenerated from the source documents before each review, not patched.

In short. A traceability matrix is not a deliverable; it is the visible form of links that must exist anyway. Keep the links on the elements, level by level, with stable identifiers and dated revisions, and it survives any walk an auditor takes through it. Keep it as a spreadsheet, and it is right on exactly one day.