Continuous auditing that should NOT be performed by internal audit
I have to admit to being a big fan of continuous auditing in general. One of my more popular papers (available for download here) is on the topic of continuous risk and control assurance. I wrote it to explain why I believe internal auditors should move from providing assurance on an occasional basis to providing assurance when it is needed by the audit committee and top management. In these days of rapidly changing risks, when businesses are moving faster and faster, internal audit needs (IMHO) to be able to provide prompt assurance on the more significant risks. Telling top management that internal audit can provide assurance in a month, after an audit is completed, is clearly sub-optimal (if not unacceptable).
But, I also believe that certain practices, generally described as continuous auditing, are NOT core internal audit practices. At best, they are consulting services; at worst, they are internal controls relied on by management – that should be performed by management.
Let’s start with a statement with which, hopefully, almost everybody will agree: the core internal audit mission is to provide assurance services related to the adequacy of management’s processes for managing risk, the organization’s governance processes, and the related controls. In addition (and to me, this is a clear secondary activity) internal audit provides value-add consulting services. Both the assurance and consulting services are intended to assist management improve the effectiveness of their processes.
I support:
- Continuous audit activities that are designed to provide assurance on a more continuous basis, for example by testing controls more frequently.
- Continuous audit activities that are recognized as value-add (rather than assurance) activities and are approved by the audit committee.
Let’s examine a few cases:
- The use of software to identify duplicate payments. To me, management should have controls to prevent, or at least identify promptly, duplicate payments. If reliance is instead placed on internal audit to identify the duplicate payments, internal audit is performing a management function. I would be reluctant to do this, unless management were able to make a convincing case that this was the best use of overall corporate resources, it did not take resources away from essential assurance activities, and was approved by the audit committee.
- The use of software to detect errors, typically the result of internal controls failing to operate effectively: for example, internal audit monitoring transactions to detect errors such as approved (or paid) vendor invoices not matching purchase orders or receiving documents. Some consider this a valid internal audit activity, but again I think that internal audit is stepping in and performing a control – a management function. Now, I am fine with audit providing a consulting function, developing the capability and turning it over to management to run. But, I am reluctant to see internal audit continuing to do it. I would do it if management could make a solid business case, it didn’t detract from essential assurance work, and it was approved by the audit committee.
- Fraud detection is an interesting case. While many internal audit functions have this in their charter, I believe that controls to prevent and detect fraud are a management responsibility – that internal audit can perform as a consulting service, with the approval of the audit committee. It should not divert resources away from essential assurance activities. In an ideal world, fraud detection is performed by management and assessed by internal audit. But, internal audit has independence and skills that may well make a compelling case for their owning fraud detection. Again, it should be approved by the audit committee and included in the internal audit charter.
My preferred continuous audit work consists of tests (that are generally but not always automated) that provide assurance that the controls relied upon to manage the more significant risks are working effectively. Testing data does not provide assurance that controls are working: when the tests identify exceptions, that implies the controls are not working – but the absence of exceptions does not provide evidence that controls are operating and effective.
What do you think? Do you agree that these forms of continuous auditing should be performed by management (and are really continuous monitoring)?
Leave a comment
Norman Marks on Governance, Risk Management, and Internal Audit 
Hi Norman, I agree with your concerns, but wish to add that Continuous Monitoring (CM) is not the same as Continuous Auditing (CA). The end result of CM is to obtain information about the performance of a process, system or data, not the issuance of an “audit report”. Generally information obtained through an auditor’s observation provides direct evidence whereas information gathered through CM provides indirect evidence. Further, CM is a management process, often systems driven and within management’s direct control, whereas CA is an independent process. The crucial point is how many organizations would be ready for CA from either a maturity level (of processes and systems) or a technological level in reality.
I agree with Dipak, but also all audit management should be performing continous monitoring in some areas always. I agree it is a audit management process and aids in the accumulation of audit knowledge regarding the company and its operations.
Dipak, I agree that these activities should be continuous monitoring by management rather than continuous auditing by IA.
Norman,
From my perspective, Simply increasing the frequency of testing (from a manual perspective) is not continuous auditing. You must also use technology, combined with increased frequency of testing, while looking at the population as a whole. Thus, my definition of continuous auditing is very simple (uses GTAG#3) as a baseline. It is as follows: Continuous auditing is using technology to continuously monitor / collect information in order to support audit activities and provide on-going assurance to management.
With regards to your examples, I wholeheartedly agree that management should have a set of controls in place to identify duplicate payments, or ensure that payments are authorized or POs are supported by valid requisitions, or other controls to minimize the risk of fraud in other business cycles, but that is why Internal Audit is here in the first place —> to validate the effectiveness of the controls in place. If management was using technology to continuously monitor transaction and controls, then the amount of continuously auditing activities performed by IA could be reduced. However, management in many organizations (at least the ones that I have been involved with over the last 15 years) have not optimized their monitoring activities. Therefore, Internal Audit functions (as a way to reassess to relevance) is the driving force behind the change to bring technology into the organization.
In your example of duplicate payments, most auditors (at least many in my network) will agree that the controls in place may not always be sufficient to prevent duplicate payments (particularly if you pay the same vendor with or without a PO and via wires or ACH) but oftentimes management accepts that risk, despite our recommendations. Thus, if IA has the opportunity to help management identify some recoveries, then I don’t see an issue with that at all. Now, once I have that script built and running, I actually turn it over to management. And if you have an integrated continuous monitoring / auditing solution, all you would need to do is change the workflow to the management team; IA then will simply audit to ensure that they are monitoring the potential duplicates that are identified. Note: continuous monitoring of duplicate payments may not be needed at all if the system has the configurations / settings already there to block invoice postings that have been identified as a potential duplicate (I have this set up in SAP with one of my clients). Therefore, IA only performs a search for duplicate payments twice a years as the likelihood there would be one is minimal.
The point that I want to make is that that both management and IA should be using technology to monitor and audit information as it relates to risks of the organization. This collaborate effort provides continuous assurance to the Exec Team and the Board.
That’s enough for now. Have a good weekend!
Bill
Bill, while I understand your comment that continuous auditing only includes activities performed using software, can you explain why? Whether you use software or a manual technique, it is still continuous and falls into the definition of continuous auditing per the GTAG you reference:
“Continuous Auditing is any method used by auditors to perform audit-related activities on a more continuous or continual basis. It is the continuum of activities ranging from continuous control assessment to continuous risk assessment — all activities on the control-risk continuum. Technology plays a key role in automating the identification of exceptions and/or
anomalies, analysis of patterns within the digits of key numeric fields, analysis of trends, detailed transaction analysis against cut-offs and thresholds, testing of controls, and the comparison of the process or system over time and/or against other similar entities.”
Great post, again! Thanks, Norman.
Frequency and scoping should correlate with risks. I think what most IA will find that management and “Compliance departments” do is they limit the scope of the CM because there can simply be too many false positives from the technology that’s being used.
For example, I laugh when I see IT GRC vendors take network security scan results and directly create a remediation item or a document to prove that the control is working. IA needs to look at those processes with a fresh set of eyes. Focus on the risks, scopes, and etc.
I agree with Norman, continuos audit is a resource in the audit process that needs to be defined in order to provide information from critical activities without to compromise the system performance.In the IT project, during the development fase, audit points must be considered, including “triggers” and monitoring reports.
I agree. I ofetn hear auditors taking about performing tests for duplicates at which point I ask, “Is the objective to find duplicates or to verify that the controls over duplicates are working?” The objective should not be to find duplicates. Therefore, do your duplicate test once – identify the control weaknesses and later (as a follow-up) test to see fi the controls have been fixed. Don’t continue to test for duplicates every month – this makes you part of the control framework.