COMPUTER SYSTEM VALIDATION
Computer System Validation based on the V-model
A documented, risk-based demonstration that a computerised system consistently and reproducibly meets its defined requirements and is suitable for its intended use.
Context
CSV connects fitness for use, safety and traceable evidence
Computer System Validation (CSV) is a documented process demonstrating that a computerised system does what it was designed to do—consistently, reproducibly and against predefined requirements.
For pharmaceutical companies and medical-device manufacturers, transparency, product quality, patient safety, data integrity and controlled IT operation are central. The risk-based scope follows intended use, GxP/QMS relevance and the potential impact of individual functions.
The same principle is relevant in validated sterility, cleaning, method and process environments. Its practical application and terminology must match the system and the applicable quality management system.
VALIDATION FOCUS
Why Computer System Validation matters
Health and patient safety
Hazards to human health and the potential consequences of defective system functions are assessed systematically.
Product quality
GxP- or QMS-critical functions are protected by defined requirements, controls and risk-based testing.
Controlled IT operation
Transparent processes, governed change and reliable system documentation reduce malfunctions and failures.
Sustainable effort
Quality and project-management standards plus dependable documentation reduce maintenance and change effort across the lifecycle.
CSV ACCORDING TO THE V-MODEL
Align development phases with their verification phases
The V-model moves from risk, planning and user requirements through functional and design specification to implementation. On the right, every level is verified by its corresponding qualification or test stage; the traceability matrix and validation summary report complete the evidence.
Specification & planning
Basic / High-Level Risk Assessment (BRA/HLRA)
Determines whether the system or individual parts require validation or are GxP/QMS-critical, and sets the risk-based scope.
Validation Plan (VP)
Defines scope, strategy, activities, deliverables, roles, responsibilities, acceptance criteria and the controls for maintaining the validated state.
User Requirements Specification (URS)
Defines intended use, required functions, behaviour, processes, data, interfaces, roles and non-functional requirements from the business perspective without prescribing the solution.
Functional Specification (FS)
Translates user requirements into understandable system functions and states what the proposed solution must do.
Design Specification (DS)
Describes how configuration, development, interfaces and technical components will be built to satisfy the functional specification.
Verification & closure
Installation Qualification (IQ)
Uses instructions and checklists to show that the installation, version, components, settings and parameters were implemented correctly, transparently and reproducibly.
Technical Test / OQ
Tests units, integration, configuration and functions within specified limits. Scope, complexity, environment, acceptance criteria and defect handling follow the FRA.
User Acceptance Test / PQ
Uses representative users, data and realistic process conditions to confirm the URS and intended use.
Traceability Matrix (TM)
Links each user requirement to specification, risk, control, test, result and any deviation—in both directions.
Validation Summary Report (VSR)
Summarises the project history, test results, deviations, open items, residual risks and the justified release decision.
Development & configuration
Implements the approved design under control. Code, configuration, reviews, versions, transports and changes remain traceable.
The three central pairings
Business intended use and user requirements are confirmed under realistic process conditions.
The defined functions are verified within specified conditions using a risk-based approach.
The intended technical design is verified against the solution actually installed and configured.
TYPICAL EVIDENCE
The V-model evidence chain
- ✓Basic / High-Level Risk Assessment (BRA/HLRA)
- ✓Validation Plan (VP)
- ✓User Requirements Specification (URS)
- ✓Functional Specification (FS)
- ✓Functional Risk Assessment (FRA)
- ✓Design Specification (DS)
- ✓Development and configuration evidence
- ✓IQ, OQ/TT and PQ/UAT protocols
- ✓Traceability Matrix (TM)
- ✓Validation Summary Report (VSR)
- ✓SOPs, training, change control and periodic review
IQ · OQ · PQ
IQ, OQ and PQ form the right side of the V-model
Qualification does not stand alone: each stage verifies approved specifications against risk-based acceptance criteria.
Installation Qualification
Documented evidence that the system, components, versions, settings and parameters were installed and configured as intended.
Operational Qualification / technical test
Documented verification of functions, integration, configuration, boundary conditions and controls within specified operating conditions.
Performance Qualification / UAT
Evidence under representative real or realistic process conditions that the system and overall process support intended use.
HOW WE SUPPORT YOU
CSV support for SAP and regulated applications
- ●Risk-based validation
- ●Validation of SAP software components and custom-developed SAP applications
- ●Validation in the context of ISO 13485
- ●Basic and functional risk assessment
- ●Test-script creation and execution
- ●Execution and documentation of validation
- ●IQ, OQ/technical testing and PQ/UAT
- ●Traceability matrix and validation summary report
- ●Change control and maintenance of the validated state
REGULATORY CONTEXT
Current primary sources for orientation
Applicable requirements must be determined for the product, market, system and process. These sources are important reference points.
ISO 13485:2016
Quality management systems for medical devices; applicability must be assessed for the organisation and market.
FDA Quality Management System Regulation (QMSR)
The QMSR became effective on 2 February 2026 and incorporates ISO 13485:2016 by reference for covered manufacturers.
21 CFR Part 11
Criteria for certain electronic records and electronic signatures in the FDA context when the scope applies.
EU GMP Annex 11
Guidance on computerised systems in the pharmaceutical GMP environment.
COMMON QUESTIONS
Clear boundaries for CSV
Does every software function need full validation?
The required scope depends on intended use, regulatory relevance and risk. Relevant functions and controls are assessed; not every technical feature automatically receives the same depth of testing.
Is a successful test protocol sufficient?
No. Testing is one element. Clear requirements, risk assessment, controlled configuration, deviation decisions, traceability and governed operation are also needed.
Does CSV end at go-live?
Initial release is a milestone. Changes, incidents, authorisations, backups, reviews and retirement must support the validated state throughout the lifecycle.
NEXT STEP
Define a sensible validation scope
For an initial assessment, share the system and version, intended use, regulatory market, critical data, interfaces, available documentation and planned go-live date.
Professional information, not legal or regulatory advice. The requirements applicable to your product, organisation and market remain decisive.
