peyudiunc

GAMP.5 Page 34
4 Risk-Based Approach to Complani GxP Computerized Systems

Oy Per GCY
See Appendix 01 for further details on User Requiremenis Specifications.

4.2.2 Specification, Configuration, and Coding

REED
The role of specifications is to enable systems to be developed, verified, and maintained. The number and level of
detail of the specications will vary depending upon ihe type of system and its intended use. For example, software
design specifications are mot expected from the regulated company for non-configured products:

te b Mi ey
Specifications may be available from ihe supplier. Before use, the requiated company should ensure that they are
adequate to support subsequent activities, including risk assessment, further specification and development of the
system, and verification as appropriate:

Zaid
The requirements for configuration and coding activities depend on the type of system (see Section 4.2.6 of this

Joy GO
Guide for typical examples).

OT
Any required configuration should be perormed in accordance with a controlled and repeatable process. Any

eG
required software coding should be performed in accordance with defined standards. The need for code reviews
should be addressed as part of risk managemeni.

SEE
APU
Configuration management is an intrinsic and vital aspect of conirolled configuration and coding.

fy
Figure 4.1 shows specification as @ separate project stage fram configuration and coding. However, specification

IST
activities may be distinct from, or tightly coupled with, configuration and coding actvities depending on ihe software
development method being adopied.

POU
Specifications should be maintained and controlled. See Appendix D2 and Appendix D3 for further details on

bo LO
specification, configuration, and design. See Appendix D4 for further details on the management, development, and
review of software.

Gy Daceet
4.2.3 Verification

Veriiication confirms that specifications have been met This may involve multiple stages of reviews and testing
depending on the type of system, the development method applied, and its use_

edd
“eg
While verication is shown a 4 single box on Figure 4.1, verification activities occur throughout the project stages.
For example, design reviews should verify specifications during ihe specification stage. See Section 4.2.5 of this

DeunCHSH)
Guide for further details on design reviews.

Terminology usec to cover venfication activities is described in Section 4.2.6.4 of this Guide.

AQ
Testing computerized systems is a fundamental verification activity. Testing is concerned with identifying defects so
that they can be corrected, as well as demonstrating that ihe system meets requirements. SUISSE)

Testing often is perfonned at several levels depending on the risk, complexity, and novelty. One level of testing may
be appropriate for simple and low risk systems. There is a range of different types of tesiing possible, including:
2)

* normal case (positive)

* invalid case (negative)

* repeatability

*" performence
 Joy GOnP-dy pL Ud TeWeyNS ZeNegne) 0} pesuasy jeVapew payyyite
Page 22 GAMP:5
4, Risk-Based Aperdach to Gamphiant Gar Computerized Sysiems

* -yolume/oad

" fegression

* structural testing

Tests may be defined in one or more test specifications, to cover harcware, software, configuration, and acceptance.

An appropriate test strategy should be developed based on ihe nsk, complexity, and novelty. -Supolier dacumeniaton
should be assessed and used if suitable. The strategy should define which tyoes of testing are required and the
number and purpose of test specifications. The test strategy should be reviewed and aporoved by appropriate SMEs.

See Appendix D5 for further details on testing and develooment.of an appropriate test strateqy.

4.2.4 Reporting and Release

“AJUO BSN SoesuaDy

The system should be accepted for use in thé operating environment and released into that environment in
accordance with-a controlled and documented process. Accepiance-and release of the system for use in-GxP
regulated activites should require the approval of the process owner, sysiem owner, and quality unit representatives.

At the conclusion of the project, a computerized system validation report should be produced summarizing the

equ ry OF)
activities performed, any deviations from the plan, any outstanding and corrective actions, and providing a statement
of fitness for intended use of the system. See Appendix My for fumher details.

lo UD ISN pode
In Some cases, Specific computenzed sysiem validation reports may not be required as described in Section 3.5 of
this Guide.

Well managed system handover from the project team to the process owner, system ovwmer, and operational users is
8 pre-requisite for effectively mainiaining compliance of the system during operation. See Appendix O71 and Section

s fingonjay
8.6 of this Guide for further details on system handover.

42.5 Supporting Processes

popwied
4257 Risk Management

An appropriate risk management process should be established.

usswOUL AQ Resi
See Section 5 of tis Guide and Appendix M3 for further detads on Risk Management.

4252 Change and Configuration Management

Approgriaié configuration management processes should be established such that a computerized system and all its
consttuent components can be identfied and defined ai any post.
Su) SEDs

Change management procedures also should be established. The point at which change management is introduced
should be defined. Aporopriate change processes should be applied to both project and operational phases.

Any involvement of the supplier in these processes should be defined and agreed.

See Appendix Mé& for further details on project change and configuration management.
 POY a2
GAMPS Page 33
4 Risk-Based Approach to Compliant Ge? Computerized Systerns

PU
Oo] PeSUSOG
425.3 Design Revisw

At suitable stages during the life cycle, planned and systematic design reviews of specifications, design, and

IO) BOG e-b yr b UO Daeg Ney - Tene

develoomeni should be performed_ This design review process should evaluaie deliverables io ensure that they
satisfy the specified requirements. Comecive actions should be defined and progressed.

The rigor of the design review process and the extent of documentation should be based onrisk, complexity. and
novelty.

See Appendix M5 for further details on design reviews.

42.5.4 Traceability

Traceability is a process for ensuring that:

Seesedn
* fequirements are addressed and iaceable to the approoriaie functional and design slements in the
specifications

ALuo SEN
* fequirements can be traced to the aporopnate verification

As well as demonsirating coverage of design and verification, traceshility can greatly assist the assessment and

ON
managementof change.

mr
Traceahility should be focused on aspects critical to patient safety product quality, and dats integrity.

Jo uenSipode:
See Appendix M5 for further guidance on traceability.

425.5 Document Management

1 Buono”
Management of documentation includes preparation, review, approval, issue, change, withdrawal, and storage. See
Appendix MS for further details on document management.

4.2.6 Practical Examples

(paykeed
This 2ection shows how the general approach may be applied in a scaleable manner to three common types of
system, using categorization of sofware. Categonzation assists in selecting appropriate tife cycie activities and

Ad peEMG
documentation, as described in Appendix M4.

These examples are only intended to be indicative and for illustration purposes only. Actual approaches for specific
systems should be based on the results of supplier assessments and nsk assessments, in addition to categonzation
of system components, as described in Appendices MZ. M3, and M4.
osu)
Terminology used in these examples & discussed in Section 4.2.6.4 of this Guide.
SHES

4.26.1 Example of a Non-Gontigured Product.

ly

Many computerized systems comprise commercially avaiable software products running on standard hardware
components.

Software producis. which are used off-the-shelf (Le., which are either noi configurable for a specific business process
or where the default configuration is used) are typically classified as GAMP Category 3.

In such cases. and based on satisfactory supplier and nsk assesements, a simple approach consisting of one level
of snecification and venficaiion is typically applicable.
 paud
Page 24 GAMP 5
4 Risk-Based Aporoach to Gampliani GxP Computerized Systems

BA
Oy Petes
Figure 4.2: Approach for a Non-Configured Product (Category 3)

Primary
Responsibility

UO zene gney Rosas

Regulated
Company
Specification Verification

Saesuao@ 1o) Booey

MIigured

Supplier

Non-Configurable or Configurable Product Supplier

“Ajo San
QMS

io uowenpoide: Sequin OF)

Testing typically covers:

* correct installation

* tests that demonstrate fitness for intended use and allow acceptance of the system against requirements

' any further tests as a result of isk and supplier assessments

o Bunpcayeu
Reguiated companies typically perform the required specification and verfication. While the system is not configured
for a business process, there may be some limited configuration such as of run-time parameters or printer setup.

Supplier activities typically include supply of the product, and provision of documentation, training, and support and

Depuued
maintenance.

4262 Example of a Configured Product

Ae)
A common type of compatenzed system involves the configuration of commercially available software products

Aa pear
“unning on standard hardware components.

Software groducis which are configured for a specific business process are typically classified as GAMP Category 4.
uso)
In such cases, and based on satisfactory supplier and risk asseseamenis, the following approach consisting of three
levels. of specification and verification is typical. The number of documents required to cover these three levels will
Sys

depend on the complesaty and impact of the system. For example, for small or low risk systenis the functional and
configuration specifications may be combined into ane document.
Su)
 payBud
GAMP 5 Page 35.
A Risk-Based Approach to Compliant GxP Computerized Systems

Uo Pee Re) RONSENS Oy POtUESy ee

Figure 4.3: Approach for a Configured Product (Category 4)

Primary
Responsibility

Regulated
Company
— ee ee ee

San Seecuedy IO) GOOF My)

Specification

o Bunponpeu Jo Uonapoda euury Of) ‘Mj

Supplier

Configurable Product Stippliat

QMS

Testing typically covers:

* comect installation

" — configuration of the system

Dead
* funetionality that supports the specific business process based on nsk and supplier assessments (this is an ares
where suppier documentation may be leveraged, see Section 6.35 of this Guide}

SYRUESS LosWON! Aq BER

" fests that demonstrate fitness for imended use and allow acceptance of the system acainst requirements

" any further tests as a result of fsk and supplier assessments

Regulated companies should decide upon the required levels of specification and venfication, and many of the
project phase activities and documents may be delegated. Since the system is configured for a business process.
testing should be focused on this configuration:

Supplier activibes typically include:

Sh)

* supply of the product

" production of specifications and test specifications-on behalf

of the regulated company

* SuUpPOT during configuration and testing

" user documerniation

 pepuBeote
Page 26 AMP5
A Risk-Based Apormach to Compliant Gx? Computerized Systems

Ape aan Seesuesq my aooz-dy |) uo TeleyNs; Deagne) oO) peSuEsy UE

= training

" support and maintenance activities

The supply of the product and configuration may be periormed by cifferent suppters-

Note that more complex confiqured systems may involve product customizations (changes to supplier delivered
software) and new custom software, such as for interaces.

4.26.3 Example ofa Custom Application

Some computenzed systems are developed to meet individual user requirements, where no commercially available
solution is suitable,

Such systems are becoming less common a3 companies use more standard products. The software developed for
such systems classified as GAMP Categary 5.

In such cases..and based on satisfactory supplier and risk assesements, the following approach consisting of four
main levels of specification and verification is typical. The number of documents required to cover these levels will
depend on the complexity and impact of the system. For example, for a small system the design specifications may
be combined into one document.

Uoinpcde aupry Oy
Figure 4.4: Approach for a Custom Application (Category 5}

Primary
Responsibility

Reguiated
Gompany

Sela a on / +

S Buna
paed
“uy Syqueiss urswiogy Kd pag
Verification

v
Supplier

Supplier Knowledge and Technical Expertise Supplier

QMS
 popB Ad
GAMP 5 Page 37
4 Risk-Based Approach to Compliant GeP Computerized Systems

Ua
OF PeaET
Testing typically covers:

* correct installation

TRANS
" functionality and design

IO] Bog 2ud yor b uo THN

* tests that demonstrate fitness for intended use and allow acceptance of the system against requiremenis

' any further iests as aresult of risk assessments and supplier assessments

Regulated companies should decide upon the required levels of specification and venfication, and many of ihe
projéct phase actvities and documents may be delegated. Since the system is new, rigorous testing should be
patormed at both tunctional and design levels.

Supplier activities typically include production of specifications and test specifications on behalf of the requiated

SoeswesH
company, development of new software, testing, user documentation, training, and suppor and maintenance
activities,

Ajo oS
Complex systems may require a further hierarchy of specifications covering hardware design specifications. and
configuration specifications.

Oy
4.2.6.4 Tenninaiogy

SOAR,
The specific terminology used io describe life cycle activities and deliverables vanes fram company to company and
from system type io system tyoe. There are a number of reasons for this, including:

HS Uc) SSR
" equated companies having different epproaches

* difference in emphasis of GLP GCP GMP. and medical devices

Bunuornyec
' difference in emphasis of various reguiatory agencies

* different intemational or local standards being followed

“pa pkedd
" different types of computerized systems (e.g, 17, manufacturing, and laboratory systems)

Ag PSEC)
" suppliers using a range of different develooment models and approaches

This Guide ain to be fexible, and does not intend to prescribe any one set of terns to the exclusion of others.

|
The terms used to describe venfication activity in particular is a much debated area. This section describes haw
qualification terminology, as traditionally used, relates to the activities described in this Guide. This will assist readers OO

who use this terminology with the application of this Guide.

SHIRES

Whatever terminology is used for verification activity, the overriding requirement is that ihe regulated company can
demonstrate that the system is cornpliant and fit for intended use.
Su)
 payametd
Page 38 GAMP5
4 Risk-Based Aporoach to Compliant Ger Computerized Systems

jue 88n = aeduedy 15) Gonzi yr | no Dede yNsy ZeHeNE) Oy pedEsy PUMe
Table 4.1: Relationship between Traditional Qualification Terminclogy and GAMP 5 Activities

Traditional Term Description GAMP 5 Verification Activity

Design Documented verification that the proposed Design review (See Section 4.2.5 of this
Qualification (DC) design of facilities, systems, and equipment (Guide for further details)
is Suitable for the intendsd purpose.

Installation Documented verification that a system is Checking, testing, or other verification to

Qualification (12) installed according to written. and demonsirate correct:
pre-approved. specifications. * installation of software and hardware
* configuration of software and hardware
(See Appendix D5 for details)

Operational Documented verification thata system Testing of other verification of the system
Qualification (22) operates according to written and against specifications to demonstrate
pre-approved specifications throughout comect operation of functionality that
spectied operaiing ranges. suppomS the specific bUSINGSS process
throughout all specifed operating ranges.
(See Appendix DS for details)

Perfonnance Documented verification that a system is Testing of other verification of the system to

of)
Qualification (PQ) capable of performing the activites of the demonstrate fitness for intended use and to
processes it is required to perform, accorcina allow acceptance of ihe system against

UU
te written and pre-approved specifications, speciied requirements.
within the scope of the business process (See Appendix DS for details)

poudes
and operating environment.

Jo Udon
Note: The use of qualification terminology in relation to computerized systems and the relationship between OO and
Pt in particular, varies from company to company. The above comparisons. provide a general interpretation only and

Gp Bunpdeapeu
are not intended to be prescriptive.

Regulated companies should decide on a venfication approach appropriate to a specific system. Testing activities
should be selected based on the risk, complexity, and novelty of the system as described in Section 4.2.3 of this

eka
Guide.

The exemples in Section 4.2.6 of this Guide illustrate the typical different levels of testing applied to different

SEC]
categories. of system, such as:

EPI
* module testing

Aq
* integration testing
Oy

* configuration testing
UALS

* functional testing
Sill

. peguirements testing

Table 4.1 lists various GAMP venfication activities. There is no one-to-one relationship between the levels of testing
and the GAMP verification activities, for example:

" Fora typical Category 2 system, testing of both installation and configuration are covered by requirements
testing.
 IAY
GAMP5 Page 39

“AUS oSn S eegueon Do) BOOZ diy-pL lb ZeSaNe, DeeRgNes oO) PesueeH peuaRRU Pop
A Risk-Based Approach to Compliant GxP Computerized Systems

' Fora typical Category 3 system, tesis aré executed to demonstrate fliness for intended use and to allow
acceptance of the system against user requirements. There is typically mo need for further testing to
demonstrate correct operation of standard functionality of the product.

'" For atypical Category 4 system, while testing of configuration is covered by configuration testing, testing of
installation may occur at-any of the testing levels depending on the proyect.

' Fora typical Category 5 system, correct operation of functionality that supports the specific business process
may be covered by module testing, integration testing and functional testing, and. may be supplemented by
pre-delivery testing.

The relationship between the required verification and the diferent levels of testing, particularly for GAMP Category 4
and GAMP Category 5 systems, may be complex: The verification or test sirategy for a particular system should
ensure that the required ventication activities aré adequately covered.

Acceptance of ihe system by the regulated company as being fit for release for operational use includes satisfactory
completion of an agreed set of verification activities. For some systems, this may occur in stages including the
leveraging, wherever possible, of testing or other acceptance activities performed prior to, and after, delivery.
Commonly used terns within such a process include Factory Acceptance Testing, Site Acceptance Testing, and
System Acceptance Testing. Venfication activities should not be duplicated unnecessarily.

Onn Bdidad Deu, Of)

Whichevertenns aré used, the verficaton sirategy should cleary define which actvities should be satisfactorily
completed to allow acceptance of the system for release into operational use by the regulated company.

See Appendix D5 for further quidance on aspects of testing.

43 Operation

s: Buono
This séction provides comprehensive guidance on system operation. Not all of these activities will be directly
relevant to all systems. The approach and required activities should be selected and scaled according to the nature,
sk, and complexity of the system in question.

Paula
As part of preparing for final acceptance and formal handover for live operation, the regulated company should
ensure that appropriate operational processes, procedures, and plans have been implemented, and are supported
by appropriate training. These procedures and plans may involve the supplier in support and maintenance activities.

Ad Be)
Once the system has been accepted and released for use, there is a need to mainiain compliance and fitness for
intended use throughout iis operational life. This is achieved by the use of up te date documented procedures and
training that cover use, maintenance, and management.

The operational phase of a system may last many years; and may include changes to software, hardware, the LO
bUSINGSS process, and requiatory requirements. The integrity of the system and its data should be maintained at.all
times and verified as part of periodic review.
oy SSS

As experience is gained during operation, opportunities for process and system improvements should be sought
based on penodic review and evaluation, operational and performance data, and root-cause analysis of failures.
Information fram the Incident Management and CAPA processes can provide significant input to the evaluation.

Change management should provide a dependable mechanism for prompt implementation of technically sound
improvements follawing the approach to specification, design, and verification described in this document The rigor
of the approach, including extent of documentation anc verification, should be based on the nsk and complexity of
the change.
 peed
Page 40 GAMP 5
A Risk-Based Aporoech to Compliant GxP Computerized Systems

Oo] pesiiady Ua
Maintaining systern compliance involves many interelated activities. Figure 4.5 shows the major relationships
between rélated groups of these activities. Service management and performance monitoring occur throughout the
operational life of the system. Other activities, such as change management, occur when iriggered.

uO ZeheqnS lens
Figure 4.5; Major Information Flows between Operational Activities
Operational life of
bs system begins

Service or Operatanal Superseded

Apo esn Seesuady JO) Boge)

Suppor required records generated or ready to
be replaced

System security (sues [sue resolved:

and administration Request fulfilled;
requests Security and
received administration
records generated
Pala oe a

Change
completed
and change

op)
A system management
Scheduled

ey
change is necards
required generated
record
management

gi funponied io us_cnpod
activityilask
becoming due
Scheduled Incident
SUppOM activity! ] resolved and
penormance ! preventative
monitoring task An actions
becoming ove incident taken where
required

Paled
Incident
escalated

oso | Aq peng Ese

Businece = les
F continues:

Ca Audit records
Heciee generated
SMe

actions
identified
“Sy

SeMvice PScords and PErOImaAnce

information generated
 pepubente
GAMP.5 Page 44
4 Risk-Based Approach to Compliant xP Computerized Systems

me
PAL SENS) Oo) Pesues)
Some of the groups of activities shown in Figure 4.5 contain several individual related processes, procedures, and
plans, 25 described in Table 4.2.

Table 4.2: Grouping of Operational Processes

Group of Processes Process Appendix

uo Teleans
Handover Handover Process oF

Service Management and Establishing and Managing Support Services O2

Performance Monitoring Performance Monitoring 3

16) Goo Fudyp)

Incident Management Incident Management O4
and CAPA CAPRA Os

Change Management Change Management O6

Configuration Management 6

Saesguecq
Repair Activity OF

Audits and Review Periodic Review 18

“Apo asr
Untemal Quality Audits not covered by GAMP 5)

Continuity Management Backup and Restore Og

Business Continuity Planning O10

GR)
Disaster Recovery Planning O10

sou
Securiy and System Secunty Management O11
Adminisiration Systems Administration O12

Baie lued S Bunpraleu1? UO pode

Records Management Retention O13
Archive and Retrieval O13

These processes aré supported by OMS activities, such as document management, raining management, and the
maintenance of up to date end user procedures.

The individual support and maintenance processes required to maintain ihe compliance of compuierized eysiems
during operation are briefly described below and covered in more detail in the Operational Appendices as shown in
Table 4.2.

See (TIL? (Reference 26, Appendix G3) for further detail on IT service management. See Appendix G3 for other

Ag pea)
useful standards and quidance.

4.3.1 Handover Process

Handover is the process for transfer of responsibility of a computerized system from a project team or a service uO
Qfoup io a new Service group.
eS

This 3 an important process: achieving compliance and fitness for intended use on it own may not be enough ta
Quarantee a successful transfer into ihe operatonal phase.
au

The handover process will fyoically involve the project team (development group and/or supper), process owner,
system owner, and quality unit. The support group should be involved at the earliest opportunity,

See Appendix 071 for further details.

* Tne IT infrastructure Litrary® (ITIL} ls the most widely accepted approach to [T service management. ITIL providesa conasive cet of best practice
drawn from the public and private sectors Intematlonally.
 peayfeatec
Page 42 GAMP 5
4 Risk-Based Approach ta Compliant GaP? Computerized Systems.

mage
OY PesuEdy
4.3.2 Service Management and Performance Monitoring

Figure 4.5 shows only the major relationships between operational processes. Service management and

UO Tee ENE) Deane;

performance nvonitoring aré shown related to records management due to records generated to demonsirate proper
operation and performance of a system. In addition, tere is potential interaction with incident management and
CAPA and change management when the results of the service or monitoring indicate there are issues which need
addressing. For canty, these interactions are not shown in Figure 4.5.

43.27 Establishing and Managing Support Services

JO) BOOZ Mil

The support required for each system, and how itwill be provided, should be established. Support may be provided
bycextemal or intemal resources. This process should ensure that support agreements, maintenance plans, and
SOPs are established.

See Appendix O2 for further details.

goestesn
Performance Monitoring

AjUO sen
The impact of system failure will vary depending on ihe criticality of the computerized system. Where aporopriate,
performance of the system should be monitored to capture problems ina timely manner. li also may be possible ta
anticipate failure through the use of monitoring tools and techniques.

Of
pT
The need for performance monitoring should be considered, and required activities scheduled and documented.

poe
See Appendix 03 for further details.

USI
4.39 Incident Management and CAPA

es BunOn)euo
433.1 Incident Management

The incident management process aims to categorize incidents to direct them to the most appropriate resource or
complemeniary process to achieve a timely resolution. There should be a procedure defining how problems related
to soitware, hardware, and procedures should be captured, reviewed, prontized, progressed, escalated, and closed

Depued
This includes the need for processes to monttor progress and provide feedback.

See Appendix 04 for further details,

Ad pe)
fF.a2 Comective- and Preventive Action (CAPRA)

CAPA is a process for investigating, understanding, and correcting discrepancies based on root-cause analysis,
while attempting to prevent their recurrence,
LoS

In the operational environment ihe CAPS process for computerized systems should feed into, or be partof, the
Siu) SQUES

overall CAPA system used for the rest of operations. When incidents occur, or when opportunities to reduce process!
system failures aré identified by other means, corréctivé actions and preventive actions should be identified and
processes established to ensure that these are implemented effectively, CAPS can provide a solution fo problem
contre! as described in ITIL Problem Management (Reference 36, Appendix G3).

See Appendix 05 for further details.

 peUBeNd
GAMP.5 Page 43
4 Risk-Based Aporoach to Compliant GxP Computerized Systems

Teens; OL PoUEdH uate

Change Management

Change Management

Change management is a_cntical acthety thai is fundamental to maintaining the compliant status of systems and
processes. All changes that are proposed during ihe operational phase of a computerized system, whether related to

Aud een saegedh my GOOF diyph uo Tene:

software (including middieware), hardware, infrastructure, or use of the system, should be subject to a formal change
control process (see Appendix OF for guidance on replacemenis}. This process should ensure that proposed
changes are appropriately reviewed to assess impact and risk of implementing the change. The process should
ensure that changes are suitably evaluated, authorized, documented, tested, and approved before implementation,
and subsequently closed.

The process should allow the rigor of the approach, including the extent of documentation and verification, to be
scaled based on the nature, risk, and complexity of the change. Some activities such as: replacements and routine
system adminisiration tasks should be covered by appropnate repair or system administration processes.

Change management should provide a mechanism for prompt implementation of continuous process and system
improvements. based on penodic review and evaluation, operational and performance data, and root-cause analysis
of failures.

See Appendix O6 for further detaiis.

soiping opy
Gonfiguratian Management

fo vononpouden
Configuration management includes those activities necessary to precisely define a computerized system at any
point during its fife cycle, from the initial steps of development through to retirement.

A configuration (emis a4 component of the system which does not change 25a result of ihe normal operation of the
system. Configuration ttems should only be modified by application of a change management process. Formal

$7 Gunyrovjeu
procédures should be established to identify, define, and baseline configuration items, and to contra! and record
modifications and releases of configuration items, including updates and paiches.

See Appendix O6 for further details.

powuuad
4343 Repair Activity

AG DOTA
The repair or replacement of defective computenzed system components, typically hardware or infrastructure
related, should be managed in accordance with a defined process. Such activities should be authonzed and
implemenied only within the context of the change management process. Many repair activities are emergencies and
fequire rapid resolution so the incident and change management processes should be designed to-allow such

USHUOy
activities to occur without delay or increased risk io the operational integrity of the computerized system.

See Appendix OF for further detaits.

Sys

4.3.5 Periodic Review

Su)

Periodic reviews aré used throughout the operational life of systems to verify that they remain compliant with
regulatory requirements, fit for intended use, and meet company policies and procedures. The reviews should
confirm that, for components of a system, the required support and maintenance processes and expected regulatory
controls (plans, procedures, and records) are established.
 peyudiatc
Page 44 GAMP:5
4 Risk-Based Approech to Compliant GxP Computerized Systems.

SEL
oy
Penodic reviews should be:

oO} SU
* scheduled at an interval appropriate to the impact and operation history of the system. Risk assessments. should

PEED
be used to determine which sysiems are in scope and the frequency of periodic review.

* perfonned in accordance with a ore-defined process

UO PONS
* documented with corrective actions trackéed.to satisfactory completion

Electronic data archives holding GxP data from retired systems also should be subject to periodic review. See the

cdl yp
GAMP Good Practice Guide: Electronic Data Archiving (Reference 34, Appendix G3} for more details.

See Appendix 08 for further details.

I) GO
4.3.6 Gontinuity Management

SSO
43.61 Backup and Restore

SSF
Processes and procedures should be established to ensure that backup copies of software, records, and data are

AU
made, maintained, and retained for a defined penod within safe and secure areas.

Oty
Restore procedures shoud be established, tested, and the resuits of that testing documented.

Ly
See Appendix 09 for further details.

pou
Business Continuity Planning

si Duroeel io UO
Business continuity planning is a series of relaied activities and processes concemed with ensuring that an
organization is fully prepared to respond effectively in the event of failures and disruptions.

Critical business processes and systems supporting these processes should be identified-and the risks io each
assessed. Plans should be established and exercised to ensure the imely and effective resumoton of these critical
business processes and systems.

poqebed
A Business Continuity Plan (BCP) defines how the business may continue to function and handle dats following
failure. It also defines. the sieps required to restore business processes following a disruption and, where
appropriate; how data generated during the cisruption should be managed.

SH]
The BCP also identifies the triggers for invoking the BCP roles and responsibilities, and required communication.

| AC
See Appendix O10 for further details.
LU

4.3.6.3 Disaster Recovery Planning

DUES

As a subset of business continuity planning, plans should be specified, approved, and rehearsed for the recovery of
specific systems in the event of a disaster These plans should detail the precautions taken to minimize the effects of
Su)

a disaster, allowing the organizaton to either maintain or quickly resume critical functions. There should be a focus
on disaster prevention, ¢.g¢., the provision of redundancy for critical systems.

See Appendix O10 for further details.

 peqyBkd
SAMPS Page 45
4, Risk-Based Approach te Compliant (xP Computerized Systems

yeu
0] pesu|dy
43.7 Security and System Administration

£377 Secunty Management

Rens;
Computerized systems and data should be adequately protected against wilful or accicental loss, damage, ar
unauthonzed change.

UO Pade yey
Procedures for managing secure access, including adding and removing privileges for authorized users, virus
management, password management, and physical security measures should be established before the systern is
approved for use.

ype
Role-based secunty should be impemented, if possible, to ensure that sensitive data and functions are not

Geese y Io) eed

compromised. Security management procedures should apply to all users, including administrators, super-users,
users, and support siait (including supplier support staffi.

See Appendix 0117 for turther details.

43.7.2 System Administration

‘Ajo een
Once a system is in operation the users of the system will require support. The System Administration process
provides administrative support for systems, including performance of standard administration tasks. The extent of

OF)
this process varies greatly depending on the nature of the system.

YL
See Appendix 012 for further. details.

Jo boyspedes
43.8 Record Managemem

£3.84 Rstentiont

Buono”
Policies for retention of regulated records should be established, based on a clear understanding of regulatory
requirements, and exising corporate policies, standards, and quidelines.

See Appendix O73 for furnner details.

(pau
Archive and Retrieval

Aq pep)
Archiving is the process of taking records and data offsine by moving them toa different location or system, often
protecting em against further changes.

Procedures for archiving and reiriéval of records should be established based on a clear understanding of réquiatory
requirements.
wes

See Appendix O73 for further details:

bf DIRE eS

The GAMP Geod Practice Guides: A Risk-Based Aporoach to Compliant Electronie Records and Signatures and
Electronic Date Archiving givé further details.
 de:
pep
Page 46 GAMP 5
A Risk-Based Aporoach to Compliant GaP Computerized Systems.

poe
Oy pesueny
44 Retirement

This section covers system withdrawal, system decommissioning, system disposal, and migraiion of required data.

ZENER
4.4.1 Withdrawal

RN
Removal of the system from active operations, ).2., users are deactivated, interfaces disabled. No daia should be
added to the system from this. point forward. Special access should be retained for data reporting, resuits analysis

UO Te
and support

Jo) GOoZ-M york

44.2 Decommissioning

The controlled shutdown of a retired system.

4.4.3 Disposal

SeesueoH
Data, documentation, software, or hardware may be permanently destroyed. Each may reach this Stage at a different
time. Data and documentation may not be disposed of until they have reached the end of the record retention period,

“AO ean
85 specified in the Recon Retention policy.

Due to the volumes of daia and records involved, retirement can be a major task, for IT systems. in panicular.

op
Consideration should be given to-

perder
* establishing procedures covering sysiem retirement, inciuding witherawal, decommissioning, and disposal as
aporopriate

Jo usp
* documentary evidence to be retained of actions taken during retirement of the system

« (3xP records to be maintained, their required retention periods, and which records can-be destroyed

9 Boppenes
* the need to migrate records ta a new system or archive, and method of venting and documenting this process

* ability to retrieve these migrated records on the new system

“pamed
Further guidance is also provided in the GAMP Good Practice Guide: A Risk-Based Approach fo Compliant
Fiectronic Records and Signatures.

AG peInGpSEC)
See Appendix M10 for further details:

4.44 Pata Migration UOMO

Data migration may be required when an existing system is replaced by a new system, when-an operational system
experiences a significant change, or when the scope of use of a system changes. The migration process should be
SIppUeS

accurate, complete, and verified,

See Appendix DF for further details.

“S|
 tds
GAMP 5 Page 47

BRE IED OL BsrSuScHy (RUE pop

4 Risk-Based Approach to Compliant GxP CGomputerized Systems.

9 Quality Risk Management

Section 3 of this Guide introduced the concept of quality risk management as part of the life cycle approach. This
Section gives an overview of the quality risk management process and 4ppendix M3 provides more detail.

bE)
This section is primarily aimed at new computerized systems. It does not imply that formal risk assessments are
required for all exisiing systems. The extent of risk management required for existing systems, including ihe need for
formal nsk assessments, should be considered as part of periodic review.

2D) GORA gp
This séction focuses on software products and custom applications rather than on infrastructure.

5.1 Overview

cs aesuEH
Quality risk management is a systematic process for the assessment, contral, communication, and review of risks. It
is an iterative process used throughout the entire computerized system life cycle from concept
to retirement.

AoSer
Figure 5.1 indicates hey areas for risk management and the benefits of the approach:

ny Op
Figure 5.1: Overview and Benefits of Risk Management

i poqsnpods
Identify
Risks

ge Gupovjau
Analyze and Review
Evaluate Risks. Risks

Ded
USALTOR| Ag POS
Control
Risks

DYMAISS

(Input) (Output)

Fora given organization, a framework for making risk management decisions should be defined to ensure
“Sp

consistency of application across systems and business functions. Terminology should be agreed upon, particularly
regarding definitions and metrics for key risk factors.

Such a framework is most effectively implemented when itis incorporated into the overall QMS, and is fully
integrated with the system life cycle.
 pone wd
Page 48 GAMP 5
4 Risk-Based Aporoeach to Compliant GeP Computerized Systems

eg
a2 Science Based Quality Risk Management

ee) RE
Determining the nisks posed by a computerized system requires a common and shared understanding of:

SE,
* impact of the computerized system on patient safety, product quality, and data integnty

" supported business processes

UE)
* (OAs for systems that monitor or conirol CPPs

‘pk
* user requirements

Id) Ege
* fpeguiatory requirements

*" project approach fcontracts, methods, timelines)

Seesiady
" sysiem components and architecture

Ajud ean
* gysiem functions

* supplier capability

op)
mary
The organization also should consider other applicable risks, such as safety, health, and environment.

io oppo
Managing the risks may be achieved by:

" elirninaton by design

" reduction to an acceptable level

sf unpaved
* yerficaton to demonstrate that msks aré managed to an acceptadle level

Itis desirable to eliminate risk, if possible, by modifying processes or system design. Design reviews can play a key

peed
role in eliminating risk by design.

Risks that cannot be eliminated by design should be reduced to-an acceptable level by controls or manual
procedures. Risk reduction includes applying controls to lower the severity, decrease probability, or increase

Aq BAM
detectability.

A systematic approach should be defined to verify that the isk associated wiih a system has been managed to an

uonuoy)
acceptable level. The overall extent of verification and the level of detail of documentation should be based on the
risk to patient safety, product quality, and data inteonty, and take into account the complexity and novelty of the
system.
Spiess

The information needed to perform risk assessments may become available, and should be considered, at different
stages in the life cycle. For example, the high-level risks associated with & business process néed tobe understood
"Sly

before the sks associated with specific functons of computerized systems can be assessed.4

The criticality of a business orocess 1s independent of whether it is manually processed, semi-automated, or fully
automated. Systeme that suport critical processes include those that:

" generate, manipulate, or control deta supporting regulatory safety and efficacy submissions

* O0As of drug development and manufacture will intuence the understanding of the Impact of the business process, while Critical Process Parameters
wil Influence the impact of specific computerized functions.
 RoaeiL pd
GAMP 5 Page 49
A Risk-Based Aporoach to Compliant GeP Computerized Systems

Oy poses
' control critical parameters and data in pre-clinical, clinical, development, and manufacturing

* control or provide data or information for product release

Ene) Bone)
* control data. or information required in case of product recall

' control adverse event orcomplaint recording or reporting

uO Rea
* support pharmacovigiance

‘Apo eon Seetuacy I) aGog-ei yk

53 Quality Risk Management Process

The ICH Guideline CH 25 describes a systematic approach to quality risk management intended for genera!
application within the pharmaceutical industry. It defines. the following two primary orinciples of quality risk
management

' The evaluation of the risk to quality should be based on scientific knowledge and ultimately link to the protection
of the patient

' The level of effort, formality, and documentation of the quality nsk management process should be

Of)
commensurate with the level of risk.

Bum onped uo UOHn pode: Ty

In the context of computenzed systems, scientific knowledge is based upon the system specifications and the
business process being supported.

This Guide uses the following key terms taken from ICH G9.

Harm: Damage to health, including the damage that can occur from loss of product quality or availability.

Hazard: The potential source of harm.

pDaued-
Risk: The combination of the probaility of occurence of harm and the severity of that harm.

Severity: A measure of the possible consequences of a hazard.

Ad peuqsi
This Guide applies the general principles of ICH O49 to describe a five step process for risk management as an
Integral parbof achieving and maintaming system compliance. For simple or low risk systems, some of these steps
may be combined. See Appendix M3 for further details on ihe quality risk management process.

This process is focused on managing risks during the project phase. Risk management also should be used
appropriately both within specific activites and during the operation phase. Examples include: oso)
Sous

1. determining the need for supplier audit as part of supotier assesement

2. determining comectivé actions arising from test failures

Sob)

3. determining impact of proposed changes as part of change management

4 determining frequency of periodic reviews

Application of risk management to ihe above activities is. covered in the appropriate sections of this Guide.
 peo
Page 50 GAMP 5
A Risk-Based Aporosch ta Comphant GxP Computerized Systems

Ne) Benne) Oo) Petey BU

Organizations
may have established risk management processes, including the use of methods such as those listed
in Appendix M3. While this Guide describes one suggested approach, it does not intend or imply that these existing
methods should be discarded, rather that they continue to be used, as aporopriate, within the context of an overall
Quality risk management framework consistent with ICH O49.

Figure 6.2: Quality Risk Management Process

uo Zea
Perform Initial Risk Assessment
3 1 i
a and Determine System Impact

yh
Ao eon Seesuacy 1) egoF-
Step 2 Identify Functions with Impact on Patient
Safety, Product Quality, and Data Integrity

s 3 Perform Functional Risk Assessmenis

Of)
tep and Identity Gontrols

palmued-G Bunpenjau ud uonsapomden Bur

Step 4 Implement and Verify Appropriate Controls

Step 5 Sich sl a and Monitor Controls

Ad Bee
Step 1— Perform Initial Risk Assessment and Determine System Impact

An initial risk assessment should be performed hased on an understanding of business processes and business risk
assessments, user requirements. regulatory requirements, and known functional areas. Any relevant previous

ues)
assessments may provide useful input, and these should not be repeated unnecessarily.

The reguits of this inital risk assessment should include a decision on whether the system is GxP regulated (i.e.
“Su Sys

(xP assessment). It also should include an overall assessment of system impact.

Based on this initial risk assessment and resulting system impact, it may not be necessary to perform the
subsequent steps of the process, as the level of risk may already be at an acceptable /evel.

The Specific Jevel of effort, formality, and documentation of any subsequent steps should be determined based on
level of risk and system impact See Appendix M3 for further details.

If relevant, regulated electronic records and signatures should be identified. Again, existing assessments may
provide useful input and should not be repeated A detailed approach and specific guidance is provided in the GAMP
Good Practice Guide: A Risk-Based Approachto Compliant Electronic Records and Signatures.
 Ad
Bee
Page 51
4 Risk-Based Approach to Compliant GeP Computerized Systems

(
GO) PSS
Step 2— Identify Functions with impact on Patient Safety, Product Quality, and Data Integrity

Funetions which have an impact on patent safety, product quality, and data inteority should be identified oy building

NSS
on information gathered during Step 1, referring to relevant specifications, and taking into account prosect approach,
system architecture, and categorzation of sysiem components.

b Ud ESS gS}
Step 3— Perform Functional Risk Assessments and Identify Controls

Functions identified during Step 2 should be assessed by considering possible hazards, and how the potential harm
ansing from these hazards may be controlled.

PO) GME
PE
It may be necessary to perform a more detailed assessment thai analyzes further the seventy of harm, likelihced of
occurrence, and probability of detection. See Appendix M3. Section 5 for an example detailed assessment process.

The judgment as to whether to perform detailed assessment for specific functions should be dealt with on a case-by-
case basis and the criteria can vary widely. The crtena to be taken into account include:

Seeger
* criticality of the supported process

ALG Si)
* specific impact of the funcion within the process

OF
* nature of the system (é.9., complexity and novelty)

airy
Approoriate controls should be identified based on the assessment A range of options is available to provide the

uo WORN poder
required contra! depending on the identified nsk.. These include, but are not limited to:

' modification of process design

" modification of system design

st Buowieu
* application of external procedures

* pnereasing the detail or formality of specifications

“peared
* increasing the number and level of detail of design reviews

Ag PenISIC)
* increasing the extent or rigor of verfication activities

Where possible, elimination of risk by design is the preferred approach.

OSKORY
Step 4— Implement and Verify Appropriate Controls

The contra! measures identified in Steo 3-should be implemented and vertied to ensure that they have been
i] SOLUS

successfully implemented. Controls should be Taceable to the relevant identified risks.

The venfication activity should demonsirate that the controls are efective in performing the required msk reduction.

Step 5— Review Risks and Monitor Controls

During penodic review of systems, or at other defined points, an organization should review the nsks_ The review
should verity that conirals are stil effective. and corrective action should be taken under change management if
deficiencies are found. The organization also should consider whether:

" previously unrecognized hazards aré present

 paged
Page 52 GAMP 5
4A. Risk-Based Aporoach to Compliant GeP Computerized Systems

je
Oy pee
' previously identified hazards are no longer applicable

* the estimated nsk associated with a hazard is no longer acceptable

ZN
* the original assessment is otherwise invalidated (¢.9., following changes to applicable regulations or change of
gysiem Use)

Ney
Where necessary, the results of the evaluation should be fed back into the nsk management process. If here is a

yer b UO Deu
potential that the residual risk or its acceptability has changed, the impact on previously implemenied nsk control
measures shouldbe considered, and resulis of the evaluation documented. It should be noted that some changes
May justify relaxation of existing controls.

JO) BOGE
The frequency and extent of any periodic reveew should be based on the level of risk.

S9Gi90
ALO GN
OF
airy
uo WORN poder
st Buowieu
“peared
Ag PenISIC)
OSKORY
i] SOLUS
 pee
GAMP 5 Page 53
A Risk-Based Aporoach te Compliant GeP Computerized Systems

teseNs oy Pesesy Re
Regulated Company Activities
Responsibility for ihe compliance of computerized systems lies with the regulated company. This involves activities
at both the organizational level and at the level of individual systems.

Aue aon Seeeuedy wc) eOoE- eyo L bo Peles

Therefore, this section 1s divided into:

* (Govemance tor Achieving Compliance

* System Specific Activities

6.1 Governance for Achieving Compliance

Achieving rofust, cost effective, compliance requires strong governance. Key elements of successful governance
include the following:

*" establishing computerized systems compliance policies and procedures

OF)
' jdentifying clear roles and responsibilities

ie Uogonpendes Mun)
* training

* managing supplier relationships

* mamntaining 2 system inventory

-f Bunonpau
* planning for validation

* Continuous imarovement activities

peed
Effective gavemance is achieved by integrating these activities into the management of the organizathon. Each
activity i8.descnbed further in the sub-séctions below,

6.7.7 Computerized Systems Policies and Procedures

eH]
sud y Ad Bah
Esch reguiated company should have a defined policy for ensuring that computerized systems are compliant and fit
for intended use. The policy should typically include a cammitment to:

' identify and comply with all applicable GxP requirements

' integrate fife cycle activities into the regulated company's GMS
SYS

' identify and assess each system

|

' censure GeP regulated systems.are compliant.and fit for intended use acoording to established SOPs

* follow'a validation framework, including the use of validation plans and validation reports as necessary

* maintain compliance throughout the life of a system

 populate
Page 54 GAMP:5
4 Risk-Based Approach to Camphant Gar Computerized Systems

uae
oF pesuacy
Further details should be documented, €.9., in more detailed policies or in SOPs, which may be supplemented by
guidance and templates. These documents will typically address:

BEES
* — maintaining the system inventory

* determining the impact of systems on patient safety, product quality, and daia integnty

Mo) egdzad y+ L bo DaneNey

' defined roles and responsinilities

* the computerized system life cycle approach

* planning, supplier assessment, nsk management, specification, venficaton, and reporting activites and
documents

* system operation and managemeni, including up to daie operating procedures for end users and administrators,

segueon
and all operational processes described in Section 4.2 of this Guide

* fecord and data management

“AjUO eens
* security management

OR)
Policies and procedures should be developed taking into account existing policies, procedures, and oractices.

oyun)
6.7.2 Identifying Clear Roles and Responsibilities

so uo gon pode
Roles and responsibilities for activities should be documented, allocated, and communicated. Key responsibilities
include:

* defining, approving,.and maintaining policies and SOPs

“peyiued-s Bumronjeo
* compiling and prioritizing the system inventory

* producing plans and reports

* managing compliance and validation activites

Aq paIqUEsH]
* maintaining compliance during operation

The roles of process owner, system owner, quality unit, SME, end user, and supplier are particularly important and
are covered separately and in more detail in Section 6.2.3 of this Guide. The appropnate anc timely involvement af

UOROdY!
these key roles should be ensured.

6.7.3 Training
Sys

Training is the process that ensures that persons who develop, maintain, or use computerized systems have the
education, traming, and experience to perform their assigned tasks.
Su)

Procedures for training covering responsibilities, plans, and records should be established. The process owner
ultimately resconsible for ensuring thai all relevant persons are adequately trained. This responsibility may be
delegated, e.g., maintenance staff may be the responsibility of the system owner, and development staff may be the
responsibility of a project manager.

Persons in responsible positions should have the appropriate training. for the management and use of computerized
systems within their field of responsibility. This should include specification, verification, installation, and operation of
computerized systems.
 pepe
GAMP 5 Page 55
4 Risk-Based Approach to Compliant GxP Computerized Systems

SR
oO] Pee)
All users and support staff of a GxP requiated system, including contracted staff, should be given appropriate training
including basic GxP training. They also should be given specific training covering reguiatory aspects of using the
computerized system, 6c.. s@curity aspects, or the use of electronic signatures.

Tene)
For computerized systems, the regulated company should therefore:

UO TREN)
* establish the necessary training needs, including users, suppliers, cata centers, IT departments, enginesning,
maintenance

" provide training to satisfy these needs

Oy BOO Fe y+
" evaluate the effectiveness of the iraining

' ensure that staff aré aware of the relevance and importance of their activities, ¢.9., GxP

Seekueon
* ensure ihat supplier staff are adequately trained, €.9., as pan of supplier assessment

* maintain appropriate raining records

Ajuo an
" ensure Taining i maintained up to date, €.9., folowing system changes

ON
Avisk-based approach should be used to detemnine the rigor of training required, including measuring the

Un
effectiveness of training, and the retention of training records.

so oqoIpde
6.7.4 Managing Supplier Relationships

All phases of the computerized systems fife cycle require cooperation between the reguiated company and extemal
and intémal suppliers, including IT and engineering. Both regulated companies and suppliers have important roles. to
play in ensuring that suitable computenzed systems are deployed as part of regulated activity.

Roe
Reguisted companies should ensure that iniernal and external suppliers are made aware of the need for regulatory
comphance. The regulated company should venhy, prorto contract placement, that the supplier has adequate
expertise and resources to support user requirements. and expectations. The mast common mechanism for this is

Peed
the suppuer assessment, which may include an audit depending on risk, complexity, and novelby.

It should be noted that some suppliers, ¢.g., suppliers of commercially available software products or systems, will

IGLESi]
have Tutfiled a significant part of their responsibilities before any relationship is established with individual regulated
companies, and that this will have a major influence on any ensuing co-operation.

AE
Supplier activities aré covered in Section 7 of this Guide.

6.7.5 Maintaining the System inventory USO

Reguiated companies should maintain. an inventory of computerized systems, showing which are SxP regulated (see
ou) DPI

Section 5.3 of this Guide). The inventory should provide summary information such as the validation status,
ownership, impact, current system version, and supplier Automated equipment may be listed separately and
duplication should: be avoided.

Note: the inventory should be at the tevel of systems that support business processes, rather than individual items of
hardware, such as keyboards and routers which would be covered by local IT procedures.

The-system inventory may be used for planning periodic reviews.

 Pep beale
Page 56 GAMP5
4 Risk-Based Aporoach to Compliant GxP Computerized Systems

yl uo PeORNe) mAERNe) OF PesuEDy uae

6.7.6 Planning for Validation

Computerized system validation within a business unitis tyoically performed using a hierarchical framework of plans
covering (xP réequisted computenzed systems.

Computerized sysiem validation plans describe how toensure compliance and fitness for intended use of specific
systems. They specify scope, approach, resources, roles and responsibrities, and the types and extent of activities,
tasks, and deliverables.

See Section 3.3 of this Guide for further details on the computerized sysiem validation Tamework. See Appendix Mit
for more detailed guidance.

“Kjuo sn Seesueon I) Booz

6.7.7 Continuous Improvement Activities

Improving the processes used to achieve and maintain compliance and fiiness for intended use is highly desirable.
Performing these activities becomes more effective and efficient, and the risk of non-compliance is reduced.

Suppliers also benefit fram improving their processes for product development and support, and for other services
provided (see Section 7.2 of this Guide}.

Achieving improvements depends on an understanding of the effectiveness of the current processes and obtaining

a Bunponpeu Io iM_inpodai MYT) Of

relevant and objective measures of the quaity of both the process and the product.

61.7.1 Understanding

Understanding the effectiveness of the current processes is best gained by considering current levels of
conformance te the process (é.9., established by audit and trending performance) and by reviewing current
processes against recognized good practices. This undersianding should assist with identifying areas of the OMS
that may require improvement. For example, persistent non-confonmities in a particular process may be caused by
problems within the process. Aliematively a review of current processes may find scope for siréeamlining of these
processes based on developments in recognized good practice.

6.1.7.2 Metrics

paued
Metrics may be gathered throughout the system life cycle, including:

' design and development metrics (2.9. from desian and code reviews)

AQ Deu
' testing metrics (e.g., fram analysis of test failures and resulting actions}

* operation and maintenance metrics {e.g., from incident management, change management, backup and
restore} LOGY

Metrics should be collected only for a clear purpose. They typically provide information on one aspect of the
Su) DS

operation of the OMS, and may assist-with determining improvements to the QMS or to its use.

6.2 System Specific Activities

Table €.7 shows the typical reguiated company activites required for a configurable computerized system. Nate: this
table is indicative only. Activities required for a specific system should be determined based on msk, complexity, and
novelty. This section provides further details on each task.
 Ae
GARE
GAMP 5 Page 57
A Risk-Based Aporoach te Compliant GxP Computerized Systems

OY GaSe) aeny [ae SPALL

Tabte 6.1: Typical Activities for a Configurable Computenzed System

Step | Task Description

ENS,
te identify Compliance Compliance activities should be performed in accordance with applicable
Standards company policies and procedures.

yp lL Uo TEAS)
2: identify System The system should be added to an inventory of systems in accordance
with documented procedures.

2. identify Key Individuars These include Process Owner, System Owner, Quality Unit, SME,
Supptier, End User

4. Produce URS The User Requirements Soecification (URS) should define clearly and

10) GOOF
precisely what the regulated company wants ihe system to do, state any
constraints, and define regulatory and documentation requirements.

SSH
5. Determine Strategy for
Achieving Compliance

ca
* Risk Assessment An initial Risk Assessment should be performed during planning:

Gan
Depending on the sysiem, further assessments may be required as

ALS
specifications are developed.
* Assessment of System Ssysiem components should be assessed and categorized to determine

Sp)
Componenis the approach required.

J Ly
* Supplier Assessment The quality capability of a supptershould be formally assessed as part of
the process of selecting a sunglier and planning for achieving

i> LOL
compliance. The decision whether to perform a Supplier Audit should be
documented and based ona Risk 4ssessment and categorization of the
system. components.

B. Plan Activities including risk assessments, deliverables, procedures, and

62 Ga Ore
responsibiities for establishing the adequacy of the system should be
defined in a plan.

fe Review and Approve The-reguiated company should review and approve specifications, as

aed
Specifications appropriate. This could involve one or several specifications depending

PeqDLU
on the system. Design reviews may be used where appropriate.

é. Develop Tesi Strategy The regquiated company should determine what testing is required after

SEC)
considering the existing documentation available. Depth and ngor of
testing should be based on level of nsk and impact of system.

Ui Sy 1 Ag POC
9. Test The regulated company should ensure that testing defined in test
strategy i completed, and ensure review of test results.

10: Report and Release 4 report should provide evidence that ai planned celiverailes and
activities have been completed and that the system is fit for intended
use. Any deviations, or outstanding or comective actions, should be
explained and followed up a8 required by the regulated company. There
Su

should be a formal process covering release of system for operational

“Su

use by-end users.

17. Maintain System The regulaied company should establish adequate system management
Compliance during and operational procedures. See Section 4.3 of this Suide for further
Operation details.

12. System Retirement The regulated company should manage the withdrawal of the
computerized system from use, including migration of data to a new
sysiem, if applicable.
 pag oAd
Page 58 GAMP 5
4A Risk-Based Aporach to Compliant GeP Computerized Systems

(Be
Of PS]
Table &.1 shows typical regulated company activities for a configurable sysiem. Fora custom system, and based on
risk, there may increased levels of specification, review, and testing required.

SSS
6.2.1 identify Compliance Standards

Complianes and fitness for intended use should be achieved in accordance with applicable company policies and

UO SSNS:
procedures. Indusiry quidance, such as GAMP. should be treated as supporting information and should net
supersede company policies and procedures.

6.2.2 identify System

gE
The system should be assessed to determine whether it is GeP regquiated and added to the system inventory in

yO) EE
accordance with documented procedures (see Section 6.1.5 of this Guide}.

6.2.3 Identify Key Individuals

Seeeo
This séction describes key roles and responsibilities when achieving compliance. Designated individuals should
have sufficient experience and training to perform their respective roles.

SS
AL
Specific activities may be delegated to appropriate nommated representatives.

OF
62.34 Process Owner

_S ponder magn
The owner of ihe business process or processes being managed should be identified. The process owner is
ultimately responsible for ensuring that the computerized system and its operation is in compliance and fit for
intended use in accordance with applicable SOPs. The process owner also may be the system owner.

so uo
Speciic activities may include:

gf Bunce
* approval of key documentation #5 defined by plans and SOPs

' providing adequate resources (personnel including SMEs, and financial resources) to support development and
Operation of the system

Dated
* ensuring adequate training for end users

| Ad PENnSEC)
* ensuring that SOPs required for operation of the system exist, are followed, and are reviewed periodically

* ensuring changes aré approved and managed

' féeviewing assessment/audit reports, responding to findings. and taking approgriaie actions to ensure xP
compliance OSU
SEIS

* goordinating input from other groups (2.¢., finance, information security, safetwHSE, legal)

6232 System Guyver

SU)

The System Owner is responsible for the availability, and support and maintenance, of a system and for the security
of the data residing on that system. The system owner is-responsibie for ensuring that the computerized system is
supported and mainiained in accordance with applicable SOPs. The system owner also may be the process owner.

The Sysiem Owner acts on behalf of the users. Global IT systems may have a global system owner and local system
owners to manage local imolementation.
 ponB ite
GAMP 5 Page 59
4 Risk-Based Aporoach to Compliant GxP Computerized Systems

oF persed ee
Specific activities may include:

' approval of key documentation as defined by plans and SOPs

4p) uo Tenenne Baan;

* ensuring that SOPs required for mainienance of the system exist and are followed

" ensunng adequate training for mainienance and support staff

* ensuring changes aré managed

* ensuring the availability of information for the system inventory and configuration management

Io) aioe
' providing adequate resources (personnel including SMEs, and financial resources) to support the system

' reviewing audit reports, responding fo findings, and taking appropriate actions io ensure GxP compliance

Ss aesuesH
* coordinating nput from other groups (¢.9., finance, information secunty, safetwHSE, legal)

judas
6.25.3 Quality Unit

The term Quality Unit used here 25 an encompassing term that includes many qualitytelated rotes inat are

se Gunanlan im iiipoida aur, Oh

ipnportant to developing and managing requiaied computerized systenis. The manner in which a Quality Unit
addresses the responsabilities noted below may vary based on the applicable regulations. For example, the strict
interpretation of the GLP requirement for separation of duties may lead some companies to interpret this as requiring
that the GLP Quatity Unit audit a validation document rather than approve it. Regardless of the mechanism, ine
intent of achieving acceptance fram ihe Quality Unit is the same.

The Quality Unit has a key role to play in successfully planming and managing the compliance and fitness for
intended use of computenzed systems, and provides an independent role in the:

'" approval or audit of key documentation such as policies, procedures, acceptance criteria, plans, reports

' focus on-quality critical aspects

payed
* involvement of SMEs

' approval of changes that poientially affect patent safety, product quality, or data integnity

ussweyy Aq pn)
* audit processes and supporting documentary evidence to verify that compliance activities are effective

The role may be split into Corporate and Operational Quality depending on ihe organization. The following example
is-indicative only and titles and details of responsibility may vary between organizations. “Su, Suess

6.2.3.4 Corporate Quality

This group operates at the corporate level and is resoonsible for:

' getting policy

' maintaining an-oversiaht of company standards

' auditing for cornpliance

' Teviewing effectiveness of quality systems and processes

 Indo
Page 60 GAMP 5

pe
A Risk-Based Approach to Compliant GaP Computerized Systems

(aU
OF PeSUeoy
Reguiatory authorities require the Corporate Quality Unit to be independent of the business activities.

B35 Operational Quality

aRNe)
This, typically, is the Quality Unit of a-division or business unit. This group is invelved in the compliance of xP

UO ZeueIne “A
regulated computerized systems within the division or business unit and typically covers:

' tmplementation of quality standards and procedures for the development and operation of computerized
systems

ppl
" jeviewing risk assessment and control activities

JO) BOR
' support of proiect phase activities as defined in computerized sysiem valdation plans

' support of life cycle processes such as change control and document.management

eesuasH
' training related to computerized systems quality and compliance

“Ajud oat
* ‘agreeing approach to managing deviations with approval of any supdorting rationales

* quality management of extemal! service and applicaten providers (6.9. contractors, outsourcing organizations,

Op)
eic.)

Aur
Specific operational quality activities can be delegated to a variety of functions provided that independence can be

UoioApoidal
demonstrated. For example:

* JT departments may have their own quality management function.

* Engineenng depanments may have their own standards groups.

so Guana
" Suppliers and consultants may be authorized to assist.

Any such delegation should be cleary defined and their respective roles agreed and documented as part of

peed
planning. In all circumsiances, ine Quality Unit retains ultimate responsibility and accountability for compliance with
reguiations.

6236 Subiect Mater Expert

Rn
Qualified and experienced SMEs have a key role in performing reviews and assessments, and taking technical

Ad
decisions, based on science based process and product understanding, and sound engineering principles. Different

vosueyy
SMEs may be involved with different activities. 2.g., during specification and verification.

SMEs should take the lead role in the verification of the computerized system. Responsibilities include planring and
Syeies

defining verification strategies, defining acceptance criteria, selection of appropriate test methods, execution of
verification tests, and reviewing results.
“Sh,

SMEs may come from a wide range of backgrounds a5 required, including business process, engineering, IT,
supplier, quality, and validation.

bear Supper

Suppliers (including intemal suppliers, such as IT or engineering) should play an important support role in achieving
and mainiaining system compliance and finess for intended use. Specific activities may include: