IQ/OQ/UAT for Configurable Software

Executive summary

Many regulated organizations describe their validation programs as “heavy,” “slow,” and “expensive,” yet still feel uncertain during audits. That tension is not a paradox; it is a common outcome when validation becomes a performance rather than an evidence system. Teams generate large volumes of documents and test scripts, but the evidence does not cleanly connect to intended use, real operational risk, or the control surfaces that regulators actually care about. Under pressure—an audit, a deviation, a data integrity concern—validation work products do not reduce ambiguity; they sometimes increase it.

This white paper presents a practical, vendor-neutral approach to computer system validation (CSV) for configurable software, including software delivered as SaaS and software installed on-premise. The approach follows a simple rule: validate the control surfaces that prevent harm and protect record integrity, and avoid testing that exists primarily to “look thorough.” Guidance frameworks such as GAMP 5 remain useful, but only when applied with clarity around system category, supplier responsibilities, and risk-based scope.

The paper is structured around the IQ/OQ/UAT lifecycle—IQ, OQ, and UAT—while emphasizing the upstream work that determines whether those phases produce credible evidence: intended use definition, requirements discipline, risk assessment, and a traceability structure that ties tests to controls and controls to risk. Where electronic records and signatures are in scope, the same model supports defensible expectations aligned with 21 CFR Part 11 and Annex 11, implemented through control-surface testing rather than feature checklists.

The goal is practical: shorten time to validated use without weakening control. That is achieved by narrowing scope to what matters, strengthening supplier/customer boundary definitions, building test evidence that is reconstruction-resistant, and operating a change control cadence that keeps the validated state current.

Abstract

Computer system validation in regulated environments is often approached as documentation volume rather than evidence quality. This leads to slow projects that still leave uncertainty during audits and investigations. This paper proposes a practical, risk-based operating model for validating configurable software—delivered as SaaS or on-premise—using a small number of primitives: intended use, risk, control surfaces, and evidence packages tied by traceability.

The model organizes validation work around IQ/OQ/UAT while emphasizing supplier/site boundaries, control-surface testing (identity, access, audit trails, electronic signatures, data retention, exception handling), and change control practices that preserve the validated state over time. The approach is aligned with expectations commonly discussed under 21 CFR Part 11 and Annex 11 when electronic records are in scope, and uses risk-based CSV methods consistent with GAMP 5 principles.

1) What “validation” means (and what it is not)

Validation is frequently described as “proving the system works,” which is true but incomplete. In regulated operations, validation is the act of demonstrating that a computerized system is fit for its intended use and that its use does not undermine product quality, patient safety (where applicable), or record integrity. The practical outcome is not a binder; it is a defendable state of control that can be explained with evidence under audit.

Validation is not the same as testing every feature. It is also not the same as relying on vendor assurances. It is a structured argument supported by evidence, typically documented through artifacts such as a Validation Master Plan (VMP), a risk assessment, requirements, traceability, and test results. The most important property of those artifacts is that they connect: each test exists to demonstrate control over a risk tied to intended use.

When electronic records and signatures are relevant, expectations such as attributable actions and tamper-evident change history are often framed through 21 CFR Part 11. In European contexts similar expectations are frequently framed through Annex 11. In both cases, the operational test is the same: can the organization show that the record can be trusted without relying on narrative explanation?

2) Why validation becomes theater

Validation becomes “theater” when teams optimize for visible activity rather than audit-resilient evidence. This is not a moral failing; it is a predictable response to ambiguous expectations, fear of audit exposure, and the desire to avoid debates about scope. In practice, theater looks like large test inventories that do not map to risk, requirements documents that are generic, and traceability matrices that exist mainly to show completeness.

Common failure patterns are consistent across industries and deployment models:

• Scope inflation: “test everything” replaces a risk-based argument, creating long timelines without improving confidence.
• Feature-driven scripts: tests are organized around screens and menus rather than intended use and control objectives.
• Weak supplier/site boundaries: responsibilities are unclear, leading to duplicated testing or, worse, untested assumptions.
• Insufficient negative testing: programs verify “happy paths” but do not demonstrate that prohibited actions are prevented.
• Change control drift: the validated state is achieved once, then erodes through unmanaged configuration and releases.
• Integration blind spots: interfaces are treated as “IT plumbing” even though audits often find integrity issues at boundaries.
• Record trust gap: teams cannot clearly explain audit trail behavior, controlled edits, retention, or identity enforcement.

The remedy is not more documentation. The remedy is to structure validation as a small number of linked claims—intended use, risk, controls, evidence—and to concentrate effort on the surfaces where failures create real harm or regulatory exposure.

3) The validation model: intended use, risk, evidence

A validation program is strongest when it uses a simple argument structure that can be explained quickly under questioning. The model used here has four primitives that translate cleanly into daily work and validation artifacts: intended use, risk, control surface, and evidence package.

This model naturally supports risk-based CSV approaches. It also limits debates: instead of arguing whether “every screen” must be tested, teams focus on whether the control surfaces that protect intended use are demonstrably reliable, including during exceptions and change.

4) System boundaries: supplier vs site, configurable vs custom

Boundary confusion is one of the most common reasons validation efforts balloon. If responsibilities are not explicit, the default behavior is duplication: the site tests what the supplier already assures, and the supplier assumes the site will manage what it actually cannot control. A defensible validation program explicitly defines: (1) what the supplier provides as a controlled product, (2) what the site configures, (3) what the site operates procedurally, and (4) what is shared.

Configurable software changes the validation posture. Configuration typically means pre-built capabilities are enabled and constrained through settings, roles, and workflows, rather than created by new code. That generally reduces software complexity but can increase operational complexity if governance is weak. The validation question becomes: are configurations controlled, traceable, and tested as part of intended use?

Clarity here reduces validation time immediately. It also reduces audit vulnerability: when auditors ask “who controls this,” the organization can answer without ambiguity and can show evidence that those controls are operating.

5) Control surfaces that must be tested

Validation effort should concentrate on the controls that prevent harm and protect regulated record integrity. In practice, these are not “features”; they are system behaviors that enforce identity, status, authorization, and traceable change. Where electronic records are relied upon, these surfaces are often where expectations aligned to Part 11 and Annex 11 are operationalized, including secure, time-stamped audit histories and controlled e-signature meaning.

Notice what is absent: tests that simply confirm that a screen loads, or that a user can navigate a menu. Those may be useful during training, but they rarely strengthen a validation argument. Validation evidence should be strongest where failure creates real risk and where auditors focus when questioning record trust.

6) Requirements, traceability, and test design

Requirements quality determines validation quality. If requirements are generic, tests will be generic; if tests are generic, evidence will not withstand scrutiny. For configurable software, requirements should be written in a way that describes controlled behavior rather than “the system shall” statements that simply restate features.

A practical structure is to separate:

• Intended use statements: what regulated work is supported and what records are relied upon.
• Critical requirements: control-surface expectations (identity, access, audit trails, e-signature meaning, holds).
• Configuration requirements: site-specific workflows, roles, and rules (with versioning and approvals).
• Interface requirements: what data crosses boundaries, latency tolerance, error handling, and reconciliation.

Traceability is the glue. It should be maintained as a living structure that ties intended use → risk → requirement → test → evidence. When done well, it prevents both over-testing and under-testing: each test exists for a reason, and each critical requirement is demonstrably verified.

For configurable systems, configuration items should be treated as controlled objects. When a workflow, role, or rule changes, it should generate a controlled change record with impact assessment and appropriate re-testing. Without that discipline, the validated state becomes a point-in-time claim rather than a sustained operating posture.

7) IQ for modern deployments (SaaS and on-prem)

The purpose of IQ is to demonstrate that the system is installed (or provisioned) according to defined requirements and that the environment is suitable for intended use. In older on-premise models, IQ typically emphasized server specifications, OS settings, database versions, and installed components. In SaaS models, IQ often shifts toward documented supplier controls and site evidence for provisioning, identity management, and connectivity to the site environment.

A practical IQ approach for modern deployments focuses on what the site can actually verify and control. IQ evidence should be credible, not exhaustive. For SaaS, IQ commonly includes supplier documentation review and site verification of the customer-controlled elements: user provisioning, role setup, connectivity, endpoint configuration, time synchronization considerations, and any local components such as label printers, scanners, or scale interfaces (see weigh scale integration and label printer integration where applicable).

IQ should not attempt to prove the supplier’s internal infrastructure controls through site testing. Instead, the site should ensure it has reviewed supplier evidence appropriately (supplier qualification) and has verified customer-controlled configuration and dependencies. This boundary discipline reduces time and improves defensibility.

8) OQ: proving controls, not clicking features

OQ is where many validation programs accumulate volume without increasing confidence. The most effective OQ protocols are organized around control objectives and critical behaviors: who can do what, what is prevented, what is recorded, and how exceptions are handled. The emphasis should include negative testing: attempts to perform prohibited actions, attempts to edit protected fields, and attempts to bypass approval or hold logic.

Control-surface focused OQ typically covers:

• Role-based access: verify least-privilege roles and segregation rules where needed.
• Audit trail behavior: verify creation of an attributable audit history for protected record fields.
• Electronic signatures (where used): verify signature meaning, binding, and changes after signature.
• Hold/release and status logic: verify prohibited actions are blocked based on status.
• Exception capture: verify deviations/overrides are captured with reasons and approvals.
• Retention and export: verify retrieval of complete records and exports without loss of context.

A practical OQ is relatively compact but high signal. It demonstrates that the system prevents and records the behaviors that matter, including under adverse conditions. If OQ does not include negative and exception tests, it will rarely provide strong audit confidence.

9) UAT: proving the process works in real use

UAT is where operational truth meets the validation argument. A common weakness is to treat UAT as training. Training is important, but UAT is evidence: it demonstrates that real users can execute the intended process under realistic conditions while the control surfaces behave as expected.

High-quality UAT scenarios are end-to-end and include: normal flows, expected variability, and at least a small number of plausible exceptions. They should also demonstrate that the organization’s procedural controls align with system behavior. If the process relies on “off-system” workarounds to complete work, that is a signal that intended use is not being achieved as defined.

When UAT is structured this way, it becomes a high-value validation artifact: it shows that the system is not only technically correct but operationally fit, and that records produced during real work remain trustworthy.

10) Audit trails, data integrity, and record trust

Record trust is often the deciding factor during audit questioning. If an organization cannot clearly explain how records are protected against inappropriate change, or how changes are made transparently, the auditor’s attention escalates quickly. The practical anchor is data integrity, commonly expressed through principles such as ALCOA+.

In validation terms, this means demonstrating that records are attributable, contemporaneous, and preserved with a reliable change history. The audit trail is not simply “present”; its behavior must be understood and shown: which fields are audited, what triggers an audit entry, how reasons-for-change are captured, what approvals are required, and what is prevented (for example, deletion of regulated records, or edits without traceable reasons).

A defensible posture includes testing and procedural controls for:

• Protected field definition: which fields and events are considered regulated or critical.
• Reason-for-change rules: when a reason is mandatory and how it is reviewed.
• Signature meaning: how e-signatures bind to record state and how post-signature change is handled.
• Retention and retrieval: how long records persist and how complete context is preserved in exports.

These are not theoretical concerns. They are precisely where audits tend to focus when electronic records support release decisions, investigations, deviations, or customer-facing evidence.

11) Integration and interfaces: where audits find gaps

Integrations are often treated as technical projects, but audits treat them as evidence boundaries. When identity, status, and timestamps cross systems, small ambiguities become significant exposures. A typical example is conflicting status between systems (e.g., “released” in one system while effectively held elsewhere), or records that lose context during transfer.

A defensible integration validation posture includes:

• Interface contracts: clear definitions of fields, meanings, and event timing.
• Error handling: what happens when messages fail, arrive late, or arrive duplicated (see message broker architecture where applicable).
• Reconciliation: how source and target systems are compared and differences resolved (see master data synchronization).
• Auditability: traceable linkage between originating event and receiving record, including who/what/when.

Integration tests should concentrate on critical interfaces—those that affect identity, status, approvals, and the completeness of regulated records—rather than on “everything that can be integrated.” The purpose is to preserve one coherent truth across the process.

12) Validation health KPIs and operating cadence

Validation is not a one-time milestone; it is an operating posture. Programs deteriorate when change outpaces governance, when configuration is altered without impact assessment, or when evidence packages cannot be retrieved quickly. Metrics help detect drift early, before the organization is forced into reconstruction during an audit.

A simple cadence works well: monthly review of change control and audit trail signals, quarterly evidence retrieval drills, and periodic review of supplier releases and site configuration baselines. The purpose is to keep the validated state current, not to generate activity for its own sake.

13) Sector notes: what changes by industry

The validation model is stable across regulated sectors. What changes is the risk emphasis: which records are most critical, which process points create the highest consequence if controls fail, and what integration boundaries are most exposed. The table below offers a practical lens; it is not exhaustive.

Regardless of sector, a reliable program prioritizes the same fundamentals: record trust, prevention of prohibited actions, evidence retrieval, and sustained control through managed change.

14) Implementation roadmap

The fastest way to create a slow validation program is to start with a large test inventory. The faster way to create a defendable program is to start with intended use and risk, define control surfaces, then build compact, high-signal evidence packages. The roadmap below is designed to reduce cycle time without weakening control.

Closing note

A defensible validation posture is not defined by binder size. It is defined by whether the organization can demonstrate—quickly and consistently—that intended use is controlled, that critical risks are mitigated by system behaviors and procedures, and that electronic records can be trusted without narrative reconstruction. In practice, this is achieved by validating control surfaces, maintaining traceability, and operating disciplined change control that preserves the validated state over time.

Readers who want supporting definitions can reference the glossary pages linked throughout this paper, including CSV, GAMP 5, IQ, OQ, UAT, audit trail, and data integrity. These references are optional; the operating model described above is intentionally vendor-neutral.