IQ OQ PQ template

A qualification protocol is a test plan that is approved before anyone runs it, then filled in as it runs. Each step states one action and the result the tester must see. The tester writes down what actually happened, marks it Pass or Fail, initials and dates it, and points any Fail at a deviation. The summary report closes it: what ran, what failed, how each failure was resolved, and whether the system is fit for its intended use.

• IQ, installation qualification: is the system installed and configured as specified?
• OQ, operational qualification: does each function do what the requirements say, including limits and error handling?
• PQ, performance qualification: does it work in your real process, with your people, over a defined period?

How to use this IQ OQ PQ template

1. Pick IQ, OQ or PQ. Each type keeps its own protocol, so you can draft all three for one system.
2. Under Write, fill the header: protocol number, version, release, the URS it traces to and the risk assessment. Then the objective, scope and acceptance criteria.
3. Write one step per requirement: the requirement id and rule, the action, the expected result. Route this version for pre-execution approval.
4. Under Execute, record the actual result in words with an evidence reference, choose Pass or Fail, and add initials, date and any deviation. Retest a Fail in a new step; never overwrite it.
5. Write the conclusion. When the status reads Ready for the summary report, print or copy the protocol. The copied step table is tab-separated, so it pastes into a spreadsheet or a Word table.

The terms come from equipment and process validation. They carry over to software with one shift: for a balance the hardware is the thing being qualified, for a LIMS or an eQMS the configuration is. Two labs running the same release with different settings have two different systems, and the IQ is where your settings get written down.

Industry practice, not regulation text. Our summary.

For a cloud system the IQ shrinks. You cannot inspect the vendor's servers, so you record the tenant, the release, your configuration and the vendor evidence you rely on. The OQ and PQ stay much the same, because they test your configuration and your use. The guide to Part 11 for cloud and SaaS systems covers what to ask the vendor for.

EU GMP Annex 11 draws the same line in one sentence of its principle: “The application should be validated; IT infrastructure should be qualified.” Servers and networks are qualified once, under an infrastructure procedure; each application on them is validated for its own intended use.

The tool opens on OQ-LIMS-004, an executed OQ of a configured QC LIMS results module. It has 14 steps, each tied to one sentence of Part 11: § 11.10(e) for the audit trail, § 11.50 for what a signature shows, § 11.70 for signature linking and § 11.200 for the signing components.

Step 08 is the kind of gap an OQ exists to find: the screen shows the meaning, the printout drops it. § 11.50(b) wants the printed name, date and time, and meaning on any human readable form of the record, “such as electronic display or printout”. The report template was fixed under change control and the check was rerun as step 09. The Fail stays on the record; overwriting it with a Pass would erase the evidence that the deviation process worked. To check a signature block on its own, use the signature manifestation check.

Part 11 never says IQ, OQ or PQ. Its rule is § 11.10(a): “Validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records.” How you organise that validation is your choice, and the three protocols are one common way to organise it.

FDA's General Principles of Software Validation (final, January 2002) names them in § 3.1.3: “industry documents and other FDA validation guidance sometimes describe user site software validation in terms of installation qualification (IQ), operational qualification (OQ) and performance qualification (PQ).” It calls that terminology “one of many legitimate ways to organize software validation tasks at the user site”, and adds that it “is not used elsewhere in this document.” What it asks for instead, in § 5.2.6 on user site testing, is “a pre-defined written plan with a formal summary of testing and a record of formal acceptance”, and “evidence that hardware and software are installed and configured as specified”. That last line is an IQ by another name.

For drug manufacturing, FDA's 2011 process validation guidance uses qualification for “activities undertaken to demonstrate that utilities and equipment are suitable for their intended use and perform properly”, and calls the next stage process performance qualification (PPQ). Its checklist reads like an IQ and an OQ: equipment “built and installed in compliance with the design specifications”, then shown to operate “in accordance with the process requirements in all anticipated operating ranges”.

FDA's Computer Software Assurance guidance, in its current version of February 3, 2026, does not use the three terms at all. It speaks of assurance activities, scripted and unscripted testing, and the record.

FDA wrote the CSA guidance for medical device makers and the software they use “as part of production or the quality management system”. It sorts each feature by process risk: high, where failure “may result in a quality problem that foreseeably compromises safety”, or not high. For high process risk it suggests “more rigor such as the use of scripted testing or a hybrid approach”; for the rest, makers “may consider using unscripted testing methods such as scenario testing, error-guessing, exploratory testing”. Both are recommendations, not rules. The comparison of CSA and CSV walks through what changed.

In this template's terms, that means:

• Scripted protocol where the risk is high. The example OQ is scripted because its risk assessment rated the audit trail and signatures on QC results high: they carry the release decision.
• A shorter record where it is not. FDA's own example is a spreadsheet that graphs nonconformance data: one exploratory session, a goal, a Pass or Fail per objective, one deviation and a conclusion. The template's steps still work for that; write fewer of them.
• Lean on the vendor and the install. For supporting software, assurance “may be sufficiently established by leveraging vendor evaluation and validation records, software installation, or software configuration”, so further testing may be unnecessary.
• Use the system's own records as evidence. FDA recommends “system logs, audit trails, and other data generated and maintained by the software, as opposed to paper documentation, screenshots”. Evidence E-01 to E-06 in the example could be the trail export itself.

Whatever the method, CSA recommends the record hold the intended use, the risk result, the testing done, issues found, a conclusion on acceptability, who tested and when, and review and approval when appropriate. The summary report section above carries each of those. To decide feature by feature which ones need a scripted step, run the CSA validation scope planner first.

Protocols are the middle of the file, not the whole of it. A lab that hands an inspector three executed protocols with no requirements behind them has shown that the system does something, not that it does what the lab needs.

1. The validation master plan sets the approach, the systems in scope and who signs what.
2. The user requirement specification numbers what the system must do. Those numbers are the refs in each protocol step.
3. The IQ, OQ and PQ test the requirements, in that order, each approved before it runs.
4. The traceability matrix links every requirement to its step and result, and shows any requirement with no test.
5. The validation report closes the file and releases the system for use.

The guide to computer system validation for small labs covers the whole lifecycle, including periodic review. If you would rather execute protocols in software than on paper, the paperless validation software comparison reads those tools against the Part 11 rows.

The rule text and guidance this template is built from, each read on the date shown.

1. 21 CFR Part 11, Electronic Records; Electronic Signatures (eCFR), National Archives and FDAread 2026-10-22
2. General Principles of Software Validation; Final Guidance for Industry and FDA Staff (January 2002, PDF), FDA, CDRHread 2026-10-22
3. Process Validation: General Principles and Practices (January 2011, PDF), FDA, CDER, CBER and CVMread 2026-10-22
4. Computer Software Assurance for Production and Quality Management System Software (February 3, 2026, PDF), FDA, CDRH and CBERread 2026-10-22
5. EudraLex Volume 4, Annex 11: Computerised Systems (2011, PDF), European Commissionread 2026-10-22