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.
The Risk Assessment process is defined in several steps as shown in the nex diagram.
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 required validation effort may be defined following the next diagram.
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:
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.
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:
Requirements for a lean Risk Assessment process:
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:
Risk based decisions during planning of Operational activities will define the activities for:
Decisions are based on nature and complexity of the system and risk priorities.
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:
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.
 PCS_RA_Form.pdf | [ ] | 25 kB |
Risk based decisions when planning for system retirement determines the approach for:
created with
Joomla Page Builder.