- System must run 24 hours a day, 7 days a week.
- Highly complex hardware, software, and system configuration;
- Highly customized;
- Unskilled operators;
- No work-around solutions;
- Vendor unrecognized in the pharmaceutical industry; no support from vendor, e.g., no documented evidence on validation during development, or no phone or on-site support in case of problems.
- Used for GXP-regulated applications
- System failure can impact data integrity or can cause loss of data.
Low-risk factors. Factors contributing to low severity risk levels include those related to product quality, health and safety, business continuity, regulatory compliance, and probability.
- System is used in early product development stage.
- System is fully automated and relies on well-validated processes.
- High probability that problem will be detected and can be corrected.
- System failures or lack of data integrity do not have any impact on human health.
- used occasionally;
- highly skilled operators;
- widely used commercial systems;
- no customization;
- work-around solutions available;
- full support from recognized vendor (e.g., documented evidence on validation during development, local language phone support or on-site support in case of problems).
- not used in regulated applications
- Failure of the system does not have an impact on data integrity and cannot cause loss of data.
Probability. Probability should answer the question, What is the likelihood that the system will fail, generate wrong data, or that data are lost?
Probability should be expressed in occurrence within a set time period. We recommend using five categories:
- Frequent (e.g., once every month);
- Probable (e.g., once in 1–3 months);
- Improbable (e.g., once in 3–12 months);
- Occasional (e.g., once in 1–3 years);
We use past experiences from the same or similar systems to estimate probability.
Importance of a risk management master plan
The most significant task during the risk assessment process is to define criteria for criticality, which determines the final risk level. For example, this question frequently comes up: what if an inspector questions my decision? There are no absolute measures, so a dispute may occur. Discussing this question today is similar to an industry discussion of 10 to 15 years ago concerning computer validation when the frequently asked question was, How much validation is enough?
Answering this question about validation was nicely solved with the development of the Validation Master Plan (VMP). Companies developed such master plans on a fairly high level to guide validation specialists through the validation process by explaining the procedure for easy understanding, offering templates for convenient implementation, and giving examples on what to validate for different systems.