With all the current buzz about Risk Assessment brought about by API Spec Q1 9th Edition, API Spec Q2 and the circulating draft of the ISO 9001 possible 2015 version, how is one supposed to know when to do risk assessment? And, how does someone initiate a risk topic to be evaluated?

The Requirement

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.

The Initial Risk Assessment

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.

Ongoing Risk Assessments

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:

1. Schedule a review of the Risk Assessment matrix once a year. This will promote awareness as well as help ensure that new risks are included in the Risk Assessment matrix and that old risks are re-assessed for possible changes. Basically, we live in a changing world so risks and their impact should be regarded as changing also.
2. Schedule a risk assessment with every MOC. This is actually required by API Specification Q1 9th Edition or API Specification Q2, therefore it should be part of your MOC procedure. The requirement is basically that for every MOC, the change be assessed to ensure you have considered any potential risks. If there is a change that merits MOC, you know Risk Assessment will follow.
3. Special circumstances. You have to recognize when there are new factors that may need to be assessed for potential risks due to their influence in the quality of your products and services; or safety of your processes; or confidentiality/integrity/availability of your information. While most of them may be already included as part of the MOC process, there may be other factors that could trigger this as well. As indicated above, these are “special circumstances,” so they may be uncommon, but your team needs to be aware of them.
4. Management Review. While the API Specification Q1 9th Edition or API Specification Q2 do not necessarily specify that one should evaluate new risks during the Management Review, the ISO 27001 standard does specify that new threats or new vulnerabilities be considered during the Management Review to see if they present a risk. I like this concept because the reality is that Risk Assessment is largely underperformed. Using Management Review – when all management should be present – as an opportunity to evaluate new risks, is truly a value-added effort.

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.