# Computerised System Validation Plan: [System name]

> Validation plan and record set for a computerised system used in a
> GxP-regulated activity (good manufacturing, laboratory, clinical or
> distribution practice) in the pharmaceutical, biotech or medical
> device industry. It follows a risk-based, critical-thinking approach
> in the spirit of computer software assurance (CSA), and maps to EU GMP
> Annex 11 (Computerised Systems, revision of January 2011, in force;
> a revised draft was consulted on from July to October 2025), US
> 21 CFR Part 11 (electronic records and electronic signatures), the
> FDA final guidance on Computer Software Assurance for Production and
> Quality Management System Software (February 2026), and the structure
> of ISPE GAMP 5 Second Edition (July 2022), which is cited by name and
> section only. Replace every `[bracketed]` value and every row marked
> *Example*. This is a documentation format, not regulatory or legal
> advice: follow your quality system, check the current official texts
> and consult qualified quality and regulatory professionals.

<!--
Guidance: How to use this template
- Write one plan per system, or one per platform with a section per
  configured module. Small, low-risk systems can use a short version:
  keep sections 1, 3, 4, 7, 9 and 12 and state why the rest is omitted.
- Fill the intended use (section 1) and the GxP and risk assessment
  (sections 3 and 4) first. They decide how much assurance work every
  later section needs; effort follows risk to patient safety, product
  quality and data integrity.
- Use evidence that already exists (supplier testing, automated test
  logs, configuration exports) instead of re-creating it in documents.
  Record why the evidence is sufficient.
- Related documents: CAPA and nonconformity (`compliance/capa-nonconformity`),
  Change control (`project/change-control`), Supplier security
  assessment (`compliance/supplier-security-assessment`), Traceability
  matrix (`requirements/traceability-matrix`), UAT plan
  (`quality/uat-plan`), Medical device software lifecycle
  (`compliance/medical-device-software-lifecycle`), Method validation
  (`compliance/iso-17025-method-validation`).
-->

## Document control

<!-- Guidance: The plan is a controlled GxP record. Use your document management system's numbering and signature process; the fields below are the minimum. -->

| Field | Value |
|---|---|
| Document ID | [CSV-PLAN-001] |
| System name and version | [*Example:* Laboratory information management system, release 8.2] |
| System owner | [@system-owner] |
| Process owner | [@process-owner] |
| Quality assurance | [@qa-reviewer] |
| GxP area | [GMP / GLP / GCP / GDP / Medical device QMS] |
| Sites | [Sites using the system] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Approvers/reviewers | [@system-owner], [@process-owner], [@qa-reviewer], [@it-service-owner] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |

### Approvals

| Role | Name | Signature meaning | Date |
|---|---|---|---|
| Process owner | [@name] | Approves intended use and acceptance | YYYY-MM-DD |
| System owner | [@name] | Approves technical approach | YYYY-MM-DD |
| Quality assurance | [@name] | Approves compliance with the quality system | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Risk assessment updated after supplier audit |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved for execution |

## Contents

<!-- Guidance: Keep this list aligned with the headings below. -->

1. [Intended use and system description](#1-intended-use-and-system-description)
2. [Regulatory basis](#2-regulatory-basis)
3. [GxP assessment and system categorisation](#3-gxp-assessment-and-system-categorisation)
4. [Risk assessment](#4-risk-assessment)
5. [Supplier assessment](#5-supplier-assessment)
6. [Requirements](#6-requirements)
7. [Assurance approach and testing](#7-assurance-approach-and-testing)
8. [Data integrity controls](#8-data-integrity-controls)
9. [Electronic records and signatures controls](#9-electronic-records-and-signatures-controls)
10. [Traceability matrix](#10-traceability-matrix)
11. [Release and validation report](#11-release-and-validation-report)
12. [Operational phase](#12-operational-phase)
13. [Roles and responsibilities](#13-roles-and-responsibilities)
14. [Glossary and references](#14-glossary-and-references)

## 1. Intended use and system description

<!-- Guidance: State what the system does in the regulated process, who uses it, which records it creates, and where it sits in the architecture. The intended use is the yardstick for every later decision; write it with the process owner, not only IT. -->

### 1.1 Intended use

[*Example:* The laboratory information management system records
sample receipt, test assignment, instrument results and result review
for release testing of finished product at the [Site] quality control
laboratory. Approved results are the basis for batch certification.
The system does not control instruments; chromatography data comes
from a separate validated system through an interface.]

### 1.2 System description

| ID | Item | Description |
|---|---|---|
| SYS-001 *(Example)* | Software | Commercial laboratory system, configured, with two custom reports |
| SYS-002 *(Example)* | Hosting | Supplier-hosted software as a service in a qualified cloud region |
| SYS-003 *(Example)* | Interfaces | Chromatography data system (results in), ERP (batch status out) |
| SYS-004 *(Example)* | Users | About 120 analysts, 15 reviewers, 4 administrators |
| SYS-005 *(Example)* | GxP records | Sample records, results, review and approval signatures, audit trail |

### 1.3 Context diagram

The diagram shows the system boundary used for this plan: components
inside the boundary are validated here; components outside are
validated or qualified under their own records.

```mermaid
flowchart LR
  CDS["Chromatography data system (validated separately)"] -->|results| LIMS["Laboratory information management system"]
  LIMS -->|batch status| ERP["ERP (validated separately)"]
  Analyst["Analysts and reviewers"] --> LIMS
  Admin["System administrators"] --> LIMS
  LIMS --> Backup["Supplier backup service"]
  Infra["Qualified cloud infrastructure"] --- LIMS
```

## 2. Regulatory basis

<!-- Guidance: List the regulations and guidance that apply to this system in each market where its records are used. Dates and status change; record the date you checked each item. -->

| ID | Source | Status as checked | Applies because |
|---|---|---|---|
| REG-001 | EU GMP Guide (EudraLex Volume 4), Annex 11 Computerised Systems | Revision January 2011 in force; draft revision with revised Chapter 4 and a new Annex 22 on artificial intelligence was open for consultation from 7 July to 7 October 2025, final text not published as of October 2026 | Product released in the EU |
| REG-002 | EU GMP Guide, Chapter 4 Documentation | January 2011 version in force; revision in the same consultation | Records are GMP documents |
| REG-003 | 21 CFR Part 11, Electronic Records; Electronic Signatures | Subpart A General provisions (11.1 to 11.3), Subpart B Electronic records (11.10 to 11.70), Subpart C Electronic signatures (11.100 to 11.300) | Records submitted to or required by FDA |
| REG-004 | FDA guidance, Computer Software Assurance for Production and Quality Management System Software | Final, February 2026, docket FDA-2022-D-0795 | Risk-based assurance approach for production and quality system software |
| REG-005 | 21 CFR Part 820, Quality Management System Regulation | Effective 2 February 2026 | Only if the system supports medical device quality processes |
| REG-006 | UK MHRA and PIC/S data integrity guidance | [Version checked] | Inspection expectations on data integrity |
| REG-007 | ISPE GAMP 5 Second Edition | July 2022, industry guidance, not law | Life cycle structure and terminology used by this plan |

Notes:

- Annex 11 is organised as a Principle and 17 numbered clauses: General
  (1 Risk management, 2 Personnel, 3 Suppliers and service providers),
  Project phase (4 Validation) and Operational phase (5 Data, 6 Accuracy
  checks, 7 Data storage, 8 Printouts, 9 Audit trails, 10 Change and
  configuration management, 11 Periodic evaluation, 12 Security,
  13 Incident management, 14 Electronic signature, 15 Batch release,
  16 Business continuity, 17 Archiving). Section 9 of this plan maps
  controls to these numbers.
- When the revised Annex 11 is published, record its effective date in
  this table and re-assess section 9 against it.
- GAMP 5 is a paid publication. Official text: ISPE, purchase or
  licensed access: https://ispe.org/publications/guidance-documents/gamp-5-guide-2nd-edition.
  This plan cites its structure only.

## 3. GxP assessment and system categorisation

<!-- Guidance: Decide whether the system is GxP relevant and which functions are. Not every function of a GxP system needs the same assurance: separate functions that create or change GxP records from those that do not. -->

### 3.1 GxP assessment

| Question | Answer |
|---|---|
| Does the system create, change, store or report records required by GxP regulations? | [Yes / No, with explanation] |
| Does the system support a decision on product quality, patient safety or batch release? | [Yes / No] |
| Are records submitted to a regulator or available for inspection? | [Yes / No] |
| Are electronic signatures used in place of handwritten signatures? | [Yes / No] |
| Result | [GxP relevant / Not GxP relevant] |

### 3.2 Software category and function classification

GAMP 5 groups software by configurability: infrastructure software
(category 1), non-configured products (category 3), configured products
(category 4) and custom applications (category 5). The category helps
judge supplier evidence; risk, not category alone, sets the assurance
effort.

| ID | Function | Category | Direct GxP impact | Notes |
|---|---|---|---|---|
| FUN-001 *(Example)* | Result entry and calculation | 4 | Yes, high | Calculations configured by the laboratory |
| FUN-002 *(Example)* | Result review and approval with e-signature | 4 | Yes, high | Replaces handwritten signature |
| FUN-003 *(Example)* | Custom certificate of analysis report | 5 | Yes, high | Custom code |
| FUN-004 *(Example)* | Sample label printing | 3 | Indirect | Standard function |
| FUN-005 *(Example)* | Training calendar view | 3 | No | Not used for GxP decisions |

## 4. Risk assessment

<!-- Guidance: Assess each GxP function for what could go wrong, how bad it would be for patients, product or data, how likely it is and how likely it is to be caught. Use your quality system's risk method; the scoring below is an example only. -->

*Example* method: severity (S), likelihood (L) and detectability (D)
are each scored 1 to 3 (for D, 3 means hard to detect). The risk
priority is S x L x D, from 1 to 27. In this example, 12 or more is
high, 6 to 11 is medium, and below 6 is low. Thresholds are set by your
quality risk management procedure, not by this template.

| ID | Function | Failure | Effect | S | L | D | Priority | Class | Assurance response |
|---|---|---|---|---|---|---|---|---|---|
| RSK-001 *(Example)* | FUN-002 | Administrator can switch off the audit trail | Changes to results not recorded | 3 | 2 | 3 | 18 | High | Configuration lock, scripted test, periodic review of configuration |
| RSK-002 *(Example)* | FUN-001 | Configured calculation gives wrong result | Wrong release decision | 3 | 1 | 2 | 6 | Medium | Scripted test of each calculation with boundary values |
| RSK-003 *(Example)* | FUN-004 | Label layout misaligned | Reprint needed | 1 | 2 | 1 | 2 | Low | Unscripted testing, supplier evidence |
| RSK-004 *(Example)* | SYS-003 | Interface drops results | Missing data for release | 3 | 2 | 2 | 12 | High | Scripted interface test, reconciliation report in operation |
| RSK-005 *(Example)* | FUN-002 | Signature not linked to the record | Signature validity challenged | 3 | 1 | 3 | 9 | Medium | Scripted test of signature manifestation and linking |

## 5. Supplier assessment

<!-- Guidance: Decide how far you can rely on the supplier's quality system and testing. Leveraging supplier evidence is expected for configured products, but only after you have assessed the supplier. Hosted services also need an agreement covering data, backups, changes and audits. -->

| ID | Supplier | Assessment method | Result | Evidence relied on | Agreement |
|---|---|---|---|---|---|
| SUP-001 *(Example)* | [Software supplier] | Questionnaire and remote audit | Acceptable with observations | Release test reports, development procedures, defect list | Quality agreement signed YYYY-MM-DD |
| SUP-002 *(Example)* | [Cloud hosting provider] | Review of independent assurance reports | Acceptable | ISO/IEC 27001 certificate, SOC 2 report | Service agreement with data location and exit terms |

Supplier observations become actions with owners in section 11.

## 6. Requirements

<!-- Guidance: Write user requirements that can be tested, each with an ID and a risk link. Group them by process step. Do not copy the supplier's feature list; state what the regulated process needs. -->

| ID | Requirement | Function | Risk | Source |
|---|---|---|---|---|
| URS-001 *(Example)* | The system shall calculate assay results with the configured formula and round per the laboratory procedure | FUN-001 | RSK-002 | Laboratory procedure [ID] |
| URS-002 *(Example)* | The system shall record who changed which GxP data, when, and the old and new values, without the possibility of being disabled by users | FUN-002 | RSK-001 | Annex 11 clause 9; 21 CFR 11.10(e) |
| URS-003 *(Example)* | Signed records shall show the signer's printed name, date and time, and meaning of the signature | FUN-002 | RSK-005 | 21 CFR 11.50 |
| URS-004 *(Example)* | Signatures shall be linked to their records so that they cannot be copied or removed | FUN-002 | RSK-005 | 21 CFR 11.70 |
| URS-005 *(Example)* | Every result sent by the chromatography system shall be received or reported as missing | SYS-003 | RSK-004 | Annex 11 clause 5 |
| URS-006 *(Example)* | Access shall be limited to authorised users with role-based permissions | All | RSK-001 | Annex 11 clause 12; 21 CFR 11.10(d) |
| URS-007 *(Example)* | The system shall print a certificate of analysis with the approved results | FUN-003 | [Risk ID] | Quality procedure [ID] |

## 7. Assurance approach and testing

<!-- Guidance: Choose the testing method per requirement by risk. The FDA CSA guidance describes scripted and unscripted testing (including exploratory and ad hoc), and encourages using existing evidence such as automated test logs. Record the method, the evidence and the acceptance criteria; avoid screenshots that add no assurance. -->

### 7.1 Method by risk class

| Risk class | Assurance method | Evidence | Who reviews |
|---|---|---|---|
| High | Scripted testing with predefined expected results, including negative and boundary cases | Executed test record, objective evidence of results | QA |
| Medium | Scripted testing focused on the risk, or unscripted testing with documented objectives | Test record with summary of results and issues | System owner, QA sample |
| Low | Unscripted or exploratory testing, or reliance on supplier evidence | Brief record: what was tested, by whom, when, result | System owner |

### 7.2 Test plan

| ID | Requirement | Method | Environment | Acceptance criterion |
|---|---|---|---|---|
| TST-001 *(Example)* | URS-001 | Scripted, each formula with normal, boundary and invalid inputs | Validation environment | All results equal independently calculated values |
| TST-002 *(Example)* | URS-002 | Scripted, change data as each role, try to disable audit trail | Validation environment | All changes recorded; no role can disable the audit trail |
| TST-003 *(Example)* | URS-003, URS-004 | Scripted, sign, export, attempt to copy signature | Validation environment | Manifestation complete; signature cannot be moved |
| TST-004 *(Example)* | URS-005 | Scripted, send 500 results including malformed ones | Integration environment | 500 accounted for: received or reported |
| TST-005 *(Example)* | URS-006 | Unscripted, role matrix exploration | Validation environment | No access beyond the role matrix |
| TST-006 *(Example)* | URS-007 | Unscripted, review report layouts | Validation environment | Report content matches approved results |

### 7.3 Deviations during testing

Record every unexpected result as a test incident with an ID, impact
assessment, resolution and retest. A test incident that reveals a
requirement or risk error updates sections 4 and 6 before release.

## 8. Data integrity controls

<!-- Guidance: Show how the system keeps records attributable, legible, contemporaneous, original and accurate, and also complete, consistent, enduring and available (ALCOA+). List each control and where it is verified. -->

| ID | Principle | Control | Verified by |
|---|---|---|---|
| DI-001 *(Example)* | Attributable | Unique user accounts, no shared logins | TST-005, user access review |
| DI-002 *(Example)* | Legible and enduring | Records stored in a format readable for the retention period | Archive test in section 12 |
| DI-003 *(Example)* | Contemporaneous | Server time stamps synchronised to a trusted source | Configuration record |
| DI-004 *(Example)* | Original | Raw data from the interface kept unchanged with the result | TST-004 |
| DI-005 *(Example)* | Accurate | Calculations verified, manual entries second-person checked | TST-001, procedure |
| DI-006 *(Example)* | Complete and consistent | Audit trail on all GxP data, reviewed before result approval | TST-002, review procedure |
| DI-007 *(Example)* | Available | Backup and restore tested, records retrievable for inspection | Restore test in section 12 |

## 9. Electronic records and signatures controls

<!-- Guidance: Map the system's controls to Annex 11 clauses and 21 CFR Part 11 sections. Use short descriptions in your own words; do not paste the regulation text. Mark clauses that do not apply and say why. -->

| ID | Annex 11 clause | 21 CFR Part 11 section | Control in this system | Evidence |
|---|---|---|---|---|
| ERS-001 | 1 Risk management | 11.10 (system controls, in general) | Section 4 risk assessment | This plan |
| ERS-002 | 3 Suppliers and service providers | Not specific | SUP-001, SUP-002 | Supplier records |
| ERS-003 | 4 Validation | 11.10(a) | Sections 6, 7, 10, 11 | Validation report |
| ERS-004 | 5 Data, 6 Accuracy checks | 11.10(h) | URS-005, DI-005 | TST-001, TST-004 |
| ERS-005 | 7 Data storage, 17 Archiving | 11.10(b), 11.10(c) | Backup, archive and retrieval procedures | Restore test |
| ERS-006 | 8 Printouts | 11.10(b) | Report generation with record identifiers | TST-006 |
| ERS-007 | 9 Audit trails | 11.10(e) | URS-002 | TST-002 |
| ERS-008 | 10 Change and configuration management | 11.10(k) | Change control procedure | Change records |
| ERS-009 | 12 Security | 11.10(d), 11.10(g), 11.300 | URS-006, password and account rules | TST-005 |
| ERS-010 | 14 Electronic signature | 11.50, 11.70, 11.100, 11.200 | URS-003, URS-004 | TST-003 |
| ERS-011 | 15 Batch release | Not specific | Only qualified persons can certify; system enforces role | TST-005 |
| ERS-012 | 16 Business continuity | Not specific | Manual fallback procedure and recovery plan | Continuity test |

## 10. Traceability matrix

<!-- Guidance: Link every requirement to its risk, test and result. A high-risk requirement without a passed test blocks release. -->

| Requirement | Risk | Test | Result | Open issue |
|---|---|---|---|---|
| URS-001 | RSK-002 | TST-001 | [Pass / Fail] | [Incident ID] |
| URS-002 | RSK-001 | TST-002 | [Pass / Fail] | [Incident ID] |
| URS-003 | RSK-005 | TST-003 | [Pass / Fail] | [Incident ID] |
| URS-004 | RSK-005 | TST-003 | [Pass / Fail] | [Incident ID] |
| URS-005 | RSK-004 | TST-004 | [Pass / Fail] | [Incident ID] |
| URS-006 | RSK-001 | TST-005 | [Pass / Fail] | [Incident ID] |
| URS-007 | [Risk ID] | TST-006 | [Pass / Fail] | [Incident ID] |

General method: traceability matrix (`requirements/traceability-matrix`).

## 11. Release and validation report

<!-- Guidance: Summarise what was done, what deviated, what remains open and whether the system is fit for its intended use. Open items need an owner, a due date and a justification that they do not affect intended use. -->

| Item | Content |
|---|---|
| Summary of activities | [Sections 3 to 10 completed; list of executed tests] |
| Results | [*Example:* 6 tests executed, 5 passed first time, 1 passed after fix] |
| Deviations and test incidents | [IDs, impact, resolution] |
| Open actions | [ID, owner, due date, justification] |
| Procedures in place | [Use, administration, backup, incident, change, periodic review] |
| Training | [Users trained before access granted] |
| Conclusion | [The system is fit for its intended use / is not released] |
| Release decision | [@process-owner], [@qa-reviewer], YYYY-MM-DD |

## 12. Operational phase

<!-- Guidance: Describe how the validated state is kept: change control, periodic review, incident management, backup and restore, access review, and decommissioning. Most inspection findings on computerised systems come from the operational phase, not the project. -->

| ID | Process | Frequency | Owner | Record |
|---|---|---|---|---|
| OPS-001 *(Example)* | Change control with impact and regression assessment | Each change | System owner | Change record |
| OPS-002 *(Example)* | Supplier release assessment for hosted updates | Each release | System owner | Release assessment |
| OPS-003 *(Example)* | Periodic review of validated state, configuration, incidents and audit trail review effectiveness | Yearly for high risk | System owner, QA | Periodic review report |
| OPS-004 *(Example)* | User access review | Quarterly | Process owner | Access review record |
| OPS-005 *(Example)* | Backup restore test | Twice a year | IT service owner | Restore record |
| OPS-006 *(Example)* | Incident and deviation handling, with CAPA where needed | Each incident | System owner | Incident and CAPA records |
| OPS-007 *(Example)* | Decommissioning with data migration or archive | End of life | System owner | Decommissioning report |

Artificial intelligence and machine learning: if a future change adds
a model that influences GxP decisions, assess it against the draft EU
GMP Annex 22 and its final version when published, and treat model
updates as changes under OPS-001.

## 13. Roles and responsibilities

<!-- Guidance: Name each role and its decisions. The process owner owns the intended use and accepts the risk; the system owner owns the technical state; quality assurance oversees compliance but does not do the testing. -->

| Role | Responsibilities |
|---|---|
| Process owner | Intended use, requirements, risk acceptance, release decision |
| System owner | Technical design, configuration, supplier management, operational processes |
| Quality assurance | Review of plan, risk assessment and report; release approval |
| Subject matter experts | Requirements, test design and execution |
| IT service owner | Infrastructure, backup, access administration |
| Supplier | Development, release testing, hosting under the quality agreement |

## 14. Glossary and references

<!-- Guidance: Define terms for reviewers outside quality and IT, and list exact versions of regulations and guidance used. -->

### 14.1 Glossary

| Term | Meaning |
|---|---|
| GxP | Good practice regulations, for example manufacturing, laboratory, clinical and distribution |
| CSV | Computerised system validation: documented evidence that a system is fit for intended use |
| CSA | Computer software assurance: risk-based approach to establishing confidence in software |
| ALCOA+ | Attributable, legible, contemporaneous, original, accurate, plus complete, consistent, enduring, available |
| Audit trail | Secure, computer-generated record of who did what to GxP data, and when |
| Scripted testing | Testing with predefined steps and expected results |
| Unscripted testing | Testing without step-by-step scripts, guided by objectives, such as exploratory testing |
| Qualified person | Person responsible in the EU for certifying batches before release |

### 14.2 References

| Reference | Version or date | Official access |
|---|---|---|
| EudraLex Volume 4, Annex 11 Computerised Systems | January 2011 (revision in consultation 2025) | https://health.ec.europa.eu/medicinal-products/eudralex/eudralex-volume-4_en |
| 21 CFR Part 11 | Current eCFR | https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11 |
| FDA, Computer Software Assurance for Production and Quality Management System Software | Final guidance, February 2026 | https://www.fda.gov/regulatory-information/search-fda-guidance-documents/computer-software-assurance-production-and-quality-management-system-software |
| ISPE GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems | Second Edition, July 2022 | Official text: ISPE, purchase or licensed access: https://ispe.org/publications/guidance-documents/gamp-5-guide-2nd-edition |
| [Data integrity guidance used by the site] | [Version] | [Link] |

## Standard and licence note

Based on public regulatory texts (EU GMP Annex 11 and Chapter 4,
21 CFR Part 11) and the FDA guidance on computer software assurance;
structure aligned with ISPE GAMP 5 Second Edition, which is a paid
publication cited by name, edition and public structure only. Official
text: ISPE, purchase or licensed access:
https://ispe.org/publications/guidance-documents/gamp-5-guide-2nd-edition.
No text from GAMP 5 or the regulations is reproduced; clause and section
numbers are given for reference and all descriptions are original text
written for this collection. Check the current official texts, in
particular the status of the Annex 11 revision and the new Annex 22,
before use. This is a documentation format, not regulatory or legal
advice; follow your quality system and consult qualified
professionals. GAMP is a trademark of ISPE; this template is not
affiliated with or endorsed by ISPE, the European Commission or the
FDA. Template licence: MIT.