What is "Risk-based" Auditing?

For the last month or two, I have been working on an IIA Practice Advisory on how to define which controls to include in the scope of an audit (hopefully, to be issued in early 2010). It is based on the popular Guide to the Assessment of IT Risk (GAIT) methodology (available to members here).

During this time, I realized that my views on “risk-based auditing” have changed from what I did a few years back. In the past, like many other chief audit executives, I performed a risk assessment and rated the various elements in the audit universe (e.g., locations, business units, processes, and projects) based on the audit team’s assessment of risk. The elements with the higher risk ratings were then audited, and the scope of each audit was defined based on the higher risk areas within that area.

As an example, I might rate the following as higher risk areas: the factories in Penang, Malaysia, and Bordeaux, France; the Corporate Shared Services Center in Dublin, Ireland; and the general controls over the IT Data Center in Longmont, Colo. The scope of the Penang audit would be based on a risk assessment of the factory’s processes, assets, etc. The audit might include the higher risk areas of inventory management, quality control, and code of conduct training. The scope of the Bordeaux factory audit would be different, as the risks in that location are not the same: payroll, procurement, and accounting for inventory. A similar local risk assessment would be performed for the other audits.

My approach today — my definition of risk-based auditing — is different. Instead of starting with an assessment of the audit universe, I start with the risks to the enterprise as a whole. The more significant risks might include: our implementation of a new enterprise resource planning (ERP) system; the startup of a new factory in Suzhou, China; the expansion of the business into Russia; compliance with the U.S. Foreign Corrupt Practices Act (FCPA) in the Asia/Pacific region; reliance on single source vendors for critical components; and the timeliness and accuracy of monthly management reporting to the executive committee.

My goal is to provide assurance on how well management’s processes are able to manage the more significant risks. My audit plan includes projects to identify and assess the controls that management is relying upon to manage the ERP implementation, FCPA compliance in Asia/Pacific, and sourcing for critical components, and to ensure the integrity of monthly management reports.

So instead of using risk assessment to determine which audit universe elements I will include in the audit plan, I am auditing the processes and controls management relies on to manage the more significant risks to the enterprise.

Which approach are you using? Have you also changed to assessing management’s controls over the more significant risks?

 

Posted on Jan 4, 2010 by Norman Marks

Share This Article:    

  1. Norman, we made this change and have built methodology, tools and guides to help companies make this transition.  One of biggest changes was to put on our advisory hats on for areas identified as high impact/high vulnerability.  In these areas, the business needs assistance to design risk responses to help bring the risks within acceptable appetite levels. No sense testing if it needs fixing. We also but our advisory hats on when the risks are identified as low impact/low vulnerability to make sure the business is not over controlling/spending.  Where the risks are high impact/low vulnerability, we do a lot of the traditional assurance role to make sure internal controls and risk responses in place are operating as intended.

    Mike Corcoran

    GRC Partners

    michael.corcoran@grcerm.com

     

  1.  Norman, your revised approach makes good sense. The board is not equally interested on all possible risks, it needs to be primarily focused on the achievement of the objectives/ outcomes it commits to stakeholders - and therefore those risks which are most likely to impact those achievements. 

    A good risk plan therefore relies on clear board-sponsored objectives - and may put pressure on the board to define and/or communicate these better than today. Probably not a bad thing to request I guess....

    Good luck with your endeavours.

  1. Norman,

    Your shift in focus/definition of risk-based auditing is logical considering the effect that failure to achieve organizational objectives is likely to have on both the current and long run viability of the organization. My only concern about a CAE making the transition to your revised approach is whether or not the organization is ready for it. There are many organizations in which the Board and senior management still view IA as primarily a compliance verifying activity with perhaps some fraud prevention/detection thrown in. In that situation, your previous approach to risk-based auditing would be appropriate. So, if a CAE would like to make the shift in the risk-based approach followed, first step is to be sure there is alignment with Board and management priorities. Otherwise, the CAE may be doing the right thing for the company and investors, but will only create conflict with the Board and management by delivering audits that don't focus on policy/procedure compliance. In that situation, maybe doing some upfront lobbying with the Board or management members who are most likely to be supportive of the shift would be a good approach. Try to get the go ahead to do some audits based on the revised approach you recommend. Then, when the change in approach delivers results, it will be easier to make the full change.

  1. I agree that your new perspective is a good one and you can almost match that shift in just the maturity of the auditing experience you have.  Few years ago you, perhaps, had a more 'head-down' perspective on auditing and focused on more detailed, specific controls and processes whereas now you are sitting back and more strategically viewing it as a 'chief auditor' would.  Thanks for the perspective and exposing it to me early in my career.

    Happy New Year!

  1. Brad, I wish I could put the change down to an elevation to 'chief auditor'. But, I have held that position since 1990, so it's not a good excuse.

    What I will say is consistent with Richard Archer's statement. My 'old' approach is the mainstream that the majority, I believe, still follow today. My thinking changed over time, accelerated in part by the change in definition of internal auditing in 1999, and in part by the 2002 requirement that CEOs and CFOs sign off on the quarterly financial statements (SOX 302).

    If top management has to opine on internal controls, why shoudn't audit? So I started doing that in the mid 1990's.

    Then my thinking matured to considering the risk management system - and the IIA position paper on IA's role in risk management helped bring about that change.

    The great recession and the failure of risk management has made this change, for me, absolutely critical.

  1. As a consultant I have been asked or directed by many clients that we build our plan with an audit universe of known audit areas or business initiatives.  My response always lead the to the question;   what primary risks  is the organization concerned with that led us to each of these areas?   I start with a prioritization of risks , using a common language, and then map to the underlying business processes where those risks manifest.   eg; customer service risk may manifest in a number of proceses such as call centers, order to cash, warranty claims, etc..   Once an audit (control assurance and/or  a consulting  review) is identified in any of these process areas,  other risks could also be addressed such as financial reporting, IT, compliance, etc. 

    Hope this helps and happy new year!

  1. I agree with Richard Archer.  Only in organisations where the governance structure appreciates the full importance and potential of risk management, can the CAE make the 'jump' to the new paradigm.  In one of my previous organisations, we had a well laid out plan to stop auditing individual risks/controls as such and focus only on how the management manages the material risks.  However, it's still struggling to raise the risk awareness across the whole organisation (46 countries across 5 continents, at last count) to a sufficient level to enable that to happen.

    And in organisations where the AC is majorly focused on financial risks (no ERM framework!), almost to the exclusion of operational and other risks, it may become well nigh impossible for the CAE to change over to the new way, regardless of whether the ground and resources are available for that.  After all, we're totally stakeholder-driven, and have to give the management/AC what they want, while working to gradually bring them around to, shall we say, a more 'enlightened' and comprehensive way of looking at risks.

    Deb

  1.  I agree with Bryan Foss. "A good risk plan therefore relies on clear board-sponsored objectives".

    I would add that we then need to get the 'in the trenches' perspectives, views, and facts that support these BOD objectives.

    I believe the most effective way for this to occur is to launch an organized enterprise-wide collaboration initiative. We need the people that 'know' to share their knowledge.

     

  1.  Dear Norman

    I agree with your approach for focusing on the risks which has major impact on the business.  In my opinion, audit plan should have be a mix of  audits, which will address

    1. the major company level risks,  

    2. location specific risk

    in such a way that the entire audit universe is covered once in 3-4 yrs. 

    The CAE and his team should be on the top of the things for the approach to be successful. The CAE should also be able to catch things on a proactive basis  before it explodes. 

  1. Parsuram,

    You note that you believe the auidt plan should address risks "in such a way that the entire audit universe is covered once in 3-4 yrs."

    Sorry, but I believe this is a return to cyclical audits. If you only address the more critical risks to the business, then there will be some risks (whether entity or local) that are never covered.

  1. I work in local goverment, and my organization over the last two years has moved to a matrixed, business process focus across nine citizen-impact core service areas (capital managment, public safety, environmental protection, etc.), supported by three internal core services (financial, IT, and HR), all of which are organized around key outcomes (growth management, economic development, quality of life, resource preservation, etc.). We're in a transition stage right now, looking at ways to re-focus on specific business processes that mitigate risks associated with key outcomes, rather than focusing on individual departmental risks/operations in isolation.

  1. Hello Norman:  Good topic and lots of good comments!  I interpret your explanation as a transition from a more operational risk assessment to a more strategic risk assessment.  I'll explain the steps I've gone through in audit planning this year:

    1) Read the company's strategic and business plans (about 400 pages of presentation materials).

    2) Identified high-level themes from the strategic plans along with specific company initiatives. Two key themes were working capital (prompt billing & collection) and generating cross-selling opportunities across our major businesses.

    3) I actively tried to determine which of about 30 strategic initiatives would benefit from audit support, either participation in meetings, facilitated support, or an audit.  We keep a list of them and track progress during the year.  I like to know how we are doing relative to our strategy.

    4) Conducted interviews with 40 executives.  We cover three questions:  What are your objectives & measures for the year? What are the key risks you see to those objectives? What are the major changes in the business recently and planned for the upcoming year (people, process, systems)?

    5) Developed a list of 33 audit projects, risk ranked them, and determined how many audit days I would need to execute each as best as possible.  About 20 made the cut; the remainder are "below the line" and I'll let the Audit Committee know the topics we won't cover. Certain projects are mandatory (external audit support) so I maxed their risk ranking so they sort to the top.

    There are no sacred cows in my audit plan. I started with a blank sheet of paper. I had a couple of areas I wanted to audit that I knew I hadn't covered before, but I'm ok with not auditing an area of the company that senior management believes is well controlled.

  1. David, this reads more like my earlier approach. Where I differ is I now take the top business risks (from your step one) and the audits (one or more for each) would address whether management has adequate processes and controls to manage them within organizational risk tolerances. The activity in step 4 is part of the audit process, rather than part of development of the audit plan. Are they able to assess and are they managing the risks?

    Does that make sense?

  1. "Risk Based Auditing" applies at both the project selection level above, as well as at the individual project level. Once you've decide what to audit, I'm a big fan of following the basic SOX concepts, with a Six Sigma overlay during testing:

    1) Determine the process and key transaction types in scope.

    2) Document the key risks.  Rank them.

    3) Document the controls related to these risks.  Rank the controls.

    4) Determine which controls to test. Not all must be tested.

    5) Develop and execute the appropriate test strategy.  Sometimes robust data is available.  Sometimes you must manually sample.  I always go for the data when I can get it!  

    This is where Six Sigma comes in.   You should always strive for the "Holy Grail" pie chart or Pareto chart that shows the reason codes for the deficiencies you found out of your sample, if helpful. 

    For example, we recently completed a project where about 10,000 out of 40,000 invoice transactions were processed in an automated way, the remainder involved manual intervention.  We crunched the data until we knew the reasons why the other 30,000 had to be manually processed (10 major reasons; 4 covered most of the problem) and put solution efforts into play to get as many of those automated as possible with the IT organization.

    The key questions Six Sigma makes you ask:  What does perfect processing look like?  What are the defects that require rework? Why is this defect occuring?  What do we have to do to get it resolved?

  1. Hello Norman:  To your 7:13 reply above...

    I typically get the best project ideas from management; I find the interviews invaluable.  When we discuss the big changes and the risks they are dealing with, ideas for projects or other support jump out.  Having read their strategic plan, we have a very robust discussion, sometimes going through the document together.

    There are four types of assurance and consulting efforts that we get involved in:

    1) Attending status meetings on particular strategic initiatives to provide ongoing, informal feedback.

    2) Providing Six Sigma facilitation, project management or analysis/support resources.  This can be as much involvement as an audit or less, depending on the nature of the project and support required by management.

    3) Traditional audits.

    Our approach and framework is tailored to the circumstances.  We have a different methodology for Six Sigma projects than audits.

    I used to work for a manufacturing company where there were two risk decisions:  Which plant to visit and which audit modules to complete.   We don't do that here.  Whether we are doing an audit or a Six Sigma project, we are tailoring our approach to the process and risks faced.  With Six Sigma, you are more focused on understanding why defects are occuring.  With audits, the focus is more on discrete risks and controls.

    If we have audited an area before, we have the risks, controls and tests in our database for our operational areas just like SOX.  The risks tend to change a bit, but the controls often change significantly when we return after a year or two, more so than SOX.

  1. ur traditional auditing is it having the same meaning as control-based approach????thanks in advance.....

  1. Starting your audit from the enterprise perspective makes a lot of sense. The only challenge however is to is finding the right link to bring together various risks into an umbrella. The danger of not being able to bring them all together will mean that the silo effect will still be a problem. Well done

  1. great

  1. I agree with your revised approach it makes a lot of sense. We nee to audit the processes and controls built into the significant risks facing the organisation.

    When developing the audit plan we need to focus on the inherent risk ratings other than residual risk ratings

  1. "Risk Based Auditing" applies at both the project selection level above, as well as at the individual project level. Once you've decide what to audit, I'm a big fan of following the basic SOX concepts, with a Six Sigma overlay during testing:

  1.  All, my point is that first and foremost we should focus on the risks that matter to the board and top management, I.e., risks to the achievement of enterprise objectives.

    Yes, you can apply risk-based at lower levels, but why do that and fail to address al the more critical risks to the organization?

Leave a Reply