Over the last few decades the internal audit world has progressively begun to embrace the notion of using computer aided auditing tools and techniques (CAATTs) as a means to gain efficiencies, greater coverage and ultimately greater assurances over specific transaction classes or areas of operation. Mostly, these are ad hoc tests which rely heavily on the audit software (i.e., ACL, IDEA, MS Access, etc.) and an auditor with an adequate knowledge of the audit software. However, there are some audit shops which have developed their CAATTs into a fully integrated and automated continuous auditing (CA) system. So what’s the difference? Both have the same goals in mind but only one has actually made the vision a reality. This post begins a series focusing on how to structure your audit department, interdepartmental relationships, systems and scripts to build an effective continuous auditing (CA) model. We will examine some of the “how to’s”, “what if’s” and “absolute do not’s” that inevitably happen along the way.
Most people I have encountered want to dive right in and start using the software to audit. However, it is my opinion that taking this approach will only get you as far as ad hoc testing. My best suggestion is to spend the time up front discussing and developing documentation and development standards. These standards should include things like:
- A clearly stated intent of the CA system
- How to properly document the objectives and assertions covered for a test
- How a test fits into the overall CA scheme
- Program or Script process flow documentation
- How and where the files will be saved
- Testing review and approval channels for new audit procedures
- Approvals and documentation around audit procedure retirement
- Dummy checks
- Audit team CA roles and responsibilities definitions
Other considerations include: contingency planning and error handling, data access and availability, version control and audit exception handling and resolution. (Most of this can be borrowed from programming industry best practices and the System Development Life Cycle.) Going through this exercise sounds boring and time consuming (and it is) but it will help avoid countless headaches and backtracking later. Once these are fully documented, however, do not just put this on a shelf and forget about it. These standards should be revisited regularly to examine what is working, what isn’t working and why. Then, fine tune as needed.
From here, I would suggest performing an S.K.E.A. (Skills, Knowledge, Experience, and Ambition) inventory of the Audit Staff. This inventory should tell you who your audit procedure developers probably will be, who needs training, and who is willing to train as a backup in case another auditor leaves. Changes of personnel in the audit department will impact operations less if all of this is in place.
This is by no means an exhaustive list and audit departments will inevitably come across situations not addressed here, but the keys to being successful are keeping your head in the game, having well trained staff that does the same and, when needed, contacting an experienced and knowledgeable professional for added support.













