Introduction

As we get closer to the conclusion of this series, the more our process becomes defined. There are yet 2 elements to be discussed. Today’s post will focus on risk.

If you’ve missed our previous posts find a small recap of the different elements below.

• The importance of processes;
• The Scope;
• Who owns the process;
• Who does the process affect;
• The process itself;
• A visual representation including it’s expected inputs and outputs;
• Roles and responsibilities at each step of the process;
• Any risks the process introduces or mitigates;
• How will the process be enforced.

What about risk?

Processes are documented so as to ensure that things are done consistently and that no steps are skipped. In and of itself, the design and documenting of a process is an exercise in risk mitigation. However a process may as well as, mitigate, also introduce new risks.

Let’s place some context around this.

Business ABC regularly sends out informative newsletters to it’s clients that includes product updates. Business ABC has a process documented as to what these newsletters can contain, how they should be sent and to whom.

The process mitigates the risk of sending out inappropriate information to the wrong audience. However the very existence of a marketing email list, introduces a risk related to data protection regulations if not maintained properly.

How do we identify risk?

There are many frameworks available to help you identify risk and put in place mitigating actions. In this case I suggest working together with your company’s risk manager to identify:

• Any risks already within the risk register that the process helps mitigate
• Any risks the process mitigates that was not recorded in the risk register
• Any risk the process may introduce.

Below are a few questions you can ask yourself and your stakeholders to help you identify risk. Please note that not all questions may apply depending on the scope of the process.

• What could go wrong with this process?
• Are there enough safeguards and validations embedded?
• Are there any parts of the process that contribute to legal compliance requirements or contractual obligations?
• What is the process dependent on? Are there any single points of failure such as human resources or systems without back-ups? Is it dependent on the performance of a supplier?
• Are any assumptions being taken?
• What out of the norm events can disrupt the process?
• Is the skill level of the process practitioners a factor?
• Does the process handle any information subject to the information security policy? If so are there any steps that may weaken the security of information.
• If data is being handled is it in accordance with the best practices outlined in the data governance policy?
• Do the process practitioners meet the clearance requirements to have access to such information, if any?
• Can this process potentially increase or decrease costs? (Costs can be operational, material, fines or other)
• Can this process potentially increase or decrease the time to complete a task?

Note: I did not use the word efficiency on purpose here. Simply because a task takes longer to complete does not mean it is more efficient. Efficiently is to do a task well, in the shortest time possible without waste and without shortcuts.

Now what?

Let’s assume you’ve identified all the risks that are either mitigated or introduced.

Create a new section in the process and document all the risks that are being mitigated through the process. If the mitigation can be linked to a particular step in the process, be sure to highlight it. This will ensure that come the next review or change, that step will not be erroneously removed.

Next up, go through the risks introduced and quantify them together with the help of the risk manager. Any risks which score Medium High or upwards need to be reviewed together with the stakeholders to come up with mitigation strategies. These can either be refinements to the process, a new process or even transference via insurance. Keep in mind that risks may as well be accepted if they do not breach the risk tolerance and risk appetite of the business.

Any risks introduced that have not been completely mitigated are also to be documented within the process as risks introduced.

A case of duplicate documentation?

Aren’t all the risks documented within the risk register, why are we documenting these risks within the process itself as well?

1. Not all stakeholders and process practitioners may have access to the risk register.
2. Even if they do, it is highly unlikely that they would go into it to correlate this with their day to day process.
3. Knowing the risks and why certain steps and measures are taken, helps with understanding and buy-in to the process.
4. Reduces the risk of any shortcuts being taken because the stakeholders do not see the value of a particular step.
5. When the process is to be reviewed for any improvements the risks and hence considerations are readily available making sure nothing is forgotten.
6. The consequences to the business are clear to all stakeholders should the process not be followed.

Conclusion

The above exercise will help you identify the risks and ensure that your process is refined and tweaked accordingly for the best outcome before it is launched. Keep in mind, that risk identification is an iterative process and once the first batch of risks have been identified and mitigated a second identification exercise is recommended as the tweaks might have created or mitigated additional risks.

Up next week, process enforcement. Stay tuned.