ISACA Journal Author Blog

ISACA > Journal > Practically Speaking Blog > Posts > Auditing Applications: How It Is Similar to Other IT Audits, and How It Is Different

Auditing Applications:  How It Is Similar to Other IT Audits, and How It Is Different

| Published: 7/30/2012 8:12 AM | Permalink | Email this Post | Comments (2)
Tommie W. Singleton, Ph.D., CISA, CGEIT, CTIP, CPA
Auditing applications has a process that is much like a general process for any IT audit. There is a risk assessment, mapping/flow charting/data flow diagrams, audit objectives, planning, identify key controls, tests and reporting.
The best way to gain an adequate understanding of a system and all of its applications, technologies and controls is through some kind of flow charting—be it a systems diagram, process diagram or data flow diagram. The best understanding probably includes the key aspects of all three. But it is even more important in an audit of applications in order to properly scope the audit and evaluate the sufficiency of testing.
Therefore, in order to adequately audit applications, the IT auditor needs a good understanding of the IT involved with the application being audited. Those facts include the operating system (O/S), database management system (DBMS), physical data location, server/host and applications that interface with it (if any) and should be mapped. Each of these components could potentially impact the operational effectiveness of that application, a different component of the IT environment or a system as a whole. Other mapping information that is relevant would include whether it is developed in-house or by a vendor, whether it is maintained in-house or by a vendor, who is the owner, how is access administered, how change control is being managed and any other pertinent notes.
A similar benefit is gained by mapping the risk of a particular application. Each risk should first of all be identified individually, the specific area or nature of the risk, audit objective for this risk, procedures needed by the IT audit of the application, a work paper reference for the procedures, scope of systems or technologies involved, inherent risk, control risk and assessed residual risk. Additional information might include number of audit days needed to complete the audit, the percentage complete to date and the number of days left to complete (along with notes) per risk.
A third mapping process should include the operational processes involved with the application, with a corresponding mapping of the data flows for the data being affected by that application—including “downstream” data flows. A more thorough map would work backwards to include the source of data to the application and the processing interfaces of the application. It should also identify other accounting and reporting processes of that data.
While such diagrams and documentation are definitely time-consuming, the benefits for the audit process and other future needs far outweigh the costs of performing the diagramming and documenting tasks. For instance, during the audit, tracking the progress and documenting noteworthy results are easily matched to not only the application, but a specific risk. It also provides a breakout of risk assessment for the risk of the application, and individual inherent risk and control risk. This kind of documentation provides much richer information to the IT auditor and to IT management and other managers.
Altogether, an extensive mapping of the applications being audited makes the entire process more effective and maybe more efficient.
Read Tommie W. Singleton’s recent Journal article:
Auditing Applications, Part 2ISACA Journal, volume 4, 2012


Re: Auditing Applications:  How It Is Similar to Other IT Audits, and How It Is Different

Good article
Lusayo758 at 8/1/2012 1:03 AM


Interesting one
Sharon1 at 8/2/2012 1:40 PM