I wonder sometimes how many controls fail due to personal issues instead of design and performance issues. In other words, do controls fail more because of communication, turf, and personal issues or is it that the control is poorly designed or not performed?
A couple of times, it was the former. One control owner failed his controls because he seldom performed the controls before the auditor asked for the evidence. He either said that he didn’t have time to perform the control because he was too busy supporting the business or that he actually performed the control, but didn’t have what auditors love to call “evidential matter.” Did I mention this director did a lot of the hands-on UNIX work himself, even though he had a couple UNIX admins? Hmmmm.
When he claimed he was too busy, I asked him who required the controls in the first place. He knew the answer was the business or “Management,” that “irritating entity that made stupid decisions that no one in particular would own up to” (or so he said).
When he claimed he was too busy to record his performance of the control, I asked him what benefit the control brings if he can’t take credit for doing it. He knew that no proof = no control. He figured he could just bully auditors into submission because “auditors are ignorant.”
The conversation always ended the same way: “These controls are stupid and a waste of my time; and now YOU are wasting my time,” he’d say.
“No,” I’d reply, “I disagree. But either way, you and I will spend more time on this control, as I have to report this failure, several people will have to read about it, and you and your management will have to respond with an action plan. Then you’ll end up performing the control, I’ll come back again to test it.”
At other times, he’d note how I had no business poking my nose into his operations (turf). Let’s see, page 2 of the internal audit charter reads as follows…
Not only did this director have personal anathema for internal audit (he’d failed several times already), he thought that pushing back each time he was audited would eventually scare us off. Although it took too long, his management eventually had a good talk with him (which is where the problem originated; it just happened to bloom in his area).
Wrong Data = Fail!
Another audit group I worked with habitually and gleefully failed any control owner who failed to provide all the data by deadline (never more than 48 hours after the request). For example, if a listing of the test system was provided instead of a listing of the production system, the control was failed (as no evidence of control was provided).
The problem with this methodology is that it tests the delivery of data rather than the design and performance of the control.
Failing controls for this reason is not only a great way to make eternal enemies, it also increases the audit load (as well as the auditee’s load). How can auditors be viewed as “here to help” if they can’t work with those that they audit to truly test a control? Everyone makes mistakes. Even auditors.
Also, some deadlines aren’t as important as others. Quite often I had my hands full with so many other controls that a 1- or 2-day delay in getting one piece of data didn’t really matter; I was busy elsewhere.
Furthermore, after working in IT for decades myself, I know emergencies, personal tragedies, family events, and department parties do occur. Sometimes, you don’t have time, but you can do it tomorrow or next week.
Let’s forego the personal and get back to the business, okay?