What an OQ Actually Is — and Is Not
The Operational Qualification (OQ) is the formal verification that every function in your installed, qualified PLC/SCADA system operates in strict accordance with the Functional Design Specification and Software Design Specification. It is executed in the final installed environment — on the real site network, with real field instruments and actuators, not signal generators and simulations.
It is not a repeat of the FAT. The FAT established that the system was built as designed. The OQ adds what the FAT deliberately omitted: boundary testing at acceptance limits, adversarial negative testing, and data integrity challenge testing. A well-written OQ protocol should be slightly uncomfortable to execute — if every test passes with comfortable margin and nothing is genuinely challenged, the OQ scope is probably too soft.
The OQ protocol must be approved by QA before a single test step is executed. Executing to an unapproved protocol produces invalid evidence. No exceptions, no "we'll approve it retroactively." The protocol is approved, then executed, then the report is written.
From OQ-SYS-001 Section 4 — all must be confirmed before any test begins:
IQ fully approved with all Category A deviations closed · Software hash re-verified at OQ start and confirmed to match IQ baseline exactly · All GMP-critical instruments within calibration date · All SOPs in draft form available to guide testing · System in operational state with live process connections · Personnel briefed that system will be subject to power cycling and fault simulation
OQ vs FAT — The Key Differences
The most common OQ writing mistake is producing a protocol that reads like a second FAT — same test cases, same test values, same test conditions. The OQ has a distinct purpose and scope from the FAT. Understanding the difference is what makes an OQ credible.
- Executed at supplier's works, before shipment
- Simulated I/O — signal generator, force table
- 100% of FDS functions — initial verification baseline
- Comfortable mid-range test values — establishes baseline, not limits
- Boundary testing: not required (OQ's job)
- Negative testing: included for some scenarios only
- QA witness: HIGH-risk cases only
- Output: FAT report + release for shipment
- Executed on site, in installed environment
- Live field instruments and actuators
- HIGH-risk: 100% including boundary. MEDIUM: representative
- Boundary testing at exact alarm setpoints — required
- Negative testing: required — wrong credentials, SQL modify attempts, NTP disconnect, signal loss, power failure
- QA witness: ALL HIGH-risk test cases
- Output: OQ report → authorisation to commence PQ
Where a function was fully verified at FAT with no deviation and the FDS/SDS has not changed, the OQ may reference the FAT result and perform a reduced check confirming the function still operates correctly in the site environment. This is risk-based leveraging — not skipping. The OQ test case must still be executed (even if abbreviated), signed, and must reference the FAT evidence explicitly. Any function that failed at FAT or where a deviation was raised must be fully retested in OQ — the FAT deviation does not carry forward.
The Three Types of OQ Test Step
Every test step in an OQ protocol falls into one of three categories. The mix of types is determined by the risk assessment — HIGH-risk functions require all three. The ratio of boundary and negative tests to normal operation tests is what distinguishes an OQ from a functional check.
Verifies that the function operates correctly at a representative operating point — not the limit, not a failure condition. Builds baseline evidence and confirms the function exists in the installed environment.
Tests at the exact specified acceptance limit — not 10% below it, not comfortably inside it. The OQ must demonstrate the system behaves correctly at its designed boundary, including hysteresis (alarm does not clear until it should).
Attempts something the system must prevent. Proves the system rejects unauthorised actions, handles failure modes correctly, and maintains data integrity under attack conditions. These are the tests that distinguish rigorous OQ from box-ticking.
Test Case Anatomy — Every Column Explained
The QLean OQ protocol uses a 5-column test case format. Each column has a specific purpose and a specific input to the regulatory evidence chain. Here is OQ-032 (conductivity alarm boundary test) showing the full format:
Below limit
At setpoint
Deadband
At setpoint
QA WITNESS
The test case header links directly to the FDS function, the URS requirement, and the risk assessment entry. An inspector can follow the reference chain in either direction. The Step column provides a numbered execution record. The Expected Result is the pre-approved acceptance criterion — the QA signature on the executed step certifies the actual result met this criterion.
What the OQ Must Cover
The OQ-SYS-001 template organises test cases across 12 functional areas. Every PLC/SCADA OQ must address all of these — the depth of coverage in each area is driven by the risk assessment, but no area can be omitted entirely for a GMP system:
| Functional Area | OQ Approach | Risk Level | Boundary/Negative Tests Required |
|---|---|---|---|
| Process control and alarming | Full boundary testing at each alarm setpoint. Challenge all interlocks. Verify divert/shutdown logic. | HIGH | Yes — at exact setpoint, hysteresis above, hysteresis below |
| User access control (RBAC) | Full 4-role regression. Each role tested for permitted actions and denied actions. Password policy boundary. | HIGH | Yes — wrong password, lockout after 3 attempts, Operator cannot perform Supervisor actions |
| Audit trail and data integrity | Full audit trail entry verification. SQL write-once challenge. Certified copy export test. | HIGH | Yes — SQL direct modify attempt (must be blocked), admin cannot delete records |
| NTP time synchronisation | Verify sync within ±30 seconds. Disconnect NTP — verify alarm and audit entry generated. | HIGH | Yes — NTP disconnect is the negative test |
| Data buffering and historian | 6-minute planned historian outage. Verify data buffer fills, synchronises on reconnect, gap alarm generated. | HIGH | Yes — historian disconnect with reconnect and buffer sync |
| Backup and recovery | Full restore test with RTO measurement. Simulated backup failure alarm. Hash verification after restore. | HIGH | Yes — backup failure generates alarm |
| Alarm management (ISA-18.2) | Acknowledgement state machine. Suppression boundary (Supervisor/Admin only). Alarm history retention. | HIGH | Yes — Operator cannot suppress alarms (negative) |
| HMI and report generation | Certified copy export — verify all data fields, units, timestamps preserved. Report cannot be modified after export. | MEDIUM | Yes — attempt to modify exported report (should be blocked or leave trail) |
| Interfaces (LIMS, ERP, AD) | End-to-end data cross-check. Interface loss alarm. Fallback behaviour on connection loss. | MEDIUM | Disconnect test for each critical interface |
| Cybersecurity functional | VPN + MFA session log verification. USB block attempt. Patch management process demonstration. | MEDIUM | Yes — USB insertion attempt, unauthorised access attempt |
| Maintenance mode | OOS isolation test — verify alarming suppressed for tagged-out instrument. Confirm audit trail records OOS status. | LOW | Abbreviated check — leverage SAT evidence |
| Software hash verification | Re-verify hash at OQ start against IQ baseline. Record in Section 4 prerequisites. Any mismatch = OQ cannot proceed. | HIGH | Mismatch scenario not tested — any mismatch is a Category A deviation |
Phase Gate — What Must Be True Before OQ Can Be Closed
The OQ phase gate criteria are defined in OQ-SYS-001 Section 15 and must be confirmed in writing before the OQ is declared complete and the report submitted for approval:
- All OQ test cases executed — no untested steps without documented QA justification for exclusion
- Software hash re-verified at OQ start and confirmed to match IQ-SYS-001 baseline exactly
- All executed test steps signed by executor and dated
- All HIGH-risk test cases witnessed by QA — witness initials and date recorded on each case
- All deviations from OQ execution raised in MDL-SYS-001 with MDL reference numbers
- Traceability Matrix (TM-SYS-001) updated with OQ results — all OQ test case results entered
- All four SOPs approved: System Operation, System Administration, Change Management, Periodic Review
- All operators trained and Training Records (TRF-SYS-001) on file for their role
- Zero open Category A deviations at time of OQ report approval
- All Category B deviations documented with root cause and remediation plan approved by QA
Criterion 7 — all four SOPs must be approved before OQ closure. The SOPs are not post-OQ deliverables. The System Operation SOP must exist and be approved before operators can be trained, and trained operators must be in place before PQ can start. This means the SOPs need to be drafted during OQ execution — not after. Leaving SOP authoring until PQ prep is a common and painful scheduling mistake.
OQ-SYS-001 is a complete, pre-structured OQ protocol for a GMP PLC/SCADA system — 12 functional sections, 80+ test cases, all three test types (normal, boundary, negative), QA witness flags, FAT/SAT reference columns, and the 10-criterion phase gate confirmation table. Every test case includes the boundary testing sequence (below setpoint → at setpoint → within hysteresis → below hysteresis) for every alarm function. The audit trail SQL challenge test and the NTP disconnect test are included as written, executable steps.