Skip to main content

Validation and data integrity

What is a requirements traceability matrix in validation, and is it required?

A requirements traceability matrix is a table linking each user requirement to the specification that meets it and to the tests and results that verify it, so reviewers can see that every requirement was tested and every test has a purpose. EU GMP Annex 11 expects user requirements to be traceable throughout the lifecycle but sets no format. The 2025 draft revision names the matrix as one way and says test cases that trace to no requirement do not count.

Illustration of a seal comparing two equipment versions, each linked to its retained evidence.

1What a traceability matrix shows.

Traceability links each requirement forward to the design or configuration that meets it and the tests that verify it, and back again, so nothing is built or tested without a reason. WHO’s guideline on validating computerised systems describes the first link: design qualification may include verification that requirements specifications “are traceable to proposed design and configuration specifications”.¹ FDA’s General Principles of Software Validation, written for medical device software, including software used in device production and quality systems, describes the rest: a software requirements traceability analysis that traces requirements “to (and from) system requirements and to risk analysis results”, and test traceability from unit tests to detailed design, integration tests to high-level design and system tests to software requirements. It recommends control measures, such as a traceability analysis, “to ensure that the intended coverage is achieved”.²

A traceability matrix shows those links in one place: one row per requirement, with columns for the design or configuration item, the test cases, their results and any deviations.

2What the regulations and guidance require.

EU GMP expects traceability, but none of the texts in force below requires a matrix as the format. Neither 21 CFR Part 11 nor the drug CGMP regulations in Part 211 use the term.³⁴ For drugs, FDA’s data integrity guidance treats each CGMP workflow on a computer system as an intended use to be checked through validation.⁵

SourceStatusWhat it says
EU GMP Annex 11, 2011EU GMP guideline in forceUser requirements “should be traceable throughout the life-cycle” (4.4).
Draft Annex 11, 2025Consultation draft, not adoptedDocumented traceability between requirements, design specifications and test cases (6.5); test cases traceable, “e.g. by means of a requirements traceability matrix”, and test cases that trace to nothing “do not meet the requirements” (9.5).
PIC/S PI 006-4, October 2026PIC/S recommendationFor a process validation protocol, a traceability matrix showing how the risk assessment is used “is also helpful” (5.3.3).
WHO TRS 1019 Annex 3, 2019WHO guidelineDesign qualification may verify that requirements are traceable to design and configuration (Appendix 5, 7.2).
FDA General Principles of Software Validation, 2002FDA guidance for device softwareTraceability analysis of requirements, design, code and tests.
FDA Computer Software Assurance, February 2026FDA guidance for device production and quality system softwareThe most detailed scripted testing may include requirements for traceability; requirement traceability tools and automated traceability support assurance.

Sources for the table: Annex 11,⁶ the draft,⁷ PIC/S,⁸ WHO,¹ and FDA.²⁹

For EU GMP work, then, traceability should be demonstrable in some form. The matrix is one format for it, and the draft Annex 11 would name it explicitly.

Each part of a row comes from an expectation in the guidance:

  • The requirement, uniquely numbered and testable, based on documented risk and GMP impact.⁶¹⁰
  • Its risk or criticality, since the extent of validation rests on a justified and documented risk assessment.⁶
  • The design or configuration item that meets it, including the chosen configuration recorded in a controlled configuration specification.⁷
  • The test cases that verify it, or the inspection or analysis that does, since a requirement can be verified by “inspection, analysis or test”.¹⁰
  • The executed result and evidence, such as executed test scripts and, where relevant, screen dumps, with who performed the test and when.⁷⁹
  • Deviations, since validation documentation should include reports on any deviations observed during validation.⁶

A row shows gaps in both directions: a requirement with no passing test, and a test that traces to no requirement.

4Keeping it current.

A matrix built once for go-live and never updated stops showing what is tested. Annex 11 asks for traceability throughout the lifecycle and for changes, including configuration changes, to be made under a defined procedure.⁶ The draft revision would require requirements to be updated as the system changes and encourages “the use of effective tools to capture and hold requirements and facilitate the traceability”.⁷ FDA’s CSA guidance recommends digital records such as system logs and audit trails over paper and screenshots, and counts automated traceability among the ways to reduce manual documentation.⁹

5How it runs in Seal.

In Seal, each requirement links forward to configuration and evidence and back to its rationale, and every execution of a test case is its own test run, so a requirement shows which tests cover it, whether they passed and on which version. The computer system assurance blueprint generates a current trace view from those links rather than one reconciled by hand, and the commissioning and qualification blueprint calculates coverage with an explicit denominator, exposing untested requirements and orphan tests.

Neil can prepare a traceability matrix that keeps mapped, tested and reviewed states apart, since a linked but unexecuted test does not satisfy a requirement. The validation owner approves the coverage and verifies the execution evidence.

References

  1. 1WHO Technical Report Series No. 1019, Annex 3, Good manufacturing practices: guidelines on validation, Appendix 5, Validation of computerized systems, WHO, 2019. https://www.who.int/docs/default-source/medicines/norms-and-standards/guidelines/production/trs1019-annex3-gmp-validation.pdf (read 6 November 2026)
  2. 2General Principles of Software Validation; Final Guidance for Industry and FDA Staff, FDA, 11 January 2002, section 5.2. https://www.fda.gov/media/73141/download (read 6 November 2026)
  3. 321 CFR Part 11, Electronic Records; Electronic Signatures, eCFR. https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11 (read 6 November 2026)
  4. 421 CFR Part 211, Current Good Manufacturing Practice for Finished Pharmaceuticals, eCFR. https://www.ecfr.gov/current/title-21/chapter-I/subchapter-C/part-211 (read 6 November 2026)
  5. 5Data Integrity and Compliance With Drug CGMP: Questions and Answers, Guidance for Industry, FDA, December 2018, question 3. https://www.fda.gov/media/119267/download (read 6 November 2026)
  6. 6EudraLex Volume 4, Annex 11: Computerised Systems, European Commission, revision 1, in operation from 30 June 2011, sections 1, 4 and 10. https://health.ec.europa.eu/system/files/2016-11/annex11_01-2011_en_0.pdf (read 6 November 2026)
  7. 7Annex 11: Computerised Systems, draft for consultation, European Commission and PIC/S, July 2025, sections 6 and 9. https://picscheme.org/docview/9714 (read 6 November 2026)
  8. 8PI 006-4, Recommendations on Qualification and Validation, PIC/S, 1 October 2026, section 5.3.3. https://picscheme.org/docview/11277 (read 6 November 2026)
  9. 9Computer Software Assurance for Production and Quality Management System Software, Guidance for Industry and FDA Staff, FDA, 3 February 2026, section V.A. https://www.fda.gov/media/188844/download (read 6 November 2026)
  10. 10PI 011-3, Good Practices for Computerised Systems in Regulated GxP Environments, PIC/S, 25 September 2007, section 9.3. https://picscheme.org/docview/3444 (read 6 November 2026)

AQuestions and answers

What is the difference between forward and backward traceability in a traceability matrix?

Forward traceability starts from a requirement and follows it to the design and the tests that verify it, showing nothing was left untested. Backward traceability starts from a test or design item and follows it back to the requirement it serves, showing nothing was built or tested without a reason. A traceability matrix shows both.

Does FDA require a traceability matrix?

Part 11 and the drug CGMP regulations do not use the term. FDA’s software validation guidance for devices recommends traceability analysis between requirements, design and tests, and its Computer Software Assurance guidance mentions traceability for its most detailed scripted testing and encourages requirement traceability tools. For drugs, FDA expects each CGMP workflow on a computer system to be validated for its intended use.

Does every requirement need its own test case?

Every requirement needs objective verification, but not always a test. PIC/S says compliance with each requirement should be verifiable by an authorised method, such as inspection, analysis or test. One test case can verify several requirements, and the matrix should show which.

Can a spreadsheet be the traceability matrix?

Nothing in the guidance forbids it, but it has to stay controlled and current through every change, which is hard to do by hand. The draft revision of Annex 11 encourages effective tools to hold requirements and their traceability, and FDA’s CSA guidance favours automated traceability and digital records over manual documentation.

Is the WHO validation matrix the same thing?

No. In WHO’s validation guideline the validation matrix is part of the validation master plan: a table showing the history and status of qualification and validation on site. A requirements traceability matrix links the requirements of one system to its design and tests.

See your process in Seal.

Bring a procedure or a recurring problem. See how your team configures it with Neil and improves the next run.

Book a demo