IT Risk Management Program

IT risk is business risk –

engage with the business to manage risk effectively

IT Risk is Business Risk

Integrate IT risk Business Risk
Therefore: management with ERM Management
using:
Accountability for IT risks and the decisions made to
address them should be shared between IT and
the business. Risk Report

A robust risk management program accomplishes this by

building permanent channels
between IT and the senior leadership team that enable risk
information and recommendations to be easily
communicated and acted upon. Risk Event Action Plan

Insight

The central goal of IT risk management is to provide

clear and accurate interpretations of IT risk to the
business regarding risk implications and response IT Risk
options. Ultimately, senior leadership is responsible for
making decisions regarding all business risk.
Management
Follow the steps to build IT risk management program

PHASE 3
Risk Risk
Governance Identification Monitor, Communicate, and
Respond to IT Risk

Risk
Response
Risk
Assessment
3.1 3.2
Monitor IT Risks Communicate
and Develop Risk IT Risk
Responses Priorities
PHASE 2
Start Here Identify and Assess IT Risk

PHASE 1 2.1 2.2

Review IT Risk Fundamentals
and Governance Identify IT Assess and
Risks Prioritize IT Risks
1.1 1.2
Review IT Risk Establish a Risk
Management Governance
Fundamentals Framework
Use this Manual to build your customized risk management
program
PHASE 3
3.1 3.2
Phase-By-Phase
Deliverables: Monitor, Communicate,
and Respond to IT Risk:
1. Risk Event Action Plan
Primary
PHASE 2
2. Risk Reports* Deliverable:
2.1 2.2 3. IT Risk Recommendations

PHASE 1
Identify and Assess IT
1.1 1.2 Risk:
1. Acceptable Risk Thresholds
Review IT Risk 2. Risk Register*
Fundamentals and 3. Prioritized List of IT Risks
Governance:
Use the tools and activities in each phase
1. Maturity Assessment
to create a comprehensive, customized
2. Stakeholder Map program manual for the ongoing
3. IT Risk Council management of IT risk.
Charter
Benefit from industry-leading best practices

The Government of the

COBIT5’s IT functions were
United Kingdom’s M_o_R RiskIT’s IT Risk Framework
used to develop and refine our
framework provided best was modified to create ’s IT
Nine IT Risk Scenarios used in
practices for IT risk Risk Management Framework.
our top-down risk identification
governance, identification, and
methodology.
assessment.

M_o_R RiskIT COBIT5

PHASE 1
Review IT Risk Fundamentals and
Governance
Phase 1 (Section 1): Review IT Risk Management
Fundamentals

PHASE 1 PHASE 2 PHASE 3

1.1 1.2 2.1 2.2 3.1 3.2

Review IT Risk Establish a Risk Identify IT Risks Assess and Monitor IT Risks Communicate IT
Management Governance Prioritize IT and Develop Risk Risk Priorities
Fundamentals Framework Risks Responses

OUTCOMES:

Reviewed key IT principles

and terminology = Gained understanding of the relationship
between IT risk management and ERM

Introduced to IT Risk Obtained the support of senior leadership

Management Framework
Abandon ad hoc risk management

Drivers of Formalized Risk Management: This section will provide you with a strong risk
management foundation which will be valuable
when building your IT risk management program.

This section covers the following IT risk

fundamentals:
Drivers External to IT  Benefits of formalized risk management
External Audit  Key terms and definitions
Internal Audit
Mandated by ERM  Risk management within ERM

Occurrence of Risk Event  Risk management independent of ERM

Demonstrating IT’s value  Four key principles of IT risk management

to the business Proactive initiative
 Importance of a risk management program
Emerging IT risk awareness manual

 Importance of buy-in and support from the

Grassroots Drivers business
Realize the tangible IT and business benefits of a formal IT
risk management program
Benefits of a Formal Risk Management Benefits of a Formal IT Risk Management
Program for IT: Program for the Business:
1. Increased on-time, in-scope, and on-budget 1. Reduced operational surprises or failures.
completion of IT projects.
2. Improved IT flexibility when responding to risk
2. Meet the business’ service requirements. events and market fluctuations.
3. Improved satisfaction of IT by senior leadership 3. Reduced budget uncertainty.
and business units.
4. Improved ability to make decisions when
4. Fewer resources wasted on fire-fighting. developing long-term strategies.
5. Improved availability, integrity, and 5. Improved stakeholder and shareholder
confidentiality of sensitive data. confidence.
6. More efficient use of resources. 6. Achieved compliance with external regulations.
7. Greater ability to respond to evolving threats. 7. Competitive advantage over organizations with
immature risk management practices.

Increase Risk Management Success by Implementing a Formal Program

Risk Management Success Business Involvement Organizations with a

(%) Organizations with a formal Success (%) formal risk management
81% Formal risk management strategy 88% strategy were
Strategy had approximately 53% 49%
Formal
approximately 80% more
53% Ad-hoc
Strategy
Approach
more risk management Ad-hoc
successful in obtaining
Approach
success than those who involvement from
0% 100% used an ad hoc approach. 0% 100% business stakeholders.
Familiarize yourself with key risk terminology
Review important risk management terms and definitions.
An uncertain event or set of events which, should it occur, will have an effect on the achievement of
Risk objectives. A risk consists of a combination of the probability of a perceived threat or opportunity
occurring and the magnitude of its impact on objectives (M_o_R, 2007).

Threat An event that can create a negative outcome (e.g. hostile cyber/physical attacks, human errors).

A weakness that can be taken advantage of in a system (e.g. weakness in hardware, software, business
Vulnerability processes).

Risk The systematic application of principles, approaches, and processes to the tasks of identifying and
assessing risks, and then planning and implementing risk responses. This provides a disciplined
Management environment for proactive decision-making (M_o_R, 2007).

Distinct from a risk event, a scenario is an abstract profile of risk. It represents a common group of risks.
Risk Category For example, you can group certain types of risks under the risk category of IT Operations Risks.

A specific occurrence of an event that falls under a particular risk category. For example, a phishing
Risk Event attack is a risk event that falls under the risk category of IT Security Risks.

An organization’s attitude towards risk taking, which determines the amount of risk that it considers
Risk Appetite acceptable. Risk appetite also refers to an organization’s willingness to take on certain levels of exposure
to risk, which is influenced by the organization’s capacity to financially bear risk.

(ERM) – A strategic business discipline that supports the achievement of an organization’s objectives by
Enterprise Risk addressing the full spectrum of organizational risks and managing the combined impact of those risks as
Management an interrelated risk portfolio (RIMS 2015)1.
Effective IT risk management is possible with or without ERM
Whether or not your organization has ERM, integrating your IT risk management program with the
business is possible.
Most IT departments find themselves in one of these two organizational frameworks for managing IT risk:

Core Responsibilities With an ERM Without an ERM

• Risk Decision-
Making Authority Senior Leadership Team Senior Leadership Team
• Final
Accountability

• Risk Governance
• Risk Prioritization & ERM
Communication
IT Risk Management
• Risk Identification
• Risk Assessment IT Risk Management
• Risk Monitoring

Pro: IT’s risk management responsibilities are Pro: IT is free to create its own IT risk council
defined (assessment schedules, escalation and develop customized processes that serve
and reporting procedures). its unique needs.
Con: IT may lack autonomy to implement IT Con: Lack of clear reporting procedures and
risk management best practices. mechanisms to share accountability with the
business.
IT risk management framework walks you through each step
to achieve risk readiness
Optimize Risk
IT Risk Management
Engage
Management Framework Stakeholder
Risk Governance Processes Participation
Risk Identification
Communication
Manage Measure the Utilize Risk Compile
Stakeholders Success of Identification IT-Related
the Program Frameworks Risks

Business
Objectives

Establish Establish
Monitoring Thresholds for
Responsibilities Unacceptable
Monitoring Risk

Perform Identify Risk Determine Risk

Calculate
Cost-Benefit Response Severity &
Risk Analysis Actions
Expected Cost
Prioritize IT Risk
Response Risks Assessment
IT risk is business risk

| ISACA’s COBIT 5 Methodology describes the

| =
relationship between IT risk and business risk:
IT Risk is Business Risk “IT risk is business risk, specifically, the business risk
associated with the use, ownership, operation, involvement,
influence, and adoption of IT within an enterprise.
Insight
IT risk consists of IT-related events that could potentially
The central goal of IT risk management is to provide clear impact the business. IT risk can occur with both uncertain
and accurate interpretations of IT risk to the business frequency and impact and creates challenges in meeting
regarding risk implications and response options. Ultimately, strategic goals and objectives.”1
senior leadership is responsible for making decisions
regarding all business risk.

An organization’s success is linked to the effectiveness of business operations and processes. Therefore, IT is an enabler of the
organization’s strategic vision and thus, any risk that adversely affects IT will adversely affect the business.

• For example, downed power lines could mean that critical business apps are offline if the organization has not anticipated
this event and built appropriate contingency plans. This could lead to lost revenue. IT risk relates to almost all aspects of
the business.

Therefore, not having an IT risk management program in place can put a financial strain on the entire organization, not just IT.

1 COBIT5
Understand the four principles of IT risk management
Principles of IT Risk Management Tools and Templates

1 Business alignment
IT risk management must:
(1) reflect business priorities,
(2) be communicated in business terms, and
Risk Report

Risk Event Action Plan

(3) integrate with enterprise risk management.

2 Defined and enforced thresholds for

(un)acceptable risk
IT must work with the business to develop clearly defined
risk thresholds that indicate if a risk requires a response
Risk Register
Tool

action.

3 Cost-benefit analysis
Risk-taking is neither inherently good nor bad. Determining
which risks to accept and which risk responses to invest in
requires a careful calculation of costs and benefits that must
Risk Costing
Tool
reflect the goals and risk appetite of the organization.

4 Ongoing
Risk management is a program, not a project – there is no
completion date. The IT threat landscape will not wait for you
to catch up, so constant monitoring, identification, and
assessment is necessary for you to avoid falling behind.
Build a program manual as the cornerstone of your risk
management program
Risk Management Program Manual
Use Risk Management Program Manual to document and communicate how IT risks are managed
within your IT department.

Follow the steps to create your Risk Management

Program Manual. This manual will house critical
documents and outline all of the major activities of
IT Risk Council Members the risk management process. From risk
identification to issue-tracking and escalation –
Meeting and Activity Schedules create repeatable, iterative processes and
document them in this central location. Use this
Acceptable Risk Thresholds document to:
• Standardize risk management processes.
Risk Identification Methodologies • Communicate processes, timelines, and results
to the central risk function or senior leadership.
Risk Event Action Plans
• Enhance risk-awareness in IT.
Key Risk Indicators and • Train new hires in IT.
Escalation Protocols • Capture new knowledge from annual risk
assessments.
Risk Reports
Create a central risk folder to store all documents related to risk management

Consolidating all IT risk-related documentation from multiple risk owners will make it easier to
manage risks year after year.

Build a central repository for risk-related documentation.

Use the folder to store:

1 The Risk Management Program Manual

2 Risk Event Action Plans for each risk event This central risk file should only be
accessible by the IT risk council. This
ensures governance around risk
3 Annual or bi-annual Risk Reports management and ensures that other
individuals are not bypassing the IT risk
council to add risks to the risk register
4 The Risk Register or request funding from senior
stakeholders to mitigate a risk.

5 The Risk Costing Tool

Phase 1 (Section 2): Establish a Risk Governance Framework
PHASE 1 PHASE 2 PHASE 3

1.1 1.2 2.1 2.2 3.1 3.2

Review IT Risk Establish a Risk Identify IT Risks Assess and Monitor IT Risks Communicate IT
Management Governance Prioritize IT and Develop Risk Risk Priorities
Fundamentals Framework Risks Responses

ACTIVITIES: OUTCOMES:

1.2.1 Assess current program maturity

Developed goals for the risk
1.2.2 Identify obstacles and pain points management program
1.2.3 Determine the risk culture of the
organization
1.2.4 Develop risk management goals Established the IT risk council
1.2.5 Develop SMART Project Metrics
1.2.6 Create a stakeholder map
1.2.7 Create the IT risk council A Assigned accountability and
R C responsibility for risk management
1.2.8 Complete a RACI chart I processes
Create an IT risk governance framework that integrates with the business

Why Ad hoc risk management fails:

• Key stakeholders are left out or consulted once risks have
already occurred.
Risk Governance • Failure to employ consistent risk identification methodologies
Optimize results in omitted and unknown risks.
Processes • Risk assessments do not reflect organizational priorities and
may not align with thresholds for acceptable risk.
Manage Measure the • Risk assessment occurs sporadically or only after a major risk
Stakeholders & Success of event has already occurred.
Assign the Program
Accountability In this section:
1. Self-assess your current approach to IT risk management.

Key metrics: 2. Identify organizational obstacles and set attainable risk

management goals.
• Number of risk management processes done “ad hoc”.
• Frequency that IT risk appears as an agenda item at IT 3. Track the effectiveness and success of the program using
steering committee meetings. SMART risk management metrics.
• Percentage of IT employees whose performance 4. Establish an IT risk council tasked with managing IT risk.
evaluations reflect risk management objectives. 5. Set clear risk management accountabilities and responsibilities
• Percentage of IT risk council members who are trained for IT and business stakeholders.
in risk management activities.
• Number of open positions in the IT risk council.
• Cost of risk management program operations per year.
 Self-assess your current approach to risk management Optimize
Processes

Assess current risk management maturity

Understanding your current level of risk management maturity will help you begin to
build your program and identify key business stakeholders. Assess the following risk
management processes:

A Governance D Monitoring & Reporting 3. The Risk Management Program Manual provides
B Identification E Response Development sample current process practices that describe an
optimized maturity level for each process (i.e.
C Assessment
process best practices). Use these sample
practices if they reflect your own, or revise them to
describe your current state.
Instructions:

1. Use maturity models on the next three slides to assess

your maturity for all five processes. Compare your current
practices to the definitions of ad hoc, defined, and optimized
provided for each of the five processes and determine which
label best describes your current practices.
2. Document the maturity level for each of the five processes in
section 2.2 of the Risk Management Program Manual.

Risk Governance describes the development of mature risk

management processes and institutions within the organization
that encourage the formalization of risk management.
Match the characteristics of your existing risk management processes to the table
below (1 of 3)
Process Key Responsibilities Ad Hoc Defined Optimized
Risk • Convene regular • IT risk is discussed • A dedicated committee or • A dedicated committee or council
Governance discussions on IT risk. informally within existing council exists to consider exists to consider and evaluate IT
• Inform business and IT committees, if at all. and evaluate IT risk. risk.
stakeholders on IT risk. • Discussions on IT risk • The council meets • The council meets regularly.
• Allocate responsibility occur on a need-to-know regularly. • Risk events are owned and
and accountability for IT basis. • Risk events are owned monitored by specific members of
risk appropriately. • Uncertainty exists as to and monitored by specific the risk council.
• Make informed risk who is responsible for members of the risk • Business stakeholders participate
decisions. managing IT risk. council. in council meetings and are
• Risk accountability is • Business stakeholders always consulted.
loosely defined. are informed about IT risk • Senior leadership signs off on all
• Risk decisions are and are frequently action plans for non-negligible IT
generally made by consulted. risk.
specific individuals within • Senior leadership is • Accountability for executing the
IT with little or no informed of key IT risks; risk management program is held
consultation from however, accountability is by the CIO.
business stakeholders. loosely shared between • Accountability for IT risk decisions
the CIO and CEO. is held by the CEO.
Risk • Gather and engage • IT is aware of most major • IT possesses a risk • IT possesses a risk register that is
Identification stakeholders impacted risks, particularly risks register that is updated updated to reflect IT’s overall risk
by, and knowledgeable pertaining to security, periodically to reflect IT’s portfolio.
about, IT risk. compliance, and overall risk portfolio. • Risk identification exercises are
• Compile all IT-related hardware. • Risk identification conducted bi-annually or quarterly.
risks. • No formal list or register exercises are conducted • The IT risk register is developed
• Leverage alternative is maintained and annually. and updated collaboratively with
risk identification updated. • The IT risk register is sent key business stakeholders.
frameworks to ensure • Risk awareness relies on to key business • Risk events are brainstormed
comprehensive risk champions advocating stakeholders for review. using high-level IT risk categories
capture. the importance of a • Risk events are and then refined using COBIT 5 IT
particular risk event. brainstormed using high- processes.
level IT risk categories.
(Continued) Match the characteristics of your existing risk management processes
to the table below (2 of 3)
Process Key Responsibilities Ad Hoc Defined Optimized
Risk • Gather and engage • IT assesses and • Formal risk assessment • Formal risk assessment exercises
Assessment stakeholders impacted prioritizes risks exercises are conducted are conducted bi-annually or
by and knowledgeable independently of the annually. quarterly.
about IT risk. business. • (Un)acceptable risk • (Un)acceptable risk thresholds are
• Create thresholds that • Risks are assessed and thresholds are approved dictated by senior leadership.
reflect the organization’s prioritized according to a by senior leadership. • All identified risk events are
appetite/tolerance for IT “gut-feeling.” • All identified risk events assigned a severity level based on
risk. • IT uses its own budget are assigned a severity probability of occurrence and
• IT risks are assessed for limitations as a guide to level based on financial impact.
probability of occurrence what constitutes an probability of occurrence • Top risks are reassessed for
and financial impact. acceptable and and financial impact. actual expected cost.
• IT risks are prioritized unacceptable risk. • IT has completed risk • Key business stakeholders
according to their • IT risk severity is typically assessments for participate in risk assessment
severity. expressed qualitatively. business stakeholder exercises.
• The CIO prioritizes IT review. • Alternative risk assessment
risks according to their methodologies are employed to
personal perception of create actual expected cost
organizational priorities. values.
Risk • Monitor risk events • Top risk events are • Risk owners are • Risk owners are assigned to
Monitoring & continuously. loosely tracked by assigned to monitor monitor specific risk events.
Reporting • Report changes in risk relevant IT units. specific risk events. • KRIs and thresholds are
severity to the IT risk • Risk ownership is shared • KRIs and thresholds developed to track changes in risk
council and key between personnel and track changes in risk severity.
stakeholders. specific responsibilities severity. • Protocols have been established to
• Assign ownership for are not assigned. • Protocols have been escalate risks when thresholds
risk monitoring • Expectations exist to established to escalate have been breached.
responsibilities. report changes in risk risks when thresholds • Risks are reported according to an
• Develop metrics to track severity. have been breached. enforced reporting schedule.
changes in risk severity. • Risks are reported • KRIs, thresholds, and reporting
• Establish thresholds and according to an enforced schedules have been approved by
escalation protocols. reporting schedule. senior leadership.
(Continued) Match the characteristics of your existing risk management processes
to the table below (3 of 3)
Process Key Responsibilities Ad Hoc Defined Optimized
Risk • Identify risk response • Response options are • Response options are • Response options are
Response options for risk events brainstormed by the brainstormed for all risks brainstormed for all risks
Development exceeding the individual(s) dealing most exceeding thresholds for exceeding thresholds for
organization’s directly with the specific acceptable risk. acceptable risk.
thresholds for risk event. • Each risk event is • Each risk event is reassessed for
acceptable risk. • Responses are not reassessed for residual residual risk.
• Assess the formally assessed. risk. • Residual expected cost values are
effectiveness of several • The best response is • Responses are selected determined for high-priority risks.
risk response options recommended to the CIO based on cost-benefit • Costs and benefits for each
for severe risks. for approval. analysis and IT’s response are analyzed over
• Conduct cost-benefit • Responses that exceed IT capabilities to implement multiple years.
analysis and select risk budget flexibility are the projects. • Responses are selected based on
response(s). proposed informally to the • All risk response cost-benefit analysis and IT’s
senior leadership team. recommendations are capabilities to implement the
presented formally to the projects.
senior leadership team • All risk response
for approval. recommendations are presented
formally to the senior leadership
team for approval.
Anticipate challenges to formalizing IT risk management

Identify obstacles and pain points

Anticipate potential challenges and “blind-spots” by determining which of these success factors
are missing from your current situation.
IT Risk Management Success Factors
Support and sponsorship from senior leadership Risk culture and awareness
• IT risk management has more success when • A risk-aware organizational culture embraces new policies
initiated by a member of the senior leadership and processes that reflect a proactive approach to risk.
team or the board, rather than emerging from IT
• An organization with a risk-aware culture is better equipped
as a grassroots initiative. to facilitate communication vertically within the organization.
• Sponsorship increases the likelihood that risk • Risk-awareness can be embedded by revising job
management is prioritized and receives the descriptions and performance assessments to reflect IT risk
necessary resources and attention. It also
management responsibilities.
ensures that IT risk accountability is assumed by
senior leadership.
Organization size
• Smaller organizations can often institute a mature risk management Instructions:
program much more quickly than larger organizations. List the potential obstacles and
• It is common for key personnel within smaller organizations to be missing success factors that you
responsible for multiple roles associated with risk management, making must overcome to effectively manage
it easier to integrate IT and business risk management. IT risk and build a risk management
program. Use this list in Activity 1.2.4
• Larger organizations may find it more difficult to integrate a more to develop program goals.
complex and dispersed network of individuals responsible for various
risk management responsibilities.
Determine the risk culture of your organization

Determine the risk culture of the organization

Determine how your organization fits the criteria listed below. Descriptions and examples do not
have to match your organization perfectly.

Risk Tolerant Moderate Risk Averse

• You have no compliance • You have some compliance • You have multiple, strict
requirements. requirements, e.g.: compliance and/or regulatory
• You have no sensitive data. o HIPAA requirements.
• Customers do not expect you to o PIPEDA • You house sensitive data, such as
have strong security controls. • You have sensitive data, and are medical records.
• Revenue generation and required to retain records. • Customers expect your
innovative products take priority • Customers expect strong security organization to maintain strong
and risk is acceptable. controls. and current security controls.
• The organization does not have • Information security is visible to • Information security is highly
remote locations. senior leadership. visible to senior management and
• It is likely that your organization • The organization has some remote public investors.
does not operate within the locations. • The organization has multiple
following industries: • Your organization most likely remote locations.
o Finance operates within the following • Your organization operates within
o Health care industries: the following industries:
o Telecom o Government o Finance
o Government o Research o Healthcare
o Research o Education o Telecom
o Education
Be aware of the organization’s attitude towards risk
Risk culture is an organization’s attitude towards taking risks. This attitude manifests itself in two
ways:
One element of risk culture is what levels of risk the organization is willing to accept in order to pursue its objectives, and what
levels of risk are deemed unacceptable. This is often called risk appetite.

Risk-tolerant Risk-averse

Risk-tolerant organizations embrace the potential of Risk-averse organizations prefer consistent, gradual
accelerating growth and the attainment of business growth and goal-attainment by embracing a more
objectives by taking calculated risks. cautious stance towards risk.

The other component of risk culture is the degree to which risk factors into decision-making.

Risk-conscious Unaware
Risk-conscious organizations place a high priority on Organizations that are largely unaware of the impact
being aware of all risks impacting business of risk generally believe there are few major risks
objectives, regardless of whether they choose to impacting business objectives and choose to invest
accept or respond to those risks. resources elsewhere.

Insight

Organizations typically fall in the middle of these spectrums. While risk culture will vary depending on the industry and
maturity of the organization, an organizational culture with a balanced risk appetite that is extremely risk conscious is
able to make creative, dynamic decisions with reasonable limits placed on risk-related decision-making.
Develop goals for the IT risk management program

Develop risk management goals

Translate your maturity assessment and knowledge about organizational risk culture, potential
obstacles, and success factors to develop goals for your IT risk management program.

Maturity assessment

Instructions:

1. In the Risk Management

Program Manual, revise, Risk culture
replace, or add to the high-level
goals provided.
2. Make sure that you have 3–5
high-level goals that reflect the
current and targeted maturity of
IT risk management processes.
3. Integrate potential obstacles,
pain points, and insights from
the organization’s risk culture.
Attach metrics to your goals to gauge the success of the
IT risk management program
Measure the
Develop SMART project metrics Success of
the Program

Create metrics for measuring success of the IT risk management program.

Instructions: Ensure that all success metrics are SMART

1. Document a list of appropriate metrics to
assess the success of the IT risk
management program on a whiteboard.
2. Use the sample metrics listed in the table
S pecific
Make sure the objective is clear and detailed.

on the next slide as a starting point.

Objectives are measurable if there are specific metrics
3. Fill in the chart to indicate the:
a) Name of the success metric.
b) Method for measuring success.
M easurable
assigned to measure success. Metrics should be
objective.

c) Baseline measurement.
d) Target measurement.
e) Actual measurements at various
A ctionable
Objectives become actionable when specific initiatives
designed to achieve the objective are identified.

points throughout the process of

improving the risk management
program.
f) A deadline for each metric to meet
R ealistic
Objectives must be achievable given your current
resources or known available resources.

the target measurement.

T ime-Bound
An objective without a timeline can be put off indefinitely.
Create a strict time frame for measuring success.
Identify stakeholders and map them according to their influence over, and interest
in, IT risk management
Manage
Create a stakeholder map Stakeholders

Instructions:
Relevant stakeholders can
1. Develop a list of stakeholders.
include individuals, groups, or
entire business units. Meet their Key • A stakeholder is anyone affected by a

Influence of stakeholders
decision and interested in its outcome
needs stakeholder (M_o_R, 2007).

2. Draw the 2x2 stakeholder map on a

Stakeholder List whiteboard and chart each stakeholder in
the appropriate quadrant.
CIO IT RMSC
3. Take a picture of the whiteboard so you
can reference the map when you create
CRO IT
Least Consider the IT risk council (Activity 1.2.7) and build
the RACI chart (Activity 1.2.8).
CFO ERM important their input
CEO Service Desk

Vendor
ITSC Management
Office Interest of stakeholders

Human Occasionally, groups or individuals outside of IT that have low interest in IT

Solution Architect risk management should be highly interested, but are unaware of the impact
Resources
that IT risk has on their objectives. Use tactics outlined in section 1.1 to bring
Sales Finance them on board. For the sake of this exercise, map stakeholders according to
how interested they should be.

Stakeholder Map from Eden and Ackerman, p. 121–125, 344–346

Assign risk management accountabilities and responsibilities to key stakeholders

Complete RACI chart

RACI diagrams are an effective way to describe how

accountability and responsibility for particular roles,
projects, and project tasks are distributed amongst
stakeholders involved in IT risk management.

A RACI diagram is a useful visualization that identifies

redundancies, and ensures that every role, project, or task
has an accountable party.

RACI is an acronym made up of four participatory roles: Instructions:

1. Use the template provided on the following slide, and
add key stakeholders identified in Activity 1.2.6 that do
Responsible Stakeholders who undertake the activity. not appear.

Accountable Stakeholders who are held responsible for 2. For each activity, assign each stakeholder a letter.
failure or take credit for success. 3. There must be an accountable party for each
Consulted activity (every activity must have an “A”).
Stakeholders whose opinions are sought.
4. For activities that do not apply to a particular
Informed Stakeholders who receive updates. stakeholder, leave the space blank.
5. Once the chart is complete, copy/paste it into section
4.1 of the Risk Management Program Manual.
(Continued): Assign risk management accountabilities and responsibilities to key
stakeholders
Complete RACI chart

Customize the RACI Chart by adding or subtracting rows.

Risk
Stakeholder Risk Risk Risk Identify Cost-Benefit
Monitoring Decision-
Coordination Identification Thresholds Assessment Responses Analysis
Making

ITRC A R I R R R A C
ERM C I C I I I I C
CIO I A A A A A I R
CRO I R C I R
CFO I R C I R
CEO I R C I A
Business
Units I C C C
IT I I I I I I R C
PMO C C C

Legend: Responsible Accountable Consulted Informed

Phase 1 Outcomes

PHASE 3
Risk Risk
Governance Identification Monitor, Communicate, and
Respond to IT Risk

Risk
Response
Risk
Assessment
3.1 3.2
Monitor IT Risks Communicate
and Develop Risk IT Risk
Responses Priorities
PHASE 1 PHASE 2
Identify and Assess IT Risk
Review IT Risk Fundamentals
and Governance
2.1 2.2
1.1 1.2 Identify IT Assess and
Risks Prioritize IT Risks

✓ 1. Maturity Assessment

✓ 2. Stakeholder Map

✓ 3. IT Risk Council Charter

PHASE 2
Identify and Assess IT Risk
Phase 2 (Section 1): Identify IT Risks
PHASE 1 PHASE 2 PHASE 3

1.1 1.2 2.1 2.2 3.1 3.2

Review IT Risk Establish a Risk Identify IT Assess and Monitor IT Risks Communicate IT
Management Governance Risks Prioritize IT and Develop Risk Risk Priorities
Fundamentals Framework Risks Responses

ACTIVITIES: OUTCOMES:

2.1.1 Engage key stakeholders

2.1.2 Add organization-specific risk
scenarios Participation of key stakeholders
2.1.3 Identify risk events
2.1.4 Augment risk event list using
COBIT 5 processes
Comprehensive list of IT risk events
2.1.5 Conduct a PEST analysis
2.1.6 Input risks into the Risk Register Tool
Get to know what you don’t know

What you don’t know CAN hurt you.

In this section:
1. Engage the right stakeholders in risk identification.
Risk Identification Engage By encouraging the participation of relevant business units
Stakeholder and senior leadership in risk identification exercises, you
Participation significantly decrease the chances of omitting a key risk.
2. Employ top-down approach to risk identification.
Utilize Risk The nine risk categories introduced in this section serve as
Compile
Identification IT-Related
useful signposts to guide brainstorming activities and
Frameworks Risks organize risks according to IT’s core functions.
3. Augment your risk event list using alternative
frameworks.
Be confident that no risk is able to slip through the cracks
Key metrics: by evaluating your risk portfolio with all of the COBIT 5 IT
• Total risks identified processes.
• New risks identified
• Frequency of updates to the Risk Register Tool
• Number of realized risk events not identified in the Insight
Risk Register Tool
• Level of business participation in enterprise IT risk What you don’t know CAN hurt you. How do you identify IT-
identification related threats and vulnerabilities that you are not already
o Number of business units represented aware of? Now that you have created a strong risk governance
o Number of meetings attended in person framework that formalizes risk management within IT and
o Number of Risk Reports received connects it to the enterprise, follow the steps outlined in this
section to reveal all of IT’s risks.
Ensure that all key risks are identified by engaging key business stakeholders Engage
Stakeholder
Participation

Instructions:
1. Reach out to key business stakeholders identified in exercise 1.2.6
Organizations that were able to
to participate in risk identification exercises.
engage the business in risk
2. If they are unable to attend, request that they review your
79% identification were 79% more
completed risk register and provide feedback. successful in identifying all
3. Document participants in section 5.1 of the Risk Management risks than organizations where
Program Manual. business participation was
minimal.

Respondents who were successful in

100% 79%
Benefits of obtaining business involvement during the
90% 86%
risk identification stage:

identifying risk (%)

80%
You will identify risk events that you had not considered or that 70%
you weren’t aware of.
60%
◦ The business can offer perspectives on risks that IT may have 48%
No Bus.
Involvement
overlooked. 50%
Business
You will identify risks more accurately. 40% Involvement
◦ The business can reinforce IT’s knowledge about particular 30%
risks, and their overall impact on the organization.
20%
Risk identification is an opportunity to raise awareness of IT
risk management early in the process. 10%
◦ IT will raise its credibility by actively addressing the business’ 0%
concern about risk. Survey: Research Group, N = 76
(Continued) Ensure that all key risks are identified by
engaging key business stakeholders
Engage key stakeholders

Alternative Perspectives Insight

All business units rely on the services and technologies that IT Obtaining business involvement when identifying
provides. They likely possess alternative perspectives on: risk is important because it is often a pre-cursor to
future business involvement during the risk
assessment and risk response phases.
1. The value that IT provides to the business.
2. The corresponding business risk associated with the
inability of IT to support business activities. Executive Participation

CIO participation is integral when building a

Prioritizing and Selecting Stakeholders comprehensive register of risk events impacting IT.
CIOs and IT Directors possess a holistic view of all
Obtaining the participation of every business unit may be a challenge. of IT’s functions, and are uniquely placed to identify
Prioritize stakeholders from the business using the following criteria: how IT affects other business units and the
attainment of business objectives. If applicable,
1. Reliance on IT services and technologies to achieve CRO and CTO participation is also critical.
business objectives.
2. Relationship with IT, and willingness to engage in risk Insight
management activities.
While IT personnel are better equipped to identify
3. Unique perspectives, skills, and experiences that IT may
IT risk than anyone, IT does not always have an
not possess.
accurate view of the business’ exposure to IT risk.
Strive to maintain a 3 to 1 ratio of IT to non-IT
personnel involved in the process.
Top-down risk identification enables IT to target risk holistically using ’s nine risk
categories
Compile
Take a top-down approach to risk identification to guide brainstorming. IT-Related
Risks

’s risk categories are consistent with a risk identification method called Risk Prompting.

A risk prompt list is a list that categorizes risks into types or areas. The nine risk categories encapsulate the services,
activities, responsibilities, and functions of most IT departments. Use these categories and the example risk scenarios
provided as prompts to guide brainstorming and organize risks. Risk Event: Specific threats and vulnerabilities that
fall under a particular risk scenario. Organizations
Risk Scenario: An abstract profile representing are able to identify anywhere between 1 and 20
common risk groups that are more specific than events for each scenario. See the Appendix of the
risk categories. Typically, organizations are able Risk Management Program Manual for a list of risk
to identify 2–5 scenarios for each category. event examples.

Risk Category Risk Scenario Risk Event

Risk Category:
High-level groupings Data Integrity Data recovery/loss within system
that describe risk Data Risk
pertaining to major Data Theft Loss of data due to stolen/lost device
IT functions. See the
following slide for all IT Staffing High turnover in key roles
nine of ’s IT risk Personnel Risk
categories.
IT Skills & Experience Poorly defined roles and responsibilities

Vendor performance requirements are

Vendor Management
improperly defined
Vendor Risk
Vendors are improperly selected to meet the
Vendor Selection
defined use case
Add risk scenarios to the examples provided under each risk category

Add organization-specific risk scenarios

Review nine risk categories and add risk scenarios to the examples provided.
Operations Risks

• Hardware implementation errors

Software Risks
Hardware Risks
• Enterprise architecture • Software implementation errors
• Hardware configuration errors • Software configuration
• Technology evaluation &
• Hardware maintenance errors • Software maintenance
selection
• Hardware performance • Software performance
• Capacity planning
• Theft • Software obsolescence
• Operational errors
• Damage/destruction
• Hardware obsolescence

Personnel Risks
Project Risks

Data Risks
• Project scoping • Data theft
• Project quality • IT staffing • Data integrity
• Project time over-runs • IT skills and experience • Data confidentiality
• Project cost over-runs • Data availability
Disaster & Business
Continuity Risks

Security Risks
Compliance &
Vendor Risks

• Regulatory compliance
• Vendor selection • Acts of nature (hurricane, etc.)
• Malware
• Vendor management • Utility performance
• Externally originated attack
• Contract termination • Industrial action
• Internally originated attack
• System failure
 Identify risk events

Identify risk events

Use risk categories and scenarios to brainstorm a comprehensive list of IT-related threats and
vulnerabilities impacting your organization.
Instructions: Facilitator Tips
1. Prepare a large space on a whiteboard to document risk
events. Tip: Assign an individual from the ITRC
to take a photo of the whiteboard and
2. List risk scenarios (organized by risk category) across the top then collect, organize, and store the
of the whiteboard. sticky notes in a safe place until the risk
3. While the brainstorming process should be informal, assign is finalized and inputted into the Risk
Register Tool.
one individual to guide the session and encourage equal
participation from all participants to avoid having the exercise
dominated by a few voices. Tip: If disagreement arises regarding
whether a specific risk event is relevant
4. Attack one scenario at a time, exhausting all realistic risk to the organization or not and it cannot
events for that grouping before moving onto the next scenario. be resolved quickly, include it in the list.
Each scenario should take approximately 45–60 minutes. The applicability of these risks will
become apparent during the
Operations Project Vendor Personnel Hardware Software …
assessment process.

Whiteboard
 (Optional) Augment the risk event list using
alternative processes
Utilize Risk
Augment the risk event list using COBIT 5 processes Identification
Frameworks

Other industry-leading frameworks provide alternative ways of conceptualizing the

functions and responsibilities of IT, and may help you uncover additional risk events.

1. Manage the IT Management Framework 22. Manage Assets

Instructions: 2. Manage Strategy 23. Manage Configuration
3. Manage Enterprise Architecture 24. Manage Operations
1. Review COBIT 5’s 37 IT 4. Manage Innovation 25. Manage Service Requests and Incidents
processes and identify 5. Manage Portfolio 26. Manage Problems
6. Manage Budget and Costs 27. Manage Continuity
additional risk events.
7. Manage Human Resources 28. Manage Security Services
2. Match risk events to the
8. Manage Relationships 29. Manage Business Process Controls
corresponding risk category 9. Manage Service Agreements 30. Monitor, Evaluate, and Assess
and scenario and add them to 10. Manage Suppliers Performance and Conformance
the whiteboard. 11. Manage Quality 31. Monitor, Evaluate, and Assess the System
12. Manage Risk of Internal Control
13. Manage Security 32. Monitor, Evaluate, and Assess
14. Manage Programs and Projects Compliance With External Requirements
15. Manage Requirements Definition 33. Ensure Governance Framework Setting
16. Manage Solutions Identification and Build and Maintenance
17. Manage Availability and Capacity 34. Ensure Benefits Delivery
18. Manage Organizational Change 35. Ensure Risk Optimization
Source: Enablement 36. Resource Optimization
Cobitonline
19. Manage Changes 37. Stakeholder Transparency
20. Manage Change Acceptance and
Transitioning
21. Manage Knowledge
(Optional) Finalize your risk register by conducting a PEST analysis

Conduct a PEST Analysis

Explore alternative identification techniques to incorporate external factors and avoid “groupthink.”

Note: Employing either of these techniques will lengthen an already time-consuming process. Only consider these
techniques if you have concerns regarding the homogeneity of the ideas being generated, or if select individuals are
dominating the exercise.

Consider the External Environment Avoid “Groupthink”

PEST Analysis Nominal Group Technique
Despite efforts to encourage equal participation in the The Nominal Group Technique uses the silent
risk identification process, key risks may not have been generation of ideas, and an enforced “safe” period of
shared in previous exercises. time where ideas are shared but not discussed to
encourage judgement-free idea generation.
Conduct a PEST analysis as a final safety net to ensure
that all key risk events have been identified. • Ideas are generated silently and independently.
List the following factors • Ideas are then shared and documented –
Environmental however, discussion is delayed until all of the
influencing the risk event:
group’s ideas have been recorded.
• Political factors
• Economic factors
P E • Idea generation can occur before the meeting and
• Social factors be kept anonymous.
• Technological factors S T
• Environmental factors
Input risk events into the Risk Register Tool

Input risks into the Risk Register Tool

The finalized risk event list must be inputted into the Risk Register Tool to prepare for risk
assessment.
Instructions:
1. Transcribe the risk event list from the whiteboard into the Risk Register Tool.
2. Disseminate the list to key stakeholders who were unable to participate and solicit their feedback.
• Consult the RACI chart located in section 4.1 of the Risk Management Program Manual.
3. Incorporate feedback and finalize the risk event list.
4. Select an individual from the ITRC to copy a finalized risk event list into the Risk Register Tool.
Phase 2 (Section 2): Assess and Prioritize IT Risks
PHASE 1 PHASE 2 PHASE 3

1.1 1.2 2.1 2.2 3.1 3.2

Review IT Risk Establish a Risk Identify IT Risks Assess and Monitor IT Risks Communicate IT
Management Governance Prioritize IT and Develop Risk Risk Priorities
Fundamentals Framework Risks Responses

ACTIVITIES: OUTCOMES:
2.2.1 Determine the threshold for
(un)acceptable risk X Business-approved thresholds for
unacceptable risk
2.2.2 Create a financial impact assessment ✓
scale
2.2.3 Select a technique to measure
reputational cost Completed Risk Register Tool with
risks prioritized according to severity
2.2.4 Create a probability scale
2.2.5 Risk severity level assessment
2.2.6 Document the proximity of the risk
event $ Expected cost calculations for high-
priority risks

2.2.7 Expected cost assessment

Carefully assess the severity of each risk event to reveal the organization’s greatest
IT threats and vulnerabilities
In this section:
Follow the steps to assess and prioritize IT risks.
1. Establish business-approved risk thresholds for acceptable
Establish and unacceptable risk.
Risk Assessment
Thresholds for 2. Conduct a streamlined assessment of all risks to separate
Unacceptable
acceptable and unacceptable risks.
Risk
3. Perform a deeper, cost-based assessment of prioritized
Determine Risk risks.
Calculate Severity &
Expected Cost Prioritize IT
Risks
Insight

Risk is money. It’s impossible to make intelligent decisions

Key metrics: about risks without knowing what their financial impact will be.

• Frequency of IT risk assessments • Assessment rigour

o (Annually, bi-annually, etc.) o Percentage of identified risk events that undergo
• Assessment accuracy first-level assessment (severity scores)
o Percentage of risk assessments that are o Percentage of identified risk events that undergo
substantiated by later occurrences or testing second-level assessment (expected cost)
o Ratio of cumulative actual costs to expected costs • Stakeholder oversight and participation
• Assessment consistency o Level of executive participation in IT risk
o Percentage of risk assessments that are assessment (attend in person, receive report, etc.)
substantiated by third-party audit o Number of business stakeholder reviews per risk
assessment
Review risk assessment fundamentals
Risk assessment provides you with the raw materials to conduct an informed cost-benefit analysis
and make robust risk response decisions.

In this section, you will be prioritizing your IT risks according to their risk severity, which is a reflection of
their expected cost.

Calculating risk severity Which must be evaluated

Produces a dollar value against thresholds for
How much you expect a risk Calibrated by how likely acceptable risk and the cost
or “severity level” for
event to cost if it were to occur: the risk is to occur: of risk responses.
comparing risks:
Risk Tolerance
Probability
Probable Risk
Impact X of = Severity
Risk Response
Occurrence
e.g. $250,000 or “High” e.g. 10% or “Low” e.g. $25,000 or “Medium”
CBA
Cost-benefit analysis
Maintain the engagement of key stakeholders in the risk assessment process

Encourage the continued participation of business stakeholders to dramatically increase the

success of risk assessment.

100% 97% 97% An survey found that only 40% of IT

departments that assessed risks without
Respondents who were successful in assessing

90% business involvement perceived their risk

assessment to be successful, while 97% of
80% organizations that involved business
70% stakeholders reported success.

60%
risk (%)

50% Where business participation pays off most:

40%
40% Senior management participation when establishing
thresholds for acceptable/unacceptable risk is essential.
30%
This ensures that unacceptable IT risks – as defined by
20% the business – are being communicated to the senior
leadership team, and appropriate risk responses are taken.
10%

0% Involve members of the senior leadership team such as the

CIO, CRO, CFO, and CEO in the threshold setting
No Bus. Involvement Business Involvement
exercise.
Survey: Research Group, N = 76
(Continued) Maintain the engagement of key stakeholders in the risk assessment
process
1. Don’t expect the business to 2. Verify risk impact and 3. Take note of the business’
participate in risk assessments, likelihood assessments. interests and where the
but use them as the final piece business stakeholders focus
to the assessment puzzle. their attention.
If IT has ranked risk events
Asking business stakeholders to appropriately, the business will While verifying, pay attention to
make significant contributions to be more likely to offer their input. the risk events that the business
the assessment exercise may be Share impact and likelihood stresses as key risks. Keep these
unrealistic (particularly for values for key risks to see if they risks in mind when prioritizing risk
members of the senior agree with the calculated risk responses as they are more likely
leadership team, other than the severity scores. to receive funding.
CIO).
Try to communicate the
Ensure that they work with you to assessments of these risk events
finalize thresholds for acceptable Finally, if the business won’t in terms of expected cost to attract
and/or unacceptable risk. provide their time... the attention of business leaders.

Explain that IT has done its job in informing the business about the relevant risks that the organization is exposed to.
Communicating your risk assessments emphasizes IT’s responsibility to protect corporate assets, but warning the
business shows IT’s proactive due diligence.

If business executives still won’t provide the necessary information to update your initial risk assessments,
IT should approach business unit leaders and lower-level management. Lean on strong relationships
forged over time between IT and business managers or supervisors to obtain any additional information.
recommends a 2-level approach to risk assessment
Review the two levels of risk assessment offered in this blueprint.

Risk severity level assessment (mandatory)

Information Assess Probability Assess Impact Output

Number of risks: Risk Severity Level:

1
Negligible Negligible
Assess all risk events
Moderate
identified in Phase 1. Low Low
Units of measurement:
Use customized probability Moderate X Moderate =
and impact “levels.”
High High
Time required: 1–5 Chart risk events according to
minutes per risk event. risk severity as this allows you to
Very High Very High
organize and prioritize IT risks.

Assess all of your identified risk events with a risk severity-level assessment.

• By creating a probability and impact assessment scale divided into 3–9 “levels” (sometimes referred to as “buckets”),
you can evaluate every risk event quickly, while being confident that risks are being assessed accurately.

• In the following activities, you will create probability and impact scales that align with your organizational risk appetite
and tolerance.

• Severity-level assessment is a “first pass” of your risk list, revealing your organization’s most severe IT risks, which
can be assessed in greater detail by incorporating expected cost into your evaluation.
(Continued) recommends a 2-level approach to risk assessment

Expected cost assessment (optional)

$ Information Assess Probability Assess Impact Output
Number of risks:
Expected Cost:

2
Only assess high-priority
risks revealed by severity-level
assessment. 15% X $100,000 = $15,000
Units of measurement: Expected cost is useful for
Use actual probability values conducting cost-benefit analysis
(%) and impact costs ($). and comparing IT risks to non-IT
Medium High risks and other budget priorities
Time required: 10–20 minutes
per risk event. for the business.

Conduct expected cost assessments for IT’s greatest risks.

For risk events warranting further analysis, translate risk severity levels into hard expected-cost numbers.
Why conduct expected cost assessments? Why is expected cost
assessment optional?
• Expected cost represents how much you would expect to pay in
an average year for each risk event. • Determining robust probability values and
• Communicate risk priorities to the business in language they can precise impact estimates can be
understand. challenging and time-consuming.
• While risk severity levels are useful for comparing one IT risk to • Some risk events may require extensive
another, expected cost data allows the business to compare IT data-gathering and industry analysis.
risks to non-IT risks that may not use the same scales.
Use ’s Risk Register Tool to assess and prioritize IT risk
events
Risk Register Tool

Use this tool to: In the following activities, you will:

1. Collect and maintain a repository for all IT risk 1. Develop risk thresholds approved by the business.
events impacting the organization and relevant
2. Create scales for probability and impact.
information for each risk.
• Capture all relevant IT risk information in one 3. Assess the probability and impact for all identified
location. risk events.
• Organize risk identification and assessment 4. Prioritize risk events according to risk severity.
information for transparent risk management,
stakeholder review, and/or internal audit.
2. Calculate risk severity scores to prioritize risk
events and determine which risks require a risk
response.
• Separate acceptable and unacceptable risks (as
determined by the business).
• Rank risks based on severity levels.
3. Assess risk responses and calculate residual risk.
• Evaluate the effect that proposed risk response
actions will have on top risk events and quantify
residual risk magnitude.
• This step will be completed in section 3.1.
Risk Register Tool
Identify a threshold for (un)acceptable risk Establish
Thresholds for
Unacceptable
Risk

Determine the threshold for (un)acceptable risk

If possible, complete this activity with the participation of the senior management team. If this is not
possible, complete the exercise independently, and have the senior management team finalize and
approve the threshold before carrying out the risk assessment.

Instructions:
Unacceptable
There are times when the business needs to know about IT risks with
high expected costs.
$100,000
Create an expected cost threshold that defines what constitutes an
acceptable and unacceptable risk for the organization. This figure should Impact
be a concrete dollar value. In the next exercises, you will build risk impact X
and probability scales with this value in mind, ensuring that “high” or Probability
“extreme” risks are immediately communicated to senior leadership.
Acceptable
Do not consider IT budget restrictions when developing this number. The
acceptable risk threshold should reflect the business’ tolerance/appetite
for risk (review activity 1.2.3 if necessary).
• This threshold is typically based on the organization’s ability to absorb
financial losses, and its tolerance/appetite towards risk.
• If your organization has ERM, adopt the existing acceptability
threshold.
Record this threshold in section 5.3 of the Risk Management Program Participants:
Manual. • IT risk council
• Relevant business stakeholders
• Representation from senior
management team
Create a financial impact assessment scale

Create a financial impact assessment scale

Instructions:

1. Create a scale to assess the financial impact of risk events.

a. Typically, risk impacts are assessed on a scale of 1–5;
however, some organizations may prefer to assess risks
using 3, 7, or 9 point scales.
$250,000 Extreme
2. Ensure that the unacceptable risk threshold is reflected in the
scale. $100,000 High
a. In the example provided, the unacceptable risk threshold
$60,000 Moderate
($100,000) is represented as “High” on the impact scale.
3. Attach labels to each point on the scale. Effective labels will $35,000 Low
easily distinguish between risks on either side of the
unacceptable risk threshold. $10,000 Negligible
4. Record the risk impact scale in section 5.3 of the Risk
Management Program Manual.

Participants:
• IT risk council
• Relevant business stakeholders
• Representation from senior management team
Incorporate project overruns and service outages into
financial impact scales
Time is money. Convert project overruns and service outages into costs.

Use the tables below to quickly convert impacts typically measured in units of time to financial cost. Replace the values in
the table with those that reflect your own costs.
• While project overruns and service outages may have intangible impacts beyond the unexpected costs stemming from
paying employees and lost revenue (such as adding complexity to project management and undermining the business’
confidence in IT), these measurements will provide adequate impact estimations for risk assessment.
• Remember, complex risk events can be analyzed further with an expected cost assessment.
Project Overruns

Average cost
Time Number of Estimated Impact
Project per employee
(days) employees cost scale
(per day) $250,000 Extreme
20
8 $300 $48,000 Low $100,000 High
days
$60,000 Moderate
Service Outages
$35,000 Low

Lost revenue Estimated $10,000 Negligible

Service Time (hours) Impact scale
(per hour) cost

4 hours $10,000 $40,000 Low

Incorporate reputational cost into risk assessments (1 of 3)

Select a technique to measure reputational cost

Realized risk events may have profound reputational costs that do not immediately impact your
bottom line.

Reputational cost can take several forms, including the Technique #1

internal and external perception of:
A Brand likeability Use financial indicators:

B Product quality For-profit companies typically experience reputational loss

as a gradual decline in the strength of their brand,
C Leadership capability exclusion from industry groups, or lost revenue.
If possible, use these measures to put a price on
D Social responsibility reputational loss:
Based on your industry and the nature of the risk, select • Lost revenue attributable to reputation loss
one of the three techniques described in this section to • Loss of market share attributable to reputation loss
incorporate reputational costs into your risk assessment. • Drops in share price attributable to reputation loss (for
public companies)

Everything an organization does or says creates an Match this dollar value to the corresponding level on the
indelible impression in the minds of its key stakeholders – impact scale created in Activity 2.2.2.
senior management, employees, customers, local • If you are not able to effectively translate all
communities, investors, and so on. The sum total of all reputational costs into financial costs, proceed to
these interactions represents your reputation.1 techniques 2 and 3 on the following slide.
– Richard Smith-Bingham, Director of Global Risk Center,
Oliver Wyman
1: Oliver Wyman
Incorporate reputational cost into risk assessments (2 of 3)

Select a technique to measure reputational cost

It is common for public sector or not-for-profit organizations to have difficulty putting a price tag on intangible
reputational costs.
• For example, a government organization may be unable to directly quantify the cost of losing confidence and/or support
of the public.
• A helpful technique is to reframe how reputation is assigned value.

Technique #2
Calculate the value of avoiding reputational cost:

1. Imagine that the particular risk event you are assessing has occurred. Describe the resulting reputational cost
using qualitative language.
For example:
• A data breach which caused the unsanctioned disclosure of 2,000 client files has inflicted high reputational costs on
the organization. These have impacted the organization in the following ways:
o Loss of organizational trust in IT
o IT’s reputation as a value provider to the organization is tarnished
o Loss of client trust in the organization
o Potential for a public reprimand of the organization by the government to restore public trust
2. Then, determine (hypothetically) how much money the organization would be willing to spend to prevent the
reputational cost from being incurred.
3. Match this dollar value to the corresponding level on the impact scale created in Activity 2.2.2.
Incorporate reputational cost into risk assessments (3 of 3)

Select a technique to measure reputational cost

If you feel that the other techniques have not reflected reputational impacts in the overall severity level of the risk, create a
parallel scale that roughly matches your financial impact scale.

Technique #3
Create a parallel scale for reputational impact: Example:

Visibility is a useful metric for measuring reputational impact. Visibility

measures how widely knowledge of the risk event has spread and how
negatively the organization is perceived. Visibility has two main External, High Amp. Extreme
dimensions: (regulators, lawsuits)

• Internal vs. External External, High Amp. High

(media)
• Low Amplification vs. High Amplification
Internal/External: The further outside of the organization that the risk External, Low Amp.
(competitors)
Moderate
event is visible, the higher the reputational impact.
Low/High Amplification: The greater the ability of the actor to
communicate and amplify the occurrence of a risk event, the higher the Internal, High Amp.
(CEO) Low
reputational impact.
After establishing a scale for reputational impact, test whether it reflects
the severity of the financial impact levels in the financial impact scale. Internal, Low Amp. Negligible
(IT)
• For example:
o If the media learns about a recent data breach, does that feel like
a $100,000 loss?
Create a probability scale

Create a probability scale

Instructions:
1. Create a scale to assess the probability that a risk event will occur over a given
period of time.
80–99% Extreme
a) recommends assessing the probability that the risk event will occur over
a period of one year (the IT risk council should be reassessing the risk
event no less than once per year). 60–79% High
2. Ensure that the probability scale contains the same number of levels as the
financial impact scale (3, 5, 7, or 9). 40–59% Moderate
3. The example provided is likely to satisfy most IT departments – however, you
may customize the distribution of probability values to reflect the organization’s 20–39% Low
aversion towards uncertainty.
a) For example, an extremely risk averse organization may consider any
risk event with a probability greater than 20% to have a “High” probability 1–19% Negligible
of occurrence.
4. Attach the same labels used for the financial impact scale (Low, Moderate,
High, etc.). Record the risk impact scale in section 5.3 of the Risk Management
Program Manual.
Insight

Note: endorses the use of probability values (1–99%) rather than frequency (3 times per year) as a measurement
of likelihood.
For an explanation of why probability values lead to more precise and robust risk assessment, see the Appendix.
 Assess all identified risk events using the Risk Register
Tool
Determine Risk
Risk severity level assessment Severity &
Prioritize IT
Risks
Assess the probability of occurrence and probable impact for all identified risk events.

Participants:
• IT risk council • Representation from the
• Relevant business senior leadership team
stakeholders
Instructions:
1. Draw the scales for financial impact, reputational impact (if different from the financial impact scale), and probability on the
whiteboard so that they are easily visible to all participants.
2. As a group, go through the list of identified risk events one at a time. Document the “Risk Category” and “Existing
Controls.”
• (See the slide following this activity for tips on identifying existing controls.)
3. Assign each risk event a probability and impact level.
• When major disagreements arise, give precedence to opinions of senior personnel, as they are more likely to
possess a holistic understanding of IT and the business, and are less likely to inflate the significance of area-
specific risks.
• Remember, you are assessing the impact that a risk event will have on the organization as a whole, not just on IT.
4. When assigning a financial impact level to a risk event, factor in the probable number of instances that the event will
occur within the time frame for which you are assessing (usually one year).
• For risk events like third-party service outages which typically occur a few times each year, assign them an impact
level that reflects the probable financial impact the risk event will have over the entire year.
o E.g. If your organization is likely to experience two major service outages next year and each outage costs
the organization approximately $15,000, the total financial impact is $30,000.
(Continued) Assess all identified risk events using the Risk Register Tool

Risk severity level assessment

Instructions (continued):
5. Assign a risk owner to non-negligible risk events.
Tips for Selecting Probability Values:
• For organizations that practice ongoing risk management and
frequently reassess their risk portfolio (minimum once per year), Does ~10% sound right?
risk ownership does not need to be assigned to “Negligible” or
low-level risks. Test a probability estimate by assessing the
truth of the following statements:
• View this slide for advice on how to select a risk owner and
information on their responsibilities. • The risk event will likely occur once in the
next 10 years (if the environment remains
6. As you input the first few probability and impact values, compare them nearly identical).
to one another to ensure consistency and accuracy: • If 10 organizations existed that were
• Is a service outage really twice as impactful as our primary nearly identical to our own, it is likely that
software provider going out of business? 1 out of 10 would experience the risk
• Is a data breach far more probable than a > 1 hour web-services event this year.
outage?
Identify existing risk controls

Consider how IT is already addressing key risks.

Types of existing risk controls

Tactical controls Tactical Strategic controls Strategic
risk risk
Apply to individual risks only. control Apply to multiple risks. control

Example: A tactical control for Example: A strategic control for

backup/replication failure is faster backup/replication failure is
Risk implementing formal DR plans. Risk Risk
WAN lines. event event event

Insight

Identifying existing risk controls (past risk responses)

provides a clear picture of the measures already in
place to avoid, mitigate, or transfer key risks. This
reveals opportunities to improve existing risk controls,
Consider both tactical and strategic controls already in place or where new strategies are needed, to reduce risk
when filling out risk event information in the Risk Register severity levels below business thresholds.
Tool.
Assign a risk owner for each risk event

Designate a member of the IT risk council to be responsible for each risk event.

Risk Owner Responsibilities

Selecting the Appropriate Risk Owner Risk ownership means that an individual is responsible for the
following activities:
Use the following considerations to determine
the best owner for each risk: • Monitoring the threat or vulnerability for changes in the
probability of occurrence and/or probable impact.
• The risk owner should be familiar with the
process, project, or IT function related to the • Monitoring changes in the market and external environment
risk event. that may alter the severity of the risk event.
• The risk owner should have access to the • Monitoring changes of closely related risks with
necessary data to monitor and measure the interdependencies.
severity of the risk event. • Developing and using key risk indicators (KRIs) to
• The risk owner’s performance assessment measure changes in risk severity.
should reflect their ability to demonstrate the • Regularly reporting changes in risk severity to the IT risk
ongoing management of their assigned risk council.
events.
• If necessary, escalating the risk event to other IT risk council
personnel or senior management for reassessment.
• Monitoring risk severity levels for risk events after a risk
response has been implemented.
Determine how timing impacts your risks

Determine the proximity of the risk event

Instructions:
What is risk proximity?
1. Go through the register of risk events that have been assessed
The impact and probability of a risk event often
and identify risks where urgency and timing may impact the
fluctuate over time. The relationship between risk
severity of the risk, and how it should be responded to.
severity and time is called the proximity of the risk.
• Focus on “High” and “Extreme” risks.
• These fluctuations are often unpredictable.
2. Describe the proximity of these risk events in the Risk Register However, occasionally you may possess
Tool. knowledge about how time will impact a
• For example: “The probability of the risk event will particular risk.
decrease when the new IT budget is released on January • While the risk severity assigned to each risk in
1st.” the Risk Register Tool informs senior
3. Use the following questions to help you construct proximity management about the relative importance of
descriptions. each risk event, the proximity description
informs senior management about the
• Is the risk event specific to one particular point in time? urgency of the risk event and important
• Will the severity of the risk event increase over time? timing considerations for implementing risk
responses.
• Will the severity of the risk event increase at one
particular point in time? o For example, specific project risks only
exist while the project is underway.
• Will the severity of the risk event decrease over time?
– The probability of a project
• Will the severity of the risk event decrease at one overrun may be considerably
particular point in time? higher during a specific project
Note: See examples on the following slide. phase.
Understand how risk proximity can impact decision-making

Review the following risk event examples that illustrate how risk severity can fluctuate over time.

Risk severity is constant. Risk severity is concentrated Risk severity

at a particular point in time. increases/decreases after
E.g. Risk of losing key personnel. a particular point in time.
E.g. Risk of data breach leading up
to new product launch. E.g. Risk of project overrun after
layoffs.
Risk Severity

Risk Severity

Risk Severity
Time Time Time
(Optional) Use ’s Risk Costing Tool to calculate the expected
cost of IT’s high-priority risks

$ Risk Costing Tool

Use this tool to: In the following activities, you will:

1. Conduct a deeper analysis of severe risks. 1. Select top risk events for expected cost
assessment (approx. 10–15 risk events)
• Determine specific probability and financial
This impact values to communicate the severity of 2. Determine probability values
section the risk in the Expected Cost tab. 3. Determine the probable financial impact
• Identify the maximum financial impact that the 4. Determine the maximum financial
risk event may inflict. impact
5. Calculate a risk event’s expected cost
2. Assess the effectiveness of multiple risk
responses for each risk event.
• Determine how proposed risk events will
change the probability of occurrence and
Section
financial impact of the risk event.
3.1
3. Incorporate risk proximity into your cost-
benefit analysis of risk responses.
• Illustrate how spending decisions will impact the
expected cost of the risk event over time.

Risk Costing Tool

(Optional) Assign probability and financial impact
values to high-priority risks
Calculate
Expected cost assessment Expected Cost

Determine which risks require a deeper assessment:

recommends conducting a second-level assessment for 5–15%
of your IT risk register.
Communicating the expected cost of high-priority risks
significantly increases awareness of IT risks by the business.
Communicating risks to the business using their language also
increases the likelihood that risk responses will receive the
necessary support and investment.

Select risks with these characteristics:

Strongly consider conducting an expected cost assessment for risk events that meet one or
more of the following criteria. Record the list of risk
events requiring second-
The risk: level assessment in the
• Has been assigned to the highest risk severity level. Risk Costing Tool.
• Has exposed the organization previously and had severe implications. • Transfer the
• Exceeds the organization’s threshold for financial impact. probability and impact
• Involves an IT function that is highly visible to the business. levels for each event
• Will likely require risk response actions that will exceed current IT budgetary constraints. into the Risk Costing
• Is conducive to expected cost assessment: Tool using data from
o There is general consensus on probability estimates. the Risk Register Tool.
o There is general consensus on financial impact estimates.
o Historical data exists to support estimates.
(Continued) Assign probability and financial impact values to high-priority risks

Expected cost assessment

Instructions:
1. Go through the list of prioritized risks in the Risk Costing Tool one by one. On a
Who should participate?
whiteboard, indicate the probability and impact level (from the Risk Register Tool) for
the risk event being assessed. • Depending on the size of
2. Go around the room and record probability values (1–99%) and impact values ($) your IT risk council, you may
from participants. want to consider conducting
• Only record values from individuals that indicate that they are fairly confident this exercise in a smaller
with their estimates. group.
• Keep probability estimates to values that are multiples of five.
• Ideally, you should try to find
3. Estimate and record the maximum impact that the risk event could inflict.
the right balance between
• See Appendix II for information on how the possibility of high-impact scenarios
ensuring that the necessary
may influence your decision-making.
experience and knowledge is
4. Discuss the estimates provided. Eliminate outliers and retracted estimates.
in the room, while insulating
• If you are unable to achieve consensus, take the average of the values
the exercise from outlier
provided.
opinions, noise, and
5. If you are having difficulty arriving at a probability or impact value, select the median
distractions.
value of the level assigned to the risk during the risk severity level assessment.
• E.g. Risk event assigned to probability level “Moderate” (20–39%). Select a
probability value of 30%.
Employ common techniques to evaluate probability and impact
Refine your risk assessment process by developing more accurate measurements of probability
and impact.
Intersubjective Probability Justifying Your Estimates:
The goal of the expected cost assessment When asked to explain the numbers you arrived at during the risk
is to develop robust intersubjective assessment, pointing to an assessment methodology gives greater
estimates of probability and financial credibility to your estimates.
impact. • Assign one individual to take notes during the assessment exercise.
• Have them document the main rationale behind each value and the
By aggregating a number of expert opinions of level of consensus.
what they deem to be the “correct” value, you
will arrive at a collectively determined value that
better reflects reality than an individual opinion. 25%
Example: The Delphi Method
The Delphi Method is a common technique to produce a judgement Insight
that is representative of the collective opinion of a group. The underlying assumption behind intersubjective
• Participants are sent a series of sequential questionnaires forecasting is that group judgements are more
(typically by email). accurate than individual judgements. However, this
• The first questionnaire asks them what the probability, probable may not be the case at all.
impact, and expected cost is for a specific risk event. Sometimes, a single expert opinion is more valuable
• Data from the questionnaire is compiled and then communicated than many uninformed opinions. Defining whose
in a subsequent questionnaire, which encourages participants to opinion is valuable and whose is not is an unpleasant
restate or revise their estimates given the group’s judgements. exercise – therefore, selecting the right personnel to
• With each successive questionnaire, responses will typically participate in the exercise is crucially important.
converge around a single intersubjective value.
Phase 2 Outcomes

PHASE 3
Risk Risk
Governance Identification Monitor, Communicate, and
Respond to IT Risk

Risk
Response
Risk
Assessment
3.1 3.2
Monitor IT Risks Communicate
and Develop Risk IT Risk
Responses Priorities
PHASE 1 PHASE 2
Identify and Assess IT Risk
Review IT Risk Fundamentals
and Governance
2.1 2.2
1.1 1.2
✓ 1. Acceptable Risk
Thresholds
✓ 1. Maturity Assessment
✓ 2. Risk Register
✓ 2. Stakeholder Map
✓ 3. Prioritized List of IT
✓ 3. IT Risk Council Charter Risks
PHASE 3
Monitor, Communicate, and Respond to IT
Risk
Phase 3 (Section 1): Monitor IT Risks and Develop Risk
Responses
PHASE 1 PHASE 2 PHASE 3

1.1 1.2 2.1 2.2 3.1 3.2

Review IT Risk Establish a Risk Identify IT Risks Assess and Monitor IT Risks Communicate IT
Management Governance Prioritize IT and Develop Risk Priorities
Fundamentals Framework Risks Risk Responses

ACTIVITIES: OUTCOMES:

3.1.1 Develop key risk indicators (KRIs)

Completed risk event action plans
and escalation protocols
3.1.2 Establish the reporting schedule
3.1.3 Root cause analysis
Risk responses identified and
3.1.4 Identify contributing factors assessed for top risks
3.1.5 Identify and assess risk responses
3.1.6 Risk response cost-benefit analysis
Risk response selected for top risks
3.1.7 Create multi-year cost projections
Select the most effective response to your high-priority risks

In this section:
1. Actively monitor threats and vulnerabilities.
2. Identify risk response actions that will address
Risk Response Establish top risks.
Monitoring
Responsibilities 3. Perform cost-benefit analyses to assess the
effectiveness and appropriateness of risk
Perform Identify Risk
responses.
Cost-Benefit Response
Analysis Actions Organizations with a formal program
for managing IT risk were 31% more
successful in mitigating risk than
organizations with an ad hoc
Key metrics: approach. 31%
Research Group, N=76
• Number of top risks without an identified risk response.
• Percentage of risk events with a positive expected
cost.
• Number and severity of realized risk events that were Insight
accepted by the business.
• Total number of risk responses assigned. Merely being aware of your greatest risks is not enough. IT
• Percentage of risk responses funded and turned into departments with a formal program for managing risk are more
projects. successful because they possess mechanisms that turn risk
• Expected cost of implementing risk responses. priorities into fully-funded projects that have the support of the
• True cost of implementing risk responses. business.
• Number of risk event action plans reviewed by senior
leadership.
 Use ’s Risk Event Action Plan to manage high- Establish

priority risks Monitoring

Responsibilities

Risk Event Action Plan

Manage risks in between risk assessments and create a paper trail for key risks that
exceed the unacceptable risk threshold. Use a new form for every high-priority risk
that requires tracking.

Document the following information in the Obtaining sign-off from the senior leadership
Risk Event Action Plan: team or from the ERM office is an important
step of the risk management process. The
1. Risk event Risk Event Action Plan ensures that high-
2. Risk severity level priority risks are closely monitored and that
changes in risk severity are detected and
3. Risk owner reported.
4. Key risk indicators (KRIs)
Clear documentation is a way to ensure that
5. Delegation of risk monitoring critical information is shared with
responsibilities (if applicable) management so that they can make informed
6. Risk escalation protocols risk decisions. These reports should be
succinct yet comprehensive – depending on
7. Risk monitoring and reporting
time and resources, it is good practice to fill
schedule
out this form and obtain sign-off for the
8. Risk response action to be taken majority of IT risks.
9. Leadership review and approval Risk Event Action Plan
 Develop KRI metrics to track changes in risk severity

Develop 3.1.1
key risk indicators (KRIs) and escalation protocols
Clearly document the risk owner and the individual(s) carrying out risk monitoring activities (delegates) in the
Risk Event Action Plan.

The risk owner should be held accountable for monitoring their assigned risks, but may delegate responsibility for these
tasks.

What are KRIs?

Instructions: • KRIs should be observable metrics that alert the IT
risk council and management when risk severity
1. Design key risk indicators (KRIs) for risks that measure exceeds acceptable risk thresholds.
changes in their severity and document them in the
Risk Event Action Plan. • KRIs should serve as trip-wires or early-warning
• See the following slide for examples. indicators that trigger further actions to be taken on
the risk.
2. Document KRIs, escalation thresholds, and escalation
protocols for each risk in a Risk Event Action Plan. • Further actions may include:
o Escalation to the risk owner (if delegated) or
Note: Examples of KRIs can be found on the following to a member of the senior leadership team.
slide. o Reporting to the IT risk council or IT steering
committee.
o Reassessment.
o Updating the risk monitoring schedule.
(Continued): Develop KRI metrics to track changes in risk severity

Develop 3.1.1
key risk indicators (KRIs) and escalation protocols

Example

Risk Event: Cloud vendor being acquired or going out of business

Escalate
KRI Metric Method Escalation Threshold
To:

Financial health Share price Monitor share prices Falls below $X CIO

Number of recent More than one industry

Potential for merger or
mergers or acquisitions Market research consolidation in the last CIO
acquisition
in the industry year
Potential for merger or Indication from the Two or more vendor staff
Intel from vendor reps CIO
acquisition vendor predicting acquisition
Consult with strategic
Dependence on Number of alternative Fewer than two alternative
sourcing/vendor CIO
vendor vendors identified vendors
management personnel
Consult with strategic
Dependence on Estimated cost to
sourcing/vendor Greater than $X CIO
vendor transition to new vendor
management personnel

Once an escalation threshold is breached, risk owners must report to a senior member of the IT risk council or to the
leadership team, who determines the next action to be taken.
Establish a schedule for monitoring risks

Establish3.1.2
the reporting schedule

For each risk event, document how frequently the risk owner must report to the IT risk council in
the Risk Event Action Plan.

• A clear reporting schedule enforces accountability for each risk event, ensuring that risk owners are fulfilling their
monitoring responsibilities.
• The ongoing discussion of risks between assessment cycles also increases overall awareness of how IT risks are not
static, but are constantly evolving.

Reporting Requirements Risk Event

Weekly reports to ITRC Extreme

Bi-weekly reports to ITRC High

Monthly reports to ITRC Moderate

Report to ITRC only if KRI thresholds

triggered Low

No reports; reassessed bi-annually Negligible

 Use ’s tools to identify, analyze, and select risk
responses
Identify Risk
Risk Register & Risk Costing Tool Response
Actions

Tool Information
• Develop risk responses for all risk events pre-populated on the “Risk

1
Response” sheet of the Risk Register Tool.
• Document the root cause of the risk (Activity 3.1.3) and other
contributing factors (Activity 3.1.4).
• Identify risk responses (Activity 3.1.5).
• Predict the effectiveness of the risk response (if implemented) by
estimating the residual probability and impact of the risk (Activity
3.1.5).
[Mandatory] Risk Register Tool • The tool will calculate the residual severity of the risk after applying
the risk response.

Tool Information

2
• Continue your second-level risk analysis for top risks for which you
calculated expected cost in section 2.2.
• Activity 3.1.5:
o Identify between 1 and 4 risk response options for each risk.
o Develop precise values for residual probability and impact.
o Compare expected cost of the risk event to expected residual
cost.
[Optional] o Select the risk response to recommend to senior leadership
Risk Costing Tool and document it in the Risk Register Tool.
Determine the root cause of IT risks

Root cause
3.1.3 analysis

Use the “Five Whys” methodology to identify

the root cause and contributing/exacerbating The Five Whys Methodology
factors for each risk event.

Diagnosing the root cause of a risk, as well as the Risk event:

environmental factors that increase its potential impact Network outage
and probability of occurring, allow you to identify more Symptom Why?
effective risk responses.
Network congestion
Risk responses that only address the symptoms of the
risk are less likely to succeed than responses that Why?
address the core issue.
Inadequate bandwidth for latency-
sensitive applications
Contributing
Factors Why?
Increased business use of latency-
sensitive applications
Root Why?
Cause Business units rely on “real-time” data
Document the root Root Cause gathered from latency-sensitive
cause for each risk event applications
in the Risk Register Tool.
Why?
Identify factors that contribute to the severity of the risk

Identify
3.1.4
contributing factors
Environmental factors interact with the root cause to increase the probability or impact of the risk
event.
Which factors matter? Develop risk responses that target contributing factors.
Identify relevant actors and
assets that amplify or Root cause: Contributing factors: Symptoms:
diminish the severity of the Business units rely on “real- Unreliable router software Network outage
risk. time” data gathered from Actors: Network provider,
Actors latency-sensitive applications Actors: All business
router vendor, router software units, network provider
• Internal (business units) Actors: vendor, IT department
• External (vendor, Enterprise App users Asset/resource:
regulator, market, (Finance, Product Asset/resource: Network, Network, business
competitor, hostile actor) Development, Product router, router software operations, employee
Assets/Resources Management) productivity
• Infrastructure Risk response:
• Applications Asset/resource: Replace the vendor that Risk response:
• Processes Applications, network provides routers and router Replace legacy
• Information/data Risk response: software. systems.
• Personnel Decrease the use of latency-
• Reputation sensitive applications. ✓ X
• Operations
Document contributing
X Replacing the vendor would Replacing legacy
factors for each risk event in Decreasing the use of key apps reduce network outages at a systems would be
the Risk Register Tool. contradicts business objectives. relatively low cost. too costly.
Identify risk responses and assess their effectiveness
Identify Risk
Identify
3.1.5
and assess risk responses Response
Actions

Instructions:
Complete the following steps for each risk event. Document the following in the Risk Event Action
1. Identify a risk response action that will help reduce the Plan for each risk event:
probability of occurrence or the impact if the event were
• Risk response actions
to occur.
• Residual probability and impact levels
• Document risk responses on the “Risk • Residual risk severity level
Responses” tabs of the Risk Register Tool.
Review the following slides on the 4 Types of
• Indicate the type of risk response (avoidance, Risk Response to help complete the activity.
mitigation, transfer, or acceptance).
1. Avoidance
2. Assign each risk response action a residual probability
2. Mitigation
level and a residual impact level.
3. Transfer
• This is the same step performed in Activity 2.2.6, 4. Acceptance
when initial probability and impact levels were
determined – however, now you are estimating the
probability and impact of the risk event AFTER the
risk response action has been implemented
successfully.
Risk Register
Tool
• The Risk Register Tool will generate a residual
risk severity level for each risk event.
3. Identify the potential Risk Action Owner (Project
Manager) if the response is selected and turned into an IT
project, and document this in the Risk Register Tool.
Take actions to avoid the risk entirely

1 Risk Avoidance

Risk Avoidance 101

• Risk avoidance involves taking evasive maneuvers to avoid the risk event.
• Risk avoidance targets risk probability, decreasing the likelihood of the risk
event occurring.
o Since risk avoidance measures are fairly drastic, the probability is often
reduced to negligible levels.
• However, risk avoidance response actions often sacrifice potential benefits
in order to eliminate the possibility of the risk entirely.
• Typically, risk avoidance measures should only be taken for risk events with
extremely high severity, and when the severity (expected cost) of the risk
event exceeds the cost (benefits sacrificed) of avoiding the risk.

Example
Risk event: Information security vulnerability from third-party cloud services
provider.
• Risk avoidance action: Store all data in-house.
• Benefits sacrificed: Cost-savings, storage flexibility, etc.
Pursue projects that reduce the likelihood or impact of
the risk event

2 Risk Mitigation Example 2

However, some risk responses will have a greater effect on
decreasing the probability of a risk event with little effect on
Risk Mitigation 101 decreasing impact.

• Risk mitigation actions are risk responses that reduce Example

the probability and impact of the risk event. Mitigation: Create policies that restrict which personnel can
• Risk mitigation actions can either be to implement new access sensitive data on mobile devices.
controls or enhance existing ones. • This mitigation decreases the number of corporate
phones that have access to (or are storing)
sensitive data, thereby decreasing the probability
Risk Event: Data compromised by loss of mobile device. that a device is compromised.

Example 1 Example 3
Most risk responses will reduce both the probability of the Others will reduce the potential impact without decreasing
risk event occurring and its potential impact. its probability of occurring.
Example Example
Mitigation: Purchase and implement Enterprise Mobility Mitigation: Utilize robust encryption for all sensitive data.
Management (EMM) software with remote wipe capability.
• Corporate-issued mobile phones are just as likely
• EMM reduces the probability that sensitive data is to fall into the hands of nefarious actors, but the
accessed by a nefarious actor. financial impact they can inflict on the organization
• The remote-wipe capability reduces the impact by is greatly reduced.
closing the window that sensitive data can be
accessed from.
(Continued) Pursue projects that reduce the likelihood or impact of the risk event
Use the following IT functions to guide your selection of risk mitigation actions:

A Process Improvement
Key processes that would most directly improve the risk profile:
• Change Management
• Project Management
• Vendor Management
B Personnel
• Greater staff depth in key areas
• Increased discipline around documentation
• Knowledge Management
• Training
C Infrastructure Management
• Disaster Recovery Plan/Business Continuity Plan
• Redundancy & Resilience
• Preventative Maintenance
• Physical Environment Security
D Rationalization and Simplification
This is a foundational activity, as complexity is a major source of risk:
• Application Rationalization – reducing the number of applications
• Data Management – reducing the volume and locations of data
Transfer risks to a third party

To… Insurance Co.

3 Risk Transfer Send

Cc…

Subject IT Risk Transfer

Risk transfer is the exchange of uncertain future costs for fixed present costs.

Insurance Other Forms of Risk Transfer

The most common form of risk transfer is the purchase of insurance. Other forms of risk transfer include:
o The uncertain future cost of an IT risk event can be • Self-insurance
transferred to an insurance company who assumes the risk o Appropriate funds can be set aside
in exchange for insurance premiums. in advance to address the financial
o The most common form of IT-relevant insurance is cyber- impact of a risk event should it
insurance. occur.
Not all risks can be insured. Insurable risks typically possess the • Warranties
following 5 characteristics:1 • Contractual transfer
1. The loss must be accidental (the risk event cannot be insured if it o The financial impact of a risk event
could have been avoided by taking reasonable actions). can be transferred to a third party
2. The insured cannot profit from the occurrence of the risk event. through clauses agreed to in a
contract.
3. The loss must be able to be measured in monetary terms.
o For example, a vendor can be
4. The organization must have an insurable interest (it must be the contractually obligated to assume
party that incurs the loss). all costs resulting from failing to
5. An insurance company must offer insurance against that risk. secure the organization’s data.

1: M_o_R, 2007
Accept risks that fall below established thresholds or are prohibitively expensive to
address
Accepting a risk means tolerating the
4 Risk Acceptance expected cost of a risk event. It is a
conscious and deliberate decision
to retain the threat.
You may choose to accept a risk event for one of the
following 3 reasons:

1. The risk severity (expected cost) of the risk event falls below
acceptability thresholds and does not justify an investment in
a risk avoidance, mitigation, or transfer measure.
2. The risk severity (expected cost) exceeds acceptability
thresholds but all effective risk avoidance, mitigation, and
transfer measures are ineffective or prohibitively
expensive.
3. The risk severity (expected cost) exceeds acceptability
thresholds but there are no feasible risk avoidance,
mitigation, and transfer measures to be implemented.

Constant monitoring and the assignment of responsibility and accountability for accepted risk events is
crucial for effective management of these risks. No IT risk should be accepted without detailed
documentation outlining the reasoning behind that decision and evidence of approval by senior
management.
(Optional) Use ’s Risk Costing Tool to analyze and
select a risk response
Perform
Risk response
3.1.6 cost-benefit analysis Cost-Benefit
Analysis

The purpose of a cost-benefit analysis (CBA) is to guide financial decision-making.

This helps IT make risk-conscious investment decisions that fall within the IT budget, and helps the organization make sound
budgetary decisions for risk response projects that cannot be addressed by IT’s existing budget.

Instructions:
1. Reopen the Risk Costing Tool. For each risk that you
Risk Costing Tool
conducted an expected cost assessment in section 2.2 for,
find the Excel sheet that corresponds to the risk number
(e.g. R001).
2. Identify between 1 and 4 risk response options for the risk
event and document them in the Risk Costing Tool.
• The “Risk Response 1” field will be automatically
populated with expected cost data for a scenario
where no action was taken (risk acceptance). This
will serve as a baseline for comparing alternative
responses.
• For the following steps, go through the risk
responses one by one.
3. Estimate the first year cost for the risk response.
• This cost should reflect initial capital expenditures and
first year operating expenditures.
(Continued) Use ’s Risk Costing Tool to analyze and select a risk response

Risk response
3.1.6 cost-benefit analysis

4. Estimate residual risk probability and financial impact for Year 1 with the risk response in place.
• Rather than estimating the probability level (low, medium, high), determine a precise probability value of the risk
event occurring once the response has been implemented.
• Estimate the dollar value of financial impacts if the risk event were to occur with the risk response in place.

The tool will calculate the expected residual cost of the risk event:
(Financial Impact x Probability) - Costs = Expected Residual Cost

5. Select the highest value risk response and document it in the Risk Register Tool.
6. Document your analysis and recommendations in the Risk Event Action Plan.

Note: See Activity 3.1.7 to build multi-year cost projections for risk responses.
(Optional) Create multi-year cost projections with the Risk Costing Tool

Create
3.1.7
multi-year cost projections

Select between risk response options by projecting their costs and benefits over multiple years.
• It can be difficult to choose between risk response options that require different payment schedules. A risk
response project with costs spread out over more than one year (e.g. incremental upgrades to an IT system) may be more
advantageous than a project with costs concentrated up-front that may cost less in the long-run (e.g. replacing the
system).

• However, the impact that risk response projects have on reducing risk severity is not necessarily static. For example, an
expensive project like replacing a system may drastically reduce the risk severity of a system failure. Whereas,
incremental system upgrades may only marginally reduce risk severity in the short-term but reach similar levels as a full
system replacement in a few years.

Use ’s Risk Costing Tool to conduct multi-year cost benefit analyses and compare risk responses.

Instructions:
Calculate expected cost for multiple years using the Risk Costing
Tool for:
• Risk events that are subject to change in severity over
time.
• Risk responses that reduce the severity of the risk
gradually.
• Risk responses that cannot be implemented immediately.
Copy/paste the graphs into the Risk Report and the Risk Event
Action Plan for the risk event.
Phase 3 (Section 2): Communicate IT Risk Priorities
PHASE 1 PHASE 2 PHASE 3

1.1 1.2 2.1 2.2 3.1 3.2

Review IT Risk Establish a Risk Identify IT Risks Assess and Monitor IT Risks Communicate IT
Management Governance Prioritize IT and Develop Risk Risk Priorities
Fundamentals Framework Risks Responses

ACTIVITIES: OUTCOMES:

Obtained approval for risk action

3.2.1 Obtain executive approval for risk
action plans
✓ plans

3.2.2 Socialize the Risk Report Communicated IT’s risk

recommendations to senior
3.2.3 Transfer ownership of risk responses leadership
to project managers
Embedded risk management into
3.2.4 Finalize the Risk Management day-to-day IT operations
Program Manual
Effectively deliver IT risk expertise to the business and foster a culture of risk-
awareness within IT

Communicate IT Risk Create a strong paper trail and obtain sign-off for the
ITRC’s recommendations.
Management in Two Directions
Now that you have collected all of the necessary raw data, you must
1. Up to senior leadership (and ERM if
communicate your insights and recommendations effectively.
applicable)

A fundamental task of risk management is communicating risk

2. Down to IT employees (embedding risk
information to senior management. It is your responsibility to enable
awareness) them to make informed risk decisions. This can be considered upward
communication.
Senior Leadership
The two primary goals of upward communication are:
1. Transferring accountability for high-priority IT risks to the ERM or to
senior leadership.
2. Obtaining funds for risk response projects recommended by the
ITRC.

Good risk management also has a trickle-down effect impacting all of

IT. This can be considered downward communication.

The two primary goals of downward communication are:

IT Personnel 1. Fostering a risk-aware IT culture.
2. Ensuring that the IT risk management program maintains
momentum and runs effectively.
Obtain sign-off on risk event action plans

Obtain
3.2.1
executive approval for risk action plans

Task:
All IT risks that were flagged for exceeding the organization’s severity
thresholds must obtain sign-off by the CIO or another member of the
senior leadership team.
• In the assessment phase, you evaluated risks using severity thresholds
approved by the business and determined whether or not they justified a
risk response.
• Whether your recommendation was to accept the risk or to analyze
possible risk responses, the business should be made aware of most IT
risks.
Best Practices and Key Benefits
Best practice is for all acceptable risks to also be signed-off by senior leadership.
However, for ITRCs that brainstorm 100+ risks, this may not be possible. If this is the
case, prioritize accepted risks that were assessed to be closest to the organization’s
thresholds.

By receiving a stamp of approval for each key risk from senior management, you ensure
that:
1. The organization is aware of important IT risks that may impact business
objectives.
2. The organization supports the risk assessment conducted by the ITRC.
3. The organization supports the plan of action and monitoring responsibilities
proposed by the ITRC.
4. If a risk event were to occur, the organization holds ultimate accountability.
Use ’s Risk Report to communicate IT’s top risk recommendations to senior
leadership
3.2.2
Publish the Risk Report
Create a succinct, impactful document that summarizes the outcomes of risk assessment and
highlights the IT risk council’s top recommendations to the senior leadership team.

The Risk Report contains: The closer IT gets to the board, the more
visibility and money they're going to get
• An executive summary page highlighting the main takeaways for senior
to address IT risk. But you need to give
management:
the business some 'tools' so they care
o A short summary of results from the most recent risk
about IT risk.
assessment
o Dashboard – VP Security and Risk, Energy Logistics
o A list of top 10 risks ordered from most severe to least Company
• Subsequent individual risk analyses (1 to 10)
o Detailed risk assessment data
o Risk responses
o Risk response analysis
o Multi-year cost projection (see the following slide)
o Dashboard
o Recommendations

Insight

Dashboards are visualizations that emphasize key data points and

support recommendations. They serve as the headlines of the Risk
Report, helping members of the senior leadership team to comprehend
the gravity of IT risks, as well as the costs associated with accepting and Use ’s Risk Report.
responding to risks.
Promote a culture of risk-awareness throughout IT

Encourage risk-awareness to extend the benefits of risk management to every aspect of IT.

Benefits of risk-awareness:

• More preventative and proactive approaches to IT projects are discussed and considered.
• Changes to the IT threat landscape are more likely to be detected, communicated, and acted upon.
• IT possesses a realistic perception of its ability to perform functions and provide services.
• Contingency plans are put in place to hedge against risk events.
• Fewer IT risks go unidentified.
• CIOs and business executives make better risk decisions.

Consequences of low risk-awareness:

• False confidence about the number of IT risks impacting the organization and their severity.
• Risk-relevant information is not communicated to the ITRC, which may result in inaccurate risk
assessments.
• Confusion surrounding whose responsibility it is to consider how risk impacts IT decision-making.
• Uncertainty and panic when unanticipated risks impact the IT department and the organization.
Embedding risk management in the IT department is a full-time job
Take concrete steps to increase risk-aware decision-making in IT.
The IT risk council plays an instrumental role in fostering a culture of risk-awareness throughout the IT department. In
addition to periodic risk assessments, fulfilling reporting requirements, and undertaking ongoing monitoring responsibilities,
members of the ITRC can take a number of actions to encourage other IT employees to adopt a risk-focused approach,
particularly at the project planning stage.

Embed risk management in project planning Embed risk management with employee
development
Make time for discussing project risks at every
Train IT staff on the ITRC’s planned responses to
project kick-off.
specific risk events.
• A main benefit of including senior personnel from
• If a response to a particular risk event is not to
across IT in the ITRC is that they are able to
implement a project, but rather to institute new
disseminate the IT risk council’s findings to their
policies or procedures, ensure that changes are
respective practices.
communicated to employees and that they receive
• At project kick-off meetings, schedule time to training.
identify and assess project-specific risks.
Provide risk management education opportunities.
• Encourage the project team to identify strategies
• Remember that a more risk-aware IT employee
to reduce the probability and impact of those risks
provides more value to the organization.
and document these in the project charter.
• Invest in your employees by encouraging them to
• Lead by example by being clear and open about
pursue education opportunities like receiving risk
what constitutes acceptable and unacceptable
management accreditation, or providing them with
risks.
educational experiences such as workshops,
seminars, and e-learning.
(Continued) Embedding risk management in the IT department is a full-time job

Encourage risk awareness by adjusting performance metrics and job titles.

Performance metrics:
Depending on the size of your IT department, and the amount of resources dedicated to ongoing risk management, you
may consider embedding risk management responsibilities into the performance assessments of certain ITRC members or
other IT personnel.
• Personalize the risk management program metrics you have documented in your Risk Management Program Manual.
• Evidence that KPIs are monitored and frequently reported is also a good indicator that risk owners are fulfilling their risk
management responsibilities.

Insight

If risk management responsibilities are not built into performance assessments, it is less likely that they will invest
time and energy into these tasks. Adding risk management metrics to performance assessments directly links good
job performance with good risk management, making it more likely that ITRC activities and initiatives gain traction
throughout the IT department.

Job descriptions:
Changing job titles to reflect the focus of an individual’s role on managing IT risk may be a good way to distinguish
personnel tasked with developing KRIs and monitoring risks on a week-to-week basis.
• Some examples include: IT Risk Officer, IT Risk Manager, and IT Risk Analyst.
Hand off risk responses to project managers

Transfer
3.2.3
ownership of risk responses to project managers
Once risk responses have obtained approval and funding, it is time to transform them into fully-
fledged projects.
• Assign responsibility for executing the specific risk
response action to a project manager.
• For advice on how to optimize project management,
read ’s blueprint, Create Project Management
Success.

Create Project Management Success

Finalize the Risk Management Program Manual

Finalize
3.2.4
the Risk Management Program Manual

Go back through the Risk Management Program

Manual and ensure that the material will accurately reflect
your approach to risk management going forward.
Primary
Remember, the program manual is a living document
that should be evolving alongside your risk management
Deliverable:
program, reflecting best practices, knowledge, and
experiences accrued from your own assessments and
experienced risk events.

The best way to ensure that the program manual continues

to guide and document your risk management program is to
make it the focal point of every ITRC meeting and ensure
that one participant is tasked with making necessary
adjustments and additions.

Upon completing the workshop, the

deliverables that we were left with were
really outstanding. We put together a 3-year
project plan from a high level, outlining
projects that will touch upon our high risk
areas. Risk Management
– Director of Security & Risk, Program Manual
Water Management Company
Don’t get complacent and allow your risk management program to flatline
So you’ve identified the most important IT risks and implemented projects to protect IT and the business.
Unfortunately, your risk assessment is already outdated.
Perform regular health checks to keep your finger on the pulse of the key risks threatening the business and your reputation.

To continue the momentum of your newly-forged IT risk management program, read ’s research on conducting periodic
risk assessments and “health checks”:

Revive Your Risk Management Program With a Regular Health Check

of organizations reassess their
82% IT risk portfolio only once per
year or even less frequently.1
 Complete ’s Risk Management  Our focus is on using data to
Health Check to seize the make IT risk assessment less
momentum you created by building like an art and more like a
a robust IT risk management science. Ongoing data-driven of organizations describe their
program, and create a process for risk management is self- 23% risk management processes
as “Mature” or “Robust.”2
conducting periodic health checks improving and grounded in
and embedding ongoing risk historical data.
management into every aspect of IT.

Don’t be lulled into a false sense of security.

It might be your greatest risk.
1 Protiviti 2 ERM Initiative
Phase 3 Outcomes

PHASE 3
Risk Risk
Governance Identification Monitor, Communicate, and
Respond to IT Risk

Risk
Response
Risk
Assessment
3.1 3.2

✓ 1. Risk Event Action Plan

✓ 2. Risk Reports
PHASE 1 PHASE 2
Identify and Assess IT Risk ✓ 3. IT Risk
Review IT Risk Fundamentals Recommendations
and Governance
2.1 2.2
1.1 1.2
✓ 1. Acceptable Risk
Thresholds
✓ 1. Maturity Assessment
✓ 2. Risk Register
✓ 2. Stakeholder Map
✓ 3. Prioritized list of IT risks
✓ 3. IT Risk Council Charter
Appendix I: Probability vs. Frequency
Why we measure likelihood using probability, not frequency:
The basic formula of Likelihood x Impact = Severity is a common methodology used across risk management frameworks.
However, some frameworks measure likelihood using Frequency, rather than Probability.
Frequency is typically measured as the number of instances an event occurs over a given period of time (e.g. once per
month).
• For risk assessment, historical data regarding the frequency of a risk event is commonly used to indicate the likelihood that
the event will happen in the future.
Probability is a numerical representation of the “degree of belief” that the risk event will occur in a given future timeframe (e.g.
25% probability that the event will occur within the next year).

False Objectivity
While some may argue that frequency provides an objective measurement of likelihood, it is well-understood in the field of
probability theory that historical data regarding the frequency of a risk event may have little bearing over the probability of that
event happening in the future. Frequency is often an indication of future probability, but should not be considered an objective
measurement of it.
Likelihood scales that use frequency underestimate the magnitude of risks that lack historical precedent. For example, an IT
department that has never experienced a high-impact data breach would adopt a very low likelihood score using the
frequentist approach. However, if all of the organization’s major competitors have suffered a major breach within the last 2
years, they ought to possess a much higher degree of belief that the risk event will occur within the next year.
Probability is a more comprehensive measurement of future likelihood, as frequency can be used to inform the selection of
a probability value. The process of selecting intersubjective probability values will naturally internalize historical data such as
the frequency that the event occurred in the past. Further, the frequency that the event is expected to occur in the future can
be captured by the expected impact value. For example, a risk event that has an expected impact per occurrence of $10,000
that is expected to occur 3 times over the next year has an expected impact of $30,000.
Appendix II: Should max impacts sway decision-making?
Don’t just fixate on the most probable impact – be aware of high impact outcomes.
Fig. 1
During assessment, risks are evaluated according to their most probable financial impact. Normal Probability
• For example, a service outage will likely last for 2 hours, and may have an expected cost of Distribution
$14,000.
Naturally, focusing on the most probable financial impact will exclude higher impacts that – while

Probability
theoretically possible – are so unlikely that they do not warrant any real consideration.
• For example, it is possible that a service outage could last for days – however, the probability
for such an event may be well below 1%.

While the risk severity level assessment allows you to present impacts as a range of values
(e.g. $50,000 to $75,000), the expected cost assessment requires you to select specific values.
• However, this analysis may fail to consider much higher potential impacts that have non- Financial Impact
negligible probability values (probability values that you cannot ignore). Fig. 2
• What you consider “non-negligible” will depend on your organizational risk tolerance/appetite. Fat-Tailed Probability
Distribution
Most Probable
Sometimes called Black Swan events or Fat-Tailed outcomes, high-impact events may occur Impact
when the far right of the probability distribution – or the “tail” – is thicker than a normal

Probability
distribution (see fig. 2).
• A good example is a data breach. While small to medium impacts are far more likely to occur
than a devastating intrusion, the high-impact scenario cannot be ignored completely.
Fat-Tailed
Outcomes
For risk events that contain non-negligible probabilities (too high to be ignored)
consider elevating the risk severity level or expected cost.
Financial Impact