Risk Assessment

Risk Assessment is the most important tool to determine the required amount of validation. The GAMP describes the Failure Mode Effect Analyses (FMEA) method for Risk Analyses. If properly applied, this is a efficient and effective method. All Risk Assessment examples in this section are based on the FMEA method.

During the Validation process Risk Assessment may be applied on several moments as shown in the following diagram.

RA moments 

Risk Assessment steps

The Risk Assessment process is defined in several steps as shown in the nex diagram.



Initial Risk Assessment

Initial Risk Assessment is required to determine if Validation is needed and how much validation is needed. The Initial Risk Assessment is usually done with a questionnaire.

Before starting the assessment ensure that:

  • the business process is understood
  • the purpose of the automation system is defined
  • critical parameters are clear

The required validation effort may be defined following the next diagram.


Risk based decisions during Planning

During the Planning step Risk Assessments are used to determine the validation approach. The Initial Risk Assessment should indicate the Risk Class of the system: High, Medium or Low. Together with the type of system (standard, configurable, custom made) the validation approach can be defined. The ISPE GAMP Good Practice Guide "Validation of Process Control Systems" shows the required actions in detail.

In the Planning step, based on the System Risk, decisions can be made about:

  • Validation approach
  • Documents that can be combined
  • Governance
  • Leveraging of existing documents
  • Leveraging of supplier inputs
  • Audits and assessments
  • Testing approach

Regulators expect that Risk assessment is done in relation to Patient Risk, Product Quality and Data Integrity, but the same technique may be used to manage risks on project, business, health, safety and environment requirements.


Functional Risk Assessment

In Functional Risk Assessments the FMEA method is used throughout.

The assessment starts with a list of requirements, derived from the User Requirements Specification (URS).  For each requirement is defined if the requirement is Critical in relation to GMP and a risk scenario is defined. The Risk Assessment team determines the Severity, Probability and Detectability of the risk. Together with the tables below the Risk priority is calculated for each requirement.


After the assessments the risks must be managed:

  • reduce High priority risks to Medium priority risks
  • reduce Medium priority risks to Low priority risks when possible
  • accept the remaining risks

Requirements for a lean Risk Assessment process:

  • Define SMART criteria for High, Medium and Low classifications
  • Limit an assessment session to 4 hours
  • Use an independent session leader to monitor the process
  • Define a team with experts of different aspects (quality, automation, business, operation, process)
  • Define a team of 5 to 8 people 
  • Do not start re-engineering
  • Re-use results from previous sessions



Risk based decisions during Test planning

With Risk based decisions during test planning a lot of muri (overdoing) can be reduced. In a project the same software may be tested in module tests, integration tests, Factory Acceptance Test, Site Acceptance Test, Installation Qualification, Operational Qualification and Performance Qualification.

Retesting the same software several time does not always add value to that software. A Risk based approach helps to decide in which test each requirement is tested or retested.

When tests by supplier are properly documented and software versions are controlled, supplier test may be leveraged into the validation documentation. When the supplier has formally tested (and documented) all requirements the following test approach may be used for a Factory Acceptance Test:


Using the Risk priority of all requirements, the table above may be used together with software category of each requirement to determine how the function is re-tested during the FAT.

Method Action
A Full retest
B Partial retest, based on Risk Scenario
C Quick test, start and stop the function
D Document Check
E Other, to be specified

With each retest, the previous test documentation is checked, including a check if non-conformances are corrected. When a function has a lot of corrections, a more intense level of retest may be required than indicated by the Risk Assessment.

In many projects this approach has proved to reduce the FAT period to 25 % of the time required for a full retest, without reducing the quality of the software.

Software categories are defined in GAMP 5 as:

  • 1  Infrastructure Software
  • 3  Non-Configured products
  • 4  Configured products
  • 5  Custom Applications


Risk based decisions during planning of Operational activities

Risk based decisions during planning of Operational activities will define the activities for:

  •  Frequency and procedure for backup / restore and archiving / retrieval
  • Disaster recovery
  • Security
  • Change Control
  • Periodic review

Decisions are based on nature and complexity of the system and risk priorities.


Risk based decisions during Change Control

Risk based decisions during Change Control may have a big impact on the validation effort. For a PCS there is a big difference in changing a symbol on a process graphic or changing the fermentation operation. A complete description of a Lean Change Control process is described in another section. In the Change Control process the following items shall be Risk Based:

  • Type of change
  • Change actions
  • Testing / Qualification
  • Signatures

The following diagram shows a relation between the type of change and the required actions for that change.





The next diagram shows the relation between type of change and the required signatures.




An example of a Risk Assessment form for changes for a PCS is attached.



Download this file (PCS_RA_Form.pdf)PCS_RA_Form.pdf[ ]25 kB

Risk based decisions when planning for system retirement

Risk based decisions when planning for system retirement determines the approach for:

  • data retention
  • data migration