Consulting and Early Involvement-There s More to Being an Auditor than Auditing

Consulting and Early Involvement-There's More to Being an Auditor than Auditing

The cost of correcting issues and adding controls postimplementation is significantly higher than the cost of doing it right the first time. There is no difference regarding independence between providing an assessment of a system or solution prior to implementation and providing an assessment after implementation. There is a difference, though, in how much value the auditor is adding to the company.

Note 

Just like quality, internal controls need to be built in up front.

Unfortunately, many auditors use independence as an excuse to not add value and to not provide opinions. You can be independent and still work side by side with your fellow employees to help them as they develop a solution to an internal control problem. Being independent does not mean that you can't provide an assessment of controls within a system prior to deployment. Time and time again you'll see internal audit departments that refuse to provide guidance and input to teams that are developing new systems or processes. They say that they can't provide input on the controls within the system because to do so means that they'll no longer be independent. They say, "How can you audit something if you've already signed off on the controls?" This is a great way to avoid work, but it is utter nonsense.

Many auditors are frozen with fear when asked for a preimplementation opinion. What if they give bad advice? Then they are as responsible for the control failure as the IT folks who implemented the system. Surely it's better to say nothing and let the IT people "sink or swim" on developing controls, right? The auditors always can audit them later and tell them where they screwed up. This is a ridiculous scenario, but unfortunately, it happens all the time. It's wrong for the company, and it's wrong for the auditor. Auditors need to be willing to step up to the plate and provide input. Whether you provide an opinion before implementation or after, you still should be providing essentially the same input. Thus, how does providing such input this week damage your independence, whereas providing it next week (after implementation) doesn't? There's no logic to it.

Is there a chance that you might miss something or give bad advice with this upfront involvement? Of course. Just as there's a chance during any traditional audit that you might miss something or give bad advice. It's always a risk, and you just need to get over it and do your best.

Note 

A key question that often comes up relates to the future independence (or objectivity) of the auditor who performed the upfront consulting work. Can he or she be allowed to audit the system in the future? Or is he or she compromised by the fact that he or she already has signed off on the controls and won't want to make himself or herself look bad by admitting that he or she missed something? This is certainly something worth considering. However, we all need to reserve the right to "get smarter" and not apologize if a postimplementation audit results in an issue being raised that we didn't consider preimplementation. The auditor who was involved before implementation is going to be your most knowledgeable resource for a postimplementation audit. It seems a shame to not use this resource. As mentioned earlier, the point of the audit is to improve internal controls. Who is better suited to perform a detailed audit than the person who was involved with the project team in the first place? If there continues to be a concern about that auditor's objectivity, then you might consider making him or her a team member but not the team leader. This will provide an extra layer of review over his or her work to ensure that he or she is not being unduly influenced by his or her prior work.

Are there lines that shouldn't be crossed when it comes to working with teams before implementation? Absolutely. The auditor generally should be involved with the team in an advisory capacity. This can and should include being involved in detailed discussions regarding how the internal controls are going to be designed. The auditor should not be afraid to roll up his or her sleeves and help to think through how the controls should work. However, this should not include actually executing the control, writing the code for implementing it, or configuring the system. We can't both own the control and audit it, but we should feel comfortable providing as much input as possible as to what the control should look like. To do less is just limiting your ability to do what you are really paid to do, which is to improve the quality of the company's internal controls.