IS Audit Basics: Helping Auditees Prepare for an IS/IT Audit

Having been audited many times over the years, it would have been of great help if the auditors had taken the time to brief us on what they were going to do, why and how this would be done, and what our role in the process would be.

Many years later, having become an auditor, my choice was to make such briefings regular events, and, through them, it became apparent that many auditees did not really know what auditors do and were unfamiliar with audit terminology and methods of work.

These briefings made it clear that auditors are often seen as looking to criticize how things are done and make auditees look bad in the eyes of their senior management. To complicate matters, an organization’s audit plan may require certain audits be done at a particular time that may not be convenient to auditees, as audits inevitably disrupt their work. This column suggests a way to facilitate the preparation for and conduct of an IS/IT audit.

Explaining the Audit Purpose to the Auditees

There are examples of audit offices that have published brochures¹ explaining their role and the way audits are planned and conducted, but this may not be common practice. Too bad, because lack of understanding and clarity leads to a lack of trust before the audit has even begun and risks creating confusion about roles and responsibilities.

Auditors are accountable to senior management to provide independent and objective statements of the measures taken by auditees (whatever their role) to mitigate business risk. This implies that auditors are meant to examine, probe and challenge activities; obtain and evaluate evidence; and then report their findings and observations, including recommendations where necessary.

The internal auditors (including specialists who may be engaged for a particular audit) and the auditees work for the same organization, and, regardless of their perspectives, they should not be regarded as the enemy (but sometimes this is precisely how they are regarded).

Facts and dialog are vital components of any audit, and collaboration between auditor and auditee helps a great deal in ensuring that the final report, when produced, is a fair representation of the current status. Remember that auditors and auditees are human beings trying to do a good job.

Not All Audits Are the Same

A list of what could be audited is long, and, in practice, the most likely activities to be audited are those that link to significant business risk.

It is likely that if previous audits raised issues and included recommendations, the auditors will be interested in what has changed since these were made and may choose to re-audit some of them.

It can be assumed that documented and current business impact analyses, business continuity plans and risk assessments will be of interest to the auditors. Questions will be raised if these are incomplete, out of date or not available. Not a good start.

In addition, a short list of what could be audited would include:

• Data center audits—Including physical and logical security, process documentation and metrics. Of course, there is much more to this, including, for example, examination of controls at various levels (e.g., operating systems, applications, databases, networks, cryptography).
• IS/IT process audits—Often a COBIT 5 -based audit, which includes the COBIT Process Assessment Model (PAM): Using COBIT 5² (It replaces the capability maturity model used up to COBIT 4.1.)
• Information security audits—Focusing on the controls used to manage the availability, confidentiality and integrity of information
• IS/IT systems development audits—Focusing on the specification, development, testing, initial data loading, accreditation, and, in particular, security and business process controls
• IS/IT large software projects audits—Related to the previous item, but focusing on project management processes, change management and reporting (A series of columns on this topic is planned for future issues of the ISACA Journal.)
• Postimplementation benefits audits—Occur once a project has been completed and has been operational for some time. These audits are intended to validate whether the benefits identified in the original business case for investing in the project have been achieved.
• Business continuity audits—To review the resiliency, recovery and other contingency plans prepared to restore an appropriate level of normalcy after a situation that heavily disrupts the organization’s IS/IT facilities
• IS/IT management/governance audits—Particularly important when relying on external service providers (i.e., outsourcing and offshoring service providers). Such audits examine cost recovery or charging systems, budgeting and cost control, and organizational structure.
• Change management audits—Reviewing the procedures and systems used to control changes to infrastructure, software and the changes in relationships arising from organizational changes and/or the introduction of new technologies (such as bring your own device [BYOD])

And there are more areas of audits generally conducted by other, often external, auditors, such as those for compliance certifications (e.g., ISO 27001 or the Payment Card Industry Data Security Standard [PCI DSS]) and IS/IT strategy audits. This list excludes investigations because these require a different skill set and good knowledge of the legal requirements for collecting and preserving evidence in case the investigation leads to litigation.

Figure 1 illustrates the three dimensions of all audits: the type of audit, the depth of detail for which it aims and the frequency at which the audits are performed.

Each selection point has identifiable resource requirements, as well as a cost and duration—all of which support the audit planning process.

What the Auditees Should Know About the Audit Process

Auditors are expected to know exactly how an audit is planned and executed, but auditees may not be in a position to share this knowledge and may find themselves poorly prepared. A presentation or brochure on the audit process should have concise descriptions of each stage:

• Audit stage 1—Notification to the auditee stating the purpose of the audit, who will conduct it and the target timing
• Audit stage 2—Scoping the audit, defining the areas to be covered and including a first list of documentation to be provided to the auditors
• Audit stage 3—Fieldwork consisting of interviews, site visits, documentation reviews and tests
• Audit stage 4—Reporting, ranging from discussions, a draft report, obtaining comments from the auditees, and exit conference and the issuance of a final report
• Audit stage 5—Following up at a later date to assess the progress made on issues identified in the report

Auditees should consider the following activities³ immediately after receiving notification of an audit:

• Review the audit history and the status of past recommendations.
• Review the documentation relevant to the scope of the audit for completeness.
• Brief the team to be audited. The message: The auditors are not the enemy and they may help the IS/IT function raise issues with management.
• Prepare to treat auditors as team members: Exchange names, accompany them, share coffee breaks and lunches (at least from time to time), and provide them with adequate office facilities and support.
• Request clarifications whenever there is doubt or ambiguity in a question, request or statement.
• Request time to study the draft report findings and observations, and point out items that may not be an accurate description of the situation (providing facts, not opinions, to make the point).
• Participate in the exit conference and ensure that any points that need to be made are, in fact, made.

Conclusions

The topics discussed here are considered to be necessary, but not sufficient to ensure that the audit will be a collaborative exercise and that the auditees will approach the process in a positive manner. On the other hand, ignoring these points will likely result in a difficult audit.

Endnotes

¹ Office of Internal Audit, “Preventing, Detecting and Managing Fraud,” South Carolina University, undated
² ISACA, COBIT Process Assessment Model (PAM): Using COBIT 5, USA, 2013
³ Gelbstein, Ed; “Successful Audits Do Not Just Happen,” ISACA Journal, vol. 2, 2015, USA

Ed Gelbstein, Ph.D., has worked in IS/IT in the private and public sectors in various countries for more than 50 years. He did analog and digital development in the 1960s, incorporated digital computers in the control systems for continuous process in the late 60s and early 70s, and managed projects of increasing size and complexity until the early 1990s. In the 1990s, he became an executive at the preprivatized British Railways and then the United Nations global computing and data communications provider. Following his (semi)retirement from the UN, he joined the audit teams of the UN Board of Auditors and the French National Audit Office. He also teaches postgraduate courses on business management of information systems.