In a previous article, I described the various types of auditors that may audit your IT project, and why your project could be selected for audit. In this article, I’ll explain the major steps in the audit for an IT application development or implementation project. In addition, I’ll provide some information on what the audit is likely to cover, and some insight into audit evidence requirements.
Steps in the audit
The audit of your project is also a project, so you can expect similar steps to occur:
· Planning and Scoping;
· Execution; and
Planning the audit
No two IT projects are the same, so before planning can start, the auditor needs to understand the project. To develop this understanding, the auditor will usually meet with IT and business representatives, as well as read background material that describes the project. The auditor will also find out what the audit requirements are. For example, if it is a financial statement audit, he or she will meet with the financial audit team to understand the areas of audit risk and what audit procedures they already have planned to cover that risk.
Based on the audit requirements and the understanding of the project, the auditor will develop a scope of work and an audit plan. Once the scope and plan are approved, the audit moves into execution phase.
Executing the audit
This step is the one you are likely most familiar with. The auditor will meet with you and other project team members to ask more detailed questions and will ask for documentation to support the answers that you provide, and to show that certain areas of the project were well controlled.
Closing the audit
At this stage, the work has been completed, and the auditor will issue recommendations for improvement, usually in the form of a formal report or management letter comments. You or someone else in your organization will also be asked to provide a response to the recommendations. After the responses are gathered, the auditor presents the report to management or to the audit committee.
Areas of audit interest
Although every project is different and the audit scope is defined for each one, there are some areas that are reviewed frequently enough that you should expect the auditor to include them. These areas of interest fall into two categories:
(1) the project itself; and
(2) the new processes and systems.
For the project itself, the auditor will usually be interested in:
· Approvals for the project;
· Project governance – for example, meeting minutes, scope change control, management oversight, issues management, go-live readiness assessment;
· Testing of the new application, including unit testing, interface testing, integration testing, performance testing, business sign offs on test results;
· Customization of the application (if it’s a package);
· Security related to the data, the development environment, and application configuration; and
· Completeness and accuracy of the data loaded to the new system, as well as data integrity.
For the new processes and new systems, the auditor is usually interested in:
· Interfaces carrying data between applications;
· Segregation of duties;
· Changes to functionality and businesses processes – e.g. does the application now have multi-currency, or does it now have on-line purchase order approvals?
If you are subject to an annual audit where only a portion of the system is audited each year, the auditor also may need to change the rotation plan so that all elements are in scope for the go-live year of the new systems.
According to the International Auditing and Assurance Standards Board (IAASB) Handbook, “The auditor should obtain sufficient appropriate audit evidence to be able to draw reasonable conclusions on which to base the audit opinion”. (International Standard on Auditing (ISA) 500, paragraph 2).
It goes on to describe in paragraph 7 that “Sufficiency is the measure of the quantity of audit evidence”, and that “Appropriateness is the measure of the quality of audit evidence”.
You can see that the auditor is required to ask you for relevant documentation, and will review it and test it. Testing means that the auditor performs some procedures to verify the usefulness of the document as audit evidence. There are numerous possible audit procedures available to the auditor and they are not covered here, but here are a couple of illustrations. For example, for your document that shows the reconciliation of data conversion, the auditor may select data from both systems and check that it agrees to what shows on your reconciliation document. Or, to verify your application testing, the auditor may select a sample of completed test cases to see if they have the results documented and signed by the tester.
Some of the examination of the project is done to provide insight for the auditor into areas of risk for the new processes and systems. For example, in reviewing the issues database for the project, the auditor will assess whether issues were tracked and followed up during the project. In addition, he or she will check to see if any high priority and high impact issues were still open at go live. If they are areas of audit interest, the auditor will likely follow up to determine what mitigation strategies were implemented in the new environment to deal with errors that may have occurred due to those open issues.
Because the auditors need to collect evidence as part of their review, you should not throw away any project documentation until after all of the relevant auditors have completed their work.
You can ask early in your project to meet with the various auditors. This should allow you to find out what areas are of particular interest, so that you can make sure your documentation is retained for their work.