IQ / OQ / PQ Protocol Templates
Battle-tested IQ, OQ and PQ protocol templates — configurable to your system class and CSA risk.
IQ, OQ and PQ are the three qualification stages of computer system validation. Installation Qualification confirms the system was installed as designed. Operational Qualification verifies each function against acceptance criteria defined in advance. Performance Qualification demonstrates the system works in the real operational context, with actual users, representative data volumes and genuine business processes.
What every protocol must contain, whatever the stage
These sections are common to IQ, OQ and PQ. A protocol missing any of them is difficult to defend regardless of how well the testing was executed.
- 1
Purpose and scope
What is being qualified, what is deliberately excluded, and why.
- 2
System and environment identified
Exact software version, configuration baseline, and the environment the testing will run in.
- 3
Roles and responsibilities
Who executes, who witnesses where required, who reviews, who approves. Named roles, not just departments.
- 4
Pre-approval signatures
Signed and dated before execution begins. A protocol approved after testing is one of the fastest findings an inspector can write.
- 5
Acceptance criteria defined in advance
Each step states its expected result before it is run. 'Works as expected' is not an acceptance criterion.
- 6
Deviation handling procedure
How a failed step is recorded, investigated, assigned an impact and closed.
- 7
Traceability reference
Each test step cites the numbered requirement it verifies, so the RTM can be built from the protocols rather than assembled afterwards.
IQ — Installation Qualification
Proves the thing you tested is the thing you specified. Short, factual, and almost entirely about evidence capture.
- 8
Hardware and infrastructure verified
Servers, storage, network and operating system match the specification and are themselves qualified.
- 9
Software version and build recorded
Exact version, patch level and build number, captured as evidence rather than transcribed.
- 10
Installation per vendor instructions
Evidence the documented installation procedure was followed, including any deviations from it.
- 11
Configuration baseline captured
The applied configuration is recorded in a form you can compare against later.
- 12
Interfaces and integrations confirmed
Connections to other systems are present, authenticated and pointing at the right environments.
- 13
Security and access roles installed
Role definitions and permissions exist as specified before any functional testing.
OQ — Operational Qualification
Tests the functions against the specification under controlled conditions. This is where the bulk of scripted testing sits, and where CSA risk-sizing actually bites.
- 14
Functional requirements tested
Every requirement classified as needing scripted testing has a script, an expected result and a recorded outcome.
- 15
Boundary and negative testing
The system rejects what it should reject. Testing only the happy path is a common and visible gap.
- 16
Security and access control testing
Each role can do what it should and cannot do what it should not, tested rather than asserted.
- 17
Audit trail verification
Entries are generated, capture the previous value, carry user and timestamp, and cannot be disabled by a user.
- 18
Electronic signature testing
Re-authentication, signature meaning, author-cannot-approve-own-work, and record freezing after signature.
- 19
Backup and restore tested
A restore is actually performed and the restored data verified. A backup never tested is not a control.
- 20
Alarms, limits and error handling
The system behaves correctly when something goes wrong, not only when it goes right.
PQ — Performance Qualification
The stage most often weakened into a second OQ. PQ has to look like real operation or it proves nothing new.
- 21
Executed in the production environment
Not in development or a sandbox. Running PQ outside the validated environment is a recurring audit finding.
- 22
Real user roles performing real tasks
Actual trained users running their own workflows end to end, not a validation engineer with an admin account.
- 23
Representative data volumes
Enough data to reflect genuine load. A three-record test proves nothing about a system that will hold three million.
- 24
End-to-end business process coverage
Complete processes across any system boundaries involved, not isolated functions.
- 25
Sustained-period observation
Where the process runs over time, performance is observed across a defined period rather than a single run.
Closing out
- 26
Executed protocol reviewed and approved
Reviewed by QA, with every deviation closed and every attachment present and legible.
- 27
Qualification report per stage
Summarises what was tested, what deviated, how it was resolved, and the conclusion for that stage.
- 28
RTM updated
Coverage reflects actual executed results, including any requirement left untested and the reason.
Scale the depth to the GAMP category and the functional risk assessment. A Category 3 non-configured product will not need the OQ depth a Category 5 bespoke system demands, provided the rationale is written down.
Execute in order. IQ before OQ, OQ before PQ, each with its report approved before the next begins. Overlapping stages to save time is the compression that most often has to be redone.
This is a working aid, not a regulatory document, and it does not replace your own quality system procedures.
Explore related resources, products and services: GxP Copilot, TraceDraft, validation services, AI transformation.
Common questions
Prefer to talk first? Chat with us on WhatsApp or book a call with an expert.
What is the difference between IQ, OQ and PQ?
IQ confirms the system was installed as designed — correct version, approved configuration, qualified infrastructure. OQ verifies each functional requirement against acceptance criteria defined in advance, under controlled conditions. PQ demonstrates the system performs in the real operational context, with trained users, representative data volumes and genuine end-to-end business processes.
Can IQ, OQ and PQ be combined into one protocol?
For low-risk Category 3 systems a combined IQ/OQ is common and defensible when the validation plan states the rationale. Combining OQ and PQ is harder to defend, because PQ must demonstrate something OQ cannot: real users, real data volumes and real processes in the production environment.
Does PQ have to run in production?
It should run in the validated production environment. Executing PQ in a development or sandbox environment is a recurring audit finding, because the point of PQ is to show the system performs where it will actually be used, with the real configuration, real integrations and real data volumes.
What is the most common IQ/OQ/PQ audit finding?
Protocols approved after execution rather than before. Close behind: acceptance criteria written as 'works as expected', deviations closed without a documented investigation, PQ executed outside the production environment, and screenshots that are illegible or cannot be attributed to who captured them.
How many test scripts does OQ need?
As many as the functional risk assessment calls for, not a fixed number. Requirements scored high risk get scripted scripts with evidence; medium-risk requirements may be covered by unscripted testing with a session record; low-risk requirements may rely on supplier evidence. What makes the number defensible is the written rationale, not the count.
Put this to work on your system.
Bring a URS. We show you risk-sized testing on your own requirements.
- We reply within one business day
- We run your URS live on the call
- You get a clear plan for your system