3
1 ISACA JOURNAL VOLUME 2, 2016 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: 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 IIA 4 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 Risk 6 and Operationally Critical Threat, Asset, and Vulnerability Evaluation [OCTAVE], 7 available in versions for large and smaller organizations). 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. Auditing IS/IT Risk Management, Part 1 ©2016 ISACA. All rights reserved. www.isaca.org

Ed Gelbstein, Ph.D., Auditing IS/IT Risk Management, Part 1

  • Upload
    others

  • View
    3

  • Download
    0

Embed Size (px)

Citation preview

1ISACA JOURNAL VOLUME 2, 2016

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:

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

THE THEORYIS/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 PRACTICEUnfortunately, 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 ACTIVITIESFigure 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).

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.

Auditing IS/IT Risk Management, Part 1

©2016 ISACA. All rights reserved. www.isaca.org

2 ISACA JOURNAL VOLUME 2, 2016

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 RISKThe 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,

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 1—Scope of Auditable IS/IT Risk Management Activities

Source: Ed Gelbstein. Reprinted with permission.

Future event scenariosProject/Operations impact

Business impactFinancial/Legal impact

ERM framework, e.g., COSORole of ERM in IS/IT assessmentExtent of IS/IT integration in ERM

COBIT® 5 for RiskNIST SP 800-30OCTAVECRAMMVERISOthers

Who was trainedQuality of material

Business impactCritical facilitiesRisk identificationRisk evaluationLevel of uncertaintyResidual riskRisk transferRisk ownership

Risk oversightRisk intelligenceRisk preventionRisk reductionRisk detectionContingency plans

Risk appetiteDefinitions

Risk Communication

Risk Planning

Risk ManagementAuditable Activities

Framework Adopted

Training Given

IS/IT Business Risk

Risk ControlsRisk ManagementSystem

Risk MonitoringActiveInspectionAuditCorrective action

ReactiveInvestigationAnalysis

3ISACA JOURNAL VOLUME 2, 2016

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 CONCLUSIONThe 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 Internal Audit: Forging a Collaborative Alliance, executive report, 2012, https://na.theiia.org/standards-guidance/Public%20Documents/RIMS%20and%20The%20

IIA%20Executive%20Report%20Forging%20a%20Collaborative%20Alliance.pdf

3 The Risk and Insurance Management Society, www.rims.org 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

10 Power, Benjamin; “Writing Good Risk Statements,” ISACA Journal, vol. 3, 2014, www.isaca.org/Journal/archives

©2016 ISACA. All rights reserved. www.isaca.org

Figure 2—How IS/IT Risk Translates Into Business Risk

Source: Ed Gelbstein. Reprinted with permission.

Threats: Human accidental, human deliberate, natural forcesVulnerabilities: People, process, technology

IT benefit/valueenablement risk

IT-speak

Business-speak

IT risk translated into enterprise risk and its potential impact

IT program andproject delivery risk

IT operations andservice delivery risk

Prioritized business risk

Strategicrisk

Operationalrisk

Financialrisk

Compliancerisk

Legalrisk

Reputationalrisk