Internal Audit: The Continuous Conundrum

A generally accepted definition of "continuous auditing" remains elusive, and expert practitioners remain rare. Here are some tips from the trenches for getting a program going.

The staff, though, did resist. The cultural change in moving from tests of data samples to tests of entire populations of data was a big issue. “Intuitively, it’s common sense and something you’d want to drive for, so it’s a little surprising that there’s a pretty wide variance in how accepting people are of it,” Digenan points out. Those in charge of implementing a continuous audit project should respect the fact that it’s a big change for people that is sure to cause the kinds of bumps that accompany most change-management processes, he adds.

There was no one who refused outright to go along, but there was some obvious reluctance, and it turned out that some people had more of an aptitude for identifying the opportunities in continuous auditing than others. At brainstorming meetings, someone would float a good idea, and someone else might chime in, “No, the data is too complex, I don’t thing we’re going to be using continuous auditing for that.” Digenan says it has taken a lot of training and reinforcement to get the team to realize that “the more complex the data is, the better opportunity we have.”

It was the data collection that indeed was difficult, as PwC had predicted, even though the audit director had been skeptical that it would be so. The issue was not about being able to get permissions; rather, at a large, complex company, if you’re looking at travel and entertainment costs, for example, the data is not all housed in the same place. The were formidable logistics involved in working with the IT department to get data in a readable format and compile it in one database to enable the use of a single set of queries instead of several. “I didn’t think getting the data would be so difficult,” says Digenan.

The situation was saved by a suggestion from PwC: convince a member of Microsoft’s product-development team to move over to internal audit. The person who was hired knew how to gather the desired data, who to talk to about issues that cropped up, and the protocols for setting up the data queries. Digenan considers the hire lucky, because “if you’re a developer at Microsoft, you probably want to work on the next product that’s going to market.”

The internal audit team then commenced the process of writing routines to query data relating to accounts payable, T&E, procurement, payroll, and human resources. Eventually the department reached what Digenan calls the “next level,” handing off processes to management that it could use in its continuous monitoring efforts. Now team members are auditing monitoring processes that use scripts they wrote for audits.

But the audit department will not turn over a routine to management unless there is a clear business process for handling exceptions that are discovered, that includes a designated process owner and a clear “escalation” path. That is, if a problem is not handled by one person, it automatically goes to the next-highest-level person. That policy redressed an annoying problem: business units would ask for specific reports to be created, and then do nothing with them. “A lot of good ideas were winding up on the shelf,” says Digenan.

Discuss

Your email address will not be published. Required fields are marked *