Risk Assessment 101: Do It Right the First

Time and Every Time

by Miriam Boudreaux, published March 21, 2014

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 9001possible 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 dont 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 dont 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 irrelevantin 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 under-performed. 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.