Computerized System Operational Qualification (OQ) Protocol

This is a ready-to-use operational qualification protocol for a GxP computerized system. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, attach the approved functional specification and configuration the protocol calls for, and route it through your normal document control, review, and approval. A worked filled specimen 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.

Computerized system OQ proves that the configured software behaves as the functional specification says it does, across the conditions it will face in use. It is the stage after installation qualification (IQ), which confirmed the software, configuration, and environment were installed correctly, and before performance qualification (PQ), which runs the system end to end with trained users on real business workflows. OQ challenges the system against its own design: every function the functional specification (FS) defines, the security model and role permissions, the audit trail, every formula and calculated value, configured alarms and limits, the negative and boundary behavior the system must refuse or warn on, the interfaces to other systems, and the data integrity controls that keep records attributable and complete. The thread to keep in view is traceability. Each OQ test must point back to a specific requirement in the user requirements specification (URS) or the FS, and forward to a result that either meets a pre-stated acceptance criterion or is dispositioned as a deviation. Under FDA’s Computer Software Assurance approach, the rigor and the evidence you capture should scale with the risk of each function, so the highest-risk functions get scripted, screenshot-backed testing while low-risk functions can rely on lighter evidence. Pass OQ and you have a documented, traced baseline of system behavior that PQ, periodic review, change control, and the eventual inspection all build on.

Document control header

1. Purpose

This protocol defines the approach, test cases, and acceptance criteria to demonstrate that <<FILL: SYSTEM NAME>> version <<FILL: version>>, as configured at <<FILL: site / environment>>, operates in accordance with the approved functional specification <<FILL: FS-ID>>. The objective is to confirm, with documented evidence, that the system’s functions, security model, audit trail, calculations, alarms, interfaces, and data integrity controls perform as specified across normal, boundary, and error conditions, before the system is used for GxP work.

2. Scope

This protocol covers operational testing of the configured functions of the system in the qualified test environment described in section 5. It covers the functions, roles, calculations, alarms, interfaces, and data integrity controls listed in the traceability matrix at Attachment 1. It does not cover installation, which is confirmed by IQ <<FILL: IQ-ID>>; it does not cover end-to-end business-process performance with production data and trained users, which is confirmed by PQ <<FILL: PQ-ID>>; and it does not cover infrastructure qualification, which is governed by <<FILL: cross-reference>>. Functions assessed as no GxP impact in the risk assessment are listed in Attachment 4 as not tested, with the rationale.

3. Responsibilities

4. Definitions

• Operational qualification (OQ): documented verification that a configured system operates as intended across its defined operating conditions, before live use.
• Functional specification (FS): the approved document that defines what the system must do, function by function; OQ tests trace to it.
• Configuration item: a setting, parameter, role, formula, limit, or workflow value that defines how the configured system behaves and that is controlled as a baseline.
• Negative test: a test that confirms the system correctly refuses, blocks, or warns on an invalid input, an unauthorized action, or an out-of-range value.
• Boundary test: a test at the exact edge of an allowed range and just outside it, where defects most often hide.
• Review by exception: a verification approach where validated reports or filters surface the records that matter rather than reading every entry.
• Test evidence: the objective record that a test was run and what it produced, for example a screenshot, a system-generated report, or a printout, attributable and dated.

5. Test environment and prerequisites

OQ runs in a controlled environment whose configuration is known and frozen for the duration of the test. Record the environment so a result can be tied to a specific build and configuration.

Prerequisites to be confirmed and recorded before execution starts:

1. IQ is complete and approved, with no open IQ deviations that affect OQ.
2. The FS, URS, configuration baseline, and risk assessment are approved and under change control.
3. Test accounts exist for every role to be tested, provisioned by IT, with credentials issued to named testers.
4. The test data set is loaded, defined, and version controlled.
5. Testers are trained on this protocol and on the system functions they will execute.

6. Test approach and rigor by risk

Allocate test method and evidence by the GxP risk of each function, recorded in the risk assessment and the traceability matrix. This keeps effort on the functions that can hurt product or patient and avoids burning the same rigor on trivial features.

Every executed result is recorded as Pass or Fail against a pre-stated, objective acceptance criterion. “Looked fine” is not an acceptance criterion. A Fail is a deviation per section 14, not a quiet re-run.

7. Functional testing against the FS

Test each in-scope function the FS defines. For each, confirm the function performs the specified action and produces the specified output. Trace every function to an FS requirement number in Attachment 1.

8. Security, roles, and electronic signatures

Confirm the access model enforces what the FS and your access procedure require, including that ordinary users cannot do administrator-only actions and cannot turn off controls.

9. Audit trail testing

Confirm the audit trail is on, cannot be disabled by ordinary users, captures the who, what, when, old value, new value, and reason, and is itself protected from edit.

10. Calculation testing

Test every GxP-relevant formula against an independently calculated expected value. Verify each at a normal value, at the boundaries, and where rounding or unit conversion applies. Independent means calculated outside the system under test, for example by hand or in a separately verified spreadsheet, not by the same code.

11. Alarms, limits, and flags

Confirm configured limits, specification flags, and alarms fire at the right value, in the right direction, and are visible and recorded.

12. Negative and boundary testing

Confirm the system refuses what it must refuse and behaves correctly at the edges. Negative and boundary tests are where defects hide; the most credible OQ packs always include them on high-risk functions.

13. Interfaces and data integrity

13.1 Interfaces

Where the system sends or receives data, confirm the data crosses correctly, completely, and without silent loss or transformation. Test the round trip and at least one error path.

13.2 Data integrity (ALCOA+)

Confirm records hold up against the full ALCOA+ attribute set: that each record can be tied to the person who made it, stays readable, is captured at the time the work happens, keeps the source values rather than a reworked copy, is correct, and on the plus side is whole, free of internal contradiction, durable over its retention life, and retrievable when needed.

14. Deviations and handling

Any test that fails its acceptance criterion, any execution error, or any departure from this protocol is documented as a test deviation per <<FILL: deviation SOP-ID>> and assessed for impact before the result is accepted. Record the deviation, its root cause, the corrective action (for example a configuration fix or an FS clarification), and the retest. Do not pass a failed test by editing the script after the fact or by re-running until it passes without a recorded reason. Where a deviation reflects an acceptable as-built behavior, the FS or configuration is updated under change control and the deviation references that change.

15. Acceptance criteria

OQ is acceptable, and the system may move to PQ or release, only when all of the following are true:

• Every in-scope function in the traceability matrix has an executed test with a Pass result, or a closed deviation with QA-approved disposition.
• Security, audit trail, calculation, alarm, negative/boundary, interface, and data integrity tests all meet their pre-stated acceptance criteria or are dispositioned.
• Every result is attributable, with objective evidence attached for high-risk and medium-risk functions.
• No open deviation affects the qualified state.
• Tester and reviewer signatures are present, and the tester did not approve their own result.

16. Test case record (per test)

Each executed test is recorded on the format below or your equivalent test script.

17. Summary report

On completion, the validation lead issues report <<FILL: report number>> summarizing the tests executed, the Pass/Fail outcome against the traceability matrix, every deviation and its resolution, the residual risk, and the conclusion on the operational qualified state. The report is reviewed and approved by QA. A traceability matrix showing every URS/FS requirement linked to its test ID and result is attached.

18. Attachments

19. References

21 CFR Part 11 (electronic records and electronic signatures), including 11.10, 11.50, 11.70. 21 CFR 211.68 (automatic, mechanical, and electronic equipment). EU GMP Annex 11 (Computerised Systems), sections on validation, accuracy checks, security, audit trails, and interfaces. EU GMP Annex 15 (Qualification and Validation), 2015 revision. FDA Guidance, Computer Software Assurance for Production and Quality Management System Software, issued 3 February 2026 (superseding the 24 September 2025 final). FDA Guidance, General Principles of Software Validation (2002). GAMP 5, A Risk-Based Approach to Compliant GxP Computerized Systems (Second Edition). ICH Q9, Quality Risk Management (for the risk-based rigor). PIC/S PI 011, Good Practices for Computerised Systems in Regulated GxP Environments. MHRA GxP Data Integrity Guidance and Definitions (for the ALCOA+ checks).

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

20. Revision history

21. Approvals

Filled specimen

The following shows selected OQ test cases completed for an example laboratory information management system (LIMS), so you can see the level of detail an inspector expects. The system, values, and references are illustrative; replace them with your own.

In this example the team traced each test to an FS requirement, calculated the expected mean outside the system, tested the limit flag just above the configured value, and confirmed the balance interface carried the full precision with no silent truncation. The OQ-DI-003 failure (a repeated entry overwrote the original in the audit detail view) was the kind of defect OQ exists to catch: it was raised as deviation DEV-2026-0188, root-caused to a display configuration, fixed under change control, and retested as OQ-DI-003-R with a Pass before the qualified state was accepted. That find-to-deviation-to-fix-to-retest sequence is exactly what a reviewer is expected to demonstrate.

Common inspection findings this protocol prevents

• OQ tests with no trace back to a URS or FS requirement, so coverage cannot be shown.
• Only positive (“happy path”) tests run, with no negative, boundary, or unauthorized-action testing.
• Calculations verified only by the system itself, not against an independent expected value.
• Audit trail “tested” by confirming it exists, without confirming it cannot be disabled or edited by ordinary users.
• Security testing that confirms a user can log in but never confirms a standard user is blocked from admin-only actions.
• The same person who executed a test also approved its result, with no independent review.
• A failed test quietly re-run until it passed, with no deviation recorded and no root cause.
• Interfaces accepted because “the number showed up”, with no check that precision was preserved and no error-path test.
• Test evidence missing for high-risk functions, leaving Pass results with nothing behind them.
• Same rigor applied to every function regardless of risk, which is both wasteful and, on the high-risk functions, often thin.

How to adapt this protocol

1. Set your document number, owner, report number, and effective date in the header, and confirm IQ is approved before you execute.
2. Build the traceability matrix in Attachment 1 from your real URS and FS, and assign each function a risk that drives its test method per section 6.
3. Replace the example functions, calculations, limits, and interfaces in sections 7 to 13 with your system’s actual configuration, using your configuration baseline as the source of truth.
4. Put your real independently calculated expected values into the calculation table, and state your rounding and tolerance rules.
5. Point the cross-references in sections 2 and 14 to your real IQ, PQ, configuration, deviation, and change control procedures.
6. For lower-risk functions, scale the evidence per your CSA risk assessment rather than forcing the same scripted depth everywhere.
7. Confirm every regulation in section 19 against the current published version before issue.