Part 12

URS → Risk Assessment → Design → FAT/SAT → IQ → OQ → PQ → SOP/Control → Final Qualification Status

It specifically requires explanation of why traceability is important, unique requirement numbering, tracing critical requirements, identifying untested requirements, managing the effect of changes on traceability, supporting inspection readiness, and providing a practical example matrix.

12.1 What Is a Traceability Matrix?

A Traceability Matrix (TM) is a controlled qualification document or record that establishes documented linkage between requirements and the lifecycle evidence used to demonstrate that those requirements have been appropriately addressed.

In a pharmaceutical qualification program, it answers:

What was required, why was it important, where was it designed, where was it verified, what evidence demonstrates compliance, and what is its final status?

A mature traceability system creates an evidence chain from the original requirement through qualification and operational control.

12.2 Fundamental Traceability Model

INTENDED USE
      │
      ▼
     URS
      │
      ▼
GMP / SYSTEM IMPACT
      │
      ▼
RISK ASSESSMENT
      │
      ▼
DESIGN / DQ
      │
      ▼
FAT / SAT
      │
      ▼
     IQ
      │
      ▼
     OQ
      │
      ▼
     PQ
      │
      ▼
SOP / LIFECYCLE CONTROL
      │
      ▼
FINAL QUALIFICATION STATUS

This supports the master handbook’s overarching principle:

Intended Use → Requirements → Risks → Design → Critical Aspects → Verification/Testing → Deviations → Traceability → Qualified State → Lifecycle Control.

12.3 Why Traceability Is Important

Qualification involves many documents generated across different lifecycle stages.

Without traceability, an organization may have:

• an approved URS;
• risk assessment;
• DQ;
• FAT;
• SAT;
• IQ;
• OQ;
• PQ;

yet still be unable to demonstrate that every relevant requirement has been appropriately addressed.

The question is not:

Do we have all the qualification documents?

The stronger question is:

Can we demonstrate that the applicable requirements and risks have been addressed by appropriate lifecycle evidence?

12.4 Purpose of the Traceability Matrix

The Traceability Matrix can help demonstrate:

Requirement coverage

Each applicable requirement has been addressed.

Risk coverage

Critical/high-risk aspects have appropriate verification.

Design linkage

Requirements are connected to their design solution where appropriate.

Test coverage

Verification activities are linked to requirements.

Gap detection

Untested or incompletely addressed requirements can be identified.

Change management

Changed requirements can be traced to affected lifecycle documents.

Inspection readiness

Evidence can be retrieved quickly during an audit or inspection.

12.5 Traceability Is More Than URS-to-OQ Mapping

A weak traceability matrix may contain only:

This provides limited lifecycle visibility.

A more useful model can establish:

Requirement → Criticality/Risk → Design → Verification → Operational Control → Final Status

The exact level of detail should remain proportionate to system complexity and risk.

12.6 Requirements Should Be Uniquely Numbered

Your source requires URS requirements to be:

Specific, measurable, achievable, relevant, testable, traceable, unambiguous, and uniquely numbered.

Unique numbering allows each requirement to maintain its identity throughout the qualification lifecycle.

For example:

• URS-GEN-001
• URS-MEC-001
• URS-UTL-001
• URS-INS-001
• URS-AUT-001
• URS-DI-001
• URS-SAF-001

12.7 Example Requirement Numbering Structure

A practical coding system might be:

Example:

URS-AUT-014

This immediately identifies the requirement as an automation-related requirement.

The coding convention itself is a company/project design choice; the source requires unique numbering but does not prescribe these particular prefixes.

12.8 Requirement IDs Should Remain Stable

Once approved, a requirement ID should remain traceable.

If:

URS-025 = Audit Trail Requirement

then URS-025 should not later be silently reused for:

Backup Requirement

Otherwise historical traceability becomes unreliable.

When requirements change, revision/change control should preserve the history.

12.9 Requirement Description

The matrix should contain enough information to identify the requirement.

Example:

Actual wording must come from the approved URS rather than being reconstructed during matrix preparation.

12.10 Criticality Classification

Traceability should distinguish requirements that have greater GMP significance.

Possible classifications may include:

• GMP critical;
• quality critical;
• safety critical;
• data-integrity critical;
• business/operational;
• non-GMP.

Classification terminology should follow the company’s approved methodology.

The source specifically requires qualification scope to consider potential impact on:

• product quality;
• patient safety;
• identity;
• strength;
• purity;
• quality;
• CPPs;
• CQAs;
• GMP records;
• data integrity;
• environmental conditions;
• cross-contamination;
• utilities.

12.11 Traceability to Risk Assessment

A requirement should be linked to applicable risk assessment entries where relevant.

Example:

This demonstrates that testing intensity was not chosen arbitrarily.

12.12 Risk Drives Verification Strategy

A useful lifecycle relationship is:

Requirement
     ↓
GMP Impact
     ↓
Potential Failure
     ↓
Risk Assessment
     ↓
Critical Aspect
     ↓
Verification Strategy
     ↓
Objective Evidence

Your master framework states that risk assessment should determine:

What needs to be tested, why it needs testing, how extensively it should be tested, and where documented supplier/commissioning evidence may be leveraged.

12.13 Traceability to Design

The matrix may identify the design document that satisfies a requirement.

Example:

URS-UTL-005

requires a defined compressed-air supply.

The design solution may be documented in:

• P&ID;
• utility specification;
• equipment drawing;
• technical specification;
• design specification.

The traceability record could therefore show:

URS-UTL-005 → DS-UTL-004 → P&ID-CA-002

12.14 Traceability to DQ

DQ should establish whether the proposed design adequately addresses applicable requirements.

Example:

A DQ reference should point to identifiable evidence rather than simply stating:

“See DQ.”

12.15 Traceability to FAT

FAT can provide early evidence for certain requirements.

Examples:

• mechanical functionality;
• control sequences;
• alarms;
• interlocks;
• HMI functions;
• recipe functions;
• instrumentation;
• electrical functions.

Example:

URS-SAF-010 → FAT Test FAT-SAF-006

However, FAT does not automatically replace site qualification.

Your source specifically requires assessment of what FAT evidence may potentially be leveraged during qualification and the conditions required before relying on supplier testing.

12.16 Traceability to SAT

SAT may provide site-specific confirmation of:

• shipment condition;
• installation;
• utility connections;
• electrical connections;
• communication;
• safety functions;
• PLC/HMI/SCADA;
• alarms;
• FAT punch-list closure;
• site-specific differences.

Example:

URS-AUT-012 → FAT-AUT-08 → SAT-AUT-03

This shows both supplier and site verification.

12.17 Traceability to IQ

IQ traceability is particularly relevant to requirements involving:

• equipment identification;
• installation;
• components;
• product-contact materials;
• utilities;
• piping;
• electrical installation;
• instrumentation;
• calibration;
• software/firmware versions;
• network connections;
• safety devices;
• drawings;
• manuals;
• as-built documentation.

Example:

URS-MEC-004 → IQ-MEC-006

12.18 Traceability to OQ

OQ is often a major source of verification evidence for functional requirements.

Typical areas include:

• operating sequences;
• control loops;
• setpoints;
• alarms;
• interlocks;
• safety functions;
• failure modes;
• emergency stop;
• PLC logic;
• HMI;
• SCADA;
• access controls;
• recipe controls;
• audit trails;
• backup/restore;
• reports;
• challenge testing.

Example:

URS-SAF-001 → OQ-SAF-004

12.19 Traceability to PQ

Requirements relating to performance under representative routine-use conditions may be traced to PQ.

Examples might include:

• equipment throughput;
• load handling;
• sustained operation;
• reproducibility;
• representative operating conditions.

Example:

URS-PRC-010 → PQ-PER-002

PQ should not be used simply because a requirement was forgotten during OQ.

12.20 Traceability to SOPs and Controls

Some requirements are implemented or maintained through procedural controls.

Examples:

• operation;
• cleaning;
• calibration;
• preventive maintenance;
• backup;
• access management;
• audit-trail review;
• recipe management;
• change control.

Your source specifically identifies these SOP categories as potentially necessary before GMP release.

Example:

URS-DI-014 → OQ-DI-010 → SOP-AT-001

This demonstrates both technical verification and ongoing procedural control.

12.21 End-to-End Traceability Example

Consider:

URS-DI-007

The system shall restrict configuration changes to appropriately authorized users.

Possible lifecycle trace:

URS-DI-007
     │
     ▼
GMP Impact Assessment
     │
     ▼
Risk RA-DI-004
Unauthorized configuration change
     │
     ▼
Design Specification
Role-based access
     │
     ▼
FAT-AUT-015
Initial functional verification
     │
     ▼
OQ-SEC-008
Role/access challenge
     │
     ▼
SOP-ACC-001
User-access management
     │
     ▼
Final Status: VERIFIED

This is substantially stronger than merely writing:

“URS-DI-007 — Pass.”

12.22 Forward Traceability

Forward traceability asks:

Starting with a requirement, where was it addressed and verified?

Example:

URS-001
  ↓
RA-005
  ↓
DS-003
  ↓
OQ-012
  ↓
SOP-006
  ↓
Final Status

This helps identify requirements with missing downstream evidence.

12.23 Backward Traceability

Backward traceability asks:

Why was this test performed? Which requirement or risk does it address?

Example:

OQ Test 27
     ↑
RA-014
     ↑
URS-AUT-009

This is useful for identifying:

• unnecessary testing;
• orphan tests;
• unclear test rationale;
• requirements introduced informally during qualification.

12.24 Bidirectional Traceability

A mature matrix supports both:

Requirement → Evidence

and

Evidence → Requirement

This creates a defensible qualification evidence chain.

12.25 Critical Requirement Traceability

Critical requirements deserve particular attention.

A practical matrix may contain:

The organization should be able to explain why each critical requirement received the chosen level of verification.

12.26 Critical Requirements Should Not Disappear

One of the most important traceability reviews is:

Are all GMP-critical requirements accounted for?

The final matrix should not contain unexplained critical requirements with:

• blank test references;
• “N/A” without justification;
• unresolved status;
• missing risk linkage;
• missing evidence.

12.27 Identifying Untested Requirements

The matrix should actively expose gaps.

Example:

This is exactly the type of gap that should be identified before qualification closure.

12.28 An Untested Requirement Is Not Automatically a Failure

A requirement may be addressed by means other than direct site testing where appropriately justified.

Possible evidence may include:

• design review;
• certificate;
• FAT;
• supplier evidence;
• inspection;
• commissioning evidence;
• procedural control.

But the rationale for relying on that evidence should be documented.

The matrix should not hide the absence of direct testing.

12.29 Example of Justified Non-Retest

Suppose a mechanical dimension was:

• verified at FAT;
• documented in controlled supplier records;
• unaffected by transportation/installation;
• reviewed and accepted under the approved qualification strategy.

The matrix could show:

The acceptability depends on the specific risk, evidence and qualification strategy.

12.30 Orphan Requirement

An orphan requirement is a requirement with no appropriate downstream evidence or disposition.

Example:

URS-AUT-027
      ↓
      ?

This should trigger investigation before qualification closure.

12.31 Orphan Test

An orphan test has no clear requirement, risk or qualification rationale.

Example:

?
↓
OQ-TEST-037

The question becomes:

Why was this test performed?

The test may still be legitimate, but its rationale should be identifiable.

12.32 Traceability Gap Categories

Potential gaps include:

Requirement gap

Requirement has no verification.

Risk gap

Identified critical risk has no corresponding control/verification.

Design gap

Requirement not adequately addressed in design.

Verification gap

Design exists but has not been adequately verified.

Documentation gap

Testing occurred but evidence/reference is missing.

Procedural gap

Technical function exists but lifecycle control is absent.

Change gap

Requirement changed but downstream documentation was not updated.

12.33 Traceability Status Codes

A company may use controlled status categories such as:

• Verified;
• Partially Verified;
• Not Verified;
• Not Applicable;
• Open;
• Closed;
• Superseded.

If abbreviations are used:

• V = Verified
• PV = Partially Verified
• NV = Not Verified
• NA = Not Applicable

Definitions should be controlled and consistently applied.

12.34 “N/A” Requires Justification

Do not use N/A as a convenient way to close gaps.

Weak:

URS-045 → N/A

Better:

URS-045 → N/A because requirement was formally removed under approved Change Control CC-017; revised URS Rev. 03 supersedes the original requirement.

The evidence should support the disposition.

12.35 Changes Affect Traceability

Your master framework specifically requires explanation of how changes affect traceability.

When a requirement changes, potentially affected documents include:

• URS;
• risk assessment;
• design specification;
• DQ;
• FAT/SAT;
• IQ;
• OQ;
• PQ;
• SOP;
• training;
• maintenance;
• calibration;
• computerized-system documentation.

12.36 Change Traceability Model

CHANGE REQUEST
      │
      ▼
Affected Requirement?
      │
      ▼
URS Impact
      │
      ▼
Risk Impact
      │
      ▼
Design Impact
      │
      ▼
Qualification Impact
      │
      ▼
SOP / Training Impact
      │
      ▼
Traceability Matrix Update
      │
      ▼
Approval / Closure

This is consistent with the source’s change-control model:

Change → GMP Impact → Risk Assessment → Qualification Impact → Required Testing → Documentation Update → Approval → Implementation → Verification → Closure.

12.37 Example — PLC Change

Suppose PLC logic controlling an equipment interlock is modified.

Original trace:

URS-SAF-009 → RA-SAF-004 → DS-AUT-015 → OQ-INT-006 → Verified

After the change:

CC-026 → Updated Risk Assessment → Revised PLC Logic → Regression/Impact Testing → OQ-INT-006A → Updated Traceability → Verified

The historical evidence should remain traceable.

12.38 Example — New Operating Range

Suppose the equipment was originally qualified for:

20–60 rpm

and a change proposes:

20–80 rpm.

Potential traceability impact:

URS operating range

↓

Risk assessment

↓

Design/equipment capability

↓

OQ upper-range challenge

↓

PQ/process validation impact where applicable

↓

SOP/recipe update

↓

Traceability update

↓

Release

12.39 Traceability and Deviations

If verification generates a deviation, the matrix should not simply mark the requirement “Pass.”

Example:

This provides a transparent evidence trail.

12.40 Traceability and Retesting

Example:

URS-AUT-006
      ↓
OQ-AUT-009
      ↓
FAIL
      ↓
DEV-032
      ↓
Investigation
      ↓
Correction
      ↓
Approved Retest OQ-AUT-009-R1
      ↓
PASS
      ↓
Final Status: Verified

Do not remove the original failed test reference.

Your source explicitly identifies re-testing without investigation and discarding failed results as unacceptable practices.

12.41 Traceability and Open Items

An open item should be visible during qualification closure.

Possible categories:

• critical open item;
• noncritical punch item;
• documentation item;
• deferred item;
• change-related item.

The qualification summary report should evaluate open items, CAPAs, change controls, traceability status and outstanding risks before recommending the qualified state.

12.42 When Should the Traceability Matrix Be Prepared?

Traceability should not be treated only as a final administrative activity.

A stronger lifecycle approach is:

Requirements stage

Establish requirement IDs.

Risk/design stage

Add risk and design references.

FAT/SAT stage

Add supplier/site verification.

IQ/OQ stage

Add qualification references.

PQ stage

Add performance evidence.

Closure

Review completeness and final status.

Thus, the matrix evolves throughout the project.

12.43 Traceability Matrix as a Living Lifecycle Document

URS Approved
    ↓
TM Version 1
    ↓
Risk/DQ Completed
    ↓
TM Updated
    ↓
FAT/SAT Completed
    ↓
TM Updated
    ↓
IQ/OQ Completed
    ↓
TM Updated
    ↓
PQ Completed
    ↓
TM Final Review
    ↓
Qualification Summary

This approach identifies gaps earlier.

12.44 Who Prepares the Matrix?

Responsibilities depend on the company’s Pharmaceutical Quality System.

A typical arrangement might involve:

The exact ownership should be defined by the project’s approved governance model.

12.45 Recommended Traceability Matrix Fields

A comprehensive matrix may contain:

Not every field is necessarily applicable to every system.

12.46 Practical Traceability Matrix Template

This table is illustrative; actual references must come from the controlled qualification package.

12.47 Detailed Example — Tablet Compression Machine

Your master framework later requires a complete worked example for a tablet compression machine, including traceability of critical requirements through qualification evidence.

A simplified traceability example follows.

12.48 Example — Emergency Stop Trace

A complete evidence chain could be:

INTENDED USE
      ↓
URS-CM-005
Emergency Stop
      ↓
RA-CM-005
Failure could create safety/equipment risk
      ↓
DQ-CM-010
Emergency-stop circuit/design reviewed
      ↓
FAT-CM-011
Function tested at vendor
      ↓
IQ-CM-012
Emergency-stop devices installed/identified
      ↓
OQ-CM-010
Emergency stop challenged
      ↓
SOP-CM-001
Operating/emergency response
      ↓
FINAL STATUS
VERIFIED

This shows why the requirement exists and where evidence resides.

12.49 Example — Audit Trail Traceability

For computerized equipment:

URS-DI-010
Audit Trail Requirement
       ↓
RA-DI-007
Data-integrity risk
       ↓
Functional/Configuration Specification
       ↓
DQ
       ↓
FAT where applicable
       ↓
IQ
Software/configuration baseline
       ↓
OQ
Create / Modify / Challenge / Review
       ↓
Audit-Trail Review Procedure
       ↓
Periodic Review
       ↓
Qualified State

The source requires computerized and automated system qualification to appropriately integrate access controls, audit-trail assessment/testing, electronic records, backup/restore, security, periodic review and applicable GAMP 5, Annex 11 and Part 11 considerations.

12.50 Traceability for Data Integrity Requirements

Potential data-integrity requirements may include:

• user access;
• administrator control;
• audit trails;
• electronic records;
• electronic signatures where applicable;
• data storage;
• backup;
• restore;
• retention;
• time synchronization;
• interfaces.

Each should be traceable to appropriate verification and lifecycle control rather than grouped under a vague statement such as:

“Computer system validated.”

12.51 Traceability for Alarm Requirements

Example:

URS-ALM-003 → Risk RA-ALM-002 → Design DS-ALM-004 → FAT-ALM-003 → OQ-ALM-007 → SOP Alarm Response → Verified

OQ should challenge applicable alarm functions rather than merely confirm that an alarm exists.

12.52 Traceability for Calibration Requirements

Example:

URS-INS-005
Critical pressure transmitter
      ↓
RA-INS-003
      ↓
Instrument Specification
      ↓
IQ Instrument Verification
      ↓
Calibration Certificate
      ↓
OQ Functional Challenge
      ↓
Calibration SOP
      ↓
Periodic Calibration

The source emphasizes that a calibration sticker alone is not sufficient evidence that an instrument is appropriate for its intended GMP use.

12.53 Traceability for Cleaning Requirements

A cleaning-related equipment requirement may be traced through:

URS → Design/Material/Surface Finish → DQ → FAT/IQ → Cleaning Procedure → Cleaning Validation where applicable

This helps distinguish:

• equipment qualification evidence;
• procedural cleaning control;
• cleaning-validation evidence.

12.54 Traceability for Maintenance

Example:

URS-MNT-004 → Design Maintenance Access → DQ → IQ Manual/Spare Parts → Preventive Maintenance SOP → PM Program

Not every maintenance requirement necessarily requires an OQ test.

The matrix helps show how it is appropriately addressed.

12.55 Traceability for Documentation Requirements

Example:

URS-DOC-002 → Vendor Documentation Requirement → FAT Document Review → IQ Manual Verification → Final Handover → Verified

Evidence could include:

• manuals;
• drawings;
• certificates;
• spare-parts list;
• maintenance instructions.

12.56 Traceability Review Before Qualification Closure

Before closing qualification, perform a formal completeness review.

Ask:

Requirements

• Are all approved URS requirements listed?
• Are requirement IDs correct?
• Are obsolete requirements identified?

Risk

• Are critical requirements linked to applicable risks?
• Are critical risks adequately controlled/verified?

Verification

• Is every applicable requirement addressed?
• Are test references correct?
• Are untested requirements justified?

Deviations

• Are failed tests linked to deviations?
• Are retests traceable?
• Are CAPAs reflected?

Changes

• Are post-URS changes included?
• Are revised requirements reflected?

Lifecycle

• Are required SOPs identified?
• Is the final requirement status clear?

12.57 Final Traceability Reconciliation

A useful final reconciliation may show:

This provides a rapid completeness check.

12.58 Requirement Coverage Calculation

For management purposes, a project may calculate:

Requirement Coverage (%) = Verified Applicable Requirements ÷ Total Applicable Requirements × 100

However:

100% numerical coverage does not by itself demonstrate adequate qualification.

A requirement marked “verified” must be supported by appropriate evidence.

12.59 Traceability Matrix Review

The reviewer should not merely check whether every row contains text.

Review should challenge:

• Does the reference actually address the requirement?
• Was the critical aspect adequately challenged?
• Is the cited test approved/executed?
• Did the test pass?
• Was there a deviation?
• Was the deviation appropriately resolved?
• Is the evidence still valid after subsequent changes?

12.60 QA Review Perspective

QA may focus particularly on:

• requirement completeness;
• critical requirement coverage;
• unexplained gaps;
• deviations;
• failed tests;
• change controls;
• retest justification;
• final status;
• qualification conclusion.

The matrix can therefore become an important input to the Qualification Summary Report.

12.61 Inspector Perspective

Your source explicitly anticipates inspector questions such as:

“Show traceability from requirement to test.”

“Why was this test performed?”

“Why was this requirement not tested?”

“Show me the deviation.”

“Who approved the re-test?”

“What raw data supports this result?”

A well-maintained Traceability Matrix allows these questions to be answered efficiently.

12.62 Inspector Question — “Show Me URS-027”

A strong evidence response might proceed:

URS-027

↓

RA-014

↓

Design Specification DS-08

↓

DQ-06

↓

FAT-12

↓

OQ-17

↓

Raw Data Attachment OQ-17-A

↓

Pass

↓

Final Status Verified

The inspector can follow the evidence chain.

12.63 Inspector Question — “Why Was This Not Tested?”

A strong answer should point to documented rationale.

For example:

Requirement verified through approved design review and FAT evidence; site retesting was determined unnecessary under the approved risk-based qualification strategy because the verified attribute was unaffected by shipment or installation.

The exact justification must be supported by the actual qualification records.

12.64 Inspector Question — “Why Did You Test This?”

A strong answer:

The test verifies URS-AUT-012 and controls the risk identified in RA-AUT-006.

Weak answer:

“Because the vendor’s standard protocol included it.”

Vendor protocols should support the site’s requirements and risks, not define them blindly.

12.65 Inspector Question — “What Happened to the Failed Test?”

Strong evidence chain:

URS → OQ Test → Failed Result → Deviation → Investigation → Corrective Action → Approved Retest → Passing Result → Final Disposition

Potential red flag:

Only the successful retest is visible in the final matrix.

12.66 Common Traceability Deficiencies

12.67 Traceability Matrix Version Control

The matrix should be controlled according to the site’s document system.

Where updated during the lifecycle, maintain:

• document number;
• revision;
• effective/approval information;
• change history;
• preparer;
• reviewer;
• approver;
• controlled status.

Historical traceability should not be destroyed when the matrix changes.

12.68 Electronic Traceability

Traceability may be managed electronically.

Potential benefits include:

• automatic requirement linkage;
• status dashboards;
• gap identification;
• change history;
• reporting;
• controlled workflows.

But electronic management does not remove the need for:

• data integrity;
• appropriate access;
• change control;
• record retention;
• review;
• approval.

12.69 Traceability During Periodic Review

Traceability is also useful after initial qualification.

When a significant change occurs, the matrix helps identify:

Which requirements and qualification evidence could be affected?

Periodic review may consider deviations, calibration history, maintenance, changes, CAPA, alarm trends, qualification status, software changes, audit-trail concerns, data-integrity events, SOP changes and recurring failures.

12.70 Traceability and Requalification

Example:

Change CC-045
     ↓
Affected URS:
URS-AUT-004
URS-AUT-006
URS-DI-003
     ↓
Affected Risks
     ↓
Affected OQ Tests
     ↓
Targeted Requalification
     ↓
Traceability Updated
     ↓
Qualified State Reconfirmed

This supports risk-based requalification rather than automatically repeating every historical qualification test.

12.71 Traceability Matrix Approval

Before final qualification closure, the matrix should be reviewed and approved according to the company’s PQS.

The approval confirms, as applicable, that:

• applicable requirements are accounted for;
• verification references are complete;
• gaps are dispositioned;
• deviations are traceable;
• changes are incorporated;
• critical requirements have appropriate evidence.

12.72 Relationship With Qualification Summary Report

The Traceability Matrix answers:

Were applicable requirements addressed?

The Qualification Summary Report answers the broader question:

Considering all qualification evidence, deviations, open items, risks and traceability, can the equipment/system be considered appropriately qualified for its intended use?

Therefore:

IQ/OQ/PQ Results
      +
Deviation Status
      +
Risk Status
      +
Traceability Matrix
      +
SOP/Training Readiness
      ↓
Qualification Summary Report
      ↓
Final Disposition

12.73 Practical Master Traceability Template

12.74 Traceability Review Checklist

URS Control

• □ Every applicable URS requirement has unique identification
• □ Requirement wording corresponds to approved URS
• □ Superseded requirements identified
• □ New requirements incorporated through approved change

Risk

• □ Critical requirements linked to applicable risks
• □ High-risk failure modes appropriately addressed
• □ Risk controls traceable

Design

• □ Design solution identified where relevant
• □ DQ evidence referenced
• □ Design changes incorporated

FAT/SAT

• □ Leveraged evidence clearly identified
• □ FAT references accurate
• □ SAT/site-specific verification identified
• □ Punch-list impact assessed

IQ

• □ Installation requirements traced
• □ Calibration evidence traced where relevant
• □ Software/configuration baseline traced where relevant

OQ

• □ Functional requirements traced
• □ Alarms/interlocks traced
• □ Challenge tests linked
• □ Data-integrity functions addressed where applicable

PQ

• □ Performance requirements traced
• □ Representative/worst-case evidence linked where applicable
• □ Reproducibility evidence referenced

Deviations

• □ Failed tests retained
• □ Deviations referenced
• □ Retests traceable
• □ Final disposition documented

Changes

• □ Change controls referenced
• □ Affected requirements identified
• □ Requalification evidence linked

Lifecycle Controls

• □ Applicable SOPs identified
• □ Maintenance/calibration controls identified where appropriate
• □ Data-integrity controls identified
• □ Periodic/requalification controls considered

Closure

• □ No unexplained blank requirements
• □ N/A entries justified
• □ Open items evaluated
• □ Final status assigned
• □ Matrix reviewed
• □ Matrix approved

12.75 Golden Rule of Traceability

A Traceability Matrix should not merely prove that qualification documents exist. It should demonstrate that applicable requirements and risks are connected to appropriate design, verification, deviation, change and lifecycle-control evidence.

12.76 Part 12 — Key Takeaway

A robust pharmaceutical Traceability Matrix establishes a defensible evidence chain:

Intended Use → URS → GMP Impact → Risk → Design/DQ → FAT/SAT → IQ → OQ → PQ → SOP/Control → Deviation/Change History → Final Qualification Status

Its primary functions are to demonstrate:

1. Requirement completeness — Applicable URS requirements are uniquely identified and accounted for.

2. Risk linkage — Critical requirements and failure modes are connected to appropriate controls and verification.

3. Design traceability — Requirements can be traced to their design solution where relevant.

4. Verification coverage — FAT, SAT, IQ, OQ and PQ evidence can be linked to applicable requirements.

5. Gap visibility — Untested, partially verified or unresolved requirements are visible rather than hidden.

6. Deviation transparency — Failed tests, investigations, CAPAs and retests remain traceable.

7. Change control — Requirement and qualification changes remain connected throughout the lifecycle.

8. Operational control — SOPs and other lifecycle controls are linked where relevant.

9. Inspection readiness — The organization can rapidly answer: What was required? Why was it critical? Where was it tested? What happened if it failed? What evidence proves its final status?

10. Qualified-state assurance — The final matrix supports the conclusion that the equipment/system has a coherent, traceable body of evidence supporting its intended GMP use.

Part 13 — Protocol Requirements. It requires to define the complete content of qualification protocols—including document identification, purpose, scope, references, responsibilities, system description, prerequisites, test instruments, calibration, methodology, acceptance criteria, test scripts, raw-data requirements, attachments, deviations, change control, retesting, summary and approvals—and to explain why protocols should normally be approved before execution.

About the Author

Ramesh Palav is a pharmaceutical professional with 20+ years of industry experience in manufacturing, GMP, quality systems, validation, compliance, and operational excellence. Through Pharma Manufacturing Hub, he shares practical insights on pharmaceutical careers, manufacturing, quality, validation, Pharma 4.0, AI, and professional development.

His goal is to help students, freshers, experienced professionals, and career-break professionals build the knowledge and skills needed to succeed in the pharmaceutical industry.