Risk Management in the (Bio)Pharmaceutical and Device Industry
Risk-based compliance is expected by regulatory agencies and
strongly recommended by industry task forces and private authors to
balance compliance efforts and costs vs. product quality and patient
safety. Risk management has a long history in the industry. For
example, when car manufacturers have a quality problem with specific
models in the market they will go through a thorough risk management
process to decide whether to recall the cars or not. The cost of
recalling and fixing the problem will be balanced against the cost
that may potentially occur through not doing anything and the effect
this would have on the company image and product liability issues.
Risk assessment is also nothing new in our private life. We
experience this every day long before we start our daily work.
Before we cross a busy road on the way to our workplace, we look
left and right because there is a risk that a car may appear and run
us over. By observing car traffic and stopping until the car has
passed or looking for a pedestrian crossing or traffic lights we can
eliminate the risk that the car will hit us.
Objectives and Principles of Risk Management
Risk management is the process that helps to identify problems,
analyze them and then to create an action plan to avoid or manage
these problems. The objective of risk management during
pharmaceutical device and drug development and manufacturing is to
provide drugs and devices that are efficient and safe without
spending too many resources, for example, for validating processes
All recommendations from official guidelines, from industry task
forces and from private authors basically follow the same principles
for risk assessment.
- Identify the risks: What can go wrong?
- Analyze the risks: What is the likelihood or probability
that something goes wrong and what are the consequences or what
is the severity if something goes wrong?
- Estimate the risk priority number (RPN) and assess if the
risk is acceptable or too high.
- If the risk is too high develop and implement control steps
to reduce or eliminate the risk.
- Analyze the residual risk and assess if it is acceptable.
Let's look at the road traffic example we mentioned at the
beginning and use the same steps as above.
- Risk or unwanted event: Car runs over a pedestrian crossing
- Probability of occurrence: Depends on the road traffic - low
for country roads, medium for town roads and high for city
Severity: Always high, because the accident may lead to
permanent injury or death.
- Risk level expressed by the risk priority number (RPN):
Always high, because of high severity and some probability. The
RPN increases from the country road to the city street due to
- Control steps to reduce probability: Depends on the risk
- Country road: Look left and right before crossing the road.
- Town road: Use pedestrian traffic lights or a pedestrian
- City street: Use pedestrian overpass or underpass.
- Residual risk: Is acceptable because probability of
occurrence has been reduced.
The effort to reduce the risk to an acceptable level increases
with the risk priority number. This is a simple example, but
illustrates the steps that are required to get safely across the
road. The principles can be applied to most risk scenarios.
The person crossing the road does not follow a formal and
documented process. She or he is using a practical approach which is
only based on experience and common sense. This way we can define
risk management for compliance as "well-justified and documented
common sense". Official guidelines and standards such as ICH Q9, ISO
31000 and others have listed a couple of important principles for
- Is an integral value of all organization processes, e.g.,
for compliance, security, health and safety.
- Is part of decision making, for example, whether to
implement changes or not.
- Is systematic, structured and timely.
- Is based on the best available information, for example, on
historical data and on science.
- Has the health and safety of patients in mind.
- Is aligned with a company's culture, strategies, risk
profile and performance measures.
- Decisions should always be justified, documented and
communicated to everybody affected by the project.
- Is an ongoing process to improve the efficiency of the
Benefits and Issues for the Regulated Industry
The value of risk assessment for the regulated industry becomes
obvious from the diagram in Figure 1. On the x-axis it shows the
level of quality, validation or compliance of a product or process.
The y-axis shows decreasing risk, decreasing additional value and
increasing costs for validation and compliance.
Figure 1: Risk Optimization vs. Quality and Cost
Doing nothing about compliance, quality or validation is a high
risk, for example, you may receive warning letters from the FDA, or
when looking at equipment, you may have high failure rates. Or even
worse, patients may get sick if a drug has too many adverse
impurities because of insufficient quality or validation of
processes and systems. Of course, the advantage is that in this case
there are no costs involved. When going to the right side of the
diagram everything is validated and the most stringent
interpretation is used for compliance and the costs get
exponentially high. The risk decreases but so does the additional
value, for example, from additional validation efforts. One of the
tasks of a risk management project is to find an optimum which
should be somewhere in the middle.
For each process or piece of equipment the company should decide
how much risk can be taken. General recommendations should come from
the Risk Management Master Plan or directly from management for a
specific project. The question is how much risk a company can or
will take, or what is the acceptable risk threshold. The answer
depends on which direct impact equipment or a process has on the
drug or device product. For example, when looking at the drug value
chain from early research through preclinical and clinical
development to manufacturing, the direct impact on consumers
increases. Therefore, assuming everything is identical; the
validation effort for equipment used in manufacturing will be higher
than when the same equipment is used in early development.
Similarly one can argue that the validation efforts during
quality control of an active pharmaceutical ingredient (API) can be
lower than for finished drugs, because API quality problems can
still be uncovered by the pharmaceutical manufacturer before the
product reaches patients through incoming checks of the API and
through quality control of finished drugs.
The main benefit of quality risk management is that the regulated
industry can optimize resources towards high risk products,
equipment and processes and save resources for low or no risk
systems. This increases the overall efficiency and improves product
quality and patient safety. While in the past the regulated industry
hesitated in applying risk management, this changed since the United
States Food and Drug Administration (FDA) started promoting quality
risk management as part of its 21st century cGMP initiative along
with some follow-up activities. In light of this, the word
compliance can be eliminated from the x-axis in Figure 1, or at
least, compliance is not always proportional to validation because
with statements like: 'The type and extent of validation depends on
the risk on the drug product', 100% compliance can be achieved at
less than 100% validation.
The example used to illustrate the benefits of quality risk
management also brings up issues. QA and other professionals may
disagree that development activities and manufacturing of API's
don't require the highest focus on quality and validation. This is a
good point as long as we understand that risk management is always
relative with objective criteria such as direct impact on product
quality and patient safety. When looking at relative risks, quality
control of finished products bears a higher risk than equivalent
measures of API products or test samples from pre-clinical studies.
Objectives of the Tutorial
This tutorial addresses risk management in the
(bio)pharmaceutical and medical device industry. It is intended to
give project managers and other professionals from the
(bio)pharmaceutical and medical device industry a good understanding
of the objectives and principles of risk assessment and to guide
them through the risk management process. Quality managers and staff
as well as regulatory affairs professionals will also benefit
through extensive discussions of relevant regulations, quality
standards and guidelines. The tutorial will discuss tools and give
strategies and specific recommendations for all steps of risk
management such as risk identification, risk evaluation, risk
assessment and mitigation controls.
In less than one day readers will get:
- An overview of regulatory and quality standard requirements
- Tools and common practices available for risk assessment and
- Strategies for implementation with practical help on how to
document the outcome.
- Recommendations for special applications, e.g., for
laboratory systems, software and computer validation, equipment
maintenance and qualification and for process validation.
From our experience in attending risk management workshops and
reading literature and Risk Management Master Plans and procedures
we realized that there is little practical information available on
how to identify, evaluate and document risks together with
documentation of failures, hazards, possible harms and justification
of risk priority numbers based on severity, probability of
occurrence and probability of detection. It seems that most authors
describe conceptual steps with little practical help. Also, official
documents such as ICH Q9 don't give detailed information. This
tutorial tries to fill this gap.
Risk management for the (bio)pharmaceutical and device industry
has been widely documented in regulatory guidance, by industry task
forces and by private authors. This chapter lists some literature
publications with relevance to risk assessment and management in the
(bio)pharmaceutical and medical device industry.
- The European Council Directive 93/42/EEC of June 14 1993
Concerning Medical Devices (1) was one of the first regulatory
documents that requested to eliminate risks as much as possible
during the design and manufacturing of medical devices when
weighed against the benefits to the patient.
- The US FDA Quality System Regulation (2) requested to
validate the design of medical devices and that design
validation should include risk analysis, as appropriate.
- The EU GMP Annex 15 for "Validation and Qualification" (3)
requests a risk assessment approach to determine the scope and
extent of validation and to evaluate the impact of the change of
facilities, systems and equipment on the (medicinal) product
including risk analysis.
- Risk-based compliance was an important element of the FDA's
Pharmaceutical cGMP Initiative for the 21st Century in 2002 (4).
- Risk-based compliance was also a key component in the FDA's
new approach for dealing with electronic records and signatures:
21 CFR Part 11 (5).
- Probably the single most important document related to risk
management for the pharmaceutical industry is the ICH Q9 "Guide
on Quality Risk Management" from 2005 (6). It describes a
systematic approach for risk management and applies to drug
development and manufacturing including laboratories.
- The World Health Organization Expert Committee on
Specifications for Pharmaceutical Preparation published a paper
entitled "Hazard and Risk Analysis in Pharmaceutical Products"
(30). It provides general guidance on the use of Hazard Analysis
and Critical Control Points (HACCP) to ensure the quality of
- The Pharmaceutical Inspection Convention/Cooperation Scheme
(PIC/S) gave an example of a methodology for implementing ICH Q9
in the pharmaceutical field (29).
Risk management is well known and practiced in many industries
and several industry task forces have developed guidance documents
that facilitate risk management.
- In 2001 GAMP published the "Guide for Validation of
Automated Systems (GAMP 4)" (7). Appendix M3 was dedicated to
risk assessment. It mainly focuses on risk-based validation of
- Its successor GAMP 5 was released in 2008 (8). The title: 'A
Risk-Based Approach to Compliant GxP Computerized Systems'
indicates that the entire guide is focused on risk-based
compliance of computerized systems.
- The Global Harmonization Task Force (GHTF) has published a
risk management guidance for the medical device industry titled:
'Implementation of Risk Management Principles and Activities
within a Quality Management System' (9).
- In 2000 ISO published a standard 14971:2000: 'Application of
Risk Management to Medical Devices'. Even though it was
developed for medical devices the FDA also recommended the
approach for pharmaceutical applications. The standard was
updated in 2007 (10).
- In 2009 ISO released two more standards: ISO 31000 on "Risk
Management Principles and Guidelines" (11) and ISO 31010 on
"Risk Assessment Techniques" (12). Both standards are applicable
to all industries.
Private authors and professional service providers have published
papers with general recommendations for risk management which are
also related to specific applications.
- R. Jones (13) gave an overview of risk management for
pharmaceutical development and manufacturing with an
introduction to risk assessment techniques and with focus on
probabilistic risk assessment (PRA).
- Campbell (14) discussed how quality risk management
principles can be applied to achieve a practical equipment
- Several authors contributed to a book: "Risk Management in
the Pharmaceutical Industry" (34). The book includes
introductory chapters on regulatory requirements and risk
management tools followed by a total of six case studies.
- J.L. Vesper (33) authored a book titled: "Risk Assessment
and Risk Management in the Pharmaceutical Industry: Clear and
Simple". The book gives an overview of the risk management
process and some of the more commonly used risk assessment
methods and tools. It also examines how the various tools can be
applied to identifying hazards and evaluating their potential
impact and effects.
- Huber (15) applied the concepts of risk management to the
validation of commercial off-the-shelf computer systems.
- K. O'Donnel and A. Green described a risk management
solution designed to facilitate risk-based qualification,
validation and change control activities within GMP and the
pharmaceutical regulatory compliance environment in the EU in
two parts. Part I (35) gave an overview on fundamental
principles and design criteria outlined in the process and Part
II (36) focused on tools, structure limitations, principle
findings and novel elements.
Most literature publications give a general overview on risk
management principles and also offer tools that help for easy
implementation. For example, Labcompliance offers a "Risk Management
Master Plan" (16), several SOPs (17-19) and case studies (20).
Regulatory agencies expect (bio)pharmaceutical risk management to
assess risks associated with development and manufacturing of
medicinal products. Industry and other task forces have developed
guidelines and standards that help them better understand and
implement risk management processes. This chapter gives an overview
of the most important regulations, guidelines and quality standards.
United States Food and Drug Administration (FDA)
FDA 21 CFR 820: Quality System Regulation (2)
This regulation was released for medical devices in 1996. The
regulation requires a risk-based design validation.
- Â§30(g): Design validation. Each manufacturer shall establish
and maintain procedures for validating the device design. Design
validation shall be performed under defined operating conditions
on initial production units, lots, batches or their equivalents.
Design validation shall ensure that devices conform to defined
user needs and intended uses and shall include testing of
production units under actual or simulated use conditions.
Design validation shall include software validation and risk
analysis, where appropriate.
FDA Guidance: General Principles of Software Validation (2002) (21)
The guidance was developed for validation of software used in
medical devices. The FDA clearly spelled out the basic idea of
risk-based compliance: The validation efforts should be commensurate
with the complexity of the software design and the risk associated
with the use of the software.
- This guidance recommends an integration of software life
cycle management and risk management activities. Based on the
intended use and the safety risk associated with the software to
be developed, the software developer should determine the
specific approach, the combination of techniques to be used and
the level of effort to be applied.
- The selection of validation activities, tasks and work items
should be commensurate with the complexity of the software
design and the risk associated with the use of the software for
the specified intended use.
- For lower risk devices, only baseline validation activities
may be conducted. As the risk increases additional validation
activities should be added to cover the additional risk.
Pharmaceutical cGMPs for the 21st Century: A Risk-Based Approach
With this document the FDA introduced risk management to the
- Risk-based orientation: In order to provide the most
effective public health protection, the FDA must match its level
of effort against the magnitude of risk. Resource limitations
prevent uniformly intensive coverage of all pharmaceutical
products and production. Although the agency has already been
implementing risk-based programs, a more systematic and rigorous
risk-based approach will be developed.
FDA Guidance: Part 11, Electronic Records; Electronic Signatures
- Scope and Application (2003) (5)
In this guidance the FDA documented the new approach for
electronic records and signatures. They recommended basing the
decision on how to implement key requirements of Part 11 on a
justified and documented risk assessment.
- We recommend that you base your approach on a justified and
documented risk assessment and a determination of the potential
of the system to affect product quality and safety and record
- We recommend that your decision on whether to apply audit
trails should be based on "a justified and documented" risk
FDA Guidance: Quality Systems Approach to Pharmaceutical CGMP
Regulations (2006) (22)
Risk management is one of the focuses of this guidance.
Risk-based approaches are expected to be used for setting
specifications and process parameters, qualification of personnel,
selection of quality unit (QU) personnel and for supplier auditing.
- Quality risk management is a valuable component of an
effective quality systems framework. Quality risk management
can, for example, help guide the setting of specifications and
process parameters for drug manufacturing, assess and mitigate
the risk of changing a process or specification and determine
the extent of discrepancy investigations and corrective actions.
- In a quality system, personnel should be qualified to do the
tasks that are assigned to them in accordance with the nature
of, and potential risk of, their operational activities.
- Although QU personnel should not take on the
responsibilities of other units of the organization, these
personnel should be selected based on their scientific and
technical understanding, product knowledge, process knowledge
and/or risk assessment abilities to appropriately execute
certain quality functions (This quality systems feature is also
found in the cGMP regulations, which identify specific
qualifications, such as education, training and experience or
any combination thereof (see 211.25 (a) and (b)).
- The quality systems approach also calls for periodic
auditing of suppliers based on risk assessment.
- Although the cGMP regulations (211.180(e)) require a product
review at least annually, a quality systems approach calls for
trending on a more frequent basis as determined by risk.
- As with other procedures, audit procedures should be
developed and documented to ensure that the planned audit
schedule takes into account the relative risks of the various
quality system activities, the results of previous audits and
corrective actions, and the need to audit the complete system.
The Council Directive 93/42/EEC of 14 June 1993 Concerning
Medical Devices (1) requires a risk-based
design and manufacture validation and reducing risks to acceptable
- The devices must be designed and manufactured in such a way
that when used under the conditions and for the purposes
intended, they will not compromise the clinical condition or the
safety of patients, or the health and safety of users or, where
applicable, other persons, provided that any risks which may be
associated with their use constitute acceptable risks when
weighed against the benefits to the patient and are compatible
with a high level of protection of health and safety.
- The solutions adopted by the manufacturer for the design and
construction of the devices must conform to safety principles,
taking account of the generally acknowledged state of the art.
In selecting the most appropriate solutions, the manufacturer
must apply the following principles in the following order:
- Eliminate or reduce risks as far as possible (inherently safe
design and construction).
- Where appropriate take adequate protection measures including
alarms if necessary.
- In relation to risks that cannot be eliminated, inform users
of the residual risks due to any shortcomings of the protection
Annex 15 to the EU GMPs Validation and Qualification (3)
has legal status. It uses risk-based
approaches to validation and for changes to facilities, systems and
- A risk assessment approach should be used to determine the
scope and extent of validation.
- The likely impact of the change of facilities, systems and
equipment on the product should be evaluated, including risk
Annex 11 to the EU GMPs Using Computerized Systems (23)
requires to base controls for computerized
systems on a justified and documented risk assessment. Once
finalized the Annex will have legal status.
- Extent of validation and data integrity controls should be
based on a justified and documented risk assessment.
Pharmaceutical Inspection Convention/Cooperation Scheme (PIC/S)
The PIC/S Good Practices Guide on
using Computers in GxP Environments (24) was
developed for inspectors but it is also a good source document for
user firms. Risk-based approaches are recommended throughout the
life of a computer system.
- For GxP regulated applications it is essential for the
regulated user to define a requirement specification prior to
selection and carry out a properly documented risk analysis for
the various system options.
- The inspector will consider the potential risks as
identified and documented by the regulated user, in order to
assess the fitness for purpose of the particular system(s).
- This risk-based approach is one way for a firm to
demonstrate that they have applied a controlled methodology to
determine the degree of assurance that a computerized system is
fit for its purpose. It will certainly be useful evidence for
consideration by an inspector.
- Regulated users should be able to justify and defend their
standards, protocols, acceptance criteria, procedures and
records in the light of their own documented risk and complexity
assessments, aimed at ensuring fitness for purpose and
- The business/GxP criticality and risks relating to the
application will determine the nature and extent of any
assessment of suppliers and software products.
- The URS should also form the basis for a risk assessment of
the system for GxP compliance requirements, in addition to other
risks such as safety. The risk analysis may be based on the FS,
which is related to the URS (e.g. for bespoke systems). The risk
assessment and the results including the reasons for the ranking
as either: 'critical' or 'non-critical' should be documented.
The nature of any GxP risks should be clearly stated.
- The risk analyses and the results, together with reasoning
for critical or non-critical classifications should be
documented. Risks potentially impacting on GxP compliance should
be clearly identified.
- Inspectors will be interested in the company's approach to
identifying GxP risks and the criteria for assessing the fitness
for purpose of the system application.
An informal Working Group within PIC/S has developed an objective
and pragmatic example of methodology for implementing ICH Q9 (29).
The document is useful for training purposes and will not have an
impact on PIC/S inspections.
United States Pharmacopeia (USP)
USP develops methodology for specific applications and general
chapters on different analytical aspects for FDA regulated industry.
Most recently published final and draft chapters recommend risk
benefit approaches for testing and using solvents.
- <232> Elemental Impurities (Proposal)
The presence of unexpected elemental contaminants, as well as
that of impurities likely to be present, should be considered in
determining compliance and planning the risk-based extent of
- <467> Residual Solvents
Solvents that are known to cause unacceptable toxicities should
be avoided in the production of drug substances, excipients or
drug products unless their use can be strongly justified in a
risk benefit assessment.
International Conference for Harmonization
ICH Q9: Quality Risk Management (6) is the
single most important reference document for risk management for the
pharmaceutical industry. ICH focuses on scientific knowledge and the
link to the protection of the patients as a primary principle. The
guide also gives recommendations for implementation.
- Two primary principles of quality risk management are:
- The evaluation of the risk to quality should be based on
scientific knowledge and ultimately linked to the protection of
the patient; and
- The level of effort, formality and documentation of the
quality risk management process should be commensurate with the
level of risk.
- It is neither always appropriate nor always necessary to use
a formal risk management process (using recognized tools and/or
internal procedures e.g., standard operating procedures). The
use of informal risk management processes (using empirical tools
and/ or internal procedures) can also be considered acceptable.
ICH Q9 has been adopted by the European Union and PIC/S in Annex
20 of the EU and PIC/S GMP Guides.
International Organization for Standardization (ISO)
ISO currently has three standards related to risk management:
14971 for medical devices and 31000 and 31010 which are for general
purpose risk management projects. ISO 31000 describes principles and
guidelines and 31010 risk assessment techniques.
ISO 14971:2007 - Application of Risk Management to Medical
This document was developed for medical devices but has also been
recommended by FDA officials for pharmaceutical industry.
- This International Standard specifies a process for a
manufacturer to identify the hazards associated with medical
devices (including in vitro diagnostic (IVD) medical devices),
to estimate and evaluate the associated risks, to control these
risks and to monitor the effectiveness of the controls.
- The requirements of this International Standard are
applicable to all stages of the life cycle of a medical device.
- This International Standard does not apply to clinical
- This International Standard does not specify acceptable risk
- This International Standard does not require that the
manufacturers have a quality management system in place.
However, risk management can be an integral part of a quality
ISO 31000:2009 - Risk Management - Principles and Guidelines
- This International Standard provides principles and generic
guidelines on risk management. It can be used by any public,
private or community enterprise, association, group or
individual. Therefore, this International Standard is not
specific to any industry or sector.
- This International Standard can be applied throughout the
life of an organization and to a wide range of activities,
including strategies and decisions, operations, processes,
functions, projects, products, services and assets.
- This International Standard can be applied to any type of
risk, whatever its nature, whether having positive or negative
- Although this International Standard provides generic
guidelines, it is not intended to promote uniformity of risk
management across organizations. The design and implementation
of risk management plans and frameworks will need to take into
account the varying needs of a specific organization, its
particular objectives, context, structure, operations,
processes, functions, projects, products, services or assets and
specific practices employed.
- It is intended that this International Standard be utilized
to harmonize risk management processes in existing and future
standards. It provides a common approach in support of standards
dealing with specific risks and/or sectors and does not replace
- This International Standard is not intended for the purpose
ISO 31010:2009 - Risk Assessment Techniques (12)
- This International Standard is a supporting standard for ISO
31000 and provides guidance on selection and application of
systematic techniques for risk assessment.
- Risk assessment carried out in accordance with this
International Standard contributes to other risk management
- The application of a range of techniques is introduced, with
specific references to other International Standards, where the
concept and application of techniques are described in greater
- This International Standard is not intended for
certification, regulatory or contractual use.
- This International Standard does not provide specific
criteria for identifying the need for risk analysis, nor does it
specify the type of risk analysis method that is required for a
- This International Standard does not refer to all techniques
and omission of a technique does not mean it is not valid. The
fact that a method is applicable to a particular circumstance
does not mean that the method should necessarily be applied.
Approaches for Risk Management
Risk management can be very simple and straightforward but it can
also be quite complex. For example, risk assessment of equipment can
be documented in just one paragraph with a simple statement such as:
The risk level is low because the equipment does not have any impact
on the quality of the finished product. For a more complex computer
system used in pharmaceutical manufacturing, a full risk management
may require an assessment of the criticality of each function with a
need for testing if the function has a high impact on the system
Similarly the vendor risk can be justified and documented on a
single page if the vendor meets all criteria as required for low
risk vendors. This does not take more than five to ten minutes. On
the other hand a full risk management for a pharmaceutical
development or manufacturing process can take quite some time and
can fill one hundred pages or more. Whether the process and
documentation is simple or complex it is always most important that
it follows a formal procedure and that the outcome and conclusion
are justified and documented. The risk management process as
applicable to the (bio)pharmaceutical and device industry has been
described in several official publications, for example ICH, GHTF
and ISO (6, 9 and 10) and by private authors. All proposals for risk
management include steps such as risk initiation, risk assessment
and evaluation, risk mitigation and control and risk communication
and review. This chapter outlines the ICH Q9 process and gives
recommendations for estimating severity and probability.
The ICH Process
ICH Q9 is the most authentic document for risk management in the
(bio)pharmaceutical industry. The guide describes quality risk
management as a systematic process from the assessment, control,
communication and review of risks to the quality of the drug along
the product life cycle. The guide also outlines an example model for
quality risk management but includes a statement that other models
are also possible. The example model is illustrated in Figure 2.
Risk management projects can be proposed by anybody in an
organization whenever there is a need for such a project and the
proposal is justified. The proposal should describe any problem with
background information and examples for data on potential hazards
Figure 2: Risk Management Process According to ICH Q9
The project is reviewed, approved and supported by management.
Management also identifies a project owner who, with the help of
affected department managers, assembles a risk management project
team. The team develops a risk management project plan with
information on process steps, required resources, tasks,
deliverables and responsibilities. The plan should also include a
In the risk assessment phase the team identifies hazards and
harms and evaluates severity and probability based on criteria as
defined in the company's Risk Management Master Plan.
Questions team members should ask are:
- What might go wrong?
- What is the likelihood (probability) that it will go wrong?
- What are the consequences (severity) if something does go
The outcome from this phase is a group of risk priority numbers
(RPNs) calculated from severity and probability. Alternatively ICH
permits a qualitative description of the terms, for example 'high',
'medium' or 'low'. The qualitative description or risk number can be
compared with risk acceptance criteria as generally defined in the
Risk Management Master Plan or by management specifically for the
project. If the risk number or corresponding qualitative description
exceeds the acceptable risk this is reduced. After reduction the
residual risk is evaluated again and accepted if the resulting risk
is lower than the acceptable risk.
The outcome of the risk management process is communicated to all
decision makers and any others who might be affected by this
process. The process is reviewed for existing and possible new
hazards on an ongoing basis. For example, new hazards may be
identified or the defined level for probability may change.
Everybody affected by the project is encouraged to actively monitor
the process and give feedback for possible updates.
Criteria for Severity, Probability and Risk Acceptance
Defining a process and objective criteria for severity (S) and
probability (P) and criteria for risk acceptance is most important
for risk assessment. Neither international standards nor regulatory
guidance documents require that a particular method is used.
Severity in general means: How big is the problem if it occurs?
Probability means: What is the likelihood that a problem occurs? For
each identified hazard the probability and severity factors are
estimated and associated to different categories. The number of
categories is usually 3, 5 or 10 but can be any number up to or more
than 10. ICH does not give any preference. The company's risk
management should give recommendations on how to decide how many
levels should be used. The number can be fixed in the master plan
for all projects or you can allow two or three options. For example,
the final number for a specific project could be dependent on the
confidence of the estimates.
The first part of this chapter suggests a procedure to estimate
severity, probability and the overall risk of an identified hazard.
The second part has recommendations on how to define objective
criteria and a process for assigning levels for probability and
Procedure for Estimating Probability and Severity
The scales can be qualitative, quantitative or semi-quantitative.
Unless there are thorough statistical or other reliable data
available, the scales should be defined as qualitative. An example
for a qualitative description of probability would be 'high',
'medium' or 'low'. Equivalent semi-quantitative expressions would
be, for example, 'once a day', 'once a week' or 'once a month'.
Figure 3 shows more examples for qualitative and semi-quantitative
descriptions for severity and Figure 4 shows equivalent examples for
Likely to happen
||Every 3 days
Every 3 weeks
||Every 2 months
Figure 3: Examples for Qualitative, Semi-Quantitative and
Quantitative Risk Categories for Probability
- Death or permanent injury
- Loss > $50 million
- Injury for up to 1 month
- Loss $10-50 million
- Temporary injury for 2 days requiring professional
- Loss $2-10 million
- Temporary injury for 2 days not requiring
professional medical treatment
- Loss $500 thousand / $2 million
- Temporary discomfort for 2 days
- Loss < $500 thousand
Figure 4: Examples for Qualitative and Semi-Quantitative Risk
Categories for Severity
Probability of detection has also been suggested as a risk
measure. This is an option but it is not a must. One can argue that
severity factors increase if the probability of detection is low. It
should be considered under specific conditions to decide whether the
risk could be included or not.
It is most important to make the risk analysis and evaluation as
objective as possible. A frequent mistake is that individual members
tend to rate everything as high risk. One way to ensure objectivity
across an organization is to take assessment criteria and examples
for severity from the corporate Risk Management Master Plan. The
probability data should be derived from available empirical data of
the same or similar systems or processes. If such data are not
available then the most unfavorable situation should be used for the
initial risk assessment.
Documentation of the severity factors should include a scientific
justification. After all the risks have been discussed and rated,
the team reviews them for relative comparison. Adjustments should be
made for RPNs that are considered to be out of order.
Graphical Determination of the Overall Risk
After values for severity and probability have been assigned, the
overall risk is determined. This can be done graphically as shown in
Figure 5. Severity levels low, medium and high are drawn as columns
and probability as rows. All cells in green are low risk, in yellow
medium risk and cells in red are defined as high risk.
Figure 5: Graphical Determination of Risk
The equivalent graph including detectability is shown in Figure
6. Risk as identified in Figure 5 is drawn using detectability as
columns starting with high on the left.
Figure 6: Graphical Determination of Risk including Detectability
Determination of the Overall Risk with Risk Priority Numbers
Levels for severity as described before can be converted to
numbers, for example 'low' becomes a 1, 'medium' a 2 and 'high' a 3.
This is especially convenient for assigning the risk for routine
applications for the determination of the overall risk.
Risk priority numbers (RPNs) are calculated from severity and
probability levels using the formula:
RPN = Severity (S) x Probability (P)
Risk (RPN) is expressed as the multiplication of severity with
RPN = S x O.
In the example in Figure 5 the RPN can go from 1 in the left lower cell to 9
in the right upper cell. RPNs from 1 to 2 are equivalent to low, 3 to 5 are
medium and 6 to 9 are high risk.
This procedure is much more flexible than the graphical
determination. For example, for specific situations weight factors
can be added to probability and/or severity. In this case the
formula could look like:
RPN = 2S x P
This means the impact is double weighted compared to probability.
Another advantage of using numerical values is that multiple risk
types can easily be combined. For example, non-patient related
business risk can be combined with patient risk using the formula:
RPN = S x (P (Business) + S x P
Again weight factors can be added, for example, if the patient
risk is considered to be more important than non-patient related
This procedure also easily allows using detectability as a
contributing factor to the overall risk. But first, categories for
the detectability have to be assigned. Then categories have to be
converted to numbers. The resulting formula is:
RPN = S x P x 1/D
Working with calculated numbers is very easy but unless there is
a good description about the meaning they don't tell us anything
about the absolute risk. This could cause problems when values for
severity, probability and detectability are initially assigned.
Therefore, a good practice is using qualitative or quantitative
descriptions during initial ranking and then allocating numbers to
Estimating Severity of Potential Harms
There are several factors that contribute to the severity of
potential harms in the (bio)pharmaceutical and device industry. The
final ranking is derived from individual factors. ICH Q9 recommends
using patient safety as the main criterion and basing the decision
on estimating levels on a scientific judgment.
Factors contributing to severity typically include:
Impact on Product Quality
The question here is if the potential harm has a direct impact on
product quality, which means that any failure cannot be corrected
before a new drug or a device product is approved for marketing or
before a batch is released for shipment. In this case the
probability of detecting the problem is low or zero. An example is
an analysis system used in a quality control laboratory where
analysis results are used as criteria whether to release a batch or
Impact on People's Health and Safety
Poor product quality as discussed in the previous paragraph only
plays an important role if the poor quality can have an adverse
impact on consumers. This directly turns into health effects for
patients. An example for high severity is when poor product quality
can cause sickness that requires treatment in a hospital.
Impact on Business Continuity
This is related to a company's ability to timely market a new
product and reliance on the system and process uptime for continuous
shipment of products. The answer for the level comes from the
question: How big is the loss in $ due to delays in new product
approval or shipment stoppages?
Impact on Compliance
This is related to the risk of failing regulatory inspections and
receiving single or multiple warning letters or inspectional
observation reports. Consequences can be shipment stops, substantial
amounts of reengineering to fix problems and resources to implement
There are other indirect factors like claims by end-users,
product liability issues, product recalls and a company's
reputation, e.g., if problems with product quality or compliance
Estimating Probability of Potential Harms
Probability should answer the question: What is the likelihood
that an identified hazard occurs? Probability should be expressed in
occurrence per time. The main source for reliable probability data
is experience with the same or similar process or system. One
important point is that we should look at the circumstances and
complete sequence from the occurrence of the hazard through to the
occurrence of the harm. A specific hazard may not always cause harm.
The probability should be estimated by subject matter experts.
Possible sources of data are:
- Historical data from using the same process or system.
- Historical data from using a similar process or system.
- For equipment and systems: Information from the vendor, for
example, reliability estimates, costs for guaranteed uptime and
- Initial production data.
Sources can be used individually or jointly. Preferably multiple
sources should be used to increase the confidence level.
Estimates are very difficult to make when no historical data are
available. As a workaround you can ask if within the same company
either at the same or other sites adequate data are available. Even
if the information cannot be copied 100% you can look at
similarities and differences and add uncertainties accordingly.
Most critical is the situation for new systems. In this case
estimates from the supplier can be used to judge what could possibly
go wrong. However, this requires having a very good relationship
based on trust with the supplier.
If no data are available the probability level should be based on
the worst case estimates.
The risk threshold is a measure on how much risk a company is
willing to take. It is expressed on a scale of very low risk
tolerance to very high risk tolerance. A low risk threshold means a
company is not willing to take a risk and a high threshold means the
company is willing to accept a lot of risk. The RT is proposed by
the project team for each risk management process and should be
approved by management. For example, when looking at computer system
validation the risk threshold is higher for a system used in early
product development than when the same system is used in
manufacturing control. Similarly processes used in API manufacturing
can take higher risk factors than processes for manufacturing of
drugs because of additional quality control of finished drugs that
can also recover quality problems of APIs. Recommendations on how to
apply the RT and examples should be documented in the Risk
Management Master Plan.
Figure 7: Risk Priority Number vs. Risk Threshold
The relationship between the RPN and the RT is shown on two
examples in Figure 7. On a scale of 0 to 10 the risk factor is
determined as approximately 6. In Example 1 this RPN is higher than
the RT (approximately 3) which means it should be reduced to below
3. In Example 2 the RPN is lower than the RT, so it is acceptable.
This procedure requires that the RPN and RT numbers should be
normalized to exactly the same range.
Tools and Methodologies for Risk
Tools are important to make the entire risk management process
efficient and consistent. They can be as simple as templates in
Microsoft Word or Excel that can be filled out by risk management
team members and other individuals to identify hazards and harms and
to justify and document risk priority numbers and mitigation steps.
Tools can also include software to guide risk management
professionals through the full risk assessment process. The most
well-established formal tools for risk assessment are: Failure Mode
Effect Analysis (FMEA), Fault Tree Analysis (FTA), Preliminary Risk
Analysis (PRA), Hazard, Hazard Operability Analysis (HAZOP) and
Hazard Analysis and Critical Control Points (HACCP). Formal tools
can be categorized into deductive and inductive tools. Inductive
techniques answer the question: What if something bad happens?
Deductive techniques look at a specific problem and answer the
question: What caused it to happen? An example for an inductive tool
is FMEA and an example for a deductive tool is FTA.
While these formal tools often proved to be efficient and
reliable in risk assessment and risk control of specific projects, a
systematic use of these tools to address all areas with requirement
for risk assessment would generally be incompatible with existing
resources. ICH Q9 also has a comment about using tools: "It is
neither always appropriate nor always necessary to use a formal risk
management process (using recognized tools and/or internal
procedures e.g., standard operating procedures). The use of informal
risk management processes (using empirical tools and/or internal
procedures) can also be considered acceptable". While in the past
more empirical tools have been used there is a tendency nowadays to
use more established formal tools.
All tools, whether they are simple or complex have one
disadvantage: They do not replace subject expert knowledge! The
output is only as good as the input. Most important is that inputs
should not only come from single individuals but also from a risk
management team that has all the required knowledge and expertise.
This chapter will describe some of the most frequently used
tools. The first section describes examples of informal tools that
are mainly used to document experience. They include tables,
templates, forms and examples and also a Risk Management Master
Plan, internal procedures, a risk database and software tools. In
the second part of the chapter we describe and move on to more
sophisticated and well-established methodologies. Figure 8 lists
some of the most well-known methodologies with advantages and
deductive, structured tool.
inductive tool, can be qualitative and quantitative.
hazards to reduce risks at specific CPs.
||Qualitative inductive tools.
||Visual fault tree
diagrams with standardized symbols to show the pathway from
basic events to the undesired event.
||Very universal and
scalable, e.g., for high level and detailed risk assessment.
Specific and flexible.
Focus on prevention.
Record keeping answers product liability and compliance
|Easily adaptable to most
||Can quickly become
very complex because it looks at one failure at a time.
||Tool does not
consider operational issues or operator performance.
Does not show interaction between events.
information on the product and process.
therefore may miss potential hazards.
Graphics with standardized symbols.
Dedicated software recommended.
Detailed process diagrams.
|Drawings and tables.
Main Application and Use
||Used to define a
particular undesired event and identify its causes (basic
For potential problems with serious impact.
e.g., medical device, hospitals.
Used to identify known and potential failure modes and
impact on processes, facilities and equipment.
Used during design and operation.
|Food and chemical
Adapted for pharmaceutical industry by WHO.
Covers full product chain.
|Used early in new
products and changes in products and processes (design
First step of complex risk assessments.
Figure 8: Formal Risk Management Methodologies
Informal tools are simple and easy to use. They are recommended
for processes that are not so complex and if there is not much
experience with risk assessment within a company. They are useful to
make all risk assessment and management processes consistent and
effective. They are also quite useful to generate preliminary
documentation which is used when making the decision to stop or when
moving a risk management project forward to a more detailed risk
management using established methodologies.
The Importance of a Generic Risk Management Master Plan
One of the biggest challenges in risk management is to make
assessment objective which means make it independent from subjective
opinions of individuals who may look at risk from just one angle.
Legislation does not give any solution to this specific problem and
different risk methods as well as private authors give different
answers to the problem.
For example, recommended numbers for probability range from 0 to
1, to 5 or to 10 and severity can vary from 1 to 3, 5 or 10. Some
methods include "detectability" or "discovery probability" in the
formula and there is even inconsistency in the formulas used for
calculation. The subjectivity problem has also been brought up by
ICH Q9: Each stakeholder might perceive different potential harms,
place a different probability on each harm occurring and attribute
different severities to each harm.
However, while it may be very difficult to get a common
understanding across the industry on the formal process and criteria
to assess a risk, it should be possible to get this understanding
within a company. The outcome of the same risk assessment process
should be consistent within a company, no matter who is doing it.
Master plans in general are excellent tools to get a common
understanding on specific topics. For example, validation master
plans are well accepted and frequently used to ensure consistency
and effectiveness of validation projects. Risk Management Master
Pans with specific examples are even more important to also ensure
objectivity for criteria such as severity and probability. As such a
Risk Management Master Plan provides a framework and practices for
risk management of processes and equipment. It also ensures that
risk assessment and controls are carried out efficiently and
consistently throughout the organization as well as meeting
regulatory, customer, quality and business requirements. The plan
should ensure that the company's risk management procedures are
based on science and that they are understood and followed
throughout the organization.
The risk management document is the first and most important
document that should be available when starting individual risk
management processes. It is the basis of individual Risk Management
Project Plans and is the reference document for all risk management
projects, no matter which risk management methodology is used.
This master plan describes:
- The company's risk management policy.
- The links between the company's organizational objectives
and policies and the risk management policy.
- Relationship of the risk management plans with other
documents, e.g., validation master plans or quality manual.
- The approach to the company's risk management process.
- Members of risk management teams (by function).
- Responsibilities of the project leader and team members.
- Products and processes that should be covered by risk
- Contents of individual Risk Management Project Plan.
- Detailed steps for risk management.
- How the likelihood is defined.
- How to identify risk levels.
- Factors contributing to high and low severity.
- Definition and determination of RPNs with examples.
- Criteria and examples for acceptable risk thresholds.
- How to make a high-level risk assessment.
- Communication of project status and outcome of risk
- Frequency and procedures for ongoing review.
The Risk Management Master Plan should be developed by a
cross-functional team at the highest level possible. Preferably the
corporate QA department should own the project and also ensure that
the concepts are implemented for individual quality risk management
Step-by-step procedures should be developed for initiating,
implementing and updating individual application-specific risk
management projects. Examples are risk-based supplier assessment,
risk-based computer system validation or risk-based testing of
starting materials for drug manufacturing. Development and use of
such procedures should be controlled by corporate quality assurance
to ensure consistent use throughout the organization.
Templates and Forms
Templates and forms with examples and process flow charts are
simple but valuable tools to improve consistency and efficiency for
risk identification, evaluation and control. They can be part of
SOPs or the Risk Management Master Plan or they can be individual
documents. Examples are specifically important to give advice on
ranking risk elements such as probability, detectability and
Examples and Case Studies
As organizations gain experience with risk management projects
and after several projects have been executed, a library with
representative examples should be developed. The examples help risk
management project managers and teams to identify, evaluate and
control risks. The library should include both good and bad
examples. Each example should include recommendations on how to
proceed with similar projects.
Checklists are lists of hazards, possible harms and controls that
have been developed from experience either as a result of previous
assessment projects or as a result of past failures or from daily
product or process support. For example, the IT help desk can
generate such a list for various computer systems. The value of
checklists is not to forget common important hazards and control
A corporate database with examples for risk hazards and harms
within a company helps to facilitate the collection and maintenance
of risk data. Relative risk priority numbers for severity and
probability and mitigation steps also help to harmonize assessment
within a company. While initially there may be no or very little
data, such a database will provide increased value over time when
databases are populated with data from more risk management
Software for Risk Assessment and Risk Management
To be added later
Failure Modes, Effects and Criticality Analysis (FMECA)
Failure Modes and Effects Analysis (FMEA) evaluates a product
process for strengths and weaknesses, for potential problem areas,
risks or failure modes and prevents failures before they occur.
FMECA adds evaluation of the criticality including severity,
occurrence and detectability and tries to answer the questions:
- How can a product or process fail?
- What is the likelihood that it fails and if so, what is the
likelihood that the failure will be detected? and,
- What will be the effect on the rest of the process or
system if a failure occurs and is not detected such that it can
FMEA has the highest impact and should be performed during design
or development of a product or process when failures are less
expensive to address. It can be a powerful tool to improve product
reliability and reduce design, development and manufacturing costs.
FMEA is a bottom up approach to failure mode analysis. It can be
used to evaluate failures that can occur when designing or running a
process, or when designing, developing or operating equipment. FMEA
helps to design and manufacture a trouble-free product. Identified
failures in a product or process are corrected before they occur to
ensure trouble-free functioning and operation.
FMEA and FMECA are the most generic risk management methodologies
and can be applied to a large variety of applications.
For example, they can be used during design and manufacturing of
equipment as well as to set up and optimize qualification and
maintenance plans for equipment. During design FMEA can help to
select the best design alternative and improve the design of
procedures and processes. Both methodologies are also used as a
preliminary screening method for complex risk management before the
project is moved forward to more time-consuming methodologies.
Advantages and Limitations
FMEA and FMECA have many advantages. They include:
- Wide applicability from design to manufacturing, servicing
and maintenance of mechanical and electronic equipment.
- Identifies failure modes, their causes and effects on the
- Ideal for simple to medium complex systems.
- Optimized for single individual failure modes, but they
don't work well for combinations of failure modes.
- Can be time-consuming for complex systems.
FMEA and FMECA require a very good knowledge of the product or
process. The assessment process is the same as described in Figure
- Select a team and team leader. All team members must be
subject matter experts.
- Select the FMECA form from the company's Risk Management
Master Plan or if not available, create one.
- Train team members on the process and on criteria for
ranking likelihood of occurrence and impact of failure when it
- Make the team members familiar with the design of the
product or process to ensure that all team members have the same
understanding. This can be through distributing product and
process documentation supported by flow diagrams.
- Set up one or more brainstorming meetings. Multiple sessions
are recommended for complex product/process designs. Individual
sessions can focus on subsets of the entire product/process.
- Brainstorm the product or process design for possible
failures. Document the outcome on a flipchart.
- Sort all suggested failures by categories.
- Combine or remove similar or duplicate entries.
- Document potential effects on the system, subsequent
operation and end user (e.g., patient).
- Assign rating factors for each identified severity,
occurrence and detectability. Definition and scale of rating
factors should be taken from the company's Risk Management
Master Plan not only to ensure objectivity and consistency with
the project team but also with other risk management projects.
Justify the rating with reference to the plan. For occurrence,
historical data from the same or similar projects can be used.
- For each identified effect list all possible causes of
failures with justifications and with all uncertainties.
- Calculate the risk priority number using the formula from
the Risk Management Master Plan. The RPN is a measure for the
overall risk associated with the project.
- Take actions to reduce potential critical risks.
- Assign owners, a schedule and deliverables for the actions.
- After the action has been implemented make a new rating for
severity, occurrence and detection and calculate the RPN.
In the brainstorming meeting the risk management team identifies
all possible failures. Most important for new products and processes
is information from the engineers who have designed the product or
process even though they may hesitate in admitting that failures may
occur. For products that have been in use for some time the user of
the products and support engineers are excellent resources. They can
not only provide good information on which failures may occur but
they can also predict the likelihood of occurrence and the severity
of a failure.
The overall risk number is calculated from the probability and
severity and the decision is made on which potential failures
require risk reduction. Possible follow-up actions could be redesign
of products or processes such that either the probability of
occurrence or severity factors are reduced such that the overall
risk priority number is also reduced.
Fault Tree Analysis (FTA)
Fault Tree Analysis is a deductive tool that assumes a failure of
the functionality of a product or process. It can be used as a
qualitative and quantitative structured tool. It is used to define a
particular event and identify its causes. Results are graphically
visualized in a tree of fault modes and this is where the name comes
from. The diagrams can be used to identify the pathways from the
base events to the undesired events. The methodology is particularly
useful to examine problems with equipment, facilities and
FTA identifies the potential root cause(s) ('basic events') of
the specific problem or hypothetical event. Problems can be caused
by design and engineering defects and also by human factors. When it
is unlikely that the root cause is not just based on single-base
events, 'cut sets' of all scenarios can be defined which can cause
the top event.
Advantages and Limitations
FTA has advantages and limitations.
- Highly systematic but also flexible.
- The 'top-down' approach focuses attention on the failure
effects which are directly related to the top event.
- Useful for analyzing systems with many interfaces.
- Pictorial representation helps to easily understand the
- Uncertainties in the probability of the base events are
included in the calculations of the probability of the top
- The static model does not address time interdependencies.
- Fault trees can only deal with binary states (failed/not
Steps for FTA Analysis
Steps for FTA analysis include:
1. Form a Team and Determine a Team Leader
Team members should be experts in the application, and either
have knowledge and experience in FTA methodology or get trained;
with emphasis on how to interpret standardized symbols used in a
2. Definition of a Problem and Justification of the Project
Define the event or describe what it is that should be prevented.
Because the amount of work for a complex FTA analysis can be
significant, the primary reason for the project should be well
justified. The definition should also clearly describe the scope and
boundaries of the project. Most important is to clearly define the
top event and to keep it in line with the project scope.
3. Construction of the Fault Tree
After team members have acquired all the information about the
process, list all possible root causes that could lead to the
unwanted event. These "basic" events are linked through
"intermediate" events to the top event in a flow chart. For the
connection between top and basic events defined logical pathways
should be used. A basic event can cause the unlikely event (top
event) on its own or in combination with others (cut sets).
4. Evaluate the Fault Tree
This step prioritizes basic events based on probability data.
That kind of prioritization is only useful if such data are
5. Prepare a Report
The report should include a description and scope of the project,
a system description, all relevant process flow diagrams, fault tree
analysis listings and the FTA flow chart. It should also include a
conclusion of the analysis related to the original question.
Hazard Analysis and Critical Control Points (HACCP)
The Hazard Analysis and Critical Control Points (HACCP) method
originated from a food management system. The objective is to ensure
food safety through identifying and preventing known hazards and
risks as they may occur at specific points in the food chain. As
such it is a systematic method for identification, assessment and
control of safety hazards. The methodology is not limited to the
food industry and has also been suggested for the pharmaceutical,
chemical, aviation and car industry. In the scope of this
methodology hazards are defined as biological, chemical or physical
agents or operations that are likely to cause illness or injury if
not controlled. The purpose of HACCP in the pharmaceutical
manufacturing process is to ensure products with quality as
specified that are efficient and safe for use. GMPs and HACCP are
not contradictory but rather complementary. Implementation of Good
Manufacturing Practices is facilitated through HACCP methodology
whereas a GMP environment with well-structured procedures
facilitates implementation of HACCP.
HACCP Principles and Methodology
HACCP principles and methodology are very well standardized which
facilitates training and applying the HACCP system. The system
addresses all steps from raw material production, procurement and
handling, to manufacturing, distribution and consumption of the
finished product. HACCP principles were defined by the National
Advisory Committee on Microbiological Criteria for Foods (NACMCF) in
1992. The document was reviewed and updated by the Committee in 1997
(32) and as a result HACCP was defined as a "systematic approach to
evaluate, identify and control food safety hazards". The HACCP
system is based on seven principles:
- Conduct a hazard analysis.
- Determine critical control points (CCPs).
- Establish critical limits for each CCP.
- Establish a monitoring system for the CCPs.
- Establish corrective actions when the CCP is not under
- Establish verification procedure to confirm HACCP is working
- Establish documentation concerning all procedures and
records on these principles and their application.
Figures 9 show a flow diagram with steps for implementation of
the HACCP analysis. Some preparation work is needed before the
hazard identification and analysis start.
1. Develop a HACCP Plan
After the project has been initiated by management and after
management has defined a project leader a preliminary plan is
drafted by the project leader. It should be product or process
specific to address specific situations in the project and it should
also be in line and derived from a company's generic Risk Management
Master Plan or HACCP Master Plan to ensure efficiency and
consistency throughout the company. The plan should include:
- The scope of the project,
- steps, tasks,
- responsibilities and
- a time line.
2. Assemble a HACCP Process Team and Define a Team Leader
Team members should include subject matter experts with specific
knowledge and expertise in pharmaceutical engineering. Preferably
team members should represent all affected disciplines, e.g.
- quality control,
- quality engineering and
- members of other disciplines directly involved in the plan's
The team should also include local personnel who are familiar
with capabilities and limitations of the operation. Team members
should either have knowledge and experience in HACCP methodology and
product safety hazards or should get training. One of the first
tasks of the team is to finalize the HACCP plan.
3. Describe the Product or Process and Develop a Flow Diagram of
The description should include the intended use and end users of
the product and the distribution method. The intended users of a
food or drug product may be the general public or a particular
segment of the population, e.g. infants and elderly people. The
product description should include a list of specifications e.g.,
physical and chemical properties.
A flow diagram should be developed with the purpose of providing
a clear, simple outline of the steps in the process which are under
the control of the establishment. It should include all process
steps such as mixing, drying, cleaning, blending, testing,
packaging, labeling, storing and distribution.
4. Verify the Flow Diagram Onsite
This step compares in a walk-through, the actual operation with
the product and process documentation, such as product description
and flow diagrams. To ensure objectivity the verification should not
be done by the same people who originally developed the flow
diagram. Deviations should be corrected in the flow diagram and
Implementing HACCP Principles
After the preparation has been done, the seven HACCP principles
as outlined previously are implemented. Steps include:
1. Identify all Potential Hazards
All potential hazards and associated control measures, if
available, are identified and documented for each operational step
from receipt of raw materials through to release and distribution of
the finished product.
2. Conduct a Hazard Analysis
The purpose of the hazard analysis is to develop a list of
hazards which are of such significance that they are reasonably
likely to cause injury or illness if not effectively controlled.
Hazards that are not reasonably likely to occur would not require
further consideration. Potential hazards include:
- chemical and
- physical compounds.
The analysis is done by the HACCP team in a brainstorming meeting
on hazard identification followed by a workshop on hazard
The process of conducting a hazard analysis involves two steps.
The first step, hazard identification, lists all potential
hazards. This is done through the brainstorming session. The team
develops a list of potential biological, chemical or physical
After the list of potential hazards is assembled, step two the
hazard evaluation, is conducted. In a workshop the HACCP team
decides which potential hazards must be addressed in the HACCP plan.
During this stage each potential hazard is evaluated based on the
severity of the potential hazard and its likely occurrence. The
occurrence factor also takes into account control measures that are
already in place to reduce the probability of occurrence.
The outcome of this exercise is to decide which identified
hazards are critical enough that they are defined as critical
control points (CCPs) and control steps are then implemented to
reduce the risk to an acceptable level. If there are no hazards that
need to be controlled there is no need to establish critical control
limits. The project moves directly to establishing monitoring
3. Determine Critical Control Points
Once the critical hazards are identified the team identifies
control measures for reduction or elimination of each critical
hazard. Areas that should be considered are:
- equipment malfunction,
- failures of sensors,
- human errors,
- power failures and
- external impacts such as natural forces, e.g., lightning or
Control steps are identified for all critical hazards where no
control measure exists. Complete and accurate identification of CCPs
is fundamental to controlling hazards. The information developed
during the hazard analysis is essential for the HACCP team in
identifying which steps in the process are CCPs. One strategy to
facilitate the identification of each CCP is the use of a CCP
decision tree. Figure 9 shows an example of such a decision tree
with three questions to answer.
Important questions to ask are:
- Does this step involve a hazard of sufficient risk and
severity to warrant its control?
- Does a control point for the hazard exist?
- Is control at this step necessary to prevent, eliminate or
reduce the risk of the hazard to consumers?
If all questions are answered with yes, a critical control is
defined for the hazard.
Figure 9: Decision Tree to Identify Critical Control Points (From
4. Establish Critical Limits for Each Control Point
Critical limits should be established for each control point. A
critical limit is a maximum and/or minimum value to which a
biological, chemical or physical parameter must be controlled at a
CCP to prevent, eliminate or reduce to an acceptable level, the
occurrence of a food safety hazard. Critical limits may be based on:
- salt concentration,
- pH or
- sensory parameters.
The limits should be scientifically justified.
Before the project moves to the next step, the remaining risk
after implementing CCPs and critical control is evaluated and the
team repeats the risk evaluation.
5. Establish a Monitoring Procedure
Monitoring is a planned sequence of observations or measurements
to assess whether a CCP is under control and to produce an accurate
record for future use in verification. The monitoring system must be
able to detect loss of control at the CCP. It should be either
continuous or done at a sufficient frequency that the detection is
available in time to ensure that corrections are possible before any
harm occurs. To avoid violation of limits as much as possible,
tighter control limits should be defined where corrective actions
are initiated before the critical limit is exceeded. All records and
documents associated with CCP monitoring should be dated and signed
or initiated by the person doing the monitoring. Examples of
monitoring activities include:
- Visual observations and
- measurement of temperature, time, pH and moisture level.
6. Establish Corrective Actions
For each observed limit violation a corrective action should be
initiated. Subject matter experts should determine the root cause
for the violation and suggest corrective actions. Corrective actions
should include the following elements:
- Determine and correct the cause of non-compliance.
- Determine the disposition of a non-compliant product.
- Record the corrective actions that have been taken.
Specific corrective actions should be developed in advance for
each CCP and included in the HACCP plan. As a minimum, the HACCP
plan should specify:
- What is done when a deviation occurs,
- who is responsible for implementing the corrective actions,
- that a record will be developed and maintained of the
The corrective action should be extended to similar CCPs to avoid
further violation of limits. The action plan should be verified for
7. Establish Verification Procedures
Verification is defined as those activities, other than
monitoring, that determine the validity of the HACCP plan and ensure
that the system is operating according to the plan. Another
important aspect of verification is the initial validation of the
HACCP plan to determine:
- That the plan is scientifically and technically sound.
- That all hazards have been identified and that the HACCP
plan is properly implemented.
- That these hazards will be effectively controlled.
Verification procedures should be implemented to determine
whether the HACCP system is working effectively or not. Examples for
verification activities include review of the HACCP plan for
completeness, CCP monitoring records, deviations and corrections,
validation of critical limits to confirm that they are adequate to
control significant hazards and confirmation that CCPs are kept
under control. Verification should be conducted, e.g., routinely or
on an unannounced basis, to confirm that changes have been
implemented correctly after the HACCP plan has been modified and to
assess whether a HACCP plan should be modified due to a change in
the process equipment. Verification records can include, for
example, the HACCP plan and the person(s) responsible for
administering and updating the HACCP plan, certification that
monitoring equipment is properly calibrated and in working order and
training and knowledge of individuals responsible for monitoring
8. Document and Communicate all Activities
Accurate documentation and communication is essential for the
success of the HACCP project. Documentation should be developed
according to the progress of the project and not just at the end.
Important steps should be communicated to everybody who is affected
by the project throughout the development and at the end of the
Records should be retained to document that the HACCP project has
been conducted according to documented HACCP requirements. They are
unavoidable to demonstrate compliance in case of any product
liability issues. Records can be retained in any format, e.g., paper
and electronic versions. Examples for records that should be
- A summary of the hazard analysis, including the rationale
for determining hazards and control measures.
- The HACCP plan.
- Training records of the key project leader and HACCP team
- Records generated during the operation of the plan.
Hazard and Operability Studies (HAZOPs)
HAZOP examines a planned or existing product, process, procedure
or system. It identifies risks to people, equipment and environment.
HAZOP also includes steps for risk mitigation. The HAZOP team
identifies failure modes of a process or system and possible causes
and consequences similar to FMEA. While FMEA starts by identifying
failure modes, HAZOP considers unwanted outcomes and deviations from
intended outcomes and works back to possible causes.
Characteristic for a HAZOP process is the use of guide words such
as "No or Not, More, Less, Part of and Compatible".
HAZOP was initially developed to analyze chemical process systems
and was extended to other complex mechanical, electronic and
software systems. It is usually undertaken during the design stage
of software and hardware development.
Steps of HAZOPs include:
- Appointment of project leader and project team. The team
should include personnel not directly involved in the design of
the project or process.
- Definition of objectives.
- Establishing a set of guide words.
- Collection of the required documentation.
- Splitting the system or process into smaller pieces and
subsystems and reviewing the relevant documentation.
- Defining and recording deviations, possible causes, actions
to address the identified problem and person(s) responsible for
the corrective action.
- Evaluating the remaining risk for deviations that cannot be
Preliminary Hazard Analysis (PHA) and
Preliminary Risk Analysis (PRA)
Preliminary Hazard Analysis (PHA) is a qualitative, inductive
tool for risk analysis. Sometimes PRA and PHA are interchangeably
used where PRA includes an evaluation of impact and probability.
PRA/PHA are based on applying prior experience or knowledge of
hazards to identify future hazards. They are especially useful to
identify and reduce risks early in a new or changed process. In the
context of this chapter we also mean PHA when we talk about PRA.
Steps of a PRA methodology include:
1. Form a Project Team
As the success of the method relies on experience with historical
knowledge, team members should include subject matter experts with
experience in similar projects. If such information is not available
external consultants should be hired. The team leader should have
experience in FTA projects.
2. Create a Project Plan
The plan is created by the team under the supervision of the team
leader. It includes background information on why the project has
been initiated and describes the approach the risk project will
follow as well as the scope, responsibilities, tasks and
deliverables. A schedule is also included. The plan follows the
rules of the company's Risk Management Master Plan. The plan also
describes the approach to define which activities will be analyzed.
3. Describe the Situation
The situation is described by the teams technical subject matter
experts. All relevant information is collected and distributed to
other team members in preparation for the hazard identification
step. The package also includes a proposal on which part of the
project will be covered by the PRA methodology. Furthermore the
preparation package also includes forms and recommendations on how
to complete them in preparation for the hazard identification
meeting. For complex projects a special training should be organized
to ensure that the process is well understood and so that the team
members can give meaningful inputs.
4. Identify Hazards
Hazards are best identified in a brainstorming meeting. All
suggestions for potential hazards are collected and documented. The
suggested hazards are grouped into categories, for example, product
characteristics, processing steps or operational phases, such as
start-up or normal operation. When all potential hazards have been
identified and categorized they are reviewed and compared with each
other. The team leader will put all suggested potential hazards up
for discussion and the group decides to leave them or remove them
from the list. This should ensure that only credible failures are
retained. An important criterion on whether to leave a hazard on the
list or not is if there are currently controls in place to reduce
the risk. Only listed hazards without sufficient control will stay
on the list.
5. Estimate the Probability of Occurrence and Severity
The final risk is estimated through looking at the probability of
occurrence and the severity of identified hazards. For probability
and severity assessment, controls already in place are considered.
Results are either expressed qualitatively, e.g., high, medium and
low or through more specific descriptions or quantitatively if
sufficient data are available.
6. Prioritize Risks for Control
For hazards exceeding the acceptable risk thresholds the team
defines controls to reduce the risk. The residual risks are
evaluated again using the same criteria as before.
7. Prepare a Report
The report should include a description of the process, the study
objectives and scope, the methodology and the identified hazards
with justifications. The report should also include the result of
risk assessment with justifications and additional controls put in
place for hazards with too high risks.
Steps for Effective Risk Management
Previous chapters of this tutorial gave an overview on regulatory
requirements. We also described the ICH Q9 process for risk
management. In addition various tools and methodologies have been
presented on how to implement risk assessment and risk management
for various situations. While most tools have advantages but also
limitations this chapter describes a generic approach and
recommended steps for risk management. The overall process and
individual steps are outlined in Figure 10 with more details on each
step following in this chapter.
Figure 10: Risk Management Process and Steps
The process is initiated by management based on inputs from
functional managers. Management also appoints a project leader who
drafts a preliminary project plan. The project leader assembles a
project team that finalizes the project plan.
In the risk analysis step team members suggest, sort, combine and
prioritize hazards and harms. Team members then determine the risk
using severity and probability and optional detectability as
criteria. If the risk is below the acceptance criteria the project
goes into the monitoring phase or is discontinued. This is to
monitor the process for some time to verify that the risk level was
correctly determined and/or to check if new hazards arise.
If the risk is higher than the acceptance criteria a risk
mitigation plan is initiated and implemented. The residual risk is
determined using the same procedure and criteria as for the first
The outcome of the risk assessment and management is documented
and communicated during and at the end of the process.
Step 1: Project Preparation and Planning
The risk management process requires detailed preparation and
planning. This step includes project initiation and identification
of a project manager and a project team.
A risk management project can be proposed by anybody. The
proposal should be forwarded to functional managers who review it
and then forward it to higher management. The proposal should
- Description of the potential risk management project.
- Definition of potential problems with some examples for
hazards and harms.
- Background information.
- Benefits of the proposed project.
- List of departments that should be part of the project.
Identification of the Project Manager and Team
Once the decision is made to initiate a risk management project
management identifies a project leader. Selection criteria for the
project owner are:
- Experienced in risk management.
- Project management skills.
- Excellent communication skills.
- Knowledge of the organization, system, process or
application being assessed.
- Ability to manage people without direct reporting.
Tasks of the project owner include:
- With the help of functional managers selects a risk
- Manages the entire process.
- Ensures necessary resources.
- Organizes and chairs team meetings.
- Drafts the risk management project plan.
- Represents the team in management meetings.
- Communicates the status and outcome of the project to
management and peers.
One of the first tasks of the project leader is to recruit a
team. The team should include members from all affected areas and
- Affected operations (product development, manufacturing).
- Project management.
- Information Services (IS).
- Quality Assurance (QA).
- Legal department.
- Quality Control (QC).
- Plant safety, maintenance and engineering.
- Regulatory affairs.
- Sales and marketing.
- Suppliers (optional).
Team members should be subject matter experts with at least five
or more years experience in the related subject. General
responsibilities of the risk management team are defined for each
function in the Risk Management Master Plan.
Define Team Responsibilities
Risk management involves several departments, functions and
personnel which requires good organization. For example, tasks and
responsibilities should be well defined for everybody. The Risk
Management Master Plan can be used as a guideline where the master
plan allocates responsibilities only to job functions and not to
individual persons. For a specific project, responsibilities can be
defined for individuals by name in addition to functions.
- Provides evidence of their commitment to the risk management
- Provides necessary resources.
- Defines and documents the policy for determining criteria
for risk acceptability.
- Approves the Risk Management Master Plan.
System User Departments
- Contribute to development and maintenance of Risk Management
- Create and maintain equipment inventory.
- Give inputs on potential hazards with estimation on severity
and probability for initial RM.
- Monitor efficiency of ongoing RM and give inputs on new
- Advises the facility/laboratory on possible hazards and
harms related to environment and staff safety.
Information Services (IS)
- Advises the facility on possible hazards and harms related
to IT, e.g., security.
- Participates in risk assessment and mitigation.
- Reviews Risk Management Project Plans related to networks.
Risk Management Team
- Develops and maintains the Risk Management Project Plan.
- Provides expertise to develop and implement RM for processes
and systems during development and during initial and ongoing
- Responsible for risk assessment and the final decision on if
and how to mitigate risks.
Quality Assurance (QA)
- Provides quality assurance expertise in the creation of the
risk management plans.
- Monitors regulatory requirements and develops and updates
company policies for RM.
- Develops and coordinates a training program on RM.
- Gives inputs for risk analysis and participates in risk
- Reviews and approves individual Risk Management Project
Plans and deliverables.
- Some of the activities can be outsourced to consultants,
e.g., identification and classification of risks.
- Inform users on potential risks arising from known software
bugs and provide workaround solutions.
- Get trained on risk assessment and management.
- Provide inputs on hazards and possible harms for new and
ongoing risk management projects.
Create a Risk Management Project Plan
Using the company's Risk Management Master Plan as a source
document, the project leader with the help of the team creates the
Risk Management Project Plan. While the Risk Management Master Plan
(RMMP) is a framework and applicable to all projects, individual
projects should be covered by the Risk Management Project Plan
(RMPP). The relationship between both these plans is shown in Figure
Figure 11: Risk Management Master Plan and Risk Management Project Plan
The project plan outlines how risk assessment is conducted, the
steps and procedures the project team will implement and who is
doing what. It also includes a time schedule and defines
deliverables for each step. The draft also includes proposals for
risk thresholds. The project leader presents the plan to management.
Management reviews the plan and discusses the suggested steps and
risk thresholds with the team in a meeting.
This is the most important step in the entire project. The
acceptable risk threshold will determine the costs for reducing the
risk but also associated costs or other problems that can arise if
risks are not reduced. Functional managers from accounting, QA and
operations should indicate priorities for how much risk the company
can take. Most likely different functions will have different
priorities. For example, when looking at the graph in Figure 1x QA
tends more towards the right side of the graph with 100% quality,
whereas finance most likely wants to save on project cost which is
only possible if a trade-off is made between risk and quality.
The Risk Management Project Plan should include chapters on:
- The purpose should be specific to the system and should
include a short system description.
- The scope defines what is and what is not covered by the
plan. It also documents constraints and limitations.
- This section describes responsibilities of corporate
management, the operations manager and staff, IT managers and
staff and the risk management team. Unlike the master plan the
project plan lists responsible people by name AND function,
rather than by function only.
- Describes the approach taken for managing the risk.
- Describes how risks, hazards and potential harms are
identified and documented. Includes tables with risks, hazards,
harms and suggestions for mitigation.
- Describes how risks are evaluated, categorized, prioritized
and documented. It includes matrices with risks, categories for
probability and severity and risk codes.
- Documents risk threshold values for the project.
- Evaluates alternatives of risk mitigation versus costs.
Describes actions in case mitigations are required. It also
includes a time schedule for actions and estimates and documents
residual risk priority numbers after mitigation.
- Compares risk threshold as originally defined with the RPN
obtained after mitigation. Based on the outcome the residual
risk is accepted rejected.
- Describes how risks are monitored, reported and documented
during use of the system. Describes the actions in case new
hazards are reported or if the risk level has changed.
- Outlines action items with owners.
Step 2: Risk Identification
Step 2 in the risk management process is risk identification. It
should answer the question: What are the potential problems that
could occur? All activities in a process under consideration are
documented. Potential risks are identified by the project team under
the leadership of the project leader. If there is little or no
experience with risk identification within a company, outside
resources who have worked on similar projects should be invited to
give their opinion. They can help to identify or discover potential
problems based on experience with similar projects. The output of
this phase is the input for risk evaluation.
Inputs for risk identification are:
- Customer complaints.
- Failure investigations.
- Corrective and preventive action plans.
- Specifications for processes and systems.
- Experience with the same process or system already installed
- Experience with similar processes and systems.
- Experience with suppliers of the system and suppliers of
material used for the process.
- Failure rates of the same or similar systems and processes.
- Trends of failures.
- System and process validation reports.
- Service records and trends.
- Internal and external audit results.
- FDA inspection reports.
Inputs can come from engineers, operators of equipment and
processes, the validation group, IT administrators or from QA
personal, e.g., as a result of internal and external audits or
The project team collects inputs on potential hazards with
possible harms. Information is collected during a brainstorming
meeting. All inputs should be accepted and documented. The project
leader should make sure that all ideas are well understood by team
members. Initial documentation can be made on a flip chart or self
adhesive notes that can be easily moved around to group similar
risks into categories and to eliminate double-quoted identical risks
or combine similar risks into single ones.
The team prioritizes all risks that are considered for follow-up.
The list of selected risks can be compared with a checklist that has
been created from other projects. This should ensure that nothing
important has been left out.
For final documentation a form as shown in the table in Figure 12
or similar should be used with entry fields for the person who made
the entry, risk description, impact on system availability, data
integrity, compliance, typical situations of occurrence and
suggestions for mitigation.
Risk description, hazard, typical situations of
Suggestion for risk control
Figure 12: Form for Risk Identification
At this point typical situations of occurrence, possible harms
and suggestions for risk control are described expressing
everybody's thoughts and experience rather than thinking about
categories. For example, contributors should describe the estimated
time intervals and special circumstances under which the process or
system can fail.
Step 3: Risk Evaluation
After information on risks has been collected, the risk
evaluation phase starts. This phase compares the identified risks
against given risk criteria. It should be determined which risks are
the most important ones to focus on and put into the risk mitigation
plan. The output of this phase is a quantitative estimate of risk or
a qualitative description of a range of risks. Most critical is to
use objective ranking criteria for severity and probability. For
more details on how this is best achieved see the section
"Approaches for Risk Management" in the chapter "Criteria for
Severity, Probability and Risk Acceptance".
For implementation the project leader calls for a workshop. Each
risk as prioritized and documented in the identification phase is
presented by the risk owner who also makes a proposal for numerical
severity and probability factors together with a justification. The
proposal is discussed with the team and either accepted as it is,
accepted after a change of severity and/or probability factors, or
rejected. Rejection should rarely happen because the risk has been
prioritized in a previous meeting. One reason for removing a risk
from the list would be if the assumptions have changed since the
risk identification step.
Numbers are associated to the levels and the overall risk
priority number (RPN) is calculated. Figure 13 shows a template on
how to document the impact (severity) of non-patient business risk,
the impact on patient health and the probability.
The RPN is calculated using the formula:
RPN = S (Business) x S (Patient) x P
On a scale of 1 to 27 the RPN is calculated as 18.
Risk description /ID
Impact on patient health (Level 1-3)
Impact on business continuity (Level 1-3)
Occurrence (Level 1-5)
Risk priority number
Figure 13: Form for Risk Evaluation
Step 4: Risk Acceptance
Risk acceptance is a formal decision to accept a risk. In this
step we analyze the countermeasures that we put in the risk response
table based on risk priorities. Starting point is the risk priority
number as calculated from probability and severity and the risk
threshold as defined for the project. The risks should be put into
three categories as defined in Figure 14.
The impact on each identified risk is evaluated using the same
criteria as defined in Step 3. RPNs are calculated and compared with
the original risk threshold. Residual risks are accepted as long as
the risk priority number is below the risk threshold. Lets assume
the RT for the project is defined as 5 on a scale of 1-10. The
normalized RPN is:
16/27 x 10 = 6.6
This means the risk is not acceptable.
|Factor 8 and
|Routinely accepted, no action taken.
|Operation requires written,
time-limited waiver endorsed by management. Mitigation
subject to cost/benefit analysis.
|Factor Higher than
16: Code 3
||Not accepted. Mitigation required.
Alternative approaches should be evaluated.
Figure 14: Definition of Risk Codes and Consequences
All risks with factors higher than 16 (Code 3 = High Risk) should be reduced
or eliminated and all risks with factors higher than 8 (Code 2 = medium risk)
should be considered for mitigation and are subject to a cost benefit analysis.
Step 5: Risk Mitigation
When the risk as evaluated in the previous step is not
acceptable, alternatives on how to mitigate risks should be
evaluated. This phase is also called Risk Treatment.
Figure 15 is used to document the mitigation strategy, costs for
mitigation and non-mitigation and the decision whether to mitigate
the risk or not.
Risk description /ID
Cost of mitigation
Cost of non-mitigation
Figure 15: Form for Risk Mitigation
Possibilities to Mitigate Risks
There are different ways and approaches to mitigate risks.
All risk mitigation options should be considered and can be
- Removing the risk source (eliminating the risk).
- Changing the likelihood.
- Changing the consequences.
- Ensuring that the risk is detected and can be treated when
- Sharing the risk with other parties.
Care should be taken that mitigation strategies do not introduce
new risks into the process or increase existing risks in other
After the risk is reduced it is evaluated again using the same
criteria as before. If the risk was acceptable the project moves
along to the last step for documentation, communication and ongoing
review for possible changes.
Estimating Costs vs. Benefits
The initial and ongoing costs for the best alternative should be
estimated and compared with the estimated costs of non-mitigation.
For risk codes 2 (medium risk) this comparison should be the basis
for the decision whether to mitigate risks or not. The rationale
behind the decision should be well justified and documented.
It is important to estimate the cost for mitigation as well as
potential losses through non-mitigation. Losses for non-mitigation
should include real or direct costs and tangible or indirect costs.
Real costs are loss of revenue and are relatively easy to estimate.
Tangible costs are more difficult to estimate. They can include
damage to a company's reputation or appearing on the FDA's radar
after one or more failed FDA inspection.
Risk Mitigation Plan
Once the decision to mitigate the risk has been made and the
strategy is identified, a mitigation plan should be developed. The
plan should describe:
- Mitigation options.
- How options will be implemented.
- Resource requirements.
- Performance measures.
- Required documentation.
- Communication requirements.
After the plan is implemented the residual risk is evaluated and
is subject to monitoring.
Step 6: Ongoing Monitoring, Reviews and Updates
Once the plan is in place and the system is running, the
effectiveness of the plan should be monitored, reviewed and adjusted
if necessary. The monitoring program should also help to identify
previously unrecognized hazards. These could have been introduced by
changing processes or introducing new technologies.
The monitoring program should check if risk priority numbers have
changed to either higher or lower values. Users and IT professionals
gain a lot of experience that can be used to further optimize the
effectiveness. If factors exceed the previous specified limit,
mitigation strategies should be evaluated. If higher values decrease
below the threshold, mitigation may no longer be necessary which can
save operating costs.
Contributors use the form in Figure 16 to document observations
and to make recommendations. They should also make a recommendation
if the change should be implemented urgently if it is time critical.
Risk description /ID
Recommendation for change
Figure 16: Form to Recommend Changes
The risk management team evaluates the recommendations made by
contributors. The team meets monthly if there are no recommendations
for changes classified as 'urgent'. In the case of an urgent
recommendation for a change the team meets and evaluates the change
within a week. Changes or additions are documented using the form in
Risk description /ID
Figure 18: Form to Document Changes
Step 7: Documentation and Communication
Regulatory agencies strongly suggest basing decisions for details
of compliance with GxP on a justified and documented risk
assessment. Therefore documentation is very important. Documentation
is also important to justify investments as they may be required to
meet business and compliance requirements. Complete documentation
for risk management should include:
- Risk Management Master Plan - This shows your company's
approach towards risk assessment and risk management.
- Risk Management Project Plan - This shows the plan for
specific system and mitigation strategies.
- Lists with description of risk categories, ranking criteria
and results of ranking.
- Justification for not mitigating risks with high factors.
- Risk mitigation plans.
- Mitigation actions taken
- Review reports.
The information should be communicated with everybody who may be
affected by the project. The information should not only be shared
toward the end of the project but this should be ongoing from the
start. Most important is to openly share all information that leads
to decisions about factors for probability and severity factors and
whether to mitigate certain risks or not.
The Risk Management Process can be applied for:
- Design and development of a product or process.
- Selection and assessment of suppliers.
- Training, especially proof of effectiveness.
- Risk-based computer validation.
- Risk-based qualification of analytical equipment.
- Part 11 compliance.
- Pharmaceutical manufacturing.
- Scheduling internal audits.
- Starting material - qualification and handling.
- Validation of analytical procedures
- Qualification of equipment
- Change control to introduce new starting material.
- Archiving electronic records.
To be completed later
Some of the risk-based definitions are original or derived from
either ISO/IEC Guide 51:1999 or ANSI/AAMI/ISO 14971:2000.
CCP Decision Tree
A sequence of questions to assist in determining whether a
control point is a CCP (Ref. 32).
Critical Control Limit (CCL)
A maximum and/or minimum value to which a biological, chemical or
physical parameter must be controlled (Ref. 32).
Any action or activity that can be used to prevent, eliminate or
reduce a significant hazard (Ref. 32).
Procedures followed when a deviation occurs (Ref. 32).
Critical Control Point (CCP)
A step at which control can be applied and is essential to
prevent or eliminate a (pharmaceutical) quality hazard or reduce it
to an acceptable level (Ref. 30).
Termination of the ability of an item to perform a required
function (IEC 60812:20067).
Manner in which an item fails (IEC 60812:20067).
FMEA - Failure Modes and Effects Analysis
Used to identify failure modes and their consequences or effects.
FMEA is a bottom-up technique: What can go wrong on a low level
component and how this impacts the system or application.
FMECA - Failure Modes, Effects and Criticality Analysis
Adds evaluation of the criticality including severity, occurrence
and detectability to the FMEA.
FTA - Fault Tree Analysis
Top-down technique. The analyst looks at the high-level system
failure and proceeds down into the system to trace failure paths.
HACCP ï¿½ Hazard Analysis and Critical Control Points
A systematic approach to the identification, evaluation and
control of food safety hazards (Ref. 32).
The written document which is based upon the principles of HACCP
and which delineates the procedures to be followed (Ref. 32).
The result of the implementation of the HACCP Plan (Ref. 32).
Physical injury or damage to the health of people, or damage to
property or the environment (ISO 14971).
Potential source of harm (ISO 14971).
In the context of HACCP: Any circumstance in the production, control
and distribution of a (pharmaceutical) product which can cause an
adverse health effect (Ref. 30).
Hazard: A biological, chemical or physical agent that is reasonably
likely to cause illness or injury in the absence of its control
The process of collecting and evaluating information on hazards
associated with the food under consideration to decide which are
significant and must be addressed in the HACCP plan (Ref. 32).
To conduct a planned sequence of observations or measurements to
assess whether a CCP is under control and to produce an accurate
record for future use in verification (Ref. 32).
Validation (related to HACCP)
That element of verification focused on collecting and evaluating
scientific and technical information to determine if the HACCP plan,
when properly implemented, will effectively control the hazards
Verification (related to HACCP)
Those activities, other than monitoring, that determine the
validity of the HACCP plan and that the system is operating
according to the plan (Ref. 32).
National Institute of Standards and Technology.
Probability/Impact equal to RPN (Risk Priority Number).
The Pharmaceutical Inspection Convention and Pharmaceutical
Inspection Co-operation Scheme (jointly referred to as PIC/S).
PHA - Preliminary Hazard Analysis
Can be used to identify hazards and to guide development of
countermeasures to mitigate the risk posed by these hazards.
PRA - Preliminary risk analysis
Probabilistic risk assessment.
Probability of Detection
Evaluates the probability of realizing that the hazard has
occurred before the resultant harm to the patient has occurred.
QRAS - Quantitative Risk Assessment System
Developed for NASA by the University of Maryland.
Risk remaining after protective measures have been taken (ISO
Combination of the probability of occurrence of harm and the
severity of that harm. Combination of the probability of harm and
the severity of that harm (ISO 14971:2007).
The decision to accept risk (ISO Guide 73).
Systematic use of available information to identify hazards and
to estimate the risk (ISO 14971:2007).
A systematic process of organizing information to support a risk
decision to be made within a risk management process. It consists of
the identification of the hazards, and the analysis and evaluation
of risks associated with the exposure of these hazards (ICH Q9).
Overall process of risk identification, risk analysis and evaluation
The sharing of information about risks and risk management
between the decision maker and the stakeholder.
The process through which decisions are reached and implemented
for reducing risks to, or maintaining risks within, specified
Process in which decisions are made and measures implemented by
which risks are reduced to, or maintained within, specified levels
Terms or reference against which the significance of a risk is
evaluated (ISO Guide 73:2009).
Process used to assign values to the probability of occurrence of
harm and the severity of that harm (ISO 14971:2007).
Process of comparing the estimated risk against given risk
criteria to determine the acceptability of the risk (ISO
The comparison of the estimated risk to given risk criteria using a
quantitative or qualitative scale to determine the significance of
The systematic use of information to identify potential sources
of harm (hazards) referring to the risk question or problem
A semi-quantitative measure of risk which is an estimate derived
using a scoring approach using ordinal scales (IEC/ISO 31010).
A quantitative estimate that describes the level of degree of
risk. The value is added based on quantitative values assigned for
public health (severity), regulatory risk and business risk. For the
purpose of this standard the risk is expressed as high, medium or
low based on the degree of regulatory risk and patient/user risk.
Systematic application of management policies, procedures and
practices to the tasks of analyzing, evaluating, controlling and
monitoring risks (ISO 14971:2007).
Actions taken to lessen the probability of occurrence of harm and
the severity of that harm.
Review of monitoring of output/results of the risk management
process considering (if appropriate) new knowledge and experience
with the risk.
Risk Priority Number
Measure of overall risk. It is obtained by multiplying the rating
of severity, occurrence (and probability of non-detection). The
higher the number the more serious the risk.
Process of selection and implementation of measures to modify
Measure of the possible consequences of a hazard (ISO
Risk that is accepted in a given context based on the current
values of society.
RMMP - Risk Management Master Plan
Framework which is applicable to all projects. Used as a source
to draft Risk Management Project Plans.
RMPP - Risk Management Project Plan
While the Risk Management Master Plan (RMMP) is a framework and
applicable to all projects, individual projects should be covered by
a Risk Management Project Plan (RMPP). It outlines risk management
activities specific to the project. The RM Master Plan should be
used to draft this plan.
Person or organization that can affect, be affected by, or
perceived themselves to be affected by, a decision or activity (ISO
- The European Council Directive 93/42/EEC of 14 June 1993
Concerning Medical Devices.
- FDA 21 CFR 820: "Quality System Regulation (for Devices)".
- EU GMP, Annex 15: "Validation and Qualification", 2010.
- FDA: Pharmaceutical cGMPs for the 21st Century: "A
Risk-Based Approach: Second Progress. Report and Implementation
- FDA Industry Guidance: "Part 11, Electronic Records;
Electronic Signatures - Scope and Application", 2003.
- ICH Q9: "Quality Risk Management", 2005.
- GAMP 4: "Guide for Validation of Automated Systems", 2001.
For ordering go to:
- GAMP 5: "A Risk-Based Approach to Compliant GxP Computerized
Systems", 2008. For ordering go to:
- GHTF: "Implementation of Risk Management Principles and
Activities within a Quality Management System", 2005.
- ISO 14791:2007: "Application of Risk Management to Medical
- ISO 31000: "Risk Management" Principles and Guidelines",
- ISO 31010: "Risk Assessment Techniques", 2009.
- R. Jones, Pharmaceutical Manufacturing: "How to Understand
the Process and Assess the Risks to Patient Safety",
Pharmaceutical Engineering, November 2009, 16.
- I. Campbell: "Applying Quality Risk Management Principles to
Achieve a Practical Verification Strategy", Pharmaceutical
Engineering, November 2009, 24-38.
- L. Huber (15): "Risk-Based Validation of Commercial
Off-the-Shelf Computer Systems", Journal of Validation
Technology, 11(3), 2005.
- Labcompliance: "Risk Management Master Plan", 2010.
- Labcompliance SOP: "Risk Assessment Used for Systems Used in
- Labcompliance SOP: "Risk Assessment for Laboratory Systems",
- Labcompliance SOP: "Risk-Based Qualification of Network
- Labcompliance Case Studies: "Risk-Based Methodologies for
- FDA Guidance: "General Principles of Software Validation",
- FDA Guidance for Industry: "Quality Systems Approach to
Pharmaceutical CGMP Regulations", (2006).
- EU GMP, Annex 11: "Using Computerized Systems".
- Pharmaceutical Inspection Convention/Cooperation Scheme
(PIC/S): "Good Practices for Computerised Systems in Regulated
- United States Pharmacopeia: <232> Elemental Impurities
- USP Chapter <467> Residual Solvents.
- FDA Guidance: "FDA Reviewers and Compliance on Off-The-Shelf
Software Use in Medical Devices", 1999.
- FDA Guidance: "Inspections of Quality Systems" (Medical
Devices), ORA Inspectional References.
- PIC/S Quality Risk Management: "Implementation of ICH Q9 in
the Pharmaceutical Field", 2010.
- Report by WHO Expert Committee on "Specifications for
Pharmaceutical Preparation", Annex 7, Application of HACCP
Methodology to Pharmaceuticals, 2003.
- FDA Guidance: "Fish and Fisheries Products Hazards and
Controls", Appendix 3, 2001.
- National Advisory Committee on Microbiological Criteria for
Foods, "HACCP Principles and Application Guidelines", 1997.
- J.L. Vesper: "Risk Assessment and Risk Management in the
Pharmaceutical Industry: Clear and Simple", Davis Healthcare
International Publishing, LLC, ISBN 1-930114-94-X, 2006.
- Concept Heidelberg: "Risk Management in the Pharmaceutical
Industry", Editio Cantor Verlag, 2008, ISBN 978-3-87193-370-7.
- K. O'Donnel and A. Greene: "A Risk Management Solution
Designed to Facilitate Risk-Based Qualification, Validation and
Change Control Activities within GMP and Pharmaceutical
Regulatory Compliance Environments in the EU", Part I:
Fundamental Principles, Design Criteria, Outline of Process,
Journal GXP Compliance, 10 (4) 12-25 (2006).
- K. O'Donnel and A. Greene, "A Risk Management Solution
Designed to Facilitate Risk-Based Qualification, Validation and
Change Control Activities Within GMP and Pharmaceutical
Regulatory Compliance Environments in the EU", Part II: Tool
Scope, Structure, Limitation, Principle Findings and Novel
Elements, Journal GXP Compliance, 10 (4) 26-35 (2006).
- ISO/IEC Guide 73:2002: "Risk Management - Vocabulary",
Guidelines for Use in Standards".