Computer System Validation (CSV)

Computer System Validation (CSV) is a method of establishing documented evidence that a computerised system is fit for its specified intended use in a defined operating environment. Also called computerized system validation or computerised system validation, CSV is a quality-system method—not the name of a statute or a vendor certification.

• Specified intended use: identify the activities, users and decisions the system will support. A user requirements specification translates that purpose into assessable requirements.
• Documented evidence: retain the basis for the conclusion, including assessments, observed results and resolution of discrepancies. Requirements traceability connects those records to the intended use.
• Defined operating environment: identify the configuration, technical dependencies and working procedures under which the evidence applies.

The assessment boundary can include application software, configuration, infrastructure dependencies, interfaces, data and operating procedures. For example, assessing a system for recording equipment cleaning does not establish its fitness for calculating batch quantities. A conclusion about one configured system and intended use does not establish fitness for every installation of the same software.

Authorised people approve validation conclusions and deployment; authorised people also make product-quality and release decisions. Software support and successful tests provide inputs to those decisions, but do not themselves make them. A validation conclusion therefore concerns a defined system use, not the acceptability of every product handled through it.

For distinctions from testing, qualification and process validation, see the comparison of neighbouring terms.

Start with the product, market and intended system use—not a generic “CSV requirement”. Applicability mapping is a practical assessment method: determine the governing rules before importing medicine-specific controls into another manufacturing context. Record the rationale so that reviewers can distinguish an applicable obligation from a voluntarily adopted assurance method.

For a US drug-GMP assessment, establish product applicability first; the 21 CFR 211 overview provides context. Where applicable, 21 CFR 211.68(b) requires controls ensuring that record changes are instituted only by authorised personnel and that computer inputs and outputs are checked for accuracy.

For electronic records and signatures, check the current text of 21 CFR 11.1 for scope and 21 CFR 11.10(a) for the applicable closed-system provision. Keep that applicability decision separate from selecting validation activities. The Part 11 glossary addresses the related terminology.

Annex 11 is official EU GMP guidance; check its current product-specific applicability. Annex 11, Principle distinguishes application validation from IT infrastructure qualification.

FDA guidance is distinct from regulatory text. The FDA Part 11 guidance, audit-trail recommendations, recommends considering predicate-rule requirements when deciding whether to use audit trails or other appropriate measures. This informs the assessment of audit-trail controls, rather than replacing the underlying rules.

Keep recognised industry frameworks in a separate category: they organise professional assurance methods, not legal authority. Software supports controlled execution and evidence handling; it is not another regulatory source. The applicability conclusion and acceptance decisions remain with authorised people.

A practical impact screen starts with functions, not software labels. For each function, ask which decisions it supports, which records it creates or changes, what depends on its outputs, and what an undetected failure could cause. Distinguish:

• Direct process control: equipment software setting operating parameters or MES directing execution.
• Quality-relevant calculations: spreadsheets calculating potency or LIMS calculating reportable results.
• Record handling: ERP maintaining material status, reporting tools presenting release information, or interfaces transferring results.
• Genuinely administrative uses: expense reporting or room booking with no dependency affecting GMP decisions or records.

Apply this screen to ERP, MES, LIMS, equipment software, spreadsheets, reporting tools and interfaces individually. One application can contain both quality-relevant and administrative functions: ERP inventory status may affect material use while its expense module does not. An exclusion needs a defensible boundary—identify shared data, configuration and services, and explain why the excluded function cannot affect the scoped activity. Calling a module “business software” is not that justification.

Keep a concise scope record covering intended use, site and process, product context, system owner, process owner, version, configuration, environments, interfaces, records and exclusions with reasons. Use the regulatory mapping for the jurisdictional assessment. These fields make the assessment reproducible; they are practical documentation choices, not a universal template. Revisit the scope record whenever intended use, interfaces or hosting arrangements change, because each change can alter which records and controls the system must support.

For hosted systems and GxP cloud computing, identify who controls infrastructure, application releases, local configuration, access administration, data export and recovery. Compare contractual responsibilities with actual technical access: that allocation informs whose evidence can be used and which checks the manufacturer can perform.

For medicinal-product GMP systems, official EU GMP guidance in Annex 11, section 4.1 addresses validation documentation and reports across relevant lifecycle steps. Section 4.4 connects required functions to documented risk assessment and GMP impact, with user requirements traceable throughout the lifecycle. The practical objective is a defensible acceptance decision for a defined system baseline—not a large collection of documents.

Sequence the work and assign accountability

1. Define intended use. The process owner identifies supported activities, users, operating boundaries and acceptable business outcomes.
2. Assess risks and suppliers. Process and quality representatives assess GMP consequences; the technical owner evaluates supplier information and the proposed architecture.
3. Specify requirements and acceptance criteria. The process owner defines functions in the user requirements specification; reviewers agree measurable acceptance criteria before execution.
4. Establish the configuration baseline. The technical owner identifies software versions, settings, infrastructure and interfaces so verification addresses a reproducible configuration.
5. Execute proportionate verification. Named testers record actual results separately from expected results and retain supporting observations. Reviewers assess coverage and evidence quality.
6. Resolve acceptance. Process and technical owners assess exceptions and residual risk; designated quality and business approvers document whether operation is authorised, including any justified restrictions.
7. Maintain and retire. The system owner coordinates ongoing assurance and eventual retirement, with assigned responsibility for retained records.

This workflow is an implementation pattern, not a mandatory sequence of document titles. Responsibilities should be explicit even when one person holds several roles.

Organise evidence around the decision

A useful validation package contains scope and plan, requirements, risk assessments, supplier evaluation, configuration records, test strategy, execution evidence, exception dispositions, traceability and the approval decision. Each component answers a different question: what was intended, why verification was sufficient, what actually happened, and why the result was accepted. A CSV deviation report connects an unexpected result to its assessment, corrective action where needed, and disposition; it does not turn a failed observation into a pass.

An illustrative data model places the baseline at the centre, linked to requirements, risks, verification evidence, exceptions and decisions. Evidence identifies the tested version and environment. Requirement-to-test relationships can be many-to-many: one test may address several requirements, while one requirement may need several tests. A CSV traceability matrix makes those relationships reviewable. Approved revisions preserve earlier evidence rather than replacing it, allowing reviewers to reconstruct each acceptance decision. These workflow and data-model relationships describe validation practice, not product functionality.

For computerised systems within EU GMP scope, Annex 11, section 1, places lifecycle risk management in the context of patient safety, data integrity and product quality. This official GMP guidance provides the starting point for deciding where assurance effort matters most.

GAMP is an industry-practice framework, not legislation. A classification label can help describe software, but cannot establish a complete validation strategy. For risk-based validation, examine configuration, customisation, complexity, uncertainty and failure consequences. A simple configurable calculation may warrant close scrutiny when its result drives a consequential decision; extensive software functionality does not make every function equally critical.

Assess relevance, not document volume

Assess supplier development and testing practices, defect handling, release communication, security and continuity evidence. Establish whether each item concerns the installed version and relevant components. A large test report offers little assurance for a configuration or interface it never exercised.

Map supplier evidence against customer-specific configuration, roles, workflows, interfaces and intended use. Identify gaps, then choose assessment depth according to their significance and uncertainty: targeted document questions may resolve a clear, limited gap; consequential unknowns may justify deeper supplier assessment and direct verification. Record which evidence is reusable and what remains to be demonstrated locally.

Annex 11, section 3.4, addresses making supplier or developer quality-system and audit information available to inspectors on request.

Worked case: configured yield calculation

Assume yield = output mass ÷ input mass × 100, with inclusive limits of 95.0%–105.0%. These are illustrative assumptions, not regulatory or product specifications. With input fixed at 200.0 kg:

• 192.0 kg output gives 96.0%: within limits.
• 189.8 kg output gives 94.9%: below the lower limit.
• 190.0 kg output gives exactly 95.0%: at the accepted boundary.

Alongside normal arithmetic, collect evidence for both limit boundaries, zero input mass and an unauthorised formula-change attempt. These scenarios probe comparison logic, undefined division and protection of the approved calculation. They make operational qualification more informative than repeatedly testing comfortable mid-range values.

These terms address different questions in quality engineering. The comparison below reflects common operational usage, not universal legal definitions.

Adopting CSA terminology alone does not determine which requirements, risks or tests matter for a particular system. It does not, by itself, make existing evidence unusable; assess that evidence against the intended use and current system conditions.

Testing, user acceptance testing and qualification—including operational qualification—can contribute evidence to an assurance case without becoming interchangeable terms. Manufacturing process validation may draw on system evidence while answering a different question. See the lifecycle and evidence package section for how these contributions are organised.

Separate operational records—measurements, material transactions and production approvals—from validation evidence: executed checks, observed results, deviations and approval decisions. Both need defined ownership, but they answer different questions: what happened in production, and why the system was accepted for its intended use. This distinction makes data integrity tests more specific.

For each record class, identify who creates, reviews, changes and retrieves it. A practical allocation might name operators and production reviewers for operational records, and test executors and authorised approvers for validation evidence. Identify permitted corrections and retrieval responsibilities separately. Connect every tested control to its requirement, expected result and retained evidence.

Where Annex 11 applies, its official GMP guidance addresses three useful verification targets:

• Section 9 says audit trails should be available, convertible to a generally intelligible form and regularly reviewed. Test the review workflow, not merely whether an audit trail exists.
• Section 12.3 describes recording the creation, change and cancellation of access authorisations.
• Section 14(b)–(c) expects electronic signatures to remain permanently linked to their respective records and include the time and date of application.

Practical challenges include attempting unauthorised changes, checking that revoked access no longer permits protected actions, retrieving record histories and producing intelligible exports for reviewers. After a controlled correction, examine the signature-to-record association: can a reviewer establish exactly which record was signed? Retain actual results, including unexpected behaviour, rather than only a pass label. These are illustrative scenarios, not a complete test specification.

Use the earlier applicability assessment for 21 CFR Part 11; do not assign every electronic record the same regulatory route.

A successful transfer demonstrates one path, not reliable recovery. Interface validation should also challenge what happens when processing stops between receipt, commitment and acknowledgement. These are practical test-design choices based on the architecture and consequences of failure.

For migration, EU GMP guidance in Annex 11, section 4.8 describes validation checks that preserve data value and meaning. Matching record counts alone cannot establish this: transferred records may retain their count while losing units, changing identifiers or statuses, or breaking relationships. Compare representative source and destination records, including material master data and its links to transactions.

For electronic exchange, Annex 11, section 5 describes built-in checks for correct and secure data entry and processing. Possible controls include stable event identifiers for duplicate detection, correlation identifiers connecting messages and responses, unit and schema checks, defined retry behaviour, detection of incomplete transactions, quarantine, authorised replay and source-to-destination reconciliation. Select these controls for the actual failure modes; they are not a universal software checklist.

Worked case 2: a lost acknowledgement

Assume opening inventory of 500.0 kg, ten unique material-issue events of 12.0 kg each and no other transactions. One event is retransmitted after the destination commits it but its acknowledgement is lost.

• Correct processing: 10 × 12.0 kg = 120.0 kg deducted; 500.0 − 120.0 = 380.0 kg remaining.
• Duplicate processing: 11 × 12.0 kg = 132.0 kg deducted; 500.0 − 132.0 = 368.0 kg remaining.
• Inventory error: 380.0 − 368.0 = 12.0 kg understated.

Require the test evidence to distinguish eleven deliveries from ten unique business events, show the duplicate's disposition and reconcile both systems before closing recovery. A delivery log alone cannot demonstrate the correct inventory balance.

Test interruptions at meaningful transaction boundaries, not only by disconnecting an idle interface. For example, an MES–SCADA integration exercise can interrupt processing after commitment but before acknowledgement, then examine retry and reconciliation evidence. Connect recovery exercises to continuity arrangements for critical processes: Annex 11, section 16 recommends documenting and testing those arrangements.

Assess the change before deployment

For computerised systems within its EU GMP scope, Annex 11, section 10 describes controlled changes, including configuration changes, under a defined procedure. Translate that guidance into a practical change-control assessment: identify the affected baseline, requirements, risks, interfaces, records and operating procedures; review supplier information; select regression checks; define deployment and rollback arrangements; and record the authorised approval decision.

Targeted regression is a justified selection of checks based on documented impact and dependencies—not an unexplained decision to perform no testing. Record why selected checks cover the affected functions and why excluded areas remain unaffected. If no execution testing is proposed, document the supporting assessment and alternative evidence for approval rather than leaving the test scope blank.

After deployment, compare results with the change objectives and investigate unexpected effects. ICH Q10, paragraph (d) preceding Table III, recommends post-implementation evaluation to confirm that objectives were achieved without deleterious impact on product quality.

Review the operating system, not just its approval date

Annex 11, section 11 describes periodic evaluation to confirm continued valid state and GMP compliance. As a practical approach, set periodic-review timing through documented risk, operational stability, and change or incident history rather than assuming one interval suits every system.

Examine actual use, access, supplier support, unresolved issues, performance, recovery evidence and changes to dependencies. Compare current operation with the approved baseline, including workarounds that may not appear in configuration records. Record actions, owners and follow-up; a dated signature alone does not explain whether identified weaknesses were resolved or accepted by authorised people.

Retire without losing record usability

A practical retirement plan identifies record custodianship, retrieval arrangements, dependencies to disconnect and evidence to retain. Include a retrieval exercise after relevant migration or platform changes, applying the migration principles covered above. Confirm who will answer future record requests and how they will access readable records before withdrawing the old service.

Use these practical checks to challenge an acceptance decision; suggested owners should match local responsibilities.

EU GMP guidance in Annex 11, section 13 says all incidents should be reported and assessed—not only obvious system failures or data errors.

For unresolved defects, use the CSV deviation report to connect impact to intended use. A severity label or defect count is not a disposition. The acceptance conclusion should identify any operational restriction, residual risk and accountable decision.

Use these questions for implementation handover and later review—not as a universal regulatory form. For each answer, identify the supporting artefact, accountable owner and any outstanding action. Refer to the evidence package, supplier assessment and record controls.

1. Is the intended use and applicable regulatory context explicit?
2. Are the system baseline and accountable owners identifiable?
3. Are critical requirements linked to evidence and acceptance decisions?
4. Are supplier-evidence gaps addressed?
5. Have relevant boundary conditions and recovery behaviours been examined?
6. Are exceptions dispositioned, with rationale and follow-up actions recorded?
7. Are operational procedures and user responsibilities ready, including the audit trail review workflow where relevant?
8. Are change, review and retirement arrangements assigned to named owners?