Computerized System Installation Qualification (IQ) Protocol

This is a ready-to-use installation qualification protocol for a GxP computerized system. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, attach the vendor documents and configuration records the protocol calls for, and route it through your normal document control, review, and approval. A worked filled specimen for a laboratory information management system (LIMS) 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.

IQ for a computerized system proves one thing: that the right software, at the right version and build, was installed correctly on the right qualified infrastructure, in the right configuration, with security, interfaces, backup, and documentation all established and recorded, before anyone tries to test what the system does. It is the installation stage of validation. Operational qualification (OQ) and performance qualification (PQ), or the equivalent CSA-scaled functional and process testing, all assume the installed state captured here. If the IQ record is wrong or thin, every later test sits on sand. Under a CSA-aligned approach (FDA guidance finalized 24 Sep 2025) you scale the depth of recorded evidence to risk, but the installed configuration of a GxP system is high value to capture regardless of method.

Document control header

1. Purpose

This protocol defines the checks and acceptance criteria to confirm that <<FILL: system name / ID>> was installed correctly in the <<FILL: environment, e.g. validated production>> environment, at the software version and build defined in the design specification, on qualified infrastructure, in the approved configuration baseline, with interfaces, security, and backup established, and with the required documentation in place, so the system is ready to enter functional and process testing. The objective is a documented, inspection-ready record that installation matches the approved specification, the vendor installation instructions, and the configuration the project agreed.

2. Scope

This protocol applies to the single computerized system and environment identified in the header and section 5, including the application software, its database and middleware, the operating system and server or virtual host it runs on, the controlling workstations or thin clients where in scope, the interfaces it exchanges GxP data through, and the backup arrangement that protects its records. It covers verification at installation only. It does not establish what the system does functionally, which is covered by the OQ or CSA functional testing referenced in the header, and it does not cover routine use, periodic review, or change control after qualification, which are governed by <<FILL: cross-reference SOP-IDs>>. Where the underlying infrastructure (server, virtual platform, network, storage) was qualified separately, that qualification is referenced here and not repeated.

3. Responsibilities

4. Definitions

• Installation qualification (IQ): documented verification that a system and its components are installed correctly, to specification, on suitable infrastructure, before functional testing.
• Configuration baseline: the complete, recorded set of configurable settings (parameters, master data, business rules, security model) that defines this installed instance, captured so any later change is visible.
• Build / version: the exact released software version plus the patch or build identifier of the application, database, and operating system as installed.
• Environment: the named instance, such as development, validation/test, or production, kept separate so testing does not touch live GxP data.
• GAMP software category: the GAMP 5 Second Edition classification (1 infrastructure, 3 non-configured, 4 configured, 5 custom) that scales the rigor of the lifecycle.
• Interface: an automated path that moves GxP data into or out of the system, for example to an instrument, an ERP, or a manufacturing system.

5. System and environment under qualification

Record the as-installed identity of the system and its host. Every field below is an inspection question, so fill each precisely rather than “see vendor docs”.

6. Test cases

Each test case states what is checked, how, the expected result, the actual result, pass or fail, and the evidence captured. Execute in order, record contemporaneously, sign and date each step, and attach the listed evidence. Where a step is not applicable, write N/A with a reason; do not leave it blank. Each case below maps to a section of the design or configuration specification named in the header.

6.1 Environment and infrastructure prerequisites

6.2 Software version and build

6.3 Installation per the design specification

6.4 Configuration baseline

6.5 Interfaces

6.6 Security setup

6.7 Backup and recovery configured

6.8 Documentation present

7. Deviations and handling

Any failed test case, departure from this protocol, or version, configuration, or security mismatch is recorded as a deviation per <<FILL: deviation SOP-ID>> and assessed for impact before installation is accepted. Each deviation records the observed result, the assessment, the resolution (correct and retest, or accept with justification), and the retest evidence. Installation is not accepted, and the system is not advanced to functional testing, until every deviation is resolved or formally justified and approved by QA.

8. Acceptance criteria (protocol level)

Installation is acceptable, and the system may enter OQ or functional testing, only when all of the following are true:

• Every test case in section 6 passed, or any failure is captured as a deviation that is resolved or formally justified and approved.
• The application, database, and operating system versions and builds match the design specification exactly.
• The configuration baseline is captured as a controlled record and matches the approved configuration specification.
• All in-scope interfaces are configured per specification and connectable.
• Security is configured per design: unique identities, password and lockout rules, role-based privileges, audit trail enabled and protected, no active default or shared accounts.
• Backup is configured to the defined scope, schedule, and retention, with a restore procedure referenced.
• Required documentation is present and version-controlled, or carries a dated completion plan.

9. Summary report

On completion, the validation lead issues report <<FILL: report number>> summarizing the test cases and their results, every deviation and its resolution, the captured configuration baseline reference, and the conclusion that installation is acceptable (or not) and the system is ready (or not) to enter functional testing. The report is approved by QA.

10. Attachments

11. References

21 CFR Part 11 (electronic records and electronic signatures). 21 CFR 211.68 (automatic, mechanical, and electronic equipment), where the system controls or records GMP data. EU GMP Annex 11 (Computerised Systems) and Annex 15 (Qualification and Validation), 2015 revision. FDA Guidance, Computer Software Assurance for Production and Quality Management System Software (current version issued 3 February 2026). ISPE GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems, Second Edition. PIC/S PI 011, Good Practices for Computerised Systems in Regulated GxP Environments. ICH Q9, Quality Risk Management (for the risk-based scaling of effort).

Confirm the current version and clause numbers of each reference before issue.

12. Revision history

13. Approvals

Filled specimen

The following shows the test-case section completed for an example LIMS installation in the production environment, so you can see the level of detail an inspector expects. The company, system, versions, and numbers are illustrative; replace them with your own.

In this example, IQ caught three real installation defects that functional testing would have inherited silently: a leftover demo database schema from the vendor default install, a single report footer field that did not match the approved configuration, and an active default vendor admin account, which is a direct 21 CFR Part 11 access-control gap. The team raised each as a deviation, removed the demo schema, corrected the footer field and re-verified the baseline, disabled the default account, and only then accepted installation and advanced to OQ. That sequence, capture the as-installed state, compare it to the approved specification line by line, and route every mismatch as a deviation before testing, is exactly what a reviewer is expected to demonstrate.

Common inspection findings this protocol prevents

• Testing performed against an installation whose software version or build was never recorded, so it cannot be proven what was tested.
• No captured configuration baseline, so later configuration changes have no documented starting point and change control cannot show what changed.
• Default or shared vendor accounts left active after install, defeating attributability under 21 CFR Part 11 and EU GMP Annex 11.
• Audit trail not confirmed enabled (and not protected from ordinary users) at installation, discovered only after live data exists.
• Validation done in a non-production environment with no record that production was installed identically.
• Backup configured but never scoped to the configuration and document store, or with no referenced restore procedure.
• Interfaces present on the live system that were never identified, configured to spec, or assessed for GxP data impact.
• “Installed per vendor” claimed with no install log, component inventory, or path/port verification to support it.

How to adapt this protocol

1. Set your document number, owner, report number, GAMP category, and effective date in the header, and point the DS, OQ/CSA, and infrastructure-qualification references to your real documents.
2. Scale the recorded evidence to risk per the CSA guidance and your GAMP category: a category 3 non-configured product needs lighter configuration capture than a category 4 configured system like the LIMS specimen, while a category 5 custom system needs more around build and code control. Keep the high-value installed-state and security evidence regardless of method.
3. Replace the test cases in section 6 with checks that map to your own design and configuration specifications, and delete any (for example interfaces) that do not apply, with a recorded reason.
4. For a hosted or SaaS system, add the supplier’s responsibility boundary: confirm which IQ elements (version, infrastructure, backup) the provider owns under the service agreement and reference their evidence, then qualify what you configure and control.
5. Point the cross-references in sections 2 and 7 to your real change-control, deviation, periodic-review, and backup/restore procedures.
6. Confirm every regulation in section 11 against the current published version before issue.