Brian Sims, OCA
In my last posting, I discussed developing a strategy for your audit shop to follow complete with development standards which create your “commander’s intent” as to the direction of the Continuous Auditing System. Now that there is a structure to fit into, we move to define our audit universe and perform risk assessments over significant areas by obtaining an inventory listing of all systems implemented. This includes, but is not limited to, the network operating system and domain controller, all application programs, and the databases supporting those applications. This listing should be organized such that relationships between systems are clearly evident and systems are ranked by relevance to the audit objectives. This should look all too familiar and should tie back to systems which house the data for transactions, accounts, or operational data that are determined as material to the financial statements or other audit objectives. Something to always keep in mind and should probably be included in the CA Strategy is that the continuous auditing system is dependent upon the system it audits.
With our audit universe now defined we move into risk assessment. For me, risk assessment has multiple factors which give a comprehensive view of the risks identified. These factors include:
Likelihood – Potential for an adverse event to occur. Likelihood breaks down into these parts:
- Imminence – is a measure of how soon the event will happen from the date the risk was identified?
- Frequency – is how often it will occur once it does happen.
- Irregularity – is how consistent or predictable the event is?
Impact – which breaks down into these parts:
- Operational Impact – is the operations that will be affected and to what extent they will be affected.
- Financial Impact – is the estimated potential financial loss due to the identified event. I specifically listed this second to Operational Impact because the Operational Impact flows through and is often the source of Financial Impacts.
Using these factors, we perform upstream and downstream risk assessments of specific business processes. Using business processes allows us to see the entire transaction as it flows from department to department. Along the way, we identify application controls, the general controls that cover them, and the evidence that is available for audit which mitigate identified risks. I would suggest reviewing the system’s data dictionary (sometimes called “database schema”) as well as the user and administrator manuals to help identify where system controls exist and audit trails and control configurations are stored. This is where a good relationship with the IT department can really come in handy because they can usually take you right to the information you are looking for. For those more sophisticated systems, there may be a module like SAP’s GRC which identifies risk exposures like rights assigned to a single user that conflict with segregation of duties for you. If your systems do not have something like that, you need to expand scope and look at designing something similar into your continuous auditing system.
Always remember that risk assessment is an iterative process that needs to be revisited regularly to adjust to changes in the environment. I have seen CA systems which actually perform on going risk identification and assessments to monitor emerging issues and even make decisions as to which procedures to perform from those assessments. These systems took time to design and build but it can be done and usually pays off big time in the long run.
no comments