Skip to main content
Bureau of AI
Category: Compliance & Audit

Traceability Matrix

Also known as: RTM, Requirements Traceability Matrix, Requirement Traceability Matrix, Traceability Matrix (TM)
Simply put

A traceability matrix is a document or tool that maps requirements to related items such as test cases, deliverables, and issues, so teams can see how each requirement is addressed. It helps confirm that nothing has been overlooked as a project or system evolves. It is commonly used in project management and software development.

Formal definition

A requirements traceability matrix (RTM) is a structured artifact that establishes and maintains bidirectional relationships between requirements and other project artifacts—typically test cases, final deliverables, issues, and source items—to support coverage analysis and change control. As described in the evidence, it is used to map user or functional requirements to test cases and deliverables, enabling practitioners to control the evolution of functionality and verify that each requirement is traced to corresponding validation activities. Note: the evidence describes the RTM in general project management and software development contexts; it does not establish any specific application, mandate, or definition within AI governance or model risk management frameworks, which are out of scope for this entry.

Why it matters

A traceability matrix matters because it provides a structured way to demonstrate that every requirement in a project or system has been accounted for—typically by linking each requirement to the test cases, deliverables, and other artifacts that address it. Without such a mapping, teams can lose track of whether functionality has been implemented, tested, or validated, particularly as requirements change over time. The evidence describes the RTM as a tool for controlling the evolution of functionality, which speaks to its value in managing change: when a requirement shifts, the matrix helps identify which downstream items are affected.

In coverage terms, the traceability matrix supports the practical question of "have we missed anything?" By making the relationships between requirements and validation activities visible, it enables gap analysis and helps teams confirm that each requirement traces to corresponding work. This is a discipline of documentation and control rather than a guarantee of correctness; the matrix records that a link exists, not that the underlying implementation or test is itself adequate.

It is worth noting the scope of this entry. The evidence describes the traceability matrix within general project management and software development. It does not establish any specific role, mandate, or defined meaning for the RTM within AI governance or model risk management frameworks. Readers in those domains should treat any application to AI-specific requirements as a matter of local practice rather than something supported by the sources here.

Who it's relevant to

Project managers
Project managers use a traceability matrix to confirm that requirements are being addressed and to control the evolution of functionality as a project progresses. It supports oversight of scope and helps identify requirements that lack corresponding deliverables or validation activities.
Software development and quality teams
Developers and QA practitioners use the matrix to map requirements to test cases, supporting coverage analysis so that each requirement is linked to the tests intended to validate it. This helps surface gaps where a requirement has no associated test or deliverable.
Business analysts and requirements owners
Those responsible for capturing and managing requirements use the matrix to maintain visibility over how user and functional requirements flow into downstream artifacts, which is useful when requirements change and affected items need to be identified.
AI governance and model risk practitioners (with caveats)
The evidence does not establish a defined role for the traceability matrix within AI governance or model risk management frameworks. Practitioners in these areas may find the general concept of requirement-to-artifact mapping useful for documentation and control purposes, but should treat any such application as local practice rather than a requirement supported by the sources cited here.

Inside RTM

Requirements or Obligations Identifiers
A list of the discrete items being traced, such as regulatory obligations, internal policy requirements, control objectives, or model risk management expectations. Each item is typically assigned a unique identifier so it can be referenced consistently across the matrix.
Linked Implementation or Evidence Artifacts
References to the design elements, controls, documentation, test results, or validation activities that satisfy or address each traced item. In an AI governance context these may point to governance policies and accountability structures; in a model risk management context they may point to validation or verification evidence, though the two should not be collapsed.
Mapping Relationships
The explicit connections between traced items and the artifacts that address them, showing coverage in one direction (from obligation to evidence) and, where used, in the reverse direction (from artifact back to obligation) to identify gaps or orphaned elements.
Status or Coverage Indicators
Fields that record whether a given item is fully addressed, partially addressed, or unaddressed, supporting gap analysis. These indicators reflect current mapping status and do not by themselves confirm that a control is effective.
Ownership and Version Metadata
Attributes such as responsible owner, source reference, and version or date of the entry, which help maintain the matrix over time and support audit and oversight activities.

Common questions

Answers to the questions practitioners most commonly ask about RTM.

Is a traceability matrix the same thing as a model validation report?
No. A traceability matrix is a mapping tool that links requirements, controls, tests, or artifacts to one another so coverage can be demonstrated; it is not itself an assessment of whether a model is fit for purpose. A validation report evaluates conceptual soundness, outcomes, and ongoing monitoring. The two are frequently used together—a matrix can help show that each validation activity traces back to a requirement or risk—but the matrix documents linkage, not judgment. Treating the matrix as evidence that validation was performed adequately is a common error; it evidences coverage, not quality.
Does completing a traceability matrix mean all requirements have been satisfied?
Not necessarily. A completed matrix typically shows that each requirement has been mapped to a corresponding artifact, test, or control, but a mapping only demonstrates that a link exists—not that the linked item passed, was executed correctly, or actually fulfills the requirement. Professionals often conflate 'traced' with 'met.' A row can be fully populated while the associated test failed or the control is ineffective. The matrix supports completeness and coverage analysis; conclusions about satisfaction require reviewing the underlying results.
Who is typically responsible for maintaining a traceability matrix across the lines of defense?
Ownership varies by organization and by how a firm structures its lines of defense. In many arrangements, the model developer or owner in the first line creates and maintains the operational matrix, while a second-line function may review it for adequacy as part of oversight. Third-line or internal audit typically uses it to test whether controls and requirements were actually covered rather than maintaining it themselves. The specific allocation should be defined in policy; the matrix works best when responsibility for updating it is assigned explicitly rather than assumed.
How granular should the entries in a traceability matrix be?
Granularity is a design choice that trades completeness against maintainability. Entries that are too coarse can obscure gaps because one line masks several distinct requirements; entries that are too fine can become burdensome to keep current and may reduce the matrix to noise. As commonly practiced, granularity is set so each traceable item can be independently verified and its coverage assessed. Because appropriate granularity depends on the model's complexity and risk profile, there is no single standard, and the level chosen should be documented so reviewers can interpret coverage consistently.
How is a traceability matrix kept current as a model changes over its lifecycle?
A matrix typically becomes stale unless updates are tied to change-management processes. In practice, revisions to requirements, data, code, or controls should trigger corresponding updates to the affected rows, ideally through defined change controls rather than ad hoc edits. Version control and dating of entries help preserve an audit trail. Because a matrix is a point-in-time representation, its usefulness depends on being maintained alongside the model; treating it as a one-time deliverable is a frequent source of drift between the documented mapping and the actual system.
How can a traceability matrix support audit and regulatory review?
A traceability matrix can help demonstrate that requirements, risks, and controls have been mapped to supporting evidence, which supports coverage and completeness testing during review. It can give reviewers a structured path from a stated requirement to the artifact intended to address it. However, it supports rather than substitutes for the underlying evidence—reviewers generally still examine the linked artifacts to confirm they were executed and are effective. The matrix is most valuable when its links resolve to accessible, current supporting documentation.

Common misconceptions

A traceability matrix proves that requirements or obligations are actually met.
A traceability matrix documents the mapping between items and the artifacts intended to address them; it shows coverage and linkage, not effectiveness. Confirming that a linked control or validation activity actually works is a separate assurance step. The matrix reduces the risk of undetected gaps but does not by itself demonstrate compliance or eliminate risk.
A traceability matrix and validation or verification evidence are the same thing.
The matrix references or links to such evidence but is not the evidence itself. Validation (assessing whether the right thing is being addressed) and verification (assessing whether it was built or done correctly) remain distinct activities; the matrix organizes pointers to their outputs rather than replacing them.
One universal traceability matrix template applies across all frameworks and jurisdictions.
The structure and content of a traceability matrix vary by context and by the framework it supports, and definitions can differ between general AI governance uses and banking-style model risk management uses. Practitioners typically tailor the matrix to the specific obligations, guidance, or standard they are mapping against rather than assuming a single interchangeable format.

Best practices

Assign a unique, stable identifier to each traced item so links remain unambiguous as requirements and artifacts evolve.
Keep the scope of the matrix explicit, stating whether it maps governance obligations, model risk management expectations, or both, so the two are not inadvertently conflated.
Maintain bidirectional traceability where feasible, so you can detect both unaddressed obligations and artifacts that no longer map to any requirement.
Record ownership, source references, and version or date metadata to keep the matrix maintainable and auditable over time.
Treat coverage status indicators as a signal of mapping completeness, not of control effectiveness, and pair the matrix with separate validation or verification activities.
Review and update the matrix on a defined cadence and when underlying requirements, models, or controls change, so it reflects the current state rather than a point-in-time snapshot.