GlaxoSmithKline-Computer System Validation Guideline

GlaxoSmithKline
GLOBAL QUALITY GUIDELINE
Management: Management Systems

COMPUTERISED SYSTEM VALIDATION
1205
JUNE 2002
RATIONALE
Computerised systems are increasingly being implemented to realise operational benefits
within manufacturing working environments. It is essential that there are controls in place
to ensure such systems are validated as fit for purpose.
PURPOSE
To provide guidance when implementing GQP 1205 Computerised System Validation.
To provide specific additional guidance on the approach to validating different types of
computerised systems.
SCOPE
This guideline applies to all sites and companies manufacturing, distributing or marketing
materials, products or devices for use or sale by, or for, GSK.
This guideline applies to computerised systems that are used in support of those agency
regulated manufacturing of pharmaceutical, biologic/biopharmaceutical, and healthcare
products requiring computer validation. Agency regulations include but are not limited to:
Adverse Event Reporting.
Electronic Records and Electronic Signatures (ERES).
Good Distribution Practices (GDP).
Good Laboratory Practices (GLP).
Good Manufacturing Practices (GMP).
Throughout this guideline GDP, GLP and GMP and are collectively referred to as GxP.
Page 1 of 104
GlaxoSmithKline

1205
JUNE 2002
SUMMARY OF REVISIONS
This replaces GQG 1205 dated October 2001, with the following revisions:
The Scope has been extended to introduce the use of GxP throughout the rest of the
guideline.
The section on System Registers has been updated to include reference to

GQG 3202.
The section on Prospective Validation has been updated. The subsection on

Compliance Assessments has been extended to include guidance on Commercial
off-the-Shelf (COTS) products. The subsection on Validation Planning has been
extended to include GxP Risk Management.
The subsection on Supplier
Assessments has been revised to improve grammar.
A subsection on the
Requirements Traceability Matrix has been added. The subsection on Operational
and Support Plans has been updated to include reference to GQG 3203 and
GQG 3301. The subsection on Use has been extended to include a subsection on
Service Level Agreements. The subsection on Archive and Decommissioning has
been renamed Decommissioning.
The section on Retrospective Validation has been revised to improve grammar.
The section on Approach to Laboratory Systems has been revised to improve

guidance on System Registers and Special Considerations for Simple COTS
Firmware Instrumentation.
The section on Approach to Control Systems has been revised to improve guidance
on System Registers, and use of off-line simulation to support Operational
Qualification.
The section on Approach to Desktop Applications has been revised to improve

guidance on Compliance Assessments and System Registers.
The section on Approach to IT Systems has been revised to include Distribution

Systems within Scope of Systems Covered and Examples of System Categorisation.
Requirements for Compliance Assessments have been clarified.
A section has been added on Approach to Centrally Developed/Supported Systems.
A section has been added on Approach to Medical Devices.
The section on Inspection Readiness has been revised to improve guidance on

Documentation.
The Bibliography has been updated to reflect the latest edition of the good automated
manufacturing practice (GAMP) and PIC/S guidance on regulated GxP applications.
Page 2 of 104
GlaxoSmithKline
1205
JUNE 2002
CONTENTS
1. Introduction ................................................................................................................. 6
2. Responsibilities .......................................................................................................... 7
2.1. Senior Management................................................................................................ 7
2.2. System Owner/User Role........................................................................................ 7
2.3. Project Manager...................................................................................................... 7
2.4. Developer/Technical Role ....................................................................................... 8
2.5. Support/Maintenance Role...................................................................................... 8
2.6. QA/Validation Role.................................................................................................. 8
3. Site/Function Activities .............................................................................................. 9
3.1. Validation Master Plans .......................................................................................... 9
3.2. System Register...................................................................................................... 9
4. Prospective Validation.............................................................................................. 11
4.1. Planning Phase ..................................................................................................... 12
4.2. Supplier Assessment Phase ................................................................................. 13
4.3. Requirements Phase............................................................................................. 14
4.4. Design and Code Phase ....................................................................................... 14
4.5. Development Testing Phase ................................................................................. 20
4.6. Deployment Phase................................................................................................ 23
4.7. Use Phase ............................................................................................................ 28
4.8. Decommissioning Phase....................................................................................... 30
4.9. Cross Phase Activities .......................................................................................... 31
5. Retrospective Validation .......................................................................................... 32
5.1. Gap Analysis ......................................................................................................... 33
5.2. Priorities ................................................................................................................ 33
5.3. Interim Measures .................................................................................................. 34
6. Managing Hardware and Software........................................................................... 36
6.1. Hardware Categories ............................................................................................ 36
6.2. Software Categories.............................................................................................. 37
Page 3 of 104
GlaxoSmithKline
1205
JUNE 2002
7. Approach to Laboratory Systems............................................................................ 42

7.1. Laboratory Systems Definition .............................................................................. 42
7.2. Scope of Systems Covered................................................................................... 43
7.3. Responsibilities ..................................................................................................... 43
7.4. Systems Register .................................................................................................. 44
7.5. Validation Life-Cycle ............................................................................................. 44
7.6. Examples of System Categorisation ..................................................................... 49
8. Approach to Control Systems.................................................................................. 49
8.1. Definition of a Control System............................................................................... 49
8.2. Scope of Systems Covered................................................................................... 50
8.4. Systems Register .................................................................................................. 51
9. Approach to Desktop Applications ......................................................................... 62
9.1. Definition of Desktop Applications......................................................................... 62
9.2. Scope of Applications Covered ............................................................................. 62
9.4. System Register.................................................................................................... 64
10. Approach to IT Systems ........................................................................................... 75
10.1. Definition of IT Systems ..................................................................................... 75
10.2. Scope of Systems Covered................................................................................ 75
10.3. Responsibilities .................................................................................................. 76
10.4. System Register................................................................................................. 76
10.5. Validation Life-Cycle .......................................................................................... 76
10.6. Examples of System Categorisation .................................................................. 89
11. Approach to IT Infrastructure .................................................................................. 90
11.1. Definition of IT Infrastructure .............................................................................. 90
11.2. Controls for IT Infrastructure .............................................................................. 90
Page 4 of 104
GlaxoSmithKline
1205
JUNE 2002
12. Approach to Centrally Developed/Supported Systems ......................................... 94

12.1. Definition ............................................................................................................ 94
12.2. Scope................................................................................................................. 94
12.4. System Register................................................................................................. 95
12.5. Validation Life Cycle........................................................................................... 95
13. Approach to Software Tools .................................................................................... 97
13.1. Definition of a Software Tool .............................................................................. 97
13.2. Scope of Tools Covered..................................................................................... 97
13.4. System Registers ............................................................................................... 99
13.5. Validation Requirements .................................................................................. 100
14. Approach to Medical Devices ................................................................................ 100
15. Inspection Readiness ............................................................................................. 101
15.1. Definition of Inspection Readiness ................................................................... 101
15.2. Organisation Charts ......................................................................................... 101
15.3. Use of Trained Personnel ................................................................................ 101
15.4. Systems Register ............................................................................................. 101
15.5. High Level Site Mapping of Key Computerised Systems ................................. 101
15.6. System/Project Overviews ............................................................................... 102
15.7. Validation Plans/Reports and Reviews ............................................................ 102
15.8. Documentation ................................................................................................. 102
15.9. Presentation ..................................................................................................... 103
15.10. Internal Audit Program ..................................................................................... 103
15.11. Mock Inspections ............................................................................................. 103
15.12. Inspection Management................................................................................... 103
16. Bibliography ............................................................................................................ 104
Page 5 of 104
GlaxoSmithKline

1.
1205
JUNE 2002
Introduction
Computerised systems for the purpose of this guideline are considered as consisting
of application software, data, and hardware platform collectively providing
functionality to a user or other computer system. Examples of computerised systems
include: laboratory systems, control systems, desktop applications (end-user
computing), IT systems, and IT infrastructure. Reports and sub-systems should not
be considered computerised systems in their own right.
Validation activities encompass the entire life of the computerised system, from
requirements definition to decommissioning, and employ quality practices known to
minimise errors. Validation does not end with implementation of computerised
systems, but includes maintaining computerised systems in a validated state and
using computerised systems in a compliant manner.
This guideline applies predominately to the introduction of new systems where it is
possible to build in validation requirements at each stage in the life of a computerised
system. Guidance includes:
How to establish whether or not a computerised system requires validation.
A general life-cycle methodology for computerised systems validation.
Expectations regarding the application of the general life-cycle methodology to

different types of computerised systems (laboratory systems, process control
systems, desktop applications, IT systems, IT infrastructure, and software
tools).
Advice on inspection readiness for computerised systems.
Guidance on roles and responsibilities.
Guidance on appropriate use of terminology.
A section is also included on retrospective validation describing where this is

appropriate and the basic approach to be adopted.
This guideline is not intended to cover safety or environmental protection
requirements; however these should be considered concurrently with the validation
process. An effective strategy may be to include such requirements within the scope
of validation rather than as a separate exercise.
Page 6 of 104
GlaxoSmithKline

2.
1205
JUNE 2002
Responsibilities
It is the responsibility of the personnel associated with computerised systems to
ensure that they understand the requirements of GQP 1205 and comply with it. This
guideline should be used by individual sites/departments as appropriate to prepare
their own local procedures. Validation and regulatory compliance is the responsibility
of each site/department and should be incorporated into their quality planning. Local
user, IT, controls engineers, laboratory technicians, and QA are expected to take an
active role. The senior management role is usually conducted in conjunction with
QA. Emphasis between roles will vary depending on the nature of the work being
conducted.
2.1.
Senior Management
Responsible for:
2.2.
Providing adequate resources.
Final authorisation of the validated system for use.
System Owner/User Role

Responsible for:
2.3.
Validation activities associated with any aspect of the requirements

definition, acceptance and use of a computerised system.
Defining the system requirements.
Ensuring that the system is validated and used in a compliant manner.
Ensuring that appropriate user procedures are in place.
Ensuring that system end users/operators are trained.
The integration of the computerised system with existing processes,

infrastructure and ways of working.
Project Manager
Responsible for:
Ensuring that validation activities associated with any aspect of the

development, provision, implementation and handover to the user of a
computerised system are conducted in accordance with agreed plans.
Page 7 of 104
GlaxoSmithKline

2.4.
1205
JUNE 2002
Developer/Technical Role
Responsible for:
2.5.
All technical aspects of the system development and validation

including preparing specification and design documentation.
The technical implementation and delivery of the computerised

system including preparing test documentation, conduct testing, etc.
Support/Maintenance Role
Responsible for:
2.6.
Ensuring that appropriate support and maintenance procedures are in

place.
All technical aspects of the system support and maintenance whilst

the system is in use including documentation not covered by
QA/Validation.
QA/Validation Role
Responsible for:
Preparing and approval of validation plans and of associated

validation reports.
Providing key validation activities and approvals as defined in

validation plans such as supplier audits, qualification plans/reports,
change control records, and configuration management.
Authorising validated computerised systems as fit for purpose.
Provide GxP and regulatory input into validation projects with

particular focus on product quality impact.
Conducting compliance audits on the implementation of GQP 1205 in

support of 'regulated' computerised systems.
Page 8 of 104
GlaxoSmithKline

3.
1205
JUNE 2002
Site/Function Activities
3.1.
Validation Master Plans

Computerised systems requiring validation should be identified as such in
site/function validation master plans (VMP) (see Section 14 and GQP 1204).
Plans should be produced in association with system registers, identifying
validation requirements for both new and legacy computerised systems.
3.2.
System Register
System registers, providing an inventory of computerised systems should be
created and maintained for each site or company. Advice for centrally
developed/supported systems can be found in Section 12.
Note: Sub-systems and systems components should not be listed in the
system register. Each register should contain, as a minimum, the following
information for each system listed:
Name (by which the system is known and commonly referred to).
Unique reference/acronym (for traceability).
System description (phrase/sentence describing what the system

does).
System type (indicate, e.g. whether this is a local system, a system

that is supported by another site, or a corporate system).
GxP/regulated determination (whether it is GxP/regulated system)

(Yes/No).
Validation status (whether it meets current computer validation

requirements) (validated, not validated, validation in progress,
validation not required).
Electronic records
(see GQG 3202).
Regulatory submissions use (whether used for regulatory purposes

other than GxP) (Yes/No).
Reference to validation support and documentation index/archive

location.
and
electronic
signatures
(ERES)
status
The basic attribute list is not exhaustive and may be extended as appropriate
to meet specific site needs.
The system register should cover all
Page 9 of 104
GlaxoSmithKline

1205
JUNE 2002
manufacturing, packaging and distribution computerised systems. Some sites

may wish to include names of contacts (e.g. developer, system support, user
and validation) that could present information concerning the computerised
system during an inspection. Sites may wish to consider including a
document archive reference to facilitate faster document retrieval.
Table 1
Approach To System Register Contents
Type of System
System Register Guidance
Examples
Laboratory System
One entry per system.
pH Meter
Ultrasonic Bath
A separate entry is required for

each physical system of the
same type.
Mass Balance
HPLC
FTIR
Chromatography Data System
Robotic Systems
Process Control
Intelligent/Smart
PLCs
One entry per system.
Instruments
SCADA System
A separate entry is required for
each physical system of the
same type.
Distributed Control Systems
Expert Control Systems

Desktop
Applications
IT System
(User)
One
entry
per
spreadsheet/database
applications.
GxP
One entry per production system

instance.
Spreadsheet applications.
Database
applications
including Lotus Notes.
SAP R/3
BPCS
LIMS
Care must be taken to ensure

sites understand which multi-site
systems they use.
Page 10 of 104
GlaxoSmithKline
1205
JUNE 2002
Guidance on which systems require registration on the system register is

given in Table 1. The system register may consist of a number of lists so long
as collectively they cover all computerised systems.
Written dispensation may be given to individual functions/departments
excluding them from the scope of the system register where they have no
computerised systems within the scope of GQP 1205.
In some situations there may be large numbers of computer applications that
do not require validation and the practicalities and value of listing them on the
system register might be questioned. For example, spreadsheet applications
are used widely but typically only a small fraction is used in a GxP context.
Guidance on which systems require registration and how to record them on
the system register is provided in the section of this guideline dealing with
desktop applications.
Standard COTS packages should not be registered separately from their
application (e.g. Excel, MS Project, MS Word, MS Access) as their use will be
captured as part of the application using them. Operating systems such as
Unix, NT, and Oracle should not be registered.
4.
Prospective Validation
Validation of computerised systems requires careful planning to identify the set of
validation activities required from initial design through to implementation use and
final decommissioning. In practice in can be impossible to validate existing systems
where initial design requirements are no longer available or appropriate activities
were not performed or documented as the system was designed and implemented.
The following sections describe the validation activities appropriate to a new system.
However, these life-cycle requirements should be considered when attempting
retrospective validation of existing systems.
The validation life-cycle activities and their order should be documented in a
validation plan. A description of each phase of the life-cycle validation activities is
presented below as a sequential process, however certain activities may overlap or
be combined. The validation plan should define such overlaps and amalgamations.
All validation activities should be carried out in a safe and secure manner, observing
local safety procedures and requirements. A number of key issues should be
addressed as soon as reasonably practical. Examples include procurement (supplier
capability), regulatory expectations for electronic records/signatures, data integrity,
user security, and hand-over issues such as advance knowledge of operation and
support requirements.
Page 11 of 104
GlaxoSmithKline

1205
JUNE 2002
For the purpose of this guideline the following generic validation life-cycle is
presented. The application of the life-cycle will vary as appropriate to the type of
computerised system being validated. Later sections in this guideline address how to
approach the validation of laboratory systems, control systems, desktop (end-user)
applications, IT systems, IT infrastructure and software tools.
4.1.
Planning Phase
Business Requirements
This high level document describes the functions to be carried out, the
operating environment and constraints, regulatory or otherwise.
The
emphasis is on the required functions and not the method of implementation
and should therefore not be product specific. The business requirements will
often document the business case and approval for work and capital
investment. The approved business requirements should provide sufficient
information for the compliance assessment and system selection activities to
be completed.
Compliance Assessment
All computerised systems should be assessed during the early planning phase
to determine if there is a GxP impact and, therefore, whether the system
should be validated or not. The compliance assessment should be approved
by QA/Validation.
The Compliance Assessment should include a review of COTS product
license requirements and release notes in order to determine any
impact/restrictions on use within specific operating environments.
Electronic Records and Electronic Signatures Assessment
Where the compliance assessment indicates a GxP impact an ERES
assessment should be planned based on the guidance offered by GQG 3202.
Validation Planning
The validation plan is a document (or group of documents) stating the
standards and the methods employed to maintain quality through the system
life-cycle and to establish the adequacy of performance of the computerised
system. Key roles and responsibilities, deliverables and authorities should be
defined in the validation plans.
The validation plan should be initiated at the earliest practicable stage and
may be reviewed and updated through subsequent stages of the project. A
rationale supporting any validation decisions made should be included within
the validation plan. Validation plans should take account of the different
software categories comprising a computerised system and the mix of GxP
Page 12 of 104
GlaxoSmithKline

1205
JUNE 2002
and non GxP components (see GQG 1401A). Guidance for the scope of
validation required for different types of computerised system is defined in
Section 6.
The need to conduct GxP Risk Assessments should be considered. Where a
need is identified, the timing of/and approach to assessments should be
documented in the Validation Plan. For larger, more complex projects, GxP
Risk Assessments may be conducted at several key phases of the system
lifecycle. The IT Risk Management Framework can be used to help facilitate
GxP Risk Assessments for larger projects.
Where there are validation plans for both the process/equipment/area and
computerised system, then these should cross-reference each other. If the
computerised system is relatively small and contained in its entirety within a
stand-alone piece of equipment, then the validation plan for the computerised
system may be embodied within the overall validation plan for the equipment.
4.2.
Supplier Assessment Phase

Supplier assessments determine the level of assurance in the supplier that
activities/deliverables equivalent to those outlined in this guideline have been
followed/produced for development of computerised systems. The information
is used to determine any corrective/additional activities to be undertaken by
the supplier and/or GSK in order to address identified deficiencies. The need
for follow-up supplier assessments should be commensurate with the number
and severity of the identified deficiencies. The validation plan should
document applicability and timing of supplier audits. The system category
(see Section 6) will assist in deciding when an audit is necessary. Supplier
audits are most beneficial if they are conducted as part of the supplier
selection and procurement process so that any actions arising can be planned
and managed as part of the project implementation.
Key areas of assessment are:
Existence and authority of quality assurance organisation.
Availability and use of competent people.
Availability and application of an effective quality management system

(procedures and practices).
Use of programming standards and good practices.
Effectiveness of testing.
Availability of a support service (as required).
Page 13 of 104
GlaxoSmithKline

1205
JUNE 2002
Ongoing viability of suppliers business (e.g. financial stability).
Assistance on conducting Supplier Audits is available through Global

Computer Validation. A repository of supplier audit reports is also available at
Global Computer Validation web-site.
4.3.
Requirements Phase
Business requirements are further developed to produce what is commonly
called a user requirements specification (URS). The URS should focus on
what the system should do and not to detail how to achieve this, i.e. design
statements should not be incorporated. For large and complex systems, a
number of URSs may be required. For small and simple systems the
business requirements and URS may be combined.
The URS provides a statement of process/functional requirements of the
proposed system. Each requirement should be categorised in order to define
the level of importance, e.g. must, should, and could. All URS requirements
should be successfully validated before system use unless otherwise justified
and approved.
Each URS requirement should be:
Referenced to facilitate
Traceability Matrix [RTM]).
Unambiguous, clear and concise.
Testable/measurable.
Be approved by the end-user.
requirements
tracking
(Requirements
The URS provides the basis for system acceptance testing and should be
approved before a design review is conducted.
Requirements Traceability
An RTM or other equivalent mechanism should be established in order to
provide a means of demonstrating how a particular function of a
system/application has been validated through design (including any DQ),
programming (including source code review), and testing (pre-qualification, IQ,
OQ, PQ).
4.4.
Design and Code Phase

During this phase of the life-cycle, the design is documented, verified by a
design review, and the system coding/configuration performed against
pre-determined standards.
Page 14 of 104
GlaxoSmithKline

1205
JUNE 2002
Design specifications may take a variety of forms. Diagrams should be used

where appropriate to assist readability. Where large systems are being
developed it is permissible to split the design specifications into a number of
separate documents. Where this approach is adopted, effective change
control must be implemented to ensure that the effect of changing one
component on others is fully assessed.
Contents of the design specification should be cross-referenced to the system
and functional requirements to demonstrate traceability.
System Overview
There should be a single document (clear, concise, accurate and complete)
describing the purpose and function of the system. The system overview
should be written in non-technical language so that personnel not trained in
computing can understand it. It should include diagrams indicating the
physical layout of the system hardware, any automated and manual interfaces
to other systems, inputs, outputs and main data flows.
System overviews have a similar content compared to business requirements.
The system overview is aimed however for use during inspections, providing a
summary of the system scope, hardware and key functions. Business
requirements may contain business case and business strategy information
that is not appropriate to GxP regulatory inspection.
The system overview should be reviewed and approved prior to use of the
system.
Functional and Design Specification
Functional specification documents are commonly used as the highest-level
design document from which more detailed design documents are developed.
The functional specification provides a response to the URS. Functional
specifications will typically address:
All inputs that the computerised system will receive.
All functions that the computerised system will perform.
All outputs that the computerised system will produce.
All performance requirements that the computerised system will meet

(e.g. data throughput, reliability, timing).
The definition of internal, external and user interfaces.
What constitutes an error and how errors should be managed.
Page 15 of 104
GlaxoSmithKline

1205
JUNE 2002
The intended operating environment for the computerised system

(e.g. hardware platform, operating system, etc. if this is a design
constraint).
All ranges, limits, defaults and specific values that the computerised
system will accept.
Safety considerations where inclusion of this information is deemed

appropriate.
Detailed design specifications document the equipment hardware and/or

software in sufficient detail and clarity to enable the hardware and software to
be built and tested. The use of formal design techniques is encouraged.
Detailed design specifications should include but are not limited to:
System architecture (software and hardware, modularity).
System functionality (including reporting).
Data processing and integrity.
Security.
Back-up, archiving and restoration.
System interfaces (including human/operator interface).
Disaster/failure recovery.
Detailed design specifications may be split into discrete elements for example,
hardware design specification and software design specifications. Further
subdivision is common for larger systems where for example unit/module
design specifications may be produced. Other documentation includes:
System architecture (including relevant design drawings).
Software program specifications (All inputs, outputs, error/handling

and alarm messages, ranges limits, defaults and calculations should
be defined ready for programming and testing).
Cabling/wiring schedules.
The design of a system should consider the partitioning of GxP and non-GxP
elements such that they can be validated and supported separately.
Page 16 of 104
GlaxoSmithKline

1205
JUNE 2002
Data Definition
Data dictionaries, architectures and flow should be defined. Actual data to be
loaded into tables, files and databases should be specified by reference to its
source. Data dictionaries should be used to describe different data types.
The data definition may standalone as a separate document or be
incorporated within functional/design specification.
Specific functional aspects to be covered by the data definition include:
ERES requirements (GQP 3202).
Built in checks for valid data entry and data processing.
Access controls to ensure data can only be entered or amended by

persons authorised to do so.
Data Definitions may be incorporated into the Functional or Design

Specification documents, or prepared as a separate document as appropriate.
Design Review
A design review is undertaken to ensure that all documentation from the
requirements and design phases have been produced and are:
Clear and concise: The specification should conform to documentation

standards and should be readily understandable.
Complete: To establish that the specifications unambiguously and

adequately define the system and that the requirements traceability
matrix (RTM) (or equivalent mechanism) has been maintained.
Testable: Criteria within the specification to be used for user

acceptance should be specific, measurable, achievable, realistic and
traceable to the functional requirements and design specification.
Fit for purpose: To generate confidence that the system will satisfy the
users requirements, have the necessary attributes of reliability,
maintainability, usability, and minimise hazards. Methods such as a
FMEA (failure mode effects analysis) or CHAZOP (computer hazard
and operability study) should be used to verify the design.
Include ERES requirements (where applicable): The design review

should confirm whether or not electronic record and electronic
signature functionality has been addressed.
Current: Verify the documentation is current and necessary change

control has been applied.
Page 17 of 104
GlaxoSmithKline

1205
JUNE 2002
After the review a report should be prepared and approved summarising the
design review. The report should clearly state if the quality of the design is
acceptable, list any deficiencies together with details of planned remedial
action.
Design reviews may be known as design qualifications (DQ). Their scope of
application may include use of the computerised system in its wider context
including equipment, procedures, and operator interaction.
It should be understood that the requirement for this design review does not
mean that other routine reviews are no longer appropriate. Activities and
documents should be reviewed and approved as defined in the validation plan
and management procedures.
Coding, Configuration and System Build
Prior to commencement of coding, configuration or system build the design
review should have been successfully completed. All software (including
configuration) should be developed with good programming practices to
appropriate standards.
Software/configuration developed internally should adopt programming
standards. Such standards should reflect the type of programming language
used, e.g. structured, object oriented, ladder logic, etc.
Typically,
programming standards will address:
Content of header information in software listings (i.e. author, version,

change details etc).
Software/configuration
structure).
Avoiding creation of non-executable code (i.e. dead code).
In-code documentation.
Naming and definition of variables.
Data definition and scope (e.g. global versus local).
Use of sub routines.
Branching.
Error/exception handling.
Expandability considerations.
structure
and
consistency
(i.e.
modular
Page 18 of 104
GlaxoSmithKline

1205
JUNE 2002
Hardware should be assembled and constructed in accordance with good

practice taking into account aspects such as regulatory requirements and
manufacturers recommendations.
Code/Configuration Review
A source code or configuration review should be performed on all
bespoke/custom application software and configurations prior to formal
testing. A two-tier approach is advocated: a high level overview of all software
identifying areas of code and a low-level walk through of critical areas.
The source code review aims to provide confidence in the operability of the
system and should:
Verify expected use of good programming practices and adherence to

programming standards referenced in development documentation.
Determine a level of assurance that the code has been constructed

against the approved requirements and design specifications.
Provide assurance that the code is maintainable by a competent

programmer.
Detect possible coding errors.
Identify evidence of dead code.
Configuration details should be reviewed to provide confidence in the

operability of the system and should verify that:
'Unused' options are deselected and cannot function.
The configurable
specifications.
elements
of
the
application
fulfil
design
The outcome of the source code or configuration review will typically be a

report providing an overview of the review conducted together with a list of all
observations that have been noted. Care must be taken only to place actions
on what is required from a regulatory or tangible business benefit perspective.
All actions should be completed before progressing to testing of the software
unit/module.
Note: The correction of typographical errors is not needed if there is no impact
on GxP functionality. Equally reports do not need to identify each individual
typographical error where a general statement of observation can do just as
well.
Page 19 of 104
GlaxoSmithKline

1205
JUNE 2002
Complete hand-written annotated listings of software subject to detailed

low-level walkthrough should be retained and attached to, or referenced by,
the report. Where suppliers withhold software source codes then access
agreements should be established. Other review evidence should also be
retained and similarly managed.
4.5.
Development Testing Phase

The system developer should conduct formal development testing prior to the
deployment phase. Development testing includes:
Unit/Module testing.
Integration testing.
Interface testing.
System testing.
For small computerised systems it may be appropriate to consolidate or omit

some of the above test activities. The justification for consolidation or
omission of any test activities should be documented in the validation plan.
Testing is carried out according to pre-approved test plans and test cases.
Due account should be taken of any test requirements identified by the
validation plan, supplier audit and design review. Testing should be conducted
against approved specifications. Progression from one test phase to another
should not occur without satisfactory resolution of any adverse test results.
Testing should be conducted in controlled test environments that should be
documented and verified in order to confirm that the hardware and software
used in the testing are appropriate representations of the finally operating
environment. Confirmation that the test environment is indeed controlled is
usually achieve by conducting an installation qualification (IQ) similar to that
conducted as part of the deployment phase.
Simulation and test equipment should be calibrated/tested, documented and
verified prior to use. Test data-sets should be reviewed and approved prior to
use.
It is important to recognise that computerised systems and software not
specifically written by GSK should also be tested prior to its use.
Development testing in these circumstances in the responsibility of the
supplier (system developer). Products that are released by a supplier pending
final evaluation (beta testing) should not be used. Initial and subsequent
product releases should only be used once they have been proven over a
period of time by a user community to be fit for purpose. New releases should
Page 20 of 104
GlaxoSmithKline

1205
JUNE 2002
be evaluated based on pilot and/or additional system testing based on the

premise that it is not fully market tested.
Test Plan
Test plans are used to define and justify the extent and approach to testing.
Group or individual test cases are identified with any interdependence.
Note: The person who develops the system should not be the person who
develops the test and should not be the same person who executes the test.
It is important that testing is objective, challenging, and impartial.
The requirements traceability matrix (RTM) or equivalent mechanism should
be used to map tests to design specifications.
The test approach should:
Verify the normal operation.
Challenge the normal operation across the design range.
Challenge boundary limits.
Challenge failure modes.
Include power failure tests.
Test plans may be embedded in validation plans, combined with test cases, or
exist as separate documents. Test plans should be reviewed and approved
before the defined testing begins.
Test Case
Test cases provide the methods by which tests are conducted and the
acceptance criteria against which the test results are assessed. Test cases
should not introduce new requirements or specifications. Each test case
should include:
Objective of test.
Cross-reference to the part of the system specification that is being

tested.
Any prerequisites such as calibration or test data or other tests that

should be completed beforehand.
A reproducible test procedure.
Page 21 of 104
GlaxoSmithKline

1205
JUNE 2002
Details of data to be recorded during test or test evidence to be

appended (e.g. screen prints).
Acceptance criteria.
The detail of necessary testing will require some judgement. Test cases
should provide 100% requirements coverage to the URS/Functional
Specification. This can be achieved by showing within the RTM that all
URS/Functional specification sections have an associated test case. Full
branch/decision/condition coverage testing within the functionality supporting
these requirements is not usually practical. Testing nevertheless should aim
to challenge the system and demonstrate it as fit for purpose. It would be
expected that all product quality related data input/output and product quality
related decision points would be tested.
Test Results
All raw data and derived results obtained should be indelibly documented,
reviewed for integrity and against acceptance criteria, and subsequently
approved. The use of ticks, crosses, 'ok' or other abbreviations to indicate
acceptance are not generally accepted by regulatory authorities and should be
avoided. The testing results should include:
Actual test results and observations.
A statement (pass or fail) as to whether or not the acceptance criteria

have been met.
Dated signature for each person performing the test.
Dated signature for the person approving test results.
References to the incident log for test failures or observations.
Inconsequential issues raised with the test cases (e.g. typographical errors not
affecting the integrity of testing) can be annotated as cosmetic changes,
signed and dated, on the test case. Inconsequential issues raised with test
cases are not logged as test failures but the nature of the annotation should
be registered in the incident log so that the resolution can be tracked.
Test Failures
The person approving the test cases should consider the consequences of a
failure on the validity of completed testing. Further testing should be
performed/repeated where necessary. All test failures should be recorded in
incident logs.
Page 22 of 104
GlaxoSmithKline

1205
JUNE 2002
If the analysis of a test failure results in amendment to the test case or

associated specification, then the remedial action should be performed under
change control. Minor deviations from the acceptance criteria, where there is
no risk to GxP, may be accepted with the approval of the User and
QA/Validation. Such concessions should be recorded in the incident log and
justified in the test report.
Resolution of test failures associated with low risk functions, if indicated by the
requirement categorisation in the URS, may be deferred. GxP requirements
are not considered low risk.
Test Report
Test reports should be prepared in order to:
Collate evidence of testing (i.e. raw data).
Conclude each phase of testing.
Authorise any subsequent phase of testing.
The results of testing are analysed and summarised in a test report that
should state:
System identification (program, version configuration).
Identification of test cases and supporting raw data.
The actions taken to resolve incident log issues, with justification.
Whether the results meet the acceptance criteria.
The test report should not exclude any test data. The test report may be
combined with the test results.
4.6.
Deployment Phase
On completion of successful testing the system is ready for installation into the
final operational environment. During this phase the hardware and software
installation is qualified and operational checks are performed.
During this phase it is necessary to ensure that arrangements for the use and
ongoing systems support and maintenance are either established or that
documented plans have been prepared to ensure that these arrangements are
in place when the system becomes operational.
Page 23 of 104
GlaxoSmithKline

1205
JUNE 2002
Data Load
Plans, procedures and protocols should define the data load process. All GxP
data should be at least double-checked to verify that it has been correctly
loaded. Other checks should be put in place as required to verify original GxP
data is correct.
Statistical sampling can be used to check other data commensurate with the
business need to verify data integrity. Rationales justifying sampling regimes
should be defined. Automated data load tools should be validated.
Where data representative of the live environment is required for testing or
where data load/migration routines need to be tested prior to final load, the
data load/migration activity may be phased.
Operational and Support Plans
Operational and support plans should be established in order to ensure that
SOP, training, service contracts, business continuity plans, etc are
established, reviewed, approved and where appropriate tested before the
computerised system becomes operational. Support organisations (both
internal and external) should be periodically audited to verify continued service
in support of GQP 1205 and associated GxP regulatory expectations.
Security Management
SOPs for managing security access (including adding and removing

authorised users, virus management, password management and physical
security measures) should be specified, tested, and approved before the
systems is approved for use. Security management procedures should apply
to all users including administrators, super users, maintainers and normal
users.
User Procedures
SOPs should be established to define the use of the computerised system.

SOPs should be approved before the computerised system is approved for
use and available, even if only in approved draft form for operational
qualification (OQ).
Maintenance
The following areas should be addressed (where appropriate):
Recommended spares holding.
Frequency of routine testing/calibration.
Page 24 of 104
GlaxoSmithKline

1205
JUNE 2002
Backup and restoration of software and data files.
Performance monitoring.
Procedures covering maintenance activities should be specified, and

where practical tested, and approved before the system is handed
over for use.
Backup and Restoration
Backup copies of all software and relevant data (see GQG 3202) should be
taken, maintained and retained within safe and secure areas, protected within
fire safes. Backup and restoration procedures should be verified.
Data Archiving and Retrieval
Archiving and retrieval procedures for data should be specified, tested, and
approved before the system is approved for use. Careful consideration should
be taken of special requirements affecting the retention preservation,
protection and confidentiality of electronic records, including their associated
audit trail information (see GQG 3203 and 3301).
Availability of Software and Reference Documentation
All software (e.g. source code, compilers, operating system) and reference
(supplier) documentation should be available for inspection and copies should
be available for business continuity. Copies of the software should be
retained within safe and secure areas, protected within fire safes. Where
access to software is restricted, formal agreements should be established to
ensure software can be accessed when needed, e.g. ESCROW accounts.
Training
Training plans should be established for use and support of the computerised
system.
Business Continuity Plans
Procedures and plans supporting business continuity (disaster recovery plans

and contingency plans) should be specified, tested, and approved before the
system is approved for use. Topics for consideration should include
catastrophic hardware and software failures, fire/flood/lightning strikes, and
security breaches. Alternative means of operation should be available in case
of failure where critical data maybe required at short notice (e.g. in case of
drug product recalls).
Page 25 of 104
GlaxoSmithKline

1205
JUNE 2002
Installation Qualification
Checks should establish that the installation has been completed in
accordance with system specification. Checks should be based on:
Inventory checks (hardware models, software name and version, data,

user manuals and SOPs).
Operating environment checks (e.g. power, RFI/EMI, RH, temp).
Diagnostic checks (installation diagnostics and software launch).
The boundary of the system and hence the scope of the IQ should be defined
in the validation plan. An IQ summary report should be prepared and
approved prior to OQ commencing.
Operational Qualification
OQ should only commence on successful completion of IQ and involves user
acceptance testing of the base functionality of the computerised system.
System tests from the developer may be used to reduce the amount of OQ
testing conducted. The suitability of such testing and available documentation
must be reviewed and approved by QA for this purpose.
Testing should be designed to demonstrate that operations will function as
specified under normal operating conditions and, where appropriate, under
realistic stress conditions, OQ should cover:
Checking required functionality.
Checking de-selected functionality cannot be accessed.
Checking execution flows/sequences.
Checking calculations and algorithms.
Checking alarm and alert messages.
Checking timer accuracy.
Conducting system loading tests.
Verifying SOPs established to control the use and maintenance of the

computerised system.
Tests should reference appropriate functional specifications.

possible to train operators to help conduct testing.
It may be
Page 26 of 104
GlaxoSmithKline

1205
JUNE 2002
An OQ summary report should be issued on completion of OQ activities.

OQ may be conducted in a controlled off-line test environment. Alternatively
OQ may be conducted with the final system installed in-situ prior to its release
for use in the live environment. Test environments should be subjected to IQ
demonstrating they are, for testing purposes, equivalent to the intended live
environment.
For simple computerised systems IQ and OQ may be combined into a single
activity and documented accordingly. More complex computerised systems
may be divided into sub-systems and each of those systems subjected to
separate OQ.
This should be complemented by a collective OQ
demonstrating that the fully integrated system functions as intended.
System Release
Computerised systems are often released into the live environment following
completion of OQ, i.e. in advance of performance qualification (PQ). Final
evidence needs to be collected from the live environment to conclude that the
system is fit for routine use. However, to do this the system must be brought
into use in the live environment.
An interim validation report or alternative e.g. system release note should be
prepared, reviewed and approved in order to authorise system release. The
interim report should cover all aspects of the validation plan up to and
including OQ. Multiple reports may be required in order to phase roll out of
discrete aspects of the system or where there is a phase roll out to multiple
sites.
Performance Qualification
PQ should only commence on successful completion of OQ and comprises
product PQ and/or process PQ.
Product PQ establishes the confidence that the data-dependent output from
the system consistently meets specification across the defined range of output
variants. Examples of product PQ outputs include:
Batch reports.
Label variants.
Pharmaceutical product packaging variants.
Process PQ ensures that operational and support processes are effective,

reproducible and reliable. Process PQ typically include:
Monitoring of user enquiries.

Page 27 of 104
GlaxoSmithKline

Progressing data changes.
System availability.
System stability.
Problem resolution to incident logging.
Progressing system changes.
1205
JUNE 2002
Manual processes, such as additional data checks and report verification,

should be operated in parallel with the computerised system until the
completion of PQ.
Validation Reporting
A validation report should be prepared to conclude on the completion of the
activities prescribed in the validation plan. The validation report should
address each of the activities defined within the validation plan and confirm
that these have been successfully completed with a clear statement that the
system is validated and fit for purpose.
The validation report for a system should not be approved until all the relevant
documents defined within its validation plan have been approved.
Where there are deviations from the validation plan or unresolved incidents
then these should be documented and justified to allow the computerised
system to be used on an ongoing basis. Where critical unresolved issues
exist, then the system cannot be considered validated and should not be put
into use for GxP applications.
The validation report and supporting documentation should be lodged with the
relevant site validation manager.
4.7.
Use Phase
This phase of the system life-cycle describes the period of time when the
system is in operational use.
Service Level Agreements (SLA)
Certain requirements of the Use Phase may be provided by internal or
external support organisations. In such cases, a SLA or other similar
contractual document should be established to define the support service
provision. SLAs should address:
Scope of service.
Page 28 of 104
GlaxoSmithKline

1205
JUNE 2002
Service access and response time.
Controls applied in support provision.
Service performance monitoring.
Escalation procedures
Service definition (e.g. upgrades, fault reporting and resolution,

system performance monitoring, back-up and restoration, archive
management).
Implementation of Operational and Support Plans

During this phase, all SOPs, plans, contracts, etc established in accordance
with operational and support plans should be implemented.
Dial-In Support Services
Suppliers of sophisticated computerised systems may offer dial-in fault
diagnosis and correction. The use of such services is not prohibited, but
extreme care should be taken prior to allowing such remote access. Make full
use of local GSK knowledge prior to requesting dial-in support from the
supplier. Consider the following:
ERES requirements particularly with regard to the open/closed

status of the system.
Scope and nature of access the supplier has to the system

(e.g. configuration, operating system, raw data, electronic records).
Access to the system by the supplier should be controlled by GSK.
What software/diagnostic tools the supplier will use.
Audit of the supplier specifically relating to the support service offered.
Keystroke/Log reports which detail all actions performed remotely on

the system by the supplier.
Confidentiality agreements established with the supplier.
Formal support contracts agreed (this should include statements

relating to the above points).
Page 29 of 104
GlaxoSmithKline

1205
JUNE 2002
Upgrades
Upgrades to software (including new releases and bug-fixes) and hardware
(including model upgrades and replacement with like-for-like equivalents)
should be managed through change control. Necessary validation for the
upgrade will be influenced by:
Bespoke/custom versus standard characteristics.
Complexity.
Criticality of the operations performed.
Large-scale functionality enhancements, especially those, which involve a

change to the character of the system may require a full validation
reassessment. Minor changes, such as patches, should analyse any impact
to the existing functional specification and re-test affected functionality with
new supplementary tests as required. The document set for the computerised
system should be updated, as appropriate, to reflect the change.
Periodic Review and Revalidation
Validation reviews should be conducted on systems to verify the compliance
and validation status; the following factors need to be taken into account when
determining the frequency of review:
Criticality.
Number of changes made.
Changes in regulatory or company requirements.
Any requirements for refresher training should be reviewed (see also section
on deployment phase).
Reviews may recommend revalidation exercises for particular computerised
systems. Refer also to section on retrospective validation for guidance.
4.8.
Decommissioning Phase
At the end of the operational life of a system a process of decommissioning
takes place, which includes archiving data and system software. Careful
consideration should be taken of special requirements affecting the retention,
preservation, protection and confidentiality of electronic records including their
associated audit trail information (see GQG 3202 and 3301).
Page 30 of 104
GlaxoSmithKline
1205
JUNE 2002
Archiving activities should be planned and results collated. A plan should be

generated describing the archive approach, and a corresponding report issued
on completion listing documents, raw data, and electronic records archived.
4.9.
Cross Phase Activities

Several activities need to be managed and linked across a number of
life-cycle phases. Procedures should be established to ensure that the
following are maintained for the entire system life:
Requirements Traceability
RTMs or equivalent mechanism should be established to provide an
assurance that all requirements have been included in the system design and
tested to verify correct operation. The mechanism should provide a method of
tracing a requirement from the initial URS document to the functional
specification, design specification and through development testing and
qualification activities (IQ, OQ, PQ).
Change Control
Change control must be established for the project and ongoing use of the
system. Change control should be established within the planning phase and
apply to software, data, documentation, and hardware, including all supporting
infrastructure. GxP related changes should be reviewed and approved by QA.
Configuration Management
A system should be established to document, manage, and control the
versions of configuration items making up the computerised system through
the design and development, testing and use of the system. Configuration
management applies to software and hardware including operating system
versions, application software, data sets and bespoke/custom code.
Incident Management
Processes should be established to capture, document and resolve incidents
that occur during the life of a computerised system. An incident log should be
set up and used. The incident log records details of the incident, the
circumstances under which the incident was noted (e.g. reference to test
case) and the name of the person making the observation. Incidents can be
prioritised for resolution. An index for incident logs should be maintained. The
incident log should record remedial action, and consider any testing, including
regression testing.
Incident logs should be closed down at appropriate
stages, for example, at the end of a project, or upon completed installation of
a major release or upgrade.
Page 31 of 104
GlaxoSmithKline

1205
JUNE 2002
Documentation Management
The validation
documentation.
already exist,
documentation.
stored.
process should create and maintain a package of

Document management procedures, where they do not
should be established to manage and control such
The contents of the validation package should be securely
Raw data attached to documents, or existing in their own right, should be

clearly itemised, signed and dated. Sets of raw data should be physically
coupled together (e.g. bound or stapled). Raw data forming attachments to
documents should be marked as such (e.g. supplier audit exhibits and test
evidence). Sets of raw data should have each page marked as belonging to
the set and the front page signed and dated.
Documentation and raw data should be reviewed prior to approval and
maintained under change control.
Hand written amendments to
documentation and raw data should not obscure the original entry. All such
amendments should be signed and dated, and the reason for the change
noted. Pencils and white-over must not be used.
Training
All personnel developing, using or maintaining a computerised system should
be trained in the technical and procedural aspects of the computerised system
in order to attain a level of competence commensurate with their job
description.
A training plan should be developed to manage this activity. Training should be
conducted against approved user procedures. User training records should
be updated to reflect training given on the system. For non-GSK personnel
(including contractors or temporary staff who do not have a GSK personnel
number) a Curriculum Vitae including all relevant details should be retained by
the responsible manager, or included in the personnel training records.
5.
Retrospective Validation
Computerised systems should be validated prospectively. It is not acceptable to
implement a new computerised system and knowingly defer validation until after its
implementation. Retrospective validation, however, is acceptable when a change in
use brings a validation requirement to an existing system that did not previously
require validation. It is also acceptable to conduct retrospective validation when
addressing a change in regulatory requirements/expectations. Otherwise it is
expected that validated computerised systems will have been maintained in a state of
compliance.
Page 32 of 104
GlaxoSmithKline

1205
JUNE 2002
Retrospective validation should be conducted as a prospective exercise. It should

include preparation of current functional requirements, system specification and
testing which must be performed against these requirements. Existing documents
and specifications should be reviewed for accuracy and completeness and used
where possible. Retrospective validation may involve modifications, upgrades, or
replacement. Where system functionality does not meet current functional
requirements or regulation, system modification, upgrade or replacement may be
necessary.
Information regarding the operational history of a computerised system may be used
to supplement its validation. The change history of a computerised system should be
reviewed alongside any statements made about reliable operation. Anecdotal
evidence of reliable operation should not be used. Retrospective validation, however,
cannot rely solely on the operational history of a computerised system to justify its
ongoing use. (see GQP 1204).
Critical applications that cannot be validated or are unsupportable must be removed
from use unless corrective actions can be used to justify their continued use, e.g.
through the development of replacement programmes. Such rationales must be
documented and approved by QA, the business owner and a technical authority. It
must be understood, however, that regulatory authorities will expect where such
rationales are put in place that the legacy computer system will be phased out of use
within a reasonable time frame.
Interim corrective actions may be required if retrospective validation cannot be
achieved in a timely fashion. The degree to which interim corrective actions is
required will depend on a number of factors including the size of the existing
compliance gap and the proposed duration of continued use for the system.
5.1.
Gap Analysis
A systematic survey and gap analysis should be conducted on legacy
computerised systems.
The basis for assessing any gap should be
GQP 1205 and this GQG, plus any other relevant policies and guidelines such
as GQP 3202 and GQG 3202 on ERES. A checklist can be developed for the
validation documentation and an analysis made as to whether there is any
existing documentation, and where there is documentation, whether it fulfils
the intent of validation documentation outlined in this guidance.
5.2.
Priorities
Priorities should be established from the gap analysis and any retrospective
validation requirements identified. Prioritisation should take into account
relevant factors such as:
Product quality impact.
Page 33 of 104
GlaxoSmithKline

System criticality - business and quality.
Severity of non-compliance.
Validation status.
Complexity of system corrections needed.
Bespoke/custom or COTS system.
Ability of supplier to support changes.
Stage in system life-cycle.
ERES compliance status.
1205
JUNE 2002
A high level strategy for the site or for specified departments should be
developed to document the prioritisation and any key milestones.
Interdependencies between different streams of work should be clearly
identified. In some cases full compliance will not be possible until the software
supplier makes a new release of software/hardware available. Interim
corrective actions should be considered until a fully compliant solution can be
applied.
Immediate priorities are those computerised systems directly involved with the
manufacturing and despatch process and the critical quality related activities
that these systems support. Where non compliant legacy computerised
systems apply to a number of steps in the manufacturing and despatch
process, a step by step flow chart of the process highlighting the role of the
computerised system at each stage should be prepared.
Critical activities that relate to product quality should be identified and the
reliance on the legacy system should be assessed. Supplementary interim
measures should be used where the critical activity cannot be assured due to
the reliance on the computerised system. These interim measures must be
sufficient to ensure product integrity and effective disposition and release but
should be no more extensive than is necessary to achieve this.
5.3.
Interim Measures
An interim measure is an additional control applied in the process that reduces
the reliance on the computerised system performing a critical function. This is
normally achieved by requiring human rather than computer decision making
and often requires additional hard copy documentation.
Interim measures should be recognised as temporary and not be viewed as a
long-term alternative.
The inherent non-compliance of the legacy
computerised system must be addressed through further longer-term
Page 34 of 104
GlaxoSmithKline

1205
JUNE 2002
corrective action plans. Both short-term interim measures and the longer-term
plan for final measures should be available to show to inspectors.
The following are important principles that need to be understood in applying
interim measures:
Interim measures do not eliminate the need for full corrective actions
and do not overcome system non-compliance.
They are typically paper based, documented by procedures, and used

to supplement or replace certain computer transactions.
Interim measures are implemented to bring additional controls to

critical quality decisions or information where non-compliant
computerised systems are used.
Interim measures must be fully defined, documented and approved.
In practice it may be easier to achieve control by introducing or strengthening

another control downstream of the process that verifies the output (e.g. vision
system checking a labeller). Verification of output such as inspection through
sampling may also be a means to reduce reliance on the computerised
system.
Those critical activities that should be given particular consideration for interim
measures should include:
Stages in the process where status change occurs such as approval

of a raw material or intermediate product.
Critical processing activities that are reliant on computerised systems

such as dispensing.
Label information and printing.
Product quality related specifications held by or used by computerised

systems.
Sentencing/disposition of product, particularly approval to release to

the market.
Current hard copy systems that are already in place may provide the basis for
the interim measures and minimise the need for additional documents. Such
documents may require only minimal change to content or to the review and
approval mechanisms. The key aspects of these documents are:
They are a formal record and must be maintained with the batch
documentation.
Page 35 of 104
GlaxoSmithKline

1205
JUNE 2002
The minimum number of documents should be created and each kept

as simple as possible.
The key product critical information on each document must have

been obtained from a compliant computerised system or secure
approved hard copy source.
The documents should be reviewed and approved using the sites

normal mechanisms.
Extra personnel may be required to install and operate interim, as these will
usually require additional activities. The number of personnel will depend upon
the extent to which existing documentation can be used and the extent to
which interim measures are required. The main impact will probably be on
quality organisation personnel.
To minimise the disruptive effects of introducing additional procedures it is
crucial that each site focuses only on the critical quality related activities.
However, it is also important to understand how computerised systems
support the complete manufacturing and despatch process as this can be
more extensive than is expected. Examples of other activities include facility
maintenance scheduling, and customer complaints.
Each site will need to identify how it can justify the continued use of
computerised systems supporting such activities without the use of interim
measures. Justifications should be documented in rationales approved by
QA.
6.
Managing Hardware and Software

6.1.
Hardware Categories
6.1.1.
Standard Hardware Components

The performance capability of standard hardware components should
be documented along with manufacturers/supplier details and version
numbers. Hardware acceptance or IQ must verify installation and
connection of components. The model, version number and, where
available, serial number, of pre-assembled hardware should be
recorded. Pre-assembled hardware that is sealed does not have to
be disassembled. This may break warranty. In such cases the
hardware details can be taken from the hardwares data sheet or other
specification material.
6.1.2.
Bespoke/Custom Built Hardware Components

These requirements are in addition to those of standard hardware
components. Bespoke/custom items of hardware should have a
Page 36 of 104
GlaxoSmithKline

1205
JUNE 2002
design specification and be subjected to acceptance testing. A

supplier audit should be performed for bespoke/custom hardware
development. Assembled systems using bespoke/custom hardware
from different sources require verification confirming compatibility of
interconnected hardware components. Any hardware configuration
should be defined in the design documentation and verified in the IQ.
6.2.
Software Categories
It is important to understand that computerised systems often consist of
multiple software elements and that within a single system these elements
may represent a variety of software categories.
6.2.1.
Category 1 Operating Systems

These are established commercially available operating systems.
Applications are developed to run under the control of these operating
systems. Features of the operating system are functionally tested and
challenged indirectly during testing of the application. The name and
version number of the operating system is documented in application
design documentation and verified (installation qualification). Change
control should be applied to manage upgrades to the Operating
system in order to determine the impact of new, modified or removed
features on the application. Application revalidation shall reflect
degree of impact.
Examples include Unix, Windows NT and VMS.
6.2.2.
Category 2 Firmware
Typically these are embedded in commercially available pieces of
electronic equipment designed to perform discreet operations.
Configuration may be required in order to set up runtime environment
and/or process parameters. The name, version number and any
configuration/calibration for the firmware should be documented and
verified (installation qualification). Functionality should be tested
during OQ. Change control should be applied to manage any change
to firmware or configuration parameters. Operational procedures
should be established and training plans implemented. Supplier audits
may be needed for highly critical or complex applications.
Bespoke/custom firmware should be considered as Category 5.
Examples include weigh scales, bar code scanners, three-term
controllers.
Page 37 of 104
GlaxoSmithKline

6.2.3.
1205
JUNE 2002
Category 3 Standard COTS Software Packages

These are commercially available, configurable, standard software
packages providing an off-the-shelf solution to a business or
manufacturing process.
Configuration should be limited to
establishing the run time environment of the package. The system is
not configured to define the business or manufacturing process itself.
Runtime process parameters may be input to the application. The
name of the package and the version number should be recorded. To
satisfy
validation
requirements
critical
user
requirements
(e.g. security, alarm and event handling, calculations and algorithms)
need to be documented, reviewed and tested.
Supplier
documentation should be leveraged wherever possible (e.g. user and
technical manuals). Supplier audits may be needed for highly critical
or complex applications or where utilisation of the application within
the pharmaceutical industry is limited. Operational procedures should
be established and training plans implemented.
Examples of standard software packages include statistical analysis
packages, PLC-based manufacturing control systems such as
non-customised software for a coating pan controller, laboratory
instruments such as Fourier transform infrared (FTIR) and standard
diagnostic tools.
6.2.4.
Category 4 Configurable COTS Software Packages

These packages provide standard interfaces and functions that enable
configuration of user specific business or manufacturing processes
from pre-defined or customised modules. Complex systems often
have layers of software, with one system including several software
categories. Software packages and the platform should be well known
and mature before being considered Category 4 software.
A supplier audit is typically required in order to confirm that the
software package has been developed in accordance with appropriate
quality systems and that application development and support
organisations are robust and competent.
In the absence of a
documented quality system, suppliers should use this guide to provide
the foundation for establishing a suitable quality system to control
package development and support.
Validation should focus on the configured business or manufacturing
process. New and bespoke/custom modules should be handled as
Category 5 software.
The validation plan should document a structured approach to the
validation of the application. The full life-cycle should be addressed,
Page 38 of 104
GlaxoSmithKline

1205
JUNE 2002
although much of it is the developers responsibility and thus may be

verified during the supplier audit. The validation plan should reflect
supplier audit observations, application criticality, size and complexity
and should include strategies for the mitigation of any shortfall
identified in the suppliers system development process.
Examples include distributed control systems (DCS), supervisory
control and data acquisition packages (SCADA), manufacturing
execution systems and some LIMS and MRP packages.
6.2.5.
Category 5 Bespoke/Custom Software

These systems are developed to meet the specific needs of the
pharmaceutical organisation. Bespoke/custom developments may be
a complete system or extension to an existing system. Complex
systems often have layers of software, with one system including
several software categories.
A supplier audit will typically be required in order to confirm that
appropriate quality systems are in place to control development and
ongoing support of the application. In the absence of a documented
quality system, suppliers should use this guide to provide the
foundation for establishing a suitable quality system to control
application development and support.
The validation plan should document a full life-cycle approach to the
validation of the bespoke/custom application based upon the
life-cycles contained in this guide. The validation plan should reflect
supplier audit observations, application criticality, size and complexity
and include strategies for the mitigation of any shortfall identified in
the suppliers system development process.
Examples of bespoke/custom software includes bespoke PLC
programming
(e.g.
ladder
logic)
and
user
applications
(e.g. spreadsheet configuration and database customisation).
Page 39 of 104
GlaxoSmithKline

6.2.6.
1205
JUNE 2002
Summary of Software Categories
Category Software
Type
Validation Approach
Operating
Systems
Record version. The operating system will be

challenged indirectly by the functional testing of
the application.
Firmware
Record version of non-configurable

firmware and calibrate as necessary.
COTS
Record version and configuration of configurable

COTS firmware. Calibrate as required and verify
against user requirements.
Manage bespoke/custom firmware as Category 5
software.
3
Standard
COTS
Software
Packages
Record version and verify operation against user

requirements. Consider auditing the supplier for
critical and complex applications.
Configurable
COTS
Software
Packages
Record version and configuration, and verify

operation against user requirements. Consider
auditing the supplier for critical and complex
applications.
Manage any bespoke/custom programming as
Category 5 software.
Bespoke/
Custom
Software
Audit supplier and validate complete system.
Page 40 of 104
GlaxoSmithKline

6.2.7.
1205
JUNE 2002
Summary of Software System Documentation
Documents typically
prepared by GSK
Software
Category
2
Comments
May be combined with URS.
System Register
Per system, not per software category.
Validation Plan
Per system, not per software category.
For bespoke and critical COTS applications.
Supplier Audit
User Requirements
Specification (URS)
ERES Assessment
When the compliance assessment states

that the system must be validated.
System Overview
Consider as separate document, maybe

included in URS/functional specification.
Functional Specification
For standard COTS packages reference to

product specification is sufficient.
Detailed Design
Specifications
Maybe split into hardware and software

design documentation.
Data Definition
For projects that populate the new system

with existing data.
Design Review
Sometimes known as DQ.
Source Code Review
Configuration only for category 4 software.
Development Testing
Includes unit, integration, interface and

system.
Data Load
For projects that populate the new system

with existing data.
Performance
Qualification
Validation Report
May be in the form of a certificate for very

simple systems.
Operational and Support

Plans
Activities include user procedures, backup

and restoration, maintenance, security
management, business continuity plans.
Archiving and
Decommissioning
Special attention is required for electronic

records/signatures.
Qualification documents may be combined

as long as test plans and test cases are
collectively approved before testing. For
standard COTS category 2 qualification
may be based on calibration activities.
Note: No specific validation activities for standard COTS compilers and operating systems
beyond documenting version details.
Page 41 of 104
GlaxoSmithKline

7.
1205
JUNE 2002
Approach to Laboratory Systems

7.1.
Laboratory Systems Definition

Laboratory systems measure, record, and control laboratory equipment,
manipulate data, or provide information that is used in product quality control,
product release or submissions to regulatory bodies.
Laboratory systems include equipment that measure physical variables, store
and manipulate data for analysis (see GQG 3202). Laboratory systems may
also be linked to higher levels of computer integrated manufacturing systems
such as laboratory information management systems (LIMS).
Laboratory systems cover a wide range of computer applications, for example,
a pH meter with microprocessor control through to sophisticated
chromatography systems and software providing complex statistical data
analysis. Most laboratory systems comprise COTS products.
Four classes of laboratory systems are identified here:
Simple firmware COTS Instrument.
Non-configurable instrumentation with dedicated functionality. Analytical data

is displayed but no electronic records are retained.
User performs
calibration/set-up. Instruments with associated personal computer are
excluded from this class.
Complex COTS Instrument.
Non-configurable instrumentation with data acquisition, manipulation and/or

reduction software. Analytical data is typically displayed. Electronic records
may be retained.
Configurable laboratory automation.
Standard COTS supervisory control and data acquisition systems with user
configuration. Some of these systems can be considered as 'SCADAs'
because the PC supervises in the instrument activity (test parameters etc.)
collects the analytical data (e.g. spectra) and then performs data analysis
(e.g. spectral library matches).
Bespoke/custom laboratory application.
Customised and bespoke/custom

bespoke/custom instrumentation.
laboratory
system.
Includes
Page 42 of 104
GlaxoSmithKline

7.2.
1205
JUNE 2002
Scope of Systems Covered

Laboratory systems typically include the following:
Data acquisition and on-line analysis systems linked to production

systems. (see also guidance on control systems).
Data historian/trending/statistical analysis systems.
FTIR spectrophotometry.
Gas chromatography (GC) systems.
High performance liquid chromatography (HPLC) systems.
Networks and interfaces within the laboratory system and to any other
connected system (see guidance on IT Infrastructure).
Supervisory control and data acquisition (SCADA) systems (see also

guidance on control systems).
Systems controlled by standalone personal computers (PC).
Chromatography data systems (CDS).
Examples of computerised systems found in the laboratory for which guidance

is given elsewhere in this GQG:
7.3.
Database applications (see guidance on desktop applications).
Laboratory information management systems (see guidance on IT

systems).
Spread-sheet applications (see guidance on desktop applications).
Responsibilities
Many laboratory systems require both process and computer validation.
Combining process and computer validation offers an opportunity to
consolidate roles and amalgamate documentation.
For example, the
QA/Validation role may be taken by someone in a department that is
responsible for quality (e.g. QA/QC laboratory personnel), or a member of the
local QA/Validation personnel. Combining roles may be the only practical way
to tackle simpler laboratory systems.
Where roles are combined it is essential that the person conducting the work
is suitably qualified for the combined role and that they do not review or
approve their own work. Independent developer, user and QA/Validation
Page 43 of 104
GlaxoSmithKline

1205
JUNE 2002
roles should always be assigned. The specific assignment of personnel to

roles should be documented in the validation plan. Responsibilities must be
clearly defined throughout the lifetime of the system.
For systems where separate process and computer validation plans exist,
special consideration should be given to the interfaces and responsibilities of
the computer and process validation specialists.
The use of common proformas and templates is encouraged. Many
laboratory systems are of similar type/design, and as such there is an
opportunity to standardise on the approach to validation and to provide
efficient and consistent validation.
7.4.
Systems Register
All laboratory systems should be maintained on a single register at a site or
laboratory level as appropriate. The definition of what comprises a system
needs careful consideration. For example, many laboratory systems comprise
of a number of interchangeable items that should be managed under change
management not the system register.
7.5.
Validation Life-Cycle
The validation approach for a laboratory system may incorporate a number of
separate validation strategies as appropriate to its components. For example,
the overall validation approach to a SCADA system that controls several
balances might be to validate the balance based on the use of standard
firmware, and to validate the SCADA software based on the use of userconfigurable standard software.
The basic validation life-cycle for laboratory systems should be in line with this
guideline and support where necessary process validation requirements.
Simple COTS instrument, complex COTS instrument, configurable laboratory
automation, and Bespoke/custom laboratory application should be validated
focused on Category 2, 3, 4 and 5 software respectively but taking into
account any other software categories present in the laboratory system. The
following points provide some additional specific guidance for each of the
life-cycle phases as described in Section 4.
7.5.1.
Planning
Requirements should be specified by the users in consultation with
developers and laboratory personnel. Where new laboratory systems
are being introduced, either as a project in its own right or as part of a
larger project, it is important that the laboratory system (high level)
requirements are considered and identified at the project planning
Page 44 of 104
GlaxoSmithKline

1205
JUNE 2002
stage. For simpler laboratory systems, the validation activities may be

encompassed within the overall project validation plan.
Laboratory systems must be assessed for applicability with the ERES
regulations and functional and design specifications should be
developed to address necessary requirements. GQG 3202 provides
additional guidance on ERES requirements.
7.5.2.
Supplier Assessments
Supplier audits should be conducted for configurable software
packages and bespoke/custom software (see Section 6). Supplier
audits are not required for standard COTS software. It is important to
appreciate, however, that many COTS laboratory systems are sold in
very small numbers and the argument that they represent standard
software may not be appropriate. Rationales justifying why supplier
audits are not necessary should include information on how many
products for the version of interest have been distributed for use and
are currently supported.
7.5.3.
Requirements
Requirements should describe the intended use and equipment type,
including:
7.5.4.
User operation.
Operational ranges and tolerances.
Environmental constraints.
IQ/OQ protocol packages.
Maintenance and calibration requirements.
Communication interfaces to other equipment/systems.
Training and support.
Detailed Design
The documentation to support the design and code phase of the
life-cycle should be provided by the supplier of the laboratory system.
This design documentation is expected to comprehensively describe
the functionality of the laboratory system. This information may be
available for standard systems in the form of a datasheet published by
the supplier. Configuration aspects of the laboratory system should
Page 45 of 104
GlaxoSmithKline

1205
JUNE 2002
be included in the design documentation. Documentation of unused

and de-selected functionality should be included.
The detailed design includes the production of hardware, software and
associated instrumentation specifications. For embedded systems
these documents may include the preparation of mechanical and
electrical specifications/documentation. Detailed design and code
activities are not normally required for small/simple laboratory
instruments. For other laboratory systems, the general principles
described in Section 4 and 6 should be applied.
7.5.5.
Code Review
Source code reviews should be conducted for bespoke/custom
software (see Section 6). Evidence that the supplier has performed
source code review of the laboratory system should be available from
the supplier. Where code reviews have been conducted by the
supplier, auditing should be considered to ensure that the reviews
have been completed by competent individuals, independent from
those developing the code/configuration. When this evidence is not
available a review should be performed to identify what action needs
to be taken.
7.5.6.
Development Testing
It is expected that evidence of supplier development testing and
calibration should be available as part of the laboratory system
documentation.
Where the supplier does not provide specific
evidence of functional testing, an increased level of user acceptance
testing, which is supported by a testing rationale/plan, will be required.
7.5.7.
Pre-Installation Testing
Pre-installation testing should focus on ensuring the correct
configuration/set-up has been conducted, including any calibration.
7.5.8.
Qualification
IQ and OQ are typically combined. However, separate IQ and OQ is
recommended for complex laboratory systems. These qualification
protocols should be based on the requirements that are documented
in the system and functional requirement documents. Wherever
possible, provide specific documented evidence of testing in the form
of hard copy printouts.
PQ should be based on verifying system suitability tests. Other
testing requirements may also be included from the business and user
Page 46 of 104
GlaxoSmithKline

1205
JUNE 2002
requirements specification. PQ will verify the operation of the

laboratory system in the live environment.
A requirements traceability matrix (RTM) is expected where the
traceability of user requirements through design to test cases cannot
be easily demonstrated.
7.5.9.
Use
Ongoing use of the laboratory system should be supported by system
suitability testing, change control and routine recalibration.
7.5.10. Decommissioning
Special activities for archiving and decommissioning are required if
there are electronic records. Record retention policies may require
the supporting user and supplier documentation to be archived when
the equipment is decommissioned.
7.5.11. Special Considerations for Simple COTS Firmware
Instrumentation
COTS firmware instrumentation is non-configurable but the user can
perform calibration/parameter set-up. The validation requirements for
any associated personal computer workstations should be considered
separately.
For instrumentation the term qualification is sometimes used rather
than validation. This is because validation is largely based on
calibration and system suitability testing.
Nevertheless simple
validation plan and validation reports should still be produced.
Business and user requirements specifications are typically combined
as a single document that is designed to support the purchasing
process. Since the instrumentation is generally purchased on the
basis of equipment catalogues or supplier datasheets, it is expected
that the functionality will be pre-set and designed for a specific task. It
should be normal practice to use the suppliers standard literature
(datasheets) to document the functional specification. Where these
documents are generic (i.e. covering a range of models), the
requirements, specifically associated with the laboratory system are
subject to this validation exercise, and should be clearly identified
within the validation and support documentation. No further design
and code documentation is required.
Pre-installation testing should focus on ensuring the correct
configuration/set-up has been conducted, including any calibration. It
should be recognised, however, that pre-installation testing is not
Page 47 of 104
GlaxoSmithKline

1205
JUNE 2002
applicable to simple, smart instruments. For these instruments

configuration/set-up will take place at IQ/OQ and be documented in
the IQ/OQ records.
IQ and OQ are typically combined. Qualification should be based on
the requirements documented in the datasheets and manuals. This
protocol will typically be a verification of components, firmware
versions, and calibration. PQ is satisfied by system suitability testing
that may be repeated within analytical methods.
An RTM is not normally required because the laboratory systems
have limited functionality that can be easily traced manually through to
qualification.
ERES assessments will be required but should be simple to conduct
since most systems only deal with electronic raw data rather than
electronic records. Record retention policies may require the
supporting user and supplier documentation to be archived when the
equipment is decommissioned.
Ongoing use of the laboratory system should be supported by change
control and routine re-calibration.
The validation planning requirement may be proceduralised rather
than generate separate validation plans and validation reporting may
be through certification rather than separate validation reports
(e.g. instrument certification).
7.5.12. Application Networks
Where networks/interfaces are used by the laboratory system to
transfer data to, or to access analytical methods or raw data from
other systems (e.g. chromatography data systems), the
networks/interfaces should be qualified as part of the validation of the
overall system. See also guidance on IT Infrastructure.
Page 48 of 104
GlaxoSmithKline

7.6.
1205
JUNE 2002
Examples of System Categorisation

The following list gives guidance on the expected categories (see Section 6)
of some typical laboratory systems. The need to assess each system
individually is still strongly recommended.
8.
Laboratory Systems
Categories
pH Meter
Ultrasonic Bath
Mass Balance
High Performance Liquid Chromatography (HPLC)
1, 3, 4
SCADA system (no user defined macros)
1, 3, 4
SCADA system (with user defined macros)
1, 3, 4, 5
FTIR Spectrophotometry
1, 3, 4
Chromatography Data Systems (CDS)
1, 3, 4, 5
Laboratory Robotic Systems
1, 2, 3, 4, 5
Standard interfaces to other connected systems
3 or 4
Bespoke/customised interfaces to other connected systems
Approach to Control Systems

8.1.
Definition of a Control System

Control systems monitor and control production processes or environments.
Control systems include equipment that measure physical variables, present
and store data and through pre-programmed/configured control algorithms,
logic blocks etc., effect real time control on physical parameters. Control
systems may also be linked to higher levels of computer integrated
manufacturing systems.
A wide range of equipment is covered from, for example, a single loop
temperature controller through to a large distributed process control system
with thousands of inputs and outputs.
Page 49 of 104
GlaxoSmithKline

1205
JUNE 2002
Control systems may be sub divided into two main classes:
Embedded systems.
An embedded system refers to control systems that are delivered as an

integrated part of a piece of manufacturing equipment (e.g. filling machine,
centrifuge, packaging machine). Typically for these systems the control
system documentation and qualification will be combined with that for the
overall equipment, and the multi-disciplined engineering effort to produce this
associated life-cycle documentation will be the contracted responsibility of the
supplier.
Standalone systems.
A standalone system refers to control systems that are typically supplied to

control or monitor and collect data from a process, and are generally supplied
separate to the process equipment. Standalone systems typically could
include multi-loop controllers/PLCs used to control part of a process, and
SCADA/DCS systems used to control the process plant as a whole. These
systems may be integrated vertically with other management systems, and
with embedded systems covering individual items of process equipment.
These systems are generally developed and tested (factory acceptance
testing) in isolation before delivery to site. Following delivery and installation,
acceptance testing and qualification with the process equipment is completed.
8.2.
Scope of Systems Covered

Control system equipment typically includes the following:
Programmable logic controllers (PLCs).
Distributed control systems (DCSs).
Data historian/trending systems.
Supervisory control and data acquisition systems (SCADA).
Systems controlled by standalone personal computers (PC).
Loop controllers.
Data acquisition systems linked to production systems.
Expert control systems.
Intelligent Instrumentation and associated networks.
Page 50 of 104
GlaxoSmithKline

1205
JUNE 2002
Networks and interfaces within the process control system and to any
other connected system.
Examples of less obvious applications utilising control systems might be:
8.3.
Warehouse management systems.
Site entry systems.
Building management systems.
Responsibilities
Particularly for large DCS systems there are likely to be multiple
equipment/system suppliers, possibly systems integrators (configuring the
systems), a managing contractor and project team.
For systems where separate process and computer validation plans exist, the
interfaces and responsibilities of the computer and process validation
specialists should also be considered.
For less complex systems roles and responsibilities may be combined,
however independent developer, user and QA/Validation roles should always
be assigned.
Responsibilities should be clearly defined throughout the lifetime of the
system.
8.4.
Systems Register
The definition of what comprises a system needs careful consideration.
Where a large DCS is interfaced to embedded PLCs controlling process
equipment, the PLCs may be considered separate systems as they provided
discrete standalone functionality.
8.5.
The validation of control systems is one element of the equipment/process
validation. Control systems validation should be in line with this guideline and
support the process validation requirements. The following points provide
some additional process control specific guidance for each of the life-cycle
phases as described in Section 4.
Page 51 of 104
GlaxoSmithKline

8.5.1.
1205
JUNE 2002
Planning
For projects where control systems are only a part of a larger project,
it is important that the control system (high level) requirements are
considered at this stage. The user should specify requirements in
consultation with developer/engineers.
Control systems should be assessed for applicability with the
electronic records, electronic signatures regulations. For systems
where the regulations apply consideration as to how the system will
comply should be included within the requirements and functional
specifications. GQG 3202 provides additional guidance on ERES
requirements.
Co-ordination of activities with those defined in any associated
process/equipment validation plans is essential, particularly during the
IQ and OQ stages. For small process control systems, the validation
activities may be encompassed within the overall project validation
plan.
8.5.2.
For embedded control systems it may be more efficient to have a
combined audit to establish the suppliers capabilities with respect to
mechanical and electrical activities in addition to control system
development.
Development and maintenance organisations may operate from
different locations and to different quality management systems. The
need to assess both the development and maintenance organisation
should be assessed and documented in the validation plan.
8.5.3.
Requirements Phase
The user requirements specification (URS) for large applications,
e.g. DCS or SCADA, may involve the development of a separate URS
for just the control system. The advantage of this approach is that it
helps to focus the software developer on the control functionality
aspects. A separate requirement specification should provide
appropriate production process and product information, electrical and
mechanical details and performance requirements.
For embedded systems the control system functions may be included
within the overall specification for the machine or equipment.
The physical parameters to be monitored/controlled and the data to be
generated by a control system should be clearly documented during
the specification phase. These parameters and data should be
Page 52 of 104
GlaxoSmithKline

1205
JUNE 2002
reviewed
with
regard
to
their
overall
function
(GxP, safety/environmental, process control) and level of criticality. A
categorisation of parameters and data should be carried out to ensure
the design and testing of both hardware and software associated with
each is appropriate for the function and level of criticality. This
information provides the basis for the traceability of critical parameters
and data through the design process to the final testing stage. This
traceability can be documented as a requirements traceability matrix
(RTM).
8.5.4.
Design and Code Phase

Functional Specifications
The structure of Functional Specifications should be tailored to suit the
category and complexity of the system, some examples are provided
below for guidance:
Embedded system.
Typically a single document combining computerised system and

overall functional specification (process, mechanical, electrical etc.)
for the equipment is appropriate.
Small SCADA system.
The functional specification typically only covers the control system

(i.e. not process, electrical or mechanical etc) and is often termed a
functional design specification where it combines sufficient detailed
design information for the system to be configured and built.
Complex DCS.
The functional specification often consists of multiple documents,

typically one for each process unit covered by the system and/or a
functional specification for each area of functionality, e.g. sequence
logic, device/interface logic, trips and alarms etc.
Detailed Design
The detailed design includes the production of hardware, software
and associated instrumentation specifications. For embedded systems
these documents may include the preparation of mechanical and
electrical specifications/documentation.
Page 53 of 104
GlaxoSmithKline

1205
JUNE 2002
Control systems differ to IT and laboratory systems in terms of the

direct interface to the manufacturing process and field
instrumentation/plant equipment. Within the detailed design therefore
consider the following key documents:
Plant/equipment layout drawings.
Engineering line drawings/process and instrument drawings.
Loop/Instrument schedules and alarm/trip schedules.
Process description/sequences.
Interconnection drawings.
Design Review
The fundamental purpose of a design review is to ensure that the user
and functional requirements have been addressed satisfactorily within
the design of the system. Mechanisms such as requirement
traceability matrices (RTM) can therefore assist in the design review
process.
For larger systems with multiple design documents, there are likely to
be multiple design reviews. Some form of hazard and operational
study (e.g. CHAZOP) should also be performed on the system.
For larger and/or more complex control systems some detailed design
information may not be available until later stages of the project,
e.g. alarm settings. The use of 'holds' within documents is
recommended to allow work to continue, with each hold logged and
subject to review once resolved.
For embedded systems where there are no safety/operability issues,
design review may consist of a simplified process to ensure that GSK
requirements have been covered within the suppliers standard
document set.
Code Review
During the design phase the configuration languages and complexity
should be considered in order to establish the approach to code
review.
Where the supplier has conducted code reviews, auditing should be
considered to ensure that competent individuals have completed the
reviews and that they are independent from those developing the
code/configuration.
Page 54 of 104
GlaxoSmithKline

8.5.5.
1205
JUNE 2002
Development Testing Phase

Testing of the system should be a combination of off-line simulation,
and integration testing utilising plant/equipment, in order to
demonstrate the operation of equipment under computer control.
Thorough system integration testing and usually factory acceptance
testing should be completed prior to delivery of the system to site.
This is particularly important for more complex systems such as DCS.
Where pre-installation test activities are well documented, with
supporting evidence and have been executed to the principles of
cGMP, then these may be used to support OQ. Particular attention
should be focussed on stress and boundary testing at this stage as
performing such tests in a 'live' environment on process plant may not
be possible.
Simulation tools are often used to simulate both the input/output (I/O)
devices (instrumentation and control devices) and the operation of
devices and process for example when the DCS sends an output to
open a block valve, the corresponding confirmation inputs are
transmitted back to the DCS by the simulation package.
The use of such tools is generally to be encouraged as these provide
the opportunity to perform more thorough, realistic and challenging
tests to the control system software; particularly in terms of stress
testing where these could potentially cause damage to process
equipment.
It is not considered necessary to formally validate simulation
packages where the following points have been addressed (see also
guidance on software tools):
The system vendor has approved use of the simulation tool.
The simulation tool cannot, itself alter the configuration of the

control system.
The use, scope and limitations of the simulation tool are

documented.
The nature and scope of changes required to the control

system configuration for the simulation tool to operate
(e.g. disabling of I/O scan blocks) are understood and
documented.
Page 55 of 104
GlaxoSmithKline

1205
JUNE 2002
Any configuration of the simulation tool itself is documented and

verified.
Simulation is not used instead of formal OQ and PQ in the 'live'
process environment.
8.5.6.
Deployment Phase
Operational and Support Planning
Control systems should have hardware maintenance and diagnostic
procedures, a list of manuals or procedures specifying how the
equipment and process instrumentation will be maintained and
serviced, including security methods for computer hardware.
The purpose of IQ is to demonstrate that the system (including
software, hardware and equipment) has been installed according to
the manufacturers specifications.
The configuration parameters of standard instruments should be
recorded in the equipment IQ.
Hardware and equipment IQ establishes that adequate documentation
for the installation of the system is available, and that the system is
properly installed (as per the appropriate specifications).
A typical list of documentation that should be available for hardware
and equipment IQ includes, but is not limited to, the following:
Documentation describing all hardware components and any

peripherals associated with the system including CPU,
interfaces and instruments, printers, etc.
List of instruments and field devices associated with the

system.
Documents describing all network and communication

hardware (including for larger systems a network/topology
diagram) associated with the system.
Documents describing all wiring and connections associated

with the system.
Documents describing all electrical connections, including

grounding and shielding.
Page 56 of 104
GlaxoSmithKline

1205
JUNE 2002
Documents describing the actual accuracy of I/O devices and

instrument associated with the system.
Documents describing switch settings, internal and external, to

configure the system as specified.
List of the loop drawings that indicate the writing terminal

address on each process control panel, field equipment panel,
field sensor, control device and alarm.
Documents describing environment condition requirements for

the system and associated equipment, including temperature,
humidity, dust, static, power fluctuation (power supply stability),
electromagnetic interference and radio frequency interference
(power line noise and required filtration).
Documents describing the systems total core and storage

capacity as installed.
Documents describing calibration requirements for associated

instruments and equipment.
The purpose of OQ is to ensure that the system functions in the user
environment as intended.
Hardware and equipment testing.
This area will ensure that physical devices attached to the control
system operate correctly and over the required ranges (may be
termed hot loop testing). This area also includes testing of trips,
interlocks and any other safety/guarding devices.
This aspect may also cover verifying display information, and verifying
that devices can be operated (manually) from the system note that
this activity may be conducted as a separate activity. Data capture,
archiving and retrieval systems can also be tested within this phase.
Functional acceptance testing.
This should be designed such that the testing covers the entire range
of the systems specified operating parameters and also demonstrates
system repeatability over a number of test runs.
System tests should include testing the system under stress
conditions where these cannot be effectively tested during factory
acceptance testing. Some examples are:
Page 57 of 104
GlaxoSmithKline

1205
JUNE 2002
Verifying the full-scale measurement capability during hot loop

testing.
Verifying system operation with multiple operator requests.
Verifying the capability of the system to deal with multiple

critical alarms.
Radio Frequency Interference (RFI), Electro-Magnetic

Interference (EMI) susceptibility of the system.
For many active pharmaceutical ingredient (API) manufacturing

control systems (SCADA and DCS), OQ is frequently split into two
phases, OQ1 and OQ2 and performed in conjunction with the process
validation activities. Typically OQ1 includes all activities up to and
including system testing using water runs in plant, OQ2 generally
covers systems testing utilising solvent and commissioning batches.
For secondary manufacture, OQ will typically involve the use of
placebo, bottles, boxes, ampoules etc., but not necessarily product.
Pre-installation tests (e.g. Factory Acceptance Testing) may be used
to support (but not replace) OQ activities where these have been
conducted to GxP principles. Further, certain tests may only be
possible within a simulated/environment off-line.
This should always be performed at the user site and include testing
specific to the user environment and defined ways of working.
Frequently for control systems, PQ will be conducted as part of an
overall process validation activity. Where this is the case the
associated
validation
documentation
should
have
clear
cross-referencing to indicate this.
Post Implementation Monitoring
In addition to general areas described in Section 4, consider the
following:
Trips and alarms frequency of nuisance alarms, number of

'standing alarms' on the system.
Operability is the plant being operated in line with the original

philosophy for example where a high degree of automation is
available is this being used or is the plant effectively being run
in 'remote-manual'.
Page 58 of 104
GlaxoSmithKline

8.5.7.
1205
JUNE 2002
Are system maintenance and calibration (support) procedures

being completed (including support agreements with system
suppliers).
Configuration changes inevitably with control systems minor

configuration changes are required through the life of the
system.
Verify that the change control system is being adhered to and

that the number of minor changes is not excessive.
Use Phase
Operational and support plans are implemented as stated in the
management principles. Periodic review and revalidation will be
conducted in accordance with criticality of the system to the
production process.
8.5.8.
Decommissioning
For control systems with ERES functionality particular care should be
given to archiving of the electronic records, raw data and system
software (including configuration).
For control systems with non-standard data formats and hardware
consideration should be given to migrating data to portable data
formats (using a validated process) or retention of hardware to allow
retrieval of data/records.
8.5.9.

Change Control,
Management
Configuration
Management
and
Incident
Changes to associated manufacturing processes or equipment are

likely to have an effect on the associated control systems.
Consequently, process or equipment change proposals should trigger
an assessment of whether the associated control system requires
modification.
Document Management
Control systems are often dependant on documentation that is not
'owned'
solely
by
the
control
system.
For
example,
instrument/electrical schedules, Engineering line diagrams (ELDs),
process and instrumentation diagrams (P&IDs) and process
descriptions. It is therefore important that a clear cross-referencing
Page 59 of 104
GlaxoSmithKline

1205
JUNE 2002
system is established to these 'external' documents (see also change

control section above).
Where 'as built' changes have been included on documentation such
as ELDs/P&IDs, these should be reviewed for any potential impact on
the control system e.g. accuracy of process diagrams displayed on
operator screens.
Page 60 of 104
GlaxoSmithKline

8.6.
1205
JUNE 2002

The following list gives guidance on the expected categories (refer to
Section 6) of some typical process control systems. The need to assess each
system individually is still strongly recommended.
Process control systems type
Categories
Loop Controllers
Smart Instruments (analogue transmission of

variable)
process 2
Smart Instruments (digital transmission of process variable)
2, 3
Intelligent Instruments (without control/logic functions)
1, 2, 3
Intelligent Instruments (with control/logic functions utilised)
1, 2, 4
PLCs (customised system)
1, 5
PLCs (embedded system with no customisation
1, 4
SCADA system (no user defined macros)
1, 3, 4
SCADA system (with user defined macros)
1, 3, 4, 5
DCSs (standard configuration)
1, 3, 4
DCSs (customised e.g. Visual Basic routines)
1, 3, 4, 5
Data acquisition systems

macros/programming)
(configured,
but
no
user 1, 4
Expert Control systems
1, 4, 5
Standard interfaces to other connected systems (e.g. MRPII, 3 or 4

LIMS, MES)
Bespoke/customised interfaces to other connected systems
Smart Instruments report one process parameter (on an exception basis the
instrument can be interrogated for configuration such as range and
engineering unit). Intelligent instruments (e.g. Fieldbus devices) control
multiple process parameters and implement control functions.
Page 61 of 104
GlaxoSmithKline

9.
1205
JUNE 2002
Approach to Desktop Applications

9.1.
Definition of Desktop Applications

The name desktop application identifies software that is the result of a users
adaptation (i.e. configuration) or extension through software development
(i.e. entry of calculations or macro coding) of readily available software
packages, such as MS Excel, MS Access, or Lotus Notes. Another common
example is user scripting of report queries for systems that may be under the
control of another group, such as IT. In comparison to purchased software
systems or those developed by internal groups such as IT, desktop
applications are usually smaller in terms of code volume, complexity, number
of users, and robustness of features or functionality provided.
Common characteristics of desktop applications are:
9.2.
Configured and/or created using the development capabilities

provided within COTS packages on standard GSK PC builds and IT
approved software.
Created and supported by a user or user group to provide

supplemental information processing or reporting capability not
available in existing electronic or paper systems.
Are typically not 'stand-alone' programs, for execution they rely upon
the environment provided by the package from which they were
created.
Scope of Applications Covered

Several packages such as MS Excel are available to the GSK user community
via the standard Desktop configuration. This section of the guideline
addresses validation of the application created by using such packages and
not the package itself.
The most common examples of packages from which desktop applications are
created include MS Excel, MS Access, Lotus Notes, MS Word, and report
writer packages for databases, such as Oracle.
This guidance is intended for relatively small, simple, and low impact
applications.
Exclusions from the scope of this guideline include:
Software developed in a traditional programming language such as

C++ or the 'stand alone' Visual Basic development environment.
Applications that employ, process, or store electronic signatures.

Page 62 of 104
GlaxoSmithKline

1205
JUNE 2002
Applications that interface systems that are not desktop applications

(e.g. interfacing LIMS with a network chromatography system).
Further review is advised whenever an application, which is to be created with

a package such as MS Excel or MS Access, appears too complex or large for
validation as a desktop application. Such a determination suggests a poor fit
between the technology and the intended functionality. For example, it would
be unreasonable to replace the sophisticated features and controls of a
commercial LIMS system with a series of MS Excel macros or a MS Access
database.
Word processor and spreadsheet packages (e.g. MS Word and Excel) are
often used as electronic typewriters to create simple output such as reports
and forms, i.e. information that is not processed by the software package.
The files created by these packages to provide typewriter functionality are not
considered desktop applications and do not require validation, since there is
no additional coding or configuration to specify, review and test. The inclusion
of calculations, automated graphs, automated data extraction/reduction or any
other programming logic such as macros indicates creation of a desktop
application and the typewriter exclusion is no longer applicable.
Where files created by packages are used in the context of a larger system,
such as creation of documents with MS Word for management within an
electronic document management system (EDMS), validation of all
components should be addressed as part of the larger system.
When in doubt on the applicability of this guidance for a specific application,
consult local procedures or QA/Validation staff for further guidance.
9.3.
Responsibilities
For smaller desktop applications, which are expected to be the majority of
cases, roles may be combined such that the author performs the roles of User,
project manager, and Support/Maintenance. These roles may also be
assigned to one, two or three different people depending on the complexity
and size of the effort. However, independent review is required. A person
should never sign as reviewer or approver of their own work.
Authors should be competent in the development and/or configuration
capabilities of the packages from which they develop desktop applications.
The QA/Validation role can be assumed by someone in a department that is
responsible for quality (e.g. QA/QC laboratory personnel) or a member of the
local QA/Validation staff.
The specific assignment of personnel to roles should be defined during
validation planning.
Page 63 of 104
GlaxoSmithKline

9.4.
1205
JUNE 2002
System Register
A list of desktop applications requiring validation should be maintained on a
system register (see Section 3). Desktop applications such as spreadsheet
and databases however are extensively used applications and the vast
majority do not require validation. As a consequence it may only be practical
to list those requiring validation on the system register. Where this approach it
taken it should be documented in a rationale approved by QA.
9.5.
Two approaches to desktop application validation are provided, one for very
simple 'one-off' applications that are typically used once or a very limited
number of times and another for more complex applications that are difficult to
verify or will be used for an extended period of time.
The approach for one-off desktop applications is based on a complete review
of the results and retention of evidence to support that review (e.g. printing
and retaining verified spreadsheet formulas) rather than adherence to a
life-cycle. The one-off approach may also be appropriate for easily verified
applications that will be used indefinitely, for example, a spreadsheet that
simply reformats a small amount of information from another system.
The approach for desktop applications not considered one-off will broadly
follow the validation life-cycle described in Section 4 but guidance is provided
for streamlining activities in accordance with the scale of the application.
9.5.1.
Compliance Assessment and System Registers

The determination of GxP significance for desktop applications should
follow the same rules and logic as other types of applications. ERES
should be considered as per GQP/G 3202. Since desktop applications
often interact with or report data from other systems, the GxP
significance of any systems the desktop application interfaces to
should be considered in the assessment. It is expected that QA will be
consulted for determination of GxP significance of systems/software.
A key difference for desktop applications is that individual written
assessments of GxP significance and systems register entries are not
required for one-off and non-GxP desktop applications. Instead a
single entry in the system register (with associated compliance
assessment) can be made to capture certain types of non-GxP
desktop applications such as non-GxP spreadsheets applications
(see Section 3).
The decision that the desktop application is one-off or non-GxP should
be agreed between the user and local QA/Validation personnel,
Page 64 of 104
GlaxoSmithKline

1205
JUNE 2002
GxP desktop applications that are not one-off should have a written
assessment of GxP significance and be maintained on a systems
register in the same manner as other systems.
9.5.2.
Desktop Applications (Not One Off)

The validation life-cycle is broadly in line with the model specified in
Section 4 of this guideline. A key difference from other systems, such
as LIMS or networked chromatography data systems, is that the
desktop applications are usually so small and simple as to warrant
overlap in the phases and combination of most activities. This
guidance provides a means of scaling the general life-cycle
expectations to desktop applications.
Planning
The decision to validate using the desktop application approach
should be documented in a compliance assessment. Validation plans
should be prepared as described in Section 4. Local procedures may
be used as 'generic' plans or controls for desktop applications in
cases where little or no variability would be expected if separate plans
were created for each application. For example, a generic validation
plan could be embodied in a local procedure to address the needs of
most MS Excel spreadsheets.
Considerations for Documentation Efficiency
Activities for the phases up to but not including the execution of test
plans/cases may be combined commensurate with the size and
complexity of the application. For the simplest of applications, such
as a spreadsheet that only calculates linearity, the activities up to test
execution may be combined within one document. More complex
desktop applications, such as databases or spreadsheets with
macros, will require more granularity (e.g. separate specification and
design documents) due to the higher level of complexity and inherent
risk of expending a significant volume of effort without review/approval
of preceding life-cycle activities. The type and detail of specifications
and testing should be planned in accordance with the expectations of
the applicable software categories.
Desktop applications may be controlled using change control,
configuration management, and incident management methods
already established for other types of applications. Alternatively, more
focused and streamlined (i.e. simpler) processes may be established
for a specific application or group of applications as long as they
satisfy the content expectations of Section 4 and are defined during
validation planning or local procedures. Implementation of such
Page 65 of 104
GlaxoSmithKline

1205
JUNE 2002
controls may be as simple as a version log sheet for configuration

management of a spreadsheet application.
Inclusion of the life-cycle documentation within the created
application, such as adding one or more worksheets to a MS Excel
workbook, is allowed when supported by the package. Printing out
and signing the applicable components constitutes approval of such
embedded documentation.
Documentation may be stored locally to the user or maintainer but
should be kept in a secure location, e.g. locked cabinet.
Supplier audits will generally not be required for desktop applications.
By definition, desktop applications are internal systems developed by
company staff using well-known, widely available, packages with
development and/or configuration capabilities. Additionally, testing of
the resultant application implicitly verifies the integrity of the
underlying package further minimising the value of auditing the
package supplier. The purchase of externally developed applications
and the application of new packages with limited quality history are
exceptions in which audits should be considered. The extent to which
intended functionality of the desktop application can be fully qualified
through testing should be considered in the audit decision for these
exception situations.
Electronic Records and Electronic Signatures
Desktop applications should be assessed in accordance with
GQP 3202. Specifications for desktop applications that include
electronic records should include the requirements identified in
GQP 3202. Any system that employs electronic signatures should not
be validated as a desktop application. A generic ERES assessment
report may be used for all desktop application used by the site
provided they are managed/controlled using the same desktop
application validation procedure and stored in the same qualified
server.
Specifications and Design Review
The desktop application may be so minimal that creation of separate
User/Business requirements, system requirements, functional
requirements, system overview and data definition sections would
needlessly replicate the same information. These sections may be
combined into as little as one section of one document as long as this
approach is addressed during validation planning and all applicable
Page 66 of 104
GlaxoSmithKline

1205
JUNE 2002
information is included.
A suggested title for the composite
description of this information is 'specifications.'
Literature references to support calculations or other specific
requirements should be used rather than replication of the information
in the specifications when the source documents are controlled and
maintained to appropriate retention schedules.
Design review should be conducted in accordance with the guidance
provided in Section 4 but the summary of the review, and any planned
remedial activities to address deficiencies, may be included in the
Specifications documentation. A separate design review report is
suggested only for the more complex desktop applications.
Coding, Configuration and System Build
Coding or configuration prior to design review is acceptable for simple
applications in which there is minimal time lost and minimal risk if the
application does not provide the intended functionality. This exception
is strongly discouraged for relatively complex applications such as
those requiring more than one or two hours of development and
testing effort.
Code Review and/or Configuration Review
When the desktop application includes development of
bespoke/custom source code, a review of that code should be
performed to determine the following:
The code conforms to the specifications.
Appropriate header information in software listings such as

author, version, and change information are provided.
The code is free of non-executable (dead) code.
Additional programming guidance or standards should be considered

for more involved desktop applications such as databases and
complex spreadsheet macro programming.
Any configuration should be reviewed to verify the intended function of
the application. When configuration results in the creation of code,
that code should be reviewed in accordance with guidance
immediately above. Whenever possible, unused options should be
disabled through configuration. When disabling is not allowed by the
desktop application package, clear user instruction should be provided
to ensure only the appropriate options are utilised. Unused options are
not considered dead code.
Page 67 of 104
GlaxoSmithKline

1205
JUNE 2002
Review results may be documented by as little as one or two

sentences that reiterate the objectives of the review and that the
conditions have been satisfied.
Development Testing and Deployment Phases
Test plans and cases for these phases may be consolidated into as
little as one test script for very simple applications and may be
combined with prior activities as long as the test documentation is
approved prior to execution. With rare exception, it is anticipated that
the general guidance for the development testing phase
(see Section 4) will be applicable but additional types of testing are
not required if they would simply repeat prior testing or are
inappropriate for the application. For example, integration or interface
testing is unnecessary for a small spreadsheet. The approach to
testing and any combination of activities and deliverables should be
addressed during the validation or test planning activities.
Installation, Operational, and Performance Qualification
Separate documents titled IQ, OQ, and PQ are not required for simple
desktop applications if similarly named sections are included within
other testing and deployment phase documentation. The OQ and PQ
information may be combined within one section of documentation.
IQ documentation should, at minimum, provide the following:
Identification of environment requirements for the application

(e.g. version of MS Excel for which the application has passed
testing and any applicable hardware standards).
Instructions for installation of the application.
Verification that installation was in accordance with those

instructions and the environmental requirements.
Identification of all computers on which the application is

installed.
Installation instructions and operating environment information are not

required for applications that are tested in the environment they will be
used (e.g. simple spreadsheets that are not copied, moved to
designated folders, or loaded on other computers prior to their
production use). GxP desktop applications should be used on
validated servers or PCs.
Page 68 of 104
GlaxoSmithKline

1205
JUNE 2002
OQ testing is not required if development testing fully addressed all

specifications and was conducted under normal operating and stress
conditions. OQ testing is encouraged under the following conditions:
The target environment is different from that in which prior

testing was conducted (e.g. different version of operating
system or MS Excel).
Single user testing was conducted however, the application will

be used by multiple users (e.g. multi-user database).
The application will have interactions with other systems that

were not simulated in prior testing.
PQ is not required if prior testing is performed in the environment in

which the application will be used. This exception should be justified
during validation planning. Complexity, function, the extent to which
prior testing covers the User/Business requirements, and the added
value of parallel running with any displaced manual ways of working
are also key considerations when assessing the need for PQ. For
example, there is likely little value in PQ for a two-calculation
spreadsheet but a multi-user database that replaces several paper
processes is a strong candidate for PQ.
User Procedures and Training
User procedures and training can be as minimal as instructions
embedded within a very simple spreadsheet. A slightly higher level of
application complexity might combine the embedded instructions with
a brief walk-through of the application. The most complex desktop
applications should adhere to the guidance for formal procedures and
training provided in Section 4. For example, procedures and formal
training may be established for a multi-user database system and
become part of a departments training curriculum whereas a much
simpler spreadsheet application may only include a few instructions
viewed at the top of a spreadsheet when opened. The appropriate
method of training and control should be considered during
validation planning and the users should know of any required training
or applicable procedures prior to using the application.
It is recommended that contact information be provided either within
desktop applications or local procedures for user questions,
suggestions, or problem reporting.
Page 69 of 104
GlaxoSmithKline

1205
JUNE 2002
Backup and Data Archival/Retrieval

The primary considerations for maintenance are backup/restoration of
the application and data. If the application does not store data then
periodic backup and data archival are not required since applications
can be restored from the backup performed at the conclusion of
validation (the master copy).
When required, the method by which both the application and any
data are backed-up and restored should be addressed by procedure.
Procedures for these activities should address the needs of the
application but, for flexibility, are not required to be specific to a
particular application. For example, a department or site may
establish a backup/archival/restoration procedure applicable to all
spreadsheets. However, the person responsible for each application
should be readily identifiable (documented using a logbook or other
means). Such procedures should ensure retrieve-ability of any
electronic records throughout the applicable retention period. The
regulatory expectations for retention of electronic records created by
desktop applications are no different than other types of systems.
Security Management
Desktop applications should be protected from both alteration of the
application itself (source code and/or configuration) and any stored
data.
To the extent possible, applications that store data should use the
security mechanisms available in the underlying package to preserve
application and data integrity. For example, MS Excel password
protection can be employed to lock all but input cells, protect the
workbook structure, or save the file as read-only. Databases should
be configured with differing levels of access security tailored to the
actions that will be performed by various users.
The security of many desktop applications can be tremendously
improved by placing the application on servers with managed access
control. Security for the servers should be configured such that users
can access the application in read-only mode or make a one-use copy
which they delete after results are reported. For example, a validated
spreadsheet with a macro for extracting and trending sample results
from a LIMS database placed on a secure server, executed from that
server to create a report, and then closed without saving of results
due to the read-only status of the server directory.
Administrative or master passwords which allow users to modify the
application or make data changes outside the intended control of the
Page 70 of 104
GlaxoSmithKline

1205
JUNE 2002
application logic, should be restricted to defined roles responsibilities

for maintenance of the applications. Such passwords should be kept
secret and known only to the define individual. It is recommended
that such passwords be changed upon completion of validation and
strictly controlled thereafter. An example control scheme would be to
store the password in a confidential envelope in a locked cabinet
accessible only to the application maintainer. A history of password
access and changes could be kept on a log in the same envelope. In
exceptional conditions, such as the maintainer forgetting the password
or leaving the company, the password could be retrieved from the
sealed envelope. Password sharing is not recommended but may be
necessary for some packages that do not allow multiple accounts for
administration activities.
While technical controls such as password locking are by far the
preference, procedural controls may also be used to enhance the
security of a desktop application. The more limited the available
technical controls the less appropriate it is to introduce or continue
use of the application in the regulated environment.
All security mechanisms should be identified in the planning phase
and subsequently tested or verified. The testing and verification
should address both the security features that are designed as part of
the desktop application itself and any configured environmental
controls such as access rights for an application placed within a
read-only server share.
Consult local QA/Validation and IT staff for guidance on locally
available environmental security options (e.g. administration of secure
area on local server) and additional guidance on securing your
specific desktop application.
Periodic Review, Revalidation, and Business Continuity Plans
Periodic review is required but may be as simple as a statement
reflecting that the operating history of the application has been
reviewed and the application continues to satisfactorily provide the
intended functionality. Revalidation is not required but should be
considered where the results of periodic review are not satisfactory.
The revalidation effort may be as simple as documenting the
re-execution of a set of test data. However, multi-user database
systems and similarly complex systems will require more
comprehensive revalidation actions that should be commensurate with
the complexity and function of the system. Business continuity
planning is not required but should be considered for systems where
reverting to manual processes is not feasible.
Page 71 of 104
GlaxoSmithKline

1205
JUNE 2002
Validation Report
It is recommended that the validation report follows the same structure
and format as the validation plan. For example, if the complexity of
the application requires a separate validation plan then a separate
validation report is anticipated for consistency. For simple
applications, the validation report information may be combined with
other deliverables in the development testing (execution/results) and
deployment phase.
It is critical that the document containing the validation report
information be signed-off prior to use in the end-user environment.
Post Implementation Monitoring
Post implementation monitoring should be considered only for the
more complex desktop applications such as multi-user databases.
Decommissioning
Special consideration should be given to ensuring retrievability of
desktop applications after their decommissioning. For example, it is
common for only one or two people in a department to be aware of a
desktop application that performs critical calculations for product
release decisions. If decommissioning is not properly managed, the
application can effectively disappear once the limited number of
knowledgeable personnel have left the company or taken other
positions. Archival of the software package required for execution of
the desktop application, for example a specific version of MS Excel,
should also be considered to ensure operability of the retrieved
application.
In addition to archival of the application and any associated data, the
decommissioning process should ensure that all documentation can
be identified, located and retrieved by persons other than those that
created and maintained the application. It is recommended that the
archive and decommissioning process include formal, documented
hand-over to personnel that can ensure availability throughout the
required retention period. The systems register should be updated to
reflect the decommissioned status of the application.
All cross phase activities described in Section 4 apply (including
requirements traceability matrix) but may be scaled to size and
complexity of the application.
Page 72 of 104
GlaxoSmithKline

9.5.3.
1205
JUNE 2002
Considerations for One-off Desktop Applications

The following items are recommendations for qualification of one-off
applications to alleviate full life-cycle documentation requirements:
The intended functionality of the application should be clear and

unambiguous to ensure appropriate manual verification. The
presentation of this information may range in formality from the
clear labelling of columns within very simple spreadsheets
(e.g. 'average')
to
separate
requirements/specifications
documentation, as appropriate for the complexity of application
functionality.
100% manual checking (verification) of input data and

processing actions (e.g. spreadsheet calculations or database
functions such as record count) should be performed at each
use of the application. Someone other than the user should
perform the check. The processing provided by calculations
and/or functions that are used multiple times should be verified
only once with subsequent uses verified to ensure accuracy of
the copy and applicable data references.
The output should indicate how the verification was performed

and include the dated signature of the person that performed
the verification. An explanation of the meaning of the signature
should be provided (e.g. a statement indicating all input data
and calculation results have been manually re-calculated to
verify their accuracy).
Printouts produced as part of the qualification, such as

spreadsheet formula with manually calculated results or report
query listings should be retained with the report printout.
The qualification process, including considerations for the

accuracy of transcribed information and calculations, and any
other required documentation should be addressed in local
procedures.
This approach is only suitable for applications that lend themselves to

manual checking such as those that are very simple and/or
infrequently used, e.g. spreadsheets containing a few calculations for
a low volume product. For example, ad-hoc queries for databases
with thousands of records are not good candidates due to the difficulty
in verifying that all intended records, and only the intended records,
are included in the reports. The practical limits of a users ability to
verify large and/or complex volumes of information such as frequent
Page 73 of 104
GlaxoSmithKline

1205
JUNE 2002
manual recalculation of Fourier transform results may also affect

whether this approach is appropriate.
9.6.

Desktop applications typically involve three types of software: an operating
system, a commercially available 'standard' configurable software package
such as MS Excel or Lotus Notes, and the desktop application which results
from configuration and/or bespoke/custom coding of such a package.
The table below provides guidance for application of the software categories
(see Section 6) to desktop applications.
Desktop Application
Categories
Spreadsheet Applications (no user configuration)
Spreadsheet Applications (user configuration of standard

functions)
Spreadsheet Applications (user defined macros/programming,

e.g. VBA macros or calculations, report queries developed
with SQL, any other bespoke/custom programming)
Database Applications
functions)
standard
Database Applications (user defined macros/programming,

e.g. VBA macros or calculations, report queries developed
with SQL, any other bespoke/custom programming)
Statistical Analysis Package (user configuration of standard

functions)
(user
configuration
of
Many desktop applications will be the result of both configuration and

bespoke/custom programming for example, a spreadsheet containing a macro
written to retrieve and parse data from an external source
(custom component) and then average the data by use of standard functions
(configuration component). Each component can be considered separately
and validated in accordance with the appropriate validation strategy for the
component (see Section 6).
Many packages provide 'wizards' to configure an application or extend
functionality through assisted code creation. In general, the use of Wizards
should be considered as a configuration activity. Wizard generated code
which is modified by a user should be considered bespoke/custom as should
a complete 'stand alone' application which does not require the presence of
the 'parent' software package (e.g. MS Access) to execute.
Page 74 of 104
GlaxoSmithKline

1205
JUNE 2002
10. Approach to IT Systems

10.1. Definition of IT Systems
IT systems can be characterised as networked applications used within a
multi-user environment that encompass a range of business and GxP critical
activities. They are commonly referred to as business or information systems.
A key characteristic of IT systems is that they are usually networked
applications that operate in a multi-user environment. As such these systems
are dependant upon a supporting network and IT infrastructure for their
operation.
Typical business processes managed by an IT system include but are not
limited to inventory management, capacity planning, master production
scheduling, sales order processing, materials requirement planning, purchase
order processing and shop floor control relating to the manufacture and
distribution of bulk drug substances, intermediates and finished packed stock.
10.2. Scope of Systems Covered
The following are examples of IT systems covered by this guideline. This list
is not exhaustive:
Enterprise resource planning (ERP).
Manufacturing resource planning (MRPII).
Laboratory information management (LIMS).
Electronic document management systems (EDMS).
Financial planning and management.
Engineering maintenance management system (EMMS).
Distribution Systems.
Schedulers.
Financial systems.
Purchasing systems.
Human Resource systems.
Page 75 of 104
GlaxoSmithKline

1205
JUNE 2002
The inter-relationships between IT systems can make it difficult to scope the

boundaries for validation. Guidance on dividing interconnected IT systems
into GxP and non-GxP is provided in GQG 1401A.
10.3. Responsibilities
An approved quality system (e.g. iQMS) should be used for the development
and implementation of IT systems. This guideline outlines validation
expectations that should be considered alongside the procedures embodied in
the selected IT quality system. Advice on desktop applications, IT
infrastructure and software tools that might be associated with an IT project
can be found elsewhere in this guideline.
10.4. System Register
Central IT support organisations as well as operating sites should maintain
system registers.
10.5. Validation Life-Cycle
10.5.1. Planning Phase
Business requirements must clearly scope what are often networked
systems with numerous interfaces.
Compliance Assessments should be used to document whether any
aspects of a computerised system have GxP impact and hence
require validation. The System Register should indicate whether any
aspect of a computerised system has GxP functionality.
Electronic Records and Electronic Signatures Assessment
IT systems used in GxP applications that contain a number of
electronic records or electronic signatures must comply with
GQP 3202. Particular consideration should be given to duplication of
electronic records across systems and also distribution of component
sub-records across systems and how they are synchronised. Where
ever possible records should be linked rather than duplicated to clarify
status of master data.
Activities to ensure ERES are met (e.g. requirements specification,
compliance assessments, design reviews and testing) should be built
into the validation plan. Early consideration of archiving requirements
Page 76 of 104
GlaxoSmithKline

1205
JUNE 2002
is recommended as this may affect the architecture and design of the

final system.
Validation Planning
Site validation plans may leverage information from related quality
documents such as project quality plans and deployment plans
developed by central projects. Further leverage can be made of
technical installation, acceptance testing and post deployment review
for IQ, OQ and PQ respectively. The requirements for IQ, OQ, and
PQ however should be reviewed to check whether supplementary
activities are required. Site validation plans should use terminology
familiar to their respective regulatory authorities, e.g. validation plans,
IQ, OQ, PQ and validation reports.
Validation plans should take account of the different categories of
software comprising the IT system and the mix of GxP critical
functionality and non-GxP critical functionality. The potential impact of
non-GxP critical functionality on GxP critical functionality should be
clear before a validation strategy can be developed. GQG 1401A can
be used to assist the identification of GxP and non-GxP functionality.
Consideration should be given to the organisation of the validation
team and how the needs of each business and/or site are met and
how consistency is to be maintained considering different cultures and
working practices at each site. The relationship between core project
team members and site project team members should be clearly
defined.
Many IT systems have a multiple site implementation. It may be
necessary to consider the development of a hierarchy of validation
plans that define the generic project validation activities and
documentation and the specific site activities and documentation.
Systems integrators often employ their own development
methodologies. Such methodologies should be reviewed in order to
determine their relationship to GSK methodologies and validation
life-cycles. Validation plans should document this relationship and,
where necessary, specify any enhancement to meet pharmaceutical
industry standards.
The validation plan should clearly define the scope of the IT systems
to be addressed. Particular attention should be made to interfaces
between IT systems when defining the validation scope. Careful
consideration should be given to the deployment strategy. Any
reporting requirements necessary to authorise a phased release of the
IT system should be defined.
Page 77 of 104
GlaxoSmithKline

1205
JUNE 2002
10.5.2. Supplier Assessments

The scope of supplier audits is often greater for IT systems than other
systems. The need to assess the following should be considered:
Business consultants.
System Integrators.
Application suppliers.
Hardware suppliers.
Support organisations.
Development and support organizations may be located in different

countries/sites and may be working to different quality standards
potentially increasing the scope of audits required.
Supplier Assessments should focus on products (including specific
versions) in addition to quality management systems.
The validation plan should define the strategy and scope for
conducting supplier audits in addition to the rationale for not auditing
particular suppliers.
For standard software products, observations against the quality
management system or product may not be addressed until future
releases of the product. Consideration should be given to the impact
of such observations and additional validation activities and
operational controls required to minimize their impact until such times
that a future release of the product is deployed.
10.5.3. Requirements Phase
For IT systems, a number of user (system) requirements may be
needed in order to convey the system and functional requirements to
a system integrator or supplier. Requirements specifications may be
based on application modules, e.g. planning, materials management,
maintenance management. Development of user requirements may
be phased in accordance with the implementation plan.
Methods and tools e.g. prototyping may be used to support the
development of requirements specifications, however, such tools
should not be used to implement the IT system.
Requirements should be uniquely referenced in order to facilitate the
development and maintenance of a requirement traceability matrix.
Page 78 of 104
GlaxoSmithKline

1205
JUNE 2002
10.5.4. Design and Code Phase

Design methodologies may differ from application to application or
supplier to supplier.
Typical design documentation should be
reviewed in order to ensure that irrespective of methodology used,
design documents are consistent and complete.
System Overview
A system Overview should be developed for the IT system. For large
IT systems, separate system overviews may be developed at a
modular level. Where modular overviews are developed, they should
be clearly cross-referenced.
Development of the system overview should be started as early as
possible. This document should be further reviewed and amended
when the system is approved for use, to ensure that it reflects the final
system.
Design Specifications
Multiple design specifications are often appropriate for large IT
systems. These may be organized at the module level (e.g. Unit
Specification). Package configuration and programming standards
should be documented.
Relevant design for IT infrastructure
(e.g. networks) should be included.
Data Definition
Data definition for an IT system is usually a major component of the
design. Data dictionaries, database schema, record life-cycles, data
distribution across systems and data security should be defined. A
listing of all database views, tables, and indexes comprising the
system should be prepared. For database tables the following should
be included: table names and field names, with field format and data
lengths provided for each field name. For database views, the
following should be included: view name, database table name, field
name, and selection criteria for view. Indexes, indexed tables and
indexed fields should also be included.
Record life-cycles should include indications of steps involving record
authorisation and approval. The methods and information required for
the audit trail should be stated as required by GQG 3202.
An assessment should be made of the GxP nature of data
(or information) in order to determine the degree of data migration
validation required. Reference should be made to GQG 3202.
Page 79 of 104
GlaxoSmithKline

1205
JUNE 2002
Where data is to be migrated from a legacy or manual system the

mapping of legacy system data structures to new data structures
should be defined along with any automated or manual data
translations. The impact of migrating electronic records should be
assessed and the rationale for continued integrity of the electronic
records documented.
Design Review
Design reviews may be known as design qualification. Appropriate
technical, quality and business representatives should be involved in
the review.
Coding, Configuration and System Build and Code Reviews
Bespoke/custom developments and GSK specific configuration and
customisations should be developed in accordance with defined
programming and configuration standards as indicated in Section 4.
Configuration is often implemented under the control of configuration
tools that form part of the standard IT system product. Such tools
often impose configuration standards on the developer.
Customisations e.g. extensions to tables and development of SQL
scripts however, may not be controlled by tools that impose such
configuration standards.
All GxP critical configuration and
customisation should be subjected to configuration and/or code review
(i.e. source code review).
The adequacy of the system
integrators/suppliers configuration/coding standards should be
assessed prior to commencing code/configuration development.
10.5.5. Development Testing Phase
Pre-Installation Testing
Pre-installation testing should ensure that new code and configuration
functions in accordance with the design and that test business
scenarios are successfully processed. Testing should include screen
navigation and screen flow testing and error message testing.
Documentation should cover unit testing and system testing for
in-house developments.
Installation of hardware and software should be recorded to assure
that the environment upon which pre-installation testing takes place is
a match of the operating environment. This is normally involves an IQ
for the development environment.
Page 80 of 104
GlaxoSmithKline

1205
JUNE 2002
Custom code and configuration should be subjected to unit and

integration testing. Unit and integration tests should ensure that the
developed/configured functionality meets design specifications.
Testing of interfaces to other systems is critical before go live. Such
interfaces may be to existing systems or new systems being
developed concurrently. Interface testing should be carefully planned
in order to ensure that parallel projects are synchronised so that
testing can proceed when required. IT system interfaces generally
involve the transfer of files from one system (server) to another.
Interface testing should verify:
Transport file security.
Transfer synchronisation.
Data translation.
Data mapping.
Test specification standards employed by system integrators and

suppliers may not meet the requirements of the pharmaceutical
industry. As such, early understanding of how expectations will be
met is necessary.
This can be achieved either by system
integrators/suppliers raising their standards or additional test
specifications being developed to replace or enhance those from the
system integrator/supplier.
10.5.6. Deployment Phase
The deployment phase essentially takes what is delivered from the
Pre-installation phase and ensures successful operation and
maintenance of the system. Often, a plan of deployment phase
activities is needed in addition to the validation plan. The plan should
address both IT and user deployment activities.
IT systems are generally associated with management of the business
and therefore cut-over from legacy systems to new systems should be
carefully managed. A minimum period of outage between the
shutdown of the legacy system and start-up of the replacement
system is required. It may be necessary to have a period of parallel
operation until the performance of the replacement system can be
determined (see performance qualification). Often systems will not be
run in parallel for practical reasons, however, business continuity and
contingency plans are still needed including procedures for reverting
back to the legacy system in the event of a disaster.
Page 81 of 104
GlaxoSmithKline

1205
JUNE 2002
Data Load
Data load/migration often takes place in stages. Initially, migration of
a limited sample of data may take place to enable early testing. As
testing progresses, greater volumes of data may be migrated to
enable comprehensive testing of business scenarios. A final data
load/migration will be required prior to system cut-over in order to
synchronise data between the new system and legacy systems.
Statistical rationales should be used to justify different approaches
data load verification.
The design phase should have previously considered data migration
in terms of:
Data sources (including source verification).
Data cleansing requirements (e.g. purging of test data prior to

migration of business data).
Data archiving.
Mapping of data between systems.
Automated migration routines.
Manual entry and manipulation of data.
Data manipulations conducted during the load/migration process

should be fully understood and documented.
Validation of automated data load/migration tools should be
considered and the requirements and timing of the validation should
be addressed by validation and project plans. All data migration
routines should be documented, reviewed and validated as
appropriate. Where migration routines are fully automated and
validated, it may be appropriate to consider statistical sampling of
migrated data especially for large volumes of data.
Where data load involves manual transfer or entry of data, all GxP
data should be at least double-checked to verify it is correct.
When migrating data from a legacy system, consideration should be
given to the currency of data. Where data is migrated from a non
validated system consideration should be given to how the data will be
verified. Historical data may not require migration to the new system
and may be archived. Consideration must also be given to archived
data. Archived data will be in the format of the legacy system, yet
Page 82 of 104
GlaxoSmithKline

1205
JUNE 2002
should still be retrievable for the retention period dictated by

regulation.
Operational and Support Plans
Operational and support plans (sometimes referred to as post

deployment review) should state how the validated status of the IT
system is to be maintained.
User Procedures
It should be recognised that different businesses and sites of GSK

have different standards, templates, terminology, roles and
responsibilities and as such User (and other) procedures should take
account of differences. As IT systems are often deployed across
multiple business and sites, such considerations should be built into
project plans.
Training
Training may be a major undertaking for a global IT project. Training

considerations must be considered early in project plans. Training
issues include:
Generic and business/site-specific training needs.
Training of Support organisation.
Resource to deliver training.
Tracking of training plans.
GxP systems require documented job roles and training

records.
Security Management
Security Access is a key issue. User profiles should be defined and

maintained. They should match training and be appropriate to job
roles of users. Additional considerations for an IT system are:
The use of intranet, internet and firewalls.
Users accessing information across a wide area network.
Critical data being transferred across a wide area network.
Page 83 of 104
GlaxoSmithKline

1205
JUNE 2002
Central and site based procedures should be established to ensure

that functionality and data is only accessible to authorised personnel.
Data Archiving and Retrieval
Archiving of GxP records and data is a major consideration for an IT

system as large volumes of information are involved. Consideration
should be given to:
Which records are GxP (and business) critical?
Appropriate archived media (volume and integrity)?
Archive frequency (business risk).
Ready retrieval of archived records for the defined retention

period.
Migration of archived records following system upgrade.
Business Continuity Plans
The risk of system failure during operation must be managed.

Business continuity plans (also known as system continuity plans)
should address the immediate and higher risks following cut-over. In
the event of a catastrophic failure, reverting to a legacy system is one
option for consideration.
Service/Support Transition Plans
Service requirements, service models, Service implementation plans,

service level agreements and operational level agreements, service
readiness testing, and transitions plans should be developed where IT
systems are handed over to service/support organisations.
Availability of Software and Reference Documentation
Regulatory inspections are largely conducted with a site focus,

however an inspection may investigate the validation of a global IT
system in use on the site. Consideration should be give to the
availability of global documentation for a site inspection. Also,
consideration should be given to how knowledgeable resource may be
made available to support site inspections.
Page 84 of 104
GlaxoSmithKline

1205
JUNE 2002
Configuration Management Plan
This plan should state how changes are to be made and by which
groups. The plan should also state the tools to be used to make
changes.
Maintenance
As with other activities, central and site responsibilities should be

defined.
Backup and Restoration
IT systems largely reside on central servers that are backed up in

accordance with central systems. Central and site-specific backup
needs should be established and the adequacy documented in the
validation plan.
IQ should ensure that the IT system software, configuration and
hardware have been correctly installed into the operating
environment. IQ activities can leverage installation plans and reports
if available. Particular considerations for IT systems include:
Organisation of IQ for core components of the system and

site-specific components.
Installation and interfacing of clients and servers.
Phasing of installation with respect to ongoing legacy system

operations (e.g. are there multiple network connections to
enable new clients to be connected before legacy clients are
removed).
Phasing of installation with concurrent related projects.
Site specific records/templates.
IQ for core components should include software installation procedure

and expected outputs, e.g. installation job logs, exception reports, etc.
Site specific components should take into account the operational
environment of the system. IQ of hardware should include the
recording of all appropriate and accessible part numbers and serial
numbers.
IT systems often require the deployment of 10s if not 100s of PC
based clients. Consideration should be given to those IQ and OQ
Page 85 of 104
GlaxoSmithKline

1205
JUNE 2002
qualifications that need to be conducted at the point of installation and

what qualifications can be conducted within a controlled desktop
environment prior to deployment of the client (see Section 11).
Installation of client front end should be covered by defined, approved
procedures,
OQ for an IT system should include demonstration that business
scenarios are successfully processed within a normal operating
environment, using test data-sets. OQ at this point is synonymous
with acceptance testing. This should normally involve 'end to end'
testing of business scenarios using a replica of the current legacy
system database (or a fully populated new database for non-legacy
systems) and SOPs designed for the new system.
OQ tests should be designed to challenge as many permutations of
the business scenarios as possible however it may not be practicable
to test all permutations prior to cut-over. When all scenarios cannot
be tested, the worst-case situations should be used. As a minimum,
all GxP scenarios should be tested.
SOPs, including operation and maintenance, should be verified during
OQ.
Actual users of the system should be involved in this testing as they
have knowledge and experience of current systems and processes
and are able to identify issues not previously identified. Involvement
of users in the OQ also provides additional system familiarisation and
training.
OQ testing should be conducted within the final operating environment
but should be conducted before the system is made live. A system
release note may be issued to authorise progression to PQ.
System Release
System release to the live environment normally occurs following OQ
of an IT system. As the validation at this point is not necessarily
complete a system release note or Interim validation report should be
prepared in order to authorise system cut-over.
Operational and support plans should be in place before authorisation
of cut-over.
Page 86 of 104
GlaxoSmithKline

1205
JUNE 2002
PQ for the IT system should be conducted under live operating
conditions. This generally involves running the system under the
control of normal SOPs and tracking certain events and performance
conditions. PQ should consider:
Tracking all permutations of business scenarios (e.g. for a

corporate labelling system this would be when all combinations
of label formats and product information have been generated).
Monitoring the performance of systems when there are many

concurrent users (i.e. difficult to monitor performance of system
for 50 concurrent users under OQ conditions).
Performance of system interfaces.
It may be appropriate in some cases to perform product performance

PQ in conjunction with OQ.
That part of PQ relating to process performance is sometimes referred
to as post implementation review or post deployment review. This
should include:
Audit of the system.
Measure of the issues/faults raised when the system is in use.
Close out of issues/resolution of faults.
Validation Reporting
Multi-site IT systems may be deployed in a phased manner.
Consideration must be given to the phasing, e.g. a validation report
should be considered for each site or business. The validation report
should respond to the site validation plan and the generic project
validation plan. Validation reports can leverage quality reports where
available.
Where parallel operation is required (see introduction to deployment
earlier in this section) the following considerations should be made
and documented:
Which system holds the master data for the purpose of decision
making?
What are the infrastructure implications?
Page 87 of 104
GlaxoSmithKline

How will the parallel systems be synchronised?
What are the system interface implications?
What are the resource implications?
What are the procedural implications?
1205
JUNE 2002
10.5.7. Use Phase

The following points should be considered during the use phase:
An audit trail of any changes made.
Update of the system register.
Maintenance of an error/deviation log.
Periodic review and revalidation.
Special consideration to who should be involved in the periodic

reviews of multi-site systems to ensure appropriate representation.
10.5.8. Decommissioning
Due to the volumes of data and records involved, archiving and
decommissioning is a major consideration for IT systems.
Consideration should be given to:
GxP records and their required retention period.
Need to migrate records to new system and re-archive.
Need to migrate to neutral file formats.
Retention of legacy hardware and software (not recommended).
Archive management procedures (media, storage, location,

labelling, long term integrity).
10.5.9. Cross Phase Activities

Cross phase activities should include document management, change
control, configuration management, incident management, and
training are required in order that:
The benefits of a standard deployment across businesses and

sites is maintained.
Page 88 of 104
GlaxoSmithKline

1205
JUNE 2002
Documentation is accessible across all installations.
Cross function/business/site responsibilities are defined.
Given the large scale of IT systems and their constantly evolving

nature, attention must be given to maintaining design and test
traceability.
Change Control
Particular considerations need to be made for change control in a
global IT system:
The impact of change at one installation is considered for other

installations.
How will core product changes be made and site impact

assessed and communicated?
How will central and site specific responsibilities be defined?
How will documentation impacted by the change be managed?
10.6. Examples of System Categorisation

Typically IT systems can be regarded as a combination of category 3, 4 and 5
software. The following list gives guidance on the expected categories
(see Section 6) of some typical IT systems. The need to assess each system
individually is still strongly recommended.
IT System
Categories
Enterprise Resource Planning (ERP)
1, 3, 4, 5
Manufacturing Resource Planning (MRPII)
1, 3, 4, 5
Laboratory Information Management (LIMS)
1, 3, 4, 5
Electronic
(EDMS)
Document
Management
system 1, 3, 4, 5
Engineering Maintenance Management system 1, 3, 4, 5

(EMMS)
Distribution System
1, 3, 4, 5
Page 89 of 104
GlaxoSmithKline

1205
JUNE 2002
11. Approach to IT Infrastructure

11.1. Definition of IT Infrastructure
IT Infrastructure comprises the software, hardware and procedural
environment that supports the secure operation of applications.
IT
Infrastructure includes:
Standard desktop.
Servers.
Networks.
Service management.
The validated status of computerised systems/applications is dependent on

the controlled management of the IT Infrastructure. IT Infrastructure typically
exhibits an evolutionary development rather than the distinct application
development associated with the computerised systems it supports.
Management controls should take account of this characteristic. The use of
validation terminology will, to a large degree, be dictated by the regulated
applications and IT infrastructure they support.
11.2. Controls for IT Infrastructure
11.2.1. Desktop Environment
Procedural controls should be established in order to manage the
distribution of desktop software and associated configuration.
Suitable records should be available to demonstrate configuration
management.
Conflict testing should be conducted in order to ensure that
applications are able to co-exist on the desktop PC.
Logical controls should be applied to all desktop PCs containing GxP
applications and electronic records. Security controls should conform
to the requirements of GQP 3202 ERES. Such controls include but
are not limited to:
Access limited to authorised users.
Control of security code issue and re-issue.
Ability to manually lock PCs.
Page 90 of 104
GlaxoSmithKline

1205
JUNE 2002
Automated locking of PCs after a defined period of inactivity.
Disabling of user accounts following a defined number of failed

login attempts.
The standard desktop configuration should be documented and critical

aspects of the desktop subjected to change control and configuration
management.
Processes should be established for the distribution of virus protection
software and the maintenance of virus detection databases in order to
maximise GSKs ability to detect and eradicate viruses.
11.2.2. Server
Servers containing GxP applications or data should be subject to
controls that ensure that the integrity of such applications and data is
maintained.
Servers should be managed under change control in accordance with
defined procedures.
Configuration records should be in place for server hardware and
software.
Servers should be backed up in accordance with appropriate SOPs.
The ability to restore multiple and single files should be tested and
documented.
Procedures should be in place to archive GxP data at defined
intervals and to ensure that such data can be readily retrieved for the
duration of the retention period. The integrity of backup and archive
media should be verified at appropriate intervals throughout the
retention period.
Backup and archive media should be stored in secure locations
subject to appropriate environmental controls.
Backup and archive media should be adequately labelled to enable
clear identification when required.
Servers should be located in secure locations subject to appropriate
environmental controls and protected against risks of flooding, fire,
etc.
Business continuity plans and disaster recovery plans should be in
place to manage catastrophic events.
Such plans should be
periodically tested.
Page 91 of 104
GlaxoSmithKline

1205
JUNE 2002
Configuration records should be in place for server hardware and

software.
11.2.3. Networks
Specifications and diagrams should be in place that describe the
Local area network and identify critical physical and logical
components of the network. Specifications and diagrams should
identify key entry points to the network and how security is managed.
Such specifications should be reviewed and approved.
Network specifications and diagrams should be in place for wide area
networks.
Network diagrams should identify all critical equipment e.g. servers,
routers and bridges and should show connections between local and
wide area networks.
The boundaries between open and closed networks should be
documented along with methods for protecting data, such as access
controls, firewalls and cryptographic techniques where employed.
Critical network configuration should be subject to installation controls,
testing, ongoing monitoring, change control and configuration
management.
Communication protocols should be documented, e.g. transmission
control protocol/internet protocol, SNA, DecNet.
Middleware (communication software used to link different
applications) should be installed according to defined procedures, and
tested as part of the computerised system it supports. Configuration
parameters should be documented and verified.
Distinct import and export features built into computerised systems
are not middleware and should be validated as part of the application.
Tools should be used to monitor network operation and performance
and security breaches.
Appropriate naming conventions should be used for networks and
devices.
11.2.4. Service Management
Procedural controls should be established in order to manage the
ongoing support and maintenance of the IT infrastructure. This
procedural framework is critical in keeping the IT infrastructure in a
Page 92 of 104
GlaxoSmithKline

1205
JUNE 2002
state of control, the objective being the maintenance of a continuous

state of compliance as the IT infrastructure evolves to meet business
requirements.
Areas that should be addressed are as follows:
Element
Detail
General Management
Training,
Service
contracts, etc.
Servers
Mainframes
level
agreements,
and Installation, changes, decommissioning,

hardware/software
maintenance,
management of outsourced services,
service start up and shut down, job
scheduling, system monitoring, problem
logging/tracking/reporting, etc.
Network Management
Installation, changes and decommissioning,

management of third party networks,
hardware/software maintenance, service
monitoring,
problem
logging/tracking/reporting, etc.
Desktop Management
Establishment
of
standard
hardware/software installation,
decommissioning, maintenance
protection,
distribution
of
upgrades, etc.
Security Management
Physical
security,
logical
security,
password
ageing,
user
account
management, access rights, installation of
anti virus software, handling of virus alerts
and infections, etc.
Data Management
Back-up and restoration of data, media

management, long term data archiving, etc.
Quality Management
Internal
audit
process,
document
management,
record
management,
corrective and preventative action, process
improvement, GxP training, etc.
desktop,
changes,
of virus
software
Page 93 of 104
GlaxoSmithKline

Change
Configuration
Management
Continuity
Management
1205
JUNE 2002
and All systems should be subject to

configuration management. All IT systems
should be subject to change control
documented in appropriate SOPs.
Disaster
planning.
recovery
and
contingency
12. Approach to Centrally Developed/Supported Systems

12.1. Definition
This section provides guidance on the validation implications for centrally
developed and/or supported applications/products deployed across multiple
sites. This guidance is intended to complement other guidance in this GQG,
in particular, Approach to IT Systems.
The objective of centrally developed and supported applications/products is
primarily to establish consistent, effective and efficient business processes
and to minimise development, support and validation costs. As such, site
modification of applications/products should be minimised.
12.2. Scope
This guidance applies to computer systems developed and supported
centrally regardless of whether or not there are local modifications. It applies
to:
Single instance of an application serving multiple locations (e.g. MERPS)
One instance of an application serving one location (e.g. HP Chem LMS
BPCS, and JD Edwards, common Distributed Control System (DCS), common
Chromatography Data System (CDS), and common Near Infrared (NIR)
instruments)
Sites may require assistance in making this distinction, and guidance will be
available from Global Computer Validation and the central Support Group for
the computer system concerned.
Central development and support teams may adopt methodologies and
terminology determined by their quality systems as long as they comply with
the principles embodied with GQP/G 1205. Site Validation Plans should
define where central application/product documents are used in support of
Page 94 of 104
GlaxoSmithKline

1205
JUNE 2002
validation. Central and site teams should agree relationships between central
and site activities and documents. Central development and support groups
and Site Validation should work with Global Computer Validation (GCV) in
order to facilitate consistent validation (e.g. use of templates) and maximise
use of central documents without duplicated site effort.
12.4. System Register
Sites should keep an entry in their System Register for those
applications/products they use that are centrally developed/supported.
Central support groups should maintain a System Register of sites using the
GxP systems they support.
12.5. Validation Life Cycle
Validation Plans
Each implementing site should develop a Validation Plan. The Validation Plan
should reference the central Validation Master Plan (or Quality Plan as
appropriate) in addition to defining site-specific validation activities. Both Site
Validation Plan and central Validation Master Plan (Quality Plan) should
clearly differentiate central team accountabilities and deliverables from site
validation accountabilities and deliverables.
Consideration should be given to GxP and non-GxP components of the
application/product (GQG 1401A provides further guidance). Further, certain
sites may not be using the application/product within a GxP environment and
as such, those elements of the site implementation need not be validated.
Supplier Assessment
Interfaces between suppliers supporting central and site activities should be
clearly defined. Central development and support teams should assure the
quality of suppliers supporting central activities. Centrally organised Supplier
Audits should be conducted in conjunction with Global Computer Validation.
Suppliers supporting local modifications should also be subject to supplier
assessment.
Central Activities Supporting Validation
The central implementation team should conduct activities to the agreed
standard in order to avoid or minimise additional work required to achieve
validation. Key documents supporting validation should be reviewed by
central and/or site validation teams as appropriate.
Centrally supported infrastructure should be incorporated within central
activities.
Page 95 of 104
GlaxoSmithKline

1205
JUNE 2002
Site Validation Activities

User Requirement Specifications (URS) stating site needs should be
established and documented in central URS and site-specific URS as
appropriate. Where ever possible a common set of user requirements should
be developed between sites using the same system. Specific local regulatory
requirements should be clearly stated.
Site implementation of centrally developed and supported systems, including
any local modification, should be validated. Site validation activities will
include configuration management, data load, and specification/design/testing
of any locally developed specific site modifications. Central documents
supporting validation e.g. specifications, design documents, test records, and
change control records should meet regulatory requirements.
Site testing (IQ, OQ, PQ) should verify core functionality including any local
modifications. Central testing should be used in support of qualification. Sites
do not need to repeat centrally supported IQ/OQ where central testing fulfils
local requirements. PQ is a site-specific activity but may be co-ordinated
across multiple sites if appropriate. Issues raised during PQ should be
reviewed with central support teams and sites. It may be beneficial for the
central implementation team to develop template documents, adapted by site
teams as appropriate, in order to provide a consistent approach across sites.
Site supported infrastructure should be incorporated within site activities.
Validation Report
Site Validation Reports should be developed in response to site Validation
Plans. In addition to confirming site validation activities, Validation Reports
should confirm the adequacy of all relevant central activities. A central
Validation Summary Report (Quality Report) report should be developed
reviewing the adequacy and release of each application/product version.
Deployment & Use
Procedures.
SOPs should be established to provide the required operational and

maintenance controls described in section 4.6 of this guidance. The use of
computer systems should be consistent with relevant GQP/Gs. Where
applicable, SOP templates can be provided by the central implementation
team for modification by sites as appropriate.
Service Level Agreements.
Service Level Agreements (SLA) should be established in order to define the

support service requirements and central and local support accountabilities.
Page 96 of 104
GlaxoSmithKline

1205
JUNE 2002
Interfaces between central support teams and sites should be defined and
appropriate SOPs established to manage the interfaces. Support service
arrangements should take account of different time zones. SLAs should
ensure that sites are given notification of upgrades to central elements of the
application/product in order to allow appropriate impact assessment and
revalidation planning. SLAs should address requirements for access to
centrally held documents to support maintenance and inspection readiness.
Change Management.
All changes should be subject to change control procedures, which should

ensure that the validated status of the application/product is maintained. Both
sites and Central Support Groups should periodically assess the cumulative
effect of change and whether any revalidation is required.
Sites should not make unauthorised changes to shared aspects of
applications/products.
Central Support Groups should notify all sites of modifications to the central
elements of the application/product in order that site support teams may
assess the impact of such changes on local developments.
Sites should conduct appropriate revalidation following modification to both
central and site-specific elements of the application/product. Central Support
Groups should ensure new or updated documentation is provided in support
of changes to the central elements of the application/product.
Changes to central and site-supported infrastructure should be subject to
appropriate change control procedures.
13. Approach to Software Tools
13.1. Definition of a Software Tool
Software tools are used to support the development and use of computerised
systems and do not form part of the end application. The are primarily used
for improved performance.
13.2. Scope of Tools Covered
13.2.1. Tools Related to GxP records and functions
These tools are used to control business data within the application,
or for handling system data such as configuration records or validation
related records. Example of the use of such tools include:
Manage validation documents.
Page 97 of 104
GlaxoSmithKline

1205
JUNE 2002
Generate, manage, or monitor inventory of validated systems or

components including source code.
Control application level security.
Monitor security breaches.
Govern validation activities (e.g. automated testing, test

records).
Govern change management process (including change control

records).
Manage release and distribution of validated software.
Manage other validation-related data.
Manage network time protocols.
13.2.2. Application Development and Diagnostic Tools

These tools provide a development and runtime environment for an
application. Such tools include spreadsheet packages and database
packages. Other examples include simulation and emulation tools
used to support testing.
13.2.3. Tools Incidental to the Creation of GxP Records
These are tools used to create paper records that are subsequently
maintained in traditional paper based systems. In this case the tools
function essentially like manual typewriters or pens and any
signatures, if required, would be traditional hand-written signatures.
Record storage and retrieval would be of the traditional 'file cabinet'
variety. More importantly, overall reliability, trustworthiness, and ability
to access the records would derive primarily from well-established and
generally accepted procedures and controls for paper records. For
example, use of word processing software to generate a paper
submission or other compliance related document.
13.2.4. Business Tools
These are tools that are used in day to day work but that are not used
to create records used in GxP decision processes and are not used in
the management of GxP records. Such tools include:
Diaries.
E-mail.
Page 98 of 104
GlaxoSmithKline

1205
JUNE 2002
Address books.
Diagnostic tools used to monitor the operation or performance

of a computerised system or application. Such tools provide
status information and often provide the capability to change
runtime parameters, internal registers and buffers.
These tools are not routinely used to control or monitor production

processes but may affect the operation and performance of a
computerized system, network or application if their use is not
controlled.
13.2.5. Compilers and Operating Systems
Compilers include for the purpose of this policy those tools that are
used purely in the development and translation of software into an
executable form. Such tools would include programming tools such
as PLC Programmers, Datalogger Programmers and MS Visual Basic
programming environments. These tools may have in-built diagnostic
facilities used such as debugging aids.
Responsibilities should be discharged as outlined in Section 2.
13.4. System Registers
The approach to listing tools on the system register should be documented
and approved by QA. Tools should be listed on the system register unless
some other arrangement has been agreed. Typically business tools and tools
incidental to the creation of GxP records need not be listed on the system
register.
Page 99 of 104
GlaxoSmithKline

1205
JUNE 2002
13.5. Validation Requirements

Validation requirements for software tools are dependent on usage of the tool
as summarised in the following table.
Tool Usage
Validation Requirements
Directly
supporting
GxP functions
and
associated
records
Validation required.
Tools should be
validated as computerised system. The costs
associated with validating bespoke/custom
may be prohibitive to their use. Where ever
possible COTS tools should be used.
Application
Development
and
Diagnostic
Tools
These tools may come in standard or

bespoke/custom form and should therefore
be addressed under the appropriate software
Category.
Security
management on
validated systems,
Test record
management for
validated systems,
Change control must be applied to manage Management of
upgrades to development and diagnostic change control &
tools in order to determine the impact of new, configuration records.
modified or removed features on developed
applications.
Spreadsheets
packages, database
packages, PLC
programming tools,
system operation and
Change control must be applied to manage diagnostic tools used
upgrades to development and diagnostic to support validated
tools.
applications.
Incidental to Validation not required

the Creation
of
GxP
records.
Business
Tools
Examples
Word processing.
Validation not required (except for e-mail Diaries, Address

used to transmit GxP records or approved Books, Email (not
GxP decisions - see GQG 3202)
used to transmit GxP
records or approve
GxP decisions).
Compilers
Validate as per Section 6.
and Operating
systems
UNIX, DOS.
14. Approach to Medical Devices

Computerised systems used in the manufacture, distribution or marketing of medical
devices should be validated in accordance with this guideline.
Where a medical device itself is automated, advice should be sought from GCV prior
to defining the validation strategy.
Page 100 of 104
GlaxoSmithKline

1205
JUNE 2002
15. Inspection Readiness

15.1. Definition of Inspection Readiness
A state of inspection readiness implies that a site is prepared for an
unannounced inspection and that minimal work is required to prepare for an
announced inspection. Some key aspects to computerised systems inspection
readiness that should be proactively managed are outlined in this section of
the guideline.
15.2. Organisation Charts
Organisation charts should be maintained to explain the fit of QA with the
wider organisation.
15.3. Use of Trained Personnel
Training records including role specifications should be kept current and
demonstrate that individuals are appropriately trained to conduct their duties.
15.4. Systems Register
An inventory of systems and which ones are GxP requiring validation should
be maintained and available for inspections. None of the other additional fields
described in Section 3.2 should be offered during an inspection. Where a
sites inventory is managed in a number of registers (perhaps one per
laboratory, one for process control systems, one for IT systems) care must be
taken that duplicate entries are avoided and equally some systems are not
missed. It should be borne in mind that where spreadsheets and databases
are used to manage an inventory then they should be assessed for validation
requirements just like any other computerised system.
15.5. High Level Site Mapping of Key Computerised Systems
Each site should maintain a high level map of the sites business processes
indicating where systems support the activities. This should concentrate on
GxP activities and identify the extent of support provided by the systems e.g.
allocate batch numbers, highlight out of specification values. Key interfaces
should be identified and whether they are manual or automatic. Regulators
are often interested in system interfaces, manual and electronic, and the
validation status of connected systems. Care must be taken to keep system
maps up to date as new systems are introduced, old systems are
decommissioned, and as the use and interfaces of some systems are
modified to meet evolving user demands.
Page 101 of 104
GlaxoSmithKline

1205
JUNE 2002
15.6. System/Project Overviews

High-level descriptions should be available for systems and projects giving a
succinct summary of the scope of the system, identifying functionality and use
of the system/application concerned. They should be developed with the aim
of helping regulators concentrate on key aspects of the system during an
inspection without getting deeply involved in aspects of the system that are
not of a prime concern. System boundaries need to be clearly defined. The
role of GxP functionality and the use of GxP data should be understood in the
context of the overall system. Owners of GxP data should be identified.
Top-level functional diagrams and physical layout diagrams are highly
recommended.
15.7. Validation Plans/Reports and Reviews
It is likely that during a GxP inspection a regulator will ask whether or not a
particular system has been validated. This line of investigation may stop with
a yes/no response, however, the line of investigation may lead to a follow-up
request to see the validation plan and report for a system described as
validated. Many of the computerised systems used today have been in use
over many years, and the regulator may also ask for any evidence of any
validation reviews. Validation plans, reports, and reviews should be checked
to make sure they exist, are approved, and meet current regulatory
expectations. Validation plans/reports and reviews should be available in
English for FDA inspection.
15.8. Documentation
Key documentation to support validation should be available at site during
inspection. Raw data and other supporting information should be retrievable
within a reasonable timeframe (see below). A document index should be
maintained to facilitate retrieval of on site and off site information.
A procedure should be developed describing how to handle requests by
regulators for documentation. Where requested, access to master (or copies
of) documents (including raw data such as test evidence) should be provided
within reasonable time scales, normally 24 hours. Service Level Agreements
between Central Support Groups and sites should define the service levels for
access to documentation.
Controlled copies of centrally held Validation Plans and associated Validation
Reports should be issued to sites in advance of any regulatory inspection.
Access to electronic copies of centrally held protocols and reports can be
facilitated during regulatory inspections to avoid unnecessary delays waiting
for paper master copies to arrive. Such access can be facilitated through email or a shared system directory. In such circumstances it should be clearly
stated to the regulator that these electronic copies may not adhere to
Page 102 of 104
GlaxoSmithKline
1205
JUNE 2002
regulatory electronic record/signature requirements but are being provided to

assist the inspector in advance of hard copies being delivered to site.
In addition to documentation, access should be provided to support personnel
with knowledge of the central application and documentation during regulatory
inspections.
15.9. Presentation
It can be useful to prepare a small presentation of each system that may be
subject to an inspection. The presentation slides should not be too detailed
but should provide a broad picture to describe a system/application and
facilitate discussion. There is a risk that too high a level of information may be
viewed as misleading following close examination of the system/application,
consequently it is worthwhile asking the legal department to review the slides.
The slides should be suitable to provide the inspector with a copy if requested.
15.10. Internal Audit Program
An internal audit program should be established if it does not already exist to
cover the use of computerised systems. A schedule of audits should be
planned placing priority on key topics subject to inspection such as
laboratories, manufacturing lines, and supply chain systems. It is essential
that audit observations are closed out in a timely manner and that the status of
corrective actions arising from audits is known.
15.11. Mock Inspections
A mock inspection programme should be developed if one does not already
exist. Mock inspections should be as realistic as possible. Mock inspections
on computerised systems validation may be conducted as part of a more wide
ranging mock inspection or as a topic of a mock inspection in its own right.
The opportunity should be taken to coach personnel receiving the mock
inspection, clearly identifying areas for improvement. If necessary be
prepared to withdraw individuals from the front line of a potential inspection if
they are not readily capable of fulfilling this role. Sometimes doing yet more
training will not be enough. It is important to accept that not everybody is
suitable for putting in front of an inspector.
15.12. Inspection Management
Personnel associated with computerised systems should be trained as
appropriate on how to handle inspections. The availability and use of trained
personnel during inspections is key. Those who present to an inspector
should be permanent employees otherwise there may be an impression of
dependence on quality from temporary staff. Presenters need to be
knowledgeable about systems/projects they are asked to front. They need to
Page 103 of 104
GlaxoSmithKline

1205
JUNE 2002
understand the validation approach taken, and appreciate why certain project
and validation decisions were taken.
A SOP should be prepared to describe how inspections are to be managed
from the notification of an inspection, through its completion. The inspection of
computerised systems is usually included within the scope of such SOPs.
Advice on how to handle inspection scenarios should be handled through
training rather than the SOP.
16. Bibliography
Food and Drug Administration (FDA), Guide to Inspection of Computerised systems
in Drug Processing, 1983, Technical Report, Reference Materials and Training Aids
for Investigators.
Food and Drug Administration (FDA), Glossary of Computerised system and
Software Development Terminology, 1995.
Good Automated Manufacturing Practice (GAMP) - Guide for Validation of
Automated Systems Version 4, 2001, published by International Society of
Pharmaceutical Engineers (ABPI and IQA Approved Supplier Guidance in
association with ISPE).
Parenteral Drug Association (PDA), Validation of Computer Related systems, 1995,
PDA Journal of Pharmaceutical Science and Technology, Technical Report 18.
Pharmaceutical Inspection Co-operation Scheme (PIC/S), Good Practices for
Computerised Systems in Regulated GxP Environments, Document PI 011-1 (Draft),
January 2002, Pharmaceutical Inspection Convention.
REFERENCES
GQG 1401A
GMP Compliance: Identification of GMP Business

Processes
GQP 1204
The Validation Life-Cycle
GQP 3202
Electronic Records and Electronic Signatures
GQP 3301
Document Archiving, Retention and Retrieval
Page 104 of 104

GlaxoSmithKline-Computer System Validation Guideline

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

GlaxoSmithKline-Computer System Validation Guideline

Uploaded by

Copyright:

Available Formats

GlaxoSmithKline

GLOBAL QUALITY GUIDELINE

Management: Management Systems

Adverse Event Reporting.

Electronic Records and Electronic Signatures (ERES).

Good Distribution Practices (GDP).

Good Laboratory Practices (GLP).

Good Manufacturing Practices (GMP).

GLOBAL QUALITY GUIDELINE

Management: Management Systems

The section on System Registers has been updated to include reference to

The section on Prospective Validation has been updated. The subsection on

The section on Retrospective Validation has been revised to improve grammar.

The section on Approach to Laboratory Systems has been revised to improve

The section on Approach to Desktop Applications has been revised to improve

The section on Approach to IT Systems has been revised to include Distribution

A section has been added on Approach to Centrally Developed/Supported Systems.

A section has been added on Approach to Medical Devices.

The section on Inspection Readiness has been revised to improve guidance on

GLOBAL QUALITY GUIDELINE

GLOBAL QUALITY GUIDELINE

7. Approach to Laboratory Systems............................................................................ 42

GLOBAL QUALITY GUIDELINE

12. Approach to Centrally Developed/Supported Systems ......................................... 94

GLOBAL QUALITY GUIDELINE

Management: Management Systems

How to establish whether or not a computerised system requires validation.

A general life-cycle methodology for computerised systems validation.

Expectations regarding the application of the general life-cycle methodology to

Advice on inspection readiness for computerised systems.

Guidance on roles and responsibilities.

Guidance on appropriate use of terminology.

A section is also included on retrospective validation describing where this is

GLOBAL QUALITY GUIDELINE

Management: Management Systems

Providing adequate resources.

Final authorisation of the validated system for use.

System Owner/User Role

Validation activities associated with any aspect of the requirements

Defining the system requirements.

Ensuring that the system is validated and used in a compliant manner.

Ensuring that appropriate user procedures are in place.

Ensuring that system end users/operators are trained.

The integration of the computerised system with existing processes,

Ensuring that validation activities associated with any aspect of the

GLOBAL QUALITY GUIDELINE

Management: Management Systems

All technical aspects of the system development and validation

The technical implementation and delivery of the computerised

Ensuring that appropriate support and maintenance procedures are in

All technical aspects of the system support and maintenance whilst

Preparing and approval of validation plans and of associated

Providing key validation activities and approvals as defined in

Authorising validated computerised systems as fit for purpose.

Provide GxP and regulatory input into validation projects with

Conducting compliance audits on the implementation of GQP 1205 in

GLOBAL QUALITY GUIDELINE

Management: Management Systems

Validation Master Plans

Unique reference/acronym (for traceability).

System description (phrase/sentence describing what the system

System type (indicate, e.g. whether this is a local system, a system

GxP/regulated determination (whether it is GxP/regulated system)

Validation status (whether it meets current computer validation