Server & Infrastructure Qualification
Frequently Asked Questions

Server and IT infrastructure that directly hosts, processes, or supports the operation of GxP-relevant computerised systems requires qualification to demonstrate it meets the performance, security, and reliability requirements necessary for the applications it supports — the qualification obligation extends to the platform, not only the application layer.

EU GMP Annex 11 Clause 4 requires that the hardware used in GxP computerised systems be fit for purpose. EU GMP Annex 15 establishes that qualification applies to equipment, utilities, and systems — a category that encompasses IT infrastructure when it directly supports GxP operations. The ISPE Good Practice Guide for IT Infrastructure Control and Compliance provides the practical framework most organisations use to implement this obligation.

The key regulatory principle is that a GxP application validated on a specific hardware and operating system configuration is only validated in that specific configuration. If the underlying infrastructure changes — different server model, different OS version, different virtualisation hypervisor — the original qualification evidence applies to a configuration that no longer exists. The infrastructure qualification documents the baseline against which subsequent changes are assessed.

Infrastructure qualification establishes that the hardware, operating system, database platform, and network environment provide a reliable, controlled foundation for GxP applications; computer system validation establishes that the application running on that infrastructure performs its intended GxP functions correctly.

The distinction matters practically because each qualification effort has a different scope, different evidence sources, and different ongoing maintenance obligations. Infrastructure qualification focuses on: server hardware performance and reliability specifications, operating system version and patch level, virtualisation platform configuration, network topology and security controls, storage performance and redundancy, and backup and recovery capability. CSV focuses on: application functionality, business process requirements, data integrity controls, user access management within the application, and electronic record and signature compliance.

Both must be completed before a GxP system enters production — a validated application running on unqualified infrastructure, or qualified infrastructure hosting an unvalidated application, each represents an incomplete compliance posture. Changes to either layer must be assessed through change control for their impact on the other.

Physical server hardware and network infrastructure components are typically treated as non-configured items analogous to GAMP Category 1 or infrastructure items outside the software category hierarchy — meaning qualification rather than software validation is the appropriate framework, with qualification depth determined by GxP impact rather than software complexity.

GAMP 5 Second Edition addresses infrastructure explicitly: hardware and operating systems are treated as infrastructure layers that are qualified rather than validated, using a qualification lifecycle (IQ/OQ) rather than a full software validation V-model. The operating system version and configuration represent a controlled baseline, but the OS itself is a non-configurable commercial product whose qualification relies primarily on vendor documentation and controlled installation verification.

For virtualisation platforms — VMware, Hyper-V, and similar hypervisors — GAMP 5 guidance treats them as infrastructure components that require qualification of the hypervisor configuration, resource allocation settings, and isolation between VMs. The hypervisor software itself is not validated by the user; rather, its qualified configuration is documented and controlled through change management.

Qualification scope should be determined by a documented infrastructure impact assessment that traces which components are directly or indirectly necessary for GxP system operation — not by a blanket rule that all IT hardware requires a formal IQ protocol.

• Physical or virtual servers hosting GxP application software, databases, or application servers require formal IQ/OQ covering hardware specifications, OS configuration, and performance verification.
• Storage systems providing the disk volumes on which GxP data resides require qualification of capacity, redundancy, performance, and data protection mechanisms.
• Database management systems hosting GxP databases require qualification covering version, configuration, backup procedures, and high-availability arrangements.
• Network components — firewalls, switches, and load balancers — that mediate access to GxP systems require documented qualification of their security configuration and access control rules, though typically at a lighter depth than application servers.
• Backup and recovery infrastructure must be qualified to demonstrate that GxP data can be reliably recovered to a specific point in time within the required recovery time objective.
• Network Time Protocol servers or other time synchronisation sources that provide the reference time for GxP system timestamps require documentation and periodic verification of their accuracy.

An infrastructure impact assessment traces each component of the IT environment from the GxP application downward — application server, database, storage, operating system, hypervisor, physical host, network, and backup — and assigns a GxP impact level to each based on the consequences of failure on GxP system availability, data integrity, and audit trail completeness.

The assessment asks for each component: if this component failed or was misconfigured, could it cause a GxP application to produce incorrect results, lose data, corrupt an audit trail, or become unavailable in a way that would affect GxP operations? A "yes" answer assigns direct or indirect GxP impact and triggers formal qualification. A "no" answer — where failure would have no GxP consequence, for example a monitoring tool with no role in GxP data flow — does not require formal qualification, but the "no" conclusion must itself be documented with rationale.

The depth of qualification for each component should then reflect the severity of the GxP impact: a primary database server hosting batch release data warrants more rigorous qualification documentation than a secondary network switch in a segment not carrying GxP traffic. This proportionality principle directly parallels the risk-based approach used in GAMP 5 software categorisation and is defensible to regulators when the rationale is documented.

Server IQ must document that the hardware and software are installed exactly as specified in the approved design or configuration baseline — verifying physical installation, operating system version and patch level, required services and their configuration, security hardening settings, and network connectivity — creating a controlled, evidenced record of the qualified configuration state.

• Physical or virtual hardware specifications: processor, memory, storage allocation, and network interface configuration verified against the approved specification.
• Operating system name, version, and patch level, with confirmation that only the approved OS version is installed and that automatic updates are controlled.
• Required software components: database management system version, application runtime versions, middleware, and agents — each with version numbers verified against the approved bill of materials.
• Security hardening settings: unnecessary services disabled, default credentials changed, firewall rules configured per the approved security specification.
• User accounts and access controls: service accounts created with minimum necessary permissions, administrator accounts controlled and documented.
• Network configuration: IP address, hostname, DNS settings, and network routing verified as consistent with the approved network diagram.
• Time synchronisation: NTP client configured and verified to synchronise from the approved time source, critical for audit trail timestamp accuracy.
• Backup agent installation and connection to the backup infrastructure, with initial test backup documented.

Qualifying a virtual machine in a GxP environment requires qualification at two layers: the physical host and hypervisor layer, which provides the infrastructure the VM runs on; and the VM itself, which hosts the GxP application — a qualified VM running on an unqualified or uncontrolled hypervisor has no defensible infrastructure baseline.

The hypervisor layer qualification documents: the hypervisor software version and configuration, the resource allocation (CPU, memory, storage) dedicated to each GxP VM, the isolation controls preventing one VM from accessing another's data or consuming its resources beyond defined limits, the snapshot and backup configuration at the hypervisor level, and the change control process for hypervisor updates and VM configuration changes. This is typically a site-level or platform-level qualification that covers all GxP VMs running on the same cluster.

The VM-level qualification then documents the specific OS, software, and configuration installed within the VM, treating it identically to a physical server IQ. The qualification documentation must link the VM to its host cluster qualification, so that an inspector can trace from the GxP application through the VM to the qualified physical infrastructure. VM snapshots used in the qualification process should be documented as part of the baseline, since restoring a snapshot effectively reverts the system to a prior configuration and requires a change control assessment if applied in production.

Network components mediating access to or between GxP systems require documented qualification of their security configuration — typically at a configuration verification level rather than full IQ/OQ protocol depth — because a misconfigured firewall or load balancer can directly undermine the access controls and audit trail integrity of GxP applications.

For firewalls: the qualified configuration documents the specific rule set controlling access to GxP application ports, the prohibition on outbound connections from GxP servers to unauthorised destinations, and the logging configuration that creates a network-level audit record of access attempts. Changes to firewall rules affecting GxP system access must pass through the pharmaceutical change control process, not only IT change management.

For load balancers: qualification documents the server pool configuration, session persistence settings (relevant for applications that maintain session state), and health check configuration. A load balancer misconfiguration that routes a user session to an unqualified server node, or that exposes a maintenance port, can create a validation gap even when the individual application servers are correctly qualified. Network switches in segments carrying GxP traffic require VLAN configuration documentation and port security verification as part of the infrastructure qualification package.

Qualified infrastructure components should appear in the GxP System Inventory as distinct entries linked to the GxP applications they support — this two-level inventory structure means that when a change is made to a server, the applications whose validation baseline includes that server are immediately identifiable and their change impact can be assessed.

The infrastructure entry in the GxP inventory should capture: component name and type, physical or virtual location, OS version and patch level at last qualification, hosting provider if cloud-based, GAMP category or qualification category, current qualification status, the last qualification date, next periodic review date, and links to the qualification documentation package. The inventory entry must also list the GxP applications hosted on or connected through the component, creating a dependency map that supports change impact assessment.

When a GxP application is retired, the infrastructure entry should be reviewed to determine whether it is still required for any other GxP application. When a GxP application is validated, the infrastructure components it depends on should already be qualified — the GxP inventory provides the evidence that they are, removing the need to repeat infrastructure qualification for each new application that uses the same qualified server.

A complete infrastructure qualification package provides sufficient documented evidence that a reviewer — whether internal QA or a regulatory inspector — can confirm the component was installed and configured correctly, that the configuration is controlled, and that changes since initial qualification have been managed through an appropriate process.

• Infrastructure impact assessment documenting the component's GxP impact classification and the rationale for the qualification scope.
• Approved qualification specification or baseline configuration document defining the target installed state.
• Executed IQ protocol with test steps, expected results, actual results, and tester signatures — verifying physical or virtual installation, OS version, software components, security settings, and network configuration.
• OQ protocol verifying that the infrastructure performs correctly under normal and boundary conditions — including performance under expected load, failover behaviour, and backup and restore verification.
• Deviation records for any IQ or OQ steps that did not produce the expected result, with resolution and closure documentation.
• Qualification Summary Report confirming the infrastructure is qualified for its intended GxP support role and identifying any conditions or restrictions.
• Reference to the supporting hypervisor or physical host qualification (for virtual machine qualifications).
• Reference to the approved security configuration document, firewall rule set, or network diagram as applicable.

Security and OS patches on qualified GxP servers must be assessed through a pharmaceutical change control process — not solely through an IT change management ticket — because each patch changes the qualified configuration baseline and potentially affects the behavior or security posture of GxP applications.

A practical patch management approach for GxP environments establishes a defined assessment process: when a patch is released, a joint IT and quality assessment evaluates the patch's scope (kernel-level, library, application runtime, security-only), its applicability to GxP-hosted components, the vendor's known impact on GxP applications running on the platform, and the testing required before production deployment. Critical security patches addressing actively exploited vulnerabilities may justify an accelerated change control pathway — but even accelerated changes require a documented risk assessment and a record of who approved the decision.

Testing patches before applying them to qualified GxP production servers typically uses a qualified non-production environment (a validation or staging server with an equivalent OS and application configuration). Test results from the non-production environment provide the evidence basis for approving production deployment. The patch level applied to the production server must then be documented and the infrastructure qualification baseline updated to reflect the current patch state — which is why patch history forms an integral part of the infrastructure periodic review.

Replacing qualified server hardware — whether planned or as emergency recovery from failure — is a change to the qualified configuration baseline and requires a documented assessment determining whether the replacement hardware is equivalent to what was qualified, and whether existing qualification evidence covers the new hardware.

For planned hardware replacement with equivalent specification hardware: if the replacement uses the same hardware model family, equivalent CPU, memory, and storage specifications, and if the OS and application software are restored from a validated backup to the same versions, a change assessment documenting hardware equivalency plus a focused verification of the key IQ items (hardware specs, OS version, software versions, and configuration) is typically sufficient rather than a full re-qualification. The change record and verification evidence are added to the system's validation file.

For emergency hardware replacement following a failure: the regulatory obligation does not change because of the urgency. A temporary use arrangement — running the restored system in a controlled manner under additional monitoring while formal change assessment and verification are completed — is sometimes implemented, but the formal assessment and documentation must be completed before the system returns to uncontrolled GxP production use. The failure itself should be documented as an incident with root cause investigation, since the failure may indicate a risk to the continued qualified state of similar infrastructure.

Migrating a GxP application to a different server — whether physical-to-physical, physical-to-virtual, or between virtual hosts — is a change to the validated configuration and requires a documented impact assessment, but does not automatically require full revalidation of the application if the new infrastructure is qualified and the application configuration is verified unchanged.

The impact assessment must evaluate: whether the target server is or will be qualified to a configuration equivalent to the source, whether the application installation and configuration on the target environment is identical to the source, whether data migration from source to target was performed completely and verifiably (if applicable), whether the application behaves identically in the new environment (verified through targeted testing), and whether any integration or interface configurations were affected by the migration.

If the target infrastructure is already qualified and the application is deployed identically, a migration verification protocol — confirming the key installation parameters, application version, configuration settings, and a subset of functional tests covering critical GxP functions — may be sufficient rather than repeating the full IQ/OQ/PQ suite. The change control record, impact assessment, and migration verification results are added to the system's validation file and the GxP inventory is updated to reference the new host.

Live migration of a VM between qualified physical hosts within the same qualified cluster typically does not require a pharmaceutical change control record — provided the target host is within the same qualified cluster and the VM's resource allocation, network configuration, and application state are verified as unchanged after migration.

The reason live migration within a qualified cluster is generally acceptable without individual change records is that it is a feature of the qualified hypervisor platform, not a change to the VM's qualified configuration. The qualification of the hypervisor cluster covers the capability of VMs to migrate between hosts within the cluster. However, the hypervisor qualification must explicitly address live migration in its scope — if the original cluster qualification did not include live migration, using it subsequently is a change to the qualified environment and requires a change assessment.

Moving a VM between separate clusters, between data centres, or between different hypervisor platforms is a different matter — this represents a change to the infrastructure environment the VM operates in and requires a formal change assessment including verification that the target environment is equivalently qualified and that the VM's configuration and performance are confirmed post-migration. The distinction between in-cluster migration and cross-environment migration should be explicitly addressed in the site's GxP infrastructure change control procedure.

Decommissioning a qualified server requires a documented retirement process confirming that GxP data and applications have been migrated or archived, that data is securely erased from decommissioned storage in accordance with the data retention policy, and that the GxP inventory and VMP are updated to reflect the server's retirement.

Before decommissioning: confirm that all GxP applications previously hosted on the server have been migrated to a qualified alternative environment with validation evidence, and that all GxP data has been migrated or archived to a system that satisfies the applicable retention period. The migration must be verified as complete and accurate before the source server is retired.

After decommissioning: update the infrastructure entry in the GxP inventory to Retired status with the retirement date, archive the original qualification documentation package for the same retention period as the GxP data the server processed, and document the secure erasure of storage media in accordance with the organisation's data security policy. If the server hosted GxP records subject to regulatory retention requirements, the retirement record should confirm that the retention obligation is being met through the archive arrangement.

Cloud IaaS qualification for GxP substitutes supplier qualification and contractual controls for the physical hardware inspection that on-premises IQ performs — the regulated organisation cannot physically verify the data centre, but must obtain and document equivalent assurance that the infrastructure meets its GxP requirements.

For a major cloud provider such as AWS, Azure, or GCP, the qualification of the physical data centre and hypervisor layer typically relies on: reviewing the provider's compliance certifications (SOC 2 Type II, ISO 27001, ISO 27017) relevant to the region where GxP data will be hosted; documenting the provider's shared responsibility model to clarify which security and reliability controls the provider manages versus which the customer must configure; and obtaining the provider's documentation for the infrastructure services being used (compute instance types, managed database services, storage services) sufficient to define the qualified configuration baseline.

The customer-managed configuration layer — the OS installed on cloud compute instances, the database configuration, the network security groups and firewall rules, the IAM roles and permissions — must be qualified using the same documentation approach as on-premises IQ. The qualification must be specific to the customer's configuration in their cloud tenant, not to the provider's platform generally. A "qualified on AWS" statement without specifying the region, service type, OS version, and configuration is not a defensible qualification baseline.

The cloud shared responsibility model divides infrastructure security and compliance obligations between the cloud provider (who is responsible for the security of the cloud — physical infrastructure, hypervisor, and core services) and the customer (who is responsible for security in the cloud — OS configuration, application security, data encryption, access management, and compliance of what is deployed).

For GxP qualification purposes, the shared responsibility model means: the provider's data centre physical security, hardware redundancy, and hypervisor isolation are addressed through supplier qualification and provider audit reports rather than customer-performed qualification. The customer must qualify everything above the hypervisor: the OS image and patch level, the network security group rules restricting access to GxP instances, the IAM policies controlling who can access GxP compute and storage resources, the encryption configuration for data at rest and in transit, and the backup and recovery configuration.

A critical gap in many cloud GxP deployments is the assumption that a SOC 2 report or cloud provider certification satisfies the infrastructure qualification obligation. SOC 2 assesses the provider's security controls against its own service commitments — it does not assess whether the customer's specific configuration meets GxP requirements. The customer's qualification documentation must be specific to their own tenant configuration, not derived from the provider's general compliance posture.

Qualified GxP infrastructure must have documented, tested disaster recovery capabilities that ensure GxP data can be recovered to a verifiable point in time within a defined recovery time objective — and the DR capability itself must be tested periodically under conditions realistic enough to provide evidence of actual recoverability.

EU GMP Annex 11 Clause 16 explicitly requires that availability, integrity, and security of data be ensured in the event of system breakdown, and that a business continuity plan be established. In practice this requires: a documented Recovery Time Objective (how long the system can be unavailable before GxP operations are impacted) and Recovery Point Objective (how much data loss is acceptable), a backup regime that meets the RPO, tested restore procedures that demonstrate actual recovery within the RTO, and a documented business continuity plan describing manual procedures for critical GxP activities during system unavailability.

The testing requirement is where many organisations have gaps: periodic backup completion reports are not the same as a tested restore. Regulators expect evidence that a full restore — from backup media to a running system with data verified as complete and consistent — has been performed within the period since the last review. For GxP-critical systems, an annual tested restore to a non-production environment with documented results is the minimum defensible position.

Backup and restore verification during infrastructure qualification should demonstrate not only that backups complete successfully, but that restored data is complete, consistent, and the application runs correctly from the restored state — a backup that cannot be successfully restored is not a backup for GxP compliance purposes.

During OQ, the qualification protocol should include a backup and restore test: initiate a full backup of the GxP application data and configuration, restore to the non-production test environment, verify that the restored application starts correctly, verify that a representative sample of GxP records are present and uncorrupted in the restored system, and verify that the audit trail data is present and complete for the period covered by the backup. The test must be performed against the specific backup tool and configuration being used in production, not assumed based on the backup tool's general capabilities.

The restore test must also verify that the backup media is readable — an incremental backup strategy should be tested by restoring from the most recent full backup plus all incrementals, not just from a single backup set. Documentation must capture the time taken to complete the restore, which becomes the baseline for RTO measurement and business continuity planning.

Inspectors reviewing infrastructure qualification evidence focus on three questions: is the qualified configuration clearly defined and documented; can it be verified that the current production environment matches what was qualified; and is there evidence that changes since qualification were assessed and controlled appropriately.

Inspectors will typically request the IQ protocol for a GxP application server and then ask IT staff to pull the current server configuration from the infrastructure management system. They compare the current OS version, patch level, key software versions, and security settings against what the IQ documented as the qualified baseline. A mismatch — particularly around OS patch level, which is commonly updated without pharmaceutical change control — is a direct finding that the server is no longer in its qualified state.

Inspectors also ask about the patch management process specifically: who approves patches to GxP servers, what testing is required before a patch is applied to production, and how the qualified configuration document is updated to reflect the current patch level. An IT team that describes their patch management as an IT-only process, with no input from Quality or validation, signals that the pharmaceutical change control requirement is not being met regardless of how thorough the original server qualification was.