Computer System Validation Protocol: The V-Model Paper Trail

At a glance

• A computer system validation (CSV) package is a connected chain of documents, not a single “protocol.” The chain follows the V-model: the left side specifies the system, the right side verifies it.
• The full deliverable set: Validation Plan, User Requirements Specification (URS), Functional and Design/Configuration Specifications, IQ/OQ/PQ protocols, a Requirements Traceability Matrix, a Validation Summary Report, and supporting SOPs.
• A Validation Plan governs the whole effort; a Validation Protocol is a specific test document (IQ, OQ, or PQ). They are different artifacts with different owners.
• The Requirements Traceability Matrix is the spine: it ties every requirement to the test that proves it, so nothing is unverified and nothing is tested for no reason.
• Right-size the set to risk. Regulators expect validation effort and documentation scaled to a justified, documented risk assessment, not maximal paperwork for every system.

If you have been told to “produce the validation documentation” for a GxP computerized system, you do not need another rehash of what IQ/OQ/PQ stand for. You need to know which documents make up the package, what each one contains, and how they connect. This guide walks the full V-model paper trail end to end, treating CSV as a document-control deliverable: the artifacts, their structure, and the traceability that binds them.

It stays on the document set. It does not argue why CSV matters (see the CSV hub), interpret the FDA’s CSA guidance (see the CSV/CSA guidance guide), or walk through executing test scripts (see the CSV testing guide). It also leaves Part 11 audit-trail and ALCOA mechanics to their own guides. Here, the deliverable set is the subject.

The CSV deliverable set at a glance (the V-model paper trail)

The V-model is the organizing idea: you specify the system going down the left arm (plan, then requirements, then functional and design detail), build it at the bottom, then verify going up the right arm (installation, then operational, then performance), with each verification document mapping back to the specification at the same level.

V-model level	Left side (specify)	Right side (verify)
Top	Validation Plan	Validation Summary Report
Requirements	User Requirements Specification (URS)	Performance Qualification (PQ)
Functional	Functional Specification	Operational Qualification (OQ)
Design	Design / Configuration Specification	Installation Qualification (IQ)
Spine	Requirements Traceability Matrix (ties left to right)
Throughout	Supporting SOPs

How the documents connect

The left side says what the system should do and be; the right side proves it does and is. A user requirement on the left is verified by a PQ test on the right; a functional spec by OQ; a design/installation detail by IQ. The Requirements Traceability Matrix is what makes the connection auditable, so a reviewer can follow any requirement to the evidence that it was met. Reviewers’ most common findings (missing acceptance criteria, untraceable requirements, unsigned deviations) are all failures of this connective tissue.

The Validation Plan vs. the Validation Protocol: what each owns

These two are routinely confused.

• The Validation Plan governs the whole validation effort for the system: its scope, the approach, the deliverables to be produced, roles and responsibilities, the risk-based rationale, and the acceptance criteria for declaring the system validated. It is the umbrella document.
• A Validation Protocol is a specific test document, an IQ, OQ, or PQ protocol, that defines and records a set of tests. There are several protocols under one plan.

In short: one plan, many protocols. The plan decides what will be done and to what rigor; each protocol executes a slice of it.

Specification deliverables: URS, Functional Spec, Design/Config Spec

The left arm, in increasing detail:

• User Requirements Specification (URS). What the users need the system to do, in business and regulatory terms. Every requirement here should be testable and traceable. This is the anchor of the whole package.
• Functional Specification. How the system will meet those requirements functionally, the features and behaviors. Verified later by OQ.
• Design / Configuration Specification. The technical design and the specific configuration of the system as deployed. Verified by IQ. For configured (rather than custom-built) systems, this often centers on configuration settings rather than code design.

The depth of these depends on the system: a configurable commercial product needs a configuration spec, not a full design spec for code you did not write.

The qualification protocols: IQ, OQ, PQ documents

The right arm. EU Annex 15, the EU qualification-and-validation standard, frames these as the qualification stages: Installation Qualification, Operational Qualification, and Performance Qualification (Annex 15, qualification stages). What each proves:

• IQ (Installation Qualification): the system is installed and configured correctly per the design/configuration specification.
• OQ (Operational Qualification): the system functions as specified, the functional spec is met, across its operating range.
• PQ (Performance Qualification): the system performs correctly in its actual intended use, meeting the user requirements in the real workflow.

Anatomy of a validation protocol

Whatever the stage, a protocol document has a recognizable structure, and reviewers check for each part:

• Purpose and scope: what this protocol verifies and the boundaries.
• Responsibilities: who executes, who reviews, who approves.
• References: the specification(s) this protocol verifies (the traceability hook).
• Acceptance criteria: the pass/fail standard, defined before testing. Missing acceptance criteria is a classic finding.
• Test cases: the steps, inputs, and expected results.
• Results / evidence fields: where actual results and objective evidence are recorded during execution.
• Deviation handling: how failures and unexpected results are documented and resolved (unsigned deviations are a common finding).
• Sign-off: dated approvals by the responsible parties.

This guide covers the document’s structure; how to execute and evidence the tests lives in the CSV testing guide.

The Requirements Traceability Matrix: tying requirements to tests

The Requirements Traceability Matrix (RTM) is the spine of the package. It is a table mapping each requirement (from the URS and specs) to the protocol and test case that verifies it, and to the result. Its job is twofold: prove that every requirement is tested (no gaps) and that every test traces to a requirement (no orphan testing). An auditor who wants to know “how do you know requirement 14 was met?” should find the answer in one row of the RTM. EU Annex 15 anchors the broader expectation that qualification and validation be planned and documented across the lifecycle, with a validation master plan or equivalent defining the programme (Annex 15, VMP); the RTM is how that documented programme stays coherent at the requirement level.

The Validation Summary Report and release

The Validation Summary Report closes the loop: it summarizes what was done, the results, any deviations and their resolution, and concludes whether the system met its acceptance criteria and is released for use. It is the right-side top of the V, mapping back to the Validation Plan. A clean summary report with unresolved deviations or unmet acceptance criteria is not a release; the report must honestly reflect the state and the disposition.

Supporting SOPs

Validation does not stand alone; it sits inside a quality system of standard operating procedures. EU Annex 15 notes that qualification and validation activities should be performed by trained personnel following approved procedures (Annex 15, organisation). A CSV SOP template typically defines:

• Purpose and scope of the CSV process.
• Roles and responsibilities (system owner, process owner, QA, IT).
• The validation lifecycle and which deliverables are produced when.
• Risk-based scoping rules (how rigor is determined).
• Change control and periodic review for validated systems.
• Deviation and CAPA handling.
• Records and retention.

The SOP is what makes validation repeatable across systems rather than a one-off.

Right-sizing the deliverable set to risk

You do not produce every document at maximal depth for every system. Both EU standards make validation effort proportionate: EU Annex 11 ties the extent of validation to a justified, documented risk assessment (§ 1), and EU Annex 15 states that the approach to qualification and validation should be based on a justified and documented risk assessment over the lifecycle (Annex 15, principles). Industry practice operationalizes this with the GAMP 5 software categories (from ISPE), which scale effort by software type and supplier-provided assurance: a standard, widely-used commercial product leveraging supplier qualification needs far less bespoke documentation than a custom-built system. The practical rule: scope the deliverable set to the system’s risk and category, document the rationale, and resist generating documents that add paperwork without adding assurance.

A reusable CSV deliverable + SOP template outline

Your takeaway checklist:

1. Validation Plan (scope, approach, deliverables, roles, risk rationale, acceptance criteria).
2. URS (testable, traceable requirements).
3. Functional Specification.
4. Design / Configuration Specification.
5. IQ protocol (installation/configuration verification).
6. OQ protocol (functional verification).
7. PQ protocol (intended-use verification).
8. Requirements Traceability Matrix (requirement → test → result).
9. Validation Summary Report (results, deviations, release decision).
10. Supporting SOPs (the CSV SOP outline above).

Scale each to risk and GAMP category; document why where you scale down.

A brief coordination note: assembling a validation package across several owners and deadlines is itself a project. A clinical project management tool can help a small team coordinate the deliverables and timelines; TrialTrack is one such tool, but it does not perform validation, ship these documents, or make anyone compliant (any Part 11 capability is TrialTrack’s own claim). The documents and their rigor remain the team’s work.

Frequently asked questions

What is a CSV protocol and how does it differ from a validation plan? A Validation Plan governs the whole validation effort (scope, approach, deliverables, acceptance criteria). A Validation Protocol is a specific test document (IQ, OQ, or PQ). One plan, many protocols.

What documents make up a CSV package? Validation Plan, URS, Functional Spec, Design/Configuration Spec, IQ/OQ/PQ protocols, Requirements Traceability Matrix, Validation Summary Report, and supporting SOPs.

What goes into an IQ, OQ, and PQ protocol? Purpose and scope, responsibilities, references to the spec verified, pre-defined acceptance criteria, test cases (steps, inputs, expected results), results/evidence fields, deviation handling, and dated sign-off. IQ verifies installation, OQ functionality, PQ intended-use performance.

What is a Requirements Traceability Matrix? A table mapping each requirement to the test that verifies it and the result, proving every requirement is tested and every test traces to a requirement.

How do you scope deliverables so you don’t over-document? By a justified, documented risk assessment and the system’s GAMP 5 category: scale rigor to risk and leverage supplier-provided assurance for standard products.

The bottom line

A CSV package is a connected V-model chain, not a lone protocol: a Validation Plan up top, specifications down the left, IQ/OQ/PQ verifications up the right, a Requirements Traceability Matrix as the spine, a Validation Summary Report to close it, and SOPs around it all. Know what each document contains and how they trace to each other, then right-size the whole set to a documented risk assessment so you validate the right things to the right depth, without drowning in paperwork that adds no assurance.

Sources

• EudraLex Volume 4, Annex 15: Qualification and Validation
• EudraLex Volume 4, Annex 11: Computerised Systems