Before API Spec Q1 9th Edition or API Spec Q2 came up with the concept of Risk Assessment, it had already been prescribed by two perhaps not-so-common standards: OHSAS 18001 Occupational Health and Safety Management Systems and ISO 27001 the Information Security Management System. While the first one placed emphasis on assessing safety hazards in your processes, the second one focused on assessing risks that could affect the confidentiality, integrity, and availability of information. Based on our experience, risk assessment is an exercise that you want to do right the first time and every time, so you don’t end up having to activate your emergency or contingency plans.
Once you have selected your risk assessment methodology and crafted your risk assessment procedure, the next step is to carry out the actual risk assessment. Make sure you invite the management team and any process owner, to ensure they not only feel involved but also that they take ownership of the management system being implemented.
Using this simple premise of doing it right the first time and every time, when should we really do a risk assessment? Here are some ideas.
When you first deploy your quality management system, EHS program or information security management system, risk assessment is required to be conducted. In this case, I suggest you conduct it after your main process mapping session and midway during your procedure development phase. While the results of your risk assessment may affect the content of the procedures, you don’t want to scare your employees, by subjecting them to a risk assessment session when they do not fully understand what a procedure should look like.
A note about which risks to record: although you may be tempted to only record those risks that everyone considers relevant, I advise to keep a section for risks that you may have disregarded as irrelevant…in case they are called out again in your next risk assessment. Rather than repeating the effort, having a list of discarded risks may help streamline the process during your next Risk Assessment review.
After the initial Risk Assessment effort, ongoing Risk Assessment may be scheduled as a yearly event, but that should be viewed as a minimum, pending other possible triggers. For example, API Specification Q1 9th Edition and API Specification Q2 both require that risk assessment be done every time there is a Management of Change. Here are some ideas for how to keep your risk register fresh:
The API Specification Q1 9th Edition or API Specification Q2 do call for a review of Risk Assessment during the Management Review, which could help to ensure that Risk Assessment was done well or to identify any risks not correctly assessed. Perhaps this meeting is also an opportunity to have management agree on the treatment of any residual risk.