Computerized System Installation Qualification

Computerized system Installation Qualification (IQ) provides documented evidence that the approved application, technical components, and supporting environment have been installed or provisioned correctly.

IQ should establish what is installed, where it operates, how it is identified, which services it depends upon, and whether the resulting environment matches the approved architecture and specifications.

It is not system-release approval. Release requires additional evidence that configured functions, controls, interfaces, procedures, training, and representative business processes support the approved intended use.

Purpose of Installation Qualification

Installation and environment qualification should confirm that:

approved hardware and software are present;
component identities and versions are recorded;
required modules and services are enabled;
unapproved components are absent or controlled;
the server or cloud environment is correctly provisioned;
databases, middleware, storage, and network dependencies are established;
authentication and security services are available;
time synchronization, certificates, monitoring, and backup agents are configured;
environments are appropriately separated;
required documentation and licenses are available;
installation discrepancies are resolved;
and an approved technical baseline has been established.

For drug-manufacturing applications, 21 CFR 211.68 addresses automatic, electronic, computer, and related systems, including checks intended to assure satisfactory performance and controls over system changes.

Where Part 11 applies, 21 CFR 11.10 requires controls supporting system accuracy, reliability, consistent intended performance, record protection, access restriction, and documentation control. IQ contributes to this evidence but does not satisfy these requirements by itself.

IQ Within the Validation Lifecycle

The scope and approach should be defined in Computerized System Validation Planning and Strategy.

IQ generally follows approval of the applicable:

intended use;
system boundary;
requirements;
architecture;
infrastructure design;
installation instructions;
security requirements;
and configuration specifications.

It normally precedes or supports:

configuration verification;
functional and control testing;
interface testing;
security testing;
data migration;
backup and restoration testing;
end-to-end testing;
and system release.

Some activities may overlap in iterative or agile implementations. The required evidence and acceptance criteria should still be defined, reviewed, and traceable.

Define the Qualification Boundary

The IQ boundary should identify the application and the technical services necessary for its operation. The boundary may include:

application servers;
database servers;
web servers;
virtual machines;
containers;
cloud resources;
operating systems;
database-management systems;
middleware;
storage;
network services;
domain and identity services;
time sources;
certificates;
backup agents;
monitoring agents;
endpoints;
printers;
scanners;
instruments;
and interfaces.

The boundary should also identify shared services qualified through separate records.

For example, an application may depend on an enterprise domain service, network, backup platform, or virtual environment governed under IT Infrastructure Qualification for GMP Computerized Systems. The application IQ may reference that evidence while verifying the application-specific connection, dependency, and configuration.

Computerized-system installation and environment qualification boundary covering the application, data layer, identity services, compute environment, infrastructure services, documentation, and approved technical baseline. — Installation qualification verifies the application and the technical services required to support its approved operating environment.

Approved Installation Basis

Installation verification should compare the observed environment with approved information. The installation basis may include:

system architecture;
infrastructure design;
approved specifications;
supplier installation instructions;
bills of materials;
approved software versions;
compatibility requirements;
security standards;
cloud-resource definitions;
network diagrams;
interface specifications;
certificate requirements;
backup requirements;
and configuration standards.

The approved basis should be sufficiently specific to establish acceptance criteria.

A test stating “verify that the server is installed correctly” is not adequate unless the expected server identity, operating system, resources, network placement, and required services are defined elsewhere.

Hardware and Compute Resources

Applicable hardware or compute resources should be identified and verified. Verification may include:

manufacturer and model;
asset number;
serial number;
processor allocation;
memory;
storage capacity;
network adapters;
connected peripherals;
redundancy;
physical or virtual location;
and support status.

For virtual or cloud environments, the record may identify:

virtual-machine name;
tenant or subscription;
account or project;
region and availability zone;
resource group;
image or template;
instance type;
processor and memory allocation;
attached storage;
network segment;
and applicable availability configuration.

The objective is not to record every technical detail. The record should capture the attributes needed to identify the qualified environment and evaluate later changes.

Application Software and Versions

IQ should confirm the identity of the installed application. Applicable information may include:

product name;
supplier;
application version;
build or patch level;
installation package;
package checksum or approved source;
installation date;
environment;
installation account;
installed services;
enabled modules;
language or regional components;
and support status.

Version information should be obtained from a reliable source, such as:

the application interface;
an installed-component inventory;
package-management records;
controlled deployment records;
or supplier-supported commands.

A filename alone may not provide reliable version evidence.

Enabled Modules and Components

Commercial applications may include modules that are licensed, installed, configured, or enabled independently. IQ should identify:

modules required for intended use;
modules installed but disabled;
optional components;
plugins;
extensions;
drivers;
integration services;
report services;
and administrative utilities.

Unneeded modules should be disabled or otherwise controlled when they could introduce unnecessary access, functions, interfaces, or security exposure.

Enabled modules should be consistent with the approved architecture, license entitlement, and validation scope.

Operating System

The operating-system baseline may include:

operating-system name;
edition;
version;
build;
architecture;
installed language;
time zone;
patch level;
required system services;
disabled services;
security configuration;
and support status.

The record should identify whether the operating system is dedicated to the application or shared with other services.

Applicable operating-system hardening may be verified through an approved technical standard, automated configuration report, or referenced infrastructure qualification evidence.

Database Environment

Database verification may include:

database product;
edition and version;
instance name;
database name;
host or managed-service identifier;
character set;
collation;
time-zone configuration;
storage allocation;
encryption settings;
service accounts;
authentication method;
backup integration;
high-availability configuration;
and support status.

The IQ should confirm that the application connects to the intended database environment. Functional verification should later demonstrate that the application correctly creates, retrieves, updates, and protects records.

Database content, business rules, calculations, and data integrity are not established merely by confirming the database installation.

Middleware and Supporting Software

Middleware may provide communication, scheduling, integration, messaging, reporting, or data-transformation services. Applicable components may include:

web servers;
application servers;
integration engines;
message brokers;
file-transfer services;
report servers;
runtime libraries;
job schedulers;
API gateways;
and container platforms.

The qualification record should identify:

component and version;
host or service location;
installed instance;
required ports;
service identity;
dependencies;
startup behavior;
monitoring;
and support status.

Where middleware performs regulated transformations or controls transaction processing, later functional and interface verification should assess its behavior.

Network Configuration

Network verification should establish that the system is connected to the approved network environment. Applicable checks may include:

host name;
Internet Protocol address or approved dynamic allocation;
network segment;
Domain Name System resolution;
required ports and protocols;
firewall rules;
proxy configuration;
load balancer;
routing;
remote-access path;
and network redundancy.

IQ should verify required connectivity without implying that complete interface behavior has been tested.

For example, confirming that a port is reachable does not demonstrate that data are mapped, transmitted, acknowledged, and reconciled correctly.

Endpoints and Client Devices

Systems accessed through workstations, mobile devices, thin clients, terminals, or browsers may require verification of the supported client environment. Applicable checks include:

endpoint type;
operating-system version;
browser and version;
client application;
screen resolution where relevant;
local drivers;
device security;
domain membership;
printing capability;
and controlled software deployment.

It may be unnecessary to qualify every identical workstation separately. A justified representative approach may be used when endpoints are deployed from a controlled standard image and managed consistently.

Domain Configuration and Authentication

The installed environment should be connected to the approved identity and authentication services. Verification may address:

domain membership;
identity provider;
directory connection;
authentication protocol;
single sign-on;
multifactor authentication integration;
service accounts;
group membership;
privileged accounts;
password-management dependencies;
and account-lockout services.

IQ confirms that the required authentication architecture and technical dependencies are established.

Testing of user roles, permissions, segregation of duties, unauthorized actions, and electronic signatures belongs within functional and security verification.

Service Accounts

Service accounts may operate application services, interfaces, scheduled jobs, databases, backups, or monitoring tools. The installation record should identify:

account purpose;
account owner;
service or component using the account;
authentication method;
privilege level;
password or credential-management method;
interactive-login restrictions;
and expiration or rotation controls.

Credentials should not be exposed in IQ evidence. The record should confirm the control without reproducing passwords, private keys, tokens, or other secrets.

Time Synchronization

Accurate and consistent system time supports:

audit trails;
electronic signatures;
event sequencing;
interface records;
security logs;
alarms;
and investigations.

IQ should verify:

the approved time source;
time-synchronization service;
time zone;
expected synchronization hierarchy;
and monitoring of synchronization failures where applicable.

The test should confirm the technical configuration. Later verification should demonstrate that application records and audit trails display and retain timestamps correctly.

Certificates and Encryption Dependencies

Certificates may support:

encrypted web sessions;
interfaces;
digital signatures;
service authentication;
device authentication;
and secure file transfer.

Applicable IQ checks include:

certificate subject;
intended use;
issuing authority;
validity period;
host or service assignment;
trust chain;
key-storage location;
and renewal ownership.

Private keys and confidential certificate material should not be included in validation evidence.

Certificate-expiration monitoring and renewal should be assigned to an identified operational owner.

Storage

Storage verification may include:

storage type;
volume or mount point;
allocated capacity;
file-system type;
permissions;
encryption;
redundancy;
retention-related controls;
and monitoring thresholds.

Separate locations may be required for:

application files;
database files;
attachments;
exports;
temporary files;
logs;
interface files;
backups;
and archives.

IQ should confirm that the intended storage locations are available and appropriately controlled. Retention, retrieval, archival, and restoration require additional lifecycle evidence.

Backup Agents and Configuration

The installation should confirm that required backup components are present and connected to the approved backup service. Verification may include:

installed backup agent;
agent version;
protected host or service;
backup policy assignment;
included data and configuration;
scheduled frequency;
monitoring status;
and responsible support group.

Confirmation that a backup agent is installed does not demonstrate recoverability. Restoration testing should verify that required data, metadata, configuration, and application services can be recovered.

FDA’s Data Integrity and Compliance With Drug CGMP guidance emphasizes controls needed to maintain complete, consistent, and accurate CGMP data. Backup configuration should be evaluated as part of the broader record-protection and recovery strategy.

Monitoring and Logging

Monitoring may address:

server health;
service availability;
storage capacity;
database status;
backup failures;
certificate expiration;
time synchronization;
interface queues;
security events;
and performance thresholds.

IQ should verify:

required agents or services;
monitoring platform connection;
monitored components;
assigned alert destinations;
and applicable logging locations.

Operational testing should later confirm that significant failures generate the expected alert and that the alert reaches the responsible support function.

Printers and Peripheral Devices

Printers may be significant when they generate:

product labels;
laboratory worksheets;
controlled forms;
certificates;
reports;
or other regulated output.

Applicable verification includes:

printer identity;
model;
network address;
driver;
print queue;
location;
approved media;
and application assignment.

Functional testing should verify report content, formatting, barcodes, labels, page completeness, and routing to the correct printer.

Other peripherals may include:

scanners;
barcode readers;
signature pads;
balances;
instrument connections;
and specialized input devices.

Interfaces

The IQ should identify application interfaces and verify that their technical components are installed or provisioned. Applicable evidence may include:

interface name;
source and destination;
middleware service;
endpoint;
port and protocol;
service account;
certificate;
file location;
queue;
scheduled job;
and monitoring service.

Technical connectivity is only part of interface assurance. Field mapping, transformations, acknowledgments, duplicate handling, rejected transactions, reconciliation, and recovery should be addressed through Computerized System Interfaces and Data-Transfer Controls.

Cloud and SaaS Environments

For cloud-hosted or software-as-a-service systems, traditional server-level access may be limited or unavailable.

Installation evidence may therefore rely on:

supplier provisioning records;
tenant identification;
subscription and region;
enabled services;
service configuration;
architecture documentation;
supplier qualification evidence;
certificates or attestations;
and customer-visible configuration records.

The customer should still verify elements under its control, including:

tenant configuration;
enabled modules;
user federation;
role integration;
interfaces;
data location commitments;
backup and recovery responsibilities;
monitoring arrangements;
and environment separation.

The division of responsibility should be consistent with Cloud and SaaS Systems in GMP Environments.

Environment Separation

Development, test, validation, training, and production environments should be separated according to system risk and operating model. IQ should verify applicable separation through:

separate servers or cloud resources;
separate databases;
separate tenants or instances;
network controls;
distinct URLs;
access restrictions;
deployment controls;
data controls;
and clear environment identification.

Production data should not be copied into nonproduction environments without approved controls addressing confidentiality, record integrity, and data handling.

Environment separation should prevent uncontrolled development or testing activity from affecting the production system.

Security Configuration

Installation qualification should verify the applicable technical security baseline. This may include:

host hardening;
firewall status;
encryption;
antivirus or endpoint protection;
vulnerability-scanning integration;
remote-access configuration;
disabled default accounts;
removal or control of supplier accounts;
restricted administrative tools;
logging;
and secure configuration of installed services.

IQ confirms the installed security settings. Functional security testing should verify that the application enforces the approved roles, permissions, and restricted actions.

Documentation

Required documentation may include:

architecture diagrams;
installation instructions;
administrator guides;
configuration specifications;
security standards;
interface documentation;
backup and recovery instructions;
supplier manuals;
release notes;
license records;
certificates;
support contacts;
and system inventories.

IQ should verify that required documentation is:

available;
applicable to the installed version;
approved where required;
protected from uncontrolled change;
and accessible to authorized support personnel.

Licenses and Entitlements

License verification should confirm that the organization is authorized to use the installed software and enabled modules. Applicable records include:

product license;
licensed modules;
number or type of users;
subscription term;
tenant entitlement;
database license;
middleware license;
support agreement;
and renewal ownership.

License expiration should not create an uncontrolled risk to system availability, data access, or record retention.

Installation Execution and Evidence

Installation may be performed:

manually by the supplier;
manually by site personnel;
through an approved deployment package;
through infrastructure-as-code;
through automated software distribution;
from a controlled virtual-machine image;
or through cloud provisioning.

The installation record should identify:

installation method;
responsible individual or automated process;
date;
source package or approved image;
environment;
resulting component identities;
verification results;
and associated discrepancies.

Evidence may include:

installation logs;
deployment records;
system-information reports;
configuration exports;
screenshots;
automated inventory reports;
command outputs;
cloud-resource records;
and supplier provisioning records.

Evidence should be selected for its value. Large collections of screenshots should not replace clear identification of the installed baseline.

Discrepancies

Any difference between the approved installation basis and the observed environment should be documented. Examples include:

unexpected software version;
missing module;
additional service;
incorrect server allocation;
unsupported operating system;
unapproved port;
missing certificate;
backup agent not connected;
incorrect time source;
insufficient storage;
undocumented account;
or incomplete installation documentation.

The discrepancy record should identify:

what was expected;
what was observed;
the cause;
affected requirements and risks;
corrective action;
required reverification;
and final disposition.

A discrepancy may be corrected, justified as acceptable, or formally accepted with residual risk. It should not be hidden by changing the expected result after execution without documented assessment.

Installation qualification workflow comparing the approved installation basis with the observed environment, resolving discrepancies, approving evidence, and establishing the controlled baseline. — Differences between the approved design and observed installation must be corrected, justified, or formally accepted before the technical baseline is approved.

Establishing the Controlled Baseline

The approved IQ establishes the initial technical baseline for the implemented environment. The baseline should identify, as applicable:

application and module versions;
operating system;
database;
middleware;
servers or cloud resources;
network placement;
storage;
identity dependencies;
service accounts;
certificates;
backup configuration;
monitoring configuration;
interfaces;
endpoints;
printers;
and controlled documentation.

The baseline may be represented through several connected records rather than one document. Requirements Traceability and Validation Evidence should identify the applicable evidence and final status.

Subsequent changes should be evaluated against this baseline.

Boundary Between IQ and Application Validation

Installation Qualification is part of the overall computerized-system validation lifecycle. Its purpose is to establish documented evidence that the approved application and supporting technical environment have been installed or provisioned correctly. IQ confirms component identities, software versions, enabled modules, infrastructure dependencies, environment separation, security configuration, and the initial controlled baseline.

Functional verification builds upon this qualified foundation. It demonstrates that the configured application performs its approved requirements and intended GxP use. This includes workflows, calculations, business rules, security roles, audit trails, electronic signatures, reports, interfaces, exception handling, record protection, and representative end-to-end processes.

The boundary is based on the verification objective rather than the name of the component. IQ may confirm that a database, printer, certificate, backup agent, interface service, or authentication connection is installed and correctly configured. Subsequent functional testing must determine whether that component performs correctly within the complete business process. Confirming that a printer and driver are installed, for example, does not demonstrate that a regulated label contains the correct information, format, barcode, and destination.

Some controls require evidence from both activities. IQ may verify that an audit-trail service is installed, enabled, and connected to the correct database. Functional testing must then demonstrate that applicable user and system actions generate complete, accurate, protected, and reviewable audit-trail entries. Similarly, IQ may confirm that a backup agent and policy are assigned, while restoration testing must demonstrate that required data, metadata, configuration, and application services can be recovered.

This division keeps the evidence focused without creating an artificial separation. IQ establishes the approved technical baseline; functional and end-to-end verification demonstrate that the complete configured system operates reliably for its intended GxP use.

IQ Approval

IQ approval should confirm that:

required checks were completed;
evidence is attributable and reviewable;
installed components match the approved basis;
discrepancies were resolved or accepted;
the technical environment is adequately documented;
the baseline is controlled;
and the system may proceed to the next authorized validation activities.

IQ approval should not be described as production release unless the approved lifecycle specifically combines IQ completion with all other release evidence.

Lifecycle Maintenance

The technical baseline should be maintained through change control when changes affect:

application versions;
enabled modules;
operating systems;
databases;
middleware;
infrastructure;
cloud services;
storage;
network configuration;
authentication;
certificates;
backup;
monitoring;
endpoints;
printers;
or interfaces.

The change assessment should determine whether the organization must:

update installation records;
repeat selected IQ checks;
revise architecture or configuration documentation;
perform functional regression testing;
update procedures;
or establish a new approved baseline.

The baseline should also support periodic review, incident investigation, disaster recovery, migration, and system retirement.

Practical Outcome

Effective installation and environment qualification provides a clear and reproducible record of:

the installed application;
its technical environment;
its supporting services;
its approved versions and modules;
its security and operational dependencies;
its installation discrepancies;
and the controlled baseline against which future changes will be evaluated.