Triggers of an IT Audit

Audits sometimes have a very stringent nature and may therefore be perceived as threatening or unfriendly by inexperienced participants. This perception is often reinforced by scenes from television, where hordes of lawyers ‘march’ into a company to turn it upside down. But is it really always like this? In fact, this type of audit does exist, usually in connection with legal violations or similar allegations, where the wind can indeed blow a bit ‘rougher’. Terms like ‘compliance audit’ or ‘litigation audit’ are often used keywords here. However, even in this case, the presumption of innocence applies in the first step, and especially the approach in our latitudes does not necessarily have much in common with the approach that Hollywood suggests.

In many cases, however, the reasons for an audit are much friendlier, but no less structured and associated with a professional approach. A company wants to grow and addresses the question of whether today’s IT landscape is even suitable for this growth. Exemplary questions can be: Are the capacities in the data center sufficient, is the infrastructure sufficiently redundant, can the team cover the extended service times? Another example is the case of special certifications where the company has committed to following certain process frameworks (e.g., ISO 27001 or ISO 9001), and compliance with these must be randomly checked as part of recertification. Especially in the financial industry, as part of the so-called Basel guidelines, the necessary risk management[1] is largely tied to corresponding IT processes, which need to be regularly reviewed. Sometimes it’s less about how IT operations are performed, but more about the cost structures behind them. A regular ‘airing out’ of older contracts and comparison with current market prices can reveal significant potential in the area of cost optimization.

Approach

Whatever the trigger for the (ordered) audit may be, in almost every case the conducting audit team is looking for good cooperation with those affected, because in a cooperative collaboration, tasks are completed much faster and more efficiently. At digatus, we apply a transparent approach based on current industry standards[2] for this purpose, which has proven successful in previous projects.

A core element is clear project communication at the beginning of the audit to convey the client’s expectations and the cooperation tasks of the area to be audited to all involved persons. Especially in our first case, “Compliance Audit,” which aims to identify suspected violations or misconduct by individuals or departments, a high level of cooperation from the affected persons is required to identify and find the respective evidence in constructive collaboration. It becomes trickier when cooperation is lacking, necessary data has been deleted, or attempts have been made to destroy it through physical damage. In such situations, specialists are deployed who are capable of extracting individual raw data piece by piece from any data carrier in painstaking detail and reconstructing the “big picture” from these puzzle pieces. Observing the corresponding colleagues at work often gives more the impression of a research laboratory than an IT company, and all kinds of special tools and equipment are used. Interested readers are recommended to refer to the “IT Forensics Guide”[3] of the Federal Office for Information Security (BSI), which provides a good overview and describes possible scenarios and procedural models.

The situation is different when it comes to the mentioned occasion of company growth or checking compliance with process models. Here, there are basically no limits to the possibilities, and the type and scope of the audit should be agreed upon with the client and their expectations. In the simplest case, existing IT capacities are reviewed, a plan for expected growth is created together with the IT team, and this is compared with the possibilities found. In a more in-depth variant, the maintenance status of an IT landscape can also be checked by assessing the version statuses of the components used in terms of their software and firmware and comparing them with any manufacturer recommendations. With an extended approach, existing support and maintenance contracts can also be reviewed, as well as the extent to which the products used are still supported by the manufacturer and, for example, whether spare parts supply is ensured in case of failure. If you want to go a step further, the systems and processes in focus can be subjected to real-world tests under actual stress, and their respective behaviors can be evaluated. In the security area (firewalls, public web services, etc.), so-called “penetration tests” (also known as “pen tests”) are used. These attempt to identify security vulnerabilities or undesired behavior through exhaustion or overload on the affected systems using special software. An example in the security environment is the “OWASP” project[4] for application testing, which has a collection of best practice approaches and tools. It’s not uncommon for many self-developed tools of the auditor to be used in this approach, representing their special know-how.

The situation is slightly different in the area of load tests for, for example, online shops or ERP systems, where the respective load limits are to be explored by artificially generating utilization (orders, simultaneous visitors, production processes, etc.). Especially in the area of trading systems and web shops, for example, a loading time of more than three seconds on an order page can result in a significant double-digit percentage of customers who drop out and do not complete their purchase, thus directly affecting the company’s business success[5]. Last but not least, such auditing projects can also test fail-over scenarios or the responsiveness of service processes, etc., by having the audit team, in close coordination with the client, perform unannounced but targeted shutdowns or decoupling of individual components, from a simple edge switch to the central core switch to the ERP system or domain controller. Here, the respective IT solutions can now prove their redundancy, or in the case of service teams, demonstrate their ability to quickly and accurately identify the correct source of error and resolve it.

The review of contracts with service providers is much more theoretical, where the primary goal is to compare the current service scope of the contracts with what is actually being provided, as well as to identify potential savings by comparing with current market prices.

Results

The presentation of the approaches suggests it – as diverse as the procedural models can be, so can the results of an IT audit. To meet the client’s expectations, it is important to clearly align the requirements at the beginning to ensure that a model is chosen in the approach that enables the necessary data for the desired scope of results. Usually, the insights generated during the audits are presented in a final presentation, and a result document is created for the client, which includes the requirements, the components, systems or processes addressed, as well as their results. Since we at digatus believe that merely pointing out problems or needs for action is not sufficient, and unfortunately too many good audit results disappear into drawers without improvement, we always provide concrete recommendations for action to address the identified issues in this context – if desired, also supported by our team.

[1] Cf. BCBS 239, https://en.wikipedia.org/wiki/BCBS_239

[2] Cf. Springer: IT-Revision, IT-Audit und IT-Compliance, ISBN 978-3-658-23764-6

[3] BSI: IT Forensics Guide, https://www.bsi.bund.de/DE/Themen/Cyber-Sicherheit/Dienstleistungen/IT-Forensik/forensik_node.html

[4] The Open Web Application Security Project (OWASP), https://www.owasp.org/index.php/Main_Page

[5] Dyn: 2015 Report: Global Consumer Online Shopping Expectations, http://pages.dyn.com/rs/dyn/images/Dyn%202015%20Report-Global%20Consumer%20Online%20Shopping%20Expectations.pdf[/artikel_text]