How to Write an OQ Protocol From Scratch: A Step-by-Step Guide

You have been handed a new piece of equipment and told to write the OQ. Maybe it is a new filling line. Maybe it is a replacement sealer. Maybe it is a piece of lab equipment your QA team says needs qualification before you can run production. Either way, you are staring at a blank Word document trying to figure out where to start.

If you have read our guide on IQ vs OQ vs PQ, you already know that Operational Qualification proves the equipment operates correctly across its full specified range. But knowing what OQ is supposed to accomplish and knowing how to actually write one are two very different things.

This guide walks you through writing an OQ protocol from scratch, step by step, in the order you should actually do the work. No templates. No copy-paste from the last protocol someone wrote. The real process.

What is an OQ protocol?

An Operational Qualification (OQ) protocol is a documented set of tests that proves a piece of equipment operates correctly across its full specified operating range, including at worst-case boundary conditions. It is the second phase of equipment qualification, executed after Installation Qualification (IQ) and before Performance Qualification (PQ). OQ is the standard mechanism used to demonstrate equipment operation as part of process validation and production-control compliance under FDA 21 CFR 820.75 for medical devices, FDA 21 CFR 211 for pharmaceuticals, and the production controls referenced in ISO 13485:2016 Section 7.5.

An OQ protocol is not a template you fill in. It is a custom-written test plan specific to the equipment being qualified, built from the User Requirements Specification and Functional Specification, and approved per your site's quality procedure before any test is executed. A well-written OQ protocol is the difference between a validation package that survives an audit and one that gets flagged in a Form 483.

Step 1: Read the User Requirements Specification and Functional Specification

Before you write a single line of test, you need to understand what the equipment is supposed to do. This information lives in two documents that should already exist: the User Requirements Specification (URS) and the Functional Specification (FS).

The URS describes what the business needs the equipment to accomplish. It is written in plain language and focuses on outcomes. The FS describes how the equipment will meet those requirements. It is written in technical language and focuses on functions, parameters, and ranges.

If either document does not exist, stop and escalate. You cannot write a meaningful OQ without them. Writing an OQ against a machine you do not have documented requirements for is how you end up with a protocol that tests everything except the things that actually matter to your process.

Read both documents cover to cover. Highlight every functional requirement, every operating range, every alarm, every interlock, and every acceptance condition mentioned. These highlights become the skeleton of your OQ.

Step 2: Review the IQ Results

You cannot run OQ until IQ is complete and approved. But more importantly, you cannot write a good OQ without knowing what IQ already covered.

Pull the executed IQ protocol. Confirm it was signed off without open deviations. Note the software and firmware versions recorded during IQ, because any version change after IQ may require you to revisit the scope of your OQ. Note the calibration status of all built-in measurement instruments because you will rely on those instruments during OQ testing.

If IQ found deviations that were closed with justifications rather than fixes, read those justifications carefully. They often contain information that affects how you should design your OQ tests.

Step 3: Define the Scope and Boundaries

Before you write test steps, write a clear scope statement that answers three questions. What equipment is being qualified. What operating modes and functions are being tested. What is explicitly out of scope.

The out-of-scope section matters as much as the in-scope section. If the equipment has a function your process will never use, document that you are not qualifying it and explain why. Auditors do not expect you to qualify every button on a machine. They expect you to qualify everything your process depends on and to be explicit about the rest.

Scope boundaries also protect you later. If someone two years from now wants to use a feature you did not qualify, the scope statement makes it clear that a change control and supplemental qualification are required.

Step 4: Identify Critical Process Parameters

This is the step where most OQs go wrong. Engineers jump straight into writing test steps without first identifying which parameters actually matter.

A Critical Process Parameter (CPP) is any parameter whose variability has an impact on a Critical Quality Attribute (CQA) of the product. Temperature on a heat sealer. Pressure on a filler. Speed on a conveyor feeding a checkweigher. Dwell time on an autoclave.

Sit down with a process engineer or a subject matter expert and list every parameter the equipment controls. For each one, ask a simple question. If this parameter drifts outside its range, does it affect product quality or patient safety. If the answer is yes, it is a CPP and it needs to be tested in OQ. If the answer is no, document why and move on.

This is also where a well-run PFMEA pays off. PFMEA results can inform CPP selection, especially for high-severity failure modes and risks tied to CQAs. RPN alone is a weak basis for CPP selection because it does not separate severity from detectability or controls; use the underlying severity, occurrence, detectability, and existing control strategy together.

Step 5: Define the Operating Range for Each CPP

For every Critical Process Parameter, you need three values. The low limit of the operating range. The nominal setpoint used in production. The high limit of the operating range.

The low and high limits come from your justified operating range, derived from the User Requirements Specification, intended use, and risk assessment. The Functional Specification and the manufacturer's manual define what the equipment is capable of, but they do not automatically define your test challenge points. Test at the boundaries you intend to operate within, not at the equipment's design extremes unless your process actually approaches them.

If your justified operating range is 160 to 200 degrees Celsius around a 180 degree setpoint, your OQ must test at 160, 180, and 200. Not just 180. Testing only at the nominal setpoint is one of the most common findings in OQ audits, because the protocol fails to demonstrate behavior at the worst-case conditions the process can encounter.

If you are looking for an OQ protocol template to start from, understand that templates are useful for structural sections but the actual test steps and acceptance criteria must come from your equipment's URS and FS. Using a generic OQ protocol template without tailoring it is one of the most common causes of audit findings.

Step 6: Write the Test Steps

Now you can start writing tests. Every test step in an OQ should follow the same structure.

Test objective. One sentence explaining what this test is proving.

Test method. The specific procedure the tester will follow. This must be detailed enough that a different person could execute it and get the same result.

Test equipment and calibration. Any measurement instruments, data loggers, or reference standards needed, along with their calibration status.

Acceptance criteria. The predefined, measurable condition that must be true for the test to pass. OQ acceptance criteria must be written before the test is executed and must be specific enough that two independent reviewers would agree on whether the test passed.

Data recording. Space for the actual measured values, not just a pass/fail checkbox. If the test involves a range, record the reading at each point. If the test involves a duration, record the start time, end time, and elapsed time.

Deviation handling. A note that any result outside the acceptance criteria triggers a deviation and must be documented before the test can be closed.

Worked example: Sealer temperature hold (CPP)

To make this concrete, here is one OQ test step written in full for a heat sealer where seal temperature is the CPP. Justified operating range 165 to 195 degrees Celsius around a 180 degree setpoint. Hold time 4 seconds.

Test objective. Verify that the sealer maintains seal jaw temperature within plus or minus 2 degrees Celsius of setpoint across the justified operating range during a 4-second hold.

Test method. With the sealer in production mode and an empty seal cycle running, set the temperature controller to 165 degrees Celsius. Allow at least 10 minutes to stabilize. Initiate three consecutive 4-second seal cycles, recording jaw temperature continuously via calibrated surface-mount thermocouple data logger (SOP-CALIB-014, sampling 10 Hz) at the centre of the heated jaw. Repeat at 180 degrees and at 195 degrees.

Test equipment and calibration. Calibrated surface-mount thermocouple, asset CAL-T-022, current calibration certificate dated within 12 months. Calibrated stopwatch (or system event log) for cycle timing.

Acceptance criteria. At each setpoint (165, 180, 195 degrees Celsius), the recorded jaw temperature during the 4-second hold shall remain within plus or minus 2 degrees Celsius of the setpoint, across all three consecutive cycles. Per Functional Specification FS-0072 Rev. B, Section 4.1.

Data recording. Setpoint, actual recorded temperature trace (attached as raw data file), maximum deviation from setpoint, pass/fail status, performer initials, date and time.

Deviation handling. Any temperature excursion outside plus or minus 2 degrees Celsius during the hold triggers a deviation under SOP-VAL-005 before the test can be closed.

That single test step is what an auditor expects to see for every CPP across every challenge point. Multiply that by the number of CPPs and the number of test categories, and you start to see why writing a complete OQ from scratch is a multi-week effort.

Step 7: Write Tests for Alarms and Interlocks

Every alarm and every interlock on the equipment needs a test. This is not optional and it is one of the most common gaps in poorly written OQs.

For each alarm, the test must deliberately create the condition that should trigger the alarm, then verify three things. The alarm activates at the correct threshold. The alarm is displayed on the HMI with the correct text. The alarm is captured in the system event or audit log per the system's design (with full Part 11 audit-trail review where Part 11 applies).

For each interlock, the test must verify that the interlock prevents the unsafe state and provides the designed operator indication or fault response. Safety interlocks in particular need to be tested with a second person present as a safety witness.

Step 8: Write Tests for Recovery and Power Failure

If the equipment has any form of automatic recovery from fault conditions, test it. This includes power failure recovery, cycle interruption recovery, and communication loss recovery.

Simulate the failure condition, observe how the equipment responds, and verify that the recovery leaves the equipment and any in-process product in a known state. Undefined behavior after a power loss is one of the most dangerous gaps in equipment qualification because it only surfaces during real production disruptions, when the consequences are highest.

Step 9: Build the Traceability Matrix

Every test step in your OQ must trace back to at least one requirement in the URS or FS, and every critical requirement in the URS or FS must trace forward to at least one test step.

Build a traceability matrix as a table with three columns. The requirement identifier. The requirement description. The OQ test step that verifies it.

If a requirement has no corresponding test, you have a coverage gap. If a test step has no corresponding requirement, you have a scope creep. Both must be resolved before the protocol is approved.

As we covered in IQ vs OQ vs PQ, a protocol without a traceability matrix is not a qualification protocol. It is a collection of tests. The matrix is what turns individual tests into a defensible qualification package.

Step 10: Add Signature Blocks and Review the Protocol

Every OQ protocol needs signature blocks for protocol preparation, protocol review, protocol approval, test execution, and test review. Under 21 CFR Part 11, if signatures are electronic, the system capturing them must meet Part 11 requirements. If signatures are wet ink, the signatures must be dated and the paper records must be controlled.

Before you circulate the protocol for approval, read it end to end one more time. Ask yourself three questions. Could a person who has never seen this equipment execute this protocol correctly. Does every test have a clear pass/fail criterion that two reviewers would interpret the same way. Does the traceability matrix actually cover every critical requirement.

If any answer is no, keep working. A protocol that gets rejected in review is still cheaper than a protocol that gets flagged in an audit.

Common Mistakes That Kill OQ Protocols

Testing only at the nominal setpoint. We said it in Step 5 and we are saying it again. A common finding. Always test at low, nominal, and high challenge points within the justified operating range.

Vague acceptance criteria. "Equipment operates correctly" is not an acceptance criterion. "Temperature reaches 180 degrees Celsius within 3 minutes and remains within plus or minus 2 degrees for 10 minutes" is an acceptance criterion.

Untested alarms. Every alarm must be deliberately triggered. Assuming an alarm works because it existed during IQ is not qualification.

Missing traceability. A protocol without a traceability matrix is not a qualification protocol, it is a collection of tests.

Executing before the protocol is approved. Running tests against a draft protocol creates a protocol-control problem and may invalidate the affected execution records. Per site procedure, the approval signatures must be in place before any test is executed.

Copying from old protocols without rewriting. This is how acceptance criteria for equipment that no longer exists end up in protocols for equipment that does. Every line of an OQ should be written for the specific equipment being qualified.

As acceptance criteria, deviations, and traceability accumulate, the maintenance burden compounds. Every revision to a CPP, every added alarm, every change-controlled equipment update has to ripple through the protocol, the matrix, and the report consistently. That ripple is where most validation teams lose hours.

The Real Problem

Writing a good OQ protocol the right way takes a senior validation engineer significant time depending on equipment complexity. Most of that time is not engineering judgment. It is formatting tables, chasing down regulatory references, building traceability matrices by hand, and reformatting the same test step structure repeatedly.

The engineering judgment matters. The formatting does not. And the formatting is where your time goes.

That is the gap Valiqa was built to close. Generate the protocol structure, the test steps, the acceptance criteria, the traceability matrix, and the regulatory references, all formatted to your company's document standard. Then let the validation engineer do what they are actually trained to do. Review the output, apply engineering judgment, and sign their name on something they can defend in an audit.

Because the goal was never faster paperwork. The goal was more time for the engineering that actually matters.

---

Valiqa is an AI-powered validation lifecycle platform for regulated manufacturing. Learn more at valiqa.io

Writing one OQ from scratch is a learning experience. Writing twenty is a tooling decision. If you are past the first protocol and thinking about software, see our guide to choosing validation software for equipment qualification.

Wondering how long this all takes in practice? See our breakdown of how long it takes to write an OQ protocol, broken down by phase.

Deciding between writing protocols by hand and moving to a tool? Take the self-scoring evaluation for a quick read on which category of validation software fits your team.