It’s getting to the point where some audit directors are saying, “No bad audit reports allowed.” In other words, don’t shoot the messenger, just the message. What follows is an experience from one of my audit colleagues…
First, a couple “I know” statements…I know auditors are supposed to be helpful and friendly. I know auditors are supposed to add value. I know auditors need to be careful about giving only bad news; we should also note in our report what the auditee is doing right (if anything). I know that it’s hard for auditees to get hammered again and again by audit reports.
However, when you audit an area for the first time (e.g., a new technology that was deployed), it usually results in a few more audit issues than normal–and while it’s expected, nobody likes it, even auditors. Because the more issues you have, the more meetings are required to ensure the facts and conclusions are correct and that you’ve assigned the appropriate risk to each issue. And then more meetings so the VPs can weigh in…
In this particular audit, not only a few more audit issues were identified, but lots more than normal. When testing was completed, the dance began: how does IT and audit keep this from being a really bad report, the kind that gets executive VP and audit committee visibility?
The opening attack involves the suggestion to roll several issues into a larger issue, which reduces the total amount of risk assigned–instead of having 4 high-risk issues, you have only 1. The problem is, you can only swallow that so many times, and often, the issue owners are different. When that fails, then the challenging of each issue begins. But when you have this many issues, even reducing the risk level by one doesn’t work (level 5, which is very high, to level 4, high).
Then comes another tactic, which goes like this: Some of these issues are the fault of other technology, not the technology being audited. For example, some software uses code that is licensed from other companies, and THAT code caused the vulnerability or doesn’t allow the recommended configuration, so the audited technology shouldn’t be “charged” with the issues–those issues should be issued under a separate audit report. You’re supposed to ignore the fact that your company included the vulnerable code from the other company in their software.
All of a sudden, you have a manageable (read “swallow-able”) amount of risk because some of the risk was removed and given it to your “little brother”. Oh, the fact that the same VPs own the risk in both audit reports is besides the point. Does that remind you of anything? What was 1 transaction is now 2, and both are below the threshold, so it slides by with much less notice. VPs are happier, managers have less explaining to do, and the audit committee is none the wiser. And IT none the safer.
Ah, but the game was played well, the score is tied, and both lived until the next audit. But that’s what happens when you manage risk levels instead of risk.
What are your experiences?