This is a ready-to-use IQ/OQ protocol for GxP IT infrastructure. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, attach the build sheets and screenshots the protocol calls for, and route it through your normal document control, review, and approval. A worked filled specimen for a virtualized server host follows the template so you can see how a completed version reads. Verify each cited regulation against the current source before you rely on it.
Infrastructure qualification proves that the platform underneath your validated applications was built, configured, and operates the way the design said it would, before any GxP application sits on top of it. GAMP 5 calls this layer the qualified infrastructure: servers and virtual hosts, the operating system and its patch baseline, network and firewall rules, time synchronization, storage and redundancy, databases, monitoring, security hardening, and backup. You qualify it once, you reference it from every application IQ that runs on it, and you keep it under change control. IQ confirms the build matches specification. OQ confirms the platform functions correctly under controlled conditions, that failover works, that backups restore, that alerts fire, that an unauthorized account cannot log in. Get this layer right and every application above it inherits a documented foundation; get it wrong and an inspector pulls the thread through every system you host.
1. Purpose
This protocol defines the checks and acceptance criteria to confirm that the infrastructure component <<FILL: platform / host name>> was built and configured per the approved design specification (IQ), and that it operates correctly under controlled, repeatable conditions (OQ), so that GxP applications can be installed and qualified on a documented, trustworthy foundation. The objective is an inspection-ready record that the build, operating system and patch baseline, network and firewall configuration, time source, storage and redundancy, database where present, monitoring and alerting, security hardening, and backup are all established, verified, and operating as designed.
2. Scope
This protocol applies to the single infrastructure component or platform identified in the header and section 5: the physical or virtual host, its operating system, the network and firewall configuration that serves it, its time synchronization source, its storage and redundancy arrangement, any database instance that supports hosted GxP applications, the monitoring and alerting that watches it, its security hardening, and the backup that protects its data. It covers verification at build time (IQ) and controlled functional verification of the platform (OQ). It does not validate any application hosted on the platform, which is covered by each application’s own IQ/OQ/PQ or CSA-scaled testing, and it does not cover routine operation, periodic review, or change control after qualification, which are governed by <<FILL: cross-reference SOP-IDs>>. Where a cloud or hosted service provides part of this stack, the provider’s responsibilities are defined in the shared-responsibility matrix referenced in section 5 and verified through supplier assessment rather than re-tested here.
3. Responsibilities
4. Definitions
- Qualified infrastructure: the GAMP 5 platform layer (compute, OS, network, storage, database, monitoring, backup) that is built and verified to a documented specification and kept under change control, on which validated applications run.
- IQ (installation qualification): documented verification that the component is built and configured as specified, on the right hardware or virtual platform, at the right OS and patch level.
- OQ (operational qualification): documented verification that the component functions correctly across its intended operating range under controlled conditions, including failover, restore, alerting, and access control.
- Configuration baseline: the as-built, approved set of settings (OS build, services, accounts, firewall rules, time source, storage layout) that becomes the reference for change control.
- Hardening: removal or disabling of unneeded services, default accounts, and open ports, and application of a security configuration standard.
- RTO / RPO: recovery time objective (how fast service is restored) and recovery point objective (how much data loss is tolerable), the targets a restore test must meet.
5. Infrastructure under qualification
6. Prerequisites
Confirm and record each before execution begins. Do not start IQ until all are met.
- The design or build specification is approved and current.
- The host or VM is built and powered, accessible to the executors with the access they need.
- Required vendor or platform documentation (hardware datasheet, hypervisor version, OS media, security baseline) is available.
- Executors are trained on this protocol and on the systems they will check.
- A change record authorizing the build exists, referenced in section 14.
7. IQ test cases (installation)
Execute each test case in order. Record the expected result, the observed result, pass or fail, evidence reference (screenshot, build sheet, query output), and executor initials and date. A single failed test is a deviation per section 11, not a quiet re-run.
7.1 Hardware or virtual build versus specification
7.2 Operating system and patch baseline
7.3 Network and firewall configuration
7.4 Time synchronization
Time synchronization is a recurring inspection target because audit trail trustworthiness depends on a reliable, controlled clock. Tie the time source here to the same source referenced in your audit trail review SOP.
7.5 Storage and RAID
7.7 Security hardening
8. OQ test cases (operation)
OQ exercises the platform under controlled conditions to show it behaves as designed. Restore and failover are the high-value tests inspectors look for; configuration alone never proves recoverability.
9. Acceptance criteria
The qualification is acceptable when all of the following are true:
- Every IQ test case in section 7 passes, with evidence attached, or any failure is dispositioned through a closed deviation that does not affect fitness for use.
- Every OQ test case in section 8 passes, including a successful backup restore and any applicable failover, with RTO and RPO met.
- The as-built configuration baseline is captured and approved as the reference for change control.
- Monitoring and alerting are confirmed working, and access control denies the unauthorized and permits the authorized.
- All deviations are documented, assessed, and resolved before the qualified state is accepted.
10. Configuration baseline (as-built)
Record the approved as-built baseline so change control has a defined reference point. At minimum capture: host identity and resources, OS version and patch baseline date, network and firewall rule set reference, time source, storage and RAID layout, database version and parameters, security baseline version, monitoring profile, and backup schedule and retention. Attach the full build sheet as Attachment 1.
11. Deviations and handling
Any test failure, configuration mismatch, or departure from this protocol is documented as a deviation per <<FILL: deviation SOP-ID>>, assessed for impact on fitness for use, and resolved before the qualified state is accepted. Re-execution after a fix is recorded with the deviation reference. Do not release the platform to host GxP applications until all deviations are closed.
12. Report
On completion, the validation lead issues report <<FILL: report number>> summarizing the IQ and OQ results against acceptance criteria, the approved configuration baseline, all deviations and their resolution, and the conclusion on the qualified state, including the verified RTO and RPO from the restore test. The report is approved by QA.
13. References
21 CFR Part 11 (electronic records and signatures; controls the platform must support).
21 CFR 211.68 (automatic, mechanical, and electronic equipment).
EU GMP Annex 11 (computerised systems), in particular sections 4 (validation), 7 (data storage), 12 (security), and 13 (incident management).
EU GMP Annex 15 (Qualification and Validation), 2015 revision, for the IQ/OQ approach.
GAMP 5 Second Edition (ISPE), infrastructure and platform qualification.
FDA guidance, Computer Software Assurance for Production and Quality Management System Software, issued 3 February 2026 (superseding the 24 September 2025 final) (risk-based scaling of evidence).
ICH Q9, Quality Risk Management (for the risk basis of test depth).
PIC/S PI 011, Good Practices for Computerised Systems in Regulated GxP Environments.
Confirm the current version and clause numbers of each reference before issue.
14. Linked records
15. Revision history
16. Approvals
Filled specimen
The following shows selected IQ and OQ results completed for an example production virtualized server host, so you can see the level of detail an inspector expects. The host, versions, and numbers are illustrative; replace them with your own.
In this example the team verified the build against specification, confirmed the clock was tied to a controlled time source within tolerance, then proved recoverability with an actual restore that met RTO and RPO rather than assuming the backup job was enough. They forced a failover and a disk alert instead of trusting the configuration, found the one misrouted alert, dispositioned it through a deviation, and re-tested. That sequence, build verification to operational proof to closed deviation, is exactly what a reviewer is expected to demonstrate.
Common inspection findings this protocol prevents
- Applications validated on infrastructure that was never qualified, so the validated state rests on an undocumented platform.
- A backup job configured but never restore-tested, so recoverability was assumed and not proven.
- System clocks not tied to a controlled time source, undermining audit trail trustworthiness across every hosted application.
- Default or shared administrator accounts left active, with no hardening baseline recorded.
- Firewall rules with broad any-any access on a GxP host, or the host placed on the wrong network segment.
- Monitoring present but alert routing never tested, so a real failure would reach no one.
- No captured configuration baseline, so change control has no reference point and drift goes undetected.
- RTO and RPO stated as targets but never verified against an actual restore.
How to adapt this protocol
- Set your document number, owner, report number, and effective date in the header.
- Replace the component and scope in section 5 with your actual host, environment, and the applications it will carry.
- Trim test cases that do not apply (for example section 7.6 if the platform hosts no database) and add any platform-specific checks your design demands.
- Set your real tolerances and targets: clock offset in 7.4, free-space threshold in 7.5, and RTO and RPO for the restore test in section 8.
- For a cloud or hosted portion, attach the shared-responsibility matrix and verify the provider’s controls through supplier assessment rather than re-testing them here.
- Point the cross-references in sections 2 and 11 to your real change control, periodic review, and deviation procedures.
- Confirm every regulation in section 13 against the current published version before issue.
