Quick Answer
A Requirements Traceability Matrix, or RTM, is a controlled table that links each approved user requirement to the design documents, risk controls, verification activities, test results, deviations, and final evidence used to demonstrate compliance.
In a cleanroom project, an RTM helps confirm that every relevant requirement has been addressed through DQ, FAT, SAT, commissioning, IQ, OQ, PQ, document review, inspection, or another justified verification method.
It provides a clear line of evidence from:
Requirement → Design → Verification → Result → Final acceptance
Key Takeaways
- An RTM connects user requirements to design and verification evidence.
- It should be created during requirements development, not after qualification.
- Every traceable requirement needs a unique and stable identifier.
- Verification should be assigned according to the nature and risk of the requirement.
- Not every requirement requires a physical test; some can be verified through calculation, document review, inspection, or certificates.
- A completed protocol does not automatically mean every linked requirement has passed.
- Changed, deleted, failed, or nonapplicable requirements require documented justification.
- The RTM should remain current through design, qualification, handover, change, and requalification.
Introduction
Cleanroom projects generate hundreds of technical, operational, quality, safety, documentation, and maintenance requirements.
These requirements may cover:
- Cleanroom classification
- HVAC capacity
- HEPA filtration
- Room pressure relationships
- Temperature and relative humidity
- Airflow direction
- Recovery time
- Wall and ceiling systems
- Doors and interlocks
- Personnel and material flow
- Environmental monitoring
- Alarms and controls
- Utilities
- Cleaning
- Documentation
- Training
- Qualification
The requirements may begin in the User Requirements Specification, but the evidence showing that they have been satisfied is distributed across drawings, calculations, specifications, supplier documents, commissioning records, and qualification protocols.
Without traceability, a project may complete DQ, FAT, SAT, IQ, OQ, and PQ while still failing to answer a basic question:
Where is the objective evidence that each approved requirement has been satisfied?
The Requirements Traceability Matrix answers this question.
For pharmaceutical projects, EU GMP Annex 15 states that the URS should remain a point of reference throughout the validation lifecycle. Although Annex 15 does not prescribe a specific spreadsheet called an RTM, a traceability matrix is an effective way to demonstrate this lifecycle connection.
For GMP computerized systems, EU GMP Annex 11 is more explicit: user requirements should be traceable throughout the lifecycle.
An RTM is therefore best understood as a practical control method rather than a universal document required under exactly the same name for every cleanroom.
What Is a Requirements Traceability Matrix?
A Requirements Traceability Matrix is a structured record showing how each approved requirement is:
- Identified
- Assessed
- Addressed by the design
- Assigned to an appropriate verification method
- Tested or reviewed
- Supported by objective evidence
- Formally closed
A basic RTM may look like this:
| URS ID | Requirement summary | Design reference | Verification reference | Status |
|---|---|---|---|---|
| URS-HVAC-001 | Room shall achieve the specified classification | HVAC-DS-01 | OQ-HVAC-012 | Passed |
| URS-PRE-004 | Room shall maintain positive pressure to the corridor | PRD-01 | OQ-HVAC-018 | Passed |
| URS-DOR-006 | Airlock doors shall be interlocked | DCS-02 | FAT-DOR-004 / OQ-DOR-003 | Passed |
| URS-DOC-003 | Supplier shall provide approved as-built drawings | MDR-01 | IQ-DOC-009 | Open |
A complex regulated project may include additional fields for risk, criticality, acceptance criteria, deviations, results, and approval.
The objective is not to create the largest possible spreadsheet. The objective is to make every important requirement easy to follow from origin to final evidence.
Why Is an RTM Important in a Cleanroom Project?
It prevents requirements from being lost
A requirement may be approved in the URS but overlooked during detailed design.
For example, the URS may require terminal HEPA filters to be accessible for integrity testing and replacement without unnecessary disruption to the classified room.
If this requirement is not traced to the ceiling layout, filter-housing design, maintenance-access strategy, and DQ review, the problem may not be discovered until installation or qualification.
It makes design review more systematic
Drawings and calculations may appear complete while still failing to address a user need.
An RTM allows reviewers to ask:
- Which design document addresses this requirement?
- Is the proposed solution complete?
- Has the responsible discipline reviewed it?
- Is the requirement measurable or otherwise verifiable?
- Does the design provide access for testing and maintenance?
This improves the quality of Design Qualification.
It improves supplier accountability
A supplier may claim general compliance with the specification without showing how each requirement will be met.
A requirement-level matrix can ask the supplier to identify:
- Comply
- Partially comply
- Do not comply
- Not applicable
- Proposed technical solution
- Design reference
- Planned verification
- Assumption or exclusion
This makes technical comparisons more reliable and reduces scope disputes after contract award.
It identifies missing evidence
The RTM can reveal that:
- A requirement has no design reference.
- A design function has no planned test.
- A critical alarm was not challenged.
- A test was planned but not completed.
- A failed result remains unresolved.
- A requirement changed after the related test.
- A protocol was approved but does not cover all assigned requirements.
It supports final system release
Before release, the project team needs to know whether every applicable requirement is:
- Passed
- Accepted by document review
- Accepted by inspection
- Accepted through an approved deviation
- Not applicable with justification
- Open
- Failed
The RTM provides this overview without requiring reviewers to search manually through every project document.
Is an RTM Mandatory for Every Cleanroom?
No. A document specifically titled “Requirements Traceability Matrix” is not universally required for every cleanroom.
Its applicability depends on:
- Regulatory framework
- Facility type
- Product or process
- Computerized-system content
- Project complexity
- Contract requirements
- Internal quality procedures
- Risk
For a pharmaceutical facility, the organization should be able to demonstrate that user requirements remain connected to design and qualification throughout the lifecycle. An RTM is one effective method.
For hospitals, laboratories, electronics facilities, or nonregulated industrial cleanrooms, a simplified requirements verification matrix or compliance matrix may provide sufficient control.
The substance is more important than the document name. The project needs a reliable method for proving that requirements have been addressed.
What Is the Difference Between an RTM and Other Project Matrices?
| Document | Primary purpose |
| Requirements Traceability Matrix | Links each requirement to design and verification evidence |
| Compliance Matrix | Records whether a supplier or design complies with specified requirements |
| Test Matrix | Coordinates tests, responsibilities, locations, and execution stages |
| Risk Traceability Matrix | Links identified risks to controls and verification evidence |
| Document Register | Tracks document submission, revision, review, and approval |
| Validation Status Register | Tracks system qualification, deviations, reports, and release status |
A supplier compliance matrix may become an input to the owner’s RTM, but it does not automatically provide complete lifecycle traceability.
When Should the RTM Be Created?
The RTM should be created when the requirements are approved or sufficiently developed to receive unique identifiers.
A practical sequence is:
- Prepare and approve the URS.
- Assign unique requirement IDs.
- Create the initial RTM.
- Add criticality and risk references.
- Link requirements to functional and design documents.
- Review traceability during DQ.
- Assign FAT, SAT, commissioning, IQ, OQ, or PQ verification.
- Update the matrix as testing is completed.
- Record results and deviations.
- Review all open requirements before system release.
- Maintain traceability during changes and requalification.
Creating the RTM only at the end of the project may expose missing evidence when correction is already costly.
Who Should Own the RTM?
The project owner or regulated user should control the master RTM.
Depending on the organization, day-to-day maintenance may be assigned to:
- Validation
- Quality assurance
- Systems engineering
- Project engineering
- Project controls
Suppliers may maintain subsystem matrices, but the owner should ensure that:
- All systems and interfaces are covered.
- Supplier references align with the approved URS.
- Deviations and exclusions are visible.
- Final evidence is available.
- The master matrix remains under document control.
The validation master plan should define who creates, maintains, reviews, and approves the RTM.
What Information Should an RTM Include?
A practical cleanroom RTM may include the following fields:
| Field | Purpose |
| Requirement ID | Provides a unique and stable reference |
| Source and revision | Identifies the approved originating document |
| Requirement summary | Describes the required outcome |
| System or discipline | Assigns the relevant technical area |
| Criticality | Indicates quality, safety, or operational importance |
| Risk reference | Links the requirement to an identified risk or control |
| Design reference | Shows where the requirement is implemented |
| Verification method | Defines how compliance will be demonstrated |
| Verification stage | Identifies DQ, FAT, SAT, IQ, OQ, PQ, or other stage |
| Acceptance criterion | Defines the condition for acceptance |
| Evidence reference | Identifies the completed record or result |
| Deviation reference | Links failures or approved exceptions |
| Final status | Shows whether the requirement is closed |
Not every project needs every column. The matrix should remain readable and maintainable.
How Should Requirements Be Numbered?
Each requirement should receive a unique identifier that remains stable throughout the project.
Examples include:
- URS-HVAC-001
- URS-ENV-014
- URS-PRE-008
- URS-DOR-006
- URS-EMS-023
- URS-DOC-004
Category codes make it easier to filter and assign requirements.
| Code | Category |
| ARC | Architectural |
| HVAC | HVAC |
| ENV | Environmental conditions |
| PRE | Differential pressure |
| FLT | Filtration |
| DOR | Doors |
| EMS | Environmental monitoring |
| UTL | Utilities |
| DOC | Documentation |
| TRN | Training |
| SAF | Safety |
Identifiers should not be repeatedly renumbered when new requirements are added. Renumbering can break references in specifications, protocols, deviations, and supplier records.
What Makes a Requirement Traceable?
A traceable requirement should be:
- Clear
- Unique
- Necessary
- Unambiguous
- Verifiable
- Consistent
- Assigned to a responsible system or discipline
Poor requirement:
The cleanroom shall have good pressure control.
Improved requirement:
URS-PRE-004: During normal operation with doors closed, Processing Room P-101 shall maintain the approved positive differential-pressure range relative to Corridor C-101.
The improved version identifies:
- The room
- The reference space
- The operating condition
- The door condition
- The expected outcome
Effective traceability therefore begins with a well-written user requirements specification.
Should Every URS Statement Be Included?
Not every sentence in a URS is a requirement.
A URS may also contain:
- Background information
- Definitions
- Scope descriptions
- Assumptions
- References
- Guidance notes
The RTM should focus on mandatory requirements affecting:
- Intended use
- Quality
- Safety
- Performance
- Compliance
- Documentation
- Training
- Maintenance
- Acceptance
Noncritical requirements should not automatically be excluded. They may still be contractual or operational obligations.
Criticality determines the level of review and verification—not whether the requirement exists.
How Should Requirements Be Linked to Risk?
The RTM may link a requirement to the risk it controls.
| Risk | Control requirement | Design solution | Verification |
| Contamination enters a cleaner room | Maintain positive room pressure | Air balance and pressure-control loop | OQ pressure test |
| Both airlock doors open simultaneously | Provide door interlock | Interlock control logic | FAT and OQ challenge |
| HEPA leakage contaminates supply air | Install testable terminal HEPA filtration | HEPA housing with test access | Filter integrity test |
| Environmental excursion is not detected | Provide monitoring and alarms | EMS sensors and alarm functions | OQ alarm test |
This demonstrates that:
- Risks were identified.
- Controls were specified.
- Controls were implemented.
- Controls were verified.
The RTM does not replace the risk assessment. It connects risk decisions to requirements and evidence.
What Verification Methods Can Be Used?
Not every requirement requires a physical performance test.
Possible verification methods include:
- Document review
- Design review
- Calculation review
- Drawing review
- Certificate review
- Visual inspection
- Dimensional measurement
- Material verification
- Functional testing
- Alarm challenge
- Interlock challenge
- Performance measurement
- Environmental testing
- Training-record review
Examples:
| Requirement | Appropriate verification |
| Wall panel shall use the approved material | Certificate review and physical inspection |
| Door shall provide the specified clear opening | Dimensional measurement |
| Pressure alarm shall activate after the approved delay | Functional alarm challenge |
| Room shall meet the specified ISO class | Particle classification test |
| HVAC shall support the design heat load | Calculation review and operational test |
| Maintenance personnel shall be trained | Approved training and competency records |
The verification method should be capable of providing objective evidence for the specific requirement.
How Should Requirements Be Assigned to DQ, FAT, SAT, IQ, OQ, and PQ?
DQ
DQ is suitable for verifying that the proposed design addresses:
- Layout
- Capacity
- Materials
- Pressure concept
- Airflow strategy
- Cleanability
- Maintainability
- System interfaces
- Regulatory design expectations
FAT
FAT may verify:
- Fabrication
- Equipment dimensions
- Components
- Control panels
- Software functions
- Alarms
- Interlocks
- Safety devices
- Supplier documentation
SAT
SAT may confirm:
- Delivery condition
- Reassembly
- Utility connections
- Site configuration
- Communication interfaces
- Local and remote operation
IQ
IQ may verify:
- Installation against approved design
- Equipment identity
- Materials
- Utility connections
- Calibration status
- Labels
- Documentation
- As-built drawings
OQ
OQ may verify:
- Operating ranges
- Airflow
- Pressure control
- Temperature and humidity
- HEPA filter integrity
- Recovery time
- Classification
- Alarms
- Interlocks
- Failure responses
PQ
PQ may verify:
- Integrated performance
- Representative occupancy
- Process loads
- Material movement
- Routine door opening
- Operational environmental conditions
The RTM should assign each requirement to the most appropriate stage. One requirement may require evidence from more than one stage.
Can FAT and Commissioning Evidence Be Used in the RTM?
Yes. FAT, SAT, and commissioning evidence may support qualification when:
- The method is appropriate.
- Acceptance criteria were approved.
- Instruments were suitable and calibrated.
- Test conditions were documented.
- Personnel were qualified.
- Deviations were controlled.
- Records are complete and traceable.
- Changes after testing do not invalidate the result.
For example, a door interlock may be tested during Factory Acceptance Testing and confirmed again after site installation.
The RTM should show what each test demonstrated and whether additional site verification was required.
How Should Changes Be Managed in the RTM?
When a requirement changes, the RTM should be reviewed for impact on:
- Design documents
- Risk assessments
- Supplier scope
- Completed tests
- Planned protocols
- Acceptance criteria
- Deviations
- Final system status
The original requirement should not simply disappear.
The matrix should identify whether the requirement was:
- Revised
- Replaced
- Deleted
- Added
- Made not applicable
The reason and approval reference should be recorded.
If a requirement changes after testing, the project must determine whether the existing evidence remains valid or whether additional verification is required.
How Should Deviations Appear in the RTM?
If a requirement fails or is only partially met, the RTM should link to the relevant deviation.
The matrix should not show “Passed” solely because the protocol containing the test was approved.
Possible statuses include:
- Passed
- Accepted by review
- Accepted with approved deviation
- Not applicable with justification
- Open
- Failed
A requirement accepted through deviation should identify:
- Deviation number
- Impact assessment
- Justification
- Corrective action
- Approval
- Any operational restriction
Final closure must be based on the actual evidence and approved disposition.
How Should the RTM Be Reviewed Before Handover?
Before system release, the project team should confirm that:
- Every applicable requirement appears in the RTM.
- Every critical requirement has an approved design reference.
- Verification methods are appropriate.
- Planned tests were completed.
- Evidence references are accurate.
- Changes have been incorporated.
- Deviations have been assessed.
- Open items are clearly identified.
- Final statuses are supported by evidence.
- Conditional acceptance is approved and controlled.
The RTM should be reviewed against actual reports and records, not completed from memory.
A final RTM is a key component of a defensible cleanroom validation conclusion.
Buyer’s Checklist
Before accepting an RTM, confirm that:
- The RTM references the current approved URS revision.
- Every mandatory requirement has a unique identifier.
- Requirement wording has not been changed by uncontrolled summaries.
- System and discipline responsibilities are assigned.
- Critical requirements are identified.
- Relevant risk references are included.
- Each requirement has a design reference.
- Each requirement has an appropriate verification method.
- DQ, FAT, SAT, IQ, OQ, and PQ assignments are justified.
- Acceptance criteria were defined before testing.
- Evidence references identify actual completed records.
- Supplier exclusions and deviations are visible.
- Changed and deleted requirements remain traceable.
- Open and failed requirements are clearly identified.
- The matrix supports both forward and backward traceability.
- Final status is based on evidence rather than protocol completion alone.
- The RTM is approved and under document control.
Common Misconceptions
“The RTM is only needed at the end of the project.”
Creating it at the end identifies problems too late. Traceability should begin during requirements and design development.
“Every requirement must be tested during OQ.”
Requirements should be verified at the most appropriate stage. Document review, calculation, inspection, FAT, IQ, OQ, or PQ may be suitable depending on the requirement.
“If the protocol passed, all linked requirements passed.”
A protocol may contain several tests and deviations. Each requirement must be evaluated against its specific evidence and acceptance criterion.
“Only critical requirements need to appear in the RTM.”
Noncritical requirements may still be operational or contractual obligations. Criticality affects verification depth, not basic accountability.
“A large RTM is automatically a good RTM.”
An oversized matrix with duplicated requirements, vague references, and outdated statuses may be less useful than a concise, controlled matrix with reliable evidence.
Expert Tip
Build the RTM from the requirement forward, then review it backward before release.
First ask:
Does every requirement have a design solution and verification result?
Then ask:
Does every test and design feature link back to an approved requirement, risk, or applicable obligation?
This bidirectional review identifies both missing evidence and unnecessary testing.
Frequently Asked Questions
What does RTM stand for?
RTM stands for Requirements Traceability Matrix. It links requirements to design, verification, results, and final acceptance evidence.
Is an RTM required by EU GMP Annex 15?
Annex 15 does not prescribe a document specifically called an RTM. It requires lifecycle-based qualification and expects the URS to remain a reference throughout validation. An RTM is an effective method for demonstrating this traceability.
Who prepares the RTM?
Validation, engineering, systems engineering, or project controls may maintain it. The project owner or regulated user should control and approve the master traceability record.
Can Excel be used for an RTM?
Yes. Excel is suitable for many projects if access, revisions, approvals, formulas, status definitions, and change history are appropriately controlled. More complex projects may use dedicated requirements-management software.
Can one RTM cover the whole facility?
Yes, but large projects are often easier to manage with system-level matrices consolidated into a master status overview.
Should the complete requirement text be copied into the RTM?
The full text or an accurate controlled summary may be used. If summarized, the source document, revision, ID, and location must be clearly identified.
Can one requirement have several test references?
Yes. A requirement may require design review, installation inspection, operational testing, and performance verification before it can be fully closed.
What happens when a requirement is not applicable?
The matrix should state “Not Applicable” and record a documented justification and approval. The requirement should not simply be deleted.
When is an RTM complete?
It is complete when all applicable requirements have approved design and verification evidence, deviations and changes have been assessed, and the final statuses support the system-release decision.
Conclusion
A Requirements Traceability Matrix provides the evidence chain connecting what a cleanroom must achieve to how it was designed, tested, and accepted.
Its value does not come from the number of rows or columns. It comes from answering four questions clearly:
- What was required?
- How was it implemented?
- How was it verified?
- What evidence supports final acceptance?
When created early and maintained throughout the project, the RTM improves design review, supplier accountability, qualification planning, deviation control, and final handover.
For cleanroom buyers and project owners, it transforms a large collection of specifications, drawings, protocols, and reports into a structured demonstration that the completed facility is fit for its intended use.
Further reading：