Traceability Matrix in Computerised System Validation

A traceability matrix is a structured way of showing how a computerised system's intended use, requirements, risks, implementation and verification evidence relate to one another. Its purpose is not to create another validation document for its own sake. It provides a test of completeness: can the organisation demonstrate that important regulated requirements were implemented and verified, and can each material validation activity be traced back to a justified need?

Purpose and Regulatory Context

EU pharmacovigilance requirements do not prescribe a document called a Traceability Matrix. The regulatory framework instead requires an effective pharmacovigilance quality system and adequate control of the computerised systems supporting pharmacovigilance activities.

GVP Module II — Pharmacovigilance system master file (Rev. 2) requires the PSMF to describe the location, functionality and operational responsibility for computerised systems and databases used for safety information and to describe their fitness for purpose. It also expects the validation status of key functionality, change control, testing, back-up arrangements and relevant repositories to be summarised.

A traceability matrix is therefore best understood as one possible validation and lifecycle-control technique used to demonstrate that these expectations are supported by coherent evidence.

Other frameworks may inform validation practice. EU GMP Annex 11, for example, applies to computerised systems used in GMP-regulated activities and requires lifecycle validation based on documented risk assessment. It should not automatically be presented as the legal basis for a standalone pharmacovigilance system unless the relevant GMP scope also applies. Industry guidance such as GAMP 5 may provide useful implementation concepts, but it is not legislation.

What Traceability Is Trying to Prove

Traceability supports two connected propositions:

1. Completeness: important approved requirements have been implemented and adequately verified.
2. Justification: validation tests and controls exist because they support an intended use, requirement or identified risk.

A matrix is useful when it makes those relationships visible. It is not useful when it becomes a large cross-reference table that is difficult to maintain and adds no assurance.

Begin With Intended Use

Validation should begin with what the computerised system is expected to do in the regulated process.

For a pharmacovigilance safety database, intended use may include functions such as:

• intake and maintenance of ICSR data;
• MedDRA coding;
• workflow and case-status control;
• generation or transmission of E2B(R3) messages;
• duplicate management;
• audit trails;
• user access control; and
• production of data used for aggregate analysis or regulatory reporting.

The importance of a requirement depends partly on the consequence of failure. A cosmetic screen-layout preference does not normally require the same assurance as a rule that determines whether a serious report is transmitted to a competent authority.

From Intended Use to Requirements

A useful traceability chain can be represented as:

regulated process → intended use → user requirement → risk → specification/configuration → verification → objective evidence.

Not every organisation uses all of these document names. Some systems combine functional and design specifications; configured commercial systems may rely heavily on supplier documentation and controlled configuration records. Traceability should reflect the actual lifecycle model rather than forcing every project into a historical V-model template.

Requirement Quality Comes Before Traceability

A matrix cannot rescue weak requirements. Each important requirement should be sufficiently clear that a reviewer can understand:

• what capability or control is needed;
• why it is needed;
• how success could be demonstrated; and
• whether the requirement has changed over time.

Stable unique identifiers are useful because they allow requirements to be referenced across specifications, tests, deviations and changes. The numbering convention itself is an organisational choice.

Risk and Traceability

Risk assessment helps determine the depth of evidence required. Relevant considerations may include:

• patient-safety consequence;
• regulatory reporting consequence;
• data integrity;
• detectability of failure;
• complexity;
• degree of configuration or customisation;
• dependence on interfaces; and
• reliance on supplier evidence.

Risk-based validation does not mean that low-risk requirements can simply disappear from the traceability model. It means that the level and form of assurance should be proportionate to the consequence and likelihood of failure.

Forward, Backward and Bidirectional Traceability

Traceability can be viewed in different directions depending on the question being asked.

Forward traceability

Forward traceability starts with an approved requirement and follows it through implementation and verification. It asks:

• Was the requirement implemented?
• Where is the relevant specification or configuration?
• How was it tested?
• What objective evidence demonstrates successful verification?

This is the main completeness test.

Backward traceability

Backward traceability starts with a test, configured function or item of evidence and asks why that activity exists. It helps identify:

• tests with no justified requirement;
• obsolete scripts retained after functionality changed;
• duplicated validation effort; and
• configuration whose regulatory purpose is unclear.

Bidirectional traceability

Bidirectional traceability supports both questions. It is particularly useful during change control because reviewers can start from either a changed requirement or a changed technical component and identify the affected validation evidence.

Typical Traceability Relationships

An organisation may need to link some or all of the following:

The matrix should include only relationships that genuinely support understanding and control.

One Requirement, Multiple Tests

A high-risk requirement can require several forms of evidence. For example, a requirement that ensures compliant E2B(R3) transmission may need:

• message-generation testing;
• gateway/interface testing;
• rejection and acknowledgement handling;
• security/access testing;
• exception-path testing; and
• end-to-end workflow verification.

The matrix should permit one-to-many relationships rather than forcing artificial one-requirement/one-test pairings.

One Test, Multiple Requirements

The reverse is also possible. An end-to-end case-processing scenario can verify workflow, access control, audit trail behaviour, coding, message generation and transmission. One test may therefore support several requirements when the relationship is clear.

Traceability to Risk

A useful matrix does more than show that a requirement was tested. It can also show why the verification depth was selected.

For example:

This does not imply a universal scoring model. The organisation should use a documented risk method appropriate to its quality system.

Supplier Evidence

Modern pharmacovigilance systems often use commercial software-as-a-service platforms. The regulated organisation may rely on supplier testing and documentation where that reliance is justified.

Traceability should make this reliance explicit. If a requirement is verified through supplier evidence rather than repeated customer testing, the record should identify:

• the supplier evidence used;
• why it is considered reliable;
• what configuration or intended-use differences remain to be tested by the customer; and
• any residual risk requiring additional assurance.

Blindly retesting all supplier functionality may waste effort. Blindly accepting all supplier claims may leave important gaps.

Traceability Through Deviations

A failed validation test does not necessarily invalidate the entire system. The traceability model should show:

• which requirement was affected;
• the nature of the failure;
• whether the defect was corrected;
• whether retesting was performed;
• whether other requirements or tests were affected; and
• the final disposition.

This relationship is particularly useful when a deviation reveals that several requirements depend on the same underlying configuration or interface.

Change Control

Traceability becomes most valuable after initial implementation.

When a change occurs, the matrix can support impact assessment by identifying:

• affected requirements;
• related risks;
• specifications or configurations needing revision;
• tests requiring rerun or replacement;
• documentation becoming obsolete; and
• downstream procedures or training that may need change.

The extent of regression testing should follow the impact and risk assessment rather than a fixed rule that every historic script must be rerun.

Periodic Review and Lifecycle Maintenance

Traceability should remain current enough to support continued confidence in the validated state. Periodic review may identify:

• obsolete requirements;
• requirements no longer linked to current tests;
• superseded test evidence;
• unassessed configuration changes;
• supplier changes; or
• interfaces whose validation evidence no longer reflects production reality.

The matrix is therefore a lifecycle artefact rather than a project close-out document.

System Retirement

At retirement, traceability can help determine which records, data migrations, archive controls and read-access arrangements must remain after the operational application is switched off. The final concern is no longer functional testing but preservation of regulated information and the ability to retrieve it for the required period.

Practical Matrix Design

The following columns are commonly useful, but they are recommended practice rather than a regulatory template:

Additional fields may be useful for complex interfaces or supplier evidence. A matrix should not become so wide that maintaining it reliably is more difficult than understanding the underlying validation package.

Illustrative Pharmacovigilance Example

Consider the requirement:

The system shall generate an E2B(R3) message containing the case data required for the applicable reporting route.

A traceability record might connect that requirement to:

• the regulatory reporting business process;
• an assessment identifying submission failure as a high-impact risk;
• the configured message-mapping specification;
• interface configuration;
• positive and negative message-generation tests;
• acknowledgement/rejection handling tests;
• executed evidence;
• any deviations; and
• the release decision.

The example illustrates relationships, not a requirement that every organisation use these exact documents.

Potential Failure Modes

The following are illustrative failure modes rather than reported inspection findings.

Inspection Considerations

For a pharmacovigilance system, an inspector may ask the organisation to demonstrate how critical functionality was validated and how the current state remains controlled. Traceability can help answer questions such as:

• Which requirements support expedited reporting?
• How was this requirement verified?
• Why was this level of testing considered adequate?
• Which supplier evidence was relied upon?
• What happened when this test failed?
• Which requirements were affected by the last major upgrade?
• How do you know the current production configuration remains within the validated state?

The strongest response is a coherent validation lifecycle. A polished matrix cannot compensate for missing requirements, inadequate testing or uncontrolled changes.

Practical Traceability Review Checklist

The following is recommended operational practice.

1. Is system intended use defined?
2. Are critical regulated requirements uniquely identifiable?
3. Is risk used to determine assurance depth?
4. Can each important requirement be traced to implementation evidence?
5. Can each important requirement be traced to adequate verification?
6. Can tests be traced back to a justified requirement or risk?
7. Are one-to-many and many-to-one relationships represented correctly?
8. Is supplier evidence identified where relied upon?
9. Are deviations linked to the requirements they affect?
10. Does change control update the affected traceability relationships?
11. Are obsolete requirements and tests clearly retired rather than silently deleted?
12. Can a reviewer identify the current evidence supporting critical production functionality?
13. Is the matrix proportionate enough to remain maintainable?

Key Takeaways

A traceability matrix is a validation-control technique, not a named pharmacovigilance regulatory deliverable.

Its value lies in demonstrating completeness and justification: important requirements should be implemented and verified, while validation activities should be traceable to intended use or risk.

Traceability should be bidirectional, risk-based and maintained through change control rather than created once at project closure.

Supplier evidence can reduce unnecessary duplicate testing when its applicability and reliability are understood. The regulated organisation remains responsible for assurance that the configured system is fit for its intended use.

For pharmacovigilance, the most important traceability relationships are those supporting patient safety, regulatory reporting, data integrity and reliable system operation.

References

1. European Medicines Agency. Guideline on good pharmacovigilance practices (GVP) Module II — Pharmacovigilance system master file (Rev. 2). EMA/816573/2011 Rev. 2. https://www.ema.europa.eu/en/documents/scientific-guideline/guideline-good-pharmacovigilance-practices-module-ii-pharmacovigilance-system-master-file-rev-2_en.pdf
2. European Medicines Agency. Guideline on good pharmacovigilance practices (GVP) Module I — Pharmacovigilance systems and their quality systems. EMA/541760/2011.
3. European Union. Commission Implementing Regulation (EU) No 520/2012, as amended.
4. European Commission. EudraLex Volume 4, Annex 11 — Computerised Systems. Revision January 2011. https://health.ec.europa.eu/document/download/8d305550-dd22-4dad-8463-2ddb4a1345f1_en
5. European Commission. Stakeholders' consultation on revision of EudraLex Volume 4 Chapter 4, Annex 11 and new Annex 22. Consultation closed 7 October 2025. The revised Annex 11 remained draft consultation material at the time of this article.
6. U.S. Food and Drug Administration. Computer Software Assurance for Production and Quality Management System Software. Final Guidance, February 2026. This is non-binding U.S. medical-device quality-system guidance and is cited only as a contemporary risk-based assurance reference, not as EU pharmacovigilance law.
7. ISPE. GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems, Second Edition. Industry guidance; not legislation.

Regulatory Note

EU pharmacovigilance legislation and GVP require controlled, fit-for-purpose pharmacovigilance systems and appropriate validation evidence, but they do not prescribe a universal Traceability Matrix format. EU GMP Annex 11 applies to GMP-regulated computerised systems and should not be treated as the direct legal basis for every pharmacovigilance application. Industry GAMP guidance and FDA computer-software-assurance guidance are implementation references rather than EU PV requirements. As of 8 September 2026, the current adopted EU GMP Annex 11 remains the January 2011 revision; a revised Annex 11 underwent stakeholder consultation in 2025.