Guide For Computer Systems Validation PDF

7/16/2020 Guide for Computer Systems Validation
Page 1
Guide for Computer Systems Validation

Guide nº 33/2020 - version 1
https://translate.googleusercontent.com/translate_f 1/112
National Health Surveillance Agency - Anvisa
2020
Page 2

EFFECTIVE FROM 4/14/2020
Start of the contribution period: 4/14/2020

End of the contribution period: 08/12/2020
This Guide expresses Anvisa's understanding of best practices with respect to

procedures, routines and methods considered adequate to meet technical requirements
or administrative requirements required by the Agency's legislative and regulatory frameworks. 1
It is a non-normative regulatory instrument, of a recommendatory and non-binding nature,

therefore, it is possible to use alternative approaches to the propositions provided here, since
compatible with the requirements related to the specific case. Failure to comply with the content
of this document does not characterize a health violation, nor does it constitute a reason for refusing
petitions, provided the requirements of the legislation are met.
The recommendations contained in this Guide take effect from the date of its publication on the Portal
Anvisa are subject to receiving suggestions from society through a form
electronic, available at https://pesquisa.anvisa.gov.br/index.php/33174?lang=pt-BR.
Contributions 2 received will be evaluated and may support the revision of the Guide and the consequent
publication of a new version of the document. Regardless of the area's decision, it will be
published general analysis of contributions and rational that justifies the revision or not of the Guide.
1Ordinance No. 1,741, of December 12, 2018 , which provides for guidelines and procedures for quality improvement
regulatory agency at the National Health Surveillance Agency (Anvisa).
2 In order to ensure greater transparency in the process of preparing the regulatory instruments issued by Anvisa,
clarify that the names of those responsible for contributions (individuals and legal entities) are considered information
public and will be made available in an unrestricted manner in reports and other documents generated from the results of this
Guide. The participants' e-mail and CPF, which are considered confidential information, will have their access restricted to agents
legally authorized public bodies and the persons to whom such information refers, as recommended in article 31, paragraph 1,
I of Law No. 12,527, of November 18, 2011. Other information that may be considered confidential by the
participants may be joined in a specific field on the electronic form.
Copyright © 2018. National Health Surveillance Agency - Anvisa. The partial or total reproduction of this
document by any means is totally free, as long as the source is properly cited.
Reproduction for any commercial purpose is prohibited.
2
Guide nº 33/2020 - version 1, of 03/26/2020
Page 3
SUMMARY
1. SCOPE ................................................. .................................................. ........................................ 5
2. INTRODUCTION ................................................. .................................................. ............................... 5
3. LEGAL BASE ................................................ .................................................. ................................... 5
4. CONCEPTS, TERMS AND DEFINITIONS ............................................. .................................................. ... 5
4.1 KEY CONCEPTS .............................................. .................................................. ....................... 5
4.2 KEY TERMS .............................................. .................................................. ........................... 7
5. LIFE CYCLE APPROACH ............................................. .................................................. ....... 9
5.1 INTRODUCTION ................................................ .................................................. .................................. 9
5.2 LIFE CYCLE OF COMPUTERIZED SYSTEMS ........................................... .............................. 10
5.3 COMPUTERIZED SYSTEM VALIDATION STRUCTURE ........................................... .......... 11
6. QUALITY RISK MANAGEMENT ............................................. ....................................... 13
6.1 INTRODUCTION ................................................ .................................................. ................................ 13
6.2 QUALITY RISK MANAGEMENT WITH SCIENTIFIC BASIS ......................................... ........... 14
6.3 QUALITY RISK MANAGEMENT PROCESS .......................................... ...................... 14
7. SOFTWARE AND HARDWARE CATEGORIZATION ............................................. .................................. 17
7.1 INTRODUCTION ................................................ .................................................. ................................ 17
7.2 USE OF GAMP CATEGORIES ............................................ ............................................. 17
7.3 SOFTWARE CATEGORIES .............................................. .................................................. ............. 18
7.4 HARDWARE CATEGORIES .............................................. .................................................. ............ 21
8. INVENTORY LIST ............................................... .................................................. ................... 22
9. VALIDATION OF COMPUTERIZED SYSTEMS .............................................. ............................. 22
9.1 INTRODUCTION ................................................ .................................................. ................................ 22
9.2 VALIDATION PLAN .............................................. .................................................. ..................... 24
9.3 DOCUMENT CONTAINING USER REQUIREMENTS SPECIFICATIONS (ERU / URS) ................. 27
9.4 SELECTION OF COMPUTER SYSTEMS SUPPLIER ........................................... ............ 32
9.5 DOCUMENT CONTAINING FUNCTIONAL SPECIFICATIONS (EF / FS) ....................................... ........... 33
9.6 DOCUMENT CONTAINING THE CONFIGURATION AND THE PROJECT .......................................... .................... 36
9.7 TESTING PLAN FOR COMPUTERIZED SYSTEMS ........................................... ..................... 41
9.8 COMPLEMENTARY ACTIVITIES ............................................... .................................................. ..... 54
9.9 VALIDATION REPORT .............................................. .................................................. .............. 57
10. INVENTORY LIST ............................................. .................................................. ..................... 59
11. OPERATIONAL PHASE OF COMPUTERIZED SYSTEMS ........................................... .................... 60
11.1 INTRODUCTION ................................................ .................................................. .............................. 60
11.2 SYSTEM DELIVERY .............................................. .................................................. ................... 61
11.3 SUPPORT SERVICE MANAGEMENT ............................................ ....................................... 62
3
Page 4
11.4 MONITORING SYSTEM PERFORMANCE ............................................ ............................ 63
11.5 INCIDENT MANAGEMENT .............................................. .................................................. .. 66
11.6 CORRECTIVE AND PREVENTIVE ACTIONS (COVER) .......................................... ......................................... 67
11.7 MANAGEMENT OF CHANGES AND SYSTEM CONFIGURATION ......................................... 68
11.8 SYSTEM REPAIR ACTIVITIES ............................................ ................................................. 71
11.9 PERIODIC REVIEW ............................................... .................................................. ..................... 73
11.10 BACKUP AND RESTORATION .............................................. .................................................. ............. 75
11.11 BUSINESS CONTINUITY PLANNING / DISASTER RECOVERY ...................... 79
11.12 SYSTEM SECURITY MANAGEMENT ............................................ ............................... 81
11.13 SYSTEM ADMINISTRATION .............................................. .................................................. ..... 82
11.14 RECORD MANAGEMENT (RETENTION, ARCHIVING AND RECOVERY) ........................ 83
12 DATA MIGRATION .............................................. .................................................. .......................... 85
12.1 INTRODUCTION ................................................ .................................................. .............................. 85
12.2 QUALITY MANAGEMENT .............................................. .................................................. .. 86
12.3 IMPORTANT POINTS ............................................... .................................................. ................ 87
12.4 DATA MIGRATION PLAN ............................................ .................................................. ..... 89
12.5 DATA MIGRATION REPORT ............................................ ................................................ 90
13 RETIREMENT OF COMPUTERIZED SYSTEMS ............................................. ............................ 90
13.1 INTRODUCTION ................................................ .................................................. .............................. 90
13.2 SYSTEM RETIREMENT PLAN ............................................ .......................................... 91
13.3 SYSTEM RETIREMENT REPORT ............................................ .................................... 93
14. VALIDATION OF SHEETS ............................................. .................................................. ................. 94
14.1 INTRODUCTION ................................................ .................................................. .............................. 94
14.2 TYPES OF APPLICATIONS FOR END USER ........................................... ....................................... 94
14.3 RISK-BASED APPROACH ............................................ .................................................. .. 96
14.4 USE OF GAMP CATEGORIES ............................................ ........................................... 97
14.5 RISK-BASED CONTROLS ............................................ .................................................. .... 97
14.6 APPROACHES FOR VALIDATION .............................................. .................................................. .... 99
15 FINAL CONSIDERATIONS ............................................... .................................................. .................... 101
16 GLOSSARY AND ACRONYMS .............................................. .................................................. ................. 101
17 BIBLIOGRAPHICAL REFERENCES ............................................... .................................................. .......... 103
17.1 REGULATORY ................................................ .................................................. .......................... 103
17.2 TECHNIQUES ................................................ .................................................. ................................... 103
4
Page 5
1. SCOPE
The purpose of this guide is to propose guidelines to help obtain, by the regulated sector,
computer systems correctly installed and validated and that meet regulatory requirements.
This Guide is applicable to the computerized systems used in the areas, equipment and other
activities relevant to Good Manufacturing Practices for Inputs and Medicines. The proposal is to internalize
the document GAMP 5 in order to facilitate the reader's understanding of the guidelines proposed by
that international guide.
The scope of this Guide includes computerized systems categories 3, 4 and 5, the interfaces between
systems and spreadsheets.
The above mentioned systems are included, installed in stand-alone or network architecture ,
this network to be installed locally, nationally or globally.
This guide replaces the eponymous guide published by this Agency in April 2010.
2. INTRODUCTION
If the regulated company decides to use this Guide, it is recommended that its implementation be carried out
in its entirety (where applicable) and not partially, since all the activities described in this
document are necessary jointly for the achievement of an adequate sequence of acquisition,
validation, operationalization and finally retirement of the computerized system, especially for
more complex systems.
3. LEGAL BASE
• Resolution - RDC No. 69 of December 8, 2014 - which provides for Good Manufacturing Practices
of Active Pharmaceutical Inputs;

• Resolution - RDC nº 301, of August 21, 2019 - which provides for the General Good Guidelines
Drug Manufacturing Practices;
• Normative Instruction - IN nº 43, of August 21, 2019 - which provides for the Good Practices of
Manufacturing complementary to the computerized systems used in the manufacture of Medicines;
• Normative Instruction - IN nº 47, of August 21, 2019 - which provides for the Good Practices of
Manufacturing complementary to qualification and validation activities
4. CONCEPTS, TERMS AND DEFINITIONS
4.1 KEY CONCEPTS
4.1.1 Understanding the Process and the Product
The understanding of the process to be automated / computerized (eg: materials management;

document management; management of analytical records, etc.) is fundamental in defining the
5
Page 6
system requirements. Understanding the process and the product is the basis for making decisions based on
in science and risk to ensure that the system is suitable for its intended use.
Efforts to ensure suitability for the intended use should focus on those aspects that are
critical to patient safety, product quality and data integrity. These critical aspects
must be identified, specified and verified.
For some systems used in manufacturing, the process requirements depend on a complete
understanding of product characteristics. For these systems, the identification of Critical Attributes of
Quality Control (ACQ) and the associated Critical Process Parameters allow the control requirements of
processes are defined.
The requirements specification should focus on the critical aspects. The extent and details of the specification of the
requirement must be commensurate with the associated risk, complexity and innovation of the system.
Incomplete understanding of the process makes effective and efficient service of the system's benefit difficult
computerized to the business.
4.1.2 Life Cycle Approach within the Quality Management System (QMS)
It implies carrying out activities in a systematic way from conception to retirement of the system,
allowing for consistent management and approach for all systems.
As more knowledge of the system is acquired during use, the
Quality Management (QMS) should allow continuous improvement of the process and the system, based on
periodic reviews and evaluations of operational and performance data and analysis of the root causes of
failures occurred. Improvements identified and corrective actions taken should follow change management.
An appropriate life-cycle approach allows for quality assurance and suitability for the intended use
system, in addition to obtaining and maintaining compliance with regulatory requirements.
4.1.3 Scalable Life Cycle Activities
Life cycle activities should be staggered according to:
• The impact of the system on patient safety, product quality and data integrity
(risk assessment);
• The complexity of the system and its innovation (architecture and categorization of system components);
• The result of the supplier's assessment (capability);
• The impact of the system on business (can also motivate escalation).
The scheduling strategy must be clearly defined in a plan and follow policies and procedures
established and approved.
4.1.4 Science-Based Quality Risk Management
Quality risk management is a systematic process for assessing, controlling, communicating and
risk review. Its application allows efforts to be concentrated on the critical aspects of a system
computerized in a controlled and justified manner.
6
Page 7
Quality risk management should be based on a clear understanding of the process and the impact
potential for patient safety, product quality and data integrity. For systems that
control or monitor Critical Process Parameters, they must be traceable to Critical Attributes
of Quality and to the regulatory submissions of the manufacturing systems.
Quantitative and qualitative techniques can be used to identify and manage risks. Controls and measures
mitigation measures are developed to reduce risks to an acceptable level. The implemented controls must be
monitored during day-to-day operation to ensure continuous effectiveness.
4.1.5 Leveraging Supplier Involvement
Companies in the regulated sector should seek to maximize supplier engagement throughout the life cycle
of the system, if it has a satisfactory evaluation, with the purpose of using its knowledge,
experience and documentation.
The supplier can assist in determining user requirements, in risk assessments, in creating
functional and other specifications, system configuration, testing, support and
system maintenance.
Planning should determine how to use the vendor's documentation, including

tests, to avoid wasted effort and duplication. The justification for using this documentation
it should be based on your satisfactory assessment of the supplier, which may include conducting on- site audits .
This documentation must be assessed for suitability, accuracy and comprehensiveness and made available
during the life cycle of the system.
4.2 KEY TERMS
4.2.1 Service to BPx
Compliance with all pharmaceutical regulatory requirements and associated with life science.
4.2.2 process owner ( Process Owner )
The process owner is responsible for ensuring that the computerized system and its operation are
compliant and suitable for the intended use according to standard operating procedures (POP) by
its entire life cycle. It is the individual responsible for the business process or managed processes. It is
person may be the head of the unit or department using the system, but responsibility should be
based primarily on specific knowledge of the process rather than position in the organization.
Owner System 4.2.3 ( System Owner )
It is the individual responsible for the availability, support and maintenance of a computerized system, as well as
as the security of the data kept in this system. It is usually the head of the department responsible for
support and maintenance of the system, the role of which must be based on specific knowledge of the system
7
Page 8
rather than the position in the organization. The system owner is responsible for ensuring that the system has
support and maintenance in accordance with applicable procedures.
NOTE: Responsibility for controlling access to the system must be agreed between the process owner and the
system owner. In some situations the owner of the process may also be the owner of the system.
The ownership of the data kept in the system must be defined and normally belongs to the owner of the process.
4.2.4 Expert Opinion ( Subject Matter Expert )
It is the individual with deep knowledge in a specific area or field (chromatography, management
materials, manufacturing process, etc.). The specialist's responsibilities include planning and
definition of the verification strategy, definition of acceptance criteria, selection of the appropriate methods,
execution of the verification tests and review of the results obtained in the tests.
4.2.5 BPx Regulations
International pharmaceutical requirements, such as those established by ANVISA, FDA, Directives

European regulations, Japanese regulations and other applicable national laws or internal regulations of the
companies.
BPX regulations include, but are not limited to: GMP; BPC; BPL; BPD; Good Quality Practices; Good
Pharmacovigilance Practices and Medical Product Regulations.
4.2.6 Quality Management System
Management system to direct and control an organization with respect to quality.
4.2.7 Computerized System
A computerized system consists of: hardware , software and network components, together with
the controlled functions and associated documentation. Figure 1 shows a schematic representation of a
computerized system.
4.2.8 Computerized System Meeting BPx
Computerized systems subject to BPx regulations. The regulated company must ensure that such
systems meet the appropriate regulations.
4.2.9 Computer Systems Validation
Obtaining and maintaining compliance with the applicable BPx regulations and their suitability for the intended use
through the use of:
8
Page 9
• Adoption of life cycle principles, approaches and activities within the framework of plans and
validation reports;
• The application of appropriate operational controls throughout the system's life cycle.
Figure 1. Computerized system.

Source: PIC / S Good Practices for Computerized Systems in Regulated “GxP” Environments (PI 011).
5. LIFE CYCLE APPROACH
5.1 INTRODUCTION
Compliance with regulatory requirements and suitability for the intended use can be achieved by adopting
a life cycle approach following Best Practices.
A life cycle approach implies defining and carrying out activities in a systematic way from the
conception, understanding of requirements from development, release and operational use, to
system retirement.
This section of the guide presents: the life cycle of the computerized system, a general approach to
specification and verification and a structure for the validation of a computerized system.
An important part of implementing the lifecycle approach for computer systems is the
definition, by the regulated company, of the employees who will exercise the roles of Process Owner,
System Owner and Subject Specialist, for each of the systems installed in the company.
The understanding and qualification of the employees chosen from / in their respective functions are the stone
fundamental for all computerized systems to be properly chosen, validated,
operationalized and retired, meeting the relevant GMP and regulatory demands.
9
Page 10
5.2 LIFE CYCLE OF COMPUTERIZED SYSTEMS
The life cycle of a computerized system covers all activities from the initial concept to the
retirement.
The life cycle of any system consists of four phases:
• Concept
• Project
• Operation
• Retirement
An inventory of computerized systems must be maintained. An impact assessment on BPx should be

carried out at the beginning of the design phase to determine whether a system is regulated by BPX, and if so,
what specific regulations apply. This should be done as part of the initial risk assessment of the
system. For similar systems, it may be appropriate to base the BPx assessment on the results of an assessment
above, as long as the regulated company has a procedure established for such activity.
5.2.1 Concept
During the concept phase, the regulated company considers the opportunity to automate one or more
processes based on business needs and benefits. Usually at this stage the initial requirements
are developed and potential solutions are considered. Based on an initial understanding of the scope,
costs and benefits, a decision is made about the progress of the design phase. It is the stage in which
company makes the decision to change an activity performed manually by a system
computerized .
5.2.2 Project
The design phase involves planning, evaluating and selecting the supplier, the various levels of specification,
configuration (or coding for custom applications) and verification that leads to acceptance and release
for operation. Risk management is applied to identify risks and to remove or reduce them
at an acceptable level.
This phase covers the activities of defining the user's requirements, based on the decision taken in the
concept, followed by the evaluation and selection of the supplier to acquire the system, with consequent installation
and validation of the computerized system by the regulated company. In summary, in this stage the
computerized system acquisition and validation activities.
5.2.3 Operation
This is usually the longest phase and is managed through the use of defined operating procedures and
updated by people who have been properly trained, educated and experienced. This phase is equivalent to
practical use of the computerized system validated by the regulated company . The maintenance
control (including safety), adequacy of intended use and compliance with BPx are aspects-
key. Managing changes of different impacts, scope and complexity is an activity
important during this phase.
10
Page 11
5.2.3 Retirement
It is the final stage of the life cycle of the computerized system. As the name says: the system is retired.
It involves decisions about data retention, migration or destruction and the management of these processes.
Suppliers of products and services should be involved, where appropriate, throughout the life cycle.
It may be appropriate to delegate many of the activities described to suppliers, if their assessment is
satisfactory and control measures are in place. The life cycle phases are shown in figure 2.
Figure 2. The Life Cycle Stages.

Source: GAMP5
5.3 COMPUTERIZED SYSTEM VALIDATION STRUCTURE
5.3.1 Introduction
There must be a structure for the validation of computerized systems that ensures obtaining and
maintenance of service to BPX throughout the life cycle of the computerized system.
This structure is based on specific plans and reports per system and the application of operational controls
appropriate. Validation plans and reports provide a consistent and disciplined approach to
compliance with regulatory requirements. Such documents are valuable for preparation for / and during
regulatory inspections.
The regulated company's Quality Risk Management System has the role of effectively and
efficiently cover the wide variety of existing systems.
If the computerized system is part of a larger manufacturing process or system, mainly

in an integrated Quality by Project (QbD) environment, the validation of the system carried out in a
specific and separate may not be necessary. This environment requires a complete understanding of both
process and the product and that the critical process parameters can be accurately and accurately
reliability, planned and controlled within the project space. In this case, the adequacy of the system
computerized to the intended use within the process, can be adequately demonstrated by the
11
Page 12
engineering documentation or project activities along with subsequent process validation

or continuous verification of the quality of the process or system in general. The same principles apply to adoption
of Process Analytical Technology (PAT).
5.3.2 Terminology
The specific terminology used to describe life cycle activities varies from company to company.
system type to another. There are several reasons for this:
• Regulated companies use different approaches;

• There is a difference in emphasis on BLP, BPC, GMP and medical devices;
• There are differences in the requirements of the various regulatory agencies;
• Different standards, local and international, are followed;
• There are different types of computerized systems (IT, manufacturing, laboratories);
• Suppliers use different models and development approaches.
This Guide, in harmony with the document GAMP 5, is intended to be flexible and is not intended to prescribe
a single set of terms, excluding others.
Table 1 shows the relationship between the traditional terminology for Qualification and the activities
described in this Guide.
The terms used to describe the systems verification stage are the ones that have the greatest
diversity. This section describes how the terminology traditionally used for qualification relates to
with the activities described in this Guide.
Whatever the terminology used by the company, the requirement that overlaps everything is that the
regulated company can demonstrate that the system is compliant and suitable for its intended use.
The use of qualification terminology in relation to computerized systems and the relationship between QO and
QD particularly, varies from company to company.
It is up to companies to decide on the verification strategy they will use.
12
Page 13
Table 1. Relationship between the traditional terminology for qualification and the activities described in this
Guide.
Verification Activity -
Traditional term description
Guide
Documented verification of
that the proposed project for
Project Qualification
installations, systems and Project Review
(QP / DQ)
equipment is suitable
for the intended purpose
Verification, testing or other
verification to demonstrate
that the activities of
that the system has been installed
Installation Qualification installation and configuration of
according
(IQ / IQ) hardware and software
written specifications is pre-
were realized
approved.
correctly
Conducting tests or
another system check
against specifications for
that the system operates
demonstrate correct
Operational Qualification according to specifications
functionality operation
(QO / OQ) writing is pre-approved and
that supports the process
across the operational range
specific business across
specified.
to written specifications is
pre-approved
that the system is capable of Conducting tests or
perform activities another system check
processes as to demonstrate suitability
Performance Qualification
expected, according to intended use and for
(QD / PQ)
written specifications is pre- allow acceptance of the
approved, within the scope system from
of the business process and specified requirements
operating environment.
6. QUALITY RISK MANAGEMENT
6.1 INTRODUCTION
Quality risk management consists of a systematic process for assessing, controlling,

communication and risk review. It is an iterative process used throughout the life cycle of the system
from conception to retirement. Figure 3 presents this concept graphically.
13
Page 14
Figure 3. A Risk-Based Approach for Computer Systems Compatible with BPx.

Source: GAMP5
6.2 QUALITY RISK MANAGEMENT WITH SCIENTIFIC BASIS
Determining the risks inherent in a computerized system requires an understanding of the following
points:
• The impact of the computerized system on patient safety, product quality and
data integrity;
• The business processes supported by the system;
• Critical Quality Attributes (CQA) for systems that monitor or control Parameters
Process Critics (CPPs);
• User requirements;
• Regulatory requirements;
• The project approach (contracts, methods, schedules);
• System components and architecture;
• System functions;
• Supplier capability.
The company must also consider other applicable risks such as safety, health and the environment.
6.3 QUALITY RISK MANAGEMENT PROCESS
There is an international guide available (ICH Q9) that deals with quality risk management within the
pharmaceutical industry.
It defines the two primary principles of quality risk management, namely:

14
Page 15
• Quality risk assessment should be based on scientific knowledge and linked to the
patient protection;
• The level of effort, formality and documentation of the quality risk management process
it must be commensurate with the level of risk.
In the context of computerized systems, scientific knowledge is based on the specifications of the
system and the business process that the system supports.
The quality risk management process involves the execution of 05 (five) steps:
1. Performing the initial risk assessment and determining the impact of the system;
2. Identification of functions that have an impact on patient safety, product quality and
data integrity;
3. Performing functional risk assessments and identifying the necessary controls;
4. Implementation and verification of appropriate controls;
5. Review of risks and monitoring of implemented controls.
These steps are detailed below.
6.3.1 Step 1 - Initial Risk Assessment
An initial risk analysis should be carried out based on an understanding of the processes and risk assessments
business requirements, user requirements, regulatory requirements and known functional areas.
The results of this initial risk assessment should include the decision on whether the system is regulated by BPx
(BPx evaluation). A general assessment of the system's impact should also be included.
Based on this initial risk assessment and system impact it may not be necessary to perform the steps
subsequent risks if the risk is already at an acceptable level.
The necessary effort, formalization and documentation of the subsequent steps must be determined with
based on the level of risk and the impact of the system on BPx.
6.3.2 Step 2 - Identification of Functions
Functions that impact patient safety, product quality and data integrity
should be identified by the construction of the information gathered in step 1, referring to the specifications
relevant and taking into account the project approach, the system architecture and the categorization of
system components.
6.3.3 Step 3 - Functional Risk Assessment
The functions identified in step 2 must be evaluated considering the possible dangers and how the
potential damage from these hazards can be controlled.
It may be necessary to perform a more detailed assessment that subsequently analyzes the severity of the damage,
the probability of occurrence and the probability of detection.
15
Page 16
The judgment, on whether or not to carry out a detailed assessment of specific functions, must be carried out
case by case and the criteria may vary. The criteria to be taken into account are:
• The criticality of the supported processes;

• The specific impact of functions within the process;
• The nature of the system (complexity and innovation).
Appropriate controls should be identified based on the assessment carried out. There are a range of options
available to carry out the required control depending on the identified risk. Controls include, among
others:
• Modification of the process design;

• Modification of the system design;
• Application of external procedures;
• Increased details or formality of specifications;
• Increasing the number and level of details of design reviews;
• Increasing the extent or rigor of verification activities.
Where possible, it is preferable that risk elimination is carried out at the project level.
6.3.4 Implementation and Verification of Controls
The control measures identified in step 3 should be implemented and verified to ensure that they
have been successfully deployed. Controls must be traceable to the relevant risks identified.
The verification activity must demonstrate that the controls are effective in implementing the risk reduction
required.
6.3.5 Risk Review and Monitoring of Controls
During the periodic system review, or at other defined opportunities, the company must
review the risks. The check must show whether the controls are still effective and corrective actions must be taken.
carried out if deficiencies are found.
The company should also consider the following points:
• If previously unidentified hazards are present;

• If the previously identified hazards are no longer applicable;
• Whether the estimated risk associated with a hazard is no longer acceptable;
• If the original assessment is currently invalidated (eg after changes to applicable regulations or
changes in system usage).
When necessary, the results of the assessment should feed back into the risk management process.
If there is a potential that the residual risk or its acceptability has changed, the impact on the measures
risk control measures previously implemented have to be considered and the result of this assessment
properly documented.
The frequency and extent of any periodic review should be based on the associated level of risk.
16
Page 17
7. SOFTWARE AND HARDWARE CATEGORIZATION
7.1 INTRODUCTION
This section describes how the software and hardware components can be analyzed and categorized. These
software and hardware categories can then be used in conjunction with the Risk Assessment and Assessment
Supplier to establish an appropriate life cycle strategy.
Categories 3 to 5 have no absolute boundaries and that the activities recommended for a given
category may be suitable for a system or component that belongs to the other category.
7.2 USE OF GAMP CATEGORIES
There is usually an increased risk of failure and defects when progressing a set
software-hardware standard for a set software - hardware customized. The increased risk comes from
combination of greater complexity and less user experience. Categorization can be part of
an effective approach to quality risk management when coupled with risk assessment and
supplier evaluation.
Most systems have components of varying complexity, such as an operating system,

non-configured components, and configured or customized components. The effort must be concentrated
in the following proportion: Customized> Configured> Not Configured> Infrastructure. Categorization can
help focus the effort where the risk is greatest.
There are two main ways of using categories:
• Evaluation of the system in a holistic way;

• Detailed evaluation by component.
In the holistic assessment, the main component category can be used to help define the approach
for supplier evaluation or selection of results to be delivered in the life cycle. The combination of
categorization with the impact assessment of the system can help you decide whether a supplier audit is
needed.
In individualized assessment, categorization is useful when applied in conjunction with other

risk management and considering the complexity and size of the system. Most systems
computerized is made up of multiple components and the categorization of such components can be
used to define specific life cycle activities.
For example, a chromatographic management system (CDS) that has a software control and
data installed on the computer and running on an operating system and a database and more subsystems
with installed firmware , such as pump controllers, auto injectors and column ovens. In this context,
these latter components are much less complex than the data and control software , so
It is reasonable that more effort is spent on the application installed on the computer than on the subsystems.
A Programmable Logic Controller (PLC) or other controller can be an integrated part of equipment
process and verification of correct operation is part of the overall check of the integrated equipment. In
In such cases, detailed analysis of the categories of the individual components may not be necessary.
17
Page 18
7.3 SOFTWARE CATEGORIES
7.3.1 Category 1 - Infrastructure Software
Infrastructure elements interconnect to form an integrated environment to run and support

applications and services.
There are two types of software in this category:
1. Software Layer ( Layered Software ) Commercially Available or Settled - Applications

are developed to run under the control of this type of software . This type of software includes:
operating systems, database managers, statistical programming tools, and spreadsheet packages
(but not applications developed using these packages).
2. Tools Software Infrastructure - This type includes tools such as software to
network monitoring; batch job scheduling tools; security software ; antivirus and
configuration management tools. Risk assessment must be carried out, however, in the tools
with high potential impact, such as password or security management to determine if
additional controls are appropriate.
The software layer are not subject to specific functional verification, although their
characteristics are functionally tested and challenged indirectly during
testing in the application. The identities and the version numbers of the software of
layer and operating system should be documented and verified during
installation.
Infrastructure tools and software are generally highly reliable and

significantly removed from any aspect of risk to the patient. All software
infrastructure should be controlled and managed.
7.3.2 Category 3 - Non-Configured Products
This category includes off-the-shelf products used for the business process. It covers both systems
that cannot be configured to suit business processes as well as the systems that are
configurable, but that only the default configuration is used. In both cases, the setting for
run in the likely user environment (eg, printer setting). Risk-based judgment and
complexity should determine whether systems used with the default configuration can be considered
Category 3 or 4.
A simplified approach to the life cycle can be applied to this category. Supplier evaluation
may not be necessary. The need and extent of the supplier's assessment should be based on risk.
User requirements are necessary and should focus on the key aspects of use. The specifications
functional and design are not necessary, although there is a need for sufficient specification
(usually in the ERU / URS) to allow testing. The verification basically consists of a
single testing phase.
All changes must be controlled, including the patch packages provided by the supplier.
Standard Operating Procedures must be established for the use and management of the system and
training should be implemented.
Configuration management must be applied. For systems where the default configuration is used, the
Configuration management demonstrates that the “ default ” option is selected correctly.
18
Page 19
7.3.3 Category 4 - Configured Products
Configurable software provides standard interfaces and functions that allow the configuration of
specific business for the user. This usually involves configuring software modules
predefined.
Much of the risk associated with the software depends on how well the system is configured to meet
user needs. There may be an increased risk associated with new software and major updates.
Detailed user requirements document (ERU / URS) is required for this software category . THE
The approach for evaluating the supplier and the configurable product must be risk-based and must be
documented.
The Functional Specification document may not be owned by the regulated user / company, but must
sufficient documentation to ensure traceability of functional specifications and their respective
tests.
The approach used by the regulated company must cover the layers of software involved and their
respective categories. The approach should reflect the result of the supplier's assessment, the risk to GMP,
system size and complexity. It should define strategies to mitigate any weaknesses
identified during the supplier assessment process.
7.3.4 Category 5 - Custom Applications

These systems and subsystems are developed to meet the specific needs of the regulated company.
The risk inherent in customized software is high. The life-cycle approach and system decisions
should take this high risk into account, because there is no user experience or information about
system reliability.
The approach used to assess the supplier must be risk-based and documented. An audit
at the supplier is required to confirm that an adequate Quality Management System exists for
control development and ongoing support for the application. In the absence of a Management System
Quality Assurance, suppliers must adapt to provide an appropriate basis for
managing application development and support.
The approach used by the regulated company must cover the layers of software involved and their
respective categories. The approach should reflect the result of the supplier's assessment, the risk to GMP,
system size and complexity. It should define strategies to mitigate any weaknesses
identified during the supplier evaluation process.
19
Page 20
7.3.5 Typical Examples and Approaches
Table 2. Categories of Software , Description and Typical Approach to the Life Cycle.
Category description Typical Examples Typical Approach

software of • software of • Operational systems • Registration of the
Infrastructure (1) Layer (that is, over • Mechanisms for version and verification of correct
which applications are databases installation
built) • Middleware • See GAMP Good Practice
• Software • Languages Guide: IT Infraestructure Control and
used for programming Compliance
manage the environment • Statistical packages
operational • Spreadsheets
• Tools
network monitoring
• Tools
scheduling
• Tools
version control
Non- Software Time parameters • Based Applications • Shortened life cycle
Configured (3) of execution can in firmware • Approach to evaluation
be inserted and • Type software supplier based on risk
stored but the COTS • Registration of the
software cannot be • Instruments of version and verification of correct
configured to Laboratory (See GAMP Good installation
suit processes Practice Guide: Validation of • Risk-based testing
business Laboratory Computerized against the requirements, based on
Systems ) their use (for systems
simple calibration can be the
test substitute)
• Existence of
maintenance procedures
care and suitability for use
Table 2: Software Categories , Description and Typical Life Cycle Approach (continued).
Category description Typical Examples Typical Approach

Configured Software (4) Software , usually more • LIMS • Cycle approach
complex, which can be • Systems of life
configured by the user data acquisition • Approach to
to meet your • SCADA supplier assessment with
specific needs. THE • ERU risk based
software code is not • MRPII • Demonstration of
changed. • DCS that the supplier has a
• CDS Management System
• EDMS Quality
• • Some
BMS
• Spreadsheets cycle documentation
• HMI ( Human life maintained by the supplier
Simple Machine Interfaces ) (ex .: Specifications of
Project)
NOTE : Specific examples
• Number registration
of system types above
can contain elements version and verification
substantial custom features. correct installation
20
Page 21
• Testing
based on risk for
demonstrate that the application
works as designed,
in a test environment
• Testing
based on risk for
demonstrate that the application
works as designed,
in an environment of
production
• Existence of
procedures for
maintenance of care
and suitability for use and
data management
Custom software (5) software customized It varies, but includes: Same approach used
designed and coded for • IT Applications for Category 4, plus:
attend a process of developed internally • An assessment of
business. and externally stricter supplier,
• Applications for with possible audit of this
process control • Possession of
developed internally documentation of the entire cycle
and externally system life
• Ladder logic (Functional Specifications,
custom Project Specifications,
• Firmware structural tests, etc.)
custom • Project Review and
• Spreadsheets (macro) of the Source Code
7.4 HARDWARE CATEGORIES
7.4.1 Hardware Category 1 - Standard Hardware Components
Most of the hardware used by regulated companies falls into this category.
Standard hardware components must be documented including details about the supplier or
manufacturer and version number. The correct installation and connections of the components must be checked. THE
model, version number and if available and the serial number of the pre-assembled hardware must be
registered. Pre-assembled hardware does not have to be disassembled. In such cases the details of the hardware
can be purchased from the hardware data sheet or other material specification.
Configuration management and change control are applicable.
7.4.2 Hardware Category 2 - Custom Built-in Hardware Components
In addition to the requirements described in the item above, those described in this item are applicable. Custom items from
hardware must have a Project Specification (EP / DS) and be subject to acceptance testing. THE
approach to supplier assessment should be risk-based and documented. In most cases a
Supplier audit must be performed for the development of customized hardware. Systems
assembled using custom hardware from different sources requires verification to confirm the
compatibility of interconnected hardware components . Any hardware configuration must be
21
Page 22
defined in the design documentation and verified. Configuration management and change control are
applicable.
8. INVENTORY LIST
Regulated companies must maintain an inventory of their computerized systems.
The inventory must present summary information about each system, describing: name of the system;
associated equipment or application; impact / criticality; category; ownership (sector, system owner,
process owner); current version; provider; validation date and status.
Automated equipment can be listed separately and duplication must be avoided.
The inventory must cover the level of the systems that support the business processes and not items
individual hardware (components) that must be covered by local industry procedures
information technology.
This inventory can be used for planning periodic reviews.
9. VALIDATION OF COMPUTERIZED SYSTEMS
9.1 INTRODUCTION
A strategy will be presented to carry out the computerized system validation, from the definition
user requirements, system selection, execution and approval of the validation report.
This strategy is applicable to systems belonging to categories 3, 4 and 5, which are the vast majority of systems
computerized systems in the pharmaceutical and pharmaceutical industries.
This section will also describe the auxiliary risk management, change and
configuration, project review, traceability and documentation management.
Terminologies that are commonly used by the pharmaceutical and chemical industries will be used in this guide.
pharmaceutical companies, namely: Validation Policies, Master Validation Plan and Validation Plan.
The regulated company must include the validation of computerized systems in its validation policy and / or
Master Validation Plan. These documents should express the overall corporate or plant approach to
company for the activity of validation of computerized systems and for maintaining their situation of
validated.
It is recommended that a Validation Plan be prepared for each computer system that has
relevance in GMP, focusing on aspects related to patient quality, product quality and
data integrity.
For automated manufacturing equipment, the validation of the separate computerized system must
be avoided. The specification and verification of the computerized system should be part of an approach
integrated engineering to ensure compliance and suitability for the intended use of the equipment
automated within a whole.
22
Page 23
Figure 4 shows the steps involved in validating the systems that form part of the system's life cycle
computerized, from the definition of user requirements, through the acquisition and validation of the system
computerized and execution of the pertinent auxiliary processes.
These steps are also applicable to the design phase and the subsequent changes that occurred during the phase
operating system.
Figure 4. Flow of the Systems Validation Process (Categories 3, 4 and 5).
23
Page 24
9.2 VALIDATION PLAN
9.2.1 Introduction
It is in the validation plan where the project is described, the actions to be carried out for an
successful validation and acceptance criteria for clearing the system are clearly defined.
You must define:
• What activities are needed;

• How the activities will be carried out and who are responsible;
• What are the expected results;
• What are the acceptance criteria;
• How the compliance situation will be maintained throughout the life of the system.
Planning should start as soon as possible, ideally during document development

describing the specifications of user requirements (ERU / URS).
A similar or generic plan can be generated for similar systems, but one that adequately reflects the
characteristics of each system.
Regarding the roles and responsibilities, the validation plan is the responsibility of the Process Owner.
It may be delegated to the Project Manager, if applicable, and the Project Owner may also be involved
System.
9.2.2 Content of the Plan
9.2.2.1 Introduction and Scope
It should contain:
• The scope of the system;

• The objectives of the validation process;
• Review, maintenance or update of the plan itself.
9.2.2.2 System Overview
The general description of the system should contain:
• Business purpose and intended use for the system;

• A high-level description of the system;
• An overview of the system architecture;
• System diagrams.
9.2.2.3 Organizational Structure
Roles and responsibilities should be described, such as:
24
Page 25
• Project manager;
✓ Project planning and management;
✓ Control of project activities, resources and costs;
✓ Monitoring the progress of the work and initiation of CAPA;
✓ Ensure that the problems and objectives of the project are resolved and met;
✓ Manage quality deviations involving the system:
✓ Respond to the sponsor or top management;
✓ Ensure system compliance in conjunction with the Quality Unit.
• Quality Unit;
✓ Ensuring system compliance with regulatory, quality and policy requirements
company;
✓ Provide support for the review and approval of the results generated by the validation work;
✓ Evaluation and approval of closing quality deviations;
✓ Approval of the system release for use.
• Process Owner and / or System Owner
✓ System deployment and management by the community of system users;
✓ Approval of each stage of the validation process.
Subject matter experts (SME) are those individuals with specific expertise and responsibility in a
particular area or field, for example, chromatographic analysis, quality unit, engineering,
automation, development, etc.
The responsibilities of these experts may include: planning and defining verification strategies
of the system; performing reviews; definition of acceptance criteria; selection of method tests
appropriate; execution of verification tests and review of the results.
9.2.2.4 Quality Risk Management
The approach used to manage quality risk should be described.
A risk assessment must be performed based on an understanding of the business processes, requirements of the
regulatory requirements and known functional areas. The results obtained must include a decision
on whether the system is relevant to GMP and a general assessment of the impact of the system.
Complex systems, such as ERP-type systems, may have some features that are
relevant to GMP and others that are not. In such cases, the method used to make such a decision should be
described and should consider the following points:
• The requirements for deciding on the impact levels on BPx;

• The procedures for carrying out the assessment;
• The current status of the process, recognizing that this assessment can be repeated and updated.
Any specific procedures or standards used to perform quality risk management

must be defined.
9.2.2.5 Validation Strategy
The strategy to be used for system validation should be described, based on the following considerations:
25
Page 26
• Risk assessment;
• Evaluation of the system components and their architecture;
• Supplier assessment.
The key conclusions of any evaluation carried out must be formalized.
Any specific procedures or standards used must be defined.
The validation strategy should include:
• The life cycle model;

• The system's hardware and software categories ;
• The requirements and results required for each stage of the project;
• The acceptance criteria for each stage;
• Approach used to ensure the traceability of data and documents;
• Approach used to review the project.
9.2.2.6 Expected Results
The results to be produced should be listed, including the responsibility for production (of
documents, tests, results), review and approval.
9.2.2.7 Acceptance Criteria
The general acceptance criteria for the system, such as the successful execution of a defined stage of the
project, should be described.
9.2.2.8 Change Control
The requirements for project change control should be defined, including reference to the
relevant procedures.
The stage at which operational change control will be applied must be defined.
9.2.2.9 Standard Operating Procedures
Standard operating procedures (SOPs) that will be created or updated as a result of the deployment
of the system must be defined and the responsibilities for its elaboration, revision and approval defined.
9.2.2.10 Auxiliary Processes
Details of ancillary processes should be defined or referenced, including, but not limited to:
• Training;
• Documentation management;
26
Page 27
• Configuration management;
• Maintaining your validated status.
9.2.2.11 Glossary
Definitions of any terms and abbreviations that may be little known should be included.
9.3 DOCUMENT CONTAINING USER REQUIREMENTS SPECIFICATIONS (ERU / URS)
9.3.1 Introduction
The User Requirements Specifications (ERU / URS) document defines the requirements for a system
computerized system component.
The length and detail of this document must be commensurate with risk, innovation and
system complexity and must be sufficient to support subsequent risk analysis activities,
specification, configuration / design and verification, if necessary.
For a low risk and commercially available system, it may be appropriate to include this document in the
purchase documentation of the system, while for a complex and customized application can be
Several levels of specification are required.
The ERU / URS document is the responsibility of the regulated company, but it can be written by a company
outsourced or by the system supplier.
The User Requirements Specifications (ERU / URS) document clearly and precisely defines what the
regulated company wants the system to do. It is driven by the needs of the business process.
For category 4 and 5 systems the requirements must be developed independently from the
solutions available on the market.
For category 3 systems, in particular, there may be a limited number of suppliers or even a
preferred supplier for a particular type of system, which justifies the use of solutions available in the
market.
The requirements must cover the following points, and may include others that are not listed:
• Operational;
• Functional;
• Dice;
• Technical;
• Interface ;
• Environmental;
• Performance;
• Availability;
•
• Safety;
Maintenance;
• Regulatory;
• Migration of any electronic data;
27
Page 28
• Restrictions to be observed;
• Life cycle.
The requirements should address applicable BPx regulations and highlight aspects that are critical to the
patient safety, product quality and data integrity. The ERU document must not include
requirements such as "meets 21CFR Part 11" or "meets Anvisa legislation" and to define what functionality
the system must have to manage the risk to patient safety, product quality and integrity
of the data.
The requirements must have the following characteristics:
• Sufficient and adequate (Specific; Measurable, Attainable; Realistic; Testable);

• Specific enough to carry out tests and verifications (Unequivocal; Clear; Precise;
Complete);
• Able to assist traceability along the requirement chain → configuration / design → test;
• Provide the basis for formal testing and be used for supplier selection;
• Prioritized with an emphasis on identifying mandatory requirements. The approach can be used
three levels of priority, described below:
✓ Mandatory (high);
✓ Beneficial (average);
✓ Good to have (low).
• Uniquely identified, with controlled version and maintenance of its control; Able to be
used as a means of communication and management of critical requirements throughout the life cycle of the
system rather than just an exercise;
• Provide the system supplier with the definitive statement of mandatory and desirable requirements.
The ownership of the requirements belongs to the regulated company. The operational needs of the business and
any associated problems can never be fully understood and captured without the effective
participation of system users. Documented requirements form the basis for system acceptance
by users.
9.3.2 Content of the ERU / URS Document
9.3.2.1 Introduction
The introduction item should provide information on:
• Who produced the document, under what authority and for what purpose;
• The contractual status of the document (if applicable), such as custom development
or outsourced;
•
Relationship or dependence with other documents.
9.3.2.2 Overview
An overview of the system should be provided, explaining why the system is needed and what is required
of the system. The following points should be considered:
• Contextualization: describes the general objective of the system in the current context and the desired situation;
28
Page 29
• Scope:
✓ The insertion of the system in the company's long-term vision;
✓ System boundaries and boundaries: what part of the business process is being automated;
✓ Key objectives and benefits;
✓ BPx requirements applicable;
✓ Other applicable regulations.
9.3.2.3 Operational Requirements
Operational requirements include:
• Functions - are the functional requirements that enable the system to execute the business process that
is being automated, such as:
✓ Calculations, including all critical algorithms;
✓ Safety against damage;
✓ Security including access control;
✓ Audit trails;
✓ Use of electronic signatures;

✓ Outputs (eg, reports);
✓ Clear error messages.
• Data - requirements related to data handling, considering its impact on security

patient, product quality and data integrity, covering the following points:
✓ Definition of electronic records;
✓ Definition of data types, including identification of characteristics, formatting,
critical parameters, valid date range and format, limits and accuracy, and so on;
✓ Where and how data will be recorded (eg, relational databases, files
encrypted, etc.)
✓ Required fields;
✓ Data migration (import and export);
✓ Data entry and subsequent editing;
✓ Backup and recovery;
✓ Archiving requirements;
✓ Data security and integrity.
• Technical Requirements - Covers the following points:

✓ Changes in system operation (start, stop, test, failures);
✓ Disaster recovery;
✓ Performance and time requirements. They must be quantitative and unambiguous;
✓ Action required in case of failure;
✓ Capacity requirements;
✓ Access speed requirements for reading and writing data;
✓ Hardware requirements (eg touch-screen, keyboard type; type of mouse and mouse pad;
type and number of physical processors, network card);
✓ Portability and remote access;
29
Page 30
✓ Efficiency (screen and system loading speeds, screen refresh and generation
reporting);
✓ Type and version of the platform on which the system will work (Windows, Unix, Linux etc.);
✓ Types and versions of the protocols used;
✓ Configurability.
• Interfaces - must be defined (if applicable), covering the following points:

✓ User interface (s) - defined in terms of access levels (operator, administrator,
system manager) or roles where appropriate;
✓ Interface (s) with other systems;
✓ Interface (s) with equipment, such as sensors or actuators. This may include I / O lists
(input and output) for systems used for process control;
✓ Form of input and output of data by users (eg keyboard, barcode reader,
printers, etc.).
• Environment - involves the environment in which the system will work, covering the following points:
✓ Layout - physical layout of the plant or other workplace that may impact the system, such as
such as remote links (remote access) or space limitations;
✓ Physical conditions (eg temperature; humidity; external interference; protection against
radio frequency, electromagnetic and / or UV interference; dust, high vibration);
✓ Physical requirements;
✓ Power / energy requirements (eg voltage; amperage; filtering; frequency; protection of
grounding; uninterrupted power supply / UPS);
✓ Any physical or logical requirements.
9.3.2.4 Restrictions
Any restrictions in the specifications or operation of the system must be identified and documented,
covering the following points:
•
Compatibility, taking into account any existing systems or hardware that they will share
the same resources or will have interfaces for exchanging information (eg sending and receiving revenue from
production and process parameter values etc.);
• Access availability (eg: location, intranet and internet);
• Reliability requirements;
• Maximum period allowed for maintenance or other downtime;
• Legal obligations;
• Working methods;
• User skill and knowledge levels;
• Capability and flexibility of expansion;
• Possible improvements;
• Expected lifetime;
• Long-term support.
30
Page 31
9.3.2.5 Life Cycle
Any requirements that may impact the development of the cycle should be identified and documented
at the supplier and any subsequent verification activities.
The following points should be covered:
• Development requirements (eg, minimum standards to be met by the

provider);
• Procedures for project management and quality assurance;
• Mandatory design methods;
• Special testing requirements;
• Test data;
• Loading test;
• Necessary simulations;
• Factory Acceptance Test (FAT);
• How the items to be delivered should be provided (eg, format and media);
• Documentation to be delivered by the supplier (eg functional specifications; test specifications;
minimum hardware and software requirements ; design specifications; maintenance guides or manuals and
user);
• Data to be prepared or converted;
• Testing, maintenance, data and access management tools;
• Training courses;
• Archiving facilities;
• Support and maintenance required after acceptance.
9.3.2.6 Glossary
Definitions of any little-known terms should be provided.
9.3.2.7 Approvals
Approvers must be defined. At a minimum, one of the approvers must be the owner of the process. Others
approvers could be the owner of the system and the quality unit.
Once the ERU document has been approved, any changes must be made through the control of
changes.
9.3.3 Out of Scope Topics
This section is intended for systems with multiple levels of specification and verification and may not be applicable to
Category 3 systems, low risk and commercially available.
The following items should not be included in the ERU / URS:
• System configuration / project details;

• Implementation details;
31
Page 32
• Project deadlines;
• Costs;
• Organizational details of the project.
The system configuration / project details item is part of the solution of how requirements will be
met, being defined in the subsequent specifications. Implementation details are also
totally dependent on the solution, not being part of this step.
9.3.4 Capture of Requirements
For category 4 and 5 systems, it is often more difficult and time consuming to prepare the
ERU / URS document. The development of this document is one of the most important tasks that the
regulated company will undertake within the project to implement a computerized system.
It is essential that the process to be automated is properly mapped before defining ERP / URS.
Thus, it is important to detail the process step by step, defining the input and output information.
This activity should be carried out by a multidisciplinary team, including the operational level.
Below is a list of the different modes that can be used by the regulated company for the capture and
refinement of user requirements:
• Discussions and interviews;

• Observation (understanding of the process as a whole);
• Workshops - multidisciplinary team;
• Understanding the pitfalls that can occur when defining requirements.
9.4 SELECTION OF COMPUTER SYSTEMS SUPPLIER

9.4.1 Introduction
After the construction of the document containing the user's requirements (ERU / URS), the regulated company will
select the supplier of the computerized system that meets the requirements established and described
previously.
Regulated companies must perform formal assessment of each computer system supplier
relevant to GMP and related services. This assessment should be based on the criticality of the
system / service to be provided.
There must be a formal justification for not carrying out the evaluation of system / service providers
relevant to GMP.
9.4.2 Types of Evaluation
There are three options for conducting a system / service provider assessment:
• Basic assessment based on available information;

• Auditing using a questionnaire;
• Audit with a visit to the supplier by a specialist, auditor or audit team.
32
Page 33
Normally, a basic audit is sufficient for low-impact systems, whereas for high-impact systems
impact it may be necessary to carry out a more in-depth assessment.
Auditing using a questionnaire may be suitable for suppliers of products and services
standard and configurable.
9.4.3 Evaluation Process
The main steps for supplier assessment are as follows:
1. Decision-making based on risk, the most appropriate route for carrying out the assessment;
2. Performing the basic assessment, if sufficient, or the assessment using a questionnaire or assessment
through visiting the supplier, depending on the decision made above;
3. Evaluation report;
4. Determination of corrective and follow-up actions, which may involve a visit from
monitoring at the supplier's company;
5. Supplier approval or rejection.
If the supplier is approved, it must be periodically reassessed by the regulated company, in accordance with the
frequency defined in standard operating procedure.
9.5 DOCUMENT CONTAINING FUNCTIONAL SPECIFICATIONS (EF / FS)

9.5.1 Introduction
Functional specifications (EF / FS) define the system that meets the user's needs, described in
specifications of user requirements (ERU / URS).
For some systems, such as those commercially available and low risk, belonging to category 3,
a simple approach consisting of a simple level of specification and verification is appropriate and a
document containing the functional specifications is not necessary.
A Functional Specifications document defines what the system should do and what functions and facilities
will be provided. It provides a list of project objectives for the system. Formal tests will be based
functional specifications.
The document containing the functional specifications is produced by the supplier and must be reviewed and
approved by the regulated company. It is often considered a contract document.
The following guidelines must be followed when producing the specification:
• All design constraints (eg, the externally defined limitations that a system must meet,
such as hardware / software platform , speed, power, test, environmental and operational conditions)
must be explicitly documented;
• Ambiguity, duplication and contradiction must be avoided;
• Consistent nomenclature conventions must be adopted;
• Each function and installation described must be testable;
• Internal and external interfaces must be clearly defined;
• The functional specifications must be clear enough to allow the project to proceed without
there is frequent need to consult the author of these specifications
✓ Both users and programmers must understand the functional specifications;
33
Page 34
✓ The use of diagrams and graphs is recommended when appropriate.
Functional specifications must be prepared and organized in a way that allows traceability by
the entire life cycle, from individual requirements to associated tests.
9.5.2 Content of the EF / FS Document
Below is a list of topics that may be part of the EF / FS document, not intended to be
neither exhaustive nor prescriptive.
The following information must be provided:
• Document ownership;
• The contractual status of the document (if applicable);
• Relationship with other documents (eg ERU / URS).
9.5.2.2 Overview
It should cover the following topics, where appropriate:
• Scope and objectives;

• Reference to the relevant GMP regulations;
• Impact on patient safety, product quality and data integrity;
• High-level description (subdivide into primary system components);
• The main interfaces between the system and other systems and / or the environment;
• Assumptions / restrictions;
• Non-conformities in relation to the specifications of the users' requirements, which must be
documented and justified.
9.5.2.3 Functions
The high-level description should be divided into individual functions.
The following aspects should be addressed, where appropriate:
• The purpose of the function and the details of its use, including interface with other parts of the system.
Inputs, outputs, critical calculations, algorithms and the impact on other functions and / or systems and / or environment
must be highlighted;
• Performance: response, scaling, centralized or distributed processing and throughput
transfer - These points must be quantitative and unambiguous;
• Security and protection - Action in case the selected software or hardware fails; self check;
verification of input value; redundancy; access restrictions; downtime and data recovery;
• Functions that are configurable and any limits for configuration;
• Traceability to the specific requirements of the ERU / URS;
34
Page 35
• Fault conditions, fault actions, log files and diagnostics.
9.5.2.4 Data
The following aspects should be addressed, where appropriate:
• Definition - data must be defined in a hierarchical manner, with complex objects being
constructed from simpler objects (eg, log files). Critical parameters must be highlighted;
• Access;
• Allowable range for input and output values;
• Required fields;
• Verification of data validation;
• Data relationship;
• Data storage capacity, retention time and details on data archiving;
• Data integrity and protection;
• Data migration (import and export).
9.5.2.5 Interfaces
The interfaces between systems should be described, defining how the systems and subsystems interact, which
they come and what they need. For systems regulated by BPx, protection of the interfaces is important.
The following points should be addressed when appropriate:
• Interfaces with users. This should be defined in roles (access profile), such as, operator,
administrator, system manager, etc. Topics to be considered: types of peripherals; general format of
screens and reports; error handling and reporting and security. User input mode (s) should be
set (s), such as, keyboard and mouse , touchscreen ; pen calligraphy;
• Interfaces with equipment, such as sensors and plant equipment;
• Interfaces with other systems. This should cover the nature and time of interaction and the methods and rules
that govern the interaction between systems. If there are any middleware restrictions , this should be
registered.
The following topics should be considered for any type of interface :
• Data transmitted and received;

• Data type, format, intervals and meaning of the values;
• Time;
• Data transfer fees;
• Communication protocols: initiation and order of execution;
• Any data sharing, creation, duplication, use, storage or destruction;
• Initiation and interruption mechanisms;
• Communication through parameters, common data areas or messages;
• Direct access to internal data;
• Error handling, recovery and reporting;
• Access and security.
9.5.2.6 Non-Functional Attributes
35
Page 36
How the system will meet non-functional requirements should be described. The following items should
addressed when appropriate:
• Availability (reliability, redundancy, error checking, stand-by operation );

• Maintenance (possibilities for expansion and improvement; extra capacity; probable changes in
environment and service life).
9.5.2.7 Environment
Any special logical or physical requirements, such as encryption or physical protection (controlled access),
should be evaluated.
9.5.2.8 Glossary
9.5.2.9 Appendices
Where appropriate, for example, for small systems, appendices should be provided to define the
specifications hardware and software .
9.6 DOCUMENT CONTAINING THE CONFIGURATION AND DESIGN
9.6.1 Introduction
This section discusses how to define the required configuration of the system components and the project
system.
Depending on the type of system (configurable or customized), the configuration and design specifications
provide a detailed technical expansion of the functional specifications. Define the features and flexibility of the
system, properties and specifications. The information generated forms the basis for subsequent
configuration management activity.
There is no need to prepare separate documents to define the configuration and the project. An
specification hierarchy may be necessary for larger and more complex systems, as for systems
smaller ones or considered low-risk specifications can be combined.
9.6.2 Overview
9.6.2.1 Configuration
For configurable products, configuration specifications that make up the system must be prepared for
that it meets the user's requirements. This includes defining all settings and parameters.
These configuration specifications are produced by the system supplier and reviewed and approved by
regulated company.
It is possible to maintain this set of configuration specifications on systems that are managed
robust configuration ( detailed and complete audit trails ). Such an approach must be well documented.
36
Page 37
9.6.2.2 Project ( Design )
For customized applications, a document containing the hardware and software design must be prepared .
software. So it may be necessary to prepare a document containing the configuration specifications.
The project hardware defines the components of hardware that make up the system, for example,
component or system architecture, or interfaces .
The software project has two levels. At the highest level it defines the software modules (subsystems)
that will form the complete system software , the interfaces between these modules and the interfaces among others
external systems. At the lowest level, the software project describes the operation of the module software
individual. These specifications must be unambiguous, clear and precise.
The design specifications are produced by the system supplier and reviewed and approved by the company
regulated.
The regulated company must have a unified approach for carrying out the specification and verification
of the infrastructure that supports your systems projects and this activity should not be repeated for each
system.
9.6.3 General Considerations
The use of tables and diagrams to illustrate the Configuration and Design Specifications is highly
recommended. Standardized tables can help ensure that all parameters and settings have been
defined. Diagrams can help within the software project to clarify and explain the data flow, the
logical control, data structures and interfaces . Diagrams in hardware design can help
understand about architecture and connectivity.
Configuration and Design must cover both hardware and software aspects . Depending on the risk,
size and complexity of the system these points can be covered by a simple specification or can
demand a hierarchy of specifications covering hardware and software separately. Each
specification must be referenced individually and be traceable to the associated high-level specification.
All specifications must be structured to support traceability throughout the entire life cycle.
from the individual application to the test associated with this requirement.
9.6.4 Document Content
The sections described below are not intended to be prescriptive or exhaustive. The level of detail
it depends on the risk, complexity and innovation of the system. They can be part of a simple document or
of a document hierarchy .
It should contain the following items:
• Ownership of the document containing the configuration and the project;

37
Page 38
•
• The contractual status of the document (If applicable);

The relationship with other documents (ERU / URS; EF / FS; other configuration specifications and
project etc.).
9.6.4.2 Overview
This section should briefly describe the configuration and / or design. Depending on the complexity of the system,
this can cover the complete system, hardware and / or software . This section can be illustrated using
diagrams.
9.6.4.3 Configuration
The necessary configuration of the components must be provided, including, but not limited to:
• Settings, or configuration parameters, needed;

• Reason for configuration, with reference to the control specification;
• Tools or methods that will be used to define the necessary configuration options;
• Dependencies or impacts of / on other modules or systems
• Infrastructure items such as operating systems or layered software;
• Settings security.
For small systems it may be possible to incorporate this information into the Specifications document
Functional.
9.6.4.4 Hardware Design
9.6.4.4.1 The Computerized System
The general architecture of the necessary hardware must be defined. At a high level this can be illustrated by
block diagram showing both the functions of the parties and their functional relationships. The
The following items should be covered, where appropriate:
• Main computer system - Must describe the primary hardware components of the system
main computer, such as central processing unit (CPU), memory, bus type ; accuracy
clock etc .;
• Storage - Describe all proposed memory devices with their respective
maximum storage capacities, such as hard disk ; CD writer , tapes etc .;
• Peripherals - Must describe the necessary peripheral devices, including any requirements
specific to your installation;
• Interconnections / networks - Must describe all hardware component interconnections and any
connections with other equipment, devices and computer systems. This description may contain the
following items: cable specifications; connector specifications; shielding requirements; networks or
other external connections, etc .;
• Configuration;
• Embedded systems (inside the process equipment) - Must include the following elements:
layout diagrams for detailing the control panel and internal and external arrangements; diagrams of
38
Page 39
location to indicate where sensors and other devices are installed on the equipment; diagrams of
electrical wiring and piping / process drawings and instrumentation diagram (P&ID);
• Reference to relevant standards / norms.
9.6.4.4.2 Inputs and Outputs
The formats of the inputs and outputs should, when necessary, be specified. These may include the signs
digital and / or analog.
For external equipment the following elements must be considered:
• Accuracy;
• Isolation;
• Current and voltage range;
• Types and number of interface cards ;
• Time.
9.6.4.4.3 Environment
The operating environment for the hardware must be defined. The following topics should be considered:
• Temperature;
• Moisture;
• External interference;
• Physical security;
• Shielding against radio frequency, electromagnetic and / or UV interference;
• Protection against physical damage such as dust or vibration.
9.6.4.4.4 Power Supply
The requirements for power supply for the configured hardware must be described. The following
elements should be considered:
• Filtration;
• Loading;
• Grounding;
• Stability;
• Uninterruptible power supplies (UPS);
• Energy consumption and / or heat emission to calculate the required air conditioning capacity or
heating, ventilation and air conditioning (HVAC) system.
39
Page 40
9.6.4.5 Software Design
The software must be designed according to recognized standards for software development , when
appropriate.
Software design specifications are required for customized applications. These specifications do not
are required for configurable systems, as in this case the software project is reviewed or evaluated as
part of the computer system supplier's assessment.
9.6.4.5.1 Description of the Software
The modules that will form the computerized system must be described, declaring the
purpose of each module. A list detailing all the interfaces between the modules and any
interfaces with external systems must be presented. A system diagram is recommended.
9.6.4.5.2 System Data
The system data and the relevant data objects must be defined. The data must be characterized
in a hierarchical way, with complex objects being built from simpler objects.
Objects can include the following items:
• Databases and file collections;

• Files;
• Records.
A description of the data objects includes, but is not limited to:
• Data types (integers, floating point numbers, characters, Booleans, string

( string) , objects (images and documents), etc.);
• Data format (alphanumeric or numeric, field length, dates, etc.);
• Data accuracy;
• Data accuracy.
Each file and data structure must be uniquely identified. The use of methods of describing
data formats such as “Entity Relationship Model” or similar can be considered.
It is acceptable for system data to be defined separately as in a dictionary. If this is done

therefore, this approach must be clearly explained and documented.
9.6.4.5.3 Module Description
For each module, the following points must be covered:
• Module operation: the description can take the form of a pseudocode or flow chart;
• Interfaces with other modules: this point can refer to the system diagram, if there is one;
• Error handling and data verification;
• Data mapping for each module;
• Software module data .
40
Page 41
For each subprogram of the software module , the following points must be covered:
• Subprogram operation: the description can take the form of a pseudocode;

• The steps involved in each process to be performed and the inputs and outputs of each step;
• Parameters: each parameter must be identified as one of the examples below:
✓ Input parameter;
✓ Output parameter;
✓ Input and output parameters.
• Algorithms;
• It must be identified how each parameter passes the test, either by value or by reference;
• Any side effects of the subprogram;
• Language type, including the “core” and platform version;
• Reference to any programming standards;
• Description or examples of all display screens;
• Subprogram data.
• Description or examples of all reports implemented, their meaning and manipulation and when
were generated.
The level of detail can be provided in separate specifications.
9.6.4.6 Glossary
9.7 TESTING PLAN FOR COMPUTERIZED SYSTEMS

9.7.1 Introduction
The performance of tests in the system meets the following objectives:
• Identification of defects that can be corrected or removed before use;

• Failure prevention that can affect patient safety, product quality or integrity
of the data;
• Provision of documented evidence that the system performs its functions as specified;
• Demonstration that the system meets the intended requirements;
• Providing confidence that the system is suitable for its intended use;
• Provision of the basis for user acceptance;
• Meeting a key regulatory requirement, where appropriate.
9.7.2 Roles and Responsibilities

The regulated company must define the roles and responsibilities related to the performance of tests in the system.
These roles and responsibilities may include:
• User - responsible for the system in question and for the approval of test documents;
• Subject Specialist (SME) - can act as a test manager, executor, reviewer or authorizer;
41
Page 42
• Test manager - test planning and test plan writing;

• Test Analyst - responsible for developing test cases and test scripts;
• Test runner - this role should be as independent as possible. You must not be the author of the software
or test scripts, if possible;
• Test reviewer - responsible for reviewing test cases, test scripts and test results
tests - it should not be the same person who performed the tests;
• Quality Unit - role defined by the GMP;
• Supplier - can act as a test planner, performer, reviewer or authorizer for some of the
tests.
9.7.3 Testing Strategies
The testing strategy, also known as the test plan, should define an appropriate approach to the
testing on a specific computerized system.
The testing strategy is based on the following points:
• Results of risk assessments;

• An understanding of the system components (GAMP categories), the complexity and innovation of the
system;
• Results of supplier evaluations, if applicable.
The testing strategy varies according to the category of the system, ranging from a simple system of the category
3 to a complex category 5 system. The testing strategy must be reviewed and approved by the Specialist
on the subject.
The testing strategy should define:
• What kind of tests are needed;

• The number and purpose of the test specifications;
• The use of the supplier's existing documentation according to the assessment carried out in the
provider;
• The testing phases:
✓ Location and duration of each test phase;
✓ Resources required for each testing phase;
✓ Responsibilities for each testing phase.
• The approach used to provide evidence of testing (eg, impressions);
• Procedures for managing test failures;
• Test documentation format;
• The use of test metrics;
• Use of visual testimony of the tests.
9.7.3.2 Test Documentation
Figure 5 below shows a typical structure for testing documentation.
42
Page 43
Figure 5. Typical structure for testing documentation.

Source: GAMP5
The use of templates to carry out test documentation, such as test specifications, records
test results and test reports, helps with consistency, facilitates review and avoids errors in
documents.
In this section, each type of document presented in figure 5 is described.
9.7.3.2.1 Testing Strategy
Described in item 9.7.3.1.
9.7.3.2.2 Test Specifications
They are a set of test scripts that are suitable for a specific purpose for a specific phase
of a project.
The test specifications should cover the following points, where applicable:
• Introduction;
• The contractual status of the defined document;
• Relationship to other documents;
• Scope - must state where the test specification fits into the overall testing strategy;
• The test scripts / cases to be executed;
• Software version or configuration under test;
• Purpose;
• Resources;
• Personnel required to carry out each test or group of tests;
• Methods used;
• Any grouping or logical ordering of the tests;
• Prerequisites;
• Environment;
43
Page 44
• Tools, including automated testing tools;

• Reference to specifications;
• Necessary documentation;
• Necessary reviews and approvals.
9.7.3.2.3 Test Cases / Itineraries
The test cases / roadmaps must contain the details of the tests. The test script should be described in detail
enough to allow consistent repeat testing.
Each test script should, where possible, include the following points:
• Unique test reference;

• Cross reference to control the specification;
• Test title;
• Description of the test, including the purpose of the test;
• Test steps - a step-by-step description of the actions to be taken by the performers,
together with the expected results;
• Acceptance criteria - Expected result (s) that must be met in order for the parameter
specific challenge is considered pass or has passed the test;
• Pre-test steps - including any test or preparation prerequisites;
• Data to be recorded - description of the data to be collected and recorded;
• Post-test actions - optional section that details the actions required to return the system to the state
original.
9.7.3.2.4 Test Results
The test results must be available for subsequent review and inspection. The information to be retained
should include tests that have passed, those that have failed, records of test failures, test reports and
any documentation of evidence of testing, such as prints, notes and photos.
9.7.3.2.5 Test Report and Summary Test Report
Test reports must contain:
• Introduction;
• Scope of tests;
• Testing organization;
• Who performed and who reviewed the tests;
• Summary of test results in tabular form;
• Summary of test failures;
• Conclusions;
• For large or complex projects that have multiple test reports the general conclusions
can be documented in a summary test report.
9.7.3.3 Components of the Test Strategy
44
Page 45
The following points should be taken into account when developing the testing strategy:
• Company policies and procedures;

• Results of risk assessments;
• Results of supplier assessment;
• GAMP system categories;
• Other documents, such as: requirements specifications; initial risk assessment; specification
functional; configuration specification; design documents; results of other activities carried out in the
different stages of software development and traceability matrix.
9.7.3.4 Types of Tests
There are basically two types of testing activities:
• White Box Testing ( White Box Testing ) - also known as a test based on the code or
structural tests, where tests are identified based on source code, knowledge of
detailed design specifications and other development documents;
• Black Box Testing ( Black Box Testing ) - testing based on functional specifications,
hence known as functional tests.
Black box tests may be sufficient as long as the supplier's assessment has found
adequate evidence of white box testing.
Specific types of tests should be considered, depending on the complexity and innovation of the system, the
associated risk and the assessment of the system supplier to be tested, including:
• Normal Case Tests (Positive Case or Capability Tests) - system skill challenges
to do what it was supposed to do, including triggering error and alarm messages,
according to specifications;
• Tests of Invalid Cases (Negative or Resistance Case) - challenges to the system's ability to not
do what you shouldn't do, according to specifications;
• Repeatability Tests - challenges to the system's ability to repeatedly do what it should do
or continuously, if associated with real-time control algorithms;
• Performance Testing - challenges to the system's ability to do what it should do as quickly and
effectively possible, according to the specifications;
• Volume / Load Testing - challenges the system's ability to manage high loads as it should.
Volume / load tests are required when system resources are critical;
• Regression Testing - challenges to the system's ability to:
1. Maintain functionality after being modified according to specified requirements;
2. Ensure that software modules not involved in the modifications are not affected
adversely.
• Structure / Path Tests - challenges to the program's internal structure to challenge
routines / algorithms, variable values, function return values, etc.
The tests must challenge the system. So, for example, if the system is designed or intended to record
the values of the parameters monitored or controlled in a database at an established frequency
(eg, every second, minute, etc.), that condition or worst case should be tested to ensure that
data generated during the routine will be recorded correctly.
45
Page 46
9.7.3.5 Test Environments
The test strategy must consider and define the environments necessary for carrying out the tests. For
typical category 3 systems there will be only one environment. For more complex systems, the performance of
Testing can take place in different environments during the design phase, which may include:
• Development environment, where prototype production or programming takes place;

• Test environment, where tests are formally performed;
• Operating environment where the system is installed in its target environment.
Formal tests, as far as possible, should be performed in an operational environment. To this end, the records
must be clearly distinguished from production records or test records can be filed before
beginning of the operation. Tests can also be performed in a separate test environment or in
two environments.
The test documents must specify which environment will be used. When using a
the test strategy chosen must justify the equivalence of the test results to the results that
would be obtained in the operational environment.
Formal tests should only be performed in environments under configuration management.
9.7.3.6 Acceptance Tests

Acceptance tests are specific tests performed to meet some contractual needs. These
tests are usually part of a predefined group of functional tests performed to demonstrate the
adequacy of the system to the intended use and compliance with user requirements. In such situations,
take advantage of test results already carried out, thus avoiding duplication of tests.
Acceptance can be carried out in two stages, Acceptance at the Factory ( Factory ) or the Plant ( Site ), namely:
• Acceptance Testing Factory ( Factory Acceptance Tests - FAT) - are performed on the premises of
before delivery, to show that the system is working well enough to be
installed and tested at the user's premises;
• Acceptance Tests in Plant ( Site Acceptance Tests - SAT) - run on the company premises
regulated to show that the system is working in its operating environment and that its interface with
other systems and peripherals and is working properly.
This approach is often used for automated equipment and control systems.
The environment for conducting the acceptance test (test or operational) must be defined.
9.7.4 Execution of Tests
All tests are performed according to specifications and scripts pre-defined and approved and maintained
under version control.
46
Page 47
9.7.4.1 Prerequisites
The following general requirements must be met before formal testing begins:
• Formal configuration management must exist before formal testing begins.

All items to be tested ( Firmware / software / hardware ) that are within the scope of the testing phase
specific, should be considered as a baseline and be under change control before execution
of tests;
• All necessary documentation must be available as described in the test specifications;
• All prerequisites must be available;
• If there is a need to calibrate any equipment, this must be done and documented. THE
calibration equipment must be certified, traceable to national standards and referenced according to
customer procedures;
• All personnel responsible for carrying out the tests, including end users, must be trained in the
test procedures and must be able to demonstrate sufficient confidence to operate the system in
test. Training must be documented.
• All employees involved must be trained in Good Documentation Practices.
9.7.4.2 Execution
Tests should be performed as follows:
• According to a pre-defined and pre-approved specification.

• Each test must be performed according to the test script and the results must be recorded;
• Each test must be performed by an appropriately trained person, including Good Practice Practices.
Documentation;
• The results of the tests must be documented directly at the time of their execution and must be
be maintained;
• All test results must be recorded immediately and accurately;
• The identity of the tester must be recorded;
• Test records made manually must be readable. Shorthand annotations should
avoided and real values should be recorded whenever possible;
• The test runner must decide whether the acceptance criterion is met and whether the test has passed or not. THE
test script must declare whether the test PASSED or FAILED;
• In the event of a FAIL in the test, the executor must decide whether to continue testing, abort
tests or refers to item 9.7.4.4 (Test Review), in accordance with approved testing procedures.
All tests that fail must be recorded;
• Testing procedures must be flexible enough to allow the tester to be able to
decide whether to continue testing when you encounter situations such as when the system is found to
works correctly, but the test script is incorrect;
• All tests that fail must be traceable during correction until final closure. At
corrections of failed tests may require regression tests to verify that corrections do not
introduced new problems in other modules or routines of the system.
The execution of the tests must be audited periodically, by sampling, by the Quality Unit of the
regulated company.
47
Page 48
9.7.4.3 Test Support Documentation
Documentation, such as prints, screen prints, notes, photos, etc., are required to give
support test results.
More complex systems require more extensive and complete support documentation than more complex systems
simple.
Unnecessary supporting documentation, which does not add any value to the test results, should be
avoided.
9.7.4.4 Review of Tests
After completing the tests, the results should be reviewed to verify:
• That all tests have been covered;
• The legibility, accuracy and completeness of the tests;
• That all relevant documents have been included and that the documentation is complete and
correctly filled;
• That the acceptance criteria have been met;
• That all records of failed tests have been included;
• Compliance with procedures.
Alternatively, the tester may request a review of the tests when a failure occurs, in
in order to decide what actions will be taken and what will be the next steps.
Reviews must be performed and documented by a person other than the test runner, such as a
test reviewer or a group, or the subject matter expert.
In the event of test failures, the test reviewer must decide what action to take and what type of retest to take.
executed if necessary. These decisions must be documented.
Testing failures can result from:
• Error in the way the script was written. Corrective action: update, followed by script approval
corrected tests and consider the need for retesting;
• Error in how the requirement was defined. Corrective action: update the requirement, with possible
execution of retest and explanation in the test report;
• Error in the way the test was performed by the tester. Corrective action: repetition of the test;
• System error. Corrective action: application of a change control and repetition of the test.
9.7.5 Testing Activities Performed by the Supplier
There are different models of software development , including:
• Waterfall;
• Spiral;
• Prototyping;
• V model.
48
Page 49
Whichever model is used, the supplier must define the implementation of the model, including the
necessary quality controls and describe the method used to demonstrate that the system
computerized is suitable for the intended use.
Testing strategies must be properly established, implemented and documented.
The hardware and software configuration used in the tests must be documented. This includes: systems
underlying systems such as operating system, database and network; hardware for networks; servers and clients,
when appropriate.
9.7.5.1 Tests Performed During Development
Internal tests performed by the supplier must be performed according to test specifications
defined and approved. Types of tests most commonly performed are:
• Acceptance testing for hardware and software purchased - hardware and software purchased must be
subjected to acceptance tests before being used for system development;
• Module / unit tests - individual tests on software components , ensuring readiness
for later insertion into an integrated system;
• Integration and System Tests - tests of the integrated components of the system, subsystems and the
complete system.
9.7.5.2 Contractual Tests
Testing and verification activities should be defined for business purposes, between the
computerized system supplier and the regulated company.
9.7.6 Automated Tests
Automated verification testing tools can be used to improve

effectiveness and efficiency of test execution. They can be used both for the execution of cash tests
black and white box tests.
Any use of these tools must be defined in the testing strategy.
These tools must be used in accordance with instructions and manuals defined and maintained under
Configuration Management. They usually belong to GAMP category 1.
It is important that responsibilities are defined in relation to the following aspects:
• Ownership (Who owns it), administration and maintenance of the test tool;
• Maintenance of test data;
• Maintenance of test documents (including test specifications, test scripts and
Test results);
• Instructions and manuals for use.
Preferably, these testing tools should have the capabilities of electronic signatures and
electronic records that meet regulatory requirements.
49
Page 50
9.7.6.1 Examples of Automated Test Execution Tools
Below are some examples of tools for automated execution (source code debugging and
testing tools) for testing the source code:
• Automated test drivers (automatic test execution);
• Test data generators;
• Environment simulators;
• Static analyzers;
• Dynamic performers;
• Symbolic performers;
• Volume / load drivers .
9.7.6.2 Automated Testing Documentation
The automated test scripts must be controlled according to approved procedures.
The records ( logs ) generated by the computer resulting from the execution of the automated test scripts are
normally generated automatically from the execution of the scripts.
The header record ( log ) must provide the following information:
• Record identification;
• Date and time of execution;
• Test script name and version;
• Test runer's identity and the name of the test environment.
The record cannot be edited or deleted. They must be read-only files ,

and should be maintained for future reviews or audits.
The automated test documentation must be kept for a minimum for the same period as the records
tests performed on paper.
The use and management of automated testing documentation must be approved in advance
by the Quality Unit as part of the development of the testing strategy.
9.7.7 Tests Applied to Different Categories of Systems
This section presents the practical considerations for planning the tests to be performed on the systems
belonging to categories 3, 4 and 5.
For those computerized systems that comprise equipment managed by a

application ( software ), there is a need to also carry out the qualification of this equipment, whose
methodology is described in international guides and specific legislation and is not the scope of this guide.
Hardware / software IQ and OQ activities are often performed by the supplier of the software .
software, but such activities must have an active participation in the realization and approval by the company
regulated.
50
Page 51
9.7.7.1 Aspects Applicable to All System Categories

9.7.7.1.1 Hardware / Software Installation (IQ) Tests
Many companies call this Installation Qualification (IQ) activity. The purpose is to verify and
document that the system components are installed according to specifications, documentation
supplier and local and global requirements.
It must be evidenced that the documentation together with the system is complete and that the installation requirements
and for local and global use are in accordance with specifications.
Installation tests provide a configuration baseline for subsequent installation activities.

verification and validation, allowing to verify the installation methods, the
testing tools and / or scripts used. This forms the basis for managing the configuration of the
installed system.
Installation tests should verify that the following documents are available, when appropriate:
• Technical and user guides;

• Standard operating procedures;
• Training schedules;
• Service Level Agreements;
• Security procedures;
• Record books;
• Hardware inventory ;
• List of instruments;
• Spec sheets;
• Calibration certificates and procedures;
• Piping / process and instrumentation diagrams (P&ID);
• Equipment list and specification sheets;
• Software inventory (including installation procedure, system software list,
application software , data list, initial data settings for initialization);
• Program source code (category 5);
• Preventive maintenance program;
• List of critical spare parts.
9.7.7.1.2 Hardware / Software Operations (OQ) Tests
Below is a general list, applicable to all systems. It should be used to assist in the verification of
installed system:
• Power outage test (prevention of loss of critical data or loss of control action;
control reset facility);
• Access to the system and system resources;
• Audit trails and record of critical actions, including manual interactions;
• Manual data entry and input validation features;
• Electronic signature features;
• Error and alarm messages;
• Critical calculations;
51
Page 52
• Critical transactions;
• Transfer of critical data to other packages or systems for further processing;
• Interfaces and data transfer;
• Backup and restore;
• Data archiving and recovery;
• Ability to handle high volume loads, particularly if the system is accessed by many
users or need to register many values of the controlled / monitored parameters at the same time,
as part of a networked application, for example.
9.7.7.2 Test Activities for an Unconfigured Product
These computerized systems are those called “ off-the-shelf” systems ,

meaning they are not configured for a specific business process or are used with your
default setting ( default ). They are classified as category 3 of the GAMP.
The regulated company may decide to make a supplier assessment to verify the quality of the product,
depending on the risk. Based on the satisfactory outcome of this assessment and the risks involved, an approach
simple consisting of only one level of specification and verification can be applied.
Tests should focus on the following points:
• Those related to the installation of the system, described in item 9.7.7.1.1;

• User Requirements Tests that demonstrate the suitability for the intended use, which may include the
conducting system functionality tests against pre-established requirements,
depending on the risk involved;
• User Requirements Tests must also include delivery and acceptance of documentation
complete sent by the supplier, including specifications, manuals and drawings, if not yet done;
• Any subsequent or more rigorous tests depending on the risk and supplier assessments;
• Any other relevant aspects listed in item 9.7.7.1.2.
9.7.7.3 Test Activities for a Configured Product
A configured product involves configuring commercially available software that runs on

standard hardware components . These systems that are configured for a specific business process
are classified as category 4 of the GAMP.
In such a situation, based on the satisfactory result of the supplier's assessment and the risks involved, the
testing strategy using the three-level approach (configuration, functionality and requirements) is the
recommended. The number of test documents needed to cover these three levels will depend on the
complexity and impact of the system.
• Those related to the installation of the system, described above in item 9.7.7.1.1;
• Configuration Tests - for each Configuration Specification there must be a Configuration Specification
Associated Configuration Test. Tests should verify that the system has been
installed according to specifications. Tests can be performed through inspection or verification
the supplier's documentation;
52
Page 53
• Functional Tests - functionality that supports the specific business process. In this activity the
vendor documentation can be leveraged. Possible types of functional tests: normal case (positive);
invalid case (negative); repeatability; performance; volume / charge; regression; structural tests;
• User Requirements Tests that demonstrate the suitability for the intended use, which may include the
conducting system functionality tests against pre-established requirements,
depending on the risk involved;
• The requirements tests must also include the delivery and acceptance of the complete documentation sent
by the supplier, including specifications, manuals and drawings, if not yet done;
• Any subsequent or more stringent tests carried out as a result of risk assessments and
provider;
9.7.7.4 Testing Activities for a Custom Application
Some computerized systems are developed to meet specific user requirements when
there are no commercially available solutions. The software developed for such systems is
classified as category 5 of the GAMP.
In such cases and based on the satisfactory assessment of the supplier and the risks involved, a
testing based on the four levels (module design (unit); integration; functionality and requirements) is
applicable.
The number of test documents needed to cover these four levels will depend on the complexity
and system impact.
• Those related to the installation of the system, described in item 9.7.7.1.1;

• Revision of the new code, required as a result of the risk assessment;
• Tests of software modules to verify that they conform to your design specifications
- for each Software Module Design Specification , a Software Module Test Specification
associated product must be produced. The software module tests to be performed must ensure that the
software module meets specifications;
• Software integration tests to test whether the modules work correctly when operating
together - the Software Integration Test Specification defines those tests that demonstrate that
all software modules communicate with each other correctly and that the software system meets the
project specification. A Software Integration Test Specification must be produced when
more than one software module composes the final system;
• Configuration test (if applicable) - for each Configuration Specification, a Configuration Specification
Associated Configuration test must be produced. Tests should verify that the system has been configured
according to specification. Tests can take the form of inspections or verification of the
provider;
• Functional Tests - functionality that supports the specific business process based on
risk and supplier assessments (This is an area where supplier documentation can be
harnessed);
• Requirements Tests (URS) - demonstrate that the system is suitable for the intended use; this can
include carrying out tests of the system's functionality against predefined requirements, based on risk;
53
Page 54
• Requirements testing should also include delivery and acceptance of all

supplier, including specifications, manuals and drawings, if this activity was still carried out;
• Any subsequent or more stringent tests carried out as a result of risk assessments and
provider;
9.7.8 Test Report
A test report must be generated that summarizes the activities carried out and the results obtained and that contains
the final conclusions.
The approval of the test report constitutes the formal release of the system to perform the steps
subsequent life cycle.
Test reports must meet the requirements of the corresponding test specifications or in the case of
a test summary report, must meet the requirements of the test strategy.
9.8 COMPLEMENTARY ACTIVITIES

9.8.1 System Description
This section seeks to meet a recurring regulatory requirement:
“There should be an updated and detailed description of the system, containing the principles, objectives,
security, range of the system and its main characteristics of use, and the interface with other systems and
procedures. ”
The need for a system description can be covered by one or more existing specifications or
other documents or a separate document can be produced.
The main use of such a document is to help new users and regulators understand what the system does and how
this is written in a non-technical language as far as possible.
9.8.1.2 General Considerations
The System Description must be maintained for the life of the system.
For complex systems that are used by different departments or plants / sites (eg ERU) a
separate document may be the most appropriate. For simpler systems it is common practice to include the description
of the system in another specification or other document.
A complete description of the system, which meets regulatory expectations, must be established before the
system be released for operational use.
The system description should be subject to change control and periodic review.
9.8.1.3 Document Content
The description should cover only the main characteristics of the system. Detailed topic information
must be included in other specifications and not repeated.
54
Page 55
9.8.1.3.1 Introduction
This part should explain the context of the system within the business process and the regulated company in general.
This should be considered from the following perspectives:
• Departmental;
• Within the plant / site;
• Within the division;
• From a global point of view.
9.8.1.3.2 Main System Functionality
This part includes the description of the key functions of the system, both in relation to BPx and non-BPx,
many of which can be critical to the business.
The functions can be grouped to keep the description at a high level. The use of diagrams is encouraged
to explain relationships between key functions.
9.8.1.3.4 Computational Environment
This part should be covered by a high level diagram showing the architecture that supports the
system, covering, where appropriate:
• The infrastructure that supports the system (eg server configurations, storage arrangements
etc.);
• Interfaces for users;
• Interfaces for equipment;
• Interfaces for other systems;
• Interfaces outside the company;
• The flow of data through the interfaces;
• Security features such as firewalls.
9.8.1.3.5 System Components
An indication of the main hardware and software components must be provided. Must include
information about servers and storage equipment, as well as operating systems, types
database and applications. You should refer to any configuration documentation relevant to
the system. A detailed inventory of all system components is not required in this document.
9.8.1.3.6 System Interfaces
This part should include an overview of the key interfaces for other systems and equipment, as well as
as the flow of data between the systems involved.
55
Page 56
9.8.1.3.7 Access Control
This part should include an overview of the characteristics of access control to the system, both physical
(if relevant) and logical.
9.8.1.3.8 Security Controls
This part should include an overview of the established security controls, both physical and
logical. These should include software to protect data and records, such as, for example, antivirus and anti-
malware .
9.8.1.3.9 Electronic records and signatures
A description of the types of electronic records created and managed by the system and the types of
of electronic signatures used, if relevant.
9.8.1.3.10 Glossaries
Definitions of any terms that are unfamiliar must be provided.
9.8.2 Configuration and Change Management
Processes for configuration management must be established so that the system

computerized and all its components can be identified and defined at any time.
Change management procedures should also be established. The point or phase at which
change management has been introduced must be defined. This management must be applied both
for the design phase as well as for the operational phase.
Any involvement of the supplier in these managements must be defined and agreed.
9.8.3 Project Review
At appropriate stages of the life cycle, planned and systematic design reviews of the project specifications
design and development must be carried out. This project review should assess the results to be
obtained to ensure that they meet the specified requirements. Corrective actions must be defined and
developed.
The rigor of the execution of the design review and the extension of the documentation must be based on risk,
complexity and innovation.
9.8.4 Documentation Management
Documentation management includes preparing, reviewing, approving, issuing, changing, withdrawing and
archiving.
56
Page 57
9.8.5 Traceability Matrix
Traceability is a process for:
• The requirements are addressed and traceable to the respective design and functional specifications.
• The requirements are traceable to the respective checks.
In addition to demonstrating project and verification coverage, traceability helps with assessment and
change management.
Traceability should focus on aspects critical to patient safety, product quality and
data integrity and is known as the Requirements Traceability Matrix
For non-configured products, traceability between user requirements and the verification performed can
be enough.
For configured products, the design specification column ( Design Specification - DS) can be
replaced by a connection to the configuration items, providing traceability between system requirements
user, configuration and verification.
For customized applications, traceability must be presented from the project specification level,
from functional specifications to verification of user requirements.
Figure 6 shows an example of a traceability matrix, where AR stands for Risk Analysis.
Figure 6. Example of a Traceability Matrix.

Source: GAMP5
9.9 VALIDATION REPORT
9.9.1 Introduction
A validation report with a focus on aspects related to patient safety,

product quality and data integrity. It should summarize the activities performed, any deviations
occurred in relation to what was planned, the most important corrective actions and a statement about the
service of the system to the intended use.
57
Page 58
The level of detail in the report should reflect the risk, complexity and innovation of the system
The structure of the report should reflect the structure of the corresponding plan.
The report must be approved by at least the process owner and the Quality Unit. May also
it is appropriate that other approvers of the corresponding plan also approve the report, such as the owner
of the system.
It is common to produce a final report. However, there may be other reports (partial or phases of the
validation) that feed into this final report or that is created later to supplement it.
9.9.2 Contents of the Computerized System Validation Report

9.9.2.1 Introduction and Scope
The introduction should reflect the corresponding plan and highlight what differences may have arisen since the
plan was issued. It should contain the following information:
• Purpose and scope of the report;

• Who drafted the report and under what authority;
• Summary of the approach used;
• Cross-reference to the plans, procedures and policies that guided the report.
9.9.2.2 Scope Changes
It may be necessary to change the initial approach. The report must highlight and justify such changes in scope.
9.9.2.3 Supplier Evaluation

Supplier assessment activities should be summarized or referenced to other source documents,

such as a Supplier Assessment or Audit Report.
If the supplier's documentation has been used / used, there should be a discussion about the measures
taken to ensure their suitability.
Information already available in other documents should not be repeated.
Content of audit reports at the supplier should not be included in the validation report.
9.9.2.4 Summary of Activities
The summary must refer to the existing documentation and there should be no duplication of information.
This section can include subsections relevant to each phase.
9.9.2.5 Summary of Results Obtained
The report must verify that all the results expected in the corresponding validation plan have been
obtained and approved. This includes the system development documentation and Operating Procedures
Standard (POP) required for operational support.
58
Page 59
9.9.2.6 Summary of Deviations and Corrective Actions
The report should describe any activities and results that did not meet the specified expectations
in the plan and explain its impact and the respective corrective actions. The most important corrective actions should
highlighted and appropriate next steps identified or referenced.
9.9.2.7 Declaration of Suitability for Intended Use
There must be a clear statement about the status of the system and whether it is suitable for its intended use, taking
mind any major deviations or corrective actions.
9.9.2.8 Training
The report must verify that the personnel involved with the new processes, equipment or systems have
been trained and that this training has been documented.
9.9.2.9 Maintenance of Service and Adequacy to the Intended Use
The report should outline how the system's service situation will be maintained. This can be
efficiently achieved by referencing the relevant policies and procedures. See the documents
described in Section 11 of this Guide.
9.9.2.10 Glossary
9.9.2.11 Appendices
There may be a need for the existence of appendices, depending on the purpose, size and complexity of the
report, the corporate style of the regulated company and its policies adopted for the preparation of reports.
10. INVENTORY LIST
Regulated companies must maintain an inventory of computer systems.
The inventory must present summary information about each system, describing: name of the system;
associated equipment or application; impact / criticality in relation to BPx; GAMP category;
ownership (sector, system owner, process owner); current version; provider; validation situation.
Automated equipment can be listed separately and duplication must be avoided.
The inventory should cover the level of systems that support business processes and not items
individual hardware (components) that must be covered by local industry procedures
information technology.
59
Page 60
This inventory can be used for planning periodic reviews.
11. OPERATIONAL PHASE OF COMPUTERIZED SYSTEMS

11.1 INTRODUCTION
This section deals with the phase of the system's life cycle subsequent to its validation, in which the system
validated computer is released for use by the end user.
The operational phase can take many years and can include changing software , hardware ,
business and regulatory requirements. The integrity of the system and its data must be maintained throughout
period of use, including when retired, and must be verified when
periodic review.
As experience is gained with the computerized system,

improvement opportunities for the process and system, based on periodic review, evaluation of
operational and performance data, in the analysis of the root causes of the failures that occurred. Information obtained
incident management processes and CAPA's can provide relevant data for the
system evaluation.
Change management should provide a mechanism for the immediate adoption of improvements
technically adequate according to the approaches used for specification, design and verification
described in this Guide. The rigor of the approach, including the extension of documentation and verification must
be based on the risk and complexity of the change.
Table 3 presents the necessary procedures for the smooth running of the operational phase of the system
computerized.
Table 3. Operating Procedures Associated with the Operating Phase of the System.
Process Groups Procedures Section
Delivery • Delivery Process 11.2
Management of • Establishment and
Service and Performance Management Services 11.3
of performance Support
• Monitoring in
11.4
Performance
Management of • Management in
11.5
Incidents and CAPA Incidents
• COVER 11.6
Management of • Management in
Changes Changes and Configuration 11.7
System
• Repair Activities 11.8
Audits and Review • Periodic Review
• 11.9
Internal Audits
Management • Backup and Restore 11.10
Continuity • Business Continuity
and
11.11
Disaster Recovery
• Management gives
11.12
Safety
60
Page 61
Security and • Administration of

Administration of System 11.13
System
Management of • Retention, Archiving
Records and Recovery 11.14
11.2 SYSTEM DELIVERY

11.2.1 Introduction
System delivery is the process of transferring responsibility from the system, the project team or a
service group for the end user. It is an important process, as achieving compliance and
suitability for the intended use alone are not sufficient to ensure a successful transfer to
the operational phase.
The delivery process usually involves the project team (development group and / or supplier), the
owner of the process, owner of the system and the quality unit.
11.2.2 Key requirements
The regulated company must be able to demonstrate formal acceptance of the system after testing and
controlled transfer to the operating environment of the work routine. This activity should be
documented.
11.2.3 Responsibilities
The project manager is responsible for preparing the system for delivery. The owner of the process and the owner
of the system are responsible for accepting the system for operational use.
Responsibility for completing any exceptional actions at the time of delivery should be agreed
between the parts.
Consideration should be given to defining a period for monitoring the system after its
delivery and a reversal / return strategy in the event of a significant problem occurring during
the monitoring period.
11.2.4 Execution of the Delivery Activity
The company should define the scope, including configuration items, the period for delivery to occur and the
acceptance criteria.
Then you must establish a plan for delivery, which can be a separate document or be
part of the Validation Plan. A checklist can be used to ensure acceptance and
transfer of responsibilities.
The next step is to carry out the activities to deliver the system to the receiving group.
61
Page 62
An agreement must be established between the parties for the conclusion (justified) or transfer of any
open questions and incomplete activities or documentation from the design environment to the environment
operational. For the delivery to be successful, critical deviations cannot persist.
A report must be prepared, signed by the transferring group and the receiving group. This document
may be part of the System Validation Report.
11.3 SUPPORT SERVICE MANAGEMENT

11.3.1 Introduction
Support Services Establishment and Management activities ensure that
support, whether internal or external, are properly specified and managed. This process is
often managed through the use of Service Level Agreements -
SLA).
Service management and system performance monitoring are related to managing

generated records to evidence the proper operation and performance of the system. Additionally, there are
potential interaction with incident management, CAPA's and change management
when the results of the service or monitoring indicate that there are problems that need to be corrected.
The necessary support for each system and how it will be provided must be formally established. THE
support can be provided by internal and external resources. This process should ensure that agreements for
support, maintenance plans and standard operating procedures are established.
Service Level Agreements can be established separately for individual systems or to cover
groups of similar systems (eg equipment in a single laboratory).
It may be useful to have a standard format for Service Level Agreements and regulated companies, in addition to
a standard operating procedure to describe how to prepare an Agreement. An approach based on
risk for defining content and details must be considered.
Service Level Agreements must be agreed, understood and approved by both the system owner
and by the service provider. These agreements must unambiguously define the system whose
support will be provided, defining how the service will be provided and the responsibilities of the service provider.
service and the system owner.
The qualification of the service provider must be ensured and monitored through appropriate assessments,
there may even be audits at the service provider.
There must be a formal agreement with suppliers, including a clear statement of responsibilities.
In this context, it is understood that suppliers, both external outsourced and other departments of the
company, belonging to other management structures of the company.
It is the responsibility of the system owner to ensure that the necessary support is identified and that the Agreement
Service Level is established, followed, monitored and reported.
62
Page 63
It is the responsibility of the system owner to ensure that the service provider is subject to the assessment of
appropriate supplier.
It is the responsibility of the service provider to ensure the competence of the support staff and that they
are properly trained and work in accordance with agreed procedures and the Service Level Agreement
Service.
It is the responsibility of the organization providing the support service, identified in the Service Level Agreement
Service, execute the terms of the Agreement.
11.3.4 Execution of Activities
The support service management activity involves performing the following actions, in this order:
• First, support needs are identified.

• Following is the evaluation and selection of the support service provider (s).
• The next step is the establishment of the Service Level Agreement.
• The next step involves establishing the standard operating procedures to support the
system.
• From then on, the Quality and Performance of the system are monitored, through audits or
performance checks.
If the support contract does not meet expectations, it must be terminated.
11.4 MONITORING SYSTEM PERFORMANCE

11.4.1 Introduction
The impact of a computer system failure will vary depending on its criticality. When appropriate,
system performance must be monitored so that problems can be detected
timely. This activity allows the user to anticipate the occurrence of failures, through the use of
monitoring tools and techniques.
Performance monitoring is part of a general preventive maintenance program that aims to

purpose of acquiring performance data that is useful for diagnosing system problems. THE
monitoring can indicate trends that can indicate performance problems and that can be
used as part of corrective and preventive actions (CAPA) to reduce application downtime
or system.
Performance Monitoring Plans are system specific. However, it may be practical to develop
a Standard Operating Procedure on how to prepare these plans and develop some parameters
generic monitoring.
The level of detail of the monitoring plan will depend on the associated risk, the complexity and the
system innovation. It may not be necessary to develop monitoring plans for simple and
low risk, which may be covered by some other document.
Performance Monitoring Plans can be integrated with the Service Level Agreements discussed
in section 11.3.1.
63
Page 64
Performance monitoring can be an automatic or manual process, or even a combination of

both.
Performance monitoring records should be subject to periodic internal audit.

The need and extent of monitoring activities should be based on the system's risk to
patient safety, product quality and data integrity.
The appropriate performance parameters should be defined based on the identified risks.
It is the responsibility of the system owner to ensure that the performance of the system is monitored and that
appropriate actions are taken when necessary.
It is the responsibility of the system owner to inform the process owner and the Quality Unit about
any performance issues that may impact patient safety,
product and data integrity, and must also invoke Incident Management.
The performance monitoring activity involves performing the following actions, in this order:
• Conduct risk assessment;

• Define the monitoring plan;
• Start monitoring system performance, change control activities,
incident and maintenance management;
• Conduct periodic reviews and evaluations as a source of data for the Periodic Review of the system.
11.4.5 Monitored parameters
Depending on the risks to BPx of installed applications / systems and the type of computerized equipment
involved, the following conditions should be checked with appropriate tools at appropriate intervals:
• Servers / workstations / PCs / control systems;

• CPU usage;
• Use of the cache;
• Interactive response time;
• Number of transactions per unit of time;
• Average waiting time at work;
• Disk capacity utilization;
• I / O load (Input / Output);
• System error messages, including operating system failures and warning messages;
• Hardware situation ;
• Existence of critical batch jobs;
64
Page 65
• Existence of critical processes;

• Availability of printer queues;
• Alarms;
• Networks;
• Component availability (server, router, etc.);
• Network load (eg, number of collisions);
• Transmissions;
• Applications;
• Monitoring of error messages;
• Response times;
• Number of concurrent users;
• General system availability for users.
NOTE: The parameters mentioned above are only examples and not a complete list.
11.4.6 Notification Mechanisms
Depending on the risk associated with the monitored parameter, mechanisms such as one or more described
below must be used to notify the main stakeholders about the exception conditions that have occurred:
• System console message;

• E-mail to the system operator;
• E-mail to external service providers;
• Printed lists or records;
• Visual or audible alarms.
11.4.7 Structure of the Monitoring Plan
The monitoring plan should cover the following areas:
• Monitored parameters;
• Alert limits;
• Observation frequency;
• Monitoring tool;
• Notification mechanism and person / system to be informed;
• Documentation of monitoring results;
• Results storage / retention period;
It is recommended to use a tabular format for plan documentation.
11.4.8 Review of the Monitoring Plan
The following items should be checked during the review of the monitoring plan:
• Whether the appropriate parameters and components are monitored;

• Whether the risks determined in the risk analysis are adequately addressed;
65
Page 66
• Whether the time intervals and alert limits for the monitored parameters are adequate;
• Whether notification methods are used and allow for timely alerting;
• Whether the results of monitoring are safely retained.
11.5 INCIDENT MANAGEMENT

11.5.1 Introduction
The incident management process aims to categorize incidents in order to target them
for a timely resolution.
There should be a procedure defining how problems related to software , hardware and
Operational procedures will be captured, reviewed, prioritized, rolled out, sized and
completed.
The primary objective of Incident Management is to ensure that any unplanned deviations that
impact on patient safety, product quality or data integrity
resolved before causing damage.
Incident Management must be designed so that the system / application / service is returned to the
user as quickly as possible. This process / procedure is usually somewhat generic and can be applied
to all systems.
Incidents should be assessed taking into account any impact on patient safety,
product quality and data integrity. The Quality Unit should be consulted to assist in the
definition of the acceptance criteria to be used in this assessment and to assist in the assessment of the incident.
The incident management process should ensure that operational events that are not part of the
standard operations (eg, deviations, problems and errors) are identified, evaluated, resolved and completed in a
timely manner. These activities must be documented.
It is the responsibility of the process owner to ensure that the incident management process and the
procedure are established to support the system.
It is the responsibility of the subject matter specialist (SME) to assess incidents and consult the
Quality on those that impact patient safety, product quality or
data integrity and take appropriate corrective actions.
It is the responsibility of the system owner to ensure that incidents are resolved and completed when
applicable.
It is the responsibility of the Quality Unit to ensure that the procedures associated with management
incidents are followed and that appropriate actions have been taken and documented.
Incident management activities involve performing the following actions:
66
Page 67
• Identify and record the incident;

• Assess the incident. The result of this assessment can be one of the following options: there is no need
of taking action; taking action according to a pre-established procedure; forward to
superior skills;
• Problem resolution and incident report preparation;
• Conclusion / closure of the incident.
11.6 CORRECTIVE AND PREVENTIVE ACTIONS (COVER)

11.6.1 Introduction
CAPA activities involve the process of investigating, understanding and correcting discrepancies based on
in the analysis of the root cause, in order to avoid its recurrence.
In the operational environment, CAPA activities related to computerized systems must be part of
CAPA's general system of activities for the other areas. When incidents occur, or when
opportunities to reduce system failures are identified by other means, corrective actions and
preventive measures must be identified and processes must be established to ensure that CAPA's are
effectively deployed.
The CAPA process is strongly associated with the Incident Management process and the
Repair.
The CAPA process is usually generic, that is, a process can be applied to all systems. THE
regulated company should assess whether to maintain a CAPA record for all systems or a record for
groups of similar systems or a record for each system.
Any corrective or preventive action taken to eliminate the causes of actual or non-compliance
potential must have a degree according to the magnitude of the problems and proportional to the risks
found.
CAPA's records must be subject to periodic internal audits.
The CAPA process must cover:
• Corrective actions for an identified problem or a potential problem;

• Determining the root cause and taking corrective action to potentially prevent recurrence of
a similar problem;
• Preventive action to prevent the recurrence of a similar potential problem, when appropriate;
• Evaluation of the effectiveness of the actions taken.
A procedure should be established to record and analyze incidents and allow corrective action
be taken. These activities must be documented.
It is the responsibility of the process owner to ensure that a CAPA process is implemented for the system
computerized and that responsibilities are delegated to the system owner.
67
Page 68
It is the responsibility of the Quality Unit to ensure that CAPA procedures are followed and actions
appropriate measures have been taken and documented.
It is the responsibility of the subject matter specialist (SME) to ensure that the corrective and preventive actions agreed
carried out and completed.
CAPA activities involve the following actions:
1. Problem identification and registration;

2. Determination of the emergency action to be taken;
3. Determination of the probable root cause. This activity can start from the immediate correction of the
problem. It usually involves a multidisciplinary team;
4. Determination of Preventive Action. This action may involve Documentation Management,
Change Management, Training, Support and Administration;
5. Record of the result obtained. A rationale should be written if no action is taken.
power plug;
6. Assessment of the success of the Corrective Action and / or Preventive Action performed (s).
11.7 MANAGING CHANGES AND SYSTEM CONFIGURATION

11.7.1 Introduction
Change management is a critical and fundamental activity for maintaining compliance with
systems and processes. All changes proposed during the operational phase of the system, be they
related to software , hardware , infrastructure or system usage, should be subject to a process
formal change control. This process should ensure that the proposed change is adequately
revised to assess the impact and risk of its implementation. The process must ensure that changes
are properly evaluated, authorized, documented, tested and approved before their implementation
and duly completed.
Some activities such as system replacements and administrative tasks must be covered by
repair and system administration processes.
Change management should provide a mechanism for prompt implementation of improvements

processes and systems based on periodic review and evaluation, operational and
performance and analysis of the root causes of failures that occurred.
Configuration Management includes those activities necessary for the precise definition of the system
computerized at any point in its life cycle, from the initial stage of development to its
retirement.
A configuration item is a component of the system that is not changed as a result of an operation
normal system. Configuration items can only be changed through a management process
of changes. There must be formal procedures in place to identify, define and establish the items of the
initial configuration and to track and record changes and releases of configuration items, including
updates and packages.
68
Page 69
Configuration Management and Change Management are closely related. When

changes are proposed, both activities need to be dealt with in parallel, particularly during the
assessment of the impact of changes.
Both activities must be applied to the complete scope of the systems including the hardware components
and software and associated documentation and records, particularly those with an impact on BPx.
Change management should continue until the system is retired. If the data is kept after
of the retired system, the management of this data must be subject to change control.
All changes must be reviewed, assessed for risk and impact, authorized, documented,
tested and approved before deployment.
The hardware and software configuration must be documented throughout the system's life cycle. The level
detail should be sufficient to allow the system to be rebuilt in the event of total loss of
system.
Tests to verify changes must be proportionate to the risk to patient safety, quality
product integrity and data integrity.
It is the responsibility of the Process Owner to ensure that a change management and
configuration is deployed.
It is the responsibility of the Quality Unit to ensure that the existing procedures for these activities
followed.
It is the responsibility of each member of the team associated with each change to play their part in the
correct way.
11.7.4 Change Management
This activity follows the same guidelines followed by other areas relevant to Good Manufacturing Practices.
However, specific processes or variations of the standard process may be necessary for the following types
of changes:
• Substitutions for similar components;

• Changes in system administration;
• Emergency changes;
• Temporary changes;
• Global changes.
The performance monitoring data of the system can cause a change proposal, and may
these data are used to support risk and impact assessment and the proposed change.
69
Page 70
11.7.5 Configuration Management
Configuration management during the operational phase should begin with the configuration called
baseline (initial) and associated configuration management records. This information should
be part of the system delivery stage by the validation team for the operational environment (routine).
Configuration Management consists of the following activities:
• Configuration Identification - WHAT must be kept in control;

• Configuration Control - HOW to perform the control;
• Configuration Status - HOW to document the control;
• Configuration Evaluation - HOW to check the control.
There should be a standard operating procedure involving the activities, responsibilities, procedures
and schedules related to configuration management during the operational phase of the system.
Configuration management and associated records are an essential part of recovery activity
disasters, where the system and its components can be correctly reassembled and integrated for the
operational reestablishment of the computerized system.
11.7.6 Configuration Identification
The components of the systems subject to configuration management must be clearly established.
The system must be broken down into configuration items, which must be identified during the
definition of specifications and development.
A configuration item is a component of the system that does not change as a result of an operation
normal system. Configuration items should be modified only by applying
changes. Examples of configuration items are: application software ; embedded software ,
hardware and system documentation.
The formally established list of configuration items and their versions are referred to as configuration
baseline ( Configuration baseline ).
11.7.7 Configuration Control
Changes to the configuration items must be coordinated and controlled. This includes the following activities:
• Version control;
• Change control;
• Configuration item storage;
• Delivery control.
A unique name and version number must be used to identify each configuration item.
Change control must be applied for each configuration item. Changes in hardware , software and
configuration must be carried out by authorized persons and controls must be maintained.
70
Page 71
11.7.8 Configuration Status
There must be documentation showing the status and history of the configuration items. Such documentation
it should include: details of the changes made; latest version numbers and release identifiers. This
shows that the system specifications are reviewed, updated and approved.
This activity can be performed in several ways, including through a document with version
controlled by describing the baseline configuration or by using automated tools.
11.7.9 Configuration Evaluation
All documented activities must be subject to management to ensure that the situation of the
system is accurate and up-to-date and provides a source for auditing system configuration management.
The periodic review of systems in operation should include checking that current information about the
system configuration is correct and accurate.
Change and configuration management activities involve performing the following actions,
only items 2, 4 and 6 are related to configuration management, specifically:
1. Proposal for change - record the details for the motivation of the change and prepare the requirements
from the user to the proposed change;
2. Assessment of the impact of the change - identification of regulatory and record impacts; identification
the configuration items (system components) affected;
3. Decision on the proposal - accept or reject;
4. Process development - Includes: software , hardware and documentation update;
5. Test of the implanted change;

6. Approval and implementation - Items to be considered: training; updating processes
business and communication;
7. Closure.
Records of activities associated with change and configuration management should be subject to
periodic internal audits.
11.8 SYSTEM REPAIR ACTIVITIES

11.8.1 Introduction
System Repair is the activity that consists of managing repairs or replacing components
failures or defects. The repair object can even be a configuration item. It is a way of
change control in which the relevant specifications are not changed.
Repairing or replacing components of computer systems that fail or fail,

generally related to hardware or infrastructure, must be managed according to a procedure
defined. Such activities should be authorized and implemented only within a context of
change control management.
71
Page 72
Many repair activities are emergency and require quick resolution. Therefore, the
incident management and change control should be structured to allow such
activities can occur without delay or without increasing the risk to the operational integrity of the system
computerized.
The repair process can be integrated with the change and configuration management process, but it is
a more simplified route can be used.
When failure (or repair) could impact patient safety, product quality or integrity
data, then an incident management process must be initiated.
Repair or replacement records must be subject to periodic internal audits and their review must be
form part of the performance management process.
The procedures to be followed in case of system failure or defect must be established, approved
and verified.
Any failures and corrective actions taken must be recorded.
A procedure should be established to record and analyze errors and allow corrective actions to be taken.
sockets.
These activities must be documented.

It is the responsibility of the system owner to identify those components that are eligible for repair or
replacement. Relevant information obtained in the design / validation phase may be available before and after
delivery of the system, such as a list of spare parts for when the system is to be made
operational.
It is the responsibility of the system owner to ensure that procedures are followed.
It is the responsibility of the team performing the repair (or replacement) to carry out the procedure
complete and accurate, including record updates as needed (eg record book).
It is the responsibility of the Quality Unit to ensure that repair procedures are followed and
appropriate actions are taken and documented.
Incident management activities involve performing the following actions:
1. Fault identification (may be via incident management);

2. Impact assessment - identification of the impact on regulated processes and records; identification of
configuration items (system components) affected; definition of test documents and requirements;
3. Evaluation and determination of the action to be taken - repair or replacement;
72
Page 73
4. Perform repair or replacement - including hardware and updating documentation and books
of records;
5. Verification of repair or replacement;
6. Return to use - communication to users.
Note: Items 2 to 6 should include configuration management.
11.9 PERIODIC REVIEW

11.9.1 Introduction
Periodic reviews are used throughout the operational life of the computerized system to verify
that it remains compatible with regulatory requirements, fit for the intended use and meets the policies
and company procedures. Reviews should confirm that, for system components, support
necessary and the expected maintenance processes and regulatory controls (plans, procedures and
records) are established.
Periodic reviews should be:
• Scheduled at appropriate intervals consistent with impact and the operational history of the system.
Risk assessments should be used to determine whether systems are in scope and whether the frequency
to perform the periodic review is adequate;
• Executed according to a pre-defined procedure;
• Documented and with traceable corrective actions.
The periodic review process must be generic and applicable to all systems.
It may be useful to develop checklists for carrying out reviews.
A process for defining the time and scheduling periodic reviews must be defined. The periods
for review of systems should be based on the impact of the system, its complexity and innovation. At
risk-based decisions must be documented.
Problems encountered during the review should be documented, along with corrective actions
sockets. The major implications related to these corrective actions should be assessed.
Corrective actions must be resolved and approved.
It is the responsibility of the process owner to ensure that periodic reviews are conducted and that
appropriate responses to the conclusions of the review were given.
It is the responsibility of Quality Assurance to ensure that periodic reviews are scheduled,
executed and documented.
73
Page 74
The review should be conducted by one or more people depending on the scope of the review. Participants can
include: Quality Unit; the Subject Specialist; users; Information technology; Engineering;
Regulatory Affairs. The conclusions must be documented.
11.9.4 Schedule for Review
Frequencies for periodic reviews should be based on the impact of the system, its
complexity and innovation.
Acceptable methods include:
• By systems, the frequency being defined in the respective system validation reports;
• Based on regular reviews and analysis of the systems inventory;
• Based on specific events, whether planned or not;
• Based on the number and complexity of change requests.
Whichever method
top management of (or
the combination of these)
regulated company andis the
chosen, thisfor
criteria must be documented
decision and approved
and responsibilities mustby
bethe
clearly
defined.
11.9.5 Reviewing a System
11.9.5.1 Preparation
Relevant information should be available for the review, such as:
• System documentation, including: plans, specifications, tests, reports, traceability,

risk management documentation, project reviews, user manuals, training materials
and records;
• Standard Operating Procedures for operation and maintenance;
• Configuration management information;
• Change management information;
• Incident records;
• Security and access control information;
• Reports of any previous audits of individual systems;
• Validation Report.
The objectives, the team and the agenda for carrying out the review must be defined. The review team must
ensure that the necessary reference material and people are available and that the process owner
is committed to the results of the review.
11.9.5.2 Conducting the Review
Problems encountered during the review should be documented, along with corrective actions
recommended. Depending on the management process created by the company, an audit of
follow-up can be scheduled.
When setting the agenda for the review, the following points should be considered:
74
Page 75
• The documentation must be complete, up to date and correct, including:

✓ Specification and verification;
✓ Operation and maintenance;
✓ List of configuration items.
• Records of any changes made to the system;
• The level of change made to the system and the nature of the change;
• Exceptional actions required by a Validation Report;
• Reports of previous audits and the respective actions taken;
• Any controls implemented to manage risks that are still in place
effective;
• Evidence of unstable or unreliable operation;
• Changes in the environment, process or business requirements, legislation or accepted best practices;
• Operational procedures;
• Business Continuity Planning;
• Personnel (including qualifications, training, experience and continuity);
• System security and access control;
• System maintenance and incident records;
• Backups of software and data.
Review activities involve the following actions:
1. Definition of the policy and process for establishing time and scheduling reviews
periodic - Can be system specific, defined in the respective Inspection Reports; defined in the List
Computerized Systems Inventory, based on triggers or events;
2. Preparation for conducting the review - Evidence may include plans, records of
previous incidents / changes, audits or reviews;
3. Performing the review;
4. Documentation of the results of the review;
5. Execution of Corrective Action, if applicable.
11.10 BACKUP AND RESTORATION
11.10.1 Introduction
Backup is the process of copying records, data and software to protect against loss of integrity or
availability of the original. Restoration is the subsequent restoration of records, data or software when
requested / required.
Backup and restore should not be confused with archiving and recovery.
75
Page 76
Procedures must be in place to describe and discriminate against backups of records, data and software ,
carried out routinely, to a safe storage location and adequately separated from the place of
primary storage. The frequency of running the backup procedure should be based on a
risk assessment.
Written procedures must be in place to ensure the restoration and maintenance of records and data
relevant to GMP, in the event of failure.
The backup procedure , storage facilities and media used must ensure the integrity of
Dice. There should be a record of the backup performed, with references to the media used for storage.
The storage medium used must be documented and justified as to its reliability.
Backup processes must be verified when they are established. Additionally, there must be
procedures and plans for regular testing of the ability to perform backup and restore.
These actions must be documented.
The process owner is responsible for:
• Definition of the data that need backup , including the data relevant to GMP;
• Definition of availability and access control requirements for GMP-relevant data.
The system owner is responsible for:
• Ensure that the organization of the backup and restoration of the software for the operating system is
defined meet the applicable regulations, in accordance with the Quality Assurance guidelines, when
applicable;
• Ensure proper backup and restore performance of software and data for the system
operational;
• Ensure appropriate access controls.
11.10.4 Backup and Restore Process
11.10.4.1 Backup Media
The backup must be performed on suitable media and it must be used according to the recommendation of the
manufacturers
When selecting and using storage media, the following points should be considered:
• The average life expectancy;

• The acceptable environmental conditions for its storage;
• Requirements for verification, renewal and overwriting.
Guidance on storage, transport and maintenance of various types of media, magnetic and optical,
used in data storage are generally available in the documentation provided by the manufacturer
of product.
76
Page 77
11.10.4.2 Backup of the Operating System
The backups of software are designed to ensure that the latest and correct version of the software is available
and can be restored in a short time and without error, in case of failure or after changes made
during development.
All software components required for the operating system must be included in the scope of the
backup to ensure that the entire system can be restored.
The process backup of the software should be defined and documented. This backup can occur:
• After any modification of the software , in which case backing up the components
modified software may be sufficient. This activity should be documented as part of the control
of changes;
• At regular intervals (eg annually) as a full backup , based on the risk and nature of the
business.
Backup copies must be stored in a safe place.
Backup media must be physically safe and protected from fire, water and other hazards. The process of
storage, standards and access must be defined and documented.
At least two generations of backup copies must be stored: the current one and the one before the last change
fulfilled. Based on the risk, it may be advisable to keep more generations to avoid the possibility of
propagation of errors in all available backup copies .
The following data must be clearly associated with the backup media , either on the label or in a
record, in a traceable manner:
• Creation date;
• System designation;
• Software designation ;
• Model and / or software / firmware build number ( build number ), if applicable;
• Current number (generation and possible multiple backups );
• Reason for backing up the software;
• Backup date ;
• Identity of the person who performed the backup .
Backups of the software should be performed while the system is operating. Backup logs
performed must be maintained. Backup and restore instructions should be stored
securely together with the backup media .
Risk-based and process backup , the transactions backup should be reviewed periodically and
Backup restoration should be periodically performed to verify that it will work correctly when
required.
11.10.4.3 Backup of Data
Electronic data relevant to GMP must be kept secure for the defined retention time.
While data is often kept on a hard disk using redundancy concepts or
77
Page 78
mirrored disks, additional backups of GMP-relevant data form a key part of preventing
loss of data in case of system failure. The data must be recoverable in a short time and
without error and copies kept remotely to avoid loss due to some common failure in one location (eg
fire). The type and frequency of the backup should be based on risk.
The data must be periodically saved on the backup media . The system owner must establish and
document the organization of data backups , covering the following aspects:
• Backup types (full or incremental);

• Interval: daily, weekly, monthly, quarterly, annual or non-cyclical (permanent retention);
• Number of generations. The number of generations defines the number of identically performed backups that
are maintained. Since backup media is often reused, after the number of generations has been
reached, subsequent backups will be overwritten over the oldest backup . For example: if the number of
generations set to four, the fifth backup will overwrite the first, the sixth will overwrite the second and
so on;
• Backup failure - Actions to be taken in case of backup failure must be established, such as
such as a repeat backup during the day. Actions taken in the event of failure should be documented
(eg, logbook) by the person responsible for the computerized system;
• Backup Media Labeling . The following items must appear on the media label, or registered at
record book: system designation; software / data designation ; version and / or build number
the software / firmware (if applicable); creation date; date of first use; current number (generations, possible
multiple backups); backup date ; reason for backup and operator identity;
• Duration of use. The media should only be used for as long as it is guaranteed;
• The type of media used must be documented;
• Storage Location. Storage locations must be safe and properly identified
and traceable;
• Data Backup Tools and Corresponding Procedures. GMP-relevant data should
be stored in an appropriate way that allows their restoration. The location and name of the procedure
control must be documented. Procedures must cover restoration, verification activities
and restart after system failure;
• Data Backup Review . The process owner, or delegated person, is responsible for ensuring
successful backup . Faults should be investigated and defective storage media
potentials must be discarded and replaced. The actions must be documented in a record book.
11.10.4.4 Restoration
Written and tested procedures must be used to perform the restoration. When the restoration
is performed manually, this must be registered and signed.
The process owner, or delegated person, must authorize the restoration of data. These people are the
responsible for ensuring that the restoration procedure is in compliance with the regulations of
Good habits.
If the restoration is motivated by technical reasons, the owner of the process and the owner of the system must make a
assessment of the process and possible risks. The restoration method used and the control of the
restoration must be documented.
78
Page 79
11.10.4.5 Long Term Integrity
Electronic storage media degrades over time, therefore, media reuse

it must be carried out according to the manufacturer's guidelines regarding its useful life.
In the unlikely event that a backup copy will be kept for a period approaching the end of its life
media, the integrity of the backups contained on the media should be reviewed according to the specifications
manufacturer. It is preferable to copy the data onto new media rather than review the old media.
The procedures for backup and restore must be checked periodically. The frequency should be
based on risk. This verification can be performed by means of restoring the backup to a backup system.
test and verifying its correct operation.
A common and pragmatic approach is to combine verification of the backup process with testing
disaster recovery. The restoration of the backup to the system running in production, with the purpose
testing is not recommended, as an error in the procedure can result in data loss.
The procedures backup and restoration should be checked during the periodic review of the system. At
conclusions must be documented.
The activities backup and restoration involve performing the following actions:
1. Risk assessment, taking into account the probability and risk of damage occurring;
2. Definition of the strategy for carrying out backup operations , covering: frequency, location of
storage, required response times, retention period and storage media;
3. Development of written backup and restoration procedures, covering:
responsibilities, training and documentation;
4. Definition of test procedures and plans to verify backup and backup operations
restoration;
5. Execution of tests, documenting the results and actions taken;
6. Execution of backup operations according to established procedure;
7. Monitoring the system during its operational life.
11.11 BUSINESS CONTINUITY PLANNING / DISASTER RECOVERY
Business Continuity Planning consists of a series of activities and related processes

with the guarantee that the regulated company is fully prepared to respond effectively when
failure and disturbance.
Critical business processes and systems that support these processes must be identified and their
associated risks should be assessed. Plans must be established and exercised to ensure the timely
and effective resumption of these processes and critical systems for the business.
The Business Continuity Plan defines how the business can continue to function and how to deal with
data after failures occur. Defines the steps required to restore business processes
after the occurrence of a disaster and how the data generated during the occurrence of this event should be
79
Page 80
managed. It also identifies the triggers for invoking the Plan, roles, responsibilities and
necessary communication.
One of the activities carried out during the performance of the Business Continuity Plan, involves the creation of
approved and trained / exercised plans for systems recovery in the event of a
disaster. These plans should be detailed with respect to the precautions to be taken to minimize
effects of a disaster, allowing the organization to continue or quickly return to its critical functions.
There should be a focus on disaster prevention, for example, with the provision of redundancy for
critical systems.
Patient safety, product quality and data integrity cannot be compromised by

computer system crashes or crashes.
The regulated company must carry out business continuity planning to actively protect its
ability to supply their products to the public and meet regulatory requirements.
The Business Continuity Plan must provide alternative procedures or processes to be

implemented to replace functionality missing from some system and allow for safe continuity
during the failure.
Business Continuity Plans should include provision for testing. Alternative processes
defined by the Business Continuity Plan must be properly documented and staff
involved properly trained.
Regulated companies must be able to demonstrate that they can ensure that critical and
processes can continue and that there is a timely resumption of essential business functions.
Business Continuity Plans and their tests must be subject to periodic internal audits.
It is the responsibility of the company's top management, including process owners, system owners and the
Quality Unit, ensure that appropriate Business Continuity Plans are in place,
periodically tested and once started, be followed, documented and communicated.
It is the responsibility of the process owner and the system owner to ensure that recovery plans are
appropriate disaster systems are in place for the systems to support the Plans for
Business Continuity.
Planning for Business Continuity and Disaster Recovery activities involve

carrying out the following actions:
1. Establishing the need for planning and management for business continuity,
including Disaster Recovery Planning, identifying key processes and services for the
business. Obtaining support from senior management;
80
Page 81
2. Risk assessment and analysis. Determination of adverse events and damages that may adversely
affect the organization. Evaluation of the severity of each event and the probability of its occurrence;
3. Definition of strategies for Business Continuity. Selection of alternative strategies for
recovery, while maintaining the organization's ability to perform its critical functions;
4. Development of the Business Continuity Plan. Identification of roles and responsibilities,
organizational resources and the triggers that can cause the use of the Plan and its escalation;
5. Implementation of the Business Continuity Plan;
6. Maintenance and Testing. Pre-planning and coordination of trials, documenting and evaluating
the results of each test, incorporating the lessons learned within the Business Continuity Plan.
Maintenance of the Plan's timeliness and its capability according to the company's strategy and requirements
regulatory requirements. Publication of test results to key stakeholders.
11.12 SYSTEM SECURITY MANAGEMENT
System security management is the process of ensuring reliability, integrity and

availability of the regulated company's systems, records and processes.
Effective security management protects the company's computer systems so that

minimize business impacts caused by security vulnerabilities and incidents.
Measures must be put in place to ensure that the computerized systems of regulated companies and
your data is adequate and protected against accidental or intentional loss, damage or unintended changes
authorized.
Such measures should ensure continuous control, integrity and availability and, where appropriate,
confidentiality of regulated data.
This process should include:
• Establishment and maintenance of roles and responsibilities, policies, standards and procedures
security-related;
• Periodic safety monitoring and testing, for example, manual book verification
system access, automated notifications of system access locks, token testing and so on
onwards;
• Implementation of corrective actions for identified weaknesses and security incidents;
• Ensure that there is a list of people authorized to access the system.
The design of the physical and technical safety mechanisms should be evaluated and, if necessary, tested.
Records associated with system security must be subject to periodic internal audits.
81
Page 82
Responsibility for the security of the system, including access control, should be agreed between the owner of the
process and the system owner.
It is the responsibility of the Quality Unit to ensure that safety procedures are followed.
The computer system user is responsible for meeting the security requirements defined
while using the computerized system.
11.12.4 Principles
Security management measures should be planned and implemented based on the following
considerations:
• System impact - assessment of the risks associated with the system;

• Awareness of employees - training of users;
• Incident management - records and actions taken to resolve incidents;
• Information security policy - physical security; security of access to the system; access by
the 3rd; electronic messaging systems; shared network resources; internet access and use;
use of mobile computing resources; connectivity to external computer systems; policies
antivirus and intrusion detection.
11.13 SYSTEM ADMINISTRATION
System administration involves routine systems management and support to ensure that they are
are operating efficiently and effectively.
System administration tasks must be identified, documented and supported by

control procedures.
System administrators must be trained and have their competence evidenced in the execution of the
activities. System administration tasks must be segregated from operational activities
related to the system.
Any system-related activities that are covered by standard operating procedures

need to be subject to change and configuration management.
System administration tasks must be subject to periodic internal audits.
82
Page 83
The process owner has overall responsibility for ensuring that the system is used and maintained in a
through detailed work instructions and procedures.
It is the responsibility of the system owner to ensure that tasks delegated to the system administrator
are clearly identified and documented. The system owner and the system administrator can be
the same person.
System administration activities involve performing the following actions:
1. Establishing the needs and scope of system administration activities

computerized;
2. Establishment of the support schedule for regular activities (daily, weekly, monthly, etc.);
3. Identification of tasks related to system administration, which can be motivated by the
Incident Management process;
4. Establishment of standard operating procedures for system administration.
11.14 RECORD MANAGEMENT (RETENTION, ARCHIVING AND RECOVERY)
Records retention policies should be established, based on a clear understanding of the

regulatory requirements, corporate policies and existing guides. Archiving requirements are
relevant to any registry that needs to be removed from operating systems before the end of its
defined retention period.
Archiving is the process of removing records and data from the computerized system and placing them in a
different location or system, often protecting them from further changes. Can also be
it is necessary to retain on file the applications that support records and data.
Archiving and retrieval procedures should be established on the basis of a clear
understanding of regulatory requirements.
Archiving and recovery should not be confused with backup and restore.
Archiving must be subject to periodic internal audits.
GMP-relevant records and data must be physically and electronically insured against accidental damage
or willful, for the entire required retention period.
The roles, responsibilities and procedures for filing and retrieval must be defined, and
there should be a standard operating procedure that describes the archiving strategy.
83
Page 84
Records and stored data should be initially and then periodically checked for their
accessibility, durability, accuracy and completeness, based on a risk analysis, taking into account
considering the type of storage, the media and the method of access.
Archiving processes must ensure that the content is preserved. Records with approvals
required by GMP regulations must ensure that the validity of approval is maintained throughout the
archiving period.
Regulatory agencies must have access to GMP records during an inspection, within a specified
period. Readable copies of archived records must be available on request.
It is the responsibility of the process owner to ensure that a filing process / procedure is
established.
It is the responsibility of the Quality Unit to ensure that the filing process / procedure is
followed.
The person performing the archiving is responsible for receiving from users the records to be archived,
keeping these records in the state in which they were received and returning them in the same state.
The system owner is responsible for maintaining or updating the systems necessary to access the records.
11.14.4 Archiving and Retention
The filing procedure should provide controls for:
• Ensure secure storage facilities;

• Check and maintain archived records for the entire retention period, that is, to manage the
aging of storage media;
• Provide indexing capabilities;

• Detect the end of the intended retention period for specified records and notify management
when appropriate;
• Provide management with the option of extending the retention period;
• Ensure that any changes to the records are carried out under change control;
• Destroy records securely when proper authorization is given;
• Ensure that the technology for reading archived records remains available throughout the
retention period.
If the archiving process is computerized, the system must be validated. This system of
automated archiving of records should:
• Ensure that data is backed up at regular intervals. The data from the
backup files must be stored for the retention period, in a separate secure location;
• Ensure that the system and its content are secure;
• Allow verification of the accessibility, accuracy and completeness of the records, after the
making changes related to hardware and software ;
• Have the ability to keep track of changes in records;
84
Page 85
• Ensure that the system and its contents are safe, keeping its meaning preserved;
• Consider the continuous availability of devices and software needed to access the records.
11.14.5 Recovery
Retained records must be readily recoverable for business and regulatory purposes. The process
recovery should be documented and consideration should be given to the following points:
• There must be formal authorization to access the retained records;

• There must be the ability to access online and offline electronic data, if applicable;
• There must be an ability to obtain hard copies and readable electronic copies of the data
electronically stored;
• There should be a means to recover any registration required by regulation after retirement from
a system regulated by GMP;
• There should be a periodic recovery exercise or verification process to check your
continuous operation.
Archiving and Recovery activities involve the following actions:
1. Identification of records and data relevant to GMP;

2. Definition of the retention policy for these records and data;
Definition of the archiving strategy, covering frequency, location, time required for
3.
response, retention period, means of retention, responsibilities, training and documentation;
4. Implementation of the filing strategy;
5. Verification of archiving activities, documenting results and actions taken;
6. Renewal or regeneration of results and archived data;
7. Monitoring the continuous availability of results and archived data;
8. Record of destruction according to the retention policy, in case of eventual retirement of the
system.
12 DATA MIGRATION
12.1 INTRODUCTION
This section covers procedures related to the planning, execution and verification of
data migration.
It does not cover the transfer of data from one system to another, within a business process in
progress. Such a situation must be addressed through typical specification and verification activities.
Data migration is an activity that can often occur during the life cycles of systems
computerized systems used by regulated companies.
85
Page 86
Data migration is the activity of transporting electronic data from one system to another, or simply
the transition of data from one system to another.
Some examples of data migration are:
• An update to an existing version of a database or application;

• Data conversion (eg, from a supplier's database to another);
• Migration within the same system (eg, transporting data from an application on a
server to another);
• Migration from a source system to a target system;
• Migration from multiple source systems to a target system.
The complexity and risk involved in the data migration effort can increase significantly if,
rules are used to select a subset of data from the source system or if data is
transformed (eg, data type conversion; filtering; cleaning; aggregation; normalization) before being
inserted into the target system. The ultimate goal of any data migration is to obtain data that
remain usable and retain their contextual meaning. Quality management controls
must exist to ensure that data migration efforts are successful, compatible and
repeatable.
Each data migration activity must be managed through a plan and report.
12.2 QUALITY MANAGEMENT
12.2.1 System Life Cycle
Data migration can occur many times during the life cycle of a computer system, in
following situations:
• During the development and initial deployment of the system;

• During application updates;
• During the retirement of the system.
As with other life cycle phases and activities, data migration activities will be more
consistent and successful if the life cycle contains procedures, tools, templates and examples of
data migration.
A complete life cycle should provide guidance for all aspects related to data migration,
including:
• Roles and responsibilities;

• Documentation requirements;
• Quality and compliance controls;
• Technical and verification activities;
• Project management.
A standard operating procedure is the best method for describing and documenting the process,
including quality and compliance requirements.
86
Page 87
12.2.2 Risk Management
The life cycle should include an established risk management process for assessing risks that
are specific to activities related to computerized systems. In addition to the risks
normally found in technological projects, the following items should be evaluated when carrying out
the migration of regulated data:
• The risk inherent in the quality and compliance associated with data migration, such as: the impact on
patient safety, product quality and integrity;
• The risk related to the business processes associated with the computer system involved;
• The risk to the business due to the system becoming unavailable or the migrated data is not reliable;
• The level of complexity (eg multiple sources or target systems; multiple phases; a lot of transformation
data);
• Technological risk due to the use of complex or cutting edge systems or tools.
12.2.3 Configuration Management and Change Control
The migration of electronic data in the regulated environment must be performed under change control.
Likewise, all documents and tools used in the data migration project must be
controlled using configuration management.
During the execution of the migration project, changes in the system not related to migration should be
prohibited. The reason is that the success of the data migration effort depends on several characteristics of the
systems (eg, software versions , database schemas) that must remain unchanged for
the project. These changes can increase the complexity of data migration and the project risk as
one all.
12.3 IMPORTANT POINTS
12.3.1 Suitability of the Software Tools to the Intended Use
Data migration typically involves using software tools to automate some

or all extraction, transformation, loading and verification activities. These tools tend to
belong to GAMP category 1 - infrastructure tools (eg, database migrators and
verifiers purchased from a software vendor ) or category 5 - custom applications (eg
SQL scripts, data migration robots, internally developed programs).
Infrastructure tools must be suitable for the intended use. The rigor of the activities of
related specification and verification must be proportionate to the associated risks. Depending on the scope,
complexity and customization of the software tools used, validation requirements may vary
from obtaining evidence of basic testing to preparing full
software and its formal verification.
The Subject Specialist (SME) should ensure that appropriate life cycle activities and objectives are
reached are identified and executed.
The Quality Unit must review and approve the key documentation, in accordance with the procedures of the
company.
For software tools that move or transform data, there are three main areas of risk:
87
Page 88
1. The data is moved or transformed incorrectly or incompletely;

2. The data already existing in the target system is damaged;
3. In case only part of the data is migrated, the residual data from the source system is
adversely affected by the removal of the migrated data.
It is important that a data mapping table (ie, fields in the model

source system data mapped to the target system data model), when using
software tools for migration.
12.3.2 Verification of Data
The data must be verified whenever they are moved or transformed. There are two general types of
post-migration verification of data: verification in a test environment and verification in an environment
operational.
In testing in a test environment, a target test system is initially filled with data, then a
migration test is performed and finally the data on the target system is verified to demonstrate that all
the data migrated successfully and without adversely affecting the existing data. This check provides
objective evidence that the software tool is suitable for its intended use and provides a level of
confidence about the migration process in general.
The intention of verification in the operating environment is the same: to verify the result of the migration process
both migrated data and existing data. The amount of data involved, however, is
usually much larger and therefore more difficult to verify. There are two general approaches to solving
this problem: data sampling and automated data verification tools.
In data sampling, a statistical sample of the population of migrated and / or existing data is
verified on the target or target system. Standards such as ANSI / ASQ Z1.4 and ISO 2859, can be used to
determine the appropriate sample size to verify the compliance of the entire data population
at the desired confidence level.
Automated software tools can be used to verify 100% of the data on the target system
or destination. However, these tools have a higher level of risk and consequently their
suitability must be strictly determined.
An important part of data migration is the confirmation that all necessary data has been
migrated. Verification techniques, such as checksum , can be used to corroborate the transmission
complete data.
Objective evidence of data verification must be generated. Check scripts and data sheets, copies
screens, error logs and paper reports should be created when appropriate and feasible.
12.3.3 Reliability of Source Data
If the source system is maintained in compliance with regulatory requirements, then the combination of
controls of the source system with the controls performed during the migration process should provide
sufficient guarantee of the accuracy and integrity of the migrated data.
To document this, the data migration plan must reference the appropriate system documentation
source.
88
Page 89
If the situation of the source system is unknown, then there are two problems: first, the veracity of the data
migrated from the source system may not be reliable; and second, the migrated data will mix with the
trusted data already in the controlled target system. After migration, existing data that is trusted and
unreliable data will be mixed and difficult to distinguish unless actions are taken to
identify the migrated data, such as: differences in registration dates and notes in defined fields
by the user. If this is not possible, then the possible data inconsistencies should be documented,
explaining the existing controls in the source system and the justification of why the migrated data should
be reliable.
12.3.4 Usability of Migrated Data on the Target System
There are three main problems to be considered, related to the usability of the data migrated to the
target system:
1. The functionality of the target system does not allow the performance of tasks previously performed in the
source system;
2. Lack of completeness of the migrated data affects the usability of the data;
3. It may not be enough to migrate the data. Separate migration of metadata or system configuration
destination may be required. For example, the source data has some access rights defined for it,
such as user groups and user rights. Data migration may not migrate this metadata,
which are normally separated from the data. However, these groups and user rights can also be
required on the target system.
12.3.5 Audit Trails ( Audit trails )
Audit trails can be problematic for the data migration process. If the target system
has an audit trail, but the source system does not, a document must be created reflecting that the
Auditing of migrated records started when they were transferred to the target system. If possible,
these records must be distinguishable from the records that were generated in the target system.
If both systems have audit trails and migration is feasible, the audit trail should be
migrated along with the audited data. If it is technically impossible to migrate the audit trail or
doing this would be a very big risk, the original audit trail should be archived in a format
that can be recovered over time.
Whenever possible, an audit trail created by the computer should be created during
movement and transformation associated with data migration, as this audit trail serves not only
as a verification tool, but also as a historical record of changes in data and should
be archived in a format that can be retrieved over time.
12.4 DATA MIGRATION PLAN
Different types of data migration require different activities and objectives. Each migration process
must have a data migration plan. This plan serves as a high-level roadmap that
guides the team that performs the migration to execute it properly.
This plan should describe the entire migration process, including:
89
Page 90
• Purpose and scope of the migration project;

• Description of the system (s);
• Roles and responsibilities;
• Objectives to be achieved;
• Risk management strategy;
•
Configuration management strategy, including source, stationary and
destiny;
• Overview and strategy of the software tool to ensure compliance and suitability for use
intended;
• Migration steps and technical activities;
• Mapping and data modeling activities;
• Transformation rules;
• Data verification strategy and acceptance criteria;
• Transition plan;
• Reversal strategy.
The migration plan must be approved by the process owner, system owner, Quality Unit and
Subject matter expert where appropriate.
There may be situations where the migration plan can be used more than once. When this occurs,
a data migration report must be generated.
12.5 DATA MIGRATION REPORT
The data migration report summarizes the activities that were conducted during the migration process.
Describes any anomalies or deviations that have occurred and lists the results of the verification activities, including
objective evidence, where appropriate.
Because the report is used to establish the reliability of the migrated data, it must declare
clearly the result of the migration activity.
The data migration report must be approved by the process owner, system owner,
Quality and subject matter expert, when appropriate.
In the event that the data migration activity is carried out as part of a system design
computerized, such as replacement or update, the report can be registered within the
project documentation and there needs to be a separate document.
13 RETIREMENT OF COMPUTERIZED SYSTEMS
13.1 INTRODUCTION
The system's retirement process must be documented through a retirement plan, which
usually receives contributions from the following actors: owner of the process, Quality Unit, owner of the
system and Information Technology.
90
Page 91
Process planning content can include:
•
Destruction and retention requirements for historical data or records;
• Identification of the current hardware and software configuration , as well as the systems they have
interface, equipment or instruments;
• Identification of any external systems that depend on the system's data or records.
The extent and accuracy of planning depends on the impact of the system and the risks associated with loss of
Dice.
The system's retirement plan must be approved by the process owner and quality unit.
13.2 SYSTEM RETIREMENT PLAN

13.2.1 Introduction
The introduction should include:
• Reference to policies, procedures, standards, guides and other documents.
13.2.2 Roles and Responsibilities
The roles and responsibilities associated with the retirement process must be documented in the plan, and
must include the owner of the process, the Quality Unit, the owner of the system, the retirement team and
its members and any other actors that contribute to the process.
13.2.3 Overview and Implications
Consideration should be given to the retirement effect of the system in some aspects, such as:
• Strategy - document the impact on the overall technology strategy and initiate any updates to the
documentation or other necessary actions;
• Process - describe the impact on supporting the business process after retirement;
• Technology - the scope and boundaries of the system to be retired must be determined and
documented, as well as the justification for retirement. Identify other systems, instruments or
equipment that has interfaces with the system that will retire. Data or information sources
can be located on multiple systems. Identify the infrastructure components (network, etc.) that
will need to be decoupled from the system;
• Personnel - describe the impact on users of the system.
13.2.4 Description of the Business Process
The pre-retirement business process must be documented and understood from the perspective of the process,
user and data / records. This helps to ensure that all impacts are identified and all
support and automation angles are translated into a post-retirement scenario.
91
Page 92
This future scenario must be documented and understood, especially with regard to changes in the process
and / or user and the location or effect on the data / records.
13.2.5 Approach to Retirement
The decision on whether to replace the system should be documented. If the system is replaced, the
retirement planning should be referenced and synchronized with the
substitute system. The approach for decoupling the interface , disconnecting the infrastructure, finalizing
or transition from technical support and any assumptions, exclusions, limitations or dependencies must be
documented.
13.2.6 Migration, Archiving and Destruction of Data and Records
The plan must identify what data should be migrated, archived or destroyed and the approval process
associated.
The approach to data migration and archiving should be determined based on the history of
access to data, the need for reprocessing, the risk level of registration and the robustness of the media
used. Controls should be established to ensure that data and records remain secure,
complete, accurate and that the signature / registration relationship is preserved, when applicable.
The approach must take into account the following aspects:
• If data are to be maintained, they must be backed up and stored, in accordance with
company data retention schedules and procedures;
• Before data is moved or archived from the system, the appropriate
data recovery must be available and tested;
• The archived data media must be stored and maintained in accordance with the recommendations of the
manufacturer and under the necessary environmental conditions;
• If data and records are migrated to a replacement system, the migration must be planned,
conducted and verified to ensure data integrity. Migration procedures should
be tested or confirmed before data is completely transferred out of the system;
• The methods to be used for migration / conversion and verification of data records must be
defined. This may include performing pilot work before actual data migration occurs, or
temporary parallel operation of both systems (new system and the system to be retired);
• If the data is going to be migrated to the replacement system, the testing strategy for verifying the
migration must be defined. If an automated migration or conversion is used, the approach to
ensuring their suitability for the intended use must be documented.
13.2.7 Approach to Verification
Verification documentation, necessary as part of the employee's retirement process, must be identified.
system.
13.2.8 System Maintenance and Discontinuation of Support
The necessary actions associated with (s) must be planned:
92
Page 93
• Modification or termination of internal or external support agreements;

• Operations, backup and restoration, disaster recovery and business continuity plans;
• Security, technical support and user administration and configuration management programs.
13.2.9 Change Management
Formal change management procedures must be followed for retirement from a system
computerized to ensure that the retirement process is controlled and managed.
Changes resulting from the retirement of the system must be addressed, such as changes in roles
support (technical support, super-users, etc.) and associated training.
The approach for communicating the impact of the system's retirement to the people involved should be
documented.
13.2.10 Timetable
The schedule should be documented and include individual retirement activities and
responsibilities, associated due dates and any other tasks, critical milestones and
verification.
13.2.11 Execution of Retirement
The timing of retirement execution must be carefully considered.
There should be plans for business continuity in case any problems occur during the
retirement or migration work. In addition, a backup plan is recommended and should include steps
detailed instructions or references to procedures for configuration and reinstallation to make the system
retired operational again if necessary.
13.2.12 System Documentation and Software
System and software documentation , including source code (Category 5), such as
life cycle, validation documentation, change history, standard operating procedures
related to the system and other system documents, must be defined. The documentation to be retained
must have a responsible owner and a designated safe location. Affected inventories, procedures and others
documents must be updated.
Decisions regarding the retention of specific software and documents should be based on their potential for
future use and in an assessment of the risk associated with its destruction.
13.3 SYSTEM RETIREMENT REPORT
After executing the system's retirement plan, a summary report should be generated to describe
execution and results obtained. If testing or verification activities are performed, the results
of these tests should be summarized and any deviations that have occurred should be discussed together with your
resolution. This report can also list all documentation related to the retired system.
93
Page 94
14. VALIDATION OF SHEETS

14.1 INTRODUCTION
Tools are available for creating a wide variety of applications for the end user,
including custom statistical analysis, local databases, filtering, data manipulation and analysis
multivariate. These applications can be used to carry out regulated activities, however these
applications tend to be the most under-documented within a GMP environment.
This Guide will emphasize spreadsheets as they are most often used in companies for
treatment of some data regulated by GMP.
The level and rigor of the specification and verification (validation) used in these applications will depend on the risk
involved, its complexity and degree of innovation. The guidelines described here are directed to spreadsheets,
but the same principles can be used for other types of applications for the end user.
14.2 TYPES OF APPLICATIONS FOR END-USER

14.2.1 Disposable Spreadsheets
They are spreadsheets used in the same way as a calculator, to perform calculations, and it is not
An electronic copy of this operation is maintained.
This activity must be documented in the same way that the calculator would be used, that is, the
values and results would be recorded and signed. Results can be printed, labeled and
signed. It should be clear on the record sheet exactly which arithmetic operation was performed. This can
be facilitated by printing a copy of the spreadsheet showing the calculation formula used. This copy
becomes part of the GMP record.
The calculations used for processing GMP data must be verified. This does not mean that
algorithms used by the spreadsheet's native functions need to be checked for accuracy, but
rather demonstrate that the correct formulas are being used. Ex .: (a + b) * c is different from a + (b * c), and this
it is a possible error to occur.
The verification of the algorithms can be carried out by printing the formula ( cell formulae ) or by
third party review.
14.2.2 Spreadsheets Retained as Documents
There are spreadsheets that are used as a word processor and not as a traditional application. The main
difference is that the spreadsheet can be used both to record BPF data and to manipulate it. Of that
Therefore, it is advisable to manage them as documents and not as applications. It is extremely difficult
establish that all copies saved later are the same as the originals. Calculations, therefore,
they should be checked and explained in detail, when they exist in a text document. This includes
evidence of the formula used, as described in item 14.2.1.
Unless the spreadsheet is properly controlled, printing on paper should be considered as the
master record.
There are a variety of options for obtaining adequate control of this type of spreadsheet:
94
Page 95
• Use of the spreadsheet's internal security options, such as cells or tabs protected by
passwords;
• Storing the spreadsheet in a secure directory;
• Spreadsheet management in an electronic document management system.
14.2.3 Spreadsheets Used as Database
These are spreadsheets used to manage or store GMP data electronically. The data can be
updated frequently, which can cause difficulties because spreadsheets don't have the controls
intrinsic features of relational databases, necessary to ensure data integrity.
Spreadsheets generally have limited or no capability to control data editing or to

support audit trails when needed. When creating a spreadsheet, controls must be developed
to overcome these deficiencies.
Users should therefore be fully aware of the limitations and vulnerabilities of spreadsheets
when proposed as an alternative to a database application.
Due to the limitations of spreadsheets, relational databases should be used instead of electronic spreadsheets,
since these are limited in terms of data storage and management and the file can be
corrupt when it reaches certain data values.
Although there are commercially available products designed to provide audit trail capabilities for
spreadsheets, as a general rule, the use of spreadsheets in which audit trails are
needed should not be used.
Spreadsheet software is generally not designed to provide audit trail functionality.

Therefore, the use of a database with this intrinsic capacity is preferable.
14.2.4 Template-Type Applications
A very common use of spreadsheets is the development of template- type solutions , where data
they can be subject to standard manipulation and the result saved as a single document. Applications for
performing statistical analysis or filtering and manipulating data may also belong to this sub-
category. The templates can be used for example for the tab and a data processing
clinical study or, similarly for tabulation and data processing of control test results
before the product is released.
When developing such templates , users and developers must fully understand and document the
necessary handling. This allows for clear confirmation of design intentions against package features
standards to be established and confirmed.
The following items should be considered:
• Calculations should be checked for accuracy;

• The template will run on a single workstation or available for download from a
single lease? If not, how can you be sure that all users will use the correct version? The control
version must be established, supported by an effective change management process;
95
Page 96
• How access to the application and data fields by users and the developer will be
controlled? Preferably all cells, except those used for data entry,
they must be blocked and inaccessible to the user;
• How will the features be configured? There is a requirement for a custom script when
application wizards are used? A “macro” is customized software . Even when created
by key capture, there is a program written in a language such as Visual Basic for Applications ® (VBA)
behind each macro;
• Will there be more than one module? Integration tests are appropriate in these cases. For spreadsheets this
may involve direct cell links to other spreadsheets. These links can be affected by changes and
should be addressed as part of change control.
• Will data entry be via keyboard only? External data feeds require
configuration and a spreadsheet may not be sophisticated enough to handle unusual entries (eg, a
string that is too long can be truncated and only part of that string is
imported);
• Will the output be saved to a file or just printed? Electronic record controls can be
necessary if the document is held electronically.
14.2.5 Desktop Database
Desktop Databases are those designed and installed on a workstation or

computer for routine use. These simple solutions are designed for the storage of small
amounts of data (eg MS Access).
The proprietary and open source desktop database offers solutions

for managing large volumes of data when compared to spreadsheets, but they still
are generally significantly less secure than more database management systems
sophisticated systems designed to run in environments based on dedicated servers and managed by
IT sector through DBA (eg Oracle®, MS SQL Server, etc.).
The use of these less secure banks can present significant risks to GMP-relevant records.
External controls are required to protect these records.
14.3 RISK-BASED APPROACH

Spreadsheets can vary significantly in risk and complexity. The following points should be
considered for this type of end user application:
• Risk assessment and appropriate risk control measures to manage the identified risks;
• The adoption of the most appropriate strategy to establish the stages of Specification and Verification of
spreadsheet, so that it is shown to work as intended. This strategy should
be based on:
✓ System impact on patient safety, product quality and data integrity
(risk assessment);
✓ System complexity and innovation (architecture and categorization of the components of the
system).
96
Page 97
• Proper security to mitigate the risk of unauthorized changes to data and data
spreadsheet;
• Change management application management.
The regulated company's policies and procedures should define its specific approach to obtaining and
maintenance of attendance and adaptation to the intended use of the spreadsheet.
14.4 USE OF GAMP CATEGORIES
The product on which the application (Spreadsheets, templates, etc.) is built must belong to Category 1. The
categories for spreadsheets and other end user applications range from Category 3 to 5.
The definition of the worksheet category depends on its complexity and innovation. It should be noted that a
spreadsheet that merely uses its tabular editing power and does not perform calculations should be considered a
document.
A spreadsheet that simply uses its original functions (averages, standard deviations) to perform calculations,
with no configuration, just acting as a calculator, it belongs to Category 3.
When the arithmetic functions of the spreadsheet are used, the calculations must be fully explained.
This includes verifying that the formula used has been used properly and that the results obtained
are correct. Such verification can be documented through the review and approval of the spreadsheet by a
second person. No additional verification is necessary, as there is no need to challenge the accuracy of
calculations.
A template- type spreadsheet in which the user inserts data that is automatically sent to another
cell where specific calculations are performed, belongs to Category 4, since the template is configured by
before use.
A spreadsheet that uses custom macros or other more sophisticated operations (e.g., editing code
source) belongs to Category 5.
For situations other than those mentioned above, consult the bibliographic references in this guide.
14.5 RISK-BASED CONTROLS
GMP risks must be assessed. The following aspects must be considered:
• The integrity of the data related to the control of the data files, since most of the
developed spreadsheets process data;
• The complexity of the spreadsheet, based on the assumption that undetected systematic errors are more
likely to occur in software not developed under a strict development method and that
more complex spreadsheets have more opportunity for errors to occur;
• The potential impact on patient safety, product quality and data integrity.
Based on these assessments, controls should be established with a focus on:
• Degree of verification;
• Security control (both for the spreadsheet code and for the BPx records that are in the
spreadsheet);
97
Page 98
• Change control;
• Control of the infrastructure on which the spreadsheet is built.
14.5.1 Degree of Verification
The extent and rigor of the verification depends on the risk, complexity and innovation of the spreadsheet.
Complex, high-risk spreadsheets require more rigorous testing. The number of logical branches
in the spreadsheet it is a good indicator of its complexity; if there are many logical functions (IF, AND, OR, etc.) or
Lookup tables, the complexity is greater. Although they are native functions, they introduce more paths
potentials within the spreadsheet and therefore more ramifications that require a more testing strategy
sophisticated.
Macros also increase the complexity of spreadsheets, because they are effectively secondary applications
embedded. Even when created using key capture, there is a program with a language for
behind the macro, although macros that simply automate a series of actions are less
worrying than those that contain logical ramifications. Macros must be challenged through
functionality tests. Macros that include logical paths should be subject to a more stringent
verification, with due attention to the multiple logic paths.
14.5.2 Security Control
Security considerations for spreadsheets are similar to those for applications on the network or
server, such as: access to the spreadsheet, access to data through the spreadsheet and access to data at the
operating system or spreadsheet code. Security within the operating environment must be appropriate to the
type of information stored or processed.
For many spreadsheets, a combination of infrastructure controls (eg, restricted access to directories) and
controls available on the spreadsheet (eg password protection for spreadsheet cells) can provide some
security against unintended changes. However, these controls can be inefficient to prevent
the spreadsheet creator makes changes outside of the change control process, particularly if the
spreadsheet to be located on an individual workstation. In these situations, the ideal is to place the
spreadsheet in a network environment in which the rights of all users, including the author, are limited,
also adding a regular scheduled backup process .
Often, data is saved within the spreadsheet itself. Ensuring the integrity of this data requires
the use of very strict controls, including any necessary controls on electronic records. In cases
where the spreadsheet is subject to some type of editing, proper control may involve the use of a
Electronic Document Management (EDMS). Alternatively, controlled copies can be kept
in a format that cannot be altered or printed.
GMP-relevant data cannot be saved to a local disk drive that is not secure and is not
submitted to performing backups ( backup ) regularly.
If the security level of the spreadsheet is not adequate enough for the data managed in it, the company
should seek an application that runs in a more robust operating environment.
98
Page 99
14.5.3 Change Control
Spreadsheets that process data relevant to GMP should be subject to change control. The management
versioning is difficult in the case of spreadsheets. In some cases, spreadsheet management within an EDMS can
be an appropriate solution, since this system maintains an audit trail of the spreadsheet versions.
Another solution is the use of library tools that are frequently used by
developers to manage code. These tools can be used to manage any type
files, can be effective, relatively easy to implement and are less expensive than a system like
EDMS.
As with any change control process, changes to the spreadsheet must have a record of
change that includes a description of the change and an impact assessment. Where appropriate, tests
associated with this function should be documented.
15.5.4 Infrastructure Control
Environments in which the spreadsheet is installed belong to Software Category 1 . These tools provide
application environment for spreadsheets, databases, scripts or scripts that are developed by users.
The installation of the environment must be verified and the environment must be managed for changes and for
your configuration.
14.6 APPROACHES FOR VALIDATION
Below are 05 (five) different applications for the end user, including the spreadsheet and a summary
of potential approaches based on considerations about the impact on GMP and the complexity of
application. They are illustrative examples and are not definitive.
14.6.1 Type A - Simple Spreadsheets for Calculations
Assessment: high impact and low complexity
Recommended approach:
• Preparation of the ERU (URS);

• Documented verification, carried out by a third person, that the calculations are correct;
• Security to ensure that it is protected from unauthorized change;
• Security to ensure that users can access only approved versions;
• Secure storage of the electronic document.
14.6.2 Type B - Training Record Worksheet
Evaluation: low impact and low complexity.
• No specific functionality requires specification and verification;
99
Page 100
• Standard controls for electronic documents containing evidence to meet GMP.
14.6.3 Type C - Desktop database
Assessment: high impact and medium complexity
• Typical Category 4 approach: validation plan; ERU / URS; Project / Functional Specification (can
be combined); traceability; documented tests, with pre-defined acceptance criteria; report of
validation;
• Security to limit access to authorized persons only;
• Change control.
14.6.4 Type D - Worksheets for Statistical Analysis - Clinical Study
Assessment: high impact and high complexity
validation;
• Change control.
14.6.5 Type E - Worksheets for Statistical Analysis - Clinical Study
Evaluation: low impact and high complexity.
• Documented verification, carried out by a third person, that the calculations are correct;
• Change control;
• Security to ensure that it is protected from unauthorized change;
• Security to ensure that users can access only approved versions.
14.6.6 Type F - Work Area Databases - Traceability of productive materials
Example of using this type of software : layout of printed labels.
Evaluation: medium impact and medium complexity.
100
Page 101
validation;
• Change control.
15 FINAL CONSIDERATIONS
For systems already installed, the company must decide whether the system can be validated or not.
The first step to be followed should be the preparation of the ERU / URS document starting from the guidelines
described in this Guide, similar to what would be done for the purchase of a new system.
The next step is the evaluation of this non-validated system using the ERU / URS document to decide
on whether the system can be validated or not. The impact of this non-validated system on the
integrity of the data generated; product quality and patient safety.
There may be situations in which the evaluated computerized system, with the appropriate mitigations, can be
validated. Otherwise, it is necessary to change the system.
16 GLOSSARY AND ACRONYMS
Antivirus - Software used to protect computers against malware . It also has the utility
decontaminate a computer that is infected with viruses, worm and malicious code. These programs
need to be updated frequently to ensure their effectiveness. There are corporate antiviruses , which are more
complete and effective, depending on the scenario, than the free antivirus.
Application - Software that makes use of network services such as file transfer, remote login and mail
electronic.
Backup - Security routine used for storage, that is, a copy of data or settings,
usually on removable media, all or part of the information on hard drives or the network. IS
a solution that can be adapted, according to the needs of the company.
ERP ( Enterprise Resource Planning or “ Enterprise resource planning”) - These are software that integrate
all the data and processes of an organization in a single system. Examples: Protheus, Focco, EMS, SAP,
Sige Cloud, Blue Account.
Firmware - set of operating instructions programmed directly into the hardware of a device
electronic.
Hardware - Generic designation of all types of computer equipment, that is, it is the physical part of the
computer. Examples: microcomputer, hard drives, memory, printer, scanner, among others.
LAN ( Local Area Network ) - It is a set of computers that belong to

the same organization and which are linked together in a small geographical area by a network,
often through the same technology (the most used is Ethernet).
Login - Identification (user name) for access to a specific computer or system.

101
Page 102
Data log - It is an expression used to describe the process of recording relevant events in a
computational system.
Malware ( Malicious Software or Software Malicious) - It is software designed to infiltrate a system

illegally using someone else's computer in order to cause some damage or theft of
information (confidential or not). Computer viruses, worms , trojan horses and spyware
are considered malware.
MAN - Company that has several offices in the same city and wants computers
remain interconnected. For this there is the ( Metropolitan Area Network ), or Metropolitan Network, which connects
several Local Area Networks within a few dozen kilometers.
Oracle - It is a DBMS (Database Management System) written in C language and available in several
material platforms.
Patch 1 - Piece of object code inserted in an executable program as a temporary correction of an error.
Patch 2 - Fix with patch 1 . Programming consists of repairing a deficiency in the functionality of a
existing routine or program, in general, in response to an unforeseen need or set of
operating circumstances. The correction by means of patches is a common way to add a
feature or function to a program while the next version of the software is not released.
PDF ( Portable Document Format ) - It is a file format created by Adobe Systems for
any document is viewed, regardless of which program originated it.
RAM ( Random Access Memory ) - It is the memory available for use by

applications and processing. Its volatile content is lost whenever the computer is turned off.
Network - Generically a set of connected computers that communicate with each other.
Disaster Recovery (DR) - From English Disaster Recovery . It involves a set of policies and procedures
to enable the recovery or continuation of vital technology and systems infrastructure following
a natural or man-made disaster.
Redundancy - It is a broad term that represents the duplication of critical components, adding
system reliability. In information technology the definition is applied more frequently as the
duplication of devices that are used for backup .
Server - It is basically a computer more powerful than the average desktop . It was developed
specifically to transmit information and provide software products to other computers that
connected to it by a network. Servers have the hardware to manage health
wireless network and ethernet cable, usually through a router. They were developed to handle
with heavier workloads and more applications, taking advantage of hardware
to increase productivity and reduce downtime.
SLA ( Service Level Agreement ) - Consists of a contract between two parties:

the entity that intends to provide the service and the customer that wishes to benefit from it. In it are specified,
in detail, all aspects of the type of service that will be provided, as well as the contractual terms, the
quality of service and the price to be paid for the work.
Software - It is a set of codes developed to perform specific functions, normally for the
user.
Template - It is a model to be followed, with a predefined structure that facilitates the development and creation
of content from something constructed.
102
Page 103
Viruses - Denomination given to small programs developed to cause damage at different levels,
affecting the integrity of data files (removing parts or files completely),
a particular computer or the entire company network.
WAN ( Wide Area Network ) - It is the type of network that allows the interconnection of local, metropolitan and
network equipment in a large geographical area (Example: country, continent, etc.).
Wireless - Technology capable of joining electronic terminals, usually computers, to each other due to the waves
radio or infrared, without the need to use connecting cables between them. The use of wireless technology
it ranges from radio transceivers like walkie-talkies to artificial satellites in space.
17 BIBLIOGRAPHIC REFERENCES
17.1 REGULATORY
• Resolution - RDC No. 69 of December 8, 2014;

• Resolution - RDC nº 301, of August 21, 2019;
• Normative Instruction - IN nº 43, of August 21, 2019;
• Normative Instruction - IN nº 47, of August 21, 2019.
17.2 TECHNIQUES
• GAMP 5 - A Risk-Based Approach to Compliant GxP Computerized Systems.

• PIC / S Guidance on Good Practices for Computerized Systems in Regulated “GxP” Environments (PI 011-
3) - September 2007 (available on the website http://www.picscheme.org).
• FDA Guidance for Industry Part 11, Electronic Records / Electronic Signatures - Scope and Application
(August 2003).
• Practical Computer Dictionary, Microsoft, 2000.
103
Page 104
104

Guide For Computer Systems Validation PDF

Uploaded by

Copyright:

Available Formats

Guide For Computer Systems Validation PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Guide For Computer Systems Validation PDF

Uploaded by

Copyright:

Available Formats

7/16/2020 Guide for Computer Systems Validation

Guide for Computer Systems Validation

National Health Surveillance Agency - Anvisa

Guide for Computer Systems Validation

Start of the contribution period: 4/14/2020

This Guide expresses Anvisa's understanding of best practices with respect to

It is a non-normative regulatory instrument, of a recommendatory and non-binding nature,

1. SCOPE ................................................. .................................................. ........................................ 5

2. INTRODUCTION ................................................. .................................................. ............................... 5

3. LEGAL BASE ................................................ .................................................. ................................... 5

4. CONCEPTS, TERMS AND DEFINITIONS ............................................. .................................................. ... 5

4.1 KEY CONCEPTS .............................................. .................................................. ....................... 5

4.2 KEY TERMS .............................................. .................................................. ........................... 7

5. LIFE CYCLE APPROACH ............................................. .................................................. ....... 9

5.1 INTRODUCTION ................................................ .................................................. .................................. 9

5.2 LIFE CYCLE OF COMPUTERIZED SYSTEMS ........................................... .............................. 10

5.3 COMPUTERIZED SYSTEM VALIDATION STRUCTURE ........................................... .......... 11

6. QUALITY RISK MANAGEMENT ............................................. ....................................... 13

6.1 INTRODUCTION ................................................ .................................................. ................................ 13

6.2 QUALITY RISK MANAGEMENT WITH SCIENTIFIC BASIS ......................................... ........... 14

6.3 QUALITY RISK MANAGEMENT PROCESS .......................................... ...................... 14

7. SOFTWARE AND HARDWARE CATEGORIZATION ............................................. .................................. 17

7.1 INTRODUCTION ................................................ .................................................. ................................ 17

7.2 USE OF GAMP CATEGORIES ............................................ ............................................. 17

7.3 SOFTWARE CATEGORIES .............................................. .................................................. ............. 18

7.4 HARDWARE CATEGORIES .............................................. .................................................. ............ 21

8. INVENTORY LIST ............................................... .................................................. ................... 22

9. VALIDATION OF COMPUTERIZED SYSTEMS .............................................. ............................. 22

9.1 INTRODUCTION ................................................ .................................................. ................................ 22

9.2 VALIDATION PLAN .............................................. .................................................. ..................... 24

9.3 DOCUMENT CONTAINING USER REQUIREMENTS SPECIFICATIONS (ERU / URS) ................. 27

9.4 SELECTION OF COMPUTER SYSTEMS SUPPLIER ........................................... ............ 32

9.5 DOCUMENT CONTAINING FUNCTIONAL SPECIFICATIONS (EF / FS) ....................................... ........... 33

9.7 TESTING PLAN FOR COMPUTERIZED SYSTEMS ........................................... ..................... 41

9.8 COMPLEMENTARY ACTIVITIES ............................................... .................................................. ..... 54

9.9 VALIDATION REPORT .............................................. .................................................. .............. 57

10. INVENTORY LIST ............................................. .................................................. ..................... 59

11. OPERATIONAL PHASE OF COMPUTERIZED SYSTEMS ........................................... .................... 60

11.1 INTRODUCTION ................................................ .................................................. .............................. 60

11.2 SYSTEM DELIVERY .............................................. .................................................. ................... 61

11.3 SUPPORT SERVICE MANAGEMENT ............................................ ....................................... 62

11.4 MONITORING SYSTEM PERFORMANCE ............................................ ............................ 63

11.5 INCIDENT MANAGEMENT .............................................. .................................................. .. 66

11.6 CORRECTIVE AND PREVENTIVE ACTIONS (COVER) .......................................... ......................................... 67

11.7 MANAGEMENT OF CHANGES AND SYSTEM CONFIGURATION ......................................... 68

11.8 SYSTEM REPAIR ACTIVITIES ............................................ ................................................. 71

11.9 PERIODIC REVIEW ............................................... .................................................. ..................... 73

11.10 BACKUP AND RESTORATION .............................................. .................................................. ............. 75

11.11 BUSINESS CONTINUITY PLANNING / DISASTER RECOVERY ...................... 79

11.12 SYSTEM SECURITY MANAGEMENT ............................................ ............................... 81

11.13 SYSTEM ADMINISTRATION .............................................. .................................................. ..... 82

11.14 RECORD MANAGEMENT (RETENTION, ARCHIVING AND RECOVERY) ........................ 83

12 DATA MIGRATION .............................................. .................................................. .......................... 85

12.1 INTRODUCTION ................................................ .................................................. .............................. 85

12.2 QUALITY MANAGEMENT .............................................. .................................................. .. 86

12.3 IMPORTANT POINTS ............................................... .................................................. ................ 87

12.4 DATA MIGRATION PLAN ............................................ .................................................. ..... 89

12.5 DATA MIGRATION REPORT ............................................ ................................................ 90

13 RETIREMENT OF COMPUTERIZED SYSTEMS ............................................. ............................ 90