Implementing Continuous Control Monitoring
Continuous Control Monitoring is a valuable tool for auditors and risk managers. However, anyone who is venturing down this path needs to be aware that, even with high level support, there can be resistance and challenges to a successful implementation. These include:
It’s often very difficult to use technology to test control operation. Often the controls are manual or they are embedded in systems. In either case, it’s difficult to meaningfully test controls using automated techniques. So, Continuous Control Monitoring tests the controls by testing the data.
Continuous Control Monitoring tests the data for any indications that the controls are not working. If the key controls are working then the processes should produce certain data outputs. Testing these output for potential errors can give the auditors insights as to whether key controls are achieving their objectives.
It’s useful to regard continuous control monitoring as a form of End User Computing.
Even with Executive or board support, resistance can be encountered at various levels. The IT function may regard Continuous Control Monitoring as an intrusion into their area of expertise. IT staff may have the resources or fully understand the how to deliver and maintain a continuous control monitoring solution. IT often suggests the solution is existing business intelligence (BI) or data visualisation toolsets.
Line managers and their staff will tend to resist Continuous Control Monitoring as they can see it as added effort or they already have reports or manual check s in place that work. There are also fears that a new and more powerful audit techniques that may expose unknown (or known) problems.
A regular problem is obtaining data. IT Departments have a duty to protect data and are often reluctant to make datasets available on a regular basis. As a last resort, the auditors will have to sometimes point to their Audit Charter to justify access. However, even if access is achieved, regularly accessing and downloading it can be a technical and political challenge. Continuous control monitoring is nothing without access to data.
The advice here is to “Keep it simple”. The IIA publishes a series of Global Technology Audit Guides (GTAG), one of which concerns continuous control monitoring. The author of one of these guides privately confessed to an error. His first instinct was to advise auditors to start with a generalised risk assessment and identify continuous control monitoring opportunities on a top down basis. However, after painful experience, he had changed his mind. His revised view was that existing internal audit reports are the best source of potential value add to Continuous Control Monitoring Routines. The auditors will have identified a range of issues over time. Management may have agreed to correct the issue. Developing a Continuous Control Monitoring Routine to test the data for evidence that the corrections have been effective (and continue to be so) is a useful (and often high return) means of “putting your toe into the water”. This approach will engage the internal auditors who often value the opportunity to establish continuous monitoring over problematic areas identified in previous audits.
When Continuous Control Monitoring is suggested, a response is often “We can buy an off the shelf solution that will do all of that”. If that were true, it would be wonderful. However, the reality is often quite different. Every organisation’s systems are different and, even if they use the same core Enterprise Software, there will be differences in configuration as well as interfaces with legacy systems and differing manual systems. Often, potted solutions will run but their outputs will tend to very large and can’t be efficiently dealt with. As well, the most powerful CMRs often cross match data between systems. A tool is required that acts to efficiently “extract, transform and load” data from differing systems.
The Continuous Control Monitoring Routines should be able to produce “high probability exceptions” (HPEs). That is, exceptions that are likely to be genuine indictors of control failure. Developing CMRs that reliably generate HPEs often requires insight and frequent iteration.
If Continuous Control Monitoring is going to be effective, then the exceptions that it generates must be captured and analysed. However, simply making the exceptions available to the operational staff won’t allow the auditors to form an opinion about control effectiveness (i.e. design and continuity of operation) or provide evidence or root cause. The exceptions must be captured in a secure environment that requires operational staff to act to resolve them (i.e. by closing an exception with a reason code).
It is in this context that careful design of CMRs becomes critical. Floods of “false positives” will not continue to be reviewed by the operational staff. They’ll “throw up their hands” and walk away from the process.
Exception management is a key difference between Continuous Control Monitoring solutions and BI or data visualisation tools.
Business As Usual
Unlike periodic analytic reviews or audits of data for control effectiveness, Continuous Control Monitoring becomes a production application that, if implemented well, the business relies heavily on. Therefore, a consideration of maintaining the system beyond go live is essential. Not only system admin duties such as data load fails, user access and backups but test logic refinement and addition of new CMRs will be a requirement.
Quite often organisations have attempted to insource these tasks as part of IT or an exiting analyst team which often leads to failure. A consideration is outsourcing to an organisation that specialises in delivering and maintaining Continuous Control Monitoring applications.