Written and maintained by CASRAI Editorial Board
Last updated
A validation summary report (VSR) is the document that closes out a computer-system or equipment qualification exercise. It is the last document in the sequence — policy, validation master plan, validation plan, protocol, summary report — and it is the one document a reviewer or inspector will read first, because it is where the whole exercise is supposed to be legible in one place: what was tested, what happened, what was deviated from and why, what is not yet resolved, and whether the system is being released for regulated use as a result.
This page covers what a VSR needs to contain to actually close a validation, not just describe it: deviation disposition, how unresolved items get carried forward defensibly, traceability closure back to the user requirements specification (URS), and the release statement itself. For the document hierarchy the VSR sits at the bottom of, see Validation Master Plan (VMP) for a Regulated Laboratory. For the URS the VSR ultimately has to trace back to, see User Requirements Specification (URS) for GxP Systems. For the full IQ/OQ/PQ lifecycle a VSR summarizes, see Computer System Validation (CSV): GAMP 5, IQ/OQ/PQ, and 21 CFR Part 11. This page deliberately doesn’t repeat any of those — it’s about the one closing document, in depth.
What a VSR Is, and What It Is Not
EU GMP Annex 15 (Qualification and Validation) names the summary report as the last item in the document hierarchy it lays out: policy → validation master plan → validation plan → protocol (IQ/OQ/PQ, URS, traceability matrix) → summary report. Where the protocol is the plan and the raw execution record — the specific tests run, the specific data captured — the summary report is the synthesis: results against acceptance criteria, deviations, and the release decision, in a form a Quality reviewer or inspector can assess without re-executing the underlying protocol.
A VSR is not a second protocol and it is not a narrative retelling of every test step. Padding it with re-stated raw data the protocol already captured is a common failure mode — it makes the report longer without making it more defensible, and it buries the three things a reviewer actually needs: what didn’t go as planned, what was done about it, and whether that leaves the system fit for its intended, regulated use.
It is also distinct from a periodic review. A VSR closes a single qualification exercise at a point in time; periodic evaluation (Annex 11, §11) is the recurring check, at a justified interval, that a system already qualified is still in a valid state — current functionality, deviation history since qualification, incidents, upgrade history, performance, reliability, security, and validation status are all inputs to that later, separate review. A VSR that reads like an attempt to also do periodic-review work is scoped wrong.
What a Complete VSR Must Contain
There’s no single universally mandated VSR template — Annex 15 describes what the document has to accomplish, not a fixed section list — but a defensible VSR consistently covers the same ground:
| Element | What it establishes |
|---|---|
| System / scope identification | Exactly what was qualified — system name, version, unique identifier, site, and the specific protocol(s) this report closes out. Ties the report unambiguously to one entry in the system inventory Annex 11 §4.3 requires. |
| Protocol and criteria summary | Which protocol(s) were executed, over what date range, against which pre-approved acceptance criteria — a pointer back to the protocol, not a restatement of it. |
| Results against criteria | A pass/fail statement for each acceptance criterion, or a clear reference to where that evidence lives if the raw data set is large. This is the section a reviewer scans first. |
| Deviation summary and disposition | Every deviation raised during execution, how each was classified, investigated, and closed — see below. |
| Unresolved items | Anything not fully closed at the time of reporting, with a documented risk justification for proceeding anyway — see below. |
| Traceability confirmation | Explicit confirmation that every URS requirement traces to an executed test, and every executed test traces back to a URS requirement — see below. |
| Conclusion and release statement | The actual determination: validated / validated with restrictions / not validated, and what that means operationally — see below. |
| Approvals | Named sign-off, with role, from the parties Annex 15 expects to have exercised quality oversight over the exercise — not just the person who ran the tests. |
Deviation Disposition: Closing Out What Didn’t Go to Plan
Annex 15 treats two different situations as a deviation, and a VSR needs to distinguish them rather than lump every deviation into one undifferentiated list:
- A failed acceptance criterion (§2.8). A test was executed as written and the result didn’t meet the pre-defined criterion. Annex 15 requires this to be fully investigated — not just logged and moved past. The VSR’s disposition for each one needs to state the investigated root cause (or explain why a root cause couldn’t be conclusively determined), the corrective action taken, and the re-test or verification evidence that closes it.
- A significant change to the protocol itself during execution (§2.7). If the test method, or the acceptance criterion, had to change mid-execution, that’s a deviation from the approved protocol requiring documented, scientific justification for the change — distinct from a failed criterion, because the criterion the system is ultimately judged against has itself moved.
For each deviation, a defensible VSR entry gives: a description specific enough to identify exactly which test step and criterion it relates to, its classification (typically by severity/impact — critical deviations affecting product quality or data integrity get different handling than minor procedural ones), the investigation outcome, the corrective action, and the closure evidence. “Deviation noted, retested, passed” without the investigated cause is a common finding — it documents that something happened, not why it’s now acceptable to conclude it won’t happen again.
Unresolved Items: Annex 15’s Conditional-Approval Path
Not every deviation is closed by the time a report is due. Annex 15 §2.10 explicitly allows conditional approval to proceed — including, by extension, conditional release at the summary-report stage — provided there is a documented assessment that the open item has no significant impact on the aspect being qualified. This is a real, permitted path, not a workaround: a VSR can legitimately state “validated, with the following item still open” as long as that assessment exists in writing.
What that assessment needs to contain, for each unresolved item, to actually hold up:
- What specifically remains open, and why it wasn’t closed before the report was issued (a pending vendor fix, a low-frequency edge case still under investigation, a scheduling constraint).
- The documented rationale for why it does not significantly impact the qualification status being reported — tied to the specific aspect of the system it touches, not a general assurance.
- An owner and a target closure date. An unresolved item with no owner and no date reads, to an inspector, as an item that was quietly dropped rather than genuinely tracked.
- Where the item is being tracked going forward (a CAPA record, a deviation-management system, a specific follow-up action) — the VSR references it, it doesn’t have to resolve it.
A VSR that lists unresolved items without this reasoning attached isn’t using the conditional-approval path correctly — it’s just an incomplete report with a release statement bolted on regardless.
Traceability Closure Back to the URS
Annex 11 §4.4 requires user requirements to be traceable throughout the system lifecycle. In practice that traceability is built as a matrix during protocol design — each URS requirement mapped to the specific OQ/PQ test step that verifies it — and the VSR’s job is to state explicitly that the matrix is complete: every requirement in the URS traces to at least one executed test, and every executed test traces back to a requirement that justified running it.
Two gaps show up here more often than any other traceability failure, and both are worth checking explicitly before writing the closure statement:
- Untested requirements. A URS requirement with no corresponding test anywhere in the protocol — often because it was added late, or because it was assumed to be “obviously” covered by a broader test that doesn’t actually verify it specifically.
- Untraceable tests. A test that was executed but doesn’t map to any URS requirement — sometimes a genuinely useful check the team added on its own judgment, but if it isn’t tied to a requirement, its result doesn’t belong in the requirements-traceability closure statement; note it separately as supplementary testing instead.
If either gap exists at report time, the VSR cannot state the traceability chain is complete — that becomes either an unresolved item handled per the conditional-approval path above, or a reason the report has to wait until the gap is closed.
The Release Statement
The release statement is the sentence the rest of the document exists to support: a specific, unambiguous determination of the system’s qualification status, not a general summary of how the exercise went. It needs to state one of a small number of real outcomes, plainly:
- Validated / qualified for intended use — every acceptance criterion was met (or deviations were investigated and closed), traceability is complete, and no unresolved items remain.
- Validated / qualified with documented restrictions — the system is released, but for a defined, narrower scope than originally planned (a specific module excluded, a specific use case not yet supported) because of an unresolved item assessed under §2.10.
- Not validated — one or more acceptance criteria were not met and the deviation was not resolved to a state that supports release; the system cannot be relied on for regulated use until further work closes the gap and a follow-up report is issued.
The statement should name the system/version being released, the effective date, and reference the protocol(s) it closes. Vague language (“the validation was generally successful”) is exactly what an inspector reads as a report avoiding a real conclusion.
Approval sits with the roles Annex 15 §1.3 expects to have exercised quality oversight over the whole validation lifecycle — that clause is explicit that validation personnel need not report organizationally to Quality, but quality oversight over the exercise as a whole is still required. In practice this means the VSR’s sign-off block typically includes the system/process owner and a Quality representative, not the tester alone — the same distributed-ownership pattern Annex 11 §2 sets up between Process Owner, System Owner, and IT.
Frequently Asked Questions
Is a validation summary report the same thing as a validation report?
In practice the terms are used interchangeably by most labs and vendors. Annex 15’s own document-hierarchy language uses “summary report / validation summary” for this exact document — the closing report against a protocol’s results, deviations, and release decision. If a program distinguishes the two internally, confirm which one a specific SOP means before assuming the terms are synonymous in that context.
Who is allowed to sign a VSR?
Annex 15 doesn’t name specific job titles, but §1.3 requires quality oversight over the validation lifecycle as a whole. The typical pattern is sign-off from the system or process owner (operational responsibility for the system) plus a Quality representative (oversight that the exercise met the programme’s requirements) — a report signed only by the person who executed the tests generally doesn’t satisfy that oversight expectation.
Can a VSR be issued with open deviations?
Yes, under Annex 15 §2.10’s conditional-approval path, provided each open item carries a documented assessment that it has no significant impact on the aspect of the system being qualified, along with an owner and target closure date. An open deviation with no such assessment is not a resolved conditional release — it’s an incomplete report.
Does a VSR replace the need for a periodic review later?
No. A VSR closes one qualification exercise at the point it was executed. Annex 11 §11 separately requires periodic evaluation of systems already in use, to confirm they remain in a valid state — a distinct, recurring review that looks at deviation history, incidents, upgrades, and performance since qualification, not a one-time report.
What happens if traceability from the URS isn’t fully closed at report time?
An incomplete requirements-to-test traceability matrix means the report can’t state the chain is complete. Depending on severity, that’s handled either as an unresolved item under the conditional-approval path (with the documented no-significant-impact rationale) or as a reason to hold the report until the specific gap is closed with additional testing.
