prioritizing and justifying the
validations to be performed
developing the initial
Validation Master Plan and producing subsequent revisions as required
establishing a mechanism to
include new computer systems in the Validation Master Plan
establishing site specific
procedures for computer systems validation
resourcing validation projects,
including approving the use of consultants
reviewing the progress of
individual validation projects to ensure timely execution of the Validation
resolving issues arising due to
conflicting priorities, schedules, or resources
Each site should establish a Validation Master Plan,
which describes all the required validation activities at the site together
with assigned responsibilities, priorities and timings for actions. The
Validation Committee should approve this site plan.
All computer systems validation projects should either
be included in this Validation Master Plan or a separate Computer Systems
Validation Master Plan established.
Master Plan should be a dynamic document which at any point in time will
which systems exist on site
which systems require
who is responsible for each
the status of the individual
the date for completion of each
All upgrades and periodic reviews should also be added
to this plan.
Systems that Require Validation
Before you can validate a system, you need to identify
the systems that require validation. This topic looks at all of the steps
involved in identifying systems that require validation.
It also looks at the:
scope of the procedure
definition of hardware
system / application owners
Identifying systems that require validation consists of
the following steps:
Create an Inventory - Note: The inventory must
consist of all hardware and software in use within a given site or
Identify the Systems
Assess Each System for Validation
Determine Validation Priority
This procedure should be applied to all systems
within a site or department.
Hardware is defined as any programmable device
workstations e.g., SUN
any programmable equipment
used in a quality process.
Each computer or computerized piece of hardware
should have a designated owner.
The hardware owner is responsible for:
identifying all software
residing on the hardware - both system software and application software
maintaining the inventory
whenever changes are made to the hardware
managing the change control
process for the system software and hardware and working with the
system/application owners to determine the impact of the change to the
The hardware owner
will be involved in step 1.
/ application owner
Each system/application should have an owner.
This owner is
defining the system (hardware
completing the system
ensuring that the information
pertaining to their specific system is correct and complete
updating the system
assessment whenever changes are made to the system.
The system owner will
be involved in steps 1, 2 and 3.
This topic looks at creating an inventory of all
hardware and software in use within a given site or department. Creating
an inventory is the first step in identifying systems that require
The hardware owner and the system/application owner are
responsible for step 1.
the previous topic to have a look at their responsibilities.
For each computer
or computerized piece of hardware (or, if appropriate, each group or class
of hardware), the operating system and all applications residing on the
hardware should be listed.
Other key information may also be recorded.
It is best practice to have a single repository within
the site or department for all data resulting from the inventory.
The exact information and format of the inventory will
vary according to the type of hardware and the needs of the business unit.
The following three tables provide examples of
information that should be included in the inventory.
The following hardware
information should be included in the inventory:
A unique identifier for each piece of hardware.
The model name of the main Central Processing Unit
Manufacturer of the main CPU.
Supplier name of
the main CPU, if different from manufacturer.
Name of person responsible for the hardware.
The departments or Business Unit relying on the
Physical location of the CPU.
Whether Installation Qualification (IQ) has been
performed on the hardware.
Mark "Qualified" if IQ has been done.
Mark "Not Qualified" if IQ has not been done.
The following system software information should be
included in the inventory:
Name of the
operating system residing on the CPU.
Version of the operating system residing on the CPU.
The following application software information should
be included in the inventory:
A unique identifier for each piece of application
For purchased systems/applications, use the product
For in-house systems/applications, use the name by
which generally known.
For computer controlled instruments, call the
application "Resident Software".
Version number of the application.
Name of person responsible for the application
Statement about origin.
Examples: Vendor Supplied - no modifications
Vendor Supplied - with modifications
Name and location
General category of use.
Examples: Raw Data Storage
Raw Data Collection
Note: A computer system may fall into multiple
categories e.g., a chromatography system provides raw data collection and
storage, date processing and, in some cases, equipment control.
The name of the system of which the application
software is a component. This may be the same as the application software
The name of the system component by which the
application software is known.
This topic looks at
identifying the systems, the second step in identifying systems that require
For inventory purposes, a system is defined as:
any programmable device including its software,
hardware, peripherals, procedures, users, interconnections and inputs for
the electronic processing and output of information to be used for reporting
The system/application owner
is responsible for identifying the systems from the inventory.
Identifying the systems
consists of the following steps:
hardware, software and interfaced equipment that describes a system
Identify the systems involved in step 1
Evaluate each software application identified on the
inventory to determine if it is part of a system or not
Identify and record the primary functions of the
Record any additional information
The exact information and format for recording the
functions of a system will vary according to the type of system and the
needs of the business unit.
The following table provides examples of information
that should be recorded:
The system or
The name of the person responsible for the overall
system, including hardware, software and interfaced equipment. This is
often the manager of the department in which the system is used.
Those departments or Business Unit that rely on the
The name and reference number of all hardware
associated with the system.
The name and reference number of all application
software associated with the system.
Any equipment associated with the system for the
purpose of control or data acquisition.
All major functions of the system.
Unused major functions should be listed separately,
since these may not be evaluated against quality critical criteria. A
risk assessment must be made on the criticality of the function and
whether the function can be turned on and off by a system administrator.
NOTE: The application or system function, depending
on the application type and the use strategy and process, may be audited
by regulatory agencies, and based on their recommendations or audit
findings, determine that all existing functions must be qualified or
validated. If a function is determined not be of a critical or usable
facet of the application, and if validating or qualifying is not
performed, then a statement could be drafted summarizing the reasoning for
System for Validation
This topic looks at assessing each system for
validation, the third step in identifying systems that require validation.
Each system that has been identified must be assessed
to see whether it performs quality or business critical functions, whether
there are sufficient controls to ensure its performance, and whether it
should be validated or not.
system/application owner is responsible for completing the assessment of
each system and updating that assessment whenever there are changes to the
Assessing each system for validation consists of the
Develop a list of:
quality critical criteria
business critical criteria.
Evaluate each function against the quality critical
criteria and record the outcome.
Note: If a function meets the quality critical
criteria, it is classed as quality critical.
Evaluate each function against the business critical
criteria and record the outcome.
Note: If a function meets the business critical
criteria, it is classed as business critical.
external controls, if any, for each quality critical and business critical
Examples: External controls include:
Parallel manual procedures
100% data reconciliation.
Determine whether the system requires validation
according to the following criteria:
If the system has quality critical functions,
validation is mandatory.
If the system has business critical functions,
validation is recommended.
Prepare the Assessment Report
quality critical criteria
Company processes are subject to various regulations
listed in the table below. Any system or function used in these regulated
areas is deemed quality critical.
Good Clinical Practice (GCP)
US Food and Drug Administration
Organization for Economic
Co-operation & Development (OECD)
* There are many local country regulations. However,
the authorities listed above represent the major regulatory authorities with
specific regulations associated with computer systems.
of quality critical criteria
Examples of systems or functions that fall under these
System functions which control
equipment, and collect, store, and/or process the following types of data:
Lot traceability - composition, disposition
Test methods and test specifications
Test results/QC records
Verdicting i.e. the association of a disposition with a
Stability trial - scheduling, data processing, sample
storage and inventory
Clinical trial - scheduling, data processing, sample
storage and inventory
Patient and animal records and results
Calibration and maintenance records
Data used to support
Development Summary Reports
Management of SOPs and protocols
Regulatory Document Management System
Electronic data archiving
Indexes of archived documents
Data associated with
Clinical Laboratory System
of manufacturing quality critical functions
The quality critical functions for manufacturing may be
defined with reference to current Good Manufacturing Practices (CFR 21,
Parts 210 and 211) as those functions that relate to:
"methods to be used in, and the facilities or
controls to be used for, the manufacture, processing, packing, or holding of
a drug to assure that the drug meets the requirements of the Act as to
safety, and has the identity and strength and meets the quality and purity
characteristics that it purports or is represented to possess."
Note: This definition is used as an example and
synonymous definitions may also be found in the European Guide to GMP and
the Australian Guide to GMP.
functions relate to areas critical to the operation of the business, but are
not related to functions, which are directly covered by regulatory
Any system or function which collects, stores or
processes information in the following areas is designated business
The assessment report identifies the quality critical
and business critical functions and documents the validation status of the
The assessment report should include:
whether validation is
recommended and, if so, the scope of the validation
quality critical functions
external controls for quality
business critical functions
external controls for business
current validation status of
details about the validation
documentation, if any
Note: The validation documentation details should
include, the location and unique reference number, the identity of the
person or persons who approved the validation documentation and the date of
This topic looks at determining validation priority,
the last step in identifying systems that require validation.
When you have identified those systems that require
validation, you need to determine the priority of each system validation (or
validation project) within a site or department. To determine the priority
of each validation, you need to perform a risk assessment of all the
The findings should be documented in a report and
include a justification for the validation priority for all of the systems.
The table below
outlines the suggested method of conducting a risk assessment.
Determine the risk assessment criteria (refer to
the list below).
Weight or score each of
Match the system to
Compare the total
system score with other systems and prioritise.
Note: Use the
scoring system as a guide only. Professional judgement will still be
Consider the following when determining the risk
Company/site history and
experience with the system
complexity of the system
industry experience with the
have the regulatory authorities
shown interest in this type of system either within or external to Company?
stage in system life cycle.
e.g. is the system new or has it been installed for some time, or, is the
system almost at the end of its use and will shortly be replaced?
criticality of system or data
contained within the system in terms of patient risk and product quality
what products are associated
with the system; are those products strategic?
Validated status of system
which department is the system
used by e.g. QA, Production, Packaging, Development
the impact on the business if
the system was not operational for a period of time