Auditors And ERPs – Can We Rest “Assured” ?
Dennis Howlett has been bugging me lately and bugging me good. All the way from Spain, he Twitters and calls and now Skypes me into thinking about what’s next.
Their comments supported my original educated gut feeling:
SAS70 issues are not getting resolved in the world of SaaS multi-tenancy and virtualized/shared compute resources.
Just take a look at one company’s approach. I’ve found it to be pretty typical of companies that are still more worried about passing their financial Sarbanes-Oxley testing than about IT controls. As if those two were not joined at the hip in a modern, automated, multinational company…
Only those processes and controls which have been deemed key, critical, high-risk or otherwise significant to achieving the company’s Sarbanes-Oxley compliance objectives are considered including key controls supporting the following IT processes:
Change Management, Logical Access, System Development Life-Cycle (SDLC), Backup, Storage & Recovery, Job Scheduling and Batch Processing, Physical Security and Incident Management.
Since the assessment of the operating effectiveness of the company’s internal controls (and by proxy, those of their service organizations) is required to satisfy SOX compliance objectives, only a Type II SAS 70 report, which assesses both the design and operating effectiveness of the service organization’s controls is relied upon.
When management’s SOX compliance testing occurs more than six months after the SAS 70 report was issued, a bridge letter certifying that changes in the design and operation of their internal controls and supporting processes (including changes in key personnel reports, contracts or service level agreements or processing errors) have not occurred since the report was issued is sought from the service organization.
Source: There is no centralized listing of the SAS 70s required throughout the company and no centralized management of the requirements for the controls to be tested by and assurances required for each vendor. In other words, [Company XXX] accepts whatever SAS 70 report the vendor sends them and files it. Therefore, our Sarbanes-Oxley testing scope was limited to the SAS 70s evaluated in 2006 and business units were contacted to obtain the reports.
Conclusion: In each case, the vendor’s Service Auditor’s Opinion for all SAS 70 Type II reports evaluated was effective for both design and operating effectiveness. However, Management’s conclusions for design and operating effectiveness will be inconclusive in all cases since very few company required controls for these processes were mapped to the service organization controls and the company’s controls were not specifically required to be opined on.
Also, since there was no centralized listing and tracking of SAS 70 Type II reports to be provided by all service providers of the company the scope matrix may not be a complete listing of all SAS 70s required to be obtained for evaluation. Therefore, we cannot provide assurance that all control objectives at individual business units for which the Company relies on outside parties have been satisfactorily met.
SAS70s are only one part of the problem with how companies are or, rather, most often aren’t getting any real level of assurance that their ERPs have the controls needed to insure the integrity of financial reporting as well as support their complex business needs.
re: The Auditors will be talking more often in the future about Information Technology as the next frontier for the audit firms, both as they try to maintain and continue to grow audit fees with or without Sarbanes-Oxley and as they attempt to restart their consulting practices.
The failure to map CLC’s and not having a centralized list of all required SAS 70 reports are both common. As an external auditor I am not overly concerned about them though because we can perform our own mapping and identify all required SAS 70’s with proper scoping and understanding of the clients systems.
To me, the real risks are:
1) Defining roles and responsibilities via access rights (SOD)
2) Improperly configured software allowing application controls to be bypassed
3) Push back from the client and the audit teams, forcing the IT Auditor to only do a cursory review of the ERP
4) Failure to identify certain application controls as key
5) Competency of client ERP admins.
6) Competency of IT Auditors
-IJustWorkHere
@IJustWorkHere Thanks much. SAS 70 was just one area around ERP risks, specifically related to growth of SaaS/cloud computing, that I wanted to mention, based on some recent conversations. You raise several more really good ones.
Hi Francine,
You and Dennis Howlett put together a great series of posts on this topic.
In your ‘Links to this Post’ section there is a link my post “Auditing IT systems” where I discuss them and add my take:
“To be able to accurately assess risk of IT system failure, three things need to be clearly understood and easily communicable:
1. Which IT assets or resources support a particular business process or service – allowing the question, “Which parts of the business will be directly affected should this IT System, or part thereof, fail?” to be answered.
2. The value of those business processes to the company operation – allowing the question “What would be the financial impact should an IT system, or component thereof, fail?” to be answered.
3. How data flows between the IT Systems that enable the business services to operate – which, critically, allows an assessment to be made of “Which parts of the business will be indirectly affected should this IT asset fail?” ”
What do you think? Your feedback is very welcome.
Regards,
Paul Wallis