Homepage / Scientific Articles / Practical risk management in IT – what does that mean in a CSV project?

Practical risk management in IT – what does that mean in a CSV project?

Completely blind to IT risk management issues?
Completely blind to IT risk management issues?

With GAMP© 5, a concept for risk management in the life cycle of a computer system in the regulated industries was presented for the first time.

Knowledge of the possible systemic risks with regard to product quality or patient safety is the key to scaling the related measures in the validation project and in the regular operation of a system. Components R1 to R7 of the GAMP© 5 risk management system (see chart) offer the starting points for an efficient process focused on the necessary, i.e. risky points. Implementation is often inadequate and potential benefits such as those described in Annex M3 of GAMP© 5are frequently not exploited. The methods and means of CSV are should thus be used in a targeted manner and paired with sensible and purposeful handling of the risks. Experience can be gathered regularly and risk management in the IT environment further developed and optimized via periodic reviews of the systems requiring validation.


General conditions
The pharmaceutical industry was confronted with the idea of risk-based approaches well before GAMP© 5(2008). The ICH guideline “Q9 Quality Risk Management” was published three years earlier.  GAMP© 3 (Appendix 18: “Risk Assessment”“) and GAMP© 4 (Appendix M3: “Guideline for Risk Assessment) included approaches for risk assessment and risk management with regard to systemic risks for product safety and product quality. Only in version 5 was risk management extended to cover the entire life cycle of a product. The GMP guidelines of the European Union also deal with the topic in the new versions of Annex 11 and Annex 15. The medical device industry has been familiar with risk management since the 1990s as part of a quality assurance system in accordance with applicable EU directives.


Influence on project work in a CSV project
The regulated industries must meet these requirements. In addition, Appendix M3 of GAMP© 5 states the benefits of risk management:

  • detection and handling of risks related to patient safety, product quality and data security
  • adaptation of the life cycle activities and corresponding documentation to effects on and risks of the system
  • justification for the use of supplier documentation
  • improved awareness of potential risks and possible controls
  • detection of areas for which detailed information is required
  • improved knowledge of the business process

However, risk management is more than just risk assessment and specification of risk-minimizing measures. It includes the following sub-processes:

  1. risk assessment: identification,  assessment and analysis of risks
  2. risk management: specification of measures to minimize risks, including acceptance of the remaining residual risk.
  3. risk monitoring: review of the risk assessment and risk management based on the observation of the actual level of risk

In most cases, risk assessment (R1, R3 – see chart) and risk management (or better, risk minimization, R2, R4, R5 – see chart) are carried out in detail for a software-based business process in an initial project, while less attention is given to the implementation of a complete risk management and monitoring system.  The latter is particularly important and must be integrated in the change management process (R6 - see chart) as well as in the everyday work of the administrators and users of the system.


Levels of risk assessment and risk management in CSV
In addition to the points in time at which risks are assessed in the life cycle of a computer-based system (see chart, R1-R7), three system levels are of interest with regard to risk analysis in practice:

Point R1: Basic risk assessment at the beginning of a project (including high-level risk assessment, initial risk analysis, or risk analysis 1 [RAI])
With the help of “predicate rules”, this establishes whether a system or a process carried out with the help of a computer system is potentially GxP-critical. This enables the identification of critical areas and the exclusion of others.

Point R3 (1): Functional risk assessment in the specification phase (including functional risk analysis or risk analysis 2 [RAII])
This methodically establishes which hardware, data or process elements are genuinely GxP-critical in process implementation, what remedies are required (risk-minimization measures) and which documentation is required in the verification test.

Point R3 (2): Functional risk assessment in the configuration/coding phase (or risk analysis 3 [RAIII])
This methodically establishes which risks may be harbored in an individually developed component of a computer system and how risk-minimizing measures at the development level are applied and what documentation is required in the development process.

In complex systems (e.g. ERP, MES, LIMS), the basic risk assessment RA I) is the tool of choice for determining which system components are important. For simple systems, the overall classification of GMP-critical or non-critical at the system level generally suffices. Subsequently, in both cases the functional risk assessments (RA II and/or RA III) of the components or systems classified as critical determine the test depth and the required test documentation against the design specification as the basis for the decisions on points R4 and R5 (see chart) based on the test results.


Complete implementation of a risk management process

The first part of the risk management process is completed, the project concluded with the validation report and the computerized system is in operation.  But this is only half of the story. For each change request, the risk assessments completed in the earlier phases must be reviewed and documented (R6, see chart), up to the decommissioning of a system for which the risk connected with the decommissioning of the system is to be assessed (R7, see chart).

If only the two sub-processes of risk assessment and risk management are carried out, the third sub-process is missing: risk monitoring (see list above). The specifications for this are not very detailed. As already mentioned, a review process for the successful implementation of the risk-minimizing measures should be established to check the risk management process quality and to initiate actions to improve it if necessary.

Successful risk management in the IT environment is a management tool with which to minimize systemic risks related to product quality and patient safety and to ensure the success of the measures. Thus, the following issues should be assessed during a periodic review:

  • Are the statements made earlier still valid?
  • Are the assessments still accurate?
  • Are the measures still the right ones today and were they successful?



Unfortunately, theory and practice still diverge considerably. Scrutinizing the earlier risk assessments in the context of risk monitoring would open things up in both directions:

  • less monitoring and more efficient processes with less restrictive new assessments, or
  • additional measures with stricter new assessments and new aspects.

The article entitled “Risikomanagement nach GAMP© 5” (Risk management in accordance with GAMP© 5) by Sieghard Wagner in Pharm. Ind. 77, No.7, 1012-1022 (2015) offers a more detailed discussion of the topic.


Dr. Thomas Karlewski und Sieghard Wagner|Consultants Efficient IT|The Business Designers



No comments found.

Chemgineering Business Design AG | Binningerstrasse 2 | 4142 Münchenstein | T +41 61 467 89 00 | F +41 61 467 89 01 | www.chemgineering.com | info@chemgineering.com