Introduction to Computer System Validation
Computer System Validation are now used throughout the pharmaceutical industry for activities such as laboratory testing, manufacturing, quality management, warehouse operations, stability studies and document management.
Because these systems may create, process, store or report GMP-related information, their reliability can directly affect product quality and data integrity.
Computer System Validation (CSV) provides documented evidence that a computerized system is suitable for its intended use and performs consistently within its defined requirements.
Related Articles
Complete Procedure for Analytical Method Validation
Procedure for HPLC Operation and Cleaning
What Is Computer System Validation?
Computer System Validation is a documented process used to demonstrate that a computerized system consistently performs its intended functions and maintains reliable, accurate and secure information.
CSV tell us “Can we demonstrate with documented evidence that this computerized system does what we need it to do and protects the information it handles?”
Examples of systems that may require validation include:
- Laboratory Information Management Systems (LIMS)
- Chromatography data systems
- ERP systems used for GMP activities
- Quality Management Systems
- Electronic Batch Record systems
- Stability management systems
- Environmental monitoring systems
- Manufacturing control systems
- Electronic document management systems
- Computerized warehouse systems
The extent of validation should depend on the system’s intended use and its potential impact on product quality, patient safety and data integrity.
Why is Computer System Validation Required?
CSV is important because a computerized system can introduce risks that may not be obvious during normal operation.
For example, incorrect software configuration could:
- Calculate a result incorrectly.
- Allow unauthorized users to change data.
- Fail to record important changes.
- Generate an incorrect report.
- Delete or overwrite information.
- Use incorrect system settings.
- Prevent retrieval of historical records.
FDA guidance recommends considering the effect of computerized systems on the accuracy, reliability, integrity, availability and authenticity of records, with the extent of validation based on documented risk.
Therefore, CSV provides evidence that important computerized functions have been properly evaluated before the system is relied upon for GMP activities.
Regulatory and GMP Expectations – Computer System Validation
Computerized systems used in GMP operations should be controlled throughout their lifecycle.
EU GMP Annex 11 states that the application should be validated and the IT infrastructure should be qualified. It also emphasizes risk management throughout the system lifecycle, considering patient safety, product quality and data integrity.
For systems subject to applicable FDA requirements, electronic records and electronic signatures may also require consideration of 21 CFR Part 11 and relevant predicate-rule requirements. FDA recommends a risk-based approach when determining the validation effort.
Important GMP expectations generally include:
- Defined intended use
- Approved user requirements
- Risk assessment
- Controlled configuration
- Appropriate testing
- User access control
- Audit trail where applicable
- Backup and recovery
- Change control
- Periodic review
- Incident/deviation management
- Data integrity controls
- Controlled system retirement
Computer System Validation Procedure
Define the Intended Use
Start by clearly explaining what the system is intended to do.
Prepare the User Requirement Specification
The URS should describe what users and the business require from the system.
Requirements may cover:
- User functions
- Data entry
- Calculations
- Reports
- Security
- Audit trail
- Electronic signatures
- Interfaces
- Data retention
- Backup
Perform a Risk Assessment
Not every function presents the same level of risk.
Identify functions that could affect:
- Product quality
- Patient safety
- GMP records
- Data integrity
- Regulatory compliance
Higher-risk functions should receive greater validation attention.
Assess the Supplier
For vendor-supplied systems, evaluate the supplier according to the site’s approved supplier-management procedure.
The assessment may consider:
- Supplier experience
- Quality system
- Software development practices
- Change management
- Testing approach
- Technical support
- Security practices
- Documentation
- Backup/recovery capabilities
Define the Validation Plan
Prepare a validation plan describing:
- System scope
- Responsibilities
- Validation strategy
- Risk approach
- Required documents
- Testing strategy
- Acceptance criteria
- Deviation handling
- Change control
- Release requirements
Configure or Develop the System
Configure the system according to approved requirements.
Important configuration items may include:
- User roles
- Password controls
- Permissions
- Workflows
- Calculations
- Report formats
- Units
- Date/time settings
- Audit trail
- Electronic signatures
- Interfaces
Configuration should be controlled and documented.
Perform Qualification and Testing
Testing should demonstrate that important requirements actually work as intended.
Depending on the system, testing may include:
Installation Qualification — IQ
Confirms that required hardware, software and supporting components have been installed correctly.
Typical checks include:
- Hardware identification
- Software version
- Operating system
- Database
- Installation documentation
- Network components
- Supporting infrastructure
Operational Qualification — OQ
Challenges important functions to confirm that they operate according to approved requirements.
Typical checks include:
- Login controls
- User roles
- Password controls
- Calculations
- Audit trails
- System alarms
- Reports
- Electronic signatures
- Security functions
Performance Qualification — PQ
Demonstrates that the system performs effectively in the actual or representative user environment.
For some systems, a different lifecycle or testing structure may be justified. The important point is that the selected approach should be risk-based and documented rather than following a qualification sequence mechanically.
Practical Implementation of CSV
A practical CSV project should include testing of the functions that matter most.
For example, suppose a QC laboratory uses a computerized system for analytical data.
Important tests include:
- Create a user.
- Assign the correct role.
- Confirm unauthorized functions cannot be accessed.
- Enter sample information.
- Generate an analytical result.
- Verify calculations.
- Change an appropriate record.
- Confirm the audit trail records the change.
- Verify electronic approval, where applicable.
- Generate the final report.
- Confirm backup and restoration.
- Verify that records remain retrievable.
FDA’s guidance describes audit trails as secure, computer-generated records that allow reconstruction of events relating to creation, modification and deletion of electronic records.
Requirement → Test → Expected Result → Actual Result → Pass/Fail → Evidence → Reviewer
This makes the validation package much easier to review.
Common Mistakes in Computer System Validation
Several problems can weaken a CSV program.
1. Testing Without Clear Requirements
If requirements are not defined properly, it becomes difficult to determine what should actually be tested.
2. Treating Vendor Documentation as Validation
Supplier documents can provide useful evidence, but the regulated company still needs to demonstrate that the configured system is suitable for its intended use.
3. Ignoring Data Integrity
CSV should consider more than software functionality. Access controls, audit trails, backups, data changes and record protection are also important.
4. Poor User Access Management
Users should receive access appropriate to their responsibilities. Excessive administrator privileges can create unnecessary risk.
5. No Traceability
Important requirements should be traceable to validation tests and their results.
6. Weak Deviation Handling
Failed tests should be investigated and documented rather than removed from the validation package.
7. Testing Only the Happy Path
Testing should also consider reasonably foreseeable incorrect inputs, unauthorized actions, system errors and boundary conditions where relevant.
8. Ignoring Changes After Validation
A validated system does not remain permanently unchanged. Software updates, configuration changes, infrastructure changes and new interfaces may require assessment through change control.
CSV Documentation
The exact documentation package depends on the system and risk, but commonly includes:
- User Requirement Specification (URS)
- System Risk Assessment
- Supplier/Vendor Assessment
- Validation Plan
- Functional or configuration specifications, where applicable
- System architecture documentation
- Installation/qualification records, where applicable
- Test protocols
- Test results
- Traceability Matrix
- Deviations/Exceptions
- Validation Summary Report
- System operating procedures
- User access records
- Backup and recovery procedures
- Change control records
- Training records
- Periodic review records
The final documentation should provide a logical story from requirement → risk → testing → result → approval.
FAQ’s for Computer System Validation
Is Computer System Validation mandatory in pharmaceutical companies?
Computerized systems used in GMP activities need appropriate controls and validation based on their intended use and applicable regulatory requirements. The extent of validation should be based on risk.
Is 21 CFR Part 11 the same as CSV?
No. CSV is the broader validation lifecycle used to demonstrate that a computerized system is suitable for its intended use. Part 11 addresses specific requirements for electronic records and electronic signatures within its scope.
Is GAMP 5 a regulation?
No. GAMP 5 is an industry good-practice framework used by many organizations to support a risk-based approach to computerized systems. It should not be described as a law or regulation.
Are IQ, OQ and PQ required for every computerized system?
Not necessarily. The validation and testing approach should be appropriate to the system’s complexity, intended use and risk.
References for Computer System Validation
FDA – 21 CFR Part 11, Electronic Records; Electronic Signatures