Software Testing in Regulated Industries: Audit Evidence, the Requirements Traceability Matrix, and Release Readiness

If an audit is coming, the strongest evidence you can hand over is a requirements traceability matrix (RTM) where every approved requirement links to a test, every test links to a recorded run on a named build, and every failure links to a defect with a decision. In most regulated audits, you also need to show the quality controls behind that chain and the named person who signed off at each step. Together, those records let an auditor pick any requirement and follow it to proof without asking your team to explain anything.

It also pays off outside the audit room. In a controlled experiment by Mäder and Egyed, developers with traceability available were, on average, 24% faster and produced 50% more correct solutions on maintenance tasks than developers without it.

Below is how auditors read a traceability matrix, what common frameworks ask for, how to build one that survives sampling, how to use the same matrix to decide whether a release is ready to ship, and how AI-generated code puts pressure on the human sign-off regulated teams depend on.

What Do Auditors Look For When They Review Your Software Testing?

Auditors in regulated industries usually review a sample of your testing records instead of re-running the tests. In financial audits, PCAOB AS 2315 defines audit sampling as applying an audit procedure to less than 100% of the items in a population. In QualityLogic’s experience, regulatory inspections and certification audits tend to work the same way: the auditor picks a requirement, a change, or a release and asks to see the trail behind it. Your audit evidence has to answer that request with records created when the work happened.

What Questions Sit Behind Most Testing Audits?

Whatever the framework, the questions an auditor brings tend to reduce to these:

• What was the system supposed to do? An approved, versioned requirement or design input.
• How do you know it does that? A test with an expected result written before it ran.
• Who checked, on what, and who signed off? An execution record with the build or version, date, and person, plus a sign-off from someone with the authority to approve the result.
• What happened when something failed? A linked defect, a fix, a retest, or a documented decision to accept the risk.

QualityLogic’s CTO, Jim Zuber, frames similar questions as the release gate for testing AI-generated code in regulated industries. The questions don’t change when the code author does.

What Counts as Audit Evidence in Compliance Testing

Audit evidence is any record that proves a control or requirement was met, created when the work happened. For software testing, that usually includes:

• Approved requirement and test case versions
• Execution logs, screenshots, or exported results tied to a specific build
• Defect records with status history and retest results
• Approvals and sign-offs from named people with the authority to give them
• The traceability matrix that links all of the above

A spreadsheet or dashboard that says “Pass” with no build number, date, or link to the run is a status report. Auditors are more likely to treat it as a claim that still needs proof.

What Is a Requirements Traceability Matrix in a Regulated Project?

A requirements traceability matrix is a table (or a set of linked records in a tool) that maps each requirement to the tests that verify it, the results of those tests, and any defects found. In regulated work, it also links requirements to the risks or hazards they control.

The FAA’s verification guide describes its version as a “matrix correlating requirements and the associated verification method(s)”, with methods of analysis, demonstration, inspection, or test. In practice, that means some requirements are verified by inspection or analysis, and the matrix should record that method in the row instead of leaving it blank.

Forward, Backward, and Bidirectional Traceability

Auditors can follow any of three directions when they trace a requirement:

• Forward traceability runs from requirement to test to result. It proves coverage: nothing approved went untested.
• Backward traceability runs from test or defect back to requirement. It proves every test and code change exists for an approved reason.
• Bidirectional traceability does both, which is what most regulated frameworks expect.

The graphic shows six linked records. Forward tracing reads left to right and proves coverage. Backward tracing reads right to left and proves nothing was built or tested without an approved reason.

Why the RTM Becomes a Deliverable in Regulated Work

In many commercial projects, the RTM is an internal checklist that teams skip under deadline pressure. Regulated teams can’t skip it. For them, the matrix is the index to their audit evidence. Uplatz’s software testing course puts it this way: in healthcare, aviation, and finance, the RTM is “almost always the exact artifact they ask to see.”

What Do Different Frameworks Expect From Your Traceability Matrix?

The wording and the legal weight change from one framework to the next. 21 CFR Part 11 and DORA are binding regulations, the FDA documents are nonbinding guidance, DO-178C is an RTCA document the FAA recognizes as an acceptable means of compliance, and PCI DSS is an industry standard. Each one asks for records that show what was tested and on which version. Named approval is explicit in some, such as PCI DSS 6.5.1, conditional in others, and absent from some.

The table below lists each framework, its type, what it asks you to trace or control, and the evidence that answers it. The sections after it cover each one in more detail.

Framework	Type	What It Asks You to Trace or Control	Evidence That Answers It
FDA Premarket Guidance for Device Software Functions (2023)	Nonbinding FDA guidance	Identified hazards traced to the risk control measures, the software requirements that implement them, and the tests that verify them	Trace records in any format, sized to the Basic or Enhanced documentation level
FDA Computer Software Assurance for Production and Quality Management System Software (February 2026)	Nonbinding FDA guidance	Assurance activities scaled to the process risk of each software feature used in production or the quality management system	Records of the assurance activities, with unscripted testing as an option for features that aren’t high process risk
21 CFR Part 11	Binding FDA regulation	Validated electronic records systems and changes to those records	Secure, computer-generated, time-stamped audit trails that keep prior entries visible
DO-178C (recognized in FAA AC 20-115D)	RTCA standard	Trace data between system requirements, high-level requirements, and tests at every software level, extending to low-level requirements and source code at Levels A to C	Trace data, review records, and test results for each objective that applies at the software level
PCI DSS v4.0.1, Requirement 6.5.1	Industry standard	Every change to system components in the production environment	Reason for and description of the change, documented security impact, documented approval by authorized parties, testing that the change doesn’t hurt security, testing of bespoke and custom software against Requirement 6.2.4, and procedures to address failures and return to a secure state
EU DORA, Articles 24 and 25 (applies from January 17, 2025)	Binding EU regulation	A risk-based digital operational resilience testing program	A documented testing program and its results. Article 25 gives a non-exhaustive list of example tests, from vulnerability assessments and source code reviews to performance, end-to-end, and penetration testing

Sources: FDA, eCFR, RTCA and FAA, PCI Security Standards Council, EUR-Lex.

Medical Device Software: FDA QMSR, Premarket Guidance, IEC 62304, and CSA

FDA’s Quality Management System Regulation took effect February 2, 2026, and incorporates ISO 13485:2016 by reference. Design verification and validation records now sit inside that framework.

For premarket submissions, FDA’s device software functions guidance says “each requirement identified in the software requirements specification should be traceable.” It also lets you present traceability “in a separate document linking together software requirements specifications, software design specifications, testing and identified hazards.” It also asks you to trace each identified hazard to the verified risk control measures, with test names and identifiers that show pass or fail results.

The final guidance asks for traceability without naming a “traceability matrix” as the required format. A matrix is the most common way to show it, but a well-linked set of records in a test management tool can do the same job.

IEC 62304 adds the risk side. Clause 7.3.3 expects traceability from each hazardous situation to the software item, the software cause, the risk control measure, and the verification of that control. A matrix without a risk column can’t show those links.

In February 2026, FDA issued Computer Software Assurance for Production and Quality Management System Software, which supersedes the September 24, 2025 version. The guidance applies to software used in medical device production or the quality management system. It describes “a risk-based approach to establish confidence in the automation” used there, says documentation “need not include more evidence than necessary,” and allows unscripted methods such as exploratory testing for features that aren’t high process risk.

For device manufacturers, that means the traceability matrix should carry a risk rating per requirement, so a reviewer can see why a high-risk function got scripted testing and a lower-risk one got exploratory testing.

Pharma and Life Sciences: Computer System Validation and Part 11

Computer system validation (CSV) is the traditional term for proving that software used in GxP processes does what it should. Under 21 CFR 11.10, electronic records systems need “secure, computer-generated, time-stamped audit trails” where “record changes shall not obscure previously recorded information.”

That second line affects how you store test evidence. If a tester can overwrite a failed result with a pass and leave no history, the record won’t support a Part 11 review.

FDA’s Computer Software Assurance guidance applies to medical device production and quality management system software, so it’s covered in the medical device section above. For pharma GxP systems, validation and record controls still follow Part 11 and the GxP regulations that apply to each record.

Aviation: DO-178C

DO-178C expects trace data between certification artifacts, and how far the traces go depends on the software level. At Levels A to C, the traces run from system requirements to high-level requirements, low-level requirements, source code, and tests. At Level D, the low-level requirement and source code objectives don’t apply, so the traces stop at high-level requirements and the tests that verify them. The number of objectives scales with software level, from 26 at Level D to 71 at Level A. FAA Advisory Circular 20-115D recognizes DO-178C as “an acceptable means, but not the only means” of compliance.

Financial Services: SOX, PCI DSS v4.0.1, and DORA

Compliance testing in finance tends to focus more on changes than requirements. Auditors often pick a production change and ask for the ticket, the approval, the test evidence, and the deployment record.

1. SOX: The act’s Section 404 requires an assessment of internal control over financial reporting. The IT general controls auditors test come from SEC interpretive guidance (Release 33-8810) and PCAOB auditing standards such as AS 2201, which refers to general controls over program changes, access to programs, and computer operations. Auditors test whether changes to financially relevant systems were authorized, tested, and approved before release.
2. PCI DSS v4.0.1: Requirement 6.5.1 expects change procedures that cover six elements: the reason for and description of the change, documented security impact, “documented change approval by authorized parties,” testing to verify the change doesn’t hurt system security, testing of bespoke and custom software changes against Requirement 6.2.4 before deployment, and procedures to address failures and return to a secure state. The standard’s future-dated requirements became mandatory after March 31, 2025.
3. EU DORA: The Digital Operational Resilience Act applies from January 17, 2025. Article 25 gives a non-exhaustive list of tests a financial entity’s testing program can include, such as vulnerability assessments, source code reviews, scenario-based tests, performance testing, end-to-end testing, and penetration testing.

For fintech teams, that means a traceability matrix should link to change tickets and requirements. A change-centered view of the same data is often what a SOX or PCI assessor asks for first.

How Do You Build a Requirements Traceability Matrix That Holds Up in an Audit?

An audit-ready RTM comes from building traceability into the work as it happens. A matrix filled in the week before an audit tends to show it: missing versions, vague evidence fields, and results that can’t be tied to a build.

Step 1: Give Every Requirement a Stable ID and a Version

Each requirement needs a unique ID that never gets reused, plus a version number that changes when the wording changes. Without versions, you can’t show which version of a requirement a test verified.

Step 2: Link Each Requirement to Its Risk

Rate each requirement’s risk (patient safety, financial impact, data integrity, security) and record the risk ID. This column justifies how much testing and documentation each requirement received, which is the core logic behind FDA’s CSA guidance.

Step 3: Map Tests and the Verification Method

Link every requirement to at least one test case, and record the method (test, inspection, analysis, or demonstration). If a requirement is verified by a design review instead of a test, say so in the row.

Step 4: Record Execution Against a Named Build

Every result needs the build or release candidate it ran on, the date, and who ran it. “Pass” on build 4.1 tells an auditor nothing about build 4.2.

Step 5: Link Defects and Their Disposition

Every failed test should link to a defect. Every defect needs a disposition: fixed and retested, deferred with a risk rationale, or rejected with a reason.

Step 6: Store Evidence Where It Can’t Be Silently Changed

Keep logs, screenshots, and signed results in a controlled system with an audit trail. The matrix should link straight to each item so the auditor can open it.

Step 7: Freeze a Matrix Version for Every Release

Baseline the RTM at each release. An auditor asking about version 3.2 needs the matrix as it stood when 3.2 shipped, not today’s version.

The graphic compares two RTM rows for the same requirement and test. Row one holds up in an audit: it shows requirement and test versions, a hazard link, the exact build, a closed and retested defect, and signed evidence. Row two shows only a requirement ID, a test ID, and “Pass,” with no build, risk, or evidence location, so an auditor can’t tell which build passed or which version of the requirement was tested.

What Should a Requirements Traceability Matrix Template Include?

A basic requirements traceability matrix template has four columns: requirement ID, description, test case ID, and status. That works for internal tracking. For regulated work, add the fields auditors sample.

Column	What Goes In It	Why Auditors Look at It
Requirement ID and Version	The unique ID for the requirement and its current approved version	Proves which approved version was tested
Requirement Source	Where the requirement came from, such as a user need, regulation clause, or change request	Shows why the requirement exists
Risk ID and Rating	The ID of the hazard or risk the requirement controls, and its risk rating	Justifies the depth of testing
Verification Method	The method used to verify, such as testing, inspection, analysis, or demonstration	Covers requirements that aren’t tested by execution
Test Case ID and Version	The unique ID for the test case and its version	Links to the expected result written before execution
Build or Release Tested	The build or release candidate the test ran on	Ties the result to what shipped
Result, Date, and Executed By	The result, the date the test ran, and the name of the person who ran it	Shows who checked and when
Defect IDs and Disposition	The IDs of any defects found and how each one was resolved	Closes the loop on failures
Evidence Location	A direct link to the run log, screenshots, or exported results	Lets the auditor open proof without help
Approval	The name of the person who approved the result, and the date	Shows authorized sign-off

Use the same requirements traceability matrix template across products so auditors see one consistent structure. If your team works in Agile, the requirement column can hold user stories and acceptance criteria, as long as each story has a stable ID and an approval record.

How Does a Traceability Matrix Decide Release Readiness?

Release readiness in a regulated environment is a documented decision that the build meets its approved requirements, with known risks accepted by someone who has the authority to accept them. The traceability matrix provides the evidence for that decision.

The flowchart walks through five checks in order. A “yes” moves to the next check, and a “no” leads to the fix that has to happen before the release moves forward:

1. Is every approved requirement linked to at least one test? If not, write the missing tests, or record how the requirement is verified another way.
2. Did those tests run on the release candidate build? If not, rerun the affected tests and the regression suite on the release candidate.
3. Does every failure have a linked defect and a decision? If not, triage the failure, then fix and retest or accept it with a written rationale.
4. Are open defects risk-rated and signed off by a named owner? If not, have someone with the authority to accept the risk sign off on it.
5. Is the evidence stored, versioned, and retrievable without help? If not, move the evidence into a controlled repository before the release ships.

When all five checks pass, the release is ready to ship, with the evidence to show it.

Coverage on the Build You’re Shipping

The most common gap shows up when verifying that tests have run on the release candidate build (step two). Tests passed on an earlier build, then a late fix went in. A change in one area can break features that nobody meant to touch, so the safest approach is to rerun the affected tests and the full regression suite on the release candidate. If a team decides to reuse any earlier results, it should document the impact analysis behind that decision and who approved it.

A dependable regression testing cycle is what makes a late fix safe to ship without restarting the whole test pass.

Open Defects With a Named Risk Owner

Shipping with open defects is normal. Open defects that nobody signed off are more likely to draw an audit finding. Each open item needs a severity, a risk assessment, and a named approver.

Freeze the Evidence Package at Release

At release, freeze the RTM version, the test results, the defect list, and the approvals together. That package is what you’ll hand over when an auditor asks about this release months from now.

Why Do Traceability Matrices Fail Audits?

Most traceability problems show up during maintenance, after the matrix was first built. Uplatz’s software testing course on traceability makes the point directly: “if a matrix falls out of date, it quickly becomes worse than having no matrix at all,” because “it creates a false sense of confidence about your coverage.”

These are the gaps that come up most often in regulated teams:

1. Requirements updated, tests not: a requirement changed from v2 to v3, but the linked test still verifies v2 behavior.
2. Orphaned tests: tests that trace to no requirement, which usually means a stale test or a requirement nobody documented.
3. Empty rows: approved requirements with no linked test or stated verification method.
4. Vague citations: the matrix says something like “see test tool” instead of linking to the specific run.
5. No risk link: medical device teams describe this one often. One commenter on r/MedicalDevices wrote: “The biggest pain point I keep seeing is the traceability gap between design inputs and verification testing.”
6. Matrix rebuilt by hand before audits: teams export from their issue tracker into a spreadsheet days before the visit, so the matrix shows a snapshot nobody reviewed during development.

Should You Manage Your Traceability Matrix in a Spreadsheet or a Tool?

A spreadsheet can work for a small product with a stable set of requirements and one team. It falls apart when requirements change often, several teams test in parallel, or you need Part 11 audit trails, because spreadsheets don’t record who changed a cell and what it said before.

A test management or application lifecycle management (ALM) tool links records automatically and keeps history. The tradeoff is setup and discipline: links are only as good as the habit of creating them during the work. Whichever you choose, the fields in the template above still apply, and someone has to own the matrix and review it at every release.

What Should You Do When the Audit Is Already on the Calendar?

We hear this request during consultations: “we have an upcoming audit and need evidence of our testing.” Usually the audit date is set, and the testing evidence is spread across a tracker, a shared drive, and someone’s laptop. It’s better to be prepared and proactive, but if you’re scrambling, the best steps we recommend are:

1. Confirm scope: find out which systems, releases, and controls are in scope.
2. Build the matrix for the highest-risk requirements first: patient safety, financial reporting, and security controls come before cosmetic features.
3. Find the gaps honestly: list requirements with no test, tests with no build reference, and failures with no defect link.
4. Close gaps with new testing: if evidence doesn’t exist, run the test now on the current version and record it with today’s date. Backdating evidence turns a gap into an integrity problem.
5. Fix the process for the next release: make traceability part of how tests get written and run, so the next audit doesn’t need a scramble.

Timing depends on how many systems are in scope and how much evidence already exists. A single product with partial records is a different job from a platform with five years of undocumented releases. If you’re on a timeline and want the work done right, contact QualityLogic. Our team responds quickly and makes sure the job is done correctly.

How QualityLogic Helps Teams Prepare Testing Evidence for Audits

QualityLogic’s approach for regulated clients starts with the audit or exam date and works backward, building evidence into testing from day one. Each test maps to a requirement, with results, logs, and defect history kept in the client’s own test management tool. Every test script and artifact QualityLogic builds is delivered to the client’s repository, so the client owns the evidence after the engagement ends.

More than 90% of QualityLogic’s work is in regulated industries, and QualityLogic has run QA programs since 1986 with a US-based team. QualityLogic is also SOC 2 Type 2 compliant. Your auditor decides what satisfies a control, and the evidence is there for them to review. For the platforms, tools, and standards QualityLogic covers, see its technical capabilities.

If you’re in healthcare, see QualityLogic’s healthcare and HIPAA software testing. For banking, payments, and fintech, see QA for financial services. If you need a test strategy and traceability approach before the testing starts, contact QualityLogic about your audit date and what’s in scope.

How Does AI-Generated Code Affect Human Sign-Off in Regulated Testing?

AI coding tools have raised the volume of code teams commit, and the capacity to verify that code hasn’t kept up. In Sonar’s 2026 State of Code Developer Survey, developers said AI accounts for 42% of the code they commit. In the same survey, 96% said they don’t fully trust that AI-generated code is functionally correct, yet only 48% said they always check it before committing.

Most of the frameworks above still rely on a person to approve the result, and PCI DSS 6.5.1 says so outright. AI can produce changes faster than any reviewer can reasonably verify by reading them, so a sign-off can go through on schedule while the code under it has had less verification than the approval suggests. When that unverified code reaches production in regulated software, it’s a liability that tends to surface during an audit, a recall, or an incident.

QualityLogic’s approach starts with a documented, testable definition of correct behavior before code is generated. From there, QualityLogic runs verification in parallel with code generation, keeps test design independent of the model that wrote the code, and captures evidence as the work happens, so the person signing off has records to stand behind. Read more in testing AI-generated code in regulated industries.

Your Requirements Traceability Matrix Is Your Audit Evidence

A requirements traceability matrix is most useful when the same data does three jobs: it proves coverage, it decides whether a release is ready, and it gives an auditor a trail they can follow without help. Build it during the work, link it to risk, tie every result to a build, record who signed off, and freeze a version at every release.

If an audit is on the calendar and your evidence isn’t where it needs to be, QualityLogic can help you scope what’s at risk and build traceable testing around your date. Contact QualityLogic to start with your scope, including how much of your code is AI-generated.

Frequently Asked Questions

What Is a Requirements Traceability Matrix in Software Testing?

A requirements traceability matrix maps each requirement to the tests that verify it, the test results, and any defects found. In regulated industries, it also links requirements to risks and approvals. It’s the document auditors usually use to sample your testing.

Is a Traceability Matrix Required by FDA?

FDA asks for traceability, and a matrix is the most common way to show it. The 2023 premarket guidance for device software functions says each software requirement “should be traceable” and allows that traceability to be presented in a separate document. It doesn’t mandate one specific format. It also expects identified hazards to trace to verified risk control measures.

What Is the Difference Between Computer System Validation and Computer Software Assurance?

Computer system validation (CSV) is the traditional approach to proving GxP software works as intended, often with heavily scripted test documentation. Computer software assurance (CSA) is FDA’s risk-based approach for medical device production and quality management system software. The current guidance, issued in February 2026, scales testing and documentation to the process risk of each feature and allows unscripted testing for features that aren’t high process risk.

What Evidence Do Auditors Ask for in Compliance Testing?

Compliance testing evidence usually includes approved requirements, test cases with expected results, execution records tied to a specific build, defect records with dispositions, and named approvals. Financial auditors also tend to sample production changes and ask for the ticket, approval, and test results behind each one. Many auditors also look for evidence of the quality controls behind each step and the named person who signed off.

How Often Should a Traceability Matrix Be Updated?

Update it whenever a requirement, test, or build changes, and baseline a version at every release. A matrix updated only before audits tends to show missing versions and stale links that auditors are likely to question.

Can We Use Jira or Excel for a Requirements Traceability Matrix?

Yes, both are common. Excel works for small, stable projects but doesn’t keep a change history for Part 11 purposes. An issue tracker or test management tool can link requirements, tests, and defects, as long as your team creates the links during the work and controls who can change results.

What Is Bidirectional Traceability?

Bidirectional traceability means you can trace forward from a requirement to its tests and results, and backward from a test, defect, or code change to the requirement that justifies it. IEC 62304 and DO-178C expect both directions, though at DO-178C Level D the traces stop at high-level requirements and their tests.

How Do You Show Test Coverage to an Auditor?

Show the percentage of approved requirements with at least one linked test and a recorded result on the release build, broken out by risk level. Then be ready to open any row and show the underlying execution record. Coverage claims without linked evidence are more likely to draw follow-up questions.

What Happens If Gaps Are Found in Our Testing Evidence Before an Audit?

Document the gap, run the missing tests on the current version, and record the results with the real date. Then fix the process that caused the gap. Backfilling or backdating records creates a data integrity problem that is worse than the original gap.

How Long Does It Take to Prepare Testing Evidence for an Audit?

It depends on how many systems are in scope, how much evidence already exists, and how traceable it is today. A single product with partial traceability needs far less work than a platform with years of undocumented releases. Start by confirming which systems, releases, and controls are in scope.

Can You Reuse Test Results From an Earlier Build?

The safest approach is to rerun the affected tests and the regression suite on the release candidate. Late changes can break features in areas nobody meant to touch. If a team does reuse earlier results, it should document the impact analysis and who approved the reuse.

Who Has to Sign Off on Testing Evidence in a Regulated Audit?

It depends on the framework. PCI DSS 6.5.1 requires documented change approval by authorized parties, FDA’s CSA guidance calls for approval when appropriate, and many quality systems expect a named approver on test results and releases. Record the approver’s name and the date in the matrix either way.

How Does AI-Generated Code Change Audit Evidence?

AI raises the volume of code faster than teams can verify it, while most regulated frameworks still rely on a person to stand behind the result. Define correct behavior before code is generated, verify it with tests that are independent of the model that wrote the code, and capture evidence as the work happens.