01-Build-an-IT-Risk-Management-Program--Phases-1-3.pptx

Info-Tech Research Group Inc. is a global leader in providing IT research and advice.
Info-Tech’s products and services combine actionable insight and relevant advice
with ready-to-use tools and templates that cover the full spectrum of IT concerns.
© 1997-2022 Info-Tech Research Group Inc.
Build an IT Risk
Management Program
Mitigate the IT risks that could
negatively impact your organization.

Info-Tech Research Group | 2
Table of
Contents 3 Executive Brief
4 Analyst Perspective
5 Executive Summary
19 Phase 1: Review IT Risk Fundamentals & Governance
43 Phase 2: Identify and Assess IT Risk
74 Phase 3: Monitor, Communicate, and Respond to IT Risk
102 Appendix
108 Bibliography

E X E C U T I V E B R I E F
Build an IT Risk
Management Program
Mitigate the IT risks that could
negatively impact your organization.

Analyst
Perspective
Siloed risks are risky business
for any enterprise.
Brittany Lutes
Senior Research
Analyst, CIO Practice
Risk is an inherent part of life but not very well understood or executed within
organizations. This has led to risk being avoided or, when it’s implemented, being
performed in isolated siloes with inconsistencies in understanding of impact and
terminology.
Looking at risk in an integrated way within an organization drives a truer sense of the
thresholds and levels of risks an organization is facing – making it easier to manage
and leverage risk while reducing risks associated with different mitigation responses
to the same risk events.
This opens the door to using risk information – not only to prevent negative impacts
but as a strategic differentiator in decision making. It helps you know which risks are
worth taking, driving strong positive outcomes for your organization.
Valence Howden
Principal Research
Director, CIO
Practice

Executive Summary
Your Challenge Common Obstacles Info-Tech’s Approach
IT has several challenges when it comes to addressing
risk management:
• Risk is unavoidable. Without a formal program to
manage IT risk, you may be unaware of your
severest IT risks.
• The business could be making decisions that are
not informed by risk.
• Reacting to risks after they occur can be costly and
crippling, yet it is one of the most common tactics
used by IT departments.
Many IT organizations realize these obstacles:
• IT risks and business risks are often addressed
separately, causing inconsistencies in the approach.
• Security risk receives such a high profile that it
often eclipses other important IT risks, leaving the
organization vulnerable.
• Failing to include the business in IT risk
management leaves IT leaders too accountable; the
business must have accountability as well.
• Transform your ad hoc IT risk management
processes into a formalized, ongoing program and
increase risk management success.
• Take a proactive stance against IT threats and
vulnerabilities by identifying and assessing IT’s
greatest risks before they occur.
• Involve key stakeholders, including the business
senior management team, to gain buy-in and to
focus on the IT risks most critical to the
organization.
Info-Tech Insight
IT risk is business risk. Every IT risk has business implications. Create an IT risk management program that shares accountability with
the business.

Ad hoc approaches to
managing risk fail because…
If you are like the majority of IT departments, you do
not have a consistent and comprehensive strategy for
managing IT risk.
1. Ad hoc risk management is reactionary.
2. Ad hoc risk management is often focused only on IT security.
3. Ad hoc risk management lacks alignment with business objectives.
58% of organizations
still lack a systematic
and robust method to
actually report on risks
The results:
• Increased business risk exposure caused by a lack of understanding of the impact of IT risks on
the business.
• Increased IT non-compliance, resulting in costly settlements and fines.
• IT audit failure.
• Ineffective management of risk caused by poor risk information and wrong risk response
decisions.
• Increased unnecessary and avoidable IT failures and fixes.
Source: AICPA, 2021
58%

Data is an invaluable asset – ensure it’s
protected
Case Studies
Cognyte, a vendor hired to be a
cybersecurity analytics company, had
over five billion records exposed in
Spring 2021. The data was compromised
for four days, providing attackers with
plenty of opportunities to obtain
personally identifying information.
SecureBlink., 2021
Security Magazine, 2021
Facebook, the world’s largest social
media giant, had over 533 million
Facebook users’ personal data
breached when data sets were able to
be cross-listed with one another.
Business Insider, 2021
Security Magazine, 2021
In 2020, over 10.6 million
customers experienced some sort
of data being accessible, with
1,300 having serious personally
identifying information breached.
The New York Times, 2020

Risk management is a
business enabler
Formalize risk management to increase your likelihood
of success.
By identifying areas of risk exposure and creating solutions proactively, obstacles can be
removed or circumvented before they become a real problem.
Only 12% of organizations are
using risk as a strategic tool
most or all of the time
A certain amount of risk is healthy and can stimulate innovation:
• A formal risk management strategy doesn’t mean trying to mitigate every possible risk; it means
exposing the organization to the right amount of risk.
• Taking a formal risk management approach allows an organization to thoughtfully choose which
risks it is willing to accept.
• Organizations with high risk management maturity will vault themselves ahead of the
competition because they will be aware of which risks to prepare for, which risks to ignore, and
which risks to take.
12%
Source: AICPA, 2021

IT risk is enterprise risk
Accountability for IT risks and the decisions made to address
them should be shared between IT and the business. IT risks have a direct
and often aggregated
impact on enterprise
risks and
opportunities in the
same way other
business risks can.
This relationship
must be understood
and addressed
through integrated
risk management to
ensure a consistent
approach to risk.
IT Risks
ENTERPRISE RISKS
Digital Risks
People Risks
Finance Risks

Follow the steps of this blueprint to build or
optimize your IT risk management program
1.1
PHASE 2
Identify and Assess IT Risk
PHASE 3
Monitor, Report, and Respond to IT Risk
PHASE 1
Review IT Risk Fundamentals and
Governance Identify IT Risks Assess and Prioritize
IT Risks
Report IT Risk
Priorities
Monitor IT Risks and
Develop Risk
Responses
2.1 2.2
3.1 3.2
Start Here
1.2
Review IT Risk
Management
Fundamentals
Establish a Risk
Governance
Framework
Governance

Each step of this blueprint is accompanied by supporting
deliverables to help you accomplish your goals:
Blueprint deliverables
Key deliverable:
Integrated Risk
Maturity Assessment
Assess the organization's
current maturity and
readiness for integrated
risk management (IRM).
Risk Costing
Tool
A potential cost-benefit
analysis of possible risk
responses to determine a
good method to move
forward.
Centralized Risk
Register
The repository for all the
risks that have been
identified within your
environment.
Risk Report & Risk
Event Action Plan
A method to report risk
severity and hold risk owners
accountable for chosen
method of responding.
Use the tools and activities in each
phase of the blueprint to create a
comprehensive, customized
program manual for the ongoing
management of IT risk.
Risk Management
Program Manual

Benefit from industry-leading best practices
As a part of our research process, we used the COSO, ISO 31000, and COBIT 2019 frameworks. Contextualizing IT risk management within these
frameworks ensured that our project-focused approach is grounded in industry-leading best practices for managing IT risk.
COBIT 2019’s IT functions were used to
develop and refine our Ten IT Risk
Categories used in our top-down risk
identification methodology.
ISO 31000
Risk Management can help
organizations increase the likelihood of
achieving objectives, improve the
identification of opportunities and
threats, and effectively allocate and
use resources for risk treatment.
COSO’s Enterprise Risk Management —
Integrating with Strategy and
Performance addresses the evolution of
enterprise risk management and the need
for organizations to improve their
approach to managing risk to meet the
demands of an evolving business
environment.
COSO ISO
31000
COBIT
2019

Abandon ad hoc risk
management
A strong risk management foundation is valuable
when building your IT risk management program.
This research covers the following IT risk fundamentals:
 Benefits of formalized risk management
 Key terms and definitions
 Risk management within ERM
 Risk management independent of ERM
 Four key principles of IT risk management
 Importance of a risk management program manual
 Importance of buy-in and support from the business
Drivers of Formalized
Risk Management:
Grassroots Drivers
Drivers External to IT
Emerging IT risk awareness
Proactive initiative
Demonstrating IT’s
value to the business
Mandated by ERM
Internal Audit
External Audit
Occurrence of Risk Event

Blueprint benefits
IT Benefits Business Benefits
• Increased on-time, in-scope, and on-budget completion of IT projects.
• Meet the business’ service requirements.
• Improved satisfaction with IT by senior leadership and business
units.
• Fewer resources wasted on fire-fighting.
• Improved availability, integrity, and confidentiality of sensitive data.
• More efficient use of resources.
• Greater ability to respond to evolving threats.
• Reduced operational surprises or failures.
• Improved IT flexibility when responding to risk events and market
fluctuations.
• Reduced budget uncertainty.
• Improved ability to make decisions when developing long-term
strategies.
• Improved stakeholder and shareholder confidence.
• Achieved compliance with external regulations.
• Competitive advantage over organizations with immature risk
management practices.

Diagnostics and consistent frameworks are used throughout all four options.
DIY Toolkit
“Our team has already made this
critical project a priority, and we
have the time and capability, but
some guidance along the way
would be helpful.”
Guided
Implementation
“Our team knows that we need to fix
a process, but we need assistance
to determine where to focus. Some
check-ins along the way would help
keep us on track.”
Workshop
“We need to hit the ground
running and get this project
kicked off immediately. Our team
has the ability to take this over
once we get a framework and
strategy in place.”
Consulting
“Our team does not have the time or
the knowledge to take this project
on. We need assistance through the
entirety of this project.”
Info-Tech offers various levels of
support to best suit your needs

Guided Implementation
What does a typical GI on this topic look like?
Phase 1 Phase 2 Phase 3
Call #1: Assess
current risk
maturity and
organizational
buy-in.
Call #2:
Establish an IT
risk council and
determine IT risk
management
program goals.
Call #3: Identify
the risk
categories used
to organize risk
events.
Call #4: Identify
the threshold
for risk the
organization
can withstand.
Call #5: Create
a method to
assess risk
event severity.
Call #6: Establish a
method to monitor
priority risks and
consider possible
risk responses.
Call #7:
Communicate
risk priorities to
the business and
implement risk
management
plan.
A Guided
Implementation
(GI) is a series
of calls with an
Info-Tech analyst
to help implement
our best practices
in your
organization.
A typical GI is 6 to 8
calls over the
course of 3 to 6
months.

Workshop Overview
Day 1 Day 2 Day 3 Day 4 Day 5
Activities
Review IT Risk
Fundamentals and
Governance
Identify IT Risks Assess IT Risks Monitor, Report, and
Respond to IT Risk
Next Steps and
Wrap-Up (offsite)
1.1 Assess current program
maturity
1.2 Complete RACI chart
1.3 Create the IT risk council
1.4 Identify and engage key
stakeholders
1.5 Add organization-specific risk
scenarios
1.6 Identify risk events
2.1 Identify risk events
(continued)
2.2 Augment risk event list using
COBIT5 processes
2.3 Determine the threshold for
(un)acceptable risk
2.4 Create impact and probability
scales
2.5 Select a technique to
measure reputational cost
2.6 Conduct risk severity level
assessment
3.1 Conduct risk severity level
assessment
3.2 Document the proximity of
the risk event
3.3 Conduct expected cost
assessment
3.4 Develop key risk indicators
(KRIs) and escalation
protocols
3.5 Perform root cause analysis
3.6 Identify and assess risk
responses
4.1 Identify and assess risk
responses
4.2 Risk response cost-benefit
analysis
4.3 Create multi-year cost
projections
4.4 Review techniques for
embedding risk management in
IT
4.5 Finalize the Risk Report and
Risk Management Program
Manual
4.6 Transfer ownership of risk
responses to project managers
5.1 Complete in-progress
deliverables from previous
four days
5.2 Set up review time for
workshop deliverables and
to discuss next steps
Deliverables
1. Maturity Assessment
2. Risk Management Program
Manual
1. Finalized List of IT Risk Events
2. Risk Register
Manual
1. Risk Register
2. Risk Event Action Plans
Manual
1. Risk Report
Manual
1. Workshop Report
Manual
Contact your account representative for more
information.
workshops@infotech.com 1-888-670-8889

Build an IT Risk Management Program
Phase 1
1.1 Review IT Risk
Management Fundamentals
1.2 Establish a Risk
Governance Framework
Phase 2
2.1 Identify IT Risks
2.2 Assess and Prioritize IT
Risks
Phase 3
3.1 Develop Risk Responses
and Monitor IT Risks
3.2 Report IT Risk Priorities
This phase will walk you through the
following activities:
• Gain buy-in from senior leadership
• Assess current program maturity
• Identify obstacles and pain points
• Determine the risk culture of the
organization
• Develop risk management goals
• Develop SMART project metrics
• Create the IT risk council
• Complete a RACI chart
This phase involves the following
participants:
• IT executive leadership
• Business executive leadership
Phase 1
Review IT Risk Fundamentals and
Governance

Step 1.1 Step 1.2
Step 1.1
Review IT Risk Management
Fundamentals
This step involves the following
participants:
Activities
Outcomes of this step
• Reviewed key IT principles and
terminology
• Gained understanding of the relationship
between IT risk management and ERM
• Introduced to Info-Tech’s IT Risk
Management Framework
• Obtained the support of senior leadership
1.1.1 Gain buy-in from senior leadership
1.1.2 Assess current program maturity

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:
Effective IT risk management is possible
with or without ERM
Senior Leadership Team
ERM
IT Risk Management
With an ERM
Senior Leadership Team
Without an ERM
• Risk Decision-Making
Authority
• Final Accountability
• Risk Governance
• Risk Prioritization &
Communication
• Risk Identification
• Risk Assessment
• Risk Monitoring
Core Responsibilities
IT Risk Management
Pro: IT’s risk management responsibilities are defined (assessment
schedules, escalation and reporting procedures).
Con: IT may lack autonomy to implement IT risk management best
practices.
Pro: IT is free to create its own IT risk council and develop
customized processes that serve its unique needs.
Con: Lack of clear reporting procedures and mechanisms to share
accountability with the business.

Business
Objectives
Communication
Monitoring
IT Risk Management
Framework
Risk Governance
Risk Identification
Risk
Assessment
Risk
Response
Assess Risk
Maturity
Measure the
Success of
the Program
Use Risk
Identification
Frameworks
Engage
Stakeholder
Participation
Compile
IT-Related
Risks
Calculate
Expected Cost
Establish
Thresholds for
Unacceptable
Risk
Determine Risk
Severity &
Prioritize IT
Risks
Report Risk
Response
Actions
Perform
Cost-Benefit
Analysis
Establish
Monitoring
Responsibilities
Info-Tech’s IT risk management framework walks you
through each step to achieve risk readiness
Optimize Risk
Management
Processes

Risk management benefits To engage the business...
IT is compliant with external laws and regulations. Identify the industry or legal legislation and regulations your organization abides by.
IT provides support for business compliance. Find relevant business compliance issues, and relate compliance failures to cost.
IT regularly communicates costs, benefits, and risks to the business.
Acknowledge the number of times IT and the business miscommunicate critical
information.
Information and processing infrastructure are very secure. Point to past security breaches or potential vulnerabilities in your systems.
IT services are usually delivered in line with business requirements.
Bring up IT services that the business was unsatisfied with. Explain that their inputs
in identifying risks are correlated with project quality.
IT related business risks are managed very well.
Make it clear that with no risk tracking process, business processes become
exposed and tend to slow down.
IT projects are completed on time and within budget. Point out late or over-budget projects due to the occurrence of unforeseen risks.
Obtain the support of the senior leadership team or IT steering committee by
communicating how IT risk impacts their priorities.
Effective IT risk
management benefits

Input Output
• List of IT personnel and
business stakeholders
• Buy-in from senior leadership
for an IT risk management
program
Materials Participants
• Risk Management Program
Manual
1.1.1 Gain buy-in from senior
leadership
1-4 hours
The resource demands of IT risk management will vary from organization to organization.
Here are typical requirements:
• Occasional participation of key IT personnel and select business stakeholders in IT risk
council meetings (e.g. once every two weeks).
• Periodic risk assessments (e.g. 4 days, twice a year).
• IT personnel must take on risk monitoring responsibilities (e.g. 1-4 hours per week).
• Record the results in the Program Manual sections 3.3, 3.4 and 3.5.
Record the results in the Risk Management Program Manual.

Frequently and continually assessing your organization’s maturity
toward integrated risk ensures the right risk management
program can be adopted by your organization.
Integrated
Risk
Maturity
Assessment
Integrated Risk
Maturity Assessment
A simple tool to understand if your
organization is ready to embrace
integrated risk management by
measuring maturity across four key
categories: Context & Strategic Direction,
Risk Culture & Authority, Risk
Management Process, and Risk Program
Optimization.
The purpose of the Integrated
Risk Maturity Assessment is to
assess the organization's
current maturity and
readiness for integrated risk
management (IRM)
Use the results from this integrated risk maturity assessment to determine the type of risk
management program that can and should be adopted by your organizations.
Some organizations will need to remain siloed and focused on IT risk management only, while
others will be able to integrate risk-related information to start enabling automatic controls
that respond to this data.

Input Output
• Maturity scores across four
key risk categories
• Integrated Risk Maturity
Assessment Tool
1.1.2 Assess current program
maturity
1-4 hours
This assessment is intended for frequent use; process completeness should be re-evaluated
on a regular basis.
How to Use This Assessment:
1. Download the Integrated Risk Management Maturity Assessment Tool.
2. Tab 2, "Data Entry:" This is a qualitative assessment of your integrated risk management
process and is organized by the categories of integrated risk maturity. You will be asked
to rate the extent to which you are executing the activities required to successfully
complete each phase of the assessment. Use the drop-down menus provided to select
the appropriate level of execution for each activity listed.
3. Tab 3, "Results:" This tab will display your rate of IRM completeness/maturity. You will
receive a score for each category as well as an overall score. The results will be
displayed numerically, by percentage, and graphically.
Record the results in the Integrated Risk Maturity Assessment.

1 Discussion Product owner meets with sales team
2 Risk Culture and
Authority
Examine if risk-based decisions are being made by those
with the right level of authority and if the organization’s risk
appetite is embedded in the culture.
4
Risk Program
Optimization
3
Risk Management
Process
Determine if the current process to identify, assess, respond,
monitor, and report on risks is benefitting the organization.
1
Context and
Strategic Direction
Understanding of the organization’s main objectives and
how risk can support or enhance those objectives.
Integrated
Risk Maturity
Categories
Consider opportunities where risk-related data is being
gathered, reported, and used to make informed decisions
across the enterprise.

Step 1.2
Establish a Risk Governance Framework
participants:
Activities
• Developed goals for the risk management
program
• Established the IT risk council
• Assigned accountability and
responsibility for risk management
processes
Review IT Risk Fundamentals and Governance
1.2.1 Identify pain points/obstacles and opportunities
1.2.2 Determine the risk culture of the organization
1.2.3 Develop risk management goals
1.2.4 Develop SMART project metrics
1.2.5 Create the IT risk council
1.2.6 Complete a RACI chart
Step 1.1 Step 1.2

Follow these best practices
to make sure your
requirements are solid:
Create an IT risk
governance
framework that
integrates with
the business
1 Self-assess your current approach to IT risk management.
2 Identify organizational obstacles and set attainable risk
management goals.
3 Track the effectiveness and success of the program using SMART
risk management metrics.
4 Establish an IT risk council tasked with managing IT risk.
5 Set clear risk management accountabilities and responsibilities for
IT and business stakeholders.

Key metrics for your IT risk governance
framework
• Key stakeholders are left out or consulted once risks have already
occurred.
• Failure to employ consistent risk identification methodologies results in
omitted and unknown risks.
• Risk assessments do not reflect organizational priorities and may not
align with thresholds for acceptable risk.
• Risk assessment occurs sporadically or only after a major risk event has
already occurred.
Key metrics:
• Number of risk management processes done ad hoc.
• Frequency that IT risk appears as an agenda item at IT steering committee
meetings.
• Percentage of IT employees whose performance evaluations reflect risk
management objectives.
• Percentage of IT risk council members who are trained in risk management
activities.
• Number of open positions in the IT risk council.
• Cost of risk management program operations per year.
Info-Tech Insight
Metrics provide the foundation for determining the success of your IT risk management program and ensure ongoing funding to support appropriate risk
responses.
Challenges:

IT risk management success factors
Risk culture and awareness
A risk-aware organizational culture embraces new
policies and processes that reflect a proactive
approach to risk.
An organization with a risk-aware culture is better
equipped to facilitate communication vertically
within the organization.
Risk awareness can be embedded by revising job
descriptions and performance assessments to reflect
IT risk management responsibilities.
Support and sponsorship
from senior leadership
IT risk management has more success when
initiated by a member of the senior leadership
team or the board, rather than emerging from IT
as a grassroots initiative.
Sponsorship increases the likelihood that risk
management is prioritized and receives the
necessary resources and attention. It also ensures
that IT risk accountability is assumed by senior
leadership.
Organization size
Smaller organizations can often institute a mature
risk management program much more quickly than
larger organizations.
It is common for key personnel within smaller
organizations to be responsible for multiple roles
associated with risk management, making it easier
to integrate IT and business risk management.
Larger organizations may find it more difficult to
integrate a more complex and dispersed network of
individuals responsible for various risk management
responsibilities.

Input Output
Assessment
• Obstacles and pain points
identified
• IT Risk Management Success
Factors
1.2.1 Identify obstacles and pain
points
1-4 hours
Anticipate potential challenges and “blind spots” by determining which success factors are
missing from your current situation.
Instructions:
1. List the potential obstacles and missing success factors that you must overcome to
effectively manage IT risk and build a risk management program.
2. Consider some opportunities that could be leveraged to increase the success of this
program.
3. Use this list in Activity 1.2.3 to develop program goals.

Risk Management
Pain Points/Obstacles
• Lack of leadership buy-in
• Skills and understanding around risk management within IT
• Skills and understanding around risk management within the
organization
• Lack of a defined risk management posture
Opportunities
• Changes in regulations related to risk
• Organization moving toward an integrated risk management
program
• Ability to leverage lessons learned from similar companies
• Strong process management and adherence to policies by
employees in the organization
Replace the example pain points and opportunities
with real scenarios in your organization.

• You have multiple, strict compliance and/or
regulatory requirements.
• You house sensitive data, such as medical records.
• Customers expect your organization to maintain
strong and current security controls.
• Information security is highly visible to senior
management and public investors.
• The organization has multiple remote locations.
• Your organization operates within the following
industries:
o Finance
o Healthcare
o Telecom
1.2.2 Determine the risk
culture of your organization
1-3 hours
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 requirements.
• You have no sensitive data.
• Customers do not expect you to have strong
security controls.
• Revenue generation and innovative products take
priority and risk is acceptable.
• The organization does not have remote locations.
• It is likely that your organization does not operate
within the following industries:
o Finance
o Health care
o Telecom
o Government
o Research
o Education
• You have some compliance requirements, e.g.:
o HIPAA
o PIPEDA
• You have sensitive data, and are required to retain
records.
• Customers expect strong security controls.
• Information security is visible to senior leadership.
• The organization has some remote locations.
• Your organization most likely operates within the
following industries:
o Government
o Research
o Education

Risk tolerant Risk averse
Risk-tolerant organizations embrace the potential of accelerating growth and the
attainment of business objectives by taking calculated risks.
Risk-averse organizations prefer consistent, gradual growth and goal attainment by
embracing a more cautious stance toward risk.
Risk culture is an organization’s attitude towards taking risks. This attitude manifests
itself in two ways:
Be aware of the organization’s
attitude towards risk
One element of risk culture is what levels of risk the organization is willing to accept to pursue its objectives and what levels of risk are deemed
unacceptable. This is often called risk appetite.
Risk conscious Unaware
Risk-conscious organizations place a high priority on being aware of all risks
impacting business objectives, regardless of whether they choose to accept or
respond to those risks.
Organizations that are largely unaware of the impact of risk generally believe there
are few major risks impacting business objectives and choose to invest resources
elsewhere.
The other component of risk culture is the degree to which risk factors into decision making.
Info-Tech Insight
Organizations typically fall in the middle of these spectrums. While risk culture will vary depending on the industry and maturity of the organization, a 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.

Input Output
Assessment
• Risk Culture
• Pain Points and Opportunities
• Goals for the IT risk
management program
Manual
1.2.3 Develop goals for the IT
risk management program
1-4 hours
Translate your maturity assessment and knowledge about organizational risk culture,
potential obstacles, and success factors to develop goals for your IT risk management
program.
Instructions:
1. In the Risk Management Program Manual, revise, replace, or add to the high-level goals
provided in section 2.4.
2. Make sure that you have three to five 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.
Record the results in the Risk Management Program Manual.

Instructions
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 on the next slide as a starting
point.
3. Fill in the chart to indicate the:
a) Name of the success metric
b) Method for measuring success
c) Baseline measurement
d) Target measurement
e) Actual measurements at various points throughout the process of
improving the risk management program
f) A deadline for each metric to meet the target measurement
Specific
Make sure the objective is clear and detailed.
Measurable
Objectives are measurable if there are specific metrics assigned to
measure success. Metrics should be objective.
Actionable
Objectives become actionable when specific initiatives designed to
achieve the objective are identified.
Realistic
Objectives must be achievable given your current resources or
known available resources.
Time-Bound
An objective without a timeline can be put off indefinitely.
Furthermore, measuring success is challenging without a timeline.
Ensure that all success metrics are SMART
1.2.4 Develop SMART project
metrics
1-3 hours
Create metrics for measuring the success of the IT risk management program.

1.2.4 Develop SMART project
metrics (continued)
1-3 hours
Attach metrics to your goals to gauge the success of the IT risk management program.
Name Method Baseline Target Deadline Checkpoint 1 Checkpoint 2 Final
Number of risks identified (per
year)
Risk register 0 100 Dec. 31
Number of business units
represented (risk identification)
Meeting minutes 0 5 Dec. 31
Frequency of risk assessment
Assessments recorded in risk
management program manual
0 2 per year Year 2
Percentage of identified risk
events that undergo expected
cost assessment
Ratio of risks assessed in the
risk costing tool to risks
assessed in the risk register
0 20% Dec. 31
Number of top risks without an
identified risk response
Risk register 5 0 March 1
Cost of risk management
program operations per year
Meeting frequency and duration,
multiplied by the cost of
participation
$2,000 $5,000 Dec. 31
Sample Metrics
Replace the example metrics with accurate KPIs or metrics
for your organization.

Create the IT risk committee (ITRC)
Responsibilities of the ITRC:
1. Formalize risk management processes.
2. Identify and review major risks throughout the IT department.
3. Recommend an appropriate risk appetite or level of exposure.
4. Review the assessment of the impact and likelihood of identified risks.
5. Review the prioritized list of risks.
6. Create a mitigation plan to minimize risk likelihood and impact.
7. Review and communicate overall risk impact and risk management success.
8. Assign risk ownership responsibilities of key risks to ensure key risks are monitored and risk responses are effectively
implemented.
9. Address any concerns in regards to the risk management program, including, but not limited to, reviewing their risk
management duties and resourcing.
10.Communicate risk reports to senior management annually.
11.Make any alterations to the committee roster and the individuals’ responsibilities as needed and document changes.
Must be on the ITRC:
 CIO
 CRO (if applicable)
 Senior Directors
 Security Officer
 Head of Operations
Should be on the ITRC:
CFO
Senior representation from every business unit
impacted by IT risk

Input Output
• Goals for the IT risk
management program
Manual
• CIO
• CRO (if applicable)
• Senior Directors
• Head of Operations
1.2.5 Create the IT risk
council
1-4 hours
Identify the essential individuals from both the IT department and the business to create a
permanent committee that meets regularly and carries out IT risk management activities.
Instructions:
1. Review sections 3.1 (Mandate) and 3.2 (Agenda and Responsibilities) of the IT Risk
Committee Charter, located in the Risk Management Program Manual. Make any
necessary revisions.
2. In section 3.3, document how frequently the council is scheduled to meet.
3. In section 3.4, document members of the IT risk council.
4. Obtain sign-off for the IT risk council from the CIO or another member of the senior
leadership team in section 3.5 of the manual.
Record the results in the Risk Management
Program Manual.

Instructions
1. Use the template provided on the following slide, and add key stakeholders
who do not appear and are relevant for your organization.
2. For each activity, assign each stakeholder a letter.
3. There must be an accountable party for each activity (every activity must
have an “A”).
4. For activities that do not apply to a particular stakeholder, leave the space
blank.
5. Once the chart is complete, copy/paste it into section 4.1 of the Risk
Management Program Manual.
1.2.6 Complete RACI chart
1-3 hours
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:
Stakeholders who undertake the activity.
Stakeholders who are held responsible for failure or
take credit for success.
Stakeholders whose opinions are sought.
Stakeholders who receive updates.
Responsible
Accountable
Consulted
Informed

1.2.6 Complete RACI chart
(continued)
1-3 hours
Assign risk management accountabilities and responsibilities to key stakeholders:
Stakeholder
Coordination
Risk
Identification
Risk
Thresholds
Risk
Assessment
Identify
Responses
Cost-Benefit
Analysis
Monitoring
Risk
Decision
Making
ITRC
ERM
CIO
CRO
CFO
CEO
Business
Units
IT
PMO
Responsible Accountable Consulted Informed
Legend:
A
A A
R
R
C
I
I
I I I I C
R
C C C
A
R
R
R
C
C
C
I
I
I
I
I
I
C C
A
R
A A A
C
R
I
C
C
C
R
I
I
I
I
R R
I
I I I

This phase will walk you through the following
activities:
• Add organization-specific risk scenarios
• Identify risk events
• Augment risk event list using COBIT 2019
processes
• Conduct a PESTLE analysis
• Determine the threshold for (un)acceptable
risk
• Create a financial impact assessment scale
• Select a technique to measure reputational
cost
• Create a likelihood scale
• Assess risk severity level
• Assess expected cost
This phase involves the following participants:
• IT risk council
• Relevant business stakeholders
• Representation from senior management
team
• Business Risk Owners
Phase 2
1.1 Review IT Risk
Risks
3.1 Develop Risk Responses
and Monitor IT Risks

Step 2.1
Identify IT Risks
participants:
• IT Risk Council
• Business risk owners
Activities
• Participation of key stakeholders
• Comprehensive list of IT risk events
2.1.1 Add organization-specific risk scenarios
2.1.2 Identify risk events
2.1.3 Augment risk event list using COBIT 19 processes
2.1.4 Conduct a PESTLE analysis
Step 2.1 Step 2.2

Get to know what you don’t know
Employ Info-Tech’s top-down
approach to risk identification.
Augment your risk event list
using alternative frameworks.
Engage the right stakeholders
in risk identification.
1
2
3
Key metrics:
• Total risks identified
• New risks identified
• Frequency of updates to the Risk Register Tool
• Number of realized risk events not identified in the Risk Register Tool
• Level of business participation in enterprise IT risk identification
o Number of business units represented
o Number of meetings attended in person
o Number of risk reports received
Info-Tech Insight
What you don’t know CAN hurt you. How do you identify IT-related threats and vulnerabilities that you are not already aware of? Now that
you have created a strong risk governance framework that formalizes risk management within IT and connects it to the enterprise, follow
the steps outlined in this section to reveal all of IT’s risks.

Prioritizing and Selecting
Stakeholders
Engage key
stakeholders
Ensure that all key risks are identified by
engaging key business stakeholders.
Benefits of obtaining business involvement during the risk identification stage:
• You will identify risk events you had not considered or you weren’t aware of.
• You will identify risks more accurately.
• Risk identification is an opportunity to raise awareness of IT risk management early in the
process.
Executive Participation:
• CIO participation is integral when building a comprehensive register of risk events impacting
IT.
• CIOs and IT directors possess a holistic view of all of IT’s functions.
• CIOs and IT directors are uniquely placed to identify how IT affects other business units and
the attainment of business objectives. If applicable, CRO and CTO participation is also critical.
1. Reliance on IT services and
technologies to achieve business
objectives.
2. Relationship with IT, and willingness to
engage in risk management activities.
3. Unique perspectives, skills, and
experiences that IT may not possess.
Info-Tech Insight
While IT personnel are better equipped to identify IT risk
than anyone, IT does not always have an 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.

Take a top-down approach to risk identification to guide brainstorming
Enable IT to target risk holistically
Info-Tech’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 n10 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 Category Risk Scenario Risk Event
Compliance
Regulatory compliance Being fined for not complying/being aware of a new regulation.
Externally originated attack Phishing attack on the organization.
Operational
Technology evaluation & selection Partnering with a vendor that is not in compliance with a key regulation.
Capacity planning Not having sufficient resources to support a DRP.
Third-Party Risk
Vendor management Vendor performance requirements are improperly defined.
Vendor selection Vendors are improperly selected to meet the defined use case.
Risk Category: High-
level groupings that
describe risk pertaining
to major IT functions.
See the following slide
for all ten of Info-Tech’s
IT risk categories.
Risk Scenario: An abstract profile representing common
risk groups that are more specific than risk categories.
Typically, organizations are able to identify two to five
scenarios for each category.
Risk Event: Specific threats and vulnerabilities that fall under a particular
risk scenario. Organizations are able to identify anywhere between 1 and 20
events for each scenario. See the Appendix of the Risk Management
Program Manual for a list of risk event examples.

2.1.1 Add organization-
specific risk scenarios
1-3 hours
Review Info-Tech’s ten IT risk categories and add risk scenarios to the examples provided.
IT Reputational IT Financial IT Strategic Operational Availability
• Negative PR
• Consumers writing
negative reviews
• Employees writing
negative reviews
• Stock prices drop
• Value of the organization is
reduced
• Organization prioritizes
innovation but remains
focused on operational
• Unable to access data to
support strategic initiative
• Enterprise architecture
• Technology evaluation and
selection
• Capacity planning
• Operational errors
• Power outage
• Increased data workload
• Single source of truth
• Lacking knowledge
transfer processes for
critical tasks
Performance Compliance Security Third Party Digital
• Network failure
• Service levels not being
met
• Capacity overload
• Regulatory compliance
• Standards compliance
• Audit compliance
• Malware
• Internally originated attack
• Vendor selection
• Vendor management
• Contract termination
• No back-up process if
automation fails

Input Output
• IT risk categories • Risk events identified and
categorized
• Risk Register Tool • IT risk council
• Relevant business
stakeholders
• Representation from senior
management team
• CRO (if applicable)
2.1.2 Identify risk events
1-4 hours
Use Info-Tech’s IT risk categories and scenarios to brainstorm a comprehensive list of IT-related
threats and vulnerabilities impacting your organization.
Instructions:
1. Document risk events in the Risk Register Tool.
2. List risk scenarios (organized by risk category) in the Risk Events/Threats column.
3. 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.
4. Attack one scenario at a time, exhausting all realistic risk events for that grouping before
moving onto the next scenario. Each scenario should take approximately 45-60 minutes.
Tip: If disagreement arises regarding whether a specific risk event is relevant to the organization or
not and it cannot be resolved quickly, include it in the list. The applicability of these risks will
become apparent during the assessment process.
Record the results in the Risk Register Tool.

Instructions
1. Review COBIT 2019’s 40 IT
processes and identify additional
risk events.
2. Match risk events to the
corresponding risk category and
scenario and add them to the Risk
Register Tool.
2.1.3 Augment the risk event list
using COBIT 2019 processes (Optional)
1-3 hours
Other industry-leading frameworks provide alternative ways of conceptualizing the
functions and responsibilities of IT and may help you uncover additional risk events.
1. Managed IT Management Framework
2. Managed Strategy
3. Managed Enterprise Architecture
4. Managed Innovation
5. Managed Portfolio
6. Managed Budget and Costs
7. Managed Human Resources
8. Managed Relationships
9. Managed Service Agreements
10. Managed Vendors
11. Managed Quality
12. Managed Risk
13. Managed Security
14. Managed Data
15. Managed Programs
16. Managed Requirements Definition
17. Managed Solutions Identification and Build
18. Managed Availability and Capacity
19. Managed Organizational Change Enablement
20. Managed IT Changes
21. Managed IT Change Acceptance and Transitioning
22. Managed Knowledge
23. Managed Assets
24. Managed Configuration
25. Managed Projects
26. Managed Operations
27. Managed Service Requests and Incidents
28. Managed Problems
29. Managed Continuity
30. Managed Security Services
31. Managed Business Process Controls
32. Managed Performance and Conformance Monitoring
33. Managed System of Internal Control
34. Managed Compliance with External Requirements
35. Managed Assurance
36. Ensured Governance Framework Setting and Maintenance
37. Ensured Benefits Delivery
38. Ensured Risk Optimization
39. Ensured Resource Optimization
40. Ensured Stakeholder Engagement

2.1.4 Finalize your risk register by
conducting a PESTLE analysis (Optional)
1-3 hours
Explore alternative identification techniques to incorporate external factors and avoid
“groupthink.”
Avoid “Groupthink” – Nominal Group Technique
The Nominal Group Technique uses the silent generation of ideas and an enforced
“safe” period of time where ideas are shared but not discussed to encourage
judgement-free idea generation.
• Ideas are generated silently and independently.
• Ideas are then shared and documented; however, discussion is delayed until all
of the group’s ideas have been recorded.
• Idea generation can occur before the meeting and be kept anonymous.
Consider the External Environment – PESTLE Analysis
Despite efforts to encourage equal participation in the risk identification
process, key risks may not have been shared in previous exercises.
Conduct a PESTLE analysis as a final safety net to ensure that all key risk
events have been identified.
List the following factors influencing the risk event:
• Political factors
• Economic factors
• Social factors
• Technological factors
• Legal factors
• Environmental factors
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.

Step 2.2
Assess and Prioritize IT Risks
participants:
• IT risk council
team
Activities
• Business-approved thresholds for
unacceptable risk
• Completed Risk Register Tool with risks
prioritized according to severity
• Expected cost calculations for high-
priority risks
2.2.1 Determine the threshold for (un)acceptable risk
2.2.2 Create a financial impact assessment scale
2.2.3 Select a technique to measure reputational cost
2.2.4 Create a likelihood scale
2.2.5 Risk severity level assessment
2.2.6 Expected cost assessment
Step 2.1 Step 2.2

Frequency of IT risk assessments
(Annually, bi-annually, etc.)
Assessment accuracy
Percentage of risk assessments that are substantiated by later occurrences or testing
Ratio of cumulative actual costs to expected costs
Assessment consistency
Percentage of risk assessments that are substantiated by third-party audit
Assessment rigor
Percentage of identified risk events that undergo first-level assessment (severity scores)
Percentage of identified risk events that undergo second-level assessment (expected cost)
Stakeholder oversight and participation
Level of executive participation in IT risk assessment (attend in person, receive report, etc.)
Number of business stakeholder reviews per risk assessment
Reveal the organization’s greatest
IT threats and vulnerabilities
Conduct a streamlined
assessment of all risks to
separate acceptable and
unacceptable risks.
Perform a deeper, cost-based
assessment of prioritized risks.
Establish business-approved
risk thresholds for acceptable
and unacceptable risk.
1
2
3
Key metrics:
Info-Tech Insight
Risk is money. It’s impossible to make intelligent decisions about risks without knowing what their financial impact will be.

Risk assessment provides you with the raw materials to conduct an informed cost-
benefit analysis and make robust risk response decisions.
Review risk assessment
fundamentals
In this section, you will be prioritizing your IT risks according to their risk severity, which is a reflection of their expected cost.
e.g. $250,000 or “High”
Calibrated by how likely the risk
is to occur:
=
Likelihood
of Risk
Impact
How much you expect a risk event to
cost if it were to occur:
X
Likelihood of
Risk
Occurrence
e.g. 10% or “Low”
Calculating risk severity
Produces a dollar value or
“severity level” for comparing
risks:
Risk
Severity
e.g. $25,000 or “Medium” CBA
Risk Tolerance
Risk Response
Cost-benefit analysis
Which must be evaluated against
thresholds for acceptable risk
and the cost of risk responses.

Maintain the engagement of key
stakeholders in the risk assessment process
Verify the Risk Impact and
Assessment
If IT has ranked risk events appropriately, the
business will be more likely to offer their input.
Share impact and likelihood values for key
risks to see if they agree with the calculated
risk severity scores.
Identify Where the Business
Focuses Attention
While verifying, pay attention to the risk events that
the business stresses as key risks. Keep these risks
in mind when prioritizing risk responses as they are
more likely to receive funding.
Try to communicate the assessments of these risk
events in terms of expected cost to attract the
attention of business leaders.
Engage the Business During
Assessment Process
Asking business stakeholders to make significant
contributions to the assessment exercise may be
unrealistic (particularly for members of the senior
leadership team, other than the CIO).
Ensure that they work with you to finalize
thresholds for acceptable or unacceptable risk.
1 2 3
Info-Tech Insight
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.

Review the two levels of risk assessment offered in this blueprint.
Info-Tech recommends a two-level
approach to risk assessment
Assess all of your identified risk events with a risk severity-level assessment.
• By creating a likelihood and impact assessment scale divided into three to nine “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 likelihood 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.
Risk severity level assessment (mandatory)
1
Number of risks:
Assess all risk events
identified in Phase 1.
Units of measurement:
Use customized likelihood
and impact “levels.”
Time required: One to five
minutes per risk event.
Assess Likelihood Assess Impact Output
Information
Negligible
Low
Moderate
High
Very High
X =
Risk Severity Level:
Negligible
Low
Moderate
High
Very High
Chart risk events according to risk
severity as this allows you to organize
and prioritize IT risks.
Moderate

Expected cost assessment (optional)
Info-Tech recommends a two-level
approach to risk assessment (continued)
Conduct expected cost assessments for IT’s greatest risks.
For risk events warranting further analysis, translate risk severity levels into hard expected-cost numbers.
2
Number of risks:
Only assess high-priority risks
revealed by severity-level
assessment.
Units of measurement:
Use actual likelihood values (%)
and impact costs ($).
Time required: 10-20 minutes
per risk event.
Assess Likelihood Assess Impact Output
Information
Moderate
X =
Expected Cost:
High
Expected cost is useful for conducting
cost-benefit analysis and comparing
IT risks to non-IT risks and other
budget priorities for the business.
15% $100,000 $15,000
Why conduct expected cost assessments?
• Expected cost represents how much you would expect to pay in an average
year for each risk event.
• Communicate risk priorities to the business in language they can understand.
• While risk severity levels are useful for comparing one IT risk to another,
expected cost data allows the business to compare IT risks to non-IT risks
that may not use the same scales.
Why is expected cost assessment optional?
• Determining robust likelihood values and precise impact estimates can be
challenging and time consuming.
• Some risk events may require extensive data gathering and industry analysis.

Implement
and leverage
a centralized
risk register
The purpose of the risk
register is to act as the
repository for all the risks that
have been identified within
your environment.
Use this tool to:
1. Collect and maintain a repository for all IT risk events impacting the organization and
relevant information for each risk.
• Capture all relevant IT risk information in one location.
• Organize risk identification and assessment 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.

Input Output
• Risk events
• Risk appetite
• Threshold for risk identified
• Risk Register Tool
Manual
• IT risk council
stakeholders
management team
• Business risk owner
2.2.1 Determine the threshold
for (un)acceptable risk
1-4 hours
Instructions:
There are times when the business needs to know about IT risks with high expected costs.
1. Create an expected cost threshold that defines what constitutes an acceptable and
unacceptable risk for the organization. This figure should be a concrete dollar value. In the
next exercises, you will build risk impact and likelihood scales with this value in mind, ensuring
that “high” or “extreme” risks are immediately communicated to senior leadership.
2. Do not consider IT budget restrictions when developing this number. The acceptable risk
threshold should reflect the business’ tolerance/appetite for risk.
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 Manual

Input Output
• Risk events
• Risk threshold
• Financial impact scale created
• Risk Register Tool
Manual
• IT risk council
stakeholders
management team
2.2.2 Create a financial impact
assessment scale
1-4 hours
Instructions:
1. Create a scale to assess the financial impact of risk events.
• Typically, risk impacts are assessed on a scale of 1-5; however, some organizations
may prefer to assess risks using 3, 4, 7, or 9-point scales.
2. Ensure that the unacceptable risk threshold is reflected in the scale.
• In the example provided, the unacceptable risk threshold ($100,000) is represented as
“High” on the impact scale.
3. Attach labels to each point on the scale. Effective labels will easily distinguish between risks
on either side of the unacceptable risk threshold.
Record the risk impact scale in section 5.3 of the Risk Management Program
Manual

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 Time (days)
Number of
employees
Average cost
per employee
(per day)
Estimated cost
20 days 8 $300 $48,000
Service Time (hours)
Lost revenue
(per hour)
Estimated cost Impact scale
4 hours $10,000 $40,000 Low
$100,000 High
Extreme
Moderate
Low
Negligible
$10,000
$35,000
$250,000
$60,000

2.2.3 Select a technique to measure
reputational cost (1 of 3)
1-3 hours
Realized risk events may have profound reputational costs that do not immediately
impact your bottom line.
Technique #1 – Use financial indicators:
For-profit companies typically experience reputational loss as a gradual decline in
the strength of their brand, exclusion from industry groups, or lost revenue.
If possible, use these measures to put a price on reputational loss:
• Lost revenue attributable to reputation loss
• Loss of market share attributable to reputation loss
• Drops in share price attributable to reputation loss (for public companies)
Match this dollar value to the corresponding level on the impact scale created in
Activity 2.2.2.
• If you are not able to effectively translate all reputational costs into financial
costs, proceed to techniques 2 and 3 on the following slides.
Reputational cost can take several forms, including the internal and
external perception of:
1. Brand likeability
2. Product quality
3. Leadership capability
4. Social responsibility
Based on your industry and the nature of the risk, select one of the three
techniques described in this section to incorporate reputational costs into
your risk assessment.

1-3 hours
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:
• Loss of organizational trust in IT
• IT’s reputation as a value provider to the organization is tarnished
• Loss of client trust in the organization
• 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.
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 the confidence and/or support
of the public.
• A helpful technique is to reframe how reputation is assigned
value.

1-3 hours
Technique #3 – Create a parallel scale for reputational impact:
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 dimensions:
• Internal vs. External
• Low Amplification vs. High Amplification
Internal/External: The further outside of the organization that the risk 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 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.
• For example, if the media learns about a recent data breach, does that feel like a $100,000
loss?
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.
High
Extreme
Moderate
Low
Negligible
Internal, Low Amp.
(IT)
Internal, High Amp.
(CEO)
External, High Amp.
(regulators, lawsuits)
Example:

2.2.4 Create a likelihood scale
1-3 hours
Instructions:
1. Create a scale to assess the likelihood that a risk event will occur over a given period of time.
• Info-Tech recommends assessing the likelihood 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).
2. Ensure that the likelihood scale contains the same number of levels as the financial impact
scale (3, 4, 5, 7, or 9).
3. The example provided is likely to satisfy most IT departments; however, you may customize the
distribution of likelihood values to reflect the organization’s aversion towards uncertainty.
• For example, an extremely risk-averse organization may consider any risk event with a
likelihood greater than 20% to have a “High” likelihood of occurrence.
4. Attach the same labels used for the financial impact scale (Low, Moderate, High, etc.)
1–19%
20–39%
40–59%
60–79%
80–99%
Negligible
Low
Moderate
High
Extreme
Info-Tech Insight
Note: Info-Tech endorses the use of likelihood values (1-99%) rather than frequency (3 times per year) as a measurement.
For an explanation of why likelihood values lead to more precise and robust risk assessment, see the Appendix.
Record the risk impact scale in section 5.3 of the Risk Management Program Manual

Input Output
• Risk events identified • Assessed the likelihood
of occurrence and
impact for all identified
risk events
• Risk Register Tool • IT risk council
stakeholders
• Representation from
senior management
team
2.2.5 Risk severity level
assessment
6-10 hours
Instructions:
1. Document the “Risk Category” and “Existing Controls.” in the Risk Register Tool.
• (See the slide following this activity for tips on identifying existing controls.)
2. Assign each risk event a likelihood and impact level.
• Remember, you are assessing the impact that a risk event will have on the organization as a whole,
not just on IT.
3. When assigning a financial impact level to a risk event, factor in the likely 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 that typically occur a few times each year, assign
them an impact level that reflects the likelihood of financial impact the risk event will have over the
entire year.
• 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.
Record results in the Risk Register Tool

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

Consider how IT is already addressing key risks.
Types of current risk control
Identify current risk controls
Consider both tactical and strategic controls already in place when filling out risk event information in the
Risk Register Tool.
Tactical controls
Apply to individual risks only.
Example: A tactical control for
backup/replication failure is faster
WAN lines.
Strategic controls
Apply to multiple risks.
Example: A strategic control for
backup/replication failure is
implementing formal DR plans.
Tactical
risk
control
Risk event
Strategic
risk control
Risk event
Risk event
Info-Tech 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, or where new
strategies are needed, to reduce risk severity
levels below business thresholds.

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
Risk ownership means that an individual is responsible for the following activities:
• Monitoring the threat or vulnerability for changes in the likelihood of occurrence
and/or likely impact.
• Monitoring changes in the market and external environment that may alter the
severity of the risk event.
• Monitoring changes of closely related risks with interdependencies.
• Developing and using key risk indicators (KRIs) to measure changes in risk severity.
• Regularly reporting changes in risk severity to the IT risk council.
• 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.
Selecting the Appropriate Risk Owner
Use the following considerations to determine the best owner for each risk:
• The risk owner should be familiar with the process, project, or IT function
related to the risk event.
• The risk owner should have access to the necessary data to monitor and
measure the severity of the risk event.
• The risk owner’s performance assessment should reflect their ability to
demonstrate the ongoing management of their assigned risk events.

Use Info-
Tech’s Risk
Costing Tool
to calculate
the expected
cost of IT’s
high-priority
risks
(optional)
1. Conduct a deeper analysis of severe risks.
• Determine specific likelihood and financial impact values to communicate the severity of the
risk in the Expected Cost tab.
• Identify the maximum financial impact that the risk event may inflict.
2. Assess the effectiveness of multiple risk responses for each risk event.
• Determine how proposed risk events will change the likelihood of occurrence and financial
impact of the risk event.
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.
Use this tool to:

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

2.2.6 Expected cost assessment (continued)
Instructions:
1. Go through the list of prioritized risks in the Risk Costing Tool one by one. Indicate the likelihood and impact
level (from the Risk Register Tool) for the risk event being assessed.
2. Record likelihood values (1-99%) and impact values ($) from participants.
• Only record values from individuals that indicate they are fairly confident with their estimates.
• Keep likelihood estimates to values that are multiples of five.
3. Estimate and record the maximum impact that the risk event could inflict.
• See Appendix III for information on how the possibility of high-impact scenarios may influence your
decision making.
4. Discuss the estimates provided. Eliminate outliers and retracted estimates.
• If you are unable to achieve consensus, take the average of the values provided.
5. If you are having difficulty arriving at a likelihood or impact value, select the median value of the level
assigned to the risk during the risk severity level assessment.
• E.g. Risk event assigned to likelihood level “Moderate” (20-39%). Select a likelihood value of 30%.
Who should participate?
• Depending on the size of your IT risk council,
you may want to consider conducting this
exercise in a smaller group.
• Ideally, you should try to find the right balance
between ensuring that the necessary
experience and knowledge is in the room while
insulating the exercise from outlier opinions,
noise, and distractions.
Assign likelihood and financial impact values to high-priority risks.

Justifying Your Estimates:
Evaluate likelihood and impact
Refine your risk assessment process by developing more accurate measurements of
likelihood and impact.
Intersubjective likelihood
The goal of the expected cost assessment is to develop robust intersubjective estimates of
likelihood and financial impact.
By aggregating a number of expert opinions of what they deem to be the “correct” value, you will
arrive at a collectively determined value that better reflects reality than an individual opinion.
Example: The Delphi Method
The Delphi Method is a common technique to produce a judgement that is representative of the
collective opinion of a group.
• Participants are sent a series of sequential questionnaires (typically by email).
• The first questionnaire asks them what the likelihood, likely impact, and expected cost is for a
specific risk event.
• Data from the questionnaire is compiled and then communicated in a subsequent
questionnaire, which encourages participants to restate or revise their estimates given the
group’s judgements.
• With each successive questionnaire, responses will typically converge around a single
intersubjective value.
When asked to explain the numbers you arrived at during the risk assessment,
pointing to an assessment methodology gives greater credibility to your estimates.
• Assign one individual to take notes during the assessment exercise.
• Have them document the main rationale behind each value and the level of
consensus.
Info-Tech Insight
The underlying assumption behind intersubjective forecasting is
that group judgements are more accurate than individual
judgements. However, this may not be the case at all.
Sometimes, a single expert opinion is more valuable than many
uninformed opinions. Defining whose opinion is valuable and
whose is not is an unpleasant exercise; therefore, selecting the
right personnel to participate in the exercise is crucially
important.

This phase will walk you through the following
activities:
• Develop key risk indicators (KRIs) and
escalation protocols
• Establish the reporting schedule
• Identify and assess risk responses
• Analyze risk response cost-benefit
• Create multi-year cost projections
• Obtain executive approval for risk action
plans
• Socialize the Risk Report
• Transfer ownership of risk responses to
project managers
• Finalize the Risk Management Program
Manual
This phase involves the following participants:
• IT risk council
team
• Risk business owner
Phase 3
Monitor, Respond, and Report on IT Risk
1.1 Review IT Risk
Risks
3.1 Monitor IT Risks and
Develop Risk Responses

Step 3.1
Monitor IT Risks and Develop Risk Responses
participants:
• IT risk council
team
Activities
• Completed risk event action plans
• Risk responses identified and assessed
for top risks
• Risk response selected for top risks
3.1.1 Develop key risk indicators (KRIs) and escalation protocols
3.1.2 Establish the reporting schedule
3.1.3 Identify and assess risk responses
3.1.4 Risk response cost-benefit analysis
3.1.5 Create multi-year cost projections
Step 3.1 Step 3.2

Use Info-
Tech’s Risk
Event Action
Plan to
manage
high-priority
risks
Risk Event
Action Plan
Obtaining sign-off from the senior leadership team or from the ERM office is an important step of
the risk management process. The Risk Event Action Plan ensures that high-priority risks are closely
monitored and that changes in risk severity are detected and reported.
Clear documentation is a way to ensure that critical information is shared with management so that
they can make informed risk decisions. These reports should be succinct yet comprehensive;
depending on time and resources, it is good practice to fill out this form and obtain sign-off for the
majority of IT risks.
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.

3.1.1 Develop key risk indicators
(KRIs) and escalation protocols
The risk owner should be held accountable for monitoring their assigned risks
but may delegate responsibility for these tasks.
Instructions:
1. Design key risk indicators (KRIs) for risks that measure changes in their
severity and document them in the Risk Event Action Plan.
• See the following slide for examples.
2. Clearly document the risk owner and the individual(s) carrying out risk
monitoring activities (delegates) in the Risk Event Action Plan.
Note: Examples of KRIs can be found on the following slide.
What are KRIs?
• KRIs should be observable metrics that alert the IT risk council
and management when risk severity exceeds acceptable risk
thresholds.
• KRIs should serve as tripwires or early-warning indicators that
trigger further actions to be taken on the risk.
• Further actions may include:
o Escalation to the risk owner (if delegated) or to a
member of the senior leadership team.
o Reporting to the IT risk council or IT steering committee.
o Reassessment.
o Updating the risk monitoring schedule.
Document KRIs, escalation thresholds, and escalation protocols for each risk
in a Risk Event Action Plan.

Developing KRIs for success
Intermediate Step
Intermediate Step
Risk Event
KRI Measurement KRI Measurement
Examples of KRIs
• Number of resources who quit or were fired who had access to
critical data
• Number of risk mitigation initiatives unfunded
• Changes in time horizon of mitigation implementation
• Number of employees who did not report phishing attempts
• Amount of time required to get critical operations access to
necessary data
• Number of days it takes to implement a new regulation or
compliance control

3.1.2 Establish 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 constantly evolving.
Reporting Risk Event
Weekly reports to ITRC
Bi-weekly reports to ITRC
Monthly reports to ITRC
Report to ITRC only if KRI thresholds triggered
No reports; reassessed bi-annually
High
Extreme
Moderate
Low
Negligible

Use Info-Tech’s tools to identify, analyze,
and select risk responses
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 one and four risk response options for each risk.
o Develop precise values for residual likelihood and impact.
o Compare expected cost of the risk event to expected residual cost.
o Select the risk response to recommend to senior leadership and document it in the Risk Register Tool.
[Optional]
Risk Costing Tool
1
• Develop risk responses for all risk events pre-populated on the “2. Risk Register” 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 likelihood and impact
of the risk (Activity 3.1.5).
• The tool will calculate the residual severity of the risk after applying the risk response.
[Mandatory]
Tool Information
Risk Register Tool
Tool Information

Use the “Five Whys” methodology to identify the root cause and
contributing/exacerbating factors for each risk event.
Diagnosing the root cause of a risk as well as the environmental factors that
increase its potential impact and likelihood of occurring allow you to identify
more effective risk responses.
Risk responses that only address the symptoms of the risk are less likely to
succeed than responses that address the core issue.
Determine the root
cause of IT risks
Root cause analysis
Root
Cause
Root
Cause
Network congestion
Risk event:
Network outage
Inadequate bandwidth for latency-sensitive
applications
Increased business use of latency-sensitive
applications
Business units rely on “real-time” data gathered
from latency-sensitive applications
Why?
Why?
Why?
Why?
The Five Whys Methodology
Symptom
Contributing
Factors
Why?

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

3.1.3 Identify and assess risk
responses
Instructions:
Complete the following steps for each risk event.
1. Identify a risk response action that will help reduce the likelihood of occurrence or the
impact if the event were to occur.
• Indicate the type of risk response (avoidance, mitigation, transfer, acceptance, or
no risk exists).
2. Assign each risk response action a residual likelihood level and a residual impact
level.
• This is the same step performed in Activity 2.2.6, when initial likelihood and
impact levels were determined; however, now you are estimating the likelihood
and impact of the risk event after the risk response action has been implemented
successfully.
• 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.
Document the following in the Risk Event Action Plan for each risk
event:
• Risk response actions
• Residual likelihood and impact levels
• Residual risk severity level
• Review the following slides about the four types of risk response
to help complete the activity.
1. Avoidance
2. Mitigation
3. Transfer
4. Acceptance
Record the results in the Risk Event Action Plan.

Take actions to avoid
the risk entirely
Risk Avoidance
• Risk avoidance involves taking evasive maneuvers to avoid the risk event.
• Risk avoidance targets risk likelihood, decreasing the likelihood of the risk event
occurring.
• Since risk avoidance measures are fairly drastic, the likelihood is often reduced to
negligible levels.
• However, risk avoidance response actions often sacrifice potential benefits 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
Example 2
However, some risk responses will have a greater
effect on decreasing the likelihood of a risk event
with little effect on decreasing impact.
Example
Mitigation: Create policies that restrict which
personnel can access sensitive data on mobile
devices.
• This mitigation decreases the number of
corporate phones that have access to (or are
storing) sensitive data, thereby decreasing the
likelihood that a device is compromised.
Example 3
Others will reduce the potential impact without
decreasing its likelihood of occurring.
Example
Mitigation: Use robust encryption for all sensitive
data.
• Corporate-issued mobile phones are just as
likely to fall into the hands of nefarious actors,
but the financial impact they can inflict on the
organization is greatly reduced.
Example 1
Most risk responses will reduce both the likelihood of
the risk event occurring and its potential impact.
Example
Mitigation: Purchase and implement enterprise
mobility management (EMM) software with remote
wipe capability.
• EMM reduces the likelihood that sensitive data is
accessed by a nefarious actor.
• The remote-wipe capability reduces the impact
by closing the window that sensitive data can be
accessed from.
• Risk mitigation actions are risk responses that reduce the likelihood and impact of the risk event.
• Risk mitigation actions can be to either implement new controls or enhance existing ones.
Risk Mitigation

ProcessImprovement
Key processes that would most directly improve the risk profile:
• Change Management
• Project Management
• Vendor Management
Personnel
• Greater staff depth in key areas
• Increased discipline around documentation
• Knowledge Management
• Training
Pursue projects that reduce the likelihood
or impact of the risk event (continued)
Use the following IT functions to guide your selection of risk mitigation actions:
InfrastructureManagement
• Disaster Recovery Plan/Business Continuity Plan
• Redundancy and Resilience
• Preventative Maintenance
• Physical Environment Security
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

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

Risk Acceptance
Accept risks that fall below
established thresholds
Accepting a risk means
tolerating the
expected cost of a risk
event. It is a
to retain the
threat.
You may choose to accept a risk event for one of the following three 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.
Info-Tech Insight
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.

3.1.4 Risk response cost-benefit
analysis (optional)
Instructions:
1. Reopen the Risk Costing Tool. For each risk that you 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 one and four 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.
Record the results in the Risk Costing Tool.
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.
The purpose of a cost-benefit analysis (CBA) is to guide financial decision making.

3.1.4 Risk response cost-benefit
analysis (continued)
Instructions:
4. Estimate residual risk likelihood and financial impact for Year 1 with the risk response in place.
• Rather than estimating the likelihood level (low, medium, high), determine a precise likelihood 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 purpose of a cost-benefit analysis (CBA) is to guide financial decision making.
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.5 to build multi-year cost projections for risk responses.
The tool will calculate the expected residual cost of the risk event:
(Financial Impact x Likelihood) - Costs = Expected Residual Cost

3.1.5 Create multi-year cost
projections (optional)
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 and paste the graphs into the Risk Report and the Risk Event Action Plan for the risk
event. Record the results in the Risk Costing Tool.
• 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.
Select between risk response options by projecting their costs and benefits over
multiple years.

Step 3.2
Report IT Risk Priorities
participants:
• IT risk council
team
Activities
• Obtained approval for risk action plans
• Communicated IT’s risk
recommendations to senior leadership
• Embedded risk management into day-to-
day IT operations
3.2.1 Obtain executive approval for risk action plans
3.2.2 Socialize the Risk Report
3.2.3 Transfer ownership of risk responses to project managers
3.2.4 Finalize the Risk Management Program Manual
Step 3.1 Step 3.2

Communicate IT risk
management in two directions:
(and ERM
if applicable)
(embedding risk awareness)
Effectively deliver IT
risk expertise to the
business
Senior Leadership
IT Personnel
Create a strong paper trail and obtain sign-off for the ITRC’s
recommendations.
Now that you have collected all of the necessary raw data, you must communicate your insights and
recommendations effectively.
A fundamental task of risk management is communicating risk information to senior management. It is
your responsibility to enable them to make informed risk decisions. This can be considered upward
communication.
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:
1. Fostering a risk-aware IT culture.
2. Ensuring that the IT risk management program maintains momentum and runs effectively.

01-Build-an-IT-Risk-Management-Program--Phases-1-3.pptx

01-Build-an-IT-Risk-Management-Program--Phases-1-3.pptx

Recommended

Recommended

More Related Content

Similar to 01-Build-an-IT-Risk-Management-Program--Phases-1-3.pptx

Similar to 01-Build-an-IT-Risk-Management-Program--Phases-1-3.pptx (20)

Recently uploaded

Recently uploaded (20)

01-Build-an-IT-Risk-Management-Program--Phases-1-3.pptx