pees el

GAMP 5 Page 64
4 Risk-Based Approach to Compliant GxP Computerized Systems:

pL US ZeluNe) BeweEne, Oo] persulesy me eu

* provision of existing documentation (266 Section 3.3 of this Guide)

"preparation and rewew of documentation

* acting as SME for technical aspects such as configuration and design options

"performing and supporting testing

* change and configuration management

* supporting processes geared toward maintaining system comoaliance, €.g., by providing software patches,
providing Second tier support for problem resolution processes, efc.

“AjUo ean seesiiady Io) OOF

See Section 7 of this Guide for further details on supplier activities.

6.23.8 End User

In addition to using the system in accordance with approved procedures, end users also may be involved in the
following activites through the life cycle:

* input fo user requirements and specifications

op)
may
" evaluation. of prototypes

pod
* festing

"acceptance of system and handover

id udp
* input to development of SOPs for use of system

6 Baonped
* reporting defects

" identifying opportunites for improvement

panied
6.2.4 User Requirements Specification

los | Ad Peas
This describes what the system should do. The URS is the responsibility of the regulated company, but may be
written by a third party or sugplier. It should be adequately reviewed by SMEs and approved by the Process Owner.
Other approvers may include the System Qwner and Quality Unit representative.

See Appendix 01 for further details on User Requirements Specifications.

6.2.5 Determine Strategy for Achieving Compliance and Fitness for intended Use
SU, SDSS

6.2.5.7 Risk Assessment

An initial isk assesement should be performed during Manning to determine whether the system is SxP regulated,
the impact of the system, and the need for further risk assessments. This process is described in Section 5 of this
Guide.

See Appendix M2 for further details on Risk Assessment.

 penetd
Page 62 GAMP &
A Risk-Based Aporoach to Compliant Ger Computerized Systems

BoNdaNs oy penEsy Ie
62s Assessment of Sysien Components

This process uses the revised GAMP software categornes and hardware categories as guidance in establishing the
required activities, based on haw the system is canstructed or configured.

See Appendix M¢ for further details on Categones of Software and Hardware.

IO) BOOM L no Zea)

2.5.3 Supplier Assessment and Education

The regulated company should formally assess each supplier to establish their quality capability. This is typically
performed by an SME and may involve an audit of the supplier depending on sk, complexity, and novelty The
assessment may find that a supplier has ether a wel-established, formal, QMS, or has atiained a recognized third
party certification, such as ISO 9001. The strategy should take account of assessment conclusions.

If another reguiated company has already assessed: the supplier for the same reason, then subject to that company

“Ajo Son Seasuedy

agreeing to share that information, an additional assesement may not be necessary. The justfication for not
assessing a specific supplier should be formally documented.

Requiated companies should be prepared to assist in the education and training of suppliers, either by direct
Involvement or oy providing advice on training requirements, sources of information, and sources of specialist
training and education, such as ISPE. It may be beneficial to supply example documents, where possible, to

oF)
establish the correct cantent and level of detail in the key documents.

o_onpeides QUT
See Appendix M2 for further details on Supplier Assessment.

6.2.6 Planning

Planning is an essential activity for any system development and should address all aspects, including activities that

tr Buona
demonstrate compliance and fitness for intended use. Responsibilities, deliverables, anc procedures to be followed
should be defined. Since the supplier may provide deliverables or directly support these activities, planning provides.
the opportunity to decide how best to leverage supplier activities and documentation io avoid unnecessary
duplication.

pelueed
See Appendix M1 and Section 3.3 of this Guide for further details on Validahon Planning.

6.2.7 System Specifications

Ad BA
There aré a number of yoes of specification that may be required to adequately define a system: These may include
Functional Specifications, Configuration Specifications, and Design Specifications.

The applicability of, and need for, these different specifications depends upon ihe specific system and should be
defined during planning. See Section 4.2.6 of this Guide for typical examples of the level of specification required for oy)
non-configured products, configured products,.and custom applications.
iu) SYS

Functional Ssecifications aré normally written by the sugolier and describe thé detailed functions of the system, Le,
what the system will do to meet the requirements. The reguiated company should review and approve Functional
Specifications where producedfor a custom application or-confiqured produc. In this situation, hey are often
considered to be @ contractual document.

See Appendix D2 for further details on Functional Specifications.

Configuration Specifications aré used to define the required configuration of oné or more software packages that
comprise the system. The regulated company should review and approve Configuration Specifications.
 Ac
Lu pee
GAMP 5 Page 63
4 Risk-Based Aporoach to Compliant GeP Computerized Systems

(Re
0) PH)
Design Specifications for custom systems should contain sufficient detail to enable the system to be built and
maintained. In some Cases, the design. requirements can be included in the Functional Specificaton: SMEs should
be involved in reviewing and approving design specifications.

Pens)
See Appendix D3 for further details on Configuration and Design.

ENS
A curent sysiem description should be available for regulatory inspection and training. This may be covered by the
URS or Functional Specification, or a separate document may be oroduced.

OO DR
See Appendix D6 for further details on System Descriptions.

JO) GOO Zang

6.2.7.1 Design Reviews

Design reviews evaluaié deliverables against standards and requirements, identify issues, and propose required
corrective actions. They are planned and systematic reviews of specifications, design, and development, and should

eoy
be planned to occur ai suitable stages during the life cycle. They aré-an important pan of the verification process.

Soe
Design reviews should be performed by SMEs, and involve others as required.

eet)
Ay
For non-configured products (GAMP Category 3}, design reviews by the regulated companies are not typically
required,

OR)
eR,
For configured products (GAMP Category 4), regulated company design review actvities should focus on the
configuration and any customizaton activities to meet user requiremenis.

oud
For custom applications (GAMP Category 5), design reviews are typically conducted at each level of detail of
specification.

LO
Supplier development activities, including reviews, should be verified during supplier assessment.

Se DOA
See Appendix M5 for further details on Design Review.

6.2.8 Development and Review of Software for Custom Applications

PSE
Software reviews aré not required for configured and non-confiqured software products. Custom applications and
cusiom software for configured products (e.9.. interfaces, macros, and report generation) should be developed in

BES)
accordance with defined standards.

The néed for, and extent of, reviews of new software during development should be based on risk, complexity, and

| A
novelty. Such reviews should be performed by an SME. The regulated company should ensure that corrective
actions resuliing from such reviews are tracked to satisfactory compleiion.
Ua

See Appendix D4 for further details on Management, Development, and Review of Software.
DUS

6.2.9 Test Strategy and Testing

“SU|

Section 4.2.3 of this Guide describes the use of testing as a fundamental part of verification activity, including the
develooment of a-tesi strategy.

The regulated company is responsible for ensuring that the test strategy will demonstrate compliance and fiiness for
intended use. The number and types of tests should be based on risk, complexity, and novelty as described in
Section 4.2.3 of this Guide. The role of the supplier, including use of existing supplier documentation, should be
considered when developing the strategy.
 PoRBe ie
Page 64 GAMP 5
A Risk-Based Aporoach to Compliant Ger Computerized Systems

PURE
OF PSUS)
The results of testing should be documented against predefined acceptance criteria based on specifications. Test
failures should be captured, reviewed, documented, and managed.

E) PURE,
See Appendix DS for further details on Testing of Computerized Systems. See Section 6.5 of this Suide for details on
efficient testing practice.

The GAMP Good Practice Guide: Testing-of GxP Systems provides comprehensive guidance on aspects of
computerized systems testing.

lo Za
6.2.70 Reporting and Release

SaeSUeOW boy Gog Zu yeh

At the conclusion of the project, a computerized system validation report should be produced summianrizing the
activities perfonned, any deviations irom the plan, any outstanding and corrective achons.and providing a statement
of fitness for intended use of the system: See Appendix MY for further details.

In some cases, specific computerized eysiem validation reports may mot be required (see Section 3.3 of this Guide}.

Release of the system into the operating environment in accordance with a controlled and documented process is

AUS aS
digtussed in Section 4.2.4 of this Guide.

6.2.97 Maintaining System Compliance During Gperation

Oh)
an,
The regulated company is responsible for maintaining system compliance during operation {see Section 4.3 of this
Guide}.

sd uo pS pde:
6.2.72 System Retirement

System retirement is described in Section 4.4 of this Guide.

+ Raonjeu
Paed
1 AC AQIS
uomOY
S| SYNOS
 pape
GAMP 5 Page 65
& Risk-Based Aporoach to Compliant GeP Computerized Systems

mete
PeWUeENS Op PeseoE
Supplier Activities
Although ihe responsibilty for compliance with SxP regulations jies with the réquiaied company, the supplier may
have considerable involvement in-the process.

AYN ese fOeSS0H 10) GOOF dye | UO PUNE)

Reguiated companies wish te leverage supplier knowledge and documentation, subject to suitability, following formal
assessment This may involve an audit depending on risk, complexity, and noveliy.

This section is written specifically to help suppliers to meet the requirements and expectations of ihe regulated
company. Some information from previous sections is included to give supphers a more complete picture.

FA Supplier Products, Applications, and Services

Suppliers provide a range of products. applications, and services for hardware, sofware, and related technologies
The relationship between supotier and regulated company will vary significanily depending upon ihe product,
application, or service being provided.

fi Non-Configured Product (GAMP Category 3)

RUA) OR)
lf the product is purchased off-the-shelf and does not require configuration to support business processes, or where
the default configuration is used by the regulated company, supplier involvement with the réguiated company 6,
typically, limited to the provision of documentation, training, support, and maintenance. The product should be

ipod)
developed and maintained by the supplier in-accordance with good practices [see Section 7.2 of fis Guide).

uo uci
T.7.2 Comigured Product (GAMP Category 4)

se Bemoenpeu
If the oroduct requires configuration to support specific business processes, supplier involvement with the regulated
company will, typically, include support with specification, configuration, verification, and operation of the system
(se Section 4 of this Guide}.

‘pated
Procedures to follow should be agreed between the regulated company and the supalier and be documented in the
appropriate plan. Procedures adopied may-be these of the requlated company of from ihe supplier OMS (see
Section 7-2 of thisGuide).

hey PegLased
The product ttséeif should be developed and maintained by the supplier in accordance with good practices (see
Section 72 of this Guide}.

.7.3 Custom Application (GAMP Category 5)

UAE SS GSA |
For a custom application, ihe regulated company typically contracts a supplier to develop the aplication based on
defined requirements. Therefore, the supplier will be involved during the full project life cycle of the system, and also
to provide suppon dunng system operation as described in Section 4 of tis Guide. Procedures to follow should be
agreed between the requiated company and the supplier and be documenied in the apprognate pian.
SU]

Procedures adopted may be those of the regulated company or from the supplier QMS (see Section 7.2 of this
Guide).
 pope id
Page 66 GAMP 5
4 Risk-Based Aporoach to Compliant GxP Computerized Systems

pUc
Oy peso”
rid Services

Suppliers that provide services should operate within a QMS (see Section 7.2 of this Guide). Quality planning should

Tene)
define ihé activities, procedures, deliverables, and responsibilities for establishing delivery and monitoring of the
service. Such a planis.a contractual document, and as such; should be approved for use by both the supplier and
the regulated company.

Seeciiody 16) Gog a-dy-rL UO ZIRE)

The required infomation may be satisfactorily covered by other contractual documents such as a Service Level
Agreement, in which case a separate plan would not be required.

The extent to which the good oractices described in Section 7.2 of this Guide apply to. services will vary considerably
depending on the scoge and nature of the service and should be defined as part of the supplier MIS.

Ti Supplier Good Practices

The table below lists good practice activities that apply to product and application developneent and support. These
are further described in this section of this Guide:

Ajit wr
The good practices also may apply to service provision (see Section 7.1 of this Suide).

perder equry op)

jo udp
2 Booed
‘peaurdd
SionuoY| Ad BeRAsO
SOROS
Su)
 cobitd
GAMP 5 Page 67
A Risk-Based Aporoach to Compliant Ger Computerized Systems

Ie
0] Bese
Table 7.1: Supplier Good Practices

Step Practice Description

PONS
1: Establish QMS The suggier QMS should:
1. Provide a documented set of procedures and standards

ns)
2. Ensure activities are performed by suitably competent and trained staff
3. Provide evidence of compliance with the documented procedures and

Uo Fee
standards
4. Enable and promote continuous improvement

i) enoz-adiy-tL
2. Establish Requirements The supplier should énsure that clear requirements are defined or
provided by the regulated compar.

a. Quality Planning The supglier should define how their QMS will be implemented fora
particular product, application, or service.

geecuedy
4. Assessments of Supliers should formally assess their sub-suppuers as pan of the
Sub-Supatiers process of selection and quality planning.

‘Apo ean
5. Produce Specifications The sugolier shoud specify the system to meet the defined requirements.

B. Perfonn Design Review The design of the system should be formally reviewed against
requirements, standards, and identified risks fo ensure that the system

oF)
will meet its intended purpose and that adequate controls are established

wun
to manage the risks.

mo dogipcide:
t. Software Production! Software should be developed in accordance with defined standards,
Configuration inchuding the use of code review processes. Configuration should follow
any pre-defined rules or recommendations and should be documented.

8. Perfonn Testing The suggier should test the system in accordance with approved test
plans and test specifications.

o Bnposjen
4. Commercial Release of the System release to customers should bé performed in accordance with a
System formal process. (Note: this is not release into SxP environment, which is
4 regulated company activity)

Palweed
10. Provide User Documentation | The supplier should provide adequate system management
and Training documentation, operational documentation, and training in accordance
wiih agreed contracts.

| Ag pe get
41. Support and Maintain the The supplier should suppor and maintain the system in accordance with
System in Operation agreed contracts. The process for managing and documenting sysiem
changes should be fully described.

Ot]
12. System Replacement and The supplier should manage the replacement or withdrawal of products
UPS
Retirement in accordance with a documented process and plan. The supper also
may support the regulated company with the retirement of computerized
systems in accordance with regulated company procedures,
Sys

7.3 Quality Management System

S|

[tis recommended that suppliers follow a QMS, oreferably based on recognized standards. The QMS should define:

* the orocess being followed to deliver and support the product, application, of service

* responsibilities, inclucing clear separation of authority between quality assurance and other groups, such as
product development, product support, finance or marketing
 poqUBpate
Page 68 GAMP 5
A Risk-Based Aporoech to Campliant xP Computerized Systems

BU
ZeeEne) oy penEy
" deliverables

* documentation

* planned reviews of the OMS and internal audits

J) BOOZ Ll OS Zenon)
* approach to continuous imorovement of the GMS and its use

The QMS should be based ona life cycle concept for the development and subsequent suppor of the comouterized
system. There aré many equally valid life cycle approaches that may be used by suppliers. This Guide does not
recommend any particular approach, but rather highlighis those activities expected of suppliers to support the
regulated company in achieving and maintaining compliance.

The OMS should include formal procedures covering the activites that suppor system development, such as:

“Apuccestl Reesuadg
" sofware management, control, and release

* development change contro!

* configuration management

Of)
* traceahility

Un)
* {raining of supplier statf

a: uno leu uo Uo pope

* document management

* backup and restore

Many sysiems developed today are based on software products and packages, which are confiqured to meei user
requirements. Such products, normally, well come with suaporting documentation, and where possible nis
documentation should be used in the system life cycle. Further modules of custom software may be required to
provide specific functionality, such as interfaces and reporns. The design and -cevelooment of such software should

(petued
be fully documented.

The QMS should cover the approach to continuous improvement. For example, CMMI (Reference 50, Anpendix G3)
provides an approach based on a iramework for assessing and improving organizational cagability.and maturity. The

Ag Be)
LSé Of Méeirics for Measuring and imaroving the quality of software and hardware should be considered as part of the
approach to improvement.

USS)
Industry guidance, such as GAMP, should be treated as supporing information and should not override the
supplier's established OMS. Si] Sous

4 Requirements

Requiremenis may be developed intemally by the supplier (in the case of product developmenii.

Requiremenis also may be provided by the customer (fora configured product, custom application, or a service).

The requirements should define clearly and precisely what the system should do and state any constraints,
Requirements should be reviewed and approved.
 Uo Tabeans; Zea GNes Of peGUed) jeUme peptic
GAMP5 Page 65
4 Risk-Based Approach to Compliant GeP Computerized Systems

Changes to requirements should be controlled: Changes to subsequent specification documents that affect the
requirements should lead to an update of the requirements.

Regulated companies wish to maximize the use of supplier testing to support their compliance activities. Therefore,
requirements should be written such that they can be tested. Individual requirements should bbe traceable through
the life cycle,

For oonfigured products and custon applications, the requiated company should describe the business processes to
be automated. In ihe case of configured products, these processes should be aligned with the functionality of the
product to be used. This may require significant process re-engineering.

“Apuo een geesuecy icy EO zdyL

See Appendix D1 for-further details on User Requirements Specifications.

5 Supplier Quality Planning

The supplier should define how the QMS will be implemented for a particular product, application, or service.

This should include defining the fife cycle madel being followed and the project organization, activities, procedures,
deliverables, and responsibilities for establishing the finess for intended use of the sysiem. The apgroach may
inciude prototyping or other software development techniques. The role of supplier Quality Assurance should be

‘pa uUed st Runjonjou susp onpoden iaupTy ON

clearly defined:

Thesé suopier quality requirements may be captured in a separate document entitled Quality Plan or other supplier
documentation. In each case, the quality requirements should be cleary documented, reviewed, approved,
accessible, and followed.

=ee Appendix M6 for further details on Quality and Project Planning.

7.5.9 Prototyping

Proiotyping methods may be used to clarity user requirements or to evaluate areas of nk. Typically. a prototype is
used to evaluate the acceptability of a user interface, the performance of critical algorithms, suitability of the overall
solution, or aspects of system performance such as capacity and speed.

To be effective, the aims and objectives of the prototype should be clearly defined, and the prototype evaluated
against these to ensure the objectives aré met. Suppliers. should define how information gained can b= incorgorated

Aq ING
inva controlled manner into specifications for the final product. This requires. rigoraus version control and segregation
of proteiype and final software.

7.6 Sub-Supplier Assessments Suess uso

Suppliers should formally assess their sub-suppliers as part of quality planning. They al=o should be penodicatly rée-
assessed in accordance with ihe GMS.
Su

The decision whether to perfonn an aucit of their sub-suppiers should be documented and based on a nsk
assessment The sugolier may find it advantageous to use the GAMP process for categorization of the sysiem
components in assessing risk.

See Appendix M2 for further details on Supplier Assessmenis.

 peed
Page 70 GAMP'S
4 Risk-Based Aporoach to Gampliant GaP Computerized Systems

Ue
Oo) PP SOOR
ii Specifications

For product development, ihe supplier should document ine functionality and design of ihe system to meet the

Ne)
defined requirements. This should cover software, hardware, and configuration.

Funetional specifications should clearly and completely describe what the product will do. They should be produced

UO Faun)
such that objective testing can be subseouently performed.

Design specifications should be based on the functional specifications and should be sufficiently detailed so that the
product can be developed.

IO) BOG P-iy-pL

Specifications may be covered by one or more documents depending on the complexity and risk of thé product.

Specifications should be reviewed and approved with traceability established between related documenis. They
should be managed under change control with the awareness that change to-one document may lead to a change

gaesuaoy
being required in others.

It is recognized that not ail suppliers use the specification terms described in this Guide, but may still meet the

AlUO SEn
objective of providing adequate specifications through ihe provision of other documentation.

See Appendices D2 and D3 for further details on Specifications.

Of)
Ja\pry
lf the supplier is mnvolved in configuring a product or developing a custom application, ine number and level af
specifications can vary considerably and should be agreed with the regulated company (see Section 6.2.7 of this

ro Uoqon pode)
Guide). Section 4.2.5 of this Guide provides examples of specification requirements for configured products and
custom applications.

1.8 Design Reviews

S) Bunovieu
Design reviews evaluate deliverables against standards and requirements, identify issues, and propose required
corrective actions. They should be planned and systematic reviews of specifications, design, and developmen, and
should be planned to occur at suitable stages during the life cycle, based on msk, complexity, and novelty. Design
reviews aim to identify and eliminate issues that would otherwise lead to changes at a later stage.

Pau
See Appendix M5 for further details on Design Reviews:

yA OSeTETLSECy
T4 Software Production/Configuration

The supplier should establish and maintain a formal system for controlling software production. Aporopriate meinods
and tools should be-used and the use of ihese should be documented. Rules and conventions, such as accepiable Lien

languages, coding standards, and naming conventions should be established. The use of code reviews should be
considered.
SUS

Existing software should be used in accordance with documented build processes and taking into account any
“Sa

changes in the system hardware, interfaces, and peripherals.

lf the supplier is involved in configuring a product, this should be performed in accordance with the controlling
configuration specification and follow appropriate guidelines and recommendations.

See Appendix D4 for further details on Management, Gevelopment, and Review of Software.
 pepueiid
SAMP 5 Page 74
4 Risk-Based Aporach to Compliant GeP Computerized Systems.

jee
OF pesued]
f.10 Testing

For product development, the supplier should test the product in accordance with approved test plans and test

THU
specifications.

The test specifications, when executed. should demonstraié that all requirements, functionality, and desian have

UO Tene)
been met

This may involve one or many siages of testing, depending on the nature of the product. For example, a simple
product may ony need one test specification while a complex product may have:

dE
* Module (Unit) Testing

HIS) EOF
* — Integration Testing

aesuao
" System Testing

Test records for each- stage should be reviewed and approved, and retained for a period defined in the QMS [nat to

AjuoeSn
be shorter than the supported fifetime of the current software version}.

Test failures should be managed in accordance wiih a forma! documented process.

of)
sae
See Appendix D5 for further details on Testing of Computenzed Systems.

Jo WoTSn pada
lf the supalier is involved in configuring @ product or developing a custom application, the number and level of test
specifications can vary considerably and should be agreed with the regulated company (see Section 6.2.9 of this
Guide).

9 Banpanien
11 Commercial Release

System release to customers should be performed in accordance with a formal process ihai describes criteria for
release, responsibilities, records to be retained, and items to be released, including software, hardware, and

pPaped
documentation. Release notes deiming fixes, changes, and new features. should accompany each release, including
minor releases and patches.

Aq DEIOLC
This activity is particularly applicable to commercially available products. For custom applications, the regulated
company would tyoically accept the sysiem following requiated company procedures.

Hote that camimercial release by a supplier is not a release into the GxP environment, which is & regulated company

iosiWoYy
activity (see Section 6.2.70 of this Guidei.

7.12 User Documentation and Training

‘SHUN

The supplier should provide adequate sysiem management documentation, operational documentation, and orovide
UW)

training for both maintenance and operation in accordance with agreed contracts.
 pepiea
Page 72 GAMP 5
A Risk-Based Approach to Compliant GxP Computerized Systems

oO] Desay [eeu

7.13 System Support and Maintenance During Operation

The supplier should support and maintain the system in accordance with agreed contracts. Formal procedures

ZUNE)
should be followed, typically covering areas.such as:

* aperational change control

pL uo FARE)
* eonfiguration management

* patch management

Seesifody 16) eOgeady

* jncident management

' document management

* backup and restore

* business continuity

Ajo en
*" managing sofware product releases

op)
* training of supplier staff

mo lidgonpordaequn
' -sysiem maintenance

Thess topics are covered by separaie sections and appendices in this Guide.

For specific systems, contracts may require that supplier documentation & subject to assessment during regulated
company penodic review activaties.

& Boponjed
F14 System Replacement and Retirement

‘peudd
The suppher should manage the replacement or withcrawal of products in.accordance with a documented process
and plans. Sufficient notice of retirement of a system or version should be given to reguiaied companies ta allow
them to. plan for ther own required activities.

Ad Rangrasig
The supplier also may suppor the requiated company with the retirement of computenzed systems.

boROgy
SUNS
“S|
 pommelde
GAMP 5 Page 73
4 Risk-Based Aporoach to Compliant GxP Computerized Systems

SMaANe) OL paSusoy en
Efficiency Improvements
This Guide provides a flexible framework for achieving compliant computerized systems that are fit for intended use.
The benefits wil be obtained only i7 the framework is applied effectively in the context of a particular organization.

Pop abort yr | lo Zane)

Aspects that can assist efficiency include:

* establishing verifiable and approoriate user requirements

* use of risk-based decisi Ons

* leveraging supplier input

SaesecH
1 feveraging existing documentation

' efficient testing practice

Ayuich Sth
* well managed handover

oy
' efficient change management

sry
* anticipating data archiving and migration needs

Jo uonon onde)
8.1 Establishing Verifiable and Objective User Requirements

Requirements should be analyzed to ensure that they are fully defined and are verifiable and objective. For example:

o Bumionled
Incomplete Requirement: Room shall be controlled at 20°C.

Complete Requirement: Room shall be controlled at 20°C + 2°C. Excursions of no oreater than 7"C are. permitted for

‘papuied
= 10 minutes.

The fével of detail is dependent on the novelty and complexity of the processes. and system being implemented.

Aq papinupe
Table 2.1 lists some aspects to consider when developing verifiable and objective requirements:

Table §.1: Considerations When Developing Requirements

Aspect Purpose uomuoy)

Process Knowledge In order to identify key requirements of the system that are related to the business or
SysS

manufacturing process

Business Knowledge To ensure that requirements are challenged against business need and benefits can
be realized
“Olly

Cwnershig To ensure clarity and understanding of the staied requirements

Analytical Te ensure that requirements are challenged to ensure they are complete and accurate

Technical/Product To ensure that requirements are practical in tenns of available techno‘ogy

Process/Product Impact To ensure requirements which impact the process or product are clearly identified

Technical Auinorship To ensure that requiremenis are written in concise, correct, and unambiquoaus lanquage
 papules
Page 74 GAMP:5
4 Risk-Based Approach to Compliant GaP Computerized Systems

pape
Of pesuacy
8.2 Use of Risk-Based Decisions

Risk management provides an opportunity to scale life cycle activities. However, the benefit is achieved only if

bo mae yNey meee:

organizations aré prepared to use risk assessments fo justify the omission or inclusion of an activity. Examples of
afeas where risk assessments may help with scaling include:

* number and depih of design reviews required

* need for,.and extent of, source code review

5) eodzad yk
' rigor of Supplier assessment

* depth and niger of testing

Similar opportunities exist during system operation, for example:

Sg eegueoR
* extent and level of specification and verification of changes

“AlUO oS
* rigor of backup and restore process

* level of business continuity required

Of
Jeu)
* frequency and level of disaster recovery

onjeuso uonoN poder

* degree to which identity checks are completed prior to providing access rights

* scope and frequency of periodic reviews

The benefits of nisk-based decision making can be maximized only if the conclusions and decisions can be
leveraged. Therefore, there should bé a practical, searchable means of access to conclusions and decisions
available to those involved in decision making, ¢.g., during subsequent assessments or reviews, dunng change

Bu
management, and on subsequent projects. Organizations may use a msk register to achieve this.

penued-s)
The risk-based approach should be focused and resourced for maximum effectiveness. Organizations should not
invest more effort and time into the risk management process than is commensurate with the potential impact on the
Supported business processes.

Aq pays]
6.3 Leveraging Supplier Input

FORO!
Supplier documentation, including test documents, may be used as part of verification documentation, provided the
requiated company has assessed the supplier and the documentation and determined both to be suitable, and the
supplier is prepared to make the documentation availatie This assessment may include & supplier audit, depending
on the risk, complexity, and.novelty of the system
SSS

The regulated company should assess the supplier for evidence of:
Ou)

*" an acceptable supolier quality system

* supplier technical capability

* supplier application of good practice such that information obtained from the supplier will be accurate and
suitable to meet the purpose of verification
 ppd
GAMP 5 Page 75
A Risk-Based Approach to Compliant (Sx? Computerized Systems

Bae
PoE RES Oy Petey
Supplier documentation should be assessed for content and quality Regulated company procedures and processes
should be flexible regarding acceptable format and structures so that supplier documentation may be leveraged.

If inadequacies are found in the supgiter quality system, technical capability, application of good practice, or
documentation, then the regulated company may choose to manage potential msks by applying specific, targeted,
additional verification checks or other controls, rather than repeating supplier activities and replicating supplier

yp ik Uo Penne;
documentation.

The decision and justification to use supplier documentation to support the verification of the computerized system
should be based on the intended use of the system, and should be documented and approved by SMEs which may
include the Quality Unit for aspects: critical to patent safety, product quality, and data integrity.

3 abies y 1o) Gea

Suppliers also may have tools or techniques unique to the specification and testing of their product or used in their
Quality control, which may be leveraged by the regulated company during specification and testing.

8.4 Leveraging Existing Documentation

Apo an
ln addition to the use of suppher documentation, regulated companies also should /everage their own documentation
from existing systems when introducing new, similar, systems. Examples include:

OF
" laboratory equigment

Udon pou dias SUA

* secondary manufacturing equipment

" packaging equipment

Relevant documents to reuse may include nsk assessments, user requirements specifications, various plans, test

i
specifications, and design reviews.

ch Be Barcaapeu
The new system should be assessed and any differences with the existing system identified and managed by the
intraduction of appropriate Specification and verification as required. 4 review of existing documentation should
determine which may be used. These conciusions should be documented.

RL
The néw system should be subject to installation and venfication. based on user requirements. The validation régart
should explain the rationale for reuse of documentation.

SEC]
ERIE
3.5 Efficient Testing Practice

ig
Testing is a major, time consuming exercise. It perhaps offers the greatest apportunity for efficiency savings.
ey

8.5.1 Reuse of Test Results

SPAS

Many systems have large amounts of test resulis available asa result of suppliers following a QMS independently of
a requiated company. On a project, there may be pre-delivery testing which may include Factory Acceptance Tesiing.
SSS]

Wherever possible, regulated companies should clearly communicate to suppliers the testing and document
requirements in-advance such that supplier test documentation is of the required standard io support compliance
activites.

Testing also may take place to meet other business or legal requirements, such as safety, health, environment, and
finance such as SO. lf so, unnecessary duplication of testing should be avoided. This is particularly true for large
business systems.
 peaks
Page 76 GAMP &
4 Risk-Based Aporoach ta Compliant GxP Computerized Systems

pee
Oo) Gedy
B52 Extent of Required Testing

The amount and tyoe of testing should be risk-based. Types of testing include:

yep Lh UO Zee RNE) Dens

* pormal case (positive)

* invalid case (negative)

* repeatability

+ performance

IO) GOOF
* wolumefioad

* fpegression

ApuO 890s. GeSeoH

* structural testing

See Appendix DS for furher details. The choice of controls to manage identified risks may result in some of these
types of testing being required.

Of)
While user requirements should be verified by the regulated company by performing installation and acceptance

SULT
tests, other required tests should be identified based on risk, complexity, and novelty. A.review of the existing tests
and results can then determine what, if any, further testing is required by the regulated company. The regulated

Jo oun peides
company’s procedures should ailow for the use of such existing test evidence subject to a documented and justified
review and approval by an SME, which may include the Quality Unit for aspects critical to patient safety, product
quality, and data integrity.

8.5.3 Hardcopy Tesr Evidence

s) Boerne
Reguiated companies should take a justified and documented decision, based on impact, novelty, and complexity, on
how much hardcopy test evidence is to be retained, as this can be a srgnificant overhead.

Ppeued
For example, regulated companies may use screen prints as hardcopy test evidence. The use of such hardcopy test
evidence should be focused on high impact functions. Test evidence may be retained electronically providing
adequate secunty and retention mechanisms are established.

Systems may have audit trails that capture much of ihe infomation thats taditonally captured by scréen prints. If

AG De
such an audit tail exists, is secure, and & available for review by the SME, then capturing additional evidence may
not be necessary.

Test evidence should be sufficient for objective review by the SME. URN

8.5.4 Use of Test Witnesses

SPSS

The usé of witnesses during testing may involve a significant overhead and should - be considered carefully.
ou)

Decisions to use witnesses should consider:

* knowledge and expenence of testers:

- ‘Trained testers with sufficient knowledge of the sysiem should be used. For example, nominated end users
who have been given appropriaie training m testing.
 peepee
GAMP 5 Page FF
4 Risk-Based Approach to Compliant GxP Computerized Systems

rey Ru
Oo) SUEY
* practical issues:

- systems, €.g., process conirol systenss, may require two people: one in a contro! room and one operating!

UO Tee ENS) TANS)

observing equipment on site

* feveland degree of review by an SME:

- use of independent witnesses may form part of the review process

" degree of automation of the tests and the resulting test evidence, ¢.9., audit trails

yh
See Appendix DS and the GAMP Good Practice Guide: Testing of GxP Systems (Reference 34, Appendix 3), for

BOOS
further details on testing of computerized sysiems.

IO)
eesuEdy
8.6 Well Managed Handover

System handover (from the project team to the Process Owner, System Owner, and operational users} should be

Apo aes
well-managed. li is a pre-requisite for the effective maintenance of system compliance during operation. Handover
should be planned in accordance with pre-aqreed criteria and should consider

ON
* support requirements for maintenance, as defined by IT or engineenng

SU
* outstanding problems or deficiencies

* how bong business processes can be stopped to enable handover

' ability and steps required to rollback to & previous operational state

ONO
3 Baoeu
* documentation, including format (e.g., electronic or paper), required at handover (e.g., specification anc
yenficaton documentation, user and maintenance manuals or quides)

* training needs (user and maintenance}

peed
* clear communication between groups, €.c., with application support and client service groups who may need to
provide help desk support

DELI
' the impact, 2.g., on the change contro! process to apply during the handover penod, where handover is to be
phased

A
UOMO)
* responsibilities during handover, 6.q., for acceptance of the system and for assessing the severity of outstanding
problems or deficiencies ou) SSS

8.7 Efficient Change Management

Efficient change management should be executed in parallel with configuration management. Key elements include:

* documented description.and business benefit of the change

* confirmation of availability of resoaurce

' gesessment of the impact of the change on the application, the underlying infrastructure, the people (users and
engineering support staff), and the documentation
 CapyBenid
Page 7a GAMP 5
A Risk-Based Approach to Compliant GeP Computerized Systems

oO) PesuScy
' |everaging ihe nsk assessment infonmaiion from the original project and assessing any new risks introduced by
the change to define the strategy for maintaining compliance — this includes the need for any regression testing

ONE)
' evaluation of the change from the financial, technical (IT or enaineering), and compliance perspectives at the
lowest technically competent level prior to management approval

(Io) GOOF yep b UO Fee Ne)

* documentation and communication of the decision

"execution and verification of the change, using traceability to Mentify existing applicable tests

' closing the change record in a timely manner

Weaknesses in change managemeni systems that may lead to inefficiencies include:

* lack of scalability, €.g., for minor changes. of for standard infrastructure components that change regularly

S.aeSiS0
' failure to execute change management steps in the aporopriate sequence

AUC WSN
* an inability to prevent unnecessary changes

' faluré to keep specifications current

Of
apn
' failure to leverage existing documentation relating to msk assessment and conol, traceability matrices, or
protocols

ponder
' lack of follow-up processes to close a change record

19 UFO
' (independent change processes leading to duplication of effon for processes, equipment, and computer systems

c: Guo
* the inappropriate application of like-for-like principles in change management (see Appendix O8 for funher
details)

' inadequate management of changes conducted by a suapier, acing to lite cycle documents and configuration

pepued
management records that are out of date

' lack of adequate follow-up after emergency changes (see Appendix O6 for further details)

csELSHy L Aq ieias
See Appendix O6 for further details.on change management. See also ITIL (Reference 36. Appendix G3) for further
details on change management within an IT service environment.

8.8 Anticipating Data Archiving and Migration Needs

Data archiving and migration requirements should be considered to ensure that data structures and formats are
Sys

efficient.
Sul

8.8.7 Different Retention Periods

It may be difficult to archive data wath different retention periods, which share the same data structures.

It may be difficult to destroy retained data that is no longer required, é.9., to reduce risk exposure to lost data and
retention costs, where data with diferent retention periods share the same data structures.
 peLybid
GAMP 45 Page T9
A Risk-Based Approach to Compliant GeP Qomputerized Systems

SE
hs oO] Pesan
Adata structure that separates data by retention period can addrese the requirements of archiving and data
destruction, but may involve a complex database design.

6.8.2 Data Formats

Pel
The migration of custom cata formats to a replacement system requires special attention and may cause difficulties.

“AlUS @Sn SaesUboy JO) aQge-a yp Lh uo ZONE)

The use of standard data formats should assist subsequent data extraction and migration.

4.8.3 Static and Dynamic Data

Data migration may be complicated where static and dynamic data is combined in a form which is difficult ta
separate.

See the GAMP Good Practices Guide: Electronic Data Archiving (Reference 34, Appendix G3) for further details on
data archiving and migration.

Op)
oF Bunpovien JO Uo_O Polder yA
‘paldd
Ag Bens
RO)
Sb) SUS
Hynighied iniaienial licensed to Guierrer Guierez on t4-Apr2009 for licensee's use only, No turiter reproduction of networking is permitted. Digitibuted by Thomson Scientific, Inc.
 payee
Page 84
4 Risk-Based Approach to Compliant GxP Computerized Systems Appendix Mi

Lan) eu
Validation Planning

Introduction

WD
This appendix covers the production of validation policies, Validation Master Plane (MPs) and individual
computerized system validation plans for sysiems or projects.

zud yep
Validation policies define management intent and commitment. MPs describe the areas of the company where
validation is required and provides an overview of validation planning. Computerized system validation plans
describe in. detail how the validation & to be performed for specific systems.

Moy BO
The terms validation policy, VYMP, and computerized system validation plan aré being used for consistency with other

a. eeGueon
sections of this and other GAMP documents, and because they are the most commonly used terms in the industry. It
is. recognized that some companies use alternative terminology.

“AlUO eS
Scope

Oh)
Jo\EN)
This guidance may be applied to all GxP regulated computenzed systems. The guidelines apply to both new-and
existing computerized systems, and sites and organizations in which these systems are used.

-s) Bumponjeuue nopopondss

Where 4 computer system is regarded as one component of a wider manufacturing process or system, particularly in
an integrated Quality by Design (Q@bD) environment, specific and separate computerized system validation may not
be necessary. This environment requires both complete product and process understanding and that the critical
process parameters can be accurately and reliably predicted and controlled over the design space. In-such a case,
the fitness for intended use of the computer system within the process may be adequately demonstrated by
documented @ngineering or project activities together with subsequent Process ‘Validation or continuoaus quality
verification of the overall process or system. The same principle applies to the adoption of Process Analytical
Technotogy (PAT).

peed
Where these pre-requisites are met, separate computerized system validation plans may not be required.

For automated manufacturing equipment, separate computer system validation should be avoided. Computer

tq peRaLASO
system specification and verification should be part of an integrated enginsenng approach io ensure complance and
fitness for intended use of the complete automated equipment.

UosmOYT
Validation Policies OQUeIS

Regulated companies should have corporate or site level policy documents that define their overall approach to
computerized system quality and compliance. Such documents should define, or make reference to, the following:
Su)

*' oles and responsibilities for activities and support

* high level expectations for deliverables

* standards, templates, and procedures that are expected to be followed throughout the organization

* definition of high evel processes, including the process to determine whether a system is GxP regulated
 popubpate
Page #2 GAMPS
Append M4 A Risk-Based Approach to Compliant GeP Computerized Systems

Qe
oy pesuESy
* fequirements for management of documentation

These policies should be readily available to all those wath responsibilities for yerficabon and validation activities,

FeeANe
and should be referred to by relevant planning documents.

Uo Zeneghe,
Validation Master Plans
4.1 General Guidelines

I) ENOe-My 4k
AVMP may be used to define the overview plan for a given time period, large project, or program of work: under
which there may be several individual validation plans.

Computerized system validation is often:a subset or chapter of a MP covering all of an organization's validation

ReaswEON
activities. A \VMP may be for the entire company, or there may be multigie YMPs for smaller business units.

The VMP should be a clear and concise summary document, typically covering:

AUO-n
* summary of facilities, systems, equipment of processes in scope

OR)
* current status of these facilities, systems, equipment, or processes

Ur
* change control process to be followed

no ioqopodeL
* planning and scheduling {including activities for new systems, activities driven by change, and periodic review)

The WMP requires approval by management, and is often subject to regulatory inepection.

a Gunponeu
The structure of MPs will depend on the way the regulated company is siructured and on company preference and
policy. Companies may have & management structure that is organized hierarchically and some choose successive
planning levels that reflect the way that the conpany itself is organized. Figure 41.1 gives an example planning
hierarchy.

peed
Figure M1.4: Planning Hierarchy

Aq BEIRpSEC)
Uses
SUES
“Si
 panied
GAMP 5 Page B3
4 Risk-Based Approach to Compliant GeP Computerized Systems Appendix M1

RL
Within @ site, there may be a singie MP for the site (MP Level 1) anc.a number of separate plans for the individual

ZeMeLNSS oy PEE
areas on that site (VMP Level 2). For the individual systems within 4 given area, a detailed plan would define the
validation activities for specific systems:

Companies may merge VMP Level 1 and Level 2 into a-single plan, or operate with a collection of Level 2 VMPs, and
not collate them into higher jeve! plans.

1S) BOZ-idiy-p | wo Zane)

42 Roles and Responsibilities

Responsibility for creating ‘MPs rests with senior management Regardless of who prepares a VMIP. senior
management sugporlis essential to ensure adequate resources for the required activites. Facility or area
management should approve VMPs-

The Quality Unit should approve the policies and procedures for validaton, including validation planning. The Quality

See sueod
Unit is responsible for verifying that the proposed approach complies with company quality standards and policies,
and meets regulatory requirements.

Aji Son
The meaning of each approval signature should be defined.

oF)
#3 Contents of the VMP

ary
The VMP should be 3 summary document which is brief, concise, and clear. It should cover:

pode:
* scope

ud udu
* eference to relevant policies

t: Bupponyee
* organizational structure

* summary of facilities, sysiems, equipment and processes

“peed
* documentation format: the format to b¢ used for protocols and reports

* planning and scheduling

Ad Beir
* change control

* reference to existing documents

nese)

Computerized System Validation Plans

SUNDS

5.1 General Guidelines

“Si,

A computerized system validation plan should be produced for each GxP regulated computerized sysiem, focusing
on aspects related to patent safety, product quality, and data integnty. It should summarize the entire project, ideniity
measures for success, and clearly define criteria for final acceptance and retease of the system.

The plan should define:

* what activities are required

 id
CER
Page #4 GAMP 5
Append Mi 4 Risk-Based Approach to Compliant GxP Computerized Systems

Ra
oO) Paseo
* how they will be performed and who is responsible

* what their outgut will be

Ree)
* what the requirements are for acceptance

RE
* how compliance will be maintained for the hifetime of the system

b UO FSi
The level of detail in the plan shoutd reflect the risk, complexity, and novelty of the system. For simote or low risk
systems a separate plan may not be needed: applicable aspects of planning may be covered within another
document.

15) AOOZ iy
A generic or commen plan may be used for similar systems (2.¢., ina laboratory), but should adequately reflect the
characteristics of specific systems. Where customization is peronmed or where supplier resources are to be
leveraged, requirements. should be communicated to the supplier at the start of ihe project so that the supplier may

AUG OSt) Soe SSO)

contribute ta thé content of the plan.

The plandefines how:compliance and finess for intended use ts to be achieved and how ihe process is to be
documented and reported. In some cases it may be convenient for a series of repors to be produced throughout the
project. The plan should take this requirement into account and indicate the different types of repart to be produced:
COVETING progress made, Ssues raised, and acceptance of different phases of ihe project:

PauLEd 4 Gupyonlau 1. coRonpondon MYA OY

Planning shoul commence as earny.as possible: ideally no later than during the development of the user
requirements specification (URS).

The plan may requiré modification during the project if there is a significant change in strategy or scope following
intel approval, in which case project change control should be applied and the plan updated accordingly.

The pian, along with the associated repor, may be one of the first documents offered during an audit to demonstrate
requiatery compliance. It shoubd, therefore, be written at a level suitable to be understood by a wide readershic.
Jargon and technical detail should be avoided.

See Appendix Mf for further details on computerized system validation réganing.

5.2 Roles and Responsibilities

ou) SHS ues) Kae MaAHC)

Responsibility for computenzed system validation planning ultimately rests with ihé Process Owner. This may be
delegated to a Project Manager and also may involve the System Owner.

Typically, the computerized system validation plan is approved by the Process Qwner and Quality Unit.

The meaning of each approval signature should be defined.

5.3 Contents of the Plan

Topics discussed in this section may be included: in the plan. The guitance proveded is intended to be neither
prescriptive nor exhaustive.

The evel of detail should reflect the risk, complexity, and novelty of the system. Separate sections may noi be
appropriate or necessary for all systems.
 peyby atc
GAMP 5 Page 65
A Risk-Based Aporoach te Compliant GxP Computerized Systems Appendix M1

OO ZeNenNe) PEeENe, 0) PeSeoy) (BL

5.31 Introduction and Scope

Information provided should include:

* the scope of the system

* the objectives of the validation process

' feview, mainienance, or update process for the plan iieelf

Mo) Goel yl
5.3.2 System Overview

A general description of the system in simple terms should be provided, including:

* business purpose and intended use for the system

Seasuaoy
* a description of the system ata high level

AjUuo en
* an overview of the system architecture

Diagrams are encouraged.

Of)
5.3.3 Organizational Structure

QU
IO UO RUC
Roles and responsibilities should be described, such as:

* project manager

- project management and planning

2 GUA
- control of project activities, resources, and costs

- Monitoring progress and initiating comectve action

Pete!
- €NSuring issues and proiect objectives are correctly addressed and resolved

| Ag pepe psicy
- Teporing to sponsor or senior management

- — liaising with the quality unit to ensure compliance

* quality unit
Oso
- assuring compliance with appropriate reguiaiory and quality requirements anc company policies
SUES

- providing support for the review and approval of deliverables

"Si

- @pproving the release of ihe system for use

* process owner and/or system owner

- implementaton and management of the system by the business. user community

- @pproving completion of stages/phases

 Doble
Page #6 GAMP'5
Appendix M1 4 Risk-Based Approach to Compliant GaP Computerized Systems

OF parses Uae
Subject Matter Experts (SMEs) are those individuals with specific expertise and responsibility In a particular area or
field (2.g., quality unit, engineering, automation, development, operations).

Bagh)
SMEs should take a lead role, as appropriate within their area of expertise and responsibility, in ensuring that
systems are compliant and fit for intended use.

JO) Booey Ll uo TENSES

SME resconsibiliies may include planning and defining venfication strategies, performing reviews, defining
accepiance critena, selecting appropriate test methods, executing venfication tests, and rewewing results.

The number of peraonnel required to approve specific documents should be kept to & minimum.

5.3.4 Quality Risk Management

The quality risk management aporoach to be applied should be desernbed.

Ajpud asr Sdesuedq

An initia! risk assessment should be performed based on an undersianding of business processes and business msk
ASSESsments, user requirements, regulatory requirements and known functional areas: Any relevant previous.
assessments may provide useful input; and these should not be repeated unnecessarily.

The resuits of this initial risk assessment should include a decision on whether the system is GxP regulated (1-e.,
GuP assessment). lt also should include an overall assessment of system impact.

op
ay
The tevel-of effort, formality, and documentation of subsequent risk management activities should be determined
based on level of risk and system impact. Siages at which msk assessment will be performed should be identified.

io ipede)
(See Section 5.3 of the Main Body and Appendix M3.)

Large enterprise systems, such as Enterprise Resource Planning (ERP) systems, may have some functionality
declared as xP retevant, while other funchonality is declared outside ihe scope of GxP. In-such cases the method
by which this decision is made should be Gescnbed and should consider:

a Rien
* the requirement for deciding tevels of GxP impact

* the procedures for performing the assessment

pane
"the current status of the process (recognizing that the assessment may be repeated and the impact assessment
undated)

“Sly Syquess usswey) Aq pore

Any specific quality risk management procedures or standards to be followed should be defined.

5.3.5 Validation Strategy

The strategy for achieving compliance and ensuring fiiness for purpose should be described: based on consideration
of:

' isk assessment

* assessment of system components and architecture

" supplier assessment

The key conclusions of any assessments perrormed should be included.

Any specific procedures or standards to be followed should be defined.

 ste
pay
GAMP5 Page 87
A Risk-Based Aporoach to Compliant GxP Computerized Systems Appendix Mi

Qe
Fauagney OF Paso
The validation straieqy should describe:

* the life cycle made!

' the application of hardware and software categones

INe
' the inputs and outputs required for each stage of the project

yep h OSU
' {he acceptance criteria for each siage

* approach to traceability

Jo) BOOZ
* approach to design review

See Appendix M4 for further details on categories of software and hardware, and Appendix M5 for further details on

6 aeseoR
design reviews and traceability.

5.3.6 Deliverables

A, UOCoSt)
The déliverabie items to be produced should be listed, including responsibility for production, review, and approval.

Op)
5a Acceptance Critena

Ly,
The overall acceptance criteria for ihe system (6.9., successful completion of defined project phases or stages)

UO RS NG
should be described. The approach to handling significant deviations should be defined.

5.3.8 Change Control!

fy Buy OO
The requirements for project change conirol should be defined, including reference to relevant procedures.

The stage at which operational change contro! will be applied should be defined.

53.9 Standard Operating Procedures

(paeued
The Standard Operating Procedures (SOPs) io be created or updated as a result of the implementation of the
system should be defined, and the plan should identify responsibility for their production, review, and approval,

Wao | AQ PS RUESE)
5.3.70 Supporting Processes

Details of relevant supporting processes should be defined or referenced, including, but not limited:to:

* training lincluding project team and user training} SUMS

' documentation management

* configuration management
“|

* maintaining compkance and fiiness for intended use

5a 1T Glossary

Definitions of any terms and abbreviations that may be unfamiliar to the readership of the document should be
included.
 nt ¢
pexpuibe
GAMES Page 89
4 Risk-Based Approach te Compliani GxP Computerized Systems. Appendix M2

ESR
CM
Supplier Assessment

rae |
1 Introduction
This appendix provides a risk-based approach to performing supplier assesemenis.. Regulated campanies should
consider formally assessing each supplier of GxP regulated computenzed systems and services. The assessment
approach should be based on thé criticality of the systemservice being provided. Dacumeniéd justification should be
-
provided for not assessing suppliers of GxP regulated systems/services. >
i;

Topics covered in this appendix include: 5at

" the reasons for carrying out supplier assessments ‘

8
z
* ithe different types of assesament é
§*
" {he assessment process =
2
* on-site and postal audits

opy
* joint and shared audits

Jin
poder
' corporate audits

" suppller préparation for an audit

USN
* supplier certification

oc) Buono
* intemational standards and certification

Note that in this appendix the term audit is used to cover both a formal visit to the supplier and a formal assessment

peed
USING & Questionnaire (known a8 a postal audit).

This appendix covers both assessments of prospective suppliers af computerized systems, and existing suppliers
who have not yet been assessed.

USO | AQ RIGILSH]
The material contained within this appendix also may be used by regulated companies io assess the competence of:

* extemal service providers (e.g., validation, project management, engineenng support, maintenance) who
support. one or more of the various. life cycle phases of computerized systems

* intemal funcions, such as IT and engineering

SUS

Open Source Software (OSS) is a developing area and requires special consideration (Reference 52, Appendix G3).
SU)

Example checklists and questionnaires for this appendix are-supplied: separately. They are intended for guidance
only and may be tallored to sunita particular type of supplier, as there may be other factors which require
consideraiion when assessing individual suppliers.
 OO] pare ay [reyEAL penuBiite
Page 90 GAMP 5
Appendix Mz 4 Risk-Based Approach to Compliant GaP Computerized Systems

2 Reasons for Supplier Assessment

SAL
Regquiated companies réquire a high level of confidence that computerized systems will meet ihe technical,
commercial, and regulatory requirements. They also wish to leverage the knowledge, experience, and
documentation of the supplier.

| Uo Se)
Financial and commercial audits of key suopliers have been a requiar oractice for some time, as have quality audits
for raw material suppiers and contract companies.

gp
Regulated companies should assess the quality and reliability of their computerized system suppliers and service
providers. Regulated companies require documented evidence that computerized sysiems will consistently perform

DOP Boe
as intended, and assurance of thé structural anc functional integrity of the software.

The computenzed system suapiier should build quality and integrity into a software product during development, as it

SOW
cannot be added effectively (e.g., through testing and re-work) later by the requilated company. The supplier is alsa

SSeS
better positioned to produce much of the required documented evidence during ihe development process. Suppliers
should, therefore, be assessed to determine the adequacy of their development and suppor orocesses, and the

Ayeiey stp
supplier assessment approach described in this appendix provides a scaleable approach to carrying out such an
assessment.

OF
For many systems ihere is likely to be more than one supplier and each of the suppliers within the supply cham

SULA
should be considered for assesament. In some cases a single supplier may provide a number of components or
perform a number of activities, in other cases multiple suppliers may be involved.

25 udion panded
Consideration should bé given to the scope of products and services to bé assessed. It is considered inefficient to
focus the process solely on one product required by a project when the regulated company is likely to use a wider
range of products or services fram the supplier. By adopting a broader approach, multiple assessments can be
avoided — this is often 4 particular issue for larger, giobal regulated companies where supplier assessment co-

Bueiorajad
ordination across ihe company can be difficult

Supplier assessments also are an opportunity te develop relationships with suppliers, to clanfy expectations and
intentions, and io identity misunderstandings and risks. The assessment process enables the regulated company to

Sed
establish a picture of the supplier's operation, which is vital input when planning specification and venfication

PAR
activities. The assesemeni report should, therefore, provide a balanced view of what was found, including positive

COPIES
observations, along with a list of concems.

3 __ Types of Assessment
On-site auditing may be expensive and time-consuming in tens of preparation, travel, the availability of personnel Ag
UCRay

and facilities during the await, and the time needed to write-up and review reports. The use of a nisk-based supplier
assessment approach that focuses on key suppliers can help io reduce these costs and is the basis of this appendix.
SUS

There are three main options for performing 4 supplier assessment:

“S|

1. basic assessment based on available information. (For components which are considered as commodities, e-g..
common desktop applications, a documented decision not to perform any assessment may be appropriate)

2. postal audit, using a questionnaire

3. on-site audit, by relevant specialist, auditor, or audit team