Risk Assessment Templates


I’m trying to develop a strategy which will use risk assessment to narrow computer system validation scope. I’ve read through the GAMP5 recommendations and they seem very sensible. But my difficulty is that the GAMP5 recommendations are at quite a high level and very conceptual. Does anybody have any concrete examples of how to implement the GAMP recommendations?


Thats a pretty broad question.

Perhaps you could provide us with your scenario and we will throw out
a few suggestions.

A simple example of providing a risk based approach is the following:

Scenario: You have a software application where inputting the date into required fields is essential to an expiry on a product. The date field is obtained from a pop up window where a calender is used to show the user all the dates they require (Similar to booking a flight on a travel website)

The problem is that this date pop-up is used in 150 different locations in the application.

Do you test all locations?

After a risk assessment it was discovered that the date pop-up is being called from one class in the code i.e from only one location.

As the same class is called each time there is no extra benefit in testing this functionality 150 different times, hence testing will be performed at one location only in the software.

Due to our risk assessment we have reduced this testing from 150 to 1 and also we are satisfied that we have perfomed comphrensive testing on this functionality.

This is a very simple example, but I hope it demonstrates somewhat, what is required.


We do Risk Assesment by selecting GMP and NON GMP critical transaction codes from each module and check for its authorization objects.
Graham is there any standard protocol or format? kindly through some light

[quote=satishcrown]We do Risk Assesment by selecting GMP and NON GMP critical transaction codes from each module and check for its authorization objects.
Graham is there any standard protocol or format? kindly through some light

I’m not sure if there is any standard protocol or format that can be used, but a good starting point might be to generate flow diagrams of the GMP critical and non critical paths and detail the level of testing through that.

I guess it depends on the application in question, I would be interested to hear if there is a standard approach for this type of testing.



We define RA process as follows with some examples. Does this help in understanding? Do let me know.

(A) GxP Determination

• List down various processes which have been automated.

(B) System Impact

Next step is to identify use of Automated System and find its direct impact on following criteria:

• Impact on generating, manipulating or controlling data supporting regulatory safety and efficacy submissions.
• Impact on control of critical parameters or data used
• Impact on control of data for product release
• Impact on control of data required in case of product recall
• Impact on controlling adverse event or complaint recording

© Functional Risk Assessment

Further, processes are listed and evaluated for assessment of risk to either product quality and data integrity. It involves mainly following steps. These are based on GAMP 5 directly.

  1. Identifying GxP Risk
  2. Identifying Risk Scenarios
  3. Assessing the likelihood of An Adverse Event
  4. Assessing the severity of impact
  5. Detection of adverse impact
  6. Overall priority

These steps are explained below.

Point number 1 & 2 are linked with User Requirement Specification document.
Point no. 3, 4 and 5, ascertains the prioritization of risk in High/Medium/Low categories.
Pt. 6 covers the overall priority on the basis of results obtained in 3,4 and 5 using RPN numbering methodology.

  1. Identifying GxP Risk

System function parameters are evaluated and identified whether they represent a risk when assessed against a series of GxP criteria.

Following types of risks are mainly identified during risk assessment process for use of automated systems in regulatory environment:

• Risks towards non-availability of required documentation
• Risks towards non-availability of required SOPs
• Risks towards non-availability of system Access Control
• Risks towards abnormal user operation performed at the time of system operation
• Risks towards incorrect configuration of system
• Risks towards Improper and/or inadequate training
• Risks towards implementation of US FDA 21 CFR Part 11 rule

  1. Identifying Risk Scenarios

Having determined that a particular function may have a GxP risk associated with it, the assessment proceeds to identify the various risk scenarios i.e. the events that identify the risks associated with use of the system.

The functions identified are analyzed by considering possible hazards/adverse effects and what controls may be needed to minimize the potential harm.

2.1 Assessing the Likelihood of An Adverse Event

After identifying hazards / adverse events, determine the likelihood (frequency or probability) of it occurring. User considers the likelihood of the adverse event occurring per number of transactions, and assigns a value to that estimate.

Ranking of likelihood methods are defined as follows:

The processes which are internally controlled by software (user can’t modify) and have been tested thoroughly during software development, may be considered as ‘Low’ risk. Such risks may fall in ranking of likelihood 1 to 3 from the Table – I ( Not attached here) below. For example: Display parameters, print records.

The processes which are controlled by users and are due to possibility of human error and non-availability of system control may be considered as ‘Medium’ risk. Such risks may fall in ranking of likelihood 4 to 6. For example: Change in set parameters, change in recipe.

In many instances adverse events may be as the result of the systematic software faults, such as software bugs and the team may be unable to estimate the likelihood of such an adverse event. In such instances the likelihood ranking should be in range of 7 to 10.

2.2 Assessing the Severity of Impact

After determining likelihood of adverse event, severity of its impact on process is assessed. These effects take into account impact on regulatory compliance, impact on product quality and impact on data integrity.

The impact of risk occurring may be described as follows:

The processes which do not directly affect the final output of the system/software may fall in ranking of severity 2 to 4. For example: Warning messages, reference parameters, etc.

The processes which are used in the initial stage of operation, however it may affect the final output but those are not used for final release of output, may fall in ranking 5 to 6 of severity. For example: System alarms, power failures, communication failure, etc.

The processes which are used in the final stage of operation and are used for final decision for output may fall in ranking 7 to 10 of severity. For example: set parameters, selection of recipe, selection of operation, print record, display record

2.3 Detection of Adverse Event

Next step is to identify if the adverse event can be recognized or detected by other means in the system. Adverse event having high probability of detection, may not pose a serious threat because it can be recognized quickly and suitable corrective action taken to mitigate its impact. If an adverse event has a low probability of detection, then the risk condition needs to seriously consider a review of the design or the implementation of alternative procedures to avoid the event.

Adverse event is detected at final stage of output or after release of output or may not be detected, may fall in ranking 6 to 10 of probability of detection. For example: Non-availability of SOP, usage of SOP, Training, wrong selection of operation etc.

The processes with adverse events are advanced to next stage of operation; however that adverse event can track down before final release of output may fall in ranking 4 to 5 of probability of detection. For examples: wrong selection of set parameters.

The processes with adverse events which are identified by system and highlighted with error message may fall in ranking 1 to 3 of probability of detection. For example: alarm message, trip conditions, etc

  1. Overall Priority

Overall priority is calculated using RPN number methodology. RPN means Risk Priority Numbering and in it multiplication of the all three assessments are done.

RPN = Severity x Occurrence x Detection

I have not attached any tables as mentioned above, however I hope that this may throw more light on actual assessment.

Based on above, you may create a table having various risk scenarios at left side and columns of impact of failure, point 2.1, 2.2, 2.3 and 3 at right side.
This may help you to quantify the RA process and determine mitigation strategies.

Hope above is useful.


Jaydeep D. Chhatrapati
Epitome Technologies Pvt. Ltd.

[quote=satishcrown]We do Risk Assesment by selecting GMP and NON GMP critical transaction codes from each module and check for its authorization objects.
Graham is there any standard protocol or format? kindly through some light

Hello Satish,

SAP provides a document which has modulewise US FDA cGMP affected areas as well as 21 CFR Part 11 affected modules. This may come in handy when you are defining and implementing SAP system in regulated environment. Idea is to incorporate this in URS and Configuration documents.

While doing SAP validation, we have seen number of SAP systems in pharma whereas there are lot of issues because use of SAP has not been defined for regulatory aspects.


Jaydeep D. Chhatrapati
Epitome Technologies Pvt. Ltd.
Ahmedabad. India.
email : jaydeepc@epitome.co.in


Good input! I like the approach.:slight_smile:



Good elaboration and clearly defined.

Risk assessment can take a lot of forms; the important thing is that you document your assessment and findings so you can justify the decisions you have based on that assessment.

One of the ways we determine validation scope is to assess risk based on a combination of GAMP 5 software category and regulatory impact (Direct, Indirect, None). This results in a risk level that we use to determine the scope of our validation.

For example:

  • Software category 3 + No Impact = Low Risk = No validation necessary.
  • Software Category 5 + Direct Impact = High Risk = Validation required, including full specification docs and extensive testing.
We determine scope of testing by using risk assessment. We use the risk assessment method described in GAMP 5 to assign a risk level to each requirement. Considerations that go into determining risk level include whether or not the functionality under consideration is a COTS function, configurable, or customized. The output of this process is a list of critical requirements that must be verified. In simplest terms, High Risk requirements require testing; Low Risk requirements do not. This process can be time consuming in the planning phase if requirements are extensive, but pays off at the end when we aren't spending our time verifying non-critical requirements.

All of this is proceduralized to ensure consistency and compliance with applicable regs and our internal standards.

Dear sir,
your concept is excellent, please let me know by taking any example, i am finding very difficult in finding risks, please help me in assessing in any examples like (risk assessment in secondary changing, or equipment qualification)

Thanks in advance

I hate risk assessments. I hate them with a passion, they are speculative, subjective and innacurate.

Risk assessments should be banned from GxP - they really are that pointless.

Garbage, garbage garbage :slight_smile:

(Bread walks away with pains in his chest)…