Auditing IS/IT Risk
Management, Part 2
Part 1 of this article described the commonalities,
differences and possible overlaps between the IS/
IT internal auditors and the IS/IT risk management
functions managed by the chief information officer
(CIO). It also suggested an audit universe for IS/
IT risk management and introduced the case for
collaboration between internal audit and enterprise
risk management (ERM). Figure 1 from part 1 is
included here as a reminder.
The discussion that follows reflects the IS/IT
auditor’s perspective. Every topic can be subdivided
into many more sections, but the intention of this
column is not to provide a detailed manual (it would
be a large book), just an overview.
The international standard ISO 31000: 2009, Risk
management—Principles and guidelines,
1 defines a
control as “any measure or action that modifies risk.
Controls include any policy, procedure, practice,
process, technology, technique, method or device
that modifies or manages risk.”
An audit of IS/IT risk management could cover
policies and procedures such as:
• Risk oversight—Audit committees and boards
of management are ultimately accountable for risk
oversight and should consider which individuals,
teams or committees have the expertise to oversee
particular risk. The auditor should seek evidence
that this has been done or is being done and
make observations as appropriate. If neither the
audit committee nor the board are involved in the
oversight of IS/IT-driven risk, a recommendation
should reflect this fact.
• Risk intelligence—Many executives may
believe that risk management requires special
technical knowledge. The book Risk Intelligence:
Learning to Manage What We Don’t Know2
disagrees and explains how four simple rules
can improve risk analysis:
1. Recognize which risk are learnable and
reduce their uncertainty by discovering more
2. Identify risk you can learn about the fastest,
particularly project risk.
3. Take on risky projects one at a time. Learn
about the risk underlying each before moving
to the next.
4. Build networks of business partners, suppliers
and customers who can collectively manage
new ventures’ risk by playing distinct roles.
In the specific case of IS/IT risk, risk intelligence
should also include operational risk by
establishing links with computer emergency
response teams (CERT) and following media
reports of current threats, e.g., botnets,
malware, denial-of-service (DoS) attacks and
industrial (and other) espionage. This sort of
information does not mean the organization
is no longer a target, but it does make the
organization an “informed target.”
Do you have
to say about
Visit the Journal
pages of the ISACA
web site ( www.isaca.
article and click on
the Comments link to
share your thoughts.
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.
The auditor should
seek evidence that
activities are being
done, to what extent
and how well.