Building a Requirements Traceability Matrix That Survives an Audit

The requirements traceability matrix is the artefact auditors ask for first and the artefact most programmes produce last. Done well, it is the connective tissue that proves every regulatory obligation has a requirement, every requirement has a test, and every test has evidence. Done badly, it is a spreadsheet of broken links assembled in the week before the audit review, which fools no one.

This post covers how to design an RTM that holds up under scrutiny, how to maintain it without suffocating the delivery team, and how to use it as a live artefact rather than a compliance theatre exercise. The patterns here are drawn from programmes in banking, insurance and healthcare, where traceability is not a nice-to-have but a condition of approval.

What the RTM is for

The RTM answers three questions that a regulator, an internal auditor or a steering committee can ask at any point in the programme:

1. Is every regulatory obligation covered by at least one requirement?
2. Is every requirement verified by at least one test?
3. Is every test result retained as evidence with the appropriate sign-off?

If the RTM cannot answer all three questions in under ten minutes, it is not doing its job. The three questions map to three types of gap: compliance gap (obligation not covered), verification gap (requirement not tested), and evidence gap (test done but evidence missing).

For a walkthrough of the related documents, see our posts on BRD vs FRD in regulated change and writing user stories for regulated industries.

The minimum viable matrix

A useful RTM has five columns. Not ten, not twenty.

Column 1: Obligation reference

The regulatory obligation, control objective, or business policy that creates the need for the requirement. For DORA this might be "Article 8 ICT risk management framework". For an internal control it might be "CTRL-023 transaction monitoring control". For a policy it might be "AML Policy v4.2 section 6.1".

Every obligation reference should be stable, versioned, and resolvable. If the obligation text changes, the reference changes, and the RTM surfaces the affected requirements.

Column 2: Business requirement reference

The BRD requirement ID that implements the obligation. One obligation often produces multiple business requirements. One business requirement can address multiple obligations. The many-to-many relationship is why the RTM is a matrix rather than a list.

Column 3: Functional requirement or story reference

The FRD requirement, user story, or technical specification that delivers the business requirement. Again many-to-many. A business requirement may be delivered by multiple stories across multiple sprints.

Column 4: Test case reference

The specific test case that verifies the functional requirement. This is the column that routinely has gaps in programmes we review. Fix the gaps by generating the column automatically from the test management tool, not by hand-filling a spreadsheet.

Column 5: Evidence reference

The evidence artefact (test results, screenshots, log excerpts, sign-off records) retained to prove the test was executed and passed. This column is the one the auditor follows to the source. If the reference does not resolve to a retrievable artefact, the trace is broken.

That is the minimum. Five columns, consistently populated, resolvable to source artefacts. Anything more is decoration. Anything less is incomplete.

Scaling the matrix without drowning in it

A mid-sized regulated programme has tens of thousands of traceability links. Maintaining this in a spreadsheet by hand is a full-time job for several people and fails under change. The matrix must be generated, not maintained.

Tooling approach one: requirements management tools

Polarion, Jama, IBM DOORS Next, Jira with structured plugins. These tools model requirements, tests and evidence as first-class objects with typed relationships. The RTM is a query over the object model, regenerated on demand. Cost: licensing, configuration effort, training. Benefit: an RTM that is always current because it is derived rather than authored.

Tooling approach two: Jira plus reporting layer

If the programme already runs on Jira, a structured approach with custom issue types (obligation, requirement, story, test, evidence) connected by Jira links plus a reporting layer (Jira Structure, Xray, Zephyr, or a custom query) delivers the same capability. This is the approach we recommend for programmes where Jira is entrenched.

Tooling approach three: the pragmatic hybrid

For smaller programmes or early phases, a source-of-truth matrix in a database (even Google Sheets or an Airtable base) with automated import from Jira and test management tools can work. The key is that the links are populated by the teams that own the underlying artefact, not by a separate RTM team.

Whichever approach you take, the business analysis service can help you select and configure the right level of tooling for the risk and scale of the programme.

The discipline that keeps it current

A matrix that is correct at baseline and wrong three months later is worse than no matrix at all, because it creates false confidence. The discipline that keeps it current is simple in principle.

No requirement without obligation

A business requirement without an obligation reference is either goldplating or a sign that the obligation is missing. Either way, the requirement does not enter the baselined BRD until the obligation column is populated.

No story without a requirement

A story without a business requirement reference is either orphan work or a sign that the requirement did not make it into the BRD. Either way, the story does not enter the sprint until the requirement column is populated.

No closed story without a test

A story cannot be marked closed until the test case reference is populated. This is a workflow rule in Jira, not a cultural aspiration. The rule has teeth.

No test marked passed without evidence

A test cannot be marked passed until the evidence reference resolves to a retained artefact. Again, a tooling rule, not a policy.

These four rules, enforced in tooling, are the discipline. The RTM is the output, not the input. When the rules are enforced, the matrix is accurate because it could not be otherwise.

Common failure modes

The spreadsheet that nobody owns

The RTM lives in a SharePoint file that everyone edits and nobody owns. By month four, it has 14 versions, three broken links out of five resolve to deleted tickets, and three teams disagree about which version is current. Fix: move the source of truth to the tools that already hold the underlying artefacts and generate the RTM as a derivative.

The baseline freeze

The RTM is correct at baseline. The baseline is immediately superseded by change requests, new regulations, and scope decisions. The RTM is never updated. By go-live, it describes a programme that no longer exists. Fix: the matrix is generated, not baselined. Every regeneration reflects the current state.

The coverage illusion

The RTM shows 100 percent coverage. On inspection, it turns out that coverage was declared rather than verified. Many "test case" references point to test plans that were never executed. Fix: the coverage metric is based on test execution and passed results, not on test case existence.

The one-way matrix

The matrix traces forward from obligation to test. It does not trace backward from test to obligation, so tests that exist without a corresponding requirement are invisible. Fix: the matrix must support both directions. Orphan tests (tests without a requirement) are just as much a concern as orphan requirements (requirements without a test), because they often indicate goldplated implementation or obsolete test coverage.

The missing non-functional layer

The matrix covers functional requirements but ignores non-functional requirements. Performance, availability, resilience, retention, security. Under regimes like DORA, these are regulated obligations and must be in the matrix. Fix: the NFR specification (see our non-functional requirements for banking platforms post) is a first-class part of the matrix.

Using the matrix in live programmes

The matrix is most valuable not at the end of the programme but throughout it. Four operational uses are worth calling out.

Change impact analysis

When a regulation is clarified or a control objective changes, the matrix shows the blast radius. Every affected requirement, every affected story, every affected test. Change impact becomes a query rather than a forensic investigation. Our change impact assessment resource covers the assessment artefact that works alongside the RTM.

Scope triage

When scope pressure forces a cut, the matrix shows the dependencies. Cutting story 247 may deorbit requirement 42, which may deorbit obligation coverage for FCA SYSC 5.1. The matrix surfaces the consequence before the cut happens.

Pre-audit readiness

Before an audit, the matrix is run in gap-detection mode. Every obligation that does not trace to a tested outcome is a finding waiting to happen. The programme closes the gaps before the auditor arrives, not during.

Go-live checkpoint

At go-live, the matrix provides the readiness evidence. Every obligation covered. Every requirement tested. Every test evidenced. The SMF attestation for the Senior Managers and Certification Regime rests on this evidence.

An honest note on effort

Building and maintaining the RTM is non-trivial effort. On a mid-sized programme it is typically 3 to 5 percent of programme cost, mostly in tooling and the BA capacity to maintain the traceability links. That cost is worth it in regulated scope because the alternative is either a discovery in the audit review (expensive and reputationally damaging) or a post-facto reconstruction exercise (even more expensive).

The programmes we see fail on RTM are usually the ones that tried to make it cheap. The programmes that succeed are the ones that accepted the cost as a condition of regulated delivery and built the tooling and discipline to amortise the cost across the programme.

The BCBS 239 principles make traceability explicit for risk data aggregation in banking, and similar principles appear in Solvency II and MIFID II regimes. The common thread: auditability is a first-order design concern, and traceability is the artefact that makes auditability possible.

The short version

A traceability matrix that is generated, not authored, and enforced through tooling rather than policy, is the only version that works at scale. Five columns, consistently populated. Four enforcement rules at the tooling layer. Regular regeneration, used as a live tool during change impact analysis and scope triage. Evidence references that resolve to retained artefacts.

If you are about to start a regulated programme, investing in the traceability tooling up front is one of the highest-leverage decisions you will make. If you are already in flight and the matrix is behind, the business analysis service can help you close the gap before your next audit review. The regulatory change readiness resource covers the broader readiness assessment that puts the RTM in context.