Overview of computer system validation

COMPUTER
SYSTEM
VALIDATION
-Nilesh Damale

History of CSV
2
 FDA’s regulation on electronic records and electronic signatures (21 CFR Part 11) became effective on August 20, 1997
 The regulation applies to both new and existing systems used in the pharmaceutical and healthcare industries.
 Compliance with the 21 CFR Part 11 regulation required computer systems to manage records entirely electronically.
Management of printed copies of electronic records (known as hybrid systems) was not deemed acceptable as a long-
term solution. This meant many computer systems needed custom developments either by pharmaceutical and
healthcare companies or their suppliers to satisfy the regulation. Where such developments were not possible,
systems had to be replaced.

Challenges in front of Regulatory Companies
3
 Current system is paper-based in most companies and requires that highly skilled technical
resources for time consuming activities like printing paper documents, writing results using
pen which creates GDP and DI errors, capturing & annexing test evidences, scanning and
routing documents for review an approval results in lose of man hours and chances of non-
compliances issues.
 Various standards, procedures, templates exist across organization which creates confusion
and duplication of work.
 Significant increase in cost caused by inconsistent interpretation of standards and
requirements.
 Decentralized governance, uncontrolled execution, inadequate planning & lack of clear role
and responsibilities.
 Users are not necessarily well versed in systems development or CSV requirements,
information technology people are frequently unfamiliar with the regulations, and QA
personnel often do not understand systems development or the business processes
supported by systems. Such fragmentation increases uncertainty in interpreting the
regulations and determining potential CSV approaches.
 That lack of essential decision making tools, particularly in large, multifunction systems, leads
to “over validation” for some systems and/or system functions and “under validation” for
others.
 Companies do not see a positive return on their CSV investments because the obstacles
involved increase the time and money they spend on CSV-related projects. Because it has
acquired the reputation of a “necessary evil”.
Docume
ntation
40%
SOPs
15%
Approvals
10%
Testing
25%
Templates
10%
FACTORS THAT ADDS
TO CSV EFFORTS- AND
COST

Challenges in front of Regulatory Companies
4
Written Observation
Product Seizure
Shutdown of Manufacturing &
Stopping of Supply
Warning Letter
Financial Penalty
Loss of Licence
IncreasingRegulatoryAction
Increasing Lack of Regulatory Compliance
Potential impact of lack of regulatory compliance

Discovery &
Innovation
Clinical Trials Registration Manufacturing QA Distribution Marketing
Regulated CSV applications in the life cycle of the product
manufacturing process
5
 Patent
Management
 Clinical Data
Management
 Statistical
Packages
 Pharmaco-
vigilance
 Product
Specifications
 Device
Certification
 Regulatory
Submissions
 Process
Instrumentation
& Control
Systems
 Inventory
Management
 Electronic Batch
Records
 Labelling
 Packaging
Systems
 MRP/ ERP
 Laboratory
instruments
 CDS, LIMS
 Certificate of
Analysis
 Document
Management
Auditing
 Electronic
Notebooks
 Artwork
 Shipping
 Recall
 Customer
Complaints
 Marketing
Specifications
 Sample
Management

Quality Systems
Facilities and
Equipment
Systems
Materials Systems
Production
Systems
Packaging and
Labelling Systems
Laboratory Control
Systems
Regulated CSV applications in the life cycle of the product
manufacturing process
6
 Document
management
 SOP administration
 Security access
controls (e.g., user
profiles and
password
management)
 Change control
records
 Customer
complaints
 Adverse event
reporting
 Review/audit/corre
ctive actions
management
 Training records
 HVAC controls and
alarm handling
 Critical equipment
and
instrumentation
(calibration and
maintenance)
 Utility Management
System (Water
storage &
distribution, Chiller,
Boiler, Heat Pump,
Compressed Gases
etc.)
 Traceability of
material handling
 Raw material
inspection/testing/
quarantine
management
 Storage conditions
 Containers usage
and cleaning
management
 Distribution records
and recall
management
 Recipe/formulation
management
 Batch
manufacturing
instruction and
records
 In-process testing
 Yield calculation
 Purified water
 Aseptic filling
 Labelling
information
 Track & Trace
 Sealing Machine
 QC raw data
 Stability testing
 Sterility testing
 QC analytical
results
 Quality disposition
 Out of specification
investigations

Regulatory Expectations Concerning Computer Validation
7
Industry
Sector
Validation Expectation Prominent Regulations
Food
Dietary supplements
Cosmetics
OTC medicines
Prescription
pharmaceuticals
Biological and
biopharmaceuticals
Blood processing and
products
Medical devices
Requirement for process validation on effective controls at
critical points, andequipment maintenance. Computer
validation is recommended.
Requirement for process characterization and equipment
maintenance. Computer validation is recommended.
Requirement for computer validation.
Process and computer validation is required.
Process and computer validation is required for medical device
and its production.
U.S. Code of Federal Regulations 21 CFR Part 110, and EU Directive
93/43/EEC
U.S. Code of Federal Regulation 21 CFR Part 111, 113 and 114), and EU
Directive 2002/46/EC
COLIPA and U.S. Code of Federal Regulation 21 CFR Part 700, 701, 710,
720, and 740)
U.S. Code of Federal Regulation 21 CFR Part 210 and 211, and EU
Directive 2003/94/EEC
U.S. Code of Federal Regulation 21 CFR Part 210 and 211, and EU
U.S. Code of Federal Regulation 21 CFR Part 600, 606, and 610, and EU
U.S. Code of Federal Regulation 21 CFR Parts 800 and 820, EU Directive
2005/ 02/EEC
U.S. Code of Federal Regulations 21 CFR Part 820 (Quality Systems
Regulation), and EU 2007/47EEC coupled with CE marking.

8
Food & Drug Administration (FDA)
 FDA 21 CFR 11 ELECTRONIC RECORD; ELECTRONIC SIGNATURES
 Subpart B‐ Electronic Records, Sec. 11.10 Controls for closed systems.
 Persons who use closed systems to create, modify, maintain, or transmit electronic records shall employ procedures and
controls designed to ensure the authenticity, integrity, and, when appropriate, the confidentiality of electronic records, and to
ensure that the signer cannot readily repudiate the signed record as not genuine. Such procedures and controls shall include
the following:
 (a) Validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or
altered records.
 21 CFR 820 QUALITY SYSTEM REGULATION
 Subpart C- Design Controls, Sec. 820.30(g)
 Design validation- Each manufacturer shall establish and maintain procedures for validating the device design. Design
validation shall be performed under defined operating conditions on initial production units, lots, or batches, or their
equivalents. Design validation shall ensure that devices conform to defined user needs and intended uses and shall include
testing of production units under actual or simulated use conditions. Design validation shall include software validation and
risk analysis, where appropriate. The results of the design validation, including identification of the design, method(s), the
date, and the individual(s) performing the validation, shall be documented in the DHF.
USA

9
 21 CFR 820 QUALITY SYSTEM REGULATION
 Subpart G- Production and Process Controls, Sec. 820.70
 (g) Equipment- Each manufacturer shall ensure that all equipment used in the manufacturing process meets specified
requirements and is appropriately designed, constructed, placed, and installed to facilitate maintenance, adjustment,
cleaning, and use.
 (i) Automated processes- When computers or automated data processing systems are used as part of production or the
quality system, the manufacturer shall validate computer software for its intended use according to an established protocol.
All software changes shall be validated before approval and issuance. These validation activities and results shall be
documented.
 FDA 21 CFR 211 CURRENT GOOD MANUFACTURING PRACTICE FOR FINISHED PHARMACEUTICALS
 Subpart D‐‐Equipment, Sec. 211.68
 (a) Automatic, mechanical, or electronic equipment or other types of equipment, including computers, or related systems that
will perform a function satisfactorily, may be used in the manufacture, processing, packing, and holding of a drug product. If
such equipment is so used, it shall be routinely calibrated, inspected, or checked according to a written program designed to
assure proper performance. Written records of those calibration checks and inspections shall be maintained.
 (b) Appropriate controls shall be exercised over computer or related systems to assure that changes in master production and
control records or other records are instituted only by authorized personnel. Input to and output from the computer or
related system of formulas or other records or data shall be checked for accuracy. The degree and frequency of input/output
verification shall be based on the complexity and reliability of the computer or related system.
USA

10
 21 CFR 1271 HUMAN CELLS, TISSUES, AND CELLULAR AND TISSUE‐BASED PRODUCTS
 Subpart D Current Good Tissue Practice, Sec. 1271.160(d)
 You must validate the performance of computer software for the intended use, and the performance of any changes to that
software for the intended use, if you rely upon the software to comply with core CGTP requirements and if the software either
is custom software or is commercially available software that has been customized or programmed (including software
programmed to perform a user defined calculation or table) to perform a function related to core CGTP requirements.
European Commission (EC)
 EC COUNCIL DIRECTIVE 93/42/
 Annex I Essential Requirements
 12.1a- For devices which incorporate software or which are medical software in themselves, the software must be validated
according to the state of the art taking into account the principles of development lifecycle, risk management, validation and
verification.
 EUDRALEX VOLUME 4 GOOD MANUFACTURING PRACTICE, MEDICINAL PRODUCTS FOR HUMAN AND VETERINARY USE
 Annex 11 Computerized Systems
 The application should be validated; IT infrastructure should be qualified.
USA
Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland,
France, Germany, Greece, Hungary, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta,
Netherlands, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, UK

11
Agência Nacional de Vigilância Sanitária
(National Health Surveillance Agency Brazil) ANVISA
 JAPAN’S GUIDELINE ON MANAGEMENT OF COMPUTERIZED SYSTEMS FOR MARKETING AUTHORIZATION HOLDERS AND
MANUFACTURERS OF DRUGS AND QUASI‐DRUGS
 “Standards for Manufacturing Control and Quality Control for Drugs and Quasi‐drugs” - by -specifying the necessary matters
during development of computerized systems, the validation items to verify such systems, -in order to ensure such systems
function as intended.
PHARMACEUTICALS & MEDICAL DEVICES AGENCY (PMDA)
 BRAZILIAN ANVS GOOD PRACTICES OF MEDICAMENT MANUFACTURING
 Title VIII Good Phytotherapic Medicaments Manufacture Practices, Chapter IV Validation, Art. 18.
 Any aspect of operation, including significant changes in the facilities, location, computer systems, equipment or processes
that can affect product quality, directly or indirectly, must be qualified and / or validated.
 Title VII, Computer Information Systems, Art. 573 Validation shall be considered part of the computer system’s life cycle, which
includes the planning, specification, scheduling, test, documentation, operation, monitoring, maintenance and change stages.
Brazil
Japan

12
INTERNATIONAL CONFERENCE ON HARMONISATION
(ICH)
 ICH Q7A, GOOD MANUFACTURING PRACTICE FOR ACTIVE PHARMACEUTICAL INGREDIENTS
 GMP related computerized systems should be validated. The depth and scope of validation depends on the diversity,
complexity, and criticality of the computerized application.
 ICH E6 Good Clinical Practice
 When using electronic trial data handling and/or remote electronic trial data systems, the sponsor should: Ensure and
document that the electronic data processing system(s) conforms to the sponsor’s established requirements for
completeness, accuracy, reliability, and consistent intended performance (i.e. validation)
PHARMACEUTICAL INSPECTION CO-OPERATION SCHEME
(PIC/S)
 GOOD PRACTICES FOR COMPUTERISED SYSTEMS IN REGULATED “GXP” ENVIRONMENTS
 (4.9) The regulated user should be able to demonstrate through the validation evidence that they have a high level of
confidence in the integrity of both the processes executed within the controlling computer system and in those processes
controlled by the computer system within the prescribed operating environment.
 (4.11) The regulated users of the system have the ultimate responsibility for ensuring that documented validation evidence is
available to GxP inspectors for review.
 (23.13) The lack of a written detailed description of each system, (kept up-to-date with controls over changes), its functions,
security and interactions (A11.4); a lack of evidence for the quality assurance of the software development process (A11.5),
coupled with a lack of adequate validation evidence to support the use of GMP related automated systems may very well be
either a critical or a major deficiency.
USA, Canada, EU, Japan
USA, Canada, Most of EU countries, Japan, Russia,
Australia etc.

13
World Health Organization (WHO)
 WHO, APPENDIX 5: VALIDATION OF COMPUTERIZED SYSTEMS
 (1.1) Computer systems should be validated at the level appropriate for their use and application. This is of importance in
production as well as in quality control.
 (7.2.5) Software validation should provide assurance that computer programs (especially those that control manufacturing
and processing) will consistently perform as they are supposed to, within pre-established limits.

Inspection Analysis
14
The potential causes of compliance failure are as follows:
 Inadequate validation planning
 Inadequate definition of what constitutes the computer system.
 Lack of clearly defined acceptance criteria.
 Inadequate specification of the software (e.g., user requirements, functional specification).
 Software does not meet specification.
 The source code for the software is not available.
 The computer hardware or operating environment differs from the specification.
 IT infrastructure, operating environment not considered during planning.
 Users fail to follow operating procedures or instructions.
 The system has been inadequately tested, or the testing has been inadequately documented.
 SOPs for development, maintenance, operation, administration, data management of the system are
inadequate.
 Business continuity procedures are inadequate.
 Data backup, archival/ retrieval procedures are inadequate.
 Roles, responsibilities and frequency for audit trial review, periodic review, user management review, internal
audit etc. not clearly defined.

15
 System developers/ users/administrators are not properly qualified,
trained or competent.
 Documentary evidence to demonstrate qualification, training and
competence level of personnel involved with the system is not
available.
 Documentation for all or part of the validation does not exist, or cannot
be located.
 Evidence of review and approval of compliance documentation by
qualified staff is not available.
 Inadequate change control over any element of the system (i.e.,
hardware, software, procedures, people).
 Revalidation is not adequate, risk assessment is not performed for
software/ hardware upgrade/ modification/ reconfiguration/part
replacement/ relocation.
 Inadequate procedure for preventive and/ or breakdown maintenance.
 Risk assessment not performed during system classification/ validation
planning/ use of supplier documentation/ vendor assessment/ defect
management/ change management/ configuration management/
system relocation/ data migration/ system retirement.
27%
8%
27%
8%
30%
Analytical Laboratory
Systems
Spreadsheets &
Databases
Network &
Infrastructure
Corporate IT
Systems
Process Control
Systems
FDA observations by type of computer system
Inspection Analysis

16
0
5
10
15
20
25
30
VALIDATION
PLANNING & RISK
MANAGEMENT
SYSTEM
SPECIFICATION &
SUPPLIER
SELECTION
DESIGN &
DEVELOPMENT
SYSTEM BUILT DEVELOPMENT
TESTING
USER
QUALIFICATION &
AUTHORITY TO
USE
OPERATION &
MAINTENANCE
PHASE OUT &
WITHDRWAL
FDA Observation by Life Cycle Phases
Inspection Analysis

Phases and associated deliverables of system life cycle
17
Phases Associated Deliverables
High Level
Classification
Supplier Assessment URS CSV Risk Assessment
Validation Plan Test Plan
Functional
Specification
Design Specification
Configuration
Specification
Quality Review
Test Specification
Test Result
Test Summary Report
Traceability Matrix
Validation Report
System Administration
Procedures
End User
Documentation
Operational & Maintenance
Procedures
System Retirement Plan System Retirement Report
GxP Applicability
Supplier Assessment Risk Assessment
Requirement Identification
Validation Planning & Approach
Specification
Design Review
Test Execution & Reporting
Validation Reporting & System Release
System Operation & Maintenance
System Decommissioning
Project
Operation
Retirement
Concept

Supporting process within software life cycle
18
 Periodic Revalidation
 Change Control
 System Administration
 Revalidation
 Incident Management
 Maintenance
Management
 Data Management
 Calibration
 HLRA
 Validation Plan
 System Overview
 User Requirement
 Functional Requirements
 Software Requirements
 Hardware Requirements
 Business Requirements
 Maintenance Requirements
 Applicable code, Standards
requirements
 Functional Specification
 Software Specification
 Hardware Specification
 Programming Standards
 Source Code
 Quality Review Report
 SLA
 Configuration Specification
 Test Plan
 Test Protocol (IQ, OQ, PQ)
 Test Result & Evidences
 Test Report (IQ, OQ, PQ)
 Test Defects
 Validation Summary Report
 System Release Certificate
 System operation, management,
maintenance procedures
 User Documents
 Quality Instructions
 User Training & Assessment
 System Inventory
 Calibration, Maintenance,
Periodic Review Schedules
 Data Migration Plan
 Data Migration Report
 Decommissioning Plan
 Decommissioning
Report
 Controlled Shutdown
 Project Team/
Business
 Change Request
Replacement
Withdrawal

Role based activities for CSV
19
User Requirement
Specification
System Overview
Pre Delivery
Inspection
User Qualification
Compliance
Determination
GxP Assessment
Supplier
Assessment
Validation Master
Plan
Validation
Summary
Report
System Owner/
User
Developer
Quality &
Compliance
Supplier Selection Design Review
Contract of
Supply
Design &
Development
Coding
Configuration
Development
Testing
ERES Review
Source Code
Review

Phase wise CSV deliverables
20
 COMPUTER SYSTEM LIFE CYCLE PHASES:
SLC
Concept
Project
Operation
Retirement
The computer system life cycle consist of four phases:
Concept
Project
Operation
Retirement
• The Concept Phase is the development of the business case.
• Some of the system lifecycle deliverables relevant to validation may be
generated in this phase such as Initial System Risk Assessment and draft
User Requirements.
• High Level Risk Assessment categories system as GxP/ Non- GxP, it further
categories system as personal information relevant, business criticality.
• This risk assessment is likely to focus on important risks to GxP and to the
business process, rather than detailed functions and technical aspects.
Concept

21
Planning
Specification
Code, Built & Configure
Testing
Reporting & Release
• Planning Shall cover activities, responsibilities, procedures.
• Deliverables in this phase are Validation Plan & Data Migration Plan
 VP must be produced for all systems,
describing how it is to be validated, and
the approach for maintaining the
validated state during operation.
 VP shall have details like- High level
system overview, applicable procedures,
regulations, life cycle deliverables roles
and responsibilities, supplier
documentation to be used, test
environments, acceptance criteria for
system go live, procedures and plans to
maintain system in validated state etc.
Validation Plan (VP)
Deliverables
 Requirement of such plan is based on
risk assessment, it is required to transfer
application or its data to new flatform,
during data conversion at the time of
system upgradation, replacing existing
system with new system
Migration Plan (MP)

22
Planning
Specification
Testing
Reporting & Release
• Specifications must be approved and maintained throughout the life cycle
 URS must be available for each GxP
System, it shall consist of user,
technical, functional, regulatory,
interface, maintenance, data,
security requirements.
 User Requirements must be written
in clear, precise, and unambiguous
language.
 Requirements must be individual
and unique, verifiable, consistent,
complete, and structured and
uniquely labelled to facilitate
traceability.
 User requirements must be
approved before the start of formal
verification/qualification activities.
 It should be prepared by user,
reviewed by user manager and
Cross functional team and approved
by quality.
User Requirement Specification
(URS)
Deliverables
 It defines what
system should do
and what functions
and facilities are to
be provided.
 Formal testing will
often be based on
the FS.
 It shall consist of
system functionality,
input/ output, critical
calculations, critical
variables, Safety &
security, errors,
alarms, interlocks
etc.
 The FS shall produce
by supplier and
approved by the
regulated company.
Functional
Specification (FS)
 It should be provided
for configured
products and cover
the appropriate
configuration of the
software products
that comprise the
system to meet
specified
requirements.
 This includes the
definition of all
settings and
parameters.
 Shall produced by the
supplier and
reviewed and
approved by
regulated Company
SMEs.
Configuration
Specification (CS)
 Custom applications
require design of hardware
and software.
 Hardware design defines
the hardware components
of a system, e.g., system or
component architecture,
or interfaces.
 S/w design at higher level
defines s/w modules that
will form complete s/w
system, interfaces
between modules and
with external systems and
module operation at lower
level.
 Shall produced by the
supplier and reviewed and
approved by regulated
company SMEs.
Design Specification (DS)

23
Planning
Specification
Testing
Reporting & Release
• When code is written, program coding standard must be defined.
• Code subjecting GxP functionality are subject to document review.
• Code reviews shall be conducted and documented by SMEs within the organization developing
the solution.
• Code review should include confirmation of conformance of the code to:
 Coding standards & Relevant specifications, such as design specifications
 Quality Review Report shall consist of documented
verification of coding standard.
 The extent of such reviews must be based upon risk
to patient safety, product quality, and data integrity,
as well as system category and complexity.
 The review must take place before acceptance
testing of the software commences.
Quality Review Report
Deliverables
 Complex computerized systems, its ancillary
equipment or sub-system requires formal documented
commissioning process prior to the commencement of
testing.
 Testing must demonstrate that computerized system
has been installed as per the supplier’s approved
drawings and specifications and that it is safe for
testing and qualification phase to commence.
Commissioning Report

24
Planning
Specification
Testing
Reporting & Release
Test Protocol/
Specification
Test Reports
Test Cases Test Scripts Test Results
Test Plan/
Strategy
Test Summary
Report
Typical Structure for Testing Documentation
Installation
Qualification (IQ)
Operational
Qualification (OQ)
Performance
Qualification (PQ)

25
Planning
Specification
Testing
Reporting & Release
Installation
Qualification (IQ)
Operational
Qualification (OQ)
Performance
Qualification (PQ)
 IQ is the installation verification of the configuration of the
hardware and software components of the system and related
documentation. It include the installation protocol and its
execution.
 The IQ shall document but not be limited to:
 Verification that the hardware and software is installed as per the
pre approved design specification and system configuration
baseline, where applicable, verification of the vendor supplied
system documentation (i.e. recipes, manuals, certifications,
licenses, etc.)
 Any deviations and changes from the pre-approved protocol must
be adequately documented, resolved approved by the various
functions with quality related input and reported accordingly
during the project lifecycle phase.
 Documentation typically consists of a protocol and an execution
record, installation records provided by the supplier, log files or
other evidence of success from an automated installation script,
or a combination of these.
Installation Qualification (IQ)

26
Planning
Specification
Testing
Reporting & Release
Installation
Qualification (IQ)
Operational
Qualification (OQ)
Performance
Qualification (PQ)
 The purpose of functional / configuration testing, commonly known as the
Operational Qualification (OQ) is to test the functionality of the system during
its normal use, with
 particular attention to the testing of functions which impact critical data.
 Challenge, stress and security tests will also be executed with the result of the
Functional Risk Assessment being considered to determine the extent of OQ
tests.
 If system mange data in electronic form and having electronic signature then
21 CFR part 11 requirement verification is required.
 Typical verifications includes:
 Power failure testing
 System access and security features
 Audit trails and logging of critical actions including manual interactions
 Manual data entry features, input validation
 Electronic signature features
 Alarms and error messages
 Critical calculations
 Critical transactions
 Transfer of critical data into other packages or systems for further
processing
 Interfaces and data transfers
 Backup and restore
 Data archival and retrieval
 Ability to deal with high volume loads especially if the system is accessed
by many users as part of a network application
Functional/ Configuration Testing/ Operational Qualification (OQ)

27
Planning
Specification
Testing
Reporting & Release
Installation
Qualification (IQ)
Operational
Qualification (OQ)
Performance
Qualification (PQ)
 Performance Qualification (PQ) is to verify that the system operates as
described within the User Requirements Specification.
 The test data sets are realistic simulation of production data and the test
environment is mimic the production environment as closely as possible.
 Any differences between the test and production environments needs to be
documented
 The following are typically challenged/confirmed:
 End to end business processes based on user requirements
 Interfaces to other systems and any direct input/output
 Business report generation
 Data life cycle management including data integrity (if not challenged in OQ)
 Interfaces with other systems if not checked during OQ.
 Any conditions triggering alarms that could not be challenged during OQ
testing.
 Ideally PQ needs to be performed by production persons in production
environment.
User Acceptance Testing (UAT)/ Performance Qualification (PQ)

28
Test Protocol/ Specification
• Test specifications are sets of test scripts that are suited for a
specific purpose at a specific phase in a project.
• It should cover- responsibility, scope, s/w under test, purpose,
methods, pre-requisite, environment, tools, required
documentation, review & approval
Test Reports
Test reports normally contain:
 introduction
 scope of testing
 organization of testing
 who performed and who reviewed
the testing
Test Cases
Separate test cases may be
prepared for some tests, which
may describe complex test data
sets, test methods, test input
data, test environment set-up,
and expected results.
Test Scripts
• Test scripts must document the instructions for executing
testing. Must be described in sufficient detail to enable
consistent repetition of the test.
• Test Script should include- unique reference number, cross
reference to controlling specification, test title, description,
test steps, acceptance criteria, pre test step, data to be
recorded, post test step etc.
Test Results
It should include details like passed tests, failed
tests, test failure records, test reports and any
supporting documentary evidence required by
the tests, such as printouts, screen shots, notes,
and pictures, tester & reviewer
identification
Test Plan/ Strategy
• The Test Strategy (also referred to as a Test Plan) must document the overall
approach to testing a system. It must be based on risk and complexity.
• It should cover roles and responsibilities related to creation & approval of test
scripts, test execution roles, approval of testing.
• It shall also include procedure for defect management occurred during testing,
test environment, pre-requisite, dependencies, sequencing, supplier document
reference etc.
Test Summary Report
• Shall summarizes activities & findings and state the final conclusion.
• Approval of the report constitutes the formal release of entities for
subsequent life cycle steps (e.g., proceed to the next phase of testing)
Typical Structure for Testing Documentation

29
Planning
Specification
Testing
Reporting & Release
• The system must be accepted for use in the operating environment and released into that environment
in accordance with a controlled and documented process, it consist of validation summary report and
system release certificate or decision to release system can be included in validation summary report.
 It should summarize the activities performed, any
deviations from the validation plan, any outstanding and
corrective actions, and a statement of fitness for
intended use of the system.
 The report should be approved, as a minimum, by the
process owner and the Quality Unit.
 It shall also include:
purpose and scope of the report
who created the report, and under what authority
summary of approach adopted
Cross reference to controlling plans, policies, or
procedures
Summary of deliverables
Summary of deviations & corrective actions
Statement of fitness for intended use
Training
Maintaining Compliance and Fitness for Intended Use
Requirement Traceability Matrix
(RTM)
Deliverables
 It shall consist of:
 Statement of
fitness for
intended use
 Decision for
release of system
for intended use.
System Release
Certificate
 Traceability is establishing link
between specifications and test
documents.
 Traceability provides a method to
ensure that all applicable
elements of specification,
including requirements, have been
verified.
 It also enables easier
documentation identification
during regulatory inspection.
 Traceability ensures that
requirements are met and can be
traced to the appropriate
configuration or design elements.
Validation Summary Report (VSR)

30
Operation
Archival &
Retrieval
Data Migration
Performance
Monitoring
Incident
Management
CAPA
Change &
Configuration
Management
Repair
Periodic Review
Backup & Restore
Business
Continuity
Management
User & Security
Management
System
Administration

Operation
Archival &
Retrieval
Data Migration
Performance
Monitoring
Incident
Management
CAPA
Change &
Configuration
Management
Repair
Periodic Review
Backup &
Restore
Business
Continuity
Management
User & Security
Management
System
Administration
31
• Performance monitoring is a part of overall preventive
maintenance that obtains performance data that is
useful in diagnosing system problems.
• It is useful during change management to support risk
assessment and at the time of periodic review.
• Performance monitoring may be an automatic or manual
process and shall be based on risk, complexity & novelty
of system.
• Parameters to be monitor includes:
 System utilization
 Error messages
 No of users
 Response Time
 Notification Mechanisms
• Monitoring plan shall include schedule, interval,
parameters, acceptance criteria etc.
Performance Monitoring
Review &
Evaluate
Define
Monitoring
Plan
Execution
Performance
Monitoring
Risk
Assessment

Operation
Data Migration
Performance
Monitoring
Incident
Management
CAPA
Change &
Configuration
Management
Repair
Periodic
Review
Backup &
Restore
Business
Continuity
Management
User &
Security
Management
Archival &
Retrieval
• The incident management process should ensure that operational
events which are not part of the standard operation (i.e., issues,
problems, and errors) are identified, evaluated, resolved, and closed
in a timely manner.
• Incidents should be trended over time to identify and understand
possible systemic issues and root causes.
• Incident Management records should be subject to periodic internal
audits.
• When an incident occurs that requires remedial action a record
must be created describing clearly details of the incident and what
action is taken to remediate it.
• If the incident require investigation and root cause analysis, a
problem record must be created and if required CAPA must be
developed. Where incident management triggers a change to a
validated system the change records and incident/problem records
must be cross-referenced. The incidents which have GxP impact
shall be cross-referenced to the deviation records. These activities
must be documented. SME must evaluate incidents and those
identified as having impact on patient safety, product quality and
data integrity must be handled via the deviation process.
Incident Management
32
Incident
Closeout
Evaluate
Incident
Resolve
Identify & log
incident

Operation
Performance
Monitoring
Incident
Management
CAPA
Change &
Configuration
Management
Repair
Periodic
Review
Backup &
Restore
Business
Continuity
Management
User &
Security
Management
Archival &
Retrieval
Data Migration
33
• Corrective and Preventive Action (CAPA) is a process for investigating,
understanding, and correcting discrepancies while attempting to prevent
their recurrence, and for recognizing potential discrepancies to prevent
their occurrence.
• The CAPA process is closely associated with the Incident Management
process and the Repair process.
• CAPA process should cover corrections of an identified problem, root
cause analysis with corrective action to help understand the cause of the
deviation and preventive action to potentially prevent recurrence of a
similar problem.
• A procedure should be established to record and analyze incidents and to
enable corrective action to be taken.
Corrective and Preventive Action (CAPA)
Determine
Preventive
Action
Determine
Corrective
Action
Root Cause
Analysis
Identify & log
problems
Document
Outcome
Effectiveness
Check

Operation
Performance
Monitoring
Incident
Management
CAPA
Change &
Configuration
Management
Repair
Periodic
Review
Backup &
Restore
Business
Continuity
Management
User &
Security
Management
Archival &
Retrieval
Data Migration
• A formalized change control process and procedure must be
implemented to maintain control over all the components of
the computerized equipment including but not limited to:
documentation
software, including patch management
hardware/equipment/instrument
operating environment
 All changes should be reviewed, impact and risk assessed,
authorized, documented, tested, and approved before
implementation. These activities should be documented.
 Patch management is a subset of change management. A
risk assessment is required to determine if and how the
patch will be applied.
 Emergency change control can be initiated when an
unexpected need arises for a change and there is not
sufficient time to gather all approvals without a significant
risk to patient safety, product quality, data integrity.
 A documented configuration management process must be
in place for the respective environments so that the system
could be restored to its current configuration if necessary.
Change & Configuration Management
34
Develop
Impact
Assessment
Decision
Proposal for
Change
Test
Close
Approve &
Implement

Operation
Incident
Management
CAPA
Change &
Configuration
Management
Repair
Periodic
Review
Backup &
Restore
Business
Continuity
Management
User &
Security
Management
Archival &
Retrieval
Data Migration
Performance
Monitoring
• Repair is the process of managing repair or replacement of a failed or
defective component, which may be a configuration Item. It is a form
of change control in which the relevant specifications do not change.
• Where the failure (or the repair) could impact patient safety, product
quality, or data integrity then the incident management process
should be initiated.
• Repair or replacement records should be subject to periodic internal
audits and their review should be part of the performance monitoring
process.
Repair
35
Make Repair or
Replace
Impact Assessment
Evaluate &
Determine Action
Identify Failure
Verify Replace or
Replacement
Return to Use
(Implement)

Operation
CAPA
Change &
Configuration
Management
Repair
Periodic
Review
Backup &
Restore
Business
Continuity
Management
User &
Security
Management
Archival &
Retrieval
Data Migration
Performance
Monitoring
Incident
Management
• Periodic reviews are used throughout the operational life of a
computerized system to verify that it remains compliant with
regulatory requirements, fit for intended use, and satisfies
company policies and procedures. The review should confirm
that, for all components of a system, the required support
and maintenance processes are established and that the
expected regulatory controls (plans, procedures and records)
are established and in use.
• A process for timing and scheduling of reviews should be
defined. Review periods for specific systems should be based
on system impact, complexity, and novelty.
• Review shall include:
 documentation for the system
 Operation & maintenance SOPs
 configuration management information
 change management information
 incident logs
 security and access control information
 any prior audits of individual systems
 Validation Report
Periodic Review
36
Document
Results of Review
Prepare for
Review
Perform Review
Define Procedure
for Plan &
Schedule
Perform
Corrective Action

Operation
Change &
Configuration
Management
Repair
Periodic
Review
Backup &
Restore
Business
Continuity
Management
User &
Security
Management
Archival &
Retrieval
Data Migration
Performance
Monitoring
Incident
Management
CAPA
• Backup is the process of copying records, data and software
to protect against loss of integrity or availability of the
original. Restore is the subsequent restoration of records,
data or software when required.
• Procedures should be established to cover routine back-up of
records, data, and software to a safe storage location,
adequately separated from the primary storage location, and
at a frequency based on risk.
• There should be written procedures for recovery following a
breakdown to ensure documented restoration and
maintenance of GxP records and data.
• The back-up procedure, storage facilities, and media used
should ensure integrity. There should be a backup log with
references to the media used for storage. The media used
should be documented and justified for reliability.
• Backup processes should be verified when they are
established. In addition, there should be procedures and
plans for regular testing of backup and restore capability.
• Backup is applicable for software and data.
Backup & Restore
37
Define Test Plans &
Procedure
Define Strategy
Develop Backup &
Restore Procedure
Risk Assessment
Perform Testing
Perform Backups
following Procedure
Monitor

Operation
Repair
Periodic
Review
Backup &
Restore
Business
Continuity
Management
User &
Security
Management
Archival &
Retrieval
Data Migration
Performance
Monitoring
Incident
Management
CAPA
Change &
Configuration
Management • Business continuity management encompasses the steps required
to restore business processes following a disruption while
continuing to provide product or services to the customer. It
includes steps often described as Disaster Recovery (DR).
• The regulated company should perform business continuity
planning to actively protect its ability to continue to supply the
public, and to comply with the regulatory requirements.
• The BCP should include a clear process for prioritizing system
restore as the disruption may involve failure or unavailability of
multiple systems which may be within or outside the regulated
company.
• The time required to bring the alternative arrangements into use
must be based on risk and appropriate for a particular system and
the business process it supports. These arrangements must be
adequately documented and tested.
Business Continuity Management
38
Develop BCP
Risk Assessment &
Evaluation
Define Business
Continuity Strategies
Initiation
Implement BCP
Maintaining &
Rehearsing

Operation
Periodic
Review
Backup &
Restore
Business
Continuity
Management
User &
Security
Management
Archival &
Retrieval
Data Migration
Performance
Monitoring
Incident
Management
CAPA
Change &
Configuration
Management
Repair
Define
Security
Policies
• Physical and/or logical controls must be in place to
restrict access to computerized system to authorized
persons. These controls must be documented and
approved. Security measures must be implemented to
ensure that only authorized individuals may access the
computerized system as well as the related data, and
that the data are accurate and available when needed.
Security includes both physical security and logical
security.
• Security measures includes- access control, password
policies, auto log out, lockout, security incident
reporting, physical security, third party access,
internet access and use, use of antivirus.
• Role-based security must be implemented, based on
risk, to ensure that sensitive data and functions are
not compromised. Personnel with a potential conflict
of interest must not be granted administrative rights
that would enable them to modify GxP data or the
configuration of GxP applications. Where date and or
time is associated with events, transactions, reports,
etc., system clocks must be protected.
User & Security Management
39
Access
System
Security
Define
Access
Rights
Test
Security
Controls
Verify
Access
Rights
Test
Security
Controls
Define User
Access
Procedure
Authenticate
User to User
Account
Role Specific
User Training
Approve
Access Rights
Review
Access Rights
System Process User Process
Operation
Project

Operation
Backup &
Restore Business
Continuity
Management
User &
Security
Management
Archival &
Retrieval
Data Migration
Performance
Monitoring
Incident
Management
CAPA
Change &
Configuration
Management
Repair
Periodic
Review
• Archiving is the process of taking records and data off-line
by moving them to a different location or system, often
protecting them against further changes.
• If data is archived, it must be checked for accessibility,
readability and integrity. If relevant changes are to be
made to the system, then the ability to retrieve the data
must be ensured and tested.
• Whenever a system is decommissioned or data is archived
a decision must be made as to how the data will be
managed. If the data is not maintained online or migrated
then it must be archived. The selection of any option
other than fully processed records must be based on a
documented risk assessment. When archived data
reaches the end of the retention period, the data owner
must decide whether to destroy it as per the or extend
the retention period.
• A decision to extend retention must have a documented
justification. Retention samples/reference samples, raw
data, laboratory records and reports must be securely
stored as per the respective retention periods with timely
access to the records throughout the retention period.
Archival & Retrieval
40
SystemLifecycle
Identify GxP
Records & Data
Define
Retention Policy
Define Archive
Strategy
Implement
Archive Strategy
Verify Archiving
Activity
Refresh
Monitor Ongoing
Availability
Record
Destruction
Design &
Test
Implement
System
Operational
Phase &
Eventual
Retirement
Define System
Requirements

Operation
Business
Continuity
Management User &
Security
Management
Archival &
Retrieval
Data
Migration
Performance
Monitoring
Incident
Management
CAPA
Change &
Configuration
Management
Repair
Periodic
Review
Backup &
Restore
• Data migration is the activity of transporting electronic data
from one system to another, or simply the transition of data
from one state to another.
• Data migration may take place multiple times during the life
cycle of a single computerized system, e.g.:
• during initial system development and deployment
• during application upgrades
• during system retirement
• Migration of electronic data in the regulated environment
should be performed under change control.
• The migration activities and results must be documented. For
large migration initiatives it is recommended that the
activities will be documented within a Migration Report.
Where the Migration Report has not been produced the
migration activities must be documented in a separate
document (maybe the Validation Report) with the results
being independently reviewed and approved.
Data Migration
41
Data Modification
Data Migration Plan
Data Extraction
Risk Assessment
Data Loading on
Another System
Data Verification &
Reporting

42
 The system retirement process should be
documented in a system retirement plan, which
typically should receive input from functions,
such as process owner, Quality Unit, system
owner, and IT. Inputs to the planning process may
include:
 record retention and destruction requirements
for historic data or records
 identification of the current software and
hardware configuration as well as interfaced
systems, equipment or instruments
 identification of any external systems that rely on
data or records from the system
 The plan should identify which data should be
migrated, archived, or destroyed, and the
associated approval process.
 Formal change management procedures should
be followed for the retirement of a computerized
system to ensure the retirement process is
controlled and managed using established
procedures for assessing change impacts.
 Affected inventories, procedures, or other
documentation should be updated
Retirement Plan
Retirement Report
 After the system retirement plan
is executed, a summary report
should be created to describe the
execution and the results.
 If testing or verification activities
were executed, the results of
these tests should be
summarized and any deviations
should be discussed along with
their resolution.
 This report also may include an
index or registry of all
documentation related to the
retired system and where it is
stored.

43
 Quality Risk Management:
Quality risk management is a systematic process
for the assessment, control, communication and
review of risks to the quality of the drug
(medicinal) product across the product lifecycle.
Risk Assessment: Risk assessment consists of the
identification of hazards and the analysis and
evaluation of risks associated with exposure to
those hazards.
As an aid to clearly defining the risk(s) for risk
assessment purposes, three fundamental
questions are often helpful:
1. What might go wrong?
2. What is the likelihood (probability) it will go
wrong?
3. What are the consequences (severity)?
Initiate Quality Risk Management Process
Risk Assessment
Risk Identification
Risk Analysis
Risk Evaluation
Overview of a typical quality risk management process
Risk Review
Review Events
Output/ Result of Quality Risk Management Process
Risk Control
Risk Reduction
Risk Acceptance
RiskCommunication
RiskManagementTools
Unacceptable
Key Concepts in CSV: Quality Risk Management

44
Risk identification: addresses the “What
might go wrong?” question, including
identifying the possible consequences.
This provides the basis for further steps in
the quality risk management process.
Risk analysis: is the estimation of the risk
associated with the identified hazards. It is
the qualitative or quantitative process of
linking the likelihood of occurrence and
severity of harms. In some risk
management tools, the ability to detect
the harm (detectability) also factors in the
estimation of risk.
Risk evaluation: compares the identified
and analyzed risk against given risk
criteria. Risk evaluations consider the
strength of evidence for all three of the
fundamental questions.
Low
Medium
High
High
Medi
um
Low
High
Medium
Low
1
2
3
High Risk
Priority
Medium Risk
Priority
Low Risk
Priority
Probability
Detectability
RiskClass
Severity
Risk Class 2
Risk Class 3
Risk Class 1
Severity= Impact on patient safety, Product Quality, and Data Integrity (or other harm)
Probability= Like hood of fault occurring
Risk Class= Severity x Probability
Detectability= Like hood that the fault will be noted before harm occurrence
Risk Priority= Risk Class x Detectability
Figure reference GAMP 5

45
Risk control: includes decision making to reduce and/or accept risks. The purpose of risk control is to reduce the
risk to an acceptable level. The amount of effort used for risk control should be proportional to the significance of
the risk. Decision makers might use different processes, including benefit-cost analysis, for understanding the
optimal level of risk control.
Risk control might focus on the following questions:
• Is the risk above an acceptable level?
• What can be done to reduce or eliminate risks?
• What is the appropriate balance among benefits, risks and resources?
• Are new risks introduced as a result of the identified risks being controlled?
Risk reduction: might include actions taken to mitigate the severity and probability of harm. Processes that
improve the detectability of hazards and quality risks might also be used as part of a risk control strategy. The
implementation of risk reduction measures can introduce new risks into the system or increase the significance of
other existing risks. Hence, it might be appropriate to revisit the risk assessment to identify and evaluate any
possible change in risk after implementing a risk reduction process.
Risk acceptance: is a decision to accept risk. Risk acceptance can be a formal decision to accept the residual risk or
it can be a passive decision in which residual risks are not specified. For some types of harms, even the best quality
risk management practices might not entirely eliminate risk. In these circumstances, it might be agreed that an
appropriate quality risk management strategy has been applied and that quality risk is reduced to a specified
(acceptable) level.

46
Risk communication: is the sharing of information about risk and risk management between the decision makers
and others. Parties can communicate at any stage of the risk management process. The output/result of the quality
risk management process should be appropriately communicated and documented.
Risk Review: The output/results of the risk management process should be reviewed to take into account new
knowledge and experience. Once a quality risk management process has been initiated, that process should
continue to be utilized for events that might impact the original quality risk management decision, whether these
events are planned (e.g., results of product review, inspections, audits, change control) or unplanned (e.g., root
cause from failure investigations, recall). The frequency of any review should be based upon the level of risk.
Project
Concept
Planning
Specification
Configuration &/ or
Coding
Verification
Reporting
R1
R2
R3
R3
R4
R5
Operation
Retirement
Changes
Retirement
R6
R6
R7 Potential Retention,
Migration, Destruction
R1: Initial Risk Assessment
R2: Risk- based decisions during planning
R3: Functional Risk Assessments
R4: Risk based decision during test planning
R5: Risk based decision during planning of operational activities
R6: Functional risk assessment in change control
R7: Risk based decision when planning system retirement
Figure reference GAMP 5

47
Yes
Yes
develop system
boundaries
Impact
on
product
quality?
Linked
to DI
System?
No Impact System
GEP
Commissioning
Indirect Impact
System
develop supporting
rationale
Direct Impact
System
Commissioning
& Qualification
GEP &
GMP
No
GEP GMP
High Complexity
High Risk
GAMP Cat 1
GAMP Cat 3
GAMP Cat 4
GAMP Cat 5
Low Complexity
Low Risk
NoofDeliverables
Custom Ladder Logic,
Macros
PLC, LIMS
pH Meter, Balance
OS, NMT
Categories
Software
Perform
Validation
Identify System Perform high level risk
assessment
No

48
Category Description Typical Examples Typical Approach
1
Infrastructure
Software
 Layered software (i.e. upon which applications are
built)
 Software used to manage operating environment
 Operating Systems
 Database Engines
 Programming Languages
 Network Monitor Tools
 Scheduling Tools
 Spreadsheets
 Record current version, verify
correct installation by following
approved installation procedures
3
Non-Configured
 Where existing configurations can be used to suite
business purpose but software can not be configured
as per the requirements
 Firmware based applications
 Customize of the self (COTS)
software
 Instruments
 High Level Risk Assessment
 URS
 Requirement Testing
 Procedures in place for maintaining
compliance and fitness for intended
use.
4
Configured
 Software often complex, that can be configured by the
user to meet the specific needs of user’s business
process. Software code is not altered
 LIMS
 DAS
 SCADA
 ERP
 DCS
 BMS
 HMI
 CDS
 Clinical Trial Monitoring
 HLRA
 URS
 Supplier Assessment
 Functional Specification
 Configuration Specification
 Functional Testing
 Requirement Testing
 Procedures in place for maintaining
compliance and fitness for intended
use and managing data.
SoftwareCategories
Key Concepts in CSV: Software & Hardware Categorization

49
Category Description Typical Examples Typical Approach
5
Custom
 Software custom designed and coded to suit business
process.
 Varies but includes:
 Internally and externally developed
IT applications
 Internally and externally developed
process control applications
 Custom ladder logic
 Custom firmware
 Spreadsheets (macro)
 Record current version, verify
correct installation by following
approved installation procedures
1
Standard
Hardware
Components
 The majority of the hardware used by regulated
companies will fall into this category.
 Standard communication cables
 Standard Relays
 Standard PLCs
 Details should be documented
including manufacturer or supplier
details, and version numbers.
Correct installation and connection
of components should be verified.
The model, version number of pre-
assembled hardware should be
recorded.
2
Custom Built
Hardware
Components
 These requirements are in addition to those of
standard hardware components. Custom items of
hardware should have a Design Specification (DS) and
be subjected to acceptance testing
 All Custom built components
 Design Specification
 Acceptance Testing
Software
Categories
Hardware
CategoriesKey Concepts in CSV: Software & Hardware Categorization

50
S/W Categories:
GAMP 1: Operating System
GAMP 2: Firmware (removed)
GAMP 3: Non- Configured Standard S/W
GAMP 4: Configurable S/W
GAMP 5: Custom Built or Bespoke S/W
Initial Risk
Assessment
URS
Non- Configured
Product
Requirements
Testing
User Testing of
Controls & Procedures
 What are the overall risks to the business?
 System GxP Determination
 What is overall impact of the system?
 Identify risks
 Define control to reduce risks
Consider
Risk- Based Approach for Non-
Configured Product (Cate. 3)
Initial Risk
Assessment
URS
Configured Product
User Testing of
Controls & Procedures
 Are more detailed risk assessments required?
Consider
FS
CS IQ
OQ
PQ
Testing of system
controlsFRS
 Identify risks to specific processes
 Identify risks to specific functions
Identify & Define
Risk- Based Approach for
Configured Product (Cate. 4)
Risk- Based Approach for
Custom Application (Cate. 5)
Initial Risk
Assessment
URS
Code Modules
User Testing of
Controls &
Procedures
 Are more detailed risk assessments required?
Consider
FS
DS IQ
OQ
PQ
Testing of
system controls
FRS
 Identify risks to specific processes
 Identify risks to specific functions
Identify & Define
Module
Specification
Module Testing
Testing of
Design controls
Key Concepts in CSV: Software Categorization

51
Prospective Concurrent Retrospective Revalidation
Establishing
documented
evidence prior to
process
implementation that
a system does what
it proposed to do
based on pre planned
protocols.
New Equipment(s),
Product(s) and
Process(s)
Establishing
documented
evidence that a
processes do what
they purport to do,
based on information
generated during
actual imputation of
the process.
Established
documented
evidence that the
process has
performed
satisfactorily and
consistently over
time, based on
review and historical
data.
This type of
validation is generally
not preferred and
accepted.
Repeating the original
validation effort
fully/partially with
investigative review
of performance data.
This approach is
essential to maintain
the validated status
of the system and
ensuring that changes
made to the process
have not resulted in
adverse effects on
quality or process.
Must Required.
Key Concepts in CSV: Types of Validation

52
Compliance Package:
Deliverables & Records
Software Category
Remark
3 4 5
System Overview X X X Executive introduction to overall system.
Validation Master Plan X X X The scope of a validation plan need not be limited to one system.
For exact replicas of a computer system, the validation plan can
be proceduralized. Reference may be made to the project
quality plans and supplier quality plans if they are separate
documents.
URS X X X Single document, covering whole system.
GxP Assessment X X X For overall system
Supplier Audit Report X X For bespoke and critical COTS-based applications.
Functional Specification X X X For standard COTS packages reference to product specification is
sufficient.
Configuration &/or Design
Specification
X X Configuration only for category 4 software.
Hardware Design For bespoke hardware, otherwise reference standard COTS
hardware documentation.
Design review (including
hazard study)
Typically, covering whole system (sometimes known as design
qualification).
Software category wise deliverables requirement

53
Compliance Package:
Deliverables & Records
Software Category
Remark
3 4 5
Source Code Review X X Executive introduction to overall system.
Unit/module testing X
May be combined as appropriate.
Integration/system testing X
Installation qualification X X X
Documents may be combined as long as test plans and test
cases are collectively approved before testing. For COTS
instrumentation, testing may be based on calibration activities.
Operational qualification X X X
Performance qualification X X X
Operation and maintenance
prerequisites
X X X Activities include user procedures/manuals, maintenance, backup
and restoration, security, training, business continuity plans.
Validation (summary)
report
X X X May be in the form of a certificate for very simple systems.
Software category wise deliverables requirement

54
Principles of Data Integrity:
 The organization needs to take responsibility for the systems used and the data they generate. The
organizational culture should ensure data is complete, consistent and accurate in all its forms, i.e. paper and
electronic.
 Arrangements within an organization with respect to people, systems and facilities should be designed,
operated and, where appropriate, adapted to support a suitable working environment, i.e. creating the right
environment to enable data integrity controls to be effective.
 The impact of organizational culture, the behavior driven by performance indicators, objectives and senior
management behavior on the success of data governance measures should not be underestimated. The data
governance policy (or equivalent) should be endorsed at the highest levels of the organization.
 Organizations are expected to implement, design and operate a documented system that provides an
acceptable state of control based on the data integrity risk with supporting rationale. An example of a suitable
approach is to perform a data integrity risk assessment (DIRA) where the processes that produce data or where
data is obtained are mapped out and each of the formats and their controls are identified and the data
criticality and inherent risks documented.
Regulatory Requirements: MHRA’s GxP Data Integrity Guidance

55
Establishing data criticality and inherent integrity risk:
 Data has varying importance to quality, safety and efficacy decisions. Data criticality may be determined by
considering how the data is used to influence the decisions made.
 The risks to data are determined by the potential to be deleted, amended or excluded without authorization
and the opportunity for detection of those activities and events. The risks to data may be increased by complex,
inconsistent processes with open-ended and subjective outcomes, compared to simple tasks that are
undertaken consistently, are well defined and have a clear objective.
 Data may be generated by:
 Recording on paper, a paper-based record of a manual observation or of an activity or
 electronically, using equipment that range from simple machines through to complex highly configurable
computerized systems or
 by using a hybrid system where both paper-based and electronic records constitute the original record or
 by other means such as photography, imagery, chromatography plates, etc.
Designing systems and processes to assure data integrity; creating the ‘right environment’:
Systems and processes should be designed in a way that facilitates compliance with the principles of data integrity.
Enablers of the desired behavior include but are not limited to:
 At the point of use, having access to appropriately controlled/synchronised clocks for recording timed events to
ensure reconstruction and traceability, knowing and specifying the time zone where this data is used across
multiple sites.

56
 Accessibility of records at locations where activities take place so that informal data recording and later
transcription to official records does not occur.
 Access to blank paper proformas for raw/source data recording should be appropriately controlled.
Reconciliation, or the use of controlled books with numbered pages, may be necessary to prevent recreation of
a record. There may be exceptions such as medical records (GCP) where this is not practical.
 User access rights that prevent (or audit trail, if prevention is not possible) unauthorized data amendments. Use
of external devices or system interfacing methods that eliminate manual data entries and human interaction
with the computerized system, such as barcode scanners, ID card readers, or printers.
 The provision of a work environment (such as adequate space, sufficient time for tasks, and properly
functioning equipment) that permit performance of tasks and recording of data as required.
 Access to original records for staff performing data review activities.
 Reconciliation of controlled print-outs.
 Sufficient training in data integrity principles provided to all appropriate staff (including senior management).
 Inclusion of subject matter experts in the risk assessment process.
 Management oversight of quality metrics relevant to data governance.

57
Definition of terms and interpretation of requirements:
Data: Facts, figures and statistics collected together for reference or analysis. All original records and true copies of
original records, including source data and metadata and all subsequent transformations and reports of these data,
that are generated or recorded at the time of the GXP activity and allow full and complete reconstruction and
evaluation of the GXP activity.
Data should be:
A - attributable to the person generating the data
L – legible and permanent
C – contemporaneous
O – original record (or certified true copy)
A - accurate
Data governance measures should also ensure that data is complete, consistent, enduring and available
throughout the lifecycle, where;
Complete – the data must be whole; a complete set
Consistent - the data must be self-consistent
Enduring – durable; lasting throughout the data lifecycle
Available – readily available for review or inspection purposes

58
Raw data (synonymous with ‘source data’ which is defined in ICH GCP):
Raw data is defined as the original record (data) which can be described as the first-capture of information,
whether recorded on paper or electronically. Information that is originally captured in a dynamic state should
remain available in that state.
Raw data must permit full reconstruction of the activities. Where this has been captured in a dynamic state and
generated electronically, paper copies cannot be considered as ‘raw data’.
Metadata: Metadata are data that describe the attributes of other data and provide context and meaning.
Typically, these are data that describe the structure, data elements, inter-relationships and other characteristics of
data e.g. audit trails. Metadata also permit data to be attributable to an individual (or if automatically generated,
to the original data source).
Metadata form an integral part of the original record. Without the context provided by metadata the data has no
meaning.
Example. 9.1 Kg; Where Kg is metadata which is giving context and meaning to data.
Data Integrity: Data integrity is the degree to which data are complete, consistent, accurate, trustworthy, reliable
and that these characteristics of the data are maintained throughout the data life cycle. The data should be
collected and maintained in a secure manner, so that they are attributable, legible, contemporaneously recorded,
original (or a true copy) and accurate. Assuring data integrity requires appropriate quality and risk management
systems, including adherence to sound scientific principles and good documentation practices.

59
Original Record: The first or source capture of data or information e.g. original paper record of manual observation
or electronic raw data file from a computerized system, and all subsequent data required to fully reconstruct the
conduct of the GXP activity. Original records can be Static or Dynamic.
True Copy: A copy (irrespective of the type of media used) of the original record that has been verified (i.e. by a
dated signature or by generation through a validated process) to have the same information, including data that
describe the context, content, and structure, as the original.
Audit Trial: The audit trail is a form of metadata containing information associated with actions that relate to the
creation, modification or deletion of GXP records. An audit trail provides for secure recording of life-cycle details
such as creation, additions, deletions or alterations of information in a record, either paper or electronic, without
obscuring or overwriting the original record. An audit trail facilitates the reconstruction of the history of such
events relating to the record regardless of its medium, including the “who, what, when and why” of the action.
Audit trails (identified by risk assessment as required) should be switched on. Users should not be able to amend
or switch off the audit trail. Where a system administrator amends, or switches off the audit trail a record of that
action should be retained.

60
Subpart- A: General Provisions
Scope:
 The regulations in this part set forth the criteria under which the agency considers electronic records, electronic
signatures, and handwritten signatures executed to electronic records to be trustworthy, reliable, and generally
equivalent to paper records and handwritten signatures executed on paper.
 This part applies to records in electronic form that are created, modified, maintained, archived, retrieved, or
transmitted, under any records requirements set forth in agency regulations. This part also applies to electronic
records submitted to the agency under requirements of the Federal Food, Drug, and Cosmetic Act and the
Public Health Service Act, even if such records are not specifically identified in agency regulations. However, this
part does not apply to paper records that are, or have been, transmitted by electronic means.
Subpart- B: Electronic Records
 Controls for closed system:
• Validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to
discern invalid or altered records.
• The ability to generate accurate and complete copies of records in both human readable and electronic form
suitable for inspection, review, and copying by the agency.
• Protection of records to enable their accurate and ready retrieval throughout the records retention period.
• Limiting system access to authorized individuals.
• Use of operational system checks
Regulatory Requirements: 21 CFR Part 11

61
• Use of device
• User Training, education and experience
• Procedures and policies for accountability of activities performed by individuals.
• Appropriate controls over system documentation, distribution of, access to, and use of documentation for
system operation and maintenance.
• Revision and change control procedures to maintain an audit trail that documents time-sequenced
development and modification of systems documentation.
 Controls for Open System:
• Persons who use open systems to create, modify, maintain, or transmit electronic records shall employ
procedures and controls designed to ensure the authenticity, integrity, and, as appropriate, the
confidentiality of electronic records from the point of their creation to the point of their receipt. Such
procedures and controls shall include those identified in 11.10, as appropriate, and additional measures such
as document encryption and use of appropriate digital signature standards to ensure, as necessary under the
circumstances, record authenticity, integrity, and confidentiality.

62
 Signature manifestations: Signed electronic records shall contain information associated with the signing that
clearly indicates all of the following:
(1) The printed name of the signer;
(2) The date and time when the signature was executed; and
(3) The meaning (such as review, approval, responsibility, or authorship) associated with the signature.
 Signature/ record linking: Electronic signatures and handwritten signatures executed to electronic records shall
be linked to their respective electronic records to ensure that the signatures cannot be excised, copied, or
otherwise transferred to falsify an electronic record by ordinary means.
Subpart-C: Electronic Signature
 Each electronic signature shall be unique to one individual and shall not be reused by, or reassigned to, anyone
else.
 Before an organization establishes, assigns, certifies, or otherwise sanctions an individual's electronic signature,
or any element of such electronic signature, the organization shall verify the identity of the individual.
 Persons using electronic signatures shall, prior to or at the time of such use, certify to the agency that the
electronic signatures in their system, used on or after August 20, 1997, are intended to be the legally binding
equivalent of traditional handwritten signatures.
 Electronic signature components and controls:
Electronic signatures that are not based upon biometrics shall:
(1) Employ at least two distinct identification components such as an identification code and password.

63
(1)Employ at least two distinct identification components such as an identification code and password.
(i) When an individual executes a series of signings during a single, continuous period of controlled system
access, the first signing shall be executed using all electronic signature components; subsequent signings shall
be executed using at least one electronic signature component that is only executable by, and designed to be
used only by, the individual.
(ii) When an individual executes one or more signings not performed during a single, continuous period of
controlled system access, each signing shall be executed using all of the electronic signature components.
(2) Be used only by their genuine owners; and
(3) Be administered and executed to ensure that attempted use of an individual's electronic signature by
anyone other than its genuine owner requires collaboration of two or more individuals.
(b) Electronic signatures based upon biometrics shall be designed to ensure that they cannot be used by
anyone other than their genuine owners.
 Controls for identification codes/passwords:
Persons who use electronic signatures based upon use of identification codes in combination with passwords
shall employ controls to ensure their security and integrity. Such controls shall include:
(a) Maintaining the uniqueness of each combined identification code and password, such that no two
individuals have the same combination of identification code and password.

64
(b) Ensuring that identification code and password issuances are periodically checked, recalled, or revised (e.g.,
to cover such events as password aging).
(c) Following loss management procedures to electronically deauthorize lost, stolen, missing, or otherwise
potentially compromised tokens, cards, and other devices that bear or generate identification code or
password information, and to issue temporary or permanent replacements using suitable, rigorous controls.
(d) Use of transaction safeguards to prevent unauthorized use of passwords and/or identification codes, and to
detect and report in an immediate and urgent manner any attempts at their unauthorized use to the system
security unit, and, as appropriate, to organizational management.
(e) Initial and periodic testing of devices, such as tokens or cards, that bear or generate identification code or
password information to ensure that they function properly and have not been altered in an unauthorized
manner.

65
Scope:
The scope of the document is broad, covering necessary steps and the documentation needed for the
implementation and validation of a computerized system. Management of such projects requires the linking2 of
important aspects of management policies, documentation and record systems embracing the respective
professional disciplines involved in the development and use of the
computerised system.
Computerized systems may simplistically be considered to exist as three main application types, i.e.: process
control systems, data processing systems, (including data collection/capture) and data record/ storage systems.
There may be links between these three types of system, described as ‘interfaces’.
Implementation of Computerized Systems:
The assurance of the reliability of a Supplier’s software products is attributable to the quality of the software
engineering processes followed during development. This should include design, coding, verification testing,
integration, and change control features of the development life cycle, (including after sales support). In order for
customers to have confidence in the reliability of the products, they should evaluate the quality methodology of
the supplier for the design, construction, supply and maintenance of the software. A formal, extensive review of
the history of the Supply Company and the software package may be an option to consider where an additional
degree of assurance of the reliability of the software is needed. This should be documented in a Supplier Audit
Report.
Regulatory Requirements: PIC/S Good Practices for Computerized Systems in Regulated
“GxP” Environments

66
Where the reliability and structural integrity of complex software products cannot be directly assessed, or
completely evaluated, then it is even more important to assure that a good construction process has been used
and has been properly documented.
Report.
The structure and functions of the computer system(s):
 Quality, safety and effectiveness must be designed and built into the software.
 Quality cannot be inspected or tested into the finished software.
 Each phase of the development process must be controlled to maximize the probability that the finished
software meets all quality and design specifications.

67
Where the reliability and structural integrity of complex software products cannot be directly assessed, or
completely evaluated, then it is even more important to assure that a good construction process has been used
and has been properly documented.
Report.
The structure and functions of the computer system(s):
 Quality, safety and effectiveness must be designed and built into the software.
 Quality cannot be inspected or tested into the finished software.
 Each phase of the development process must be controlled to maximize the probability that the finished
software meets all quality and design specifications.

68
• A computerized system is composed of the computer system and
the controlled function or process. The computer system is
composed of all computer hardware, firmware, installed devices,
and software controlling the operation of the computer. The
controlled function may be composed of equipment to be
controlled and operating procedures that define the function of
such equipment, or it may be an operation, which does not
require equipment other than the hardware in the computer
system. Interfaces and networked functions through LAN and
WAN are aspects of the computerized system and operating
environment potentially linking a multitude of computers and
applications.
• A large variety of computer systems are used in regulated user
organizations. These range from the simple standalone to large
integrated and complex systems. For example, a significant
proportion of programmable electronic systems and proprietary
automated equipment for manufacturing, laboratory or clinical
use, contains 'firmware' with embedded software in place.
S/W
H/W
(including
firmware)
SOP &
People
Equipment
Computer System
(Controlling Systems)
Controlled
functions or
processes
Computerized System
Operating Environment
(including other network & standalone computerized
systems, other systems, media, people, equipment &
procedures)
Computerized Systems

69
 It is important to acknowledge that the scope and level of documentation and records needed to formalize and
satisfy basic project management requirements for critical systems will be dependent upon:
 the complexity of the system and variables relating to quality and performance;
 the need to ensure data integrity;
 the level of risk associated with its operation;
 the GxP impact areas involved.
 All computerized systems should have been subjected to documented prospective validation or qualification.
 GxP compliance evidence is essential for the following aspects and activities related to computerised systems:
data input (capture and integrity), data filing, data-processing, networks, process control and monitoring,
electronic records, archiving, retrieval, printing, access, change management, audit trails and decisions
associated with any automated GxP related activity;
in this context, examples of GxP related activities might include: dispensing/weighing, manufacturing,
assembly, testing, quality control quality assurance, inventory control, storage and distribution, training,
calibration, maintenance, contracts/technical agreements and associated records and reports.
 Retrospective validation is not equivalent to prospective validation and is not an option for new systems.
Firms will be required to justify the continued use of existing computerized systems that have been
inadequately documented for validation purposes.

70
 There must be written procedures in place describing the processes and systems governing the
creation, control, distribution, use, retention and disposal of GMP documents and records. This
includes records and documents associated with performing, monitoring, recording and evaluating
all activities and operations that can directly or indirectly influence product quality, patient safety,
or data integrity.
 The issue, revision, superseding and withdrawal of all GMP documents must be controlled. The
current status of controlled documents within the Quality Management System must be available.
 When a need for document creation or revision is identified, this must be justified and the reason
for the change must be maintained as part of the document’s revision history. Where the change
significantly impacts an existing GMP process, the impact of the change must be assessed,
documented and approved before it is implemented.
 Documents must be authored and approved by authorized persons according to the type of
document, subject matter, applicable regulations and local procedures. Signatures must include
the author and/or owner and one or more approvers; Quality Assurance must approve all GMP
procedures. The purpose of each signature must be evident and the name, role and date of each
signer must be clearly stated.
 The effective or issue date of the document, and, where applicable, the expiration or periodic
review due date, must be defined.
EU Vol 4, 4.1
EU Vol 4, 4.32
EU Vol 4, 4.3
ICH Q7, 6.11
21 CFR Part 211
EU Vol 4, 4.3
Regulatory Requirements: Good Documentation Practices & Document
Management

71
 GMP document content must be regularly reviewed and kept up-to-date. Document types that
require periodic review, and the review period for each, must be specified in a local procedure.
 Paper copies of GMP procedures may be issued for use as ‘controlled copies’, which must be
clearly identified as such. Their issue must be recorded and all previously issued ‘controlled copies’
must be recalled when superseded by a new version. Evidence of full recall must be retained. The
reproduction of working documents/ records from master documents must not allow any error to
be introduced through the reproduction process.
 Manual entries into records must be clear, legible and indelible, and must be readable as long as
the record must be retained. Where data are entered manually into electronic records or
generated electronically, this must be in such a way that these data are committed to durable
media and cannot be over-written or obscured.
 Any alteration, change or correction made to an entry on a GMP record must permit the reading
of the original information and the reason for the change must be clear.
 Where the ink fades or smudges during recording of data, the faded or smudged entries shall be
struck out and a new entry must be made by giving appropriate justification with signature and
date.
 Scratch papers, loose papers or “Post-it” notes shall not be used to record the data.
 Pre-dating or post-dating of GMP documents is not an acceptable practice.
EU Volume 4, 4.5
EU Volume 4, 4.9
21 CFR 11.10
ICH Q7, 6.14
EU Volume 4, 4.7
ICH Q7, 6.14
Regulatory Requirements: Good Documentation Practices & Document
Management

References
72
 21 CFR Part 11
 EU GMP Annnex 11
 EU Vol 4
 21 CFR Part 211
 ICH Q7
 ICH Q9
 PIC/S Good Practices for Computerized Systems in Regulated “GxP” Environments
 MHRA’s GxP Data Integrity Guidance
 ICH E6
 WHO Appendix 5
 21 CFR Part 820
 GAMP 5…etc.

THANKS!
Any questions?
You can find me at:
nileshdamale330@gmail.com
Phone: +918087228891
73
Nilesh Damale

Overview of computer system validation

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Overview of computer system validation

Similar to Overview of computer system validation (20)

Recently uploaded

Recently uploaded (20)

Overview of computer system validation