Regulatory Reality

Sep 1 2009   3:29PM GMT

IT audits versus reviews

David Schneier David Schneier Profile: David Schneier


I had mentioned in my last post a recent conversation with my partner regarding a proposed IT general controls (ITGC) audit. My primary role in our practice is to head up regulatory compliance services which includes audits, assessments and program development; my partner’s primary role is head of sales and business strategy. However, there’s a significant amount of overlap between our two sides and I sometimes forget that I’m the compliance expert when we’re discussing the industry. His knowledge of the myriad regulations is impressive and there are times where I’ll vet ideas through him to validate my own thinking.

Anyway, he’d mentioned a conversation with the client around the proposed ITGC audit in which the project sponsor asked what the difference is between an audit and a review. I knew right away where the question stemmed from because of my experience in the industry. Many firms we compete with (and some I’ve even worked for in another time and place) don’t conduct audits, they conduct reviews. Sometimes they don’t even conduct a review or an audit but rather an assessment. I’ve struggled with this blurred use of terms because in my mind there are very clear delineations. The lifecycle of the governance, risk and compliance (GRC) domain is as such: identify and assess risk, design controls to mitigate those risks and test to validate that those controls are functioning as expected. And so, a risk assessment is conducted, governance elements are introduced in the form of policies and procedures, and regularly scheduled tests occur to make sure that the whole enchilada is actually getting the job done. And so when practitioners offer services that aren’t specific to one of the key areas of the GRC spectrum, it bothers me.

See, an audit is an audit is an audit; you determine the control objectives that are supposed to be supported by the entity that are in scope for the type of audit, identify the related control activities that either are or should be in place and then design a series of test steps to determine if those activities are occurring and tie back to the overall objective.The auditor has some leeway when it comes to offering an opinion as to what the results actually mean (one auditors pass is oft times another auditors finding) but fundamentally the audit results tend to be binary, you either pass or fail.It’s all fairly straight forward.

Now a risk assessment is not an audit; it’s a bit more arbitrary. Management generally is polled to determine what areas of their infrastructure (including finance, operations and technology) they are most concerned with, factor in regulatory and industry requirements and then come up with a plan for conducting the risk assessments. As these assessments occur, what they reveal would be factored into the overall audit plan to make certain that the areas presenting the greatest risk to the business are being examined closely and in a timely fashion.

So here’s my question: what exactly is a review? If you’re conducting tests and examining evidence you’re conducting an audit. If you’re interviewing stakeholders and determining what controls are in place but not testing their effectiveness then you’re conducting a risk assessment (assuming you’re asking the right sort of questions – a post for another day). Is there some odd dimension between the risk assessment and the audit I’m unaware of where this review occurs? And what exactly are you expecting from the results of this review? Because I’ll tell you this much, examiners only recognize risk assessments and audits. You can present them with a report that’s called a review in the title and tell them it’s actually an audit but you’d better be prepared to produce work papers because they’re going to ask you for them, trust me on this point. But my experience is that reviews don’t produce work papers because evidence is generally not formally collected in support of the report and requires significantly less effort to conduct. Which is why when we discussed the semantics of our industry, my partner is fond of saying that the difference between an audit and a review is about 50% of the proposed amount.

And as long as I’m ranting on the topic, how many of you out there include work papers as a deliverable when you contract with external entities to conduct audits? I’ve long been amazed at how many audit projects I’ve managed where work papers weren’t required or provided because it wasn’t included in the statement of work. I’m of the opinion that a summary audit report by itself is useless if you don’t have the supporting documentation because it’s the only true way to confirm that the testing occurred and support the findings. And of course it’s important to loop back to my earlier comment: Examiners will absolutely ask you for the work papers. I routinely receive phone calls from clients I’ve worked with at my previous firms asking if I still had access to their work papers because their examiner is asking for them. It’s awful for me because I have to tell them that while the evidence is still available (I keep everything for seven years for fieldwork I’ve conducted) there are no formal work papers to provide. Thus the reason that when we started our firm and developed the methodologies, I made certain that part of the scoping process included asking the client if work papers were to be included in the deliverables. It adds time to the project and so there’s a cost implication, but it’s the right way to run an audit and so really a need-to-have. You can take a short cut where applicable and only document findings but even so, how can you prove that a successful test was actually successful? For those practitioners looking for shortcuts it provides the wrong incentive.

If you want/need an audit, schedule an audit. If you want/need a risk assessment, schedule a risk assessment. If you’re considering a review or a generic assessment reconsider; decide which of the two proper categories your work fits into and than schedule accordingly. This isn’t rocket science; the FDIC and NCUA have been quite clear as to what you’re required to do so keep it simple. And if the resources you’re using aren’t speaking in the common audit and compliance vernacular force their hand and make them do so. Audit or risk assess, pick one.

1  Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.
  • Koolhits Few challenges which are common to IT project management stream are unrealistic deadlines, communication deficits, scope changes, uncertain dependencies, failure to manage risks, lack of skills, lack of accountability, communication gaps between various stakeholders etc. Usually, the organizations to take up the project to portfolio do not reveal all these so openly because of one or more reasons. The worst part is when the partner organization hides the ground reality from relevant stakeholders because of whatever reasons. There are unimaginable cases where top organizations were caught doing visa frauds, deploying less skilled resources, not sharing the ground level challenges or risks and keeping project stakeholders in dark on so many other fronts. This article focuses on how service orientation in IT project management can be leveraged to improve on end to end delivery visibility, and end to end delivery governance enabling well informed decision making at all times at all stages of delivery.
    0 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: