A traceability matrix answers a simple question: has every relevant requirement been implemented and verifiably tested? Simple as the question is, answering it becomes laborious when the links between requirements, risk assessment, specifications and test protocols have to be reconstructed at the end of the project. This article shows how a traceability matrix is structured, how detailed it should be and how to maintain it over the life cycle of a system.
What is a traceability matrix for?
The matrix is what holds the qualification documentation together. It links the requirements in the user requirement specification to the results of the risk assessment, the technical specifications and the tests in DQ, IQ, OQ and PQ. This gives it three functions:
- Evidence of completeness: every requirement has at least one piece of evidence. This does not always have to be a dedicated test. A check in the DQ or a FAT or SAT result used with justification also counts.
- Link to risk: it shows that critical requirements are tested more thoroughly than non-critical ones. This reflects the risk-based approach described in Annex 15 of the EU GMP Guide and, for computerised systems, in GAMP 5.
- Navigation aid: reviewers, auditors and later the operating staff can use the matrix to find the evidence for a particular requirement quickly.
The explicit requirement for traceability is in Annex 11 (4.4): user requirements for computerised systems should be traceable throughout the life cycle. No guideline prescribes a matrix as such. It is, however, the usual way to show this traceability and the evidence for every URS requirement.
Structure: the typical columns
A structure that follows a requirement’s path through the project has proven useful:
- URS ID and short description: unique and identical to the numbering in the URS.
- Criticality or risk class: the result of the GMP risk assessment, e.g. high, medium, low.
- Reference to the functional or design specification (FS/DS): where and how the requirement is implemented technically.
- Test case: protocol and test step number in the DQ, IQ, OQ or PQ, or a reference to a FAT/SAT result used with justification.
- Result and status: passed, failed or open, with a reference to any deviation.
Depending on the project, further columns may be added, such as a risk ID, the test method, a separate column for each qualification phase, a deviation reference, a reference to supplier documents or a remarks column.
In practice, a few rules have proven useful. A requirement with no link to risk, for example one from an SOP, still needs a test route. Where a field does not apply, it contains “N/A” with a brief justification rather than being left blank. The matrix is not a test protocol: acceptance criteria and results stay in the protocol, and the matrix only refers to them. ID conventions for requirements, risks and test steps are best defined in advance in the quality plan.
Example: cleanroom with monitoring system
The following table is a fictitious, simplified example for a cleanroom area with an HVAC system and a monitoring system:
| URS ID | Requirement (short) | Risk | FS/DS | Test case | Result / status |
|---|---|---|---|---|---|
| URS-012 | Differential pressure between cleanroom and airlock as per the pressure cascade in the URS | high | FS-4.2, DS supply air control | OQ-07 differential pressure measurement; PQ-03 continuous monitoring | OQ passed; PQ open |
| URS-018 | Particle concentration at rest meets the specified cleanroom grade | high | DS filter design, airflow pattern | OQ-11 particle measurement at rest | passed |
| URS-025 | Alarm when differential pressure falls below the limit, with delay and acknowledgement | high | FS-6.1 alarm management | OQ-14 alarm test | failed, deviation DEV-003 |
| URS-031 | Wall and ceiling surfaces smooth, non-porous and resistant to the disinfectants used | medium | Room book, DS finishes | IQ-05 visual inspection and material certificate | passed |
Even this small extract shows the benefit: the open PQ item and the deviation in the alarm test stand out immediately, and the criticality shows that both must be resolved before final approval. If the next qualification stage is to start earlier, Annex 15 (2.10) allows this only as a conditional approval, based on a documented assessment that the open items have no significant impact on the next activity.
Reading forwards and backwards
A traceability matrix should work in both directions. Read forwards, it shows whether every requirement has evidence. Read backwards, it shows whether every test case traces back to a requirement. This second direction is often overlooked. Test steps with no link to the URS are not automatically wrong, but they often point to requirements that were never formally defined, or to testing effort with no clear purpose. Either way, a conscious decision is needed: the requirement is added to the URS, or the test step is dropped with a justification.
The right level of detail
A common question is how detailed the matrix should be. Too coarse, with “HVAC system” as a single line, and it loses its value. Too fine, down to every screw and every cable, and it becomes unwieldy and hard to maintain.
A pragmatic rule is: one line per testable requirement. If a URS requirement contains several independent statements, that is usually a sign that it should be split in the URS itself. For non-critical requirements, grouping can make sense, provided the evidence can still be assigned unambiguously.
Maintenance over the life cycle
A traceability matrix is not a close-out document. It is a working tool:
- Project start: set up with URS IDs and the risk assessment.
- Design: add the FS/DS references. Gaps show early on where a requirement has not been implemented.
- Test planning: assign test cases before the test plans are approved.
- Execution: update result and status, and link deviations.
- Close-out: check for completeness as a prerequisite for the qualification report.
- Operation and changes: for every change, use change control to check which lines are affected, which tests must be repeated and whether new requirements arise. The matrix is versioned and approved again.
This last point in particular is often neglected. A matrix that shows the state at commissioning but no longer holds three changes later is more of a risk than a help in an audit.
Tooling: spreadsheet or dedicated tool?
For most technical qualification projects, a well-structured spreadsheet is sufficient. Everyone involved can access it, it can be filtered and it can be archived as an approved PDF. What matters are fixed column definitions, a locked structure, a version identifier and a clear rule on who may make changes. If the spreadsheet file itself is used as a GMP record, it falls under Annex 11. Otherwise, the approved version is archived as a PDF and is the version of record.
A specialised requirements or validation tool tends to pay off on large projects, with many interfaces or complex computerised systems. If such a tool is itself used for GMP-relevant purposes, the Annex 11 requirements for computerised systems apply, including access control (12.1) and, depending on the risk assessment, an audit trail (9).
Common pitfalls
- Created after the fact: the matrix is put together shortly before the report, and gaps can then only be closed with considerable effort.
- Inconsistent IDs: the URS, the matrix and the protocols use different numbering.
- Status “passed” despite an open deviation: the status must honestly reflect the deviation situation.
- Blanket references: “see OQ” instead of a protocol and test step number.
- No link to risk: all requirements are treated the same, and the depth of testing is not justified.
- No versioning: it is unclear which version of the matrix has been approved.
Value in an audit
In an audit or a regulatory inspection, a common question, asked on a sample basis, is: where is the evidence for this requirement? With a well-maintained traceability matrix, this can be answered quickly, with references to the specification, protocol, raw data and, where applicable, the deviation. That builds confidence in the entire qualification structure. For other points that matter in preparation, read our article on common errors in GMP documentation.
If you want to build an auditable qualification structure with end-to-end traceability, you will find more information under Qualification.