ISACA Journal - 2016 Volume 3

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.

Risk Controls

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 about them.

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 something to say about this article? Visit the Journal pages of the ISACA web site ( www.isaca. org/journal),find the 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.