Risk management and audit management are distinctly separate in terms of personnel involved and the techniques used. Most organisations that have ventured into assessing risks, have found that moving from risk assessment to audit (control and test creation) is quite a daunting task. Conceptually, moving from risk assessment to audits is the ideal and logical step to take, but there has be considerable hesitation from numerous organisations.

The GRC Envelop tool has a risk management module for the enterprise version. Risk registers, associated risks, stakeholders, risk opinions/scoring, risk treatments and many more features are present in the risk module. However, there is no connection between the risk management module and audits module.Why is this left out?

Once there is a decision by the business management as to which risks exist and which are to be assessed, the next step is vague for most of the clients. Here are some of the approaches that have been noticed when we implement GRC Envelop at organisations who have started risk-based auditing:

• create a new audit and define a “relatively” new set of controls that will assess the risks
• map the risks to a department or division and create a new set of controls
• modify existing controls and tests to cover the new risks, but later realise there are control gaps

Over time we have observed two aspects that should help overcome the hesitation while moving from risks to audit creation; first, the understanding that risks are part of a process that exists in the organisation and second, the overlap between existing controls/tests and the new ones has to be taken care of.

Risk as a part of a process

Risks do not exist independently within an organisation.

The recommendation is to attach a risk that needs to be handled, to an existing process. This existing process forms the basis of the risk based audit. Attaching the risk to a process is the most efficient mechanism to track where the risk would fall within the entire organisation.

However, attaching risks directly to a process may not be the ideal situation because risk exists with reference to an objective. A risk is the situation when an objective fails to achieve the desired output of a process. Therefore, attaching the risk to an objective is a much better alternative. This results in the overall structure being: Process (at the top), having numerous objectives, and each objective having numerous risks.

Do keep in mind that risks may span multiple objectives.

Control and test overlap

Though it is true that newly identified risk may need a new set of controls and tests to capture the assurance that business management needs, it is not true that these controls and tests have to be new completely new. Most large organisation have quite stable processes and keeping this assumption means that the newly identified risks may have been implicitly captured in some other control.

Understanding control overlap caused by the newly identified risk is a painful process of weeding out controls and tests that are no longer needed. This also maintains an optimised number of controls and tests for each process (not to mention control owner satisfaction).

Not so easy to find a common path

To conclude, I agree that moving from risk assessment to audit execution is not a straight forward task, but the framework of using the process/objective hierarchy will help ease the transition and help manage the ever growing risk control matrices in large organisations.

One aspect that I’d like to throw in is, the feedback from audit results back to risk assessment, but I think I’ll keep it for another post.

I look forward to your feedback on how you move from risk assessment to audit definition!