IS Audit Basics: Auditing IS/IT Risk Management, Part 1

There are significant differences between conducting an IS/IT audit and conducting an IS/IT risk management audit.

The Theory

IS/IT auditors ought to be knowledgeable about the risk owned by the chief information officer (CIO) and her/his team and those that have been externalized (outsourcing, cloud services, other providers, vendors, etc.). In an ideal situation, at least some of the IS/IT audit team should have a certification such as ISACA’s Certified in Risk and Information Systems Control (CRISC).

Those involved in the enterprise risk management (ERM) function should be able to determine the business impact of the risk associated with IS/IT. Ideally, at least some of the team should have a certification such as Certified Information Systems Auditor (CISA) or Certified Information Security Manager (CISM).¹

In 1999, The Institute of Internal Auditors (The IIA) published an updated definition of internal auditing, describing it as “an independent, objective assurance and consulting activity designed to add value and improve an organization’s operations. It helps an organization accomplish its objectives by bringing a systematic, disciplined approach to evaluate and improve the effectiveness of risk management, control and governance processes.”²

The Risk Management Society (RIMS)³ defines ERM as a strategic business discipline, while the IIA⁴ defines it as a structured, consistent and continuous process across the whole organization.

The CIO should be able to provide appropriate risk assessments for systems and services, ideally based on a formal framework and, to the extent possible, quantified. These risk assessments and a related risk register describing mitigation plans, their ownership and time scales should have a clear link to the business impact analyses that support business continuity plans.

Business managers and systems and data owners are responsible for prioritizing risk for appropriate action and, thus, become the risk owners. This implies that internal audit takes on an assurance role that excludes consulting and partnering in risk management.

The Practice

Unfortunately, this is not always the case. This author audited several well-known organizations that merely played lip service to risk management at all levels. They went through the motions of engaging consultants to run a brief workshop on risk maps (heat maps), asked their staff to develop them quickly, put them all in a big file and claimed they had done risk management.

Given that internal audit and ERM both exist to provide independent and robust advice to senior management, friction between them—let alone a turf war—would be bad for business.

This article provides a map of the IS/IT risk management activities that are auditable and shows how to maintain a collaborative relationship with the ERM team while avoiding conflicts of interest.

Auditable Activities

Figure 1 shows a top-level map of the things an auditor may consider including in an IS/IT risk management audit assumed to be conducted by the CIO and her/his team.

The organization’s business continuity and impact assessment studies, assuming they exist and are regularly updated, assist the auditors in defining the scope of audit. If these do not exist or are outdated, the first critical audit recommendation should be that they be conducted as a matter of urgency.

Figure 1 illustrates that there are enough activities to keep auditors busy for quite a while, and a good start would be to find out which of them have been done, by whom and when. It may be useful to identify first if a formal framework for risk management was adopted by the IS/IT function and, if so, which one. Some are simplistic, such as drawing risk maps of little boxes colored green, yellow and red based on intuition,⁵ and others are relatively complex, requiring considerable time to master (e.g., COBIT 5 for Risk⁶ and Operationally Critical Threat, Asset, and Vulnerability Evaluation [OCTAVE],⁷ available in versions for large and smaller organizations).

Some risk assessment methodologies may be poorly suited for IS/IT, for example, those specifically designed to assess financial risk because they require complex calculations and access to historically consistent data.

Adopting a methodology is, in itself, not enough if those who need to apply it do not know how. This implies some kind of training and much study. Study requires time, and in today’s corporate environment it is hard to make time⁸ as the “urgent” displaces the “important” and the trend toward open plan accommodation and densely packed cubicles makes concentration on learning harder to achieve.

IS/IT Risk Translated Into Business Risk

The Risk IT Practitioner Guide⁹ (issued before COBIT 5 for Risk) is a valuable document. Figure 2 presents a variant of one of the guide’s figures (figure 5 in chapter 1) that shows how the starting point in the CIO’s risk assessments is transformed into business risk.

The CIO and the chief information security officer (CISO), as custodians of the organization’s systems and data, including incident management and disaster recovery plans, necessarily focus on the threats and vulnerabilities that can adversely affect business operations without necessarily being conversant with the contents of the various business impact analyses carried out on a regular basis, the risk appetite of the organization or the organization’s priorities for mitigating business risk.

What often happens is that, having identified threats (from hackers to earthquakes) and vulnerabilities (the usual triad of people, process and technology), the CIO moves quickly to address issues that, in terms of business impact, may not be at all important and are, therefore, a poor use of resources. Achieving a successful translation into business risk requires extensive dialog with business process owners, senior management and the ERM team, and collaboration toward producing an integrated risk register that can then be used to request the resources needed to mitigate the highest risk to the business.

However, this requires every one of the players to make time available for such discussions and engage in a spirit of collaboration, not allowing it to be inhibited by unavoidable corporate politics. Small organizations may not have a formal ERM team and/or business processes and may, therefore, have limited knowledge of risk and impact assessment.

Preliminary Conclusion

The reader may find the short article, “Writing Good Risk Statements,”¹⁰ very helpful. It confirms the statement, “If you think this is simple, you just have not looked closely enough.” Part 2 of this column will examine the remaining branches of the map in figure 1, i.e., risk controls, risk management system, risk communications and risk scenario planning.

Endnotes

¹ ISACA, Certified in Risk and Information Systems Control
² The Risk and Insurance Management Society and The Institute of Internal Auditors, Risk Management and Internal Audit: Forging a Collaborative Alliance, executive report, 2012, http://na.theiia.org/standards-guidance/Public%20Documents/RIMS%20and%20The%20IIA%20Executive%20Report%20Forging%20a%20Collaborative%20Alliance.pdf
³ The Risk and Insurance Management Society, www.rims.org
⁴ The Institute of Internal Auditors, www.theiia.org
⁵ Gelbstein, E.; “Quantifying Information Risk and Security,” ISACA Journal, vol. 4, 2013
⁶ ISACA, COBIT 5 for Risk, USA, 2013
⁷ CERT Division, OCTAVE, Software Engineering Institute, Carnegie Mellon University, USA, www.cert.org/resilience/products-services/octave/octave-method.cfm
⁸ Adams, S.; The Dilbert Principle: A Cubicle’s-Eye View of Bosses, Meetings, Management Fads & Other Workplace Afflictions, HarperBusiness, USA, 1996
⁹ ISACA, Risk IT Practitioner Guide, USA, 2009
¹⁰ Power, Benjamin; “Writing Good Risk Statements,” ISACA Journal, vol. 3, 2014

Ed Gelbstein, Ph.D., 1940-2015, worked in IS/IT in the private and public sectors in various countries for more than 50 years. Gelbstein 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 ‘90s, 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. Thanks to his generous spirit and prolific writing, his column will continue to be published in the ISACA Journal posthumously