Risk Assessments
In validation, Risk Assessment documents potential business and compliance risks associated with a system and the strategies that will be used to mitagate those risks. Risk Assessments justify allocation of validation resources and can streamline the testing process. They also serve as a forum for users, developers, system owners, and quality to discuss the system which can have other intangible benefits. 21 CFR 11 does not require risk assessments, but Annex 11 does require a risk-management strategy.
Assigning risk should be a multi-disciplinary function. System owners, key end-users, system developers, information technology, engineers, and Quality should all participate if they are involved with the system. The Risk Assessment should be signed by the personnel who participated in the assessment.
Risk Assessment Examples
There are many methods for Risk Assessment, but they generally all include rating risk for each requirement in at least three specific categories:
- Criticality – How important a function is to system functionality. Low criticality means that the system can continue to function relatively normally, even if the function is completely compromised. High risk means that if the function is damaged, one of the primary functions of the system cannot be accomplished.
- Detectability – The ease of detecting an issue arising with a particular function. It is more risky if there is a low chance of detectability; high chances of detectability correspond to lower risk.
- Probability – The probability of an issue arising with a particular function. Low probability means there is little chance that the function will fail; high probability means there is a high chance that the function will fail.
Alternative Document Names and Acronyms
The following terms or abbreviations are sometimes used: Risk Assessment, RA
0 Comments