Tag Archives: audit management

From Risks to Audits

Posted on by
Reply

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!

Looking for an Audit management tool at low cost?

Posted on by
Reply

When looking for a GRC software, how much would price affect your decision? Would you try a free open source, but reduced feature software?

An interesting comment on the Norman Marks blog asks why you would stick to a fixed set of features rather than look for “á la carte” GRC software. At what “point” would you choose product that covers a fixed feature set over a pick-and-choose approach to software or visa versa?

The GRC Envelop is a risk and audit management tool that is web – based and has risk and audit work flows. To answer the price issue, GRC Envelop tool is available in 2 licences: an open source licence and an enterprise licence. The open source licence is referred to as the community version. The enterprise licence is refer to as the enterprise version. The enterprise version has commercial support and many additional features to help with risk and audits. Please take a look at the feature list to decide which one is better for you.

GRC Envelop tries to blend the price and feature set issue by the classic software design of breaking the tool into modules. For example, the risk management module that can be swapped for another risk management tool, using APIs provided.

Audit and risk management tools are quite common in the enterprise, and they help structure the audit work flow, maintain a common repository of audit/risk related information (such as objectives, risks, controls, and tests) and manage the people around the audit/risk activities. Assuming we look at audit management for now, there are four basic areas for every audit management tool should have:

  1. Creating audits – Title, description, start and end dates are of some of the features that are available while creating an audit. You can also attached work papers to an Audit. While creating an audit, you can create the processes, the objectives, the risks, the controls and the tests. At each of these levels you can attach work papers too.
  2. Managing and executing audits – to manage or execute an Audit, the GRC Envelop tool provides a separate workflow to ensure that auditors can only enter test results and test descriptions. While executing the audit you can create findings and actions. The ability to make control and test assessment is only available in the enterprise version.
  3. Report generation – the main use of this tool is to provide easy report generation at the end of an auditing exercise. report generation template can be modified according to your needs. The community version has only one default report generation template. The enterprise version has the ability to have multiple templates.
  4. User management – Restricting users to their areas is an important task for a tool. The community version has only one user type ( auditor) whereas the enterprise version has 6 user types (Audit manager, auditor, external viewer, internal business user, repository manager and risk manager)

The GRC Envelop provides all these basic areas. Paid support is also available for the community version. The community version has to be downloaded and installed on your machine or server. The enterprise version can be run on your servers or hosted on a public server. Please take a look at the feature list to understand which version will be most suitable for your use. Here are a few questions that we’d like to pose:

  1. Do you think there are other basic areas that was missed out?
  2. How would you define if a audit tool is easy or complex to use (steep learning curve)? The time it takes to learn a tool is one aspect, what else affects complexity?

Let us know in the comments below.