WHEN looking up “audit” online, one will likely come across definitions and phrases like “an audit is an evaluation (of a person, a product…)” and that an audit provides reasonable assurance that the statements are free of material errors. These definitions, however, are commonly used only when referring in general to financial audits. An information technology (or information systems) audit differs in that it evaluates the IT/IS processes, systems infrastructure and settings.
IT audits conclude by showing that the information processed by the systems in the given scope is safeguarded (at an acceptable level), accurate, reliable and provided on time, and that the operation of the systems are able to ascertain such assurance. The conclusion is drawn by identifying and assessing so-called “controls” or “control activities”, which are usually, as indicated above, various system settings, written procedures, properly signed request forms or even devices that monitor temperatures or movement.
IT audits are often associated with IT security; however, this assumption is not quite accurate. Simply put, an IT audit may not only include a security review, but could also consist of a review of the performance and systems' utilisation, evaluation of the application’s data entry and internal processing controls, a help desk/support process review, and much more.
On the other hand, a pure IT security audit may touch these areas as well, but its primary focus is on logical and physical security and its aspects in all other areas of IT. By highlighting this difference, which is not often taken into account, IT audits can be split into two categories: (1) IT process and organisation audits and (2) IT infrastructure and security audits. While the first category includes IT strategy reviews, assessment of the IT organisational structure and relationships, project management quality assurance, assessment of systems development life-cycle and review of IT processes (helpdesk, service management, application management, monitoring), the second focuses on reviewing the IT security policy and procedures, disaster recovery and business continuity management analyses, data integrity analysis, penetration testing and overall IT security assessment.
In both types of IT audit, the auditor will evaluate and assess the effectiveness of the controls in place in order to conclude whether the desired objectives are being met. The objectives are defined by frameworks, methodologies or international standards. Standards include pure IT security standards (ISO27001), more general IT process standards (COBIT), and sets of rules for particular IT areas, such as service quality and delivery (ITIL). In each of the standards, the objectives are usually grouped into general categories (e.g. daily processing, access management) with defined goals. When these goals are met or fulfilled, the risks connected with the particular area are considered minimised to an acceptable level.
As mentioned previously, a control may be a manual activity within a process, performed by relevant personnel, a system setting, system check/log, or any kind of monitoring tool or device with regards, for example to temperature, humidity monitors, etc.
The controls usually differ in the way they are processed. One type is performed manually, i.e. a “manual control” such as a formal approval of a request by a signature, while another is processed automatically, i.e. an “automatic control” such as a system verification of the minimum length of a password. Other differentiation splits the controls into preventive (the previously-mentioned formally signed request), detective (e.g. an auditor acts as a detective control), and corrective controls (as a response to detective controls).
Process of an IT audit
So far, the basics and different types of IT audit have been described. The entire process, however, is a little more complex.
An IT audit has three basic phases, starting with planning and preparation activities where the audit scope and audit type is defined and agreed upon. In order to ensure that the audit meets its given expectations, the planning activities are carried out before the fieldwork itself, which is the audit’s main phase. Once the audit fieldwork is performed, a detailed report or reports are prepared in order to finalise the audit process.
The whole audit process starts with the planning and preparation phase. Once the scope is defined, the audit category and, if applicable (for infrastructure audits), the computer environment(s) subject to the audit should be specified. As part of the next steps of the preparation phase, the IT auditor (or rather the audit team) obtains a reasonable understanding of the IT environment to be examined. A clear picture should be created by understanding the systems’ interfaces, including interfaces to/from systems out of the audit's scope, as well as the basic network topology and the multiple sites that are interconnected. Furthermore, during this phase the corresponding methodology or framework is selected against which the audit is carried out. More often than not, such framework is required by legislation as opposed to being part of an auditor’s internal methodology.
The first preparatory phase is followed by fieldwork. One vital activity included in the audit is a kick-off meeting with the company and IT management, which should be carried out to understand the organisational structure, roles and responsibilities of the audited company. At this point, it is safe to say the preparation phase has fluidly transformed into the fieldwork phase - or the audit itself - as the policies and procedures, and possibly other guiding documentation, have been reviewed and understood.
The most interesting audit work then starts, with a series of interviews and follow-ups with the system configuration/settings review and testing in order to identify and test the controls in place. Since at this point the identified controls are assessed as to whether they effectively meet their objectives, this is where “professional judgment”, the auditor’s true knowledge and experience, is required. Once the controls are identified and assessed in each area for all applications in the scope and for all objectives defined by the selected framework, the audit fieldwork is deemed finished.
The entire audit process is wrapped up with reporting. Although the final audit report is prepared and finalised as one of the last steps following the fieldwork, it is common for progress meetings to be held continuously to discuss findings and issues. Such meetings help to prevent misunderstandings and provide opportunities to report issues continuously. In the end, it is vital that the final report consist of a “management” part with “non-IT language” summary as well as detailed appendixes where more technical terms are covered. The detailed findings should then be categorised according to their importance, severity and expected remediation costs.
The final outcome of an IT audit is either to provide assurance or to document facts based on agreed procedures. In the latter, no assurance is provided. If assurance is expressed, the required assurance level must also have an impact on the scope and depth of the audit performed. In any case, the final report, identified issues and recommendations, as well as the conclusion, should be mutually agreed and accepted by the audited subject. It is common for the auditor to offer or, if agreed, to perform follow-up activities for a certain period of time after the audit is finished. This is to assure that the reported findings and issues are being dealt with and corrected.
When summing up the key points of an IT audit, namely that the auditor simply looks for controls that cover objectives according to a methodology in order to mitigate the risks or report findings that the controls are inadequate or missing and that the risks may deteriorate, one might say “What an easy job!” …Well, I wouldn’t say that!
Juraj Vrbenský, Manager, Enterprise Risk Services, Deloitte, CISA (Certified Information System Auditor)