Part 2

A critical principle applies throughout:

Not every document listed below is universally mandated by regulation as a separately titled document.

The required package depends on the system’s intended use, GMP impact, complexity, risk, applicable regulations, company Pharmaceutical Quality System (PQS), and project strategy. Documents may also be combined where this produces an equally clear, controlled, and traceable evidence package.

2.1 Purpose of the Qualification Document Hierarchy

Qualification documentation should create an evidence chain rather than a collection of independent protocols.

The hierarchy should answer five fundamental questions:

The preferred evidence chain is:

Business Need

↓

Validation Policy / VMP

↓

Project or Qualification Strategy

↓

System Definition

↓

URS

↓

Impact Assessment

↓

Risk Assessment

↓

Design Specifications

↓

DQ / Design Review

↓

Supplier Qualification / Vendor Assessment

↓

FAT

↓

Installation

↓

SAT / Commissioning

↓

IQ

↓

OQ

↓

PQ

↓

Traceability

↓

Qualification Summary Report

↓

SOP + Training Readiness

↓

QA/GMP Release

↓

Lifecycle Control

↓

Requalification / Periodic Review

↓

Retirement

2.2 Four-Level Qualification Documentation Model

A practical pharmaceutical hierarchy can be organized into four levels.

This hierarchy creates vertical traceability from policy to execution evidence.

2.3 Governance and Planning Documents

2.3.1 Validation Policy

Definition

A Validation Policy is a high-level company or site document establishing the organization’s overall philosophy and governance for qualification and validation.

Purpose

It defines how the organization intends to control validation activities across its GMP operations.

GMP rationale

A pharmaceutical manufacturer requires an organized and controlled validation system. The precise title “Validation Policy” is generally an organizational choice rather than a universal requirement for a separately titled document.

Typical owner

Quality Assurance / Validation Governance

Typical author

• Validation
• QA
• Corporate Quality
• Site Quality

Typical reviewers

• Engineering
• Production
• QC
• IT/Automation
• Quality Systems

Typical approver

Senior Quality management according to the company’s document-management system.

Minimum content

A robust policy may define:

• purpose;
• scope;
• regulatory framework;
• validation philosophy;
• lifecycle approach;
• risk-based methodology;
• roles and responsibilities;
• qualification categories;
• validation categories;
• computerized-system approach;
• data-integrity principles;
• change control;
• deviation management;
• requalification;
• periodic review;
• document retention;
• retirement/decommissioning.

Typical deficiency

A policy states:

“All GMP equipment shall undergo IQ/OQ/PQ.”

This may be too simplistic because it does not explain how qualification scope is determined according to intended use and risk.

2.4 Validation Master Plan — VMP

The VMP is one of the most important site-level validation governance documents.

Purpose

The VMP describes the site’s overall validation/qualification strategy and provides a structured framework for controlling validation activities.

Typical lifecycle position

Site/Project Planning

Typical owner

Validation/QA depending on the company’s PQS.

Typical preparation

Validation/CQV.

Typical review

Cross-functional review involving, as appropriate:

• QA;
• Production;
• Engineering;
• QC;
• IT;
• Automation;
• Utilities;
• Validation.

Typical approval

QA and designated site management functions according to the PQS.

Recommended VMP Structure

1. Introduction

Purpose and validation philosophy.

2. Site description

Overview of:

• manufacturing operations;
• dosage forms;
• buildings;
• production areas;
• laboratories;
• warehouses;
• major utilities.

3. Scope

Define systems covered by the VMP.

4. Validation organization

Define responsibilities.

5. Qualification strategy

Define the approach to:

• facilities;
• utilities;
• equipment;
• HVAC;
• computerized/automated systems.

6. Process validation strategy

Define lifecycle expectations.

7. Cleaning validation strategy

8. Analytical validation strategy

Where relevant.

9. Computerized system strategy

10. Risk management

Explain how risk influences qualification effort.

11. Documentation

Define documentation hierarchy.

12. Deviations

Define handling requirements.

13. Change control

Define lifecycle control.

14. Requalification

Define triggers and periodic requirements where applicable.

15. Periodic review

16. Validation schedule/status

17. Document retention

18. Retirement/decommissioning

2.5 Project Validation Plan

Large projects frequently require a project-specific validation plan.

Examples:

• new manufacturing facility;
• brownfield expansion;
• new granulation suite;
• new packaging line;
• HVAC upgrade;
• purified-water system;
• major automation implementation.

Purpose

Translate the high-level VMP strategy into a project-specific execution strategy.

Typical contents

• project description;
• project boundaries;
• systems/equipment list;
• GMP-impact methodology;
• risk methodology;
• document strategy;
• C&Q strategy;
• supplier involvement;
• FAT/SAT approach;
• commissioning leverage strategy;
• IQ/OQ/PQ strategy;
• CSV/automation strategy;
• responsibilities;
• schedule;
• deliverables;
• acceptance/release strategy;
• change management;
• deviation management;
• turnover requirements.

2.6 Qualification Plan

A Qualification Plan is typically system- or project-specific.

Example

Qualification Plan — Tablet Compression Machine CM-101

It may establish:

• qualification scope;
• system boundaries;
• URS reference;
• risk-assessment approach;
• FAT strategy;
• SAT strategy;
• IQ strategy;
• OQ strategy;
• PQ requirements;
• automation testing;
• supplier-document leverage;
• responsibilities;
• prerequisites;
• deviation management;
• traceability;
• final-release requirements.

Best practice

The plan should answer:

What evidence will be generated to demonstrate this particular system is fit for intended use?

2.7 System Boundary Definition

Before qualification begins, define exactly what constitutes the system.

Consider a tablet compression machine.

The boundary may include:

Incoming power

↓

Compression machine

↓

PLC/HMI

↓

Deduster interface

↓

Metal detector interface

↓

Reject system

↓

Data/network interface

The qualification team must determine which items belong inside the system boundary and which are separately qualified systems.

Why important

Poor boundary definition can produce:

• duplicated testing;
• missing interface testing;
• ownership gaps;
• unqualified components;
• incomplete change assessment.

2.8 System Impact Assessment

A System Impact Assessment determines whether and how a system can affect GMP operations.

Potential impacts include:

• product quality;
• patient safety;
• identity;
• strength;
• purity;
• critical process parameters;
• critical quality attributes;
• contamination control;
• environmental conditions;
• GMP records;
• electronic records;
• data integrity.

Example classification

These classifications must be based on actual intended use, not equipment names alone.

2.9 GMP Impact Assessment

A GMP Impact Assessment asks:

Could the system or function affect a GMP requirement or GMP-controlled activity?

A practical assessment may examine:

The output influences qualification scope.

2.10 Quality Risk Assessment

Once GMP impact has been identified, risk assessment helps determine what requires verification and how much assurance is appropriate.

Risk assessment should consider:

Failure Mode

↓

Potential GMP Consequence

↓

Existing Design/Process Controls

↓

Risk Evaluation

↓

Required Risk Control

↓

Qualification Verification

↓

Residual Risk

Example

For a compression machine:

Failure mode: Reject mechanism fails.

Potential effect: Nonconforming tablets may not be removed.

Control: Automated reject mechanism with confirmation logic.

Qualification action: Challenge reject functionality during OQ.

The risk assessment therefore directly drives testing.

2.11 Validation / Qualification Strategy

The strategy document defines the overall verification philosophy.

It may determine:

• what requires DQ;
• which supplier documents will be reviewed;
• FAT scope;
• SAT scope;
• commissioning leverage;
• IQ scope;
• OQ scope;
• PQ requirements;
• CSV requirements;
• critical testing;
• traceability;
• requalification strategy.

A strategy is particularly useful for complex systems where a simple IQ/OQ/PQ approach is insufficient.

2.12 Requirements and Design Documentation

The next level converts intended use into technical requirements.

The relationship is approximately:

URS

↓

Functional Requirements

↓

Design/Technical Specifications

↓

Configuration

↓

Verification

2.13 User Requirement Specification — URS

The URS defines what the user needs from the system.

Purpose

Translate business, process, GMP, quality, safety, operational, maintenance, and data requirements into testable requirements.

Typical owner

User department.

Typical authors

Cross-functional team involving:

• Production/User;
• Engineering;
• Validation;
• QA;
• Automation;
• IT;
• EHS;
• Maintenance.

Typical approvers

Defined by the PQS; usually includes the user and QA with relevant technical approval.

Minimum URS Content

Typical categories include:

Process

• capacity;
• operating range;
• load;
• speed;
• critical parameters.

Mechanical

• materials of construction;
• product-contact parts;
• surface finish;
• cleanability.

Utilities

• electricity;
• compressed air;
• vacuum;
• water;
• HVAC/environmental requirements.

Instrumentation

• sensors;
• ranges;
• accuracy requirements;
• calibration.

Automation

• PLC;
• HMI;
• SCADA;
• recipes;
• alarms;
• interlocks.

Data integrity

Where applicable:

• access control;
• audit trails;
• records;
• retention;
• backup;
• restore;
• time synchronization.

Documentation

• drawings;
• manuals;
• certificates;
• software documents;
• spare-parts documentation.

Qualification

• FAT;
• SAT;
• commissioning;
• qualification support.

Each requirement should ideally have a unique identifier:

URS-001

URS-002

URS-003

This supports traceability.

2.14 Functional Requirement Specification — FRS

The FRS describes how the system is expected to function to meet user requirements.

Example:

URS

The system shall prevent operation when the main safety guard is open.

Functional requirement

The FRS may define:

Opening the main guard shall cause the safety circuit to remove the applicable machine enable and prevent machine operation until defined reset conditions are satisfied.

The exact technical solution belongs in subsequent design documentation.

2.15 Design Specification

The Design Specification defines how the system will technically meet the requirements.

It may describe:

• mechanical architecture;
• electrical architecture;
• control philosophy;
• instrumentation;
• piping;
• automation;
• interfaces;
• safety;
• data handling.

The document may be produced by the vendor, engineering contractor, system integrator, or internal engineering team.

2.16 Technical Specification

A Technical Specification provides detailed technical requirements for procurement, fabrication, configuration, or implementation.

Typical content:

• dimensions;
• construction;
• materials;
• motor ratings;
• instrumentation;
• electrical standards;
• utility consumption;
• control requirements;
• environmental requirements;
• documentation requirements.

Depending on project structure, technical specifications may overlap with or form part of design specifications.

2.17 Hardware Design Specification

For automated systems, the HDS may define:

• PLC hardware;
• CPU;
• I/O modules;
• HMI;
• servers;
• industrial PCs;
• network equipment;
• communication interfaces;
• storage devices;
• UPS arrangements;
• printers where applicable.

The need and depth depend on system complexity and risk.

2.18 Software Design Specification

An SDS may define:

• software architecture;
• program modules;
• sequences;
• control logic;
• recipes;
• alarms;
• interlocks;
• user roles;
• interfaces;
• calculations;
• data handling.

Again, a separately titled SDS is not automatically required for every piece of pharmaceutical equipment.

2.19 Design Qualification — DQ

DQ verifies that the proposed design is suitable for its intended purpose and appropriately addresses applicable requirements.

A strong DQ asks:

Does the proposed design adequately satisfy the approved requirements and identified GMP-critical needs before installation?

DQ may verify

• URS compliance;
• process capability;
• materials;
• cleanability;
• containment;
• utility requirements;
• instrumentation;
• automation;
• data integrity;
• maintenance;
• safety;
• documentation;
• qualification provisions.

DQ output

Accepted

or

Accepted subject to defined actions

or

Not accepted — redesign required

Open critical issues should not simply disappear into project punch lists without appropriate assessment.

2.20 Design Review

Design Review is a broader engineering activity and may support DQ.

Participants can include:

• User;
• Engineering;
• Validation;
• QA;
• Maintenance;
• Automation;
• EHS;
• Vendor.

Design review may cover:

• P&IDs;
• layouts;
• accessibility;
• product flow;
• personnel flow;
• maintainability;
• utility loads;
• instrumentation;
• safety;
• cleaning.

DQ vs Design Review

They may overlap, but conceptually:

Design Review: technical multidisciplinary review.

DQ: documented qualification conclusion that design is suitable against relevant requirements.

2.21 Design Risk Assessment

Design risk assessment identifies potential failures before fabrication or implementation.

For example:

This assessment can significantly improve both design and subsequent testing.

2.22 Requirement Traceability Matrix

The Traceability Matrix establishes the connection between requirements and evidence.

Example:

Traceability prevents the common problem:

A requirement exists, but nobody can demonstrate where it was verified.

2.23 Supplier and Pre-Delivery Documentation

Before equipment arrives at site, supplier-related documentation may provide significant qualification value.

2.24 Vendor Assessment

Vendor assessment evaluates whether the supplier is capable of providing a system suitable for its intended GMP application.

Potential considerations:

• experience;
• quality system;
• technical capability;
• documentation practices;
• software development controls;
• change management;
• testing capabilities;
• service/support;
• calibration controls;
• subcontractor management.

The depth should be risk-based.

A simple mechanical item and a complex GMP computerized system should not automatically receive identical supplier assessments.

2.25 Supplier Qualification

Supplier qualification is the organization’s formal process for determining whether a supplier is acceptable for the relevant supply/service.

It can involve:

• questionnaires;
• document review;
• audit;
• performance history;
• technical evaluation;
• quality agreement where applicable.

Do not confuse:

Supplier Qualification

with

Equipment Qualification.

They address different risks.

2.26 Vendor Documentation Review

Before FAT, the qualification/project team should identify required vendor documentation.

A typical Vendor Document Requirement List may include:

• GA drawing;
• P&ID;
• electrical drawing;
• pneumatic diagram;
• instrument list;
• component list;
• material certificates;
• surface-finish certificates;
• calibration certificates;
• manuals;
• spare-parts list;
• software versions;
• alarm list;
• I/O list;
• functional descriptions;
• certificates;
• test reports.

Documents should be reviewed for adequacy rather than merely counted.

2.27 Factory Acceptance Test — FAT

FAT is normally performed at the supplier’s facility before shipment.

Purpose

Verify important aspects of fabrication, functionality, controls, and performance while correction is still relatively easy.

Typical FAT scope

Mechanical

• construction;
• dimensions;
• components;
• product-contact parts;
• movement.

Electrical

• panels;
• wiring;
• motors;
• safety circuits.

Instrumentation

• sensor identification;
• ranges;
• basic functionality.

Automation

• PLC;
• HMI;
• recipes;
• alarms;
• interlocks;
• sequences;
• user access.

FAT evidence

May include:

• approved test protocol;
• executed tests;
• raw data;
• printouts;
• screenshots;
• deviations;
• punch list;
• report.

Final disposition

Accepted for shipment

Accepted with defined punch-list actions

or

Not accepted

2.28 Can FAT Be Leveraged During Qualification?

Potentially yes.

But supplier testing should not be accepted merely because it is called FAT.

Before relying upon FAT evidence, assess:

• Was the test predefined?
• Was the configuration representative?
• Were acceptance criteria appropriate?
• Were instruments suitable?
• Was evidence retained?
• Were deviations documented?
• Were changes made after FAT?
• Can the result be traced to requirements?
• Was execution adequately controlled?
• Does transport/site installation invalidate the evidence?

Example

Material certificates reviewed at FAT may not need to be recreated during IQ.

But a safety interlock affected by site installation may need site verification.

2.29 Site Acceptance Test — SAT

SAT is performed after equipment arrives at the manufacturing site.

Typical purpose

Confirm:

• shipment condition;
• site installation;
• utility connections;
• basic operation;
• site-specific configuration;
• communication;
• FAT punch-list closure;
• absence of unacceptable transport damage.

Typical SAT checks

• equipment identification;
• shipment damage;
• utilities;
• electrical supply;
• compressed air;
• network connection;
• safety;
• instruments;
• PLC/HMI communication;
• basic alarms;
• basic interlocks;
• basic operation.

SAT can bridge FAT/commissioning and formal qualification.

2.30 Commissioning Protocol

A commissioning protocol or test package may contain:

• installation checks;
• loop checks;
• motor checks;
• valve checks;
• utility verification;
• startup;
• sequence checks;
• alarm tests;
• functional tests.

Where commissioning evidence is intended for qualification leverage, its documentation quality should be planned accordingly.

2.31 Installation Qualification — IQ

IQ provides documented verification that the equipment/system is installed appropriately against approved specifications and requirements.

IQ answers:

Did we receive and install the correct system, components and configuration?

Typical IQ Sections

Equipment identification

• equipment ID;
• manufacturer;
• model;
• serial number;
• location.

Installation

• physical installation;
• anchoring;
• accessibility;
• orientation.

Components

• motors;
• pumps;
• valves;
• filters;
• critical components.

Materials

• product-contact materials;
• certificates;
• surface finish where relevant.

Utilities

• electricity;
• compressed air;
• vacuum;
• water;
• steam;
• gases.

Instrumentation

• instrument ID;
• manufacturer;
• model;
• range;
• calibration status.

Documentation

• manuals;
• drawings;
• P&IDs;
• electrical diagrams;
• certificates.

Automation

• PLC version;
• HMI version;
• firmware;
• network identification.

Maintenance

• lubrication;
• spare parts;
• PM requirements.

As-built verification

Confirm documentation reflects actual installed configuration.

2.32 Operational Qualification — OQ

OQ provides documented evidence that the system operates as intended throughout predefined operating conditions/ranges.

OQ asks:

Does the installed system function correctly, including under appropriately challenged conditions?

Typical OQ tests include:

• start/stop;
• operating sequences;
• operating ranges;
• setpoints;
• control loops;
• alarms;
• interlocks;
• emergency stop;
• failure conditions;
• power failure/recovery;
• recipes;
• user access;
• data handling;
• audit trails where applicable;
• reports;
• backup/restore where applicable.

OQ should not be limited to proving normal operation.

Appropriate critical functions should be challenged.

2.33 Performance Qualification — PQ

PQ provides documented evidence that the equipment/system performs effectively and reproducibly under routine or appropriately simulated operating conditions.

Typical considerations:

• trained operators;
• approved procedures;
• normal operating conditions;
• load configurations;
• minimum/maximum loads;
• appropriate materials;
• sampling;
• reproducibility;
• defined acceptance criteria.

Important distinction

Equipment PQ and process validation may overlap operationally, but the qualification strategy should define their respective objectives and boundaries.

2.34 Supporting Qualification Documentation

A qualification package extends far beyond IQ/OQ/PQ protocols.

Supporting evidence can be essential.

Calibration Records

Should establish:

• instrument identification;
• calibration status;
• calibration range;
• reference standards;
• results;
• calibration date;
• due date.

A calibration sticker alone does not establish suitability for intended use.

Material Certificates

May support verification of:

• stainless-steel grade;
• elastomer type;
• product-contact material;
• construction material.

Instrument Certificates

May include:

• calibration certificates;
• conformity certificates;
• manufacturer documentation.

Welding Documentation

For relevant piping systems, documentation may include:

• welder qualifications;
• weld maps;
• weld logs;
• inspection records;
• boroscope records where justified.

The exact requirements depend on the system and applicable engineering/GMP strategy.

Passivation Documentation

Relevant stainless-steel systems may require documented evidence of appropriate passivation depending on system design and service.

Pressure / Leak Testing

Potentially relevant to:

• process piping;
• utility piping;
• pressure vessels;
• gas systems.

Acceptance criteria should derive from applicable design/engineering requirements.

2.35 Drawings

Important controlled drawings may include:

• P&IDs;
• equipment layouts;
• utility drawings;
• electrical drawings;
• pneumatic drawings;
• network diagrams;
• process-flow diagrams.

Critical requirement

The final qualification package should rely upon appropriate as-built/as-configured information, not outdated design drawings.

2.36 Equipment Manuals

Typical manuals:

• installation manual;
• operation manual;
• maintenance manual;
• troubleshooting manual;
• software manual.

Vendor manuals support qualification but generally do not replace site SOPs.

2.37 Spare Parts List

The spare-parts strategy should identify critical parts necessary to maintain equipment reliability and configuration.

Particularly important:

• critical sensors;
• controllers;
• PLC modules;
• drives;
• seals;
• filters;
• product-contact components.

2.38 Preventive Maintenance Requirements

Qualification should establish the maintenance baseline.

Examples:

• lubrication intervals;
• belt inspection;
• filter replacement;
• sensor inspection;
• mechanical inspection;
• backup-battery replacement;
• safety-device checks.

The qualified state depends on continued maintenance.

2.39 SOPs

Before routine GMP release, relevant SOPs should be available according to intended operation.

Potential SOPs:

• operation;
• cleaning;
• setup;
• changeover;
• maintenance;
• calibration;
• breakdown handling;
• alarm response;
• user management;
• backup/restore;
• audit-trail review;
• recipe management.

2.40 Training Records

Personnel involved in PQ and routine operation should be appropriately trained.

Training may cover:

• operation;
• cleaning;
• safety;
• data handling;
• alarm response;
• recipe management;
• GMP documentation.

Training status becomes part of operational readiness.

2.41 Closure Documentation

Qualification is not complete merely because protocol testing has ended.

The closure stage is critical.

2.42 Qualification Deviations

Any departure from:

• approved protocol;
• expected result;
• acceptance criterion;
• approved procedure;
• planned test method

should be appropriately documented and assessed according to the applicable procedure.

A typical lifecycle is:

Observation

↓

Documentation

↓

Initial Assessment

↓

Impact Assessment

↓

Investigation

↓

Correction/CAPA

↓

Approved Re-test where necessary

↓

QA Review

↓

Closure

2.43 Punch Lists

Punch lists typically document outstanding project items.

Examples:

• missing label;
• documentation correction;
• minor paint damage;
• outstanding drawing;
• component adjustment.

Critical caution

A punch list must not be used to hide qualification failures.

Every open item should be evaluated for:

• GMP impact;
• safety impact;
• qualification impact;
• release impact.

Critical issues should be resolved before GMP release unless a formally justified and approved disposition establishes otherwise.

2.44 Qualification Discrepancy Report

Some organizations distinguish a qualification discrepancy from a general quality-system deviation.

A discrepancy may document:

• unexpected test result;
• test execution issue;
• documentation problem;
• acceptance-criteria failure.

Whether it is subsequently escalated into the formal deviation/CAPA system depends on the PQS and significance.

2.45 CAPA

Not every qualification deviation automatically requires CAPA.

CAPA may be appropriate when investigation identifies:

• systemic weakness;
• significant root cause;
• recurring problem;
• design deficiency;
• procedural failure;
• training deficiency;
• broader GMP risk.

This distinction prevents CAPA systems from becoming overloaded with minor isolated corrections.

2.46 Final Traceability Matrix

Before closure, the traceability matrix should demonstrate that relevant requirements have been addressed.

Example:

Any unverified requirement should be identified and dispositioned rather than silently omitted.

2.47 Qualification Summary Report — QSR

The QSR evaluates the complete qualification package.

It should not merely state:

“All tests passed. Equipment is qualified.”

A robust report evaluates:

• qualification scope;
• protocols executed;
• test results;
• deviations;
• failures;
• re-tests;
• change controls;
• punch-list status;
• traceability;
• outstanding risks;
• SOP status;
• training status;
• restrictions;
• final conclusion.

Recommended QSR Structure

1. Document identification
2. Objective
3. Scope
4. System description
5. Qualification strategy
6. Protocols executed
7. Test summary
8. Deviations
9. Re-tests
10. Change controls
11. Punch-list status
12. Traceability status
13. Outstanding risks
14. SOP readiness
15. Training readiness
16. Calibration/PM readiness
17. Restrictions
18. Conclusion
19. Recommended qualification status
20. Approvals

2.48 Qualification / GMP Release

Qualification completion and GMP release should be distinguished.

A machine may have completed OQ but still not be ready for routine GMP production.

Before release, verify as applicable:

Qualification complete

Deviations appropriately dispositioned

Calibration active

PM active

SOPs approved

Personnel trained

Cleaning controls established

Computerized controls ready

Outstanding risks acceptable

=

GMP Operational Readiness

The formal release mechanism is defined by the company’s PQS.

2.49 Handover Documentation

The project team should formally transfer the system into routine operational ownership.

A turnover package may contain:

• approved qualification documents;
• as-built drawings;
• manuals;
• certificates;
• calibration records;
• software/configuration baseline;
• spare-parts list;
• PM requirements;
• warranties;
• open-item status;
• training evidence;
• backup copies;
• licenses where relevant.

2.50 Requalification Strategy

The initial qualification package should define or link to how future qualification status will be managed.

Possible triggers include:

• major maintenance;
• relocation;
• critical component replacement;
• software modification;
• operating-range change;
• repeated failure;
• adverse trend;
• significant process change.

The scope should normally follow:

Trigger

↓

Impact Assessment

↓

Risk Assessment

↓

Affected Requirements

↓

Required Verification

↓

Requalification Evidence

↓

Approval

2.51 Master Qualification Document Matrix

The terminology “mandatory” should only be applied after considering the applicable regulatory framework and internal PQS rather than treating every industry document name as a universal legal requirement.

2.52 Document Ownership Model

A practical responsibility model is:

This is an illustrative model only. Actual responsibilities should follow the company’s PQS.

2.53 Document Approval Gates

A mature qualification project establishes approval gates.

Gate 1 — Requirements Freeze

URS approved

↓

Proceed to final design.

Gate 2 — Design Acceptance

DQ/design review acceptable

↓

Proceed to fabrication/configuration.

Gate 3 — FAT Acceptance

FAT complete + critical issues resolved

↓

Release for shipment.

Gate 4 — Installation Readiness

SAT/commissioning sufficiently complete

↓

Proceed to IQ/OQ as defined.

Gate 5 — Qualification Execution

Approved protocol + prerequisites complete

↓

Execute.

Gate 6 — Qualification Closure

Testing + deviations + traceability complete

↓

Approve QSR.

Gate 7 — GMP Release

Qualification + SOPs + training + PM + calibration + required controls ready

↓

Release for routine GMP operation

2.54 Example — Tablet Compression Machine Document Hierarchy

A practical document chain could look like this:

Governance

VMP

↓

Project

Qualification Plan — Compression Machine

↓

Requirements

URS-CM-001

↓

Impact

System/GMP Impact Assessment

↓

Risk

Compression Machine FMEA

↓

Design

Design Specification

Electrical Drawings

Software/Functional Description

↓

DQ

DQ-CM-001

↓

Supplier

Vendor Assessment

↓

FAT

FAT-CM-001

↓

Site

SAT-CM-001

↓

Qualification

IQ-CM-001

↓

OQ-CM-001

↓

PQ-CM-001

↓

Closure

RTM-CM-001

↓

QSR-CM-001

↓

Operational readiness

SOPs

Training

Calibration

PM

↓

QA/GMP Release

↓

Lifecycle

Change Control

Periodic Review

Requalification

2.55 Example of Requirement-to-Evidence Flow

Consider one requirement:

URS-CM-045

The compression machine shall prevent operation of the turret when the designated main safety guard is open.

The evidence chain could be:

URS-CM-045

↓

Risk Assessment RA-017

Guard/interlock failure assessed for operator/system risk and applicable GMP impact.

↓

Design Specification DS-112

Safety interlock architecture defined.

↓

FAT Test FAT-8.4

Basic interlock function challenged at vendor.

↓

SAT

Verify site installation did not compromise safety circuit.

↓

OQ Test OQ-6.8

Challenge guard interlock in installed configuration.

↓

Actual Result

Opening the designated guard produces the specified response and prevents operation according to approved acceptance criteria.

↓

Traceability Matrix

URS-CM-045 → RA-017 → DS-112 → FAT-8.4 → OQ-6.8

↓

Verified

That is what a defensible qualification evidence chain looks like.

2.56 Common Document-Hierarchy Deficiencies

2.57 Inspector’s View of the Document Hierarchy

An inspector may effectively move through the documentation in either direction.

Forward traceability

“Show me the URS.”

↓

“Which requirement is critical?”

↓

“What risk did you identify?”

↓

“How did the design address it?”

↓

“Where was it tested?”

↓

“Show me the raw evidence.”

Reverse traceability

The inspector may instead begin with an observed machine function:

“What does this reject button do?”

↓

“Is this function GMP critical?”

↓

“Where is that established?”

↓

“Show me the qualification test.”

↓

“Show me the requirement.”

↓

“Show me changes made since qualification.”

A strong qualification system should survive both forward and reverse traceability.

2.58 Qualification Documentation Pyramid

The overall documentation structure can be visualized as:

                    ┌────────────────────────┐
                    │   VALIDATION POLICY    │
                    └────────────┬───────────┘
                                 │
                    ┌────────────▼───────────┐
                    │          VMP           │
                    └────────────┬───────────┘
                                 │
              ┌──────────────────▼──────────────────┐
              │ PROJECT / QUALIFICATION STRATEGY   │
              └──────────────────┬──────────────────┘
                                 │
                    ┌────────────▼───────────┐
                    │     URS / INTENDED USE │
                    └────────────┬───────────┘
                                 │
              ┌──────────────────▼──────────────────┐
              │ IMPACT + QUALITY RISK ASSESSMENT   │
              └──────────────────┬──────────────────┘
                                 │
                    ┌────────────▼───────────┐
                    │ DESIGN / DQ / REVIEW   │
                    └────────────┬───────────┘
                                 │
                 ┌───────────────▼───────────────┐
                 │ FAT → SAT → COMMISSIONING    │
                 └───────────────┬───────────────┘
                                 │
                       ┌─────────▼─────────┐
                       │   IQ → OQ → PQ    │
                       └─────────┬─────────┘
                                 │
                 ┌───────────────▼───────────────┐
                 │ DEVIATIONS + TRACEABILITY    │
                 └───────────────┬───────────────┘
                                 │
                 ┌───────────────▼───────────────┐
                 │ QUALIFICATION SUMMARY REPORT │
                 └───────────────┬───────────────┘
                                 │
                 ┌───────────────▼───────────────┐
                 │ SOP + TRAINING + GMP RELEASE │
                 └───────────────┬───────────────┘
                                 │
              ┌──────────────────▼──────────────────┐
              │ MAINTAINING THE QUALIFIED STATE    │
              │ Change / PM / Calibration / Review │
              └──────────────────┬──────────────────┘
                                 │
                       ┌─────────▼──────────┐
                       │  REQUALIFICATION  │
                       └────────────────────┘

2.59 Golden Rule for Qualification Documentation

A qualification package is strong when every important requirement can answer:

Why does this requirement exist?

URS / GMP / Process Need

↓

What could happen if it fails?

Risk Assessment

↓

How was it addressed?

Design

↓

How was it verified?

FAT / SAT / IQ / OQ / PQ

↓

What evidence proves the result?

Raw Data / Record / Certificate / Electronic Evidence

↓

Were problems appropriately managed?

Deviation / CAPA / Re-test

↓

Is everything accounted for?

Traceability Matrix

↓

Can the system be released?

Qualification Summary + Operational Readiness

↓

How will it remain controlled?

Change Control + Calibration + PM + Monitoring + Periodic Review + Requalification

Part 2 — Key Takeaway

The pharmaceutical qualification-document hierarchy should not be viewed as:

URS + DQ + IQ + OQ + PQ = Qualification

A more complete lifecycle model is:

Governance → Intended Use → Requirements → Impact → Risk → Design → Supplier Assurance → Commissioning → Qualification Testing → Deviations → Traceability → Qualification Conclusion → GMP Operational Readiness → Lifecycle Control

The value of the documentation lies in the connections between documents.

A strong qualification package allows the organization—and an inspector—to move seamlessly from:

Requirement → Risk → Design → Test → Raw Evidence → Deviation → Traceability → Qualified State

That evidence chain is the foundation for Part 3 — User Requirement Specification (URS), where the URS can be developed in detail, including GMP requirements, mechanical/process requirements, automation, PLC/SCADA/HMI, recipe management, audit trails, electronic records, data integrity, FAT/SAT requirements, poor-vs-good URS examples, and a practical pharmaceutical URS template.

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.