Computerized System Validation Summary Report

This is a ready-to-use computerized system validation summary report (CSV VSR). Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, attach your executed protocols and deviation records, and route it through your normal document control, review, and approval. A worked filled specimen follows the template so you can see how a completed version reads. Verify each cited regulation against the current source before you rely on it.

A CSV VSR is the closing record for a single computerized system. It does not repeat the testing; it summarizes what the validation plan called for, what was executed, the results against pre-approved acceptance criteria, every deviation and how it was resolved, the requirements-to-test traceability, and the two statements an inspector looks for in a software validation that the generic equipment report does not always carry: an explicit Part 11 and Annex 11 electronic records and signatures compliance statement, and the periodic review interval that keeps the validated state alive after go-live. An inspector reads this report first to decide whether to trust the system, then follows the trail you cite into the protocols and the traceability matrix. Write it so every claim points to evidence.

Document control header

1. Purpose

This report summarizes the validation of <<FILL: system name>> performed under validation plan <<FILL: plan number>> and concludes on its validated state and fitness for intended use. It records the deliverables executed, the results against approved acceptance criteria, all deviations and their resolution, confirmation of requirements-to-test traceability, the system’s compliance with 21 CFR Part 11 and EU GMP Annex 11, the residual risk accepted, the release statement that authorizes GxP use, and the interval at which the system will be periodically reviewed.

2. System description, scope, and intended use

State the boundary the conclusion covers, in the same terms the plan used. A report that claims more than the plan tested is not defensible.

3. References

The governing plan, specifications, supplier assessment, and risk assessment that defined this effort.

4. Summary of deliverables executed

List every planned deliverable and its real status. The planned-versus-executed comparison is the heart of the report: any deliverable in the plan that was not executed, and any activity not in the plan, is explained here, not buried. For a SaaS or supplier-supplied effort, name what supplier evidence you accepted and the assessment that justified accepting it.

State any plan deviation: <<FILL: any planned deliverable not executed, with rationale and approval, or "All planned deliverables were executed as planned.">>

5. Results against acceptance criteria

Summarize execution. Counts must reconcile: executed equals passed first run plus failed or repeated, and every failed or repeated test traces to a deviation in section 6. Do not report a pass percentage that hides an unresolved failure. The test rigor should match the risk-based, critical-thinking approach in the FDA Computer Software Assurance guidance: deep, scripted testing for high-risk GxP functions, lighter unscripted or supplier-supplied evidence for low-risk function.

Narrative: <<FILL: state plainly whether every acceptance criterion in the protocols was met after resolution, and call out any criterion met only by an approved change to a test step or an acceptance limit.>>

6. Deviations and their resolution

Every deviation, test failure, and protocol departure raised during execution is listed here with its resolution and its impact on the conclusion. An open deviation that affects intended use blocks the release statement; an open deviation that does not must be justified and routed to an action with an owner and a due date.

Open items at release: <<FILL: list any deviation or action open at the time of release, the interim control in place, the owner, and the due date, OR "No deviations are open at the time of release.">>

7. Traceability confirmation

Confirm that the requirements-to-test trail is complete and bidirectional: every GxP requirement traces forward to at least one executed test that passed, and every executed test traces back to a requirement and to its assessed risk. This is the single statement an inspector checks to know that nothing in scope went untested.

Confirmation: <<FILL: e.g. "Traceability matrix CSV-VTM-IT-031 confirms full bidirectional coverage of all 53 in-scope requirements, including 11 Part 11 / Annex 11 control requirements; no gaps." OR describe any accepted gap and its justification.>>

8. Part 11 and Annex 11 compliance statement

This is the section a CSV report carries that a plain equipment report often does not. Confirm, control by control, that the system meets the electronic records and electronic signatures expectations, with the test or evidence that proves each one. Mark a control N/A only with a stated reason (for example, the system uses no electronic signatures). This table is the evidence that supports the single compliance sentence below it.

Compliance statement: <<FILL: e.g. "The system meets the applicable requirements of 21 CFR Part 11 and EU GMP Annex 11 for the intended use. All controls above are implemented and verified, except [list any N/A with reason]. The system is suitable to create and retain GxP electronic records [and apply electronic signatures].">>

9. Residual risk

State the risk that remains after validation, drawn from the risk assessment and from any deviation resolved by a control rather than a fix. A report that claims zero residual risk is rarely believed; name what remains, the control that holds it, and who owns the control.

Overall residual risk statement: <<FILL: e.g. "Residual risk is reduced to acceptable by the controls above and is acceptable for the intended use." Quality Assurance confirms acceptance.>>

10. Procedures, training, and ongoing controls

A computerized system is not validated for use until the people, procedures, and operational safeguards around it are ready. Confirm the controls that hold the validated state after release.

11. Conclusion, release for use, and periodic review interval

State the conclusion in one defensible sentence, qualify it, release the system, and set the date the validated state will be re-confirmed. The conclusion must be supported by every section above; do not conclude “validated” if a section 6 deviation, a section 7 gap, or a section 8 control is unresolved for the intended use.

Conclusion on validated state: <<FILL: e.g. "Based on the deliverables executed, the results against acceptance criteria, the resolution of all deviations, confirmed traceability, and verified Part 11 / Annex 11 controls, [system] version [build] is validated and fit for its intended use within the scope of section 2.">>

Conditions or limitations: <<FILL: any function not validated, any environment not covered, any condition under which revalidation is required, OR "No limitations beyond the stated scope.">>

Release statement. The release statement authorizes GxP use. It is dated and signed by the role that owns the disposition, normally Quality Assurance, and it is the line an inspector reads to confirm the system was approved before data was generated under it.

Periodic review interval. Set the interval by the system’s GxP impact and risk; a common range is one to three years, with the highest-impact systems reviewed most often. Record the basis so the interval is defensible, not arbitrary.

12. Approvals

13. References (standards and regulations)

21 CFR Part 11 (electronic records and electronic signatures). EU GMP Annex 11 (Computerised Systems) and Annex 15 (Qualification and Validation), 2015 revision. 21 CFR 211.68 (automatic, mechanical, and electronic equipment), for drug GMP systems. FDA Computer Software Assurance for Production and Quality Management System Software, final guidance issued 3 February 2026 (superseding the 24 September 2025 version). GAMP 5 (A Risk-Based Approach to Compliant GxP Computerized Systems), second edition, for the lifecycle and software categories. ICH Q9 (Quality Risk Management), for the risk basis of test depth and residual-risk acceptance. 21 CFR Part 820 (QMSR), effective 2 February 2026, which incorporates ISO 13485:2016 by reference, for medical-device software and process validation. PIC/S PI 011 (Good Practices for Computerised Systems in Regulated GxP Environments). MHRA GxP Data Integrity Guidance and Definitions, for the data integrity expectations behind the audit trail and access controls.

Confirm the current version and clause numbers of each reference before issue.

14. Attachments

15. Revision history

Filled specimen

The following shows the core sections completed for an example chromatography data system (a GAMP 5 category 4 configured product) used for drug release testing, so you can see the level of detail an inspector expects. The company, system, and numbers are illustrative; replace them with your own.

Header and scope. CSV-VSR-LAB-024 v1.0, closing validation plan CSV-VP-LAB-024, for a chromatography data system (CDS), version 8.3.2, GAMP 5 category 4 (configured), predicate rule 21 CFR 211. Intended use: instrument control, acquisition, integration, result calculation, electronic review and approval of analytical results for drug substance and drug product release. Hosting: on-premise, on a qualified server. Interfaces in scope: bidirectional interface to the LIMS for result transfer. Out of scope: the long-term archive storage appliance, validated separately under CSV-VSR-IT-009. Configuration baseline: config ID CDS-CFG-024-r3.

Deliverables executed.

Results against acceptance criteria.

All acceptance criteria were met after resolution. Counts reconcile: 158 executed, 153 passed first run, 5 repeated and passed on retest, all 5 traced to the 3 deviations below.

Deviations and resolution.

Traceability. CSV-VTM-LAB-024 confirms full bidirectional coverage of all 53 in-scope URS requirements, including all 11 Part 11 and Annex 11 control requirements. Every high-risk function (audit trail, electronic signature, re-integration, result calculation, LIMS transfer) has at least one passed test. No requirement untested, no test orphaned.

Part 11 and Annex 11 compliance. All 11 controls implemented and verified under P11-LAB-024: audit trail captures who, what, old and new value, when, and reason for re-integrations and result changes and cannot be disabled by analysts; unique user IDs with role-based privileges and no shared accounts; electronic signatures carry name, date, time, and meaning and are linked to the result; records are retrievable and human-readable for the 15-year retention period; server time is synchronized to the site time source. Statement: the system meets the applicable requirements of 21 CFR Part 11 and EU GMP Annex 11 for the intended use, with no control marked N/A.

Residual risk.

Conclusion, release, and periodic review. Based on the deliverables executed, the results against acceptance criteria, the resolution of all 3 deviations, confirmed traceability, and verified Part 11 and Annex 11 controls, the CDS version 8.3.2 is validated and fit for its intended use within the scope of section 2. Released for GxP use as of 18 June 2026, configuration baseline CDS-CFG-024-r3, with the one interim control above and change CC-2026-0501 raised for the interface patch. Authorized by R. Gomez, QA, signed 18 June 2026. Periodic review interval: every 2 years (high GxP impact, moderate change frequency); next review due 18 June 2028, under SOP-QA-031.

In this example the report did not hide the five OQ and UAT failures; it reconciled the counts, tied each repeat to a closed deviation, proved each Part 11 control with a named test rather than a claim, carried the one item fixed by a control rather than a patch into residual risk with an owner and a change record, and only then released the system and set the review clock. That sequence, executed-versus-planned to results to deviations to traceability to a Part 11 statement to residual risk to a conditioned release with a periodic review date, is exactly what an inspector expects a CSV summary report to demonstrate.

Common inspection findings this report prevents

• The report concludes “validated” while deviations or test failures remain open with no impact assessment.
• Test counts do not reconcile: more tests passed than were executed, or failures appear in the protocols but not in the report.
• No explicit Part 11 or Annex 11 statement, so it cannot be shown the audit trail, access controls, and electronic signatures were actually verified.
• A Part 11 control claimed as met with no test or evidence behind it, or controls marked N/A with no reason.
• A requirement in scope has no linked test, or a test has no requirement, and the gap is not acknowledged.
• The conclusion claims more than the plan tested, covering modules, interfaces, or a software version that was never qualified.
• No dated release statement signed by Quality Assurance, so it cannot be shown the system was approved before GxP data was generated under it.
• No periodic review interval set, so the validated state is never re-confirmed and quietly decays as the system is patched and reconfigured.
• Residual risk declared as zero, with no mention of the controls that resolved deviations instead of fixes.
• The configuration or software version released is not recorded, so there is no baseline to detect later drift.

How to adapt this report

1. Set your document number, owner, linked plan number, and effective date in the header, and record the exact software version and configuration baseline in section 2.
2. Match section 2 scope to your plan word for word; if the plan changed, reconcile it here and reference the change.
3. Fill the section 4 deliverable list with your real document numbers and flag any planned deliverable not executed. For a SaaS or supplier-supplied system, name the supplier assessment and the evidence you accepted.
4. Reconcile the section 5 counts against the executed protocols before you sign; executed must equal passed first run plus repeated, and every repeat must trace to a section 6 deviation.
5. Complete the section 8 table control by control; mark a control N/A only with a stated reason, and make sure each non-N/A control names a real test ID or evidence record.
6. Carry any deviation resolved by a control, not a fix, into section 9 residual risk with an owner and a change-control reference.
7. Set the section 11 periodic review interval from the system’s GxP impact and risk, record the basis, and put the next-due date in the inventory so it is not forgotten.
8. For a medical-device system keep the QMSR reference; for a non-GMP regulated use, swap the predicate rule in section 2 and the references in section 13 to match.
9. Confirm every regulation in section 13 against the current published version before issue.