Role of Internal Audit in SOX Compliance 1801



  • Hi, this is my first post 🙂
    I work in an Internal Audit division of a large UK plc. I got into a heated discussion with a Manager over the classification of a control as Key v Non-Key. I had tested the control and it failed - in communicating this it was implied to me that it was MY fault that the control was designated as Primary, my fault it had to be tested, and my fault it had failed. Oh, and I was the one that needed to make a case to our Auditors to downgrade the control. Needless to say I took major issue with this. We resolved the issue but I do sometimes have to step back and think about the role of IA in SOX.
    My view is that IA are there to independently test controls, to liaise with external auditors and assist - perhaps drive - control owners to keep documentation up to date. IA cannot and should not ‘own’ controls. And while I certainly think that IA can facilitate such discussions, I don’t think they should initiate changes in designation of controls etc. If a Control Owner suddenly decides that a control is no longer primary, surely they need to make a case for a change to the Auditors and not pass this task off to IA?
    I should say that our IA division is relatively new and is only now just becoming involved in SOX - I feel that Mgmt now feel they can wash their hands of their SOX responsibilities just because IA are on board. I sense some teething problems ahead…
    Any advice that you could give would be welcomed. Anyone working in IA that can show their war wounds?.



  • Unfortunately, this seems to be a common issue for Internal Audit. We as internal auditors are in the tough position as liasons between management and external auditors. Part of that position seems to be that we do the things you mentioned above. Unfortunately, many times the argument to downgrade a key control falls into our hands.
    My recommendation to you, is that if you don’t feel comfortable approaching the externals with the change by yourself, see if management would be willing to sit in on a meeting with you and the externals and help make the case for the control.
    My most interesting ‘war story’ if you will happened last quarter. A division in my ogranization has a policy where large expenditures are approved beforehand and if the division overspends on something they must have the overspend approved as well. Typical expenditure control…well one department was not following this rule. They were overspending by large amounts and not receiving the approval until a significant time had passed in case more spending became involved…that way they would only approve the overspend once.
    The obvious problem is that this department is spending LOTS of company money without any sort of approval. When I failed the control for Sox purposes, management’s argument was that this is just the way things are done, even though their policy completely contradicts.
    I was unable to convince them to follow policy…so the decided remediation…change the policy so that overexpenditures don’t have to be approved until up to 2 months are they are made.
    Tell me if you think that control is effective.
    J



  • Yes, a common dilemma. I work in the corporate office for a company that has 7 very decentralized subs located throughout the US and one in Canada. As a one-man audit shop, I’ve been charged with bringing the entire company into compliance by year end 2007. My role has been to develop templates, communicate the corporate approach to implementing SOX to the subs, review all of the SOX documents created by the subs, and be the liaison between managment and the auditors. Overall, a daunting task, to say the very least. It has yet to be decided how much, if any, independent testing I will do in 2007, if I remain here that is. I regularly inform the CFO that the 404 assessment is a function of management and not IA, and that he/they should be more actively involved in developing SOX documents. 2007 will be a very interesting year for this company indeed.



  • in communicating this it was implied to me that it was MY fault that the control was designated as Primary, my fault it had to be tested, and my fault it had failed. Oh, and I was the one that needed to make a case to our Auditors to downgrade the control.
    Even though it hadn’t been a primary control, it still should be functioning as it has been identified as a control. It is his process, and as a process owner, it is his responsibility that the documentation that is included in his sign-off is correct. If he’s signed it and it fails, it’s his responsibility. It’s as easy as that 🙂
    But, yes, I sometimes get the same response as you did.



  • For objectiivity, SOX key controls should be determined by management.
    I am the management. I have my reverse stories. I have come across IAD having a tendency to determine non key controls as key controls to justify their existence.
    For e.g. access to non critical shared folders have been determined to be a key control by them and added this deficiency to other similar deficiencies in their presentation to the audit committee. Our external did not fall for this and qualitatively filtered out such deficiencies to determine effectiveness or otherwise of our ITGC over ICFR.



  • Hi,
    To add to the previous comments, a key control may be identified in OBJECTIVE terms and this approach may reduce ‘negotiation’ tactics (positive or otherwise) to help you to reach an early solution with all concerned parties (management, external audit, process owner, internal audit)
    The link below is for a discussion of key controls and provides specifics.
    http://www.sarbanes-oxley-forum.com/modules.php?name=Forums-and-file=viewtopic-and-t=1421-and-highlight=key control
    Hope this further helps,
    Milan



  • Hi, this is my first post 🙂 %0AHi and welcome … I’ll share from yet another viewpoint, that of IT.%0A I work in an Internal Audit division of a large UK plc. I got into a heated discussion with a Manager over the classification of a control as Key v Non-Key. I had tested the control and it failed - in communicating this it was implied to me that it was MY fault that the control was designated as Primary, my fault it had to be tested, and my fault it had failed. Oh, and I was the one that needed to make a case to our Auditors to downgrade the control. Needless to say I took major issue with this. We resolved the issue but I do sometimes have to step back and think about the role of IA in SOX. %0AThe business area had to blame someone 😉 🙂 More seriously though, SOX involves a lot of judgement and interpretations at times. You were right to stand your ground and get this resolved satisfactorily. Even though this was a difficult process, your area has rightfully earned respect in the process. %0A My view is that IA are there to independently test controls, to liaise with external auditors and assist - perhaps drive - control owners to keep documentation up to date. IA cannot and should not ‘own’ controls. And while I certainly think that IA can facilitate such discussions, I don’t think they should initiate changes in designation of controls etc. If a Control Owner suddenly decides that a control is no longer primary, surely they need to make a case for a change to the Auditors and not pass this task off to IA? %0AThat’s indeed a good mission statement for IA 🙂 They are a service resource to the organization to ascertain and promote the best practices for controls on a daily basis. They are a valuable service functioning as part of the mainstream operations of the business, where as External Auditors (EA) are engaged contractually as needed.%0A I don’t think they should initiate changes in designation of controls etc. If a Control Owner suddenly decides that a control is no longer primary, surely they need to make a case for a change to the Auditors and not pass this task off to IA? %0A %0AI could see IA rendering expert opinion on this and helping coordinate ideas with the external auditors as needed. It is more appropriate for the business area and IT to recommend controls and for IA to bless them. I don’t see anything wrong though with IA sharing ideas to help facilitate the process, if the area is struggling on control designs.%0A I should say that our IA division is relatively new and is only now just becoming involved in SOX - I feel that Mgmt now feel they can wash their hands of their SOX responsibilities just because IA are on board. I sense some teething problems ahead… %0AChange is always a difficult process in any organization. As a new organizational entity, the business areas may also be confused on what IA’s role is? (e.g., as evidenced in your 1st ‘close encounter’). Maybe, senior management could better clarify this with a brief overview of IA’s mission statement to the staff, if future issues surfaced%0AHopefully, over time IA will partner with the business areas and IT, as all of you guys work for the same company and wish for it to succeed. That still means you have to sometimes stand your ground for the good of the company in meeting it’s fiscal and control obligations. Time plus a continued effort will help overcome these early struggles. %0A Anyone working in IA that can show their war wounds?. %0AI’ve worked with closely with Audit (IA and EA both) over my 30+ years in IT. As a victum, I mean participant 😉 in many audits, I had to write responses back as to whether I agreed with their recommendations. In well over 90% of the cases, I agreed. Like all humans, not all recommendations have been completely accurate or realistic, but this group of professionals earned my respect. Over the years, their advice on controls, workflows, and other best practices have made a difference in my application system designs.



  • I am the management. I have my reverse stories. I have come across IAD having a tendency to determine non key controls as key controls to justify their existence.
    Management owns key/non-key controls and should have final say on which controls are significant for the 404 assessment. The IA’s responsibility should be to provide advice and guidance. If management insists that any given control is key or not key in contradiction to what IA has recommended, then IA should try to get it in writing and let it go. When the s**t comes down, let management, whether it be that of IA or the process owner, defend their decision.
    If your IA function needs to justify their existence by identifying bogus controls, then maybe the annual audit plan should be re-evaluated with priorities assigned to areas (i.e. actual internal audits) that warrant IA’s attention and time.


Log in to reply