refers to Non-Configurable Software , often called Commercial Off-The-Shelf (COTS) products . These are "off-the-shelf" solutions used for business purposes with no configuration or very limited configuration capacity. Key Characteristics
Because Category 3 software is standardized and used by a wide market, the inherent risk associated with "bugs" in the core code is generally considered lower than Category 5 (Custom) or Category 4 (Configured) systems. Consequently, the validation burden is lighter, allowing companies to leverage the vendor's own testing. The Validation Lifecycle for Category 3 gamp 5 category 3
| Pitfall | Impact | Mitigation | |---------|--------|------------| | | Regulatory findings, non‑compliance | Apply risk‑based validation; perform IQ/OQ/PQ | | Relying solely on vendor documentation | Gaps in site‑specific configuration evidence | Create independent CS and CI register; perform gap analysis | | Inadequate supplier qualification | Undetected vendor change‑control weaknesses | Conduct formal audit, request vendor VVP, maintain qualification file | | Missing change‑impact analysis | Uncontrolled configuration drift | Use impact matrix for every change request; re‑run OQ/PQ when needed | | Insufficient training / SOPs | Operator error, data integrity breaches | Develop role‑specific SOPs and training records; periodic competency assessment | | Weak audit‑trail configuration | 21 CFR 11 non‑compliance | Verify audit‑trail completeness in OQ, test tamper‑proofing | Retirement | • Data migration
| URS # | FS # | CS # | CI # | Test Case # (OQ) | PQ Scenario # | |-------|------|------|------|-------------------|---------------| | URS‑01 – “System shall restrict user access based on role” | FS‑01 – Role‑Based Access Control | CS‑01 – Role definitions (Admin, Analyst, Viewer) | CI‑01 – Role Table in DB | TC‑OQ‑01 – Verify login for each role | PQ‑01 – Analyst creates batch record, Admin approves | | URS‑02 – “Electronic signatures must be captured per 21 CFR 11” | FS‑02 – Signature Capture | CS‑02 – Signature configuration (user, time‑stamp) | CI‑02 – Signature settings | TC‑OQ‑02 – Verify signature workflow | PQ‑02 – QA signs off release | | URS‑03 – “All changes to configuration must be logged” | FS‑03 – Audit‑Trail of configuration changes | CS‑03 – Audit‑trail parameters | CI‑03 – Audit‑trail table | TC‑OQ‑03 – Verify audit‑trail entries | PQ‑03 – Simulate configuration change, review log | system de‑commissioning | Retirement Plan
The most common mistake in GAMP classification is confusing with Category 4 (Configured) .
| Phase | Key Activities | Primary Deliverables | |-------|----------------|----------------------| | | • Define scope, risk classification, team roles • Create Validation Master Plan (VMP) with Category 3 focus | VMP, Project Charter | | 2. Requirements Specification | • User Requirements Specification (URS) • Functional Specification (FS) derived from URS • Gap analysis (vendor vs. URS) | URS, FS, Gap Analysis Report | | 3. Configuration & Build | • Configure the package (parameter settings, workflows, security, interfaces) • Document each configuration item (CI) | Configuration Specification (CS), CI Register | | 4. Supplier Qualification | • Vendor audit (ISO‑9001, GAMP 5 compliance, change‑control) • Review of vendor validation package (VVP) | Supplier Qualification Report, VVP Acceptance | | 5. Testing | • IQ – Installation Qualification (infrastructure, OS, DB) • OQ – Operational Qualification (configuration meets FS) • PQ – Performance Qualification (real‑world use cases) | IQ Protocol/Report, OQ Protocol/Report, PQ Protocol/Report | | 6. Release | • Review of all testing, deviations, risk assessment • Formal sign‑off | Release Summary, Validation Sign‑off Sheet | | 7. Operation | • SOPs for daily use, backup, security, incident handling • Periodic review (e.g., annual) | SOPs, Periodic Review Report | | 8. Change Control | • Impact‑based change control (minor config change vs. major functional change) | Change Request, Impact Assessment, Updated CI Register | | 9. Retirement | • Data migration, archiving, system de‑commissioning | Retirement Plan, Archive Verification |
Analyze how the software handles data. Does it impact product release? Is the data used for clinical decisions? This assessment determines the depth of testing required. 4. Verification (IQ/OQ)