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
·
Closing.
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;
·
Security;
·
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.
Audit evidence
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.
Conclusion
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.
Copyright
2015 Debbie Gallagher
