RECORDREFERENCE OUTLINE

CSV Requirements Traceability Matrix

A requirements traceability matrix linking each user and functional requirement to its risk assessment, design specification, and verification test with a result and status — the trace that demonstrates coverage in a GAMP 5 computerised-system validation. Rendered as an editable spreadsheet. Aligned to GAMP 5 (2nd ed.) and EU GMP Annex 11.

What a template is not

A template is a document baseline to adapt inside your own quality system. SPEQ does not approve, validate, or take responsibility for what you issue from it, and using one is not evidence of compliance.

CHECKING ACCESS

Checking your Professional access…

REGULATIONS MAPPED
GAMP 5 (2nd ed.)EU GMP Annex 1121 CFR Part 11
DOCUMENT TYPE
Record
LAST UPDATED
August 2026
PURPOSE

The matrix that proves coverage in both directions: every requirement reaches a test, and every test answers a requirement. It fails in practice not by being absent but by being built at the end from the tests that were run, which produces a tidy table and no coverage evidence. Which requirements are GxP-relevant, and therefore which must be traced, is the organisation’s determination.

What's Inside

✓Requirement register with a unique, stable identifier per requirement, so a later change can be traced rather than guessed
✓Requirement type and GxP relevance, recorded per row because effort follows relevance and relevance needs a decision
✓Risk assessment reference per requirement, linking the test depth to the harm the requirement guards against
✓Design specification reference, showing which configured or coded element actually delivers the requirement
✓Verification test reference and recorded result, with the test protocol version as executed
✓Coverage status per requirement and the reverse view — tests that answer no requirement at all
✓Gap summary and change history, so a requirement added mid-project cannot slip in untested

How to Use It

1Build the matrix from the requirements, not from the tests; a matrix assembled after testing records what happened, not what was covered
2Give every requirement a unique identifier that survives renumbering, and reuse it in the specification and test documents
3Record the risk assessment reference next to each requirement so a reviewer can see why a test is light or heavy
4Link each requirement to the design element delivering it, and challenge any requirement with no design element behind it
5Run the reverse check before closure: a test that maps to no requirement is either scope creep or a missing requirement
6Update the matrix under change control, because the version tested and the version released must be demonstrably the same
DOCUMENT CONTENTS

The full section structure of this template — every section and sub-section, so you can use it as a baseline for your own site document.

—Document Control
› Document Information› Approval Signatures› Revision History› Distribution List
1Requirements Traceability Matrix
2Coverage Summary
REGULATORY CONTEXT

GAMP 5 (2nd ed.) expects requirements to be traceable through risk assessment, specification and verification, and to stay traceable as the system changes. EU GMP Annex 11 and 21 CFR Part 11 require the computerised system to be validated and its records controlled, and this matrix is the coverage evidence for that. None of them defines your requirement identifiers, your risk scale, or where the GxP boundary of your system sits. Those are your determinations, and the matrix makes them visible rather than assumed.

MAPPED STANDARDS
GAMP 5 (2nd ed.)EU GMP Annex 1121 CFR Part 11
Browse the standards catalog →