Auditing IS/IT Risk Management, Part 1
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.
Do you have
something
to say about
this article?
Visit the Journal
pages of the ISACA
web site (www.isaca.
org/journal), find the
article and choose
the Comments tab to
share your thoughts.
Go directly to the article:
©2016 ISACA. All rights reserved. www.isaca.org
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®).1
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.”2
The Risk Management Society (RIMS)3 defines
ERM as a strategic business discipline, while the
IIA4 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,5 and others are relatively complex,
requiring considerable time to master (e.g.,
COBIT® 5 for Risk6 and Operationally Critical
Threat, Asset, and Vulnerability Evaluation
[OCTAVE],7 available in versions for large and
smaller organizations).
ISACA JOURNAL VOLUME 2, 2016 1
 Figure 1—Scope of Auditable IS/IT Risk Management Activities

COBIT® 5 for Risk

Future event scenarios NIST SP 800-30
Project/Operations impact OCTAVE
Business impact Risk Planning Framework Adopted CRAMM
Financial/Legal impact VERIS
Others
Risk Communication
Risk appetite
Training Given
Definitions Who was trained
Quality of material
Risk Monitoring
Risk Management
Active Auditable Activities IS/IT Business Risk
Inspection
Audit Business impact
Corrective action Critical facilities
Risk Management Risk Controls Risk identification
Reactive System Risk evaluation
Investigation Risk oversight Level of uncertainty
Analysis Risk intelligence Residual risk
ERM framework, e.g., COSO Risk prevention Risk transfer
Role of ERM in IS/IT assessment Risk reduction Risk ownership
Extent of IS/IT integration in ERM Risk detection
Contingency plans
Source: Ed Gelbstein. Reprinted with permission.

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 time8 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 Guide9 (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,
2 ISACA JOURNAL VOLUME 2, 2016
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
©2016 ISACA. All rights reserved. www.isaca.org
 Figure 2—How IS/IT Risk Translates Into Business Risk

Threats: Human accidental, human deliberate, natural forces

Vulnerabilities: People, process, technology

IT benefit/value IT program and IT operations and

enablement risk project delivery risk service delivery risk

IT-speak

IT risk translated into enterprise risk and its potential impact

Strategic Operational Financial Compliance Legal Reputational
risk risk risk risk risk risk

Business-speak
Prioritized business risk

Source: Ed Gelbstein. Reprinted with permission.

collaboration, not allowing it to be inhibited by unavoidable IIA%20Executive%20Report%20Forging%20a%20

corporate politics. Small organizations may not have a formal Collaborative%20Alliance.pdf
ERM team and/or business processes and may, therefore, have The Risk and Insurance Management Society, www.rims.org
3

limited knowledge of risk and impact assessment.
PRELIMINARY CONCLUSION
The reader may find the short article, “Writing Good Risk
Statements,”10 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
1 ISACA, Certified in Risk and Information Systems Control,
www.isaca.org/Certification/CRISC-Certified-in-Risk-and-
Information-Systems-Control/Pages/default.aspx
2 The Risk and Insurance Management Society and The
Institute of Internal Auditors, Risk Management and
10
4 The Institute of Internal Auditors, www.theiia.org
5 Gelbstein, E.; “Quantifying Information Risk and
Security,” ISACA® Journal, vol. 4, 2013, www.isaca.org/
Journal/archives
6 ISACA, COBIT® 5 for Risk, USA, 2013, www.isaca.org/
COBIT/Pages/Risk-product-page.aspx
7 CERT Division, OCTAVE, Software Engineering Institute,
Carnegie Mellon University, USA, www.cert.org/resilience/
products-services/octave/octave-method.cfm
8 Adams, S.; The Dilbert Principle: A Cubicle’s-Eye View of
Bosses, Meetings, Management Fads & Other Workplace
Afflictions, HarperBusiness, USA, 1996
9 ISACA, Risk IT Practitioner Guide, USA, 2009,
https://www.isaca.org/bookstore/Pages/Product-Detail.
aspx?Product_code=RITPG
Power, Benjamin; “Writing Good Risk Statements,” ISACA

Internal Audit: Forging a Collaborative Alliance, executive Journal, vol. 3, 2014, www.isaca.org/Journal/archives
report, 2012, https://na.theiia.org/standards-guidance/
Public%20Documents/RIMS%20and%20The%20

©2016 ISACA. All rights reserved. www.isaca.org ISACA JOURNAL VOLUME 2, 2016 3