GxP Software Validation Checklist: Every Step From URS to Go-Live Under GAMP 5 and CSA

Phase 1: Planning

• Validation Plan. Defines scope, approach, responsibilities, deliverables, and timeline. References GAMP 5 and CSA principles. Names the system, its GAMP 5 category, and the risk-based testing approach. Approved by QA and system owner.
• GAMP 5 category classification. Category 3 (non-configured commercial), Category 4 (configured commercial), or Category 5 (custom). The category determines the depth of every subsequent step. Classification Engine in GxP Copilot automates this classification with documented rationale.
• Vendor qualification. Assess the vendor's quality system, development practices, and change notification process. Request and review the vendor audit package. Document whether vendor evidence can be leveraged to reduce customer testing. supplier qualification.

Phase 2: Requirements and risk

• User Requirements Specification (URS). Defines what the system must do in your environment. Each requirement has a unique ID, is testable, and is classified by regulatory impact. The URS is the foundation — if it is incomplete or unclear, everything downstream suffers.
• Functional Risk Assessment. Assess the risk of each requirement failing: impact on product quality, patient safety, and data integrity, combined with likelihood. Risk classification drives test depth under CSA: high-risk requirements get scripted testing, medium-risk get structured testing, low-risk get vendor evidence or ad-hoc verification. AI Risk Assessment automates this scoring.
• Configuration specification (Category 4) or design specification (Category 5). Documents how the system will be configured or built to meet the URS. Maps configuration decisions to specific requirements.

Phase 3: Testing

• IQ (Installation Qualification). Verifies the system is installed correctly: software version matches specification, hardware meets requirements, network connectivity confirmed, access controls configured, backup configured. Executed by IT or the system administrator, witnessed or reviewed by QA.
• OQ (Operational Qualification). Verifies the system operates as specified: each requirement tested against its acceptance criteria. For high-risk requirements (under CSA), scripted test protocols with predefined steps, expected results, and documented actual results. For medium-risk, structured testing with documented outcomes. For low-risk, leveraged vendor evidence with documented acceptance.
• PQ (Performance Qualification). Verifies the system performs as expected in the production environment with representative real-world data. End-to-end workflow testing that exercises the complete business process, including HITL review, approval, and audit trail generation.
• Traceability matrix. Maps requirements to design, design to test cases, and test cases to results. Every requirement has at least one test; every test traces to at least one requirement. No orphan tests, no uncovered requirements. Live RTM in GxP Copilot derives this matrix automatically and keeps it current.

Phase 4: Release and ongoing

• Validation Summary Report (VSR). Documents the validation outcome: what was tested, what passed, what deviations occurred and how they were resolved, and the conclusion that the system is fit for intended use. Signed by QA and system owner.
• SOPs for system operation. Standard operating procedures for system use, administration, backup, recovery, and change control.
• Training records. Documented training for all users on the SOPs and system operation.
• Change control. From this point forward, every change to the system — configuration, version update, patch — goes through change control with impact assessment, testing, and approval.
• Periodic review. Annual or semi-annual review confirming the system remains in a validated state: no uncontrolled changes, audit trail integrity verified, performance acceptable, SOPs current.

What inspectors look for

• A complete traceability chain from URS through test results — no gaps.
• Risk-based justification for test depth — not "we tested everything equally" but "we tested more where the risk was higher."
• Evidence that the audit trail is tamper-evident — not just that it exists.
• Evidence that change control is followed — not just that the process is defined.
• Evidence that the system is still in a validated state — not just that it was validated once.

How GxP Copilot accelerates this checklist

GxP Copilot generates the validation package for any GxP software system: the URS template, risk assessment with per-requirement scoring, IQ/OQ/PQ protocols sized to risk under CSA, the live traceability matrix, and the Validation Summary Report shell. Your team fills in the system-specific details, executes the protocols, and signs. The AI handles the structural drafting; humans handle the judgment calls. The result is the same inspection-ready evidence — produced in weeks rather than months. book a demo to see it on your next validation project.