COMPUTER SYSTEM

VALIDATION (CSV)
in
cGMP ENVIRONMENT
Overview
Computer System General Requirements and
Validation Documentation

Password Policy

User Management Policies

Audit Trail Review Mechanisms

What is a Computerised System

A computerized system collectively controls the

performance of one or more automated processes and/or
functions. It includes computer hardware, software,
peripheral devices, networks and documentation.
What is Computerised Systems Validation
Means confirmation by examination and provision of
objective evidence that computer system specifications
conform to user needs and intended uses and that all
requirements can be consistently fulfilled
The purpose of validation of a computerized system is
to ensure an acceptable degree of documented
evidence that establishes confidence in the accuracy,
reliability and consistency in performance of the system
in accordance with predetermined specifications
Computerized system validation should ensure that all
necessary technical and procedural controls are
implemented ensuring compliance with good
documentation practices for electronic data generated by
the system
.................WHO GUIDELINES ON VALIDATION – APPENDIX 5 VALIDATION OF COMPUTERIZED SYSTEMS
Why CSV Validation
Validation of Computerized system is required as per various
regulatory agencies regulations:

21 CFR Sec. 211.68 - Automatic, mechanical, and electronic equipment

21 CFR part 11 § 11.10(a): Validation of systems to ensure accuracy,
reliability, consistent intended performance, and the ability to discern
invalid or altered records
ICH Q7 – Sec. 12: Validation
EU Annex 11: Computerized Systems Should be validated; IT
infrastructure should be qualified
PIC/S - Good practices for computerized systems in regulated “GxP”
environments
WHO Guidelines on validation – Appendix 5 : Validation of
computerized systems 3
Why CSV Validation

Provides evidence that the system functions to meet its intended

purpose
System bugs that may arise later can be rectified in a controlled
way so as to not impact the current functioning of the system
Computer systems, especially software components , cannot be
tested in the same way as a physical product/ equipment,
because:
Software is different, all software programs contain errors. How it is
used will determine whether the errors become visible or not
Software application complexity can mean that we could not test all
permutation of inputs and scenarios
Therefore end line testing (Vendor Testing) cannot be relied upon its
own to ensure product quality
How to Validate Computer Systems

Follow the Computer system validation master plan

Contact Corporate Informatics team for assistance
Follow the SOPs
Follow V-Model as mentioned in CSVMP
V-Model phases may be broadly grouped into two
categories
Development ( Plan, Design/Build, Validate)
Maintenance
How to Validate Computer Systems
Documents Requirements of CSV

Validation plan
Initial Risk assessment
Vendor Audit
URS, FS and SDS
Functional risk assessment
IQ.OQ.PQ
Traceability Matrix
Validation Summary Reports (IQ, OQ, PQ)
Maintenance : SOPs
Training Records
 To ensure authenticity and integrity, All
software controlled instruments should have

1. Prevent access to unauthorized users

2. Define privileges as per job functions /
hierarchies (PRM)
3. Data should be traceable (Audit Trail)
4. Protect the data from environmental hazards
(Disaster Recovery)
5. Protect from cyber attacks (Anti virus)
6. Implement the backup procedure
Key Principles of Validation
Establish quality management system

Establish documents management and their control

Establish configuration and change management strategy

Develop validation and qualification plans (VP/QP)

Establish user requirements (URS) and intended uses

Establish traceability across requirements, design docs and testing

Determine acceptance criteria and develop protocols

Validation summary reports of IQ, OQ and PQ

Quality Infrastructure

Quality Framework : Quality Policy and SOPs

Trainings

Project execution approach

System Design

Operation and Maintenance

Software Validation Flow Chart
Typical Software Validation Flow Chart
User Requirement
Initial Risk Assessment
Specification
Validation Plan

Functional/System
Vendor Assessment Specification
(Software/Hardware) Functional
Risk Assessment
Functional/System Design Specification
Requirement
System configuration specification Traceability
Module/ Unit testing Matrix
Source code review
Configuration freeze notification
Installation Qualification Protocol and Report
Draft SOP Prepare
Operational Qualification Protocol and Report
Final SOPs and Training
Performance Qualification Protocol and Report
Validation summary report
System Release or Rollout
The User Requirements

A Key CSV document , also called “The root document”

Required in the requirements definition phase
Helping the user groups to write short , concise , testable
and traceable requirements will reduce the
guesswork and help fast track the testing approach
Developing the traceability matrix throughout the
project lifecycle focuses testing and reduces project
closeout time at the end of the project.
Requirements are Complete
Not the HOW
The MES shall communicate with the PLC/SCADA in a hosted
environment using TCPIP Communication protocol
BUT the WHAT
The MES shall have the capability to communicate with the
PLC/SCADA

Not Recommended :
Requirement only states WHAT happens on power fail

Recommended :
Requirements states WHAT happens on power Fail & Power
restore
ATTRIBUTE : Unambiguous

Requirements shouldn’t be written in more than one way

Not Recommended
1. User shall be able to upload documents of maximum size of 2 MB
2. User shall be able to upload the Legacy (Scanned) documents of
size maximum 20 MB

Recommended
1. Maximum file size for files upload is as follows :
a. 20 MB for Legacy/ Scanned documents
b. 2 MB for the rest of the document types
Elements of a well written URS

Requirements must specify the “what” and not the “how”

Requirements are complete

Requirements are unambiguous

Requirements are testable

Requirements are traceable

Requirements are traceable –A typical URS
For purposes of traceability, requirements should be
uniquely numbered and not bulleted

Not Recommended :
Maximum file size for files upload is as follows :
• 20 MB for Legacy/ Scanned documents
• 2 MB for the rest of the document types

Recommended :
1.0 Maximum file size for files upload is as follows
1.1 20 MB for Legacy/ Scanned documents
1.2 2 MB for the rest of the document types
Installation Qualification
Purpose
Scope
Reference
System Description
Identification of Test Participants
Execution procedure
Pre-requisites
Test scripts
• Verification of system documentation
• Verification of installation of hardware and software components
Discrepancy Handling
Summary and conclusion
Document History
Approvals
Operation Qualification
Purpose
Scope
Reference
System Description
Identification of Test Participants
Execution procedure
Pre-requisites
Test scripts
• Verification of system functionality (positive and negative testing)
• Verification of workflow scenarios
• Verification of access rights and privileges
• Verification of audit trail
• Verification of data backup and restore
Continued…
Operation Qualification
• 21 CFR Part 11 verification
• Verification Disaster recovery procedure
• Verification of BCP procedure
• Verification of draft SOPs (Administration, operation etc.)
• Verification of trainings
Discrepancy Handling
Summary and conclusion
Document History
Approvals
Performance Qualification
Purpose
Scope
Reference
System Description
Identification of Test Participants
Execution procedure
Pre-requisites
Test scripts
• Verification of effective SOPs
• Verification of system functionality in actual scenario by end users
Discrepancy Handling
Summary and conclusion
Document History
Approvals
SOPS for CSV
Validation (CSVMP)
Vendor Audit
Document management
Change Control (QMS)
Training
Access security
User management
Audit Trail review
Periodic Review
Backup Restore
Data Archival
Maintenance phase SOPs
What is a VMP

Blueprint document for validation of systems and software

Cornerstone for validation

Provides the framework for :

How validation is performed and documented

How issues are managed
How to control and asses changes
How to maintain system in a validated state.
 Validation Approach as per Software type

SOFTWARE TYPICAL
DESCRIPTION VALIDATION APPROACH
CATEGORY EXAMPLES

Infrastructure Operating Document the version

Software Systems number and
Established or Database configuration details
commercially Managers as part of
available layered Programming infrastructure
software Languages qualification; verify
1 Applications are Middleware
that the system is
developed to run installed correctly as
Ladder Logic per approved or
under the control
Network prescribed installation
of this kind of
Monitoring procedures.
software.
Tools
 Validation Approach as per Software type

SOFTWARE TYPICAL
DESCRIPTION VALIDATION APPROACH
CATEGORY EXAMPLES
Non-configured or Computer Reduced system
Commercial off-the- controlled validation life-cycle
shelf (COTS) Systems spectrophotomete approach
Ready-made Computer rs URS
system or standard Firmware based Validation plan
software package where applications
Supplier Assessment
no customization or Laboratory
configuration has been Initial Risk assessment
instrument
done or possible to be software with no Functional and Hardware
3 done configuration specification
Installation Qualification
required
Operation Qualification
SOPs
Performance
Qualification
Validation summary
report
Data Backup procedure
 Validation Approach as per Software type

SOFTWARE VALIDATION
DESCRIPTION TYPICAL EXAMPLES
CATEGORY APPROACH
Commercial off-the- LIMS, Track- Full system validation life-cycle
approach
shelf (COTS) Systems wise,
URS, Supplier Assessment,
(Hybrid) SCADA, HMI Initial risk assessment
These are ready-made SAP Hardware specifications
computer systems or Functional requirements
Clinical Trial specifications
standard software
Monitoring, System configuration
package which are specifications
DCS, EDMS,
configured to suit the
4 BMS, Functional risk assessment
workflow requirements Installation Qualification
of the user. Spread-sheets
Operation Qualification
SOPs
User trainings
Performance Qualification
Requirement traceability matrix
Validation summary report
System release certificate
Data Backup procedure
 Validation Approach as per Software type

SOFTWARE VALIDATION
DESCRIPTION TYPICAL EXAMPLES
CATEGORY APPROACH
System developed for Full system validation life-cycle approach
Custom-Built plus more rigorous supplier assessment with
specific use as per user
Applications (In-house requirements.
possible onsite supplier audit
URS, Supplier Assessment, Initial risk
/ Customized) ZyIMS assessment
Hardware specifications
Custom-Built is a type of
Functional requirements specifications
software that is System configuration specifications

developed an individual System design specifications

Source code review
organization .
Functional risk assessment

5 Such systems may either

be developed by an in-
Module/ Unit testing at vendor site during
software development
Configuration freeze notification
house programming Installation Qualification

team or by an external Operation Qualification

SOPs
vendor but these kinds of User trainings
software are tailor-made Performance Qualification
Requirement traceability matrix
only for a particular
Validation summary report
organization's specific System release certificate
requirements. Data Backup procedure
Test Environments
Complexity and size determines size and number of environments

Typically 3 environments for large applications

Re-Validation
Gap Assessments and Validation of Legacy system
Legacy Computerized Systems – PIC/s
• These are regarded as systems that have been established and
in use for some considerable time. For a variety of reasons, they
may be generally characterized by lack of adequate GMP
compliance related documentation and records pertaining to the
development and commissioning stage of the system.
Additionally, because of their age there may be no records of a
formal approach to validation of the system. (PIC/s)

Regulatory requirements for Legacy system – (PIC/s)

• Defined requirements (URS)
• System description, or equivalent (FS, DS)
• Verification evidence that the system has been qualified and
accepted and that GxP requirements are met (IQ, OQ, PQ)
Insure IT Infrastructure is qualified

IT SOPs are implemented

GAP assessments for legacy systems is carried out and

mitigation plans ready

Software and IT systems inventory is available

All GxP software have independent Administrators

No Generic IDs present in system

Administrator JD is available

User training records and privilege right matrix are available

Etc….
 PASSWORD POLICY
The administrator authorizes access for a user by creating a user
account.
All users are identified by having a unique user-ID and a secret
password before being able to gain access to system
Account should lock after a certain number of failed login attempts
Auto logout from system when idle
Password policies requirements are:
A defined length of passwords to be kept
Password should be complex
Users should be able to change their own passwords at any time
Password should have a defined expiry duration
When the user log on for the first time, the system should ask to
change the password.
User Controls
Desktop policies to be activated on the computer system to control
access to the software by users
Password control
Date and time locking
Restriction for file/folder creation, cut, copy, paste and deletion.
No access to the window explorer and internet explorer
Locking of software / computer after predetermined time when idle.
Disable USB, CD and floppy drive
Hide local drives
Restrict access to Control panel in the computer
Restrict access to Network neighborhood
Restrict access to My Documents
Restrict access to Run option etc.
Restrict access to local administrator
Etc…..
USER MANAGEMENT SYSTEM IN QC
SOFTWARES
USER MANAGEMENT SYSTEM IN QC
SOFTWARES
USER MANAGEMENT SYSTEM IN QC
SOFTWARES
Typical Audit Trail review
Shashank Pandey
[email protected]