Requirements Traceability & Critical Aspects
The evidence chain runs user need, intended use, critical aspects, risk, design, verification, acceptance — and traceability is what lets any one of those be followed to the evidence that satisfied it. Without it an organisation can show that testing happened but not that the testing covered what mattered, and the second is the question an inspector actually asks.
What an explainer is not
A topic explainer is SPEQ’s synthesis of what a practice involves, cited to the standards that govern it. It does not reproduce their text, and it does not determine which of them apply to your product or process.
[ POSITION IN THE FRAMEWORK ]
7 DIMENSIONS · 25 LINKSA traceability matrix is a claim that the testing covered what mattered. It fails as evidence exactly when it is complete but every requirement in it is untestable.
06 · QUALITY MATURITY — REQUIREMENTS TRACEABILITY & CRITICAL ASPECTS, REACTIVE TO ADAPTIVE
Everything is traced to everything. The matrix is complete, enormous, and tells nobody which requirements carry the risk.
Critical aspects are identified, but they were selected from a template of typical ones rather than from this process and this equipment.
Criticality is derived from what the process needs and what failure would do, requirements are written so a test could fail them, and the matrix links the two.
The matrix is maintained through change, so a modified requirement is visibly re-verified rather than leaving a link that no longer means anything.
Requirements are authored to be verifiable from the start, so traceability is a by-product of good specification rather than a document assembled afterwards.
SPEQ’s shared five-stage progression, labelled synthesis — not the FDA QMM rating scale. Where does your organization sit? Score your quality system →
07 · REGULATORY & EVIDENCE
GOVERNING STANDARDS · 5
Derived from the 5 standards SPEQ maps to this subject, across 4 regulatory bodies: EMA, ICH, ISPE, ASTM.
RECORDS & OBJECTIVE EVIDENCE
- The critical-aspect determination, with the process reasoning behind each
- Requirements written in verifiable terms, with acceptance criteria
- The traceability matrix linking requirement to verification to result
- Change records showing re-verification where a traced requirement moved
- The rationale for any requirement accepted as verified by supplier evidence
COMMON INSPECTION FINDINGS
- Requirements phrased so that no test could fail them, traced to tests that therefore prove nothing
- Critical aspects copied from a template with no process-specific reasoning
- A matrix complete at qualification and never updated through subsequent change
- Verification results that do not actually address the requirement they are linked to
- Supplier evidence accepted against a critical aspect with no assessment of its adequacy
Critical aspects, not everything
ASTM E2500 reframed qualification around a specific idea: verification effort should concentrate on the aspects of a system that are critical to product quality and patient safety, identified through science- and risk-based assessment, and drawing on subject-matter expertise rather than on a standard document set. EU GMP Annex 15 reaches similar ground by requiring qualification proportionate to criticality.
The practical effect is to replace "test everything to the same depth" with "identify what is critical and test that convincingly". This is more demanding, not less: it requires the organisation to state which aspects are critical and defend the reasoning, where a uniform approach lets the question go unasked. Programmes that adopt the language without doing the assessment end up with the same test volume and a weaker justification.
A traceability matrix is a claim, not a spreadsheet
The matrix is often produced at the end of a project, mapping tests to requirements after both exist, and it then demonstrates only that every requirement has a test next to it. What it should demonstrate is that every critical aspect flows from a user need, is addressed by a design decision, is verified by a test capable of detecting its failure, and has an acceptance criterion tied to the reason it was critical.
The diagnostic is to work backwards from a single critical quality attribute and ask what evidence establishes control of it. In a healthy package the path is short and each link is real. In an unhealthy one the path runs through a requirement stated so generally that its test could not fail, which is the most common way a full matrix conceals a gap.
Requirements that cannot be verified are the root cause
Most traceability failures originate in the specification, not the testing. "The system shall control temperature" cannot be verified in any meaningful way; "the system shall maintain product temperature between 2 and 8 °C, alarm on excursion within 60 seconds, and record the excursion in the batch record" can. The second is harder to write and makes the whole downstream chain possible.
GAMP 5 places supplier assessment and leverage alongside this: where a supplier’s development and testing are robust, that evidence can substitute for re-testing — but only if the requirements are specific enough to judge whether the supplier’s testing covered them. Vague requirements make leverage impossible, so the organisation re-tests everything and calls it rigour.
SPEQ interpretation — traceability is a maintenance obligation
Traceability is built during a project and treated as a project deliverable. Then the system changes: a requirement is superseded, a critical aspect is redefined by a process change, a test is replaced. Unless those changes flow back into the matrix, the traceability degrades into a historical record of what was once true, and its value at the next inspection is close to zero.
The practical control is that change control updates traceability as a required output, not as a documentation task to be caught up later. That is a small procedural addition and it is the difference between a matrix that answers a question in year five and one that has to be reconstructed before it can be shown.
FREQUENTLY ASKED
What are critical aspects?
The features of a system that are critical to product quality and patient safety, identified through science- and risk-based assessment with subject-matter expertise, per ASTM E2500. Concentrating verification on them is more demanding than testing everything uniformly, because it requires stating which aspects are critical and defending the reasoning.
What should a traceability matrix actually demonstrate?
That every critical aspect flows from a user need, is addressed by a design decision, is verified by a test capable of detecting its failure, and has an acceptance criterion tied to why it was critical. A matrix showing every requirement has a test beside it demonstrates only that the columns were filled in.
Why do traceability packages fail inspection?
Usually because of the specification, not the testing. A requirement stated so generally that its test cannot fail creates a complete-looking matrix concealing a gap. Working backwards from a critical quality attribute to the evidence that establishes control of it exposes those paths quickly.
How does traceability relate to supplier leverage under GAMP 5?
Leverage requires requirements specific enough to judge whether the supplier’s testing covered them. Where requirements are vague, the organisation cannot assess the supplier evidence against anything, so it re-tests everything — which is expensive and is not the same as rigour.