Skip to main content

Validation Protocol Management Software: Workflow and Checklist

written by
Sundar
Director, GoVal
Published on
Last updated on
Reading time: 5 min read

Ready to modernize?

See GoVal in Action

Book a 30-minute walkthrough with our validation specialists. No slides — just your questions, answered live.

Contact Us
Summary

Protocol software should preserve more than signed IQ/OQ/PQ documents. This guide walks through an illustrative LIMS OQ test, the evidence to retain and six checks for a product demonstration. It separates example workflow labels from regulatory requirements.

What does validation protocol management software need to prove?

That the approved test instructions, actual execution, exceptions, evidence and final review can be followed as one controlled record. A polished protocol template is only the starting point.

A protocol is easy to find when everything passes. The harder question comes six months later: which version was approved, what did the tester observe, and how was a failed step resolved?

The protocol workflow to look for

For IQ, OQ or PQ work, software should help the team control the full record rather than just store a signed document. A practical workflow is: draft the test, link its requirement and risk, approve it before execution, capture actual results, record exceptions, review the evidence and close the protocol. Each handoff should leave an attributable record.

Illustrative protocol flow

Draft → Approved → In execution → Review → Closed. A failed step opens a linked deviation and may require a justified retest before closure. These are example stages, not a prescribed regulatory workflow or universal software status names.

Worked example: One OQ test for a LIMS approval rule

Consider a fictional laboratory information management system (LIMS). The requirement is that only authorized QC reviewers may approve a result, and an analyst must not alter it after approval. The following illustrates a test design, not an executed or approved protocol.

OQ-LIMS-07: Approved result is protected

Requirement: URS-LIMS-014   Test state: Not executed (illustration)

Preconditions: Test sample T-042 exists; Analyst and QC Reviewer accounts are configured; the approved test environment and audit-trail controls are available.

  1. Analyst enters a result. Expected: T-042 retains the entered value and becomes available for review. Evidence: test result view.
  2. QC Reviewer approves T-042. Expected: status changes to Approved; reviewer identity and approval time are retrievable. Evidence: approval record.
  3. Analyst attempts to edit the approved value. Expected: the change is denied; the approved value and status remain unchanged. Evidence: rejected action and before/after record.

Pass criterion: All three expected behaviors are demonstrated. If the edit succeeds, record a failure and link a deviation; do not overwrite the initial result with a retest.

What a complete execution record looks like

For this example, the reviewer should be able to retrieve the approved test version, requirement ID, tester and execution time, actual observations, evidence references, any deviation, the decision to retest and the final approval. The evidence should explain the conclusion without relying on a tester’s memory.

A useful spot-check: Start with deviation DEV-OQ-03, if one exists. Can you find the failed OQ-LIMS-07 step, original result, investigation, retest record and approval without asking someone to reconcile several spreadsheets?

Six questions for a protocol software demo

  • Version control: Which approved protocol was executed, and can we retrieve the earlier version?
  • Traceability: Can we open the source URS and risk decision from one test step?
  • Evidence: Are actual observations and attachments linked to the specific step?
  • Failures: What happens when a tester records Fail rather than Pass?
  • Changes: How is a correction handled after execution begins, without erasing earlier evidence?
  • Reporting: Can reviewers export a readable record of testing, deviations and approvals?

Reusable templates help with consistency, but a template for one LIMS configuration should not be copied unchanged into another. Scope and expected results need to follow the intended use and assessed risks. EU GMP Annex 11, sections 4.4 and 4.7, addresses traceable requirements and appropriate test scenarios, including limits and error handling; it does not prescribe a particular protocol-management product.

Where GoVal fits

GoVal describes support for requirements, risk assessment, paperless IQ/OQ/PQ execution, deviations, approvals and traceability. Ask to see the LIMS scenario above in a GoVal workflow demonstration, including what happens to the original evidence when a step fails.

Related Topics

IQ, OQ and PQ Validation Requirements Traceability Matrix Validation Deviation Management How to Choose Validation Software

Frequently Asked Questions

What should validation protocol management software track besides the protocol PDF?
It should make the approved version, assigned executor, actual results, supporting evidence, deviations, review decisions and final disposition easy to retrieve. The exact workflow may differ by organization. Ask vendors to demonstrate how an auditor follows one test from requirement to approved evidence.
Can an IQ, OQ or PQ protocol be changed after testing begins?
A correction can be managed through the organization’s approved change or deviation procedure. The important controls are preserving the original approved version, recording why the change was needed, assessing impact on executed steps and approving the revised approach before affected testing continues.
What evidence should be retained for a failed OQ test?
Retain the expected result, the observed result, the test configuration, relevant screenshots or system records, the deviation reference, the investigation and the retest decision. Do not replace the original failed execution with a later passing result.
Can protocol templates be reused across GxP systems?
Yes, as a starting structure. Review each system’s intended use, configuration, requirements and failure risks before adopting the test steps and acceptance criteria. A reusable template reduces formatting work; it does not replace system-specific test justification.

See how protocol execution is managed in GoVal

Ask for a walkthrough of requirements, test evidence, deviations and approvals.

Book a Free Demo