Get Instant Access
to This Blueprint

Cio icon

Build an IT Risk Management Program

Mitigate the IT risks that could negatively impact your organization.

  • 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.

Our Advice

Critical Insight

  • IT risk is business risk. Every IT risk has business implications. Create an IT risk management program that shares accountability with the business.

Impact and Result

  • 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 IT risks most critical to the organization.

Build an IT Risk Management Program Research & Tools

1. Build an IT Risk Management Program – A holistic approach to managing IT risks within your organization and involving key business stakeholders.

Gain business buy-in to understanding the key IT risks that could negatively impact the organization and create an IT risk management program to properly identify, assess, respond, monitor, and report on those risks.

2. Risk Management Program Manual – A single source of truth for the risk management program to exist and be updated to reflect changes.

Leverage this Risk Management Program Manual to ensure that the decisions around how IT risks will be governed and managed can be documented in a single source accessible by those involved.

3. Risk Register & Risk Costing Tool – A set of tools to document identified risk events. Assess each risk event and consider the appropriate response based on your organization’s threshold for risk.

Engage these tools in your organization if you do not currently have a GRC tool to document risk events as they relate to the IT function. Consider the best risk response to high severity risk events to ensure all possible situations are considered.

4. Risk Event Action Plan and Risk Report – A template to document the chosen risk responses and ensure accountable owners agree on selected response method.

Establish clear guidelines and responses to risk events that will leave your organization vulnerable to unwanted threats. Ensure risk owners have agreed to the risk responses and are willing to take accountability for that response.


Member Testimonials

After each Info-Tech experience, we ask our members to quantify the real-time savings, monetary impact, and project improvements our research helped them achieve. See our top member experiences for this blueprint and what our clients have to say.

9.5/10


Overall Impact

$69,299


Average $ Saved

13


Average Days Saved

Client

Experience

Impact

$ Saved

Days Saved

MassMutual

Guided Implementation

10/10

$69,299

16

Fernco Inc

Workshop

9/10

N/A

10

Massey University

Workshop

3/10

N/A

N/A

Desert Lime Ltd

Guided Implementation

9/10

$20,500

23

The University of Alabama at Birmingham

Guided Implementation

10/10

$2,479

5

The Government of the Northwest Territories

Workshop

10/10

$22,000

50

University of Exeter

Guided Implementation

9/10

N/A

N/A

City of Carlsbad

Workshop

10/10

N/A

20

Integris Credit Union

Guided Implementation

9/10

$10,000

10

Dropbox

Guided Implementation

8/10

N/A

5

Pegasus Business Intelligence, LP d/b/a Onyx CenterSource

Guided Implementation

10/10

N/A

N/A

UMG RECORDINGS, INC.

Guided Implementation

10/10

N/A

N/A

AARP Inc

Guided Implementation

10/10

N/A

N/A

Fernco Inc

Workshop

10/10

$30,999

20

RPC Inc.

Guided Implementation

10/10

$2,546

10

CFA Institute

Guided Implementation

8/10

N/A

N/A

Central Bank of Trinidad & Tobago

Guided Implementation

9/10

N/A

N/A

Kentucky Housing Corporation

Guided Implementation

10/10

$1,782

5

Trinidad and Tobago Unit Trust Corporation

Guided Implementation

10/10

$3,820

20


Risk Management

"Hope" is not a risk management strategy.
This course makes up part of the Security & Risk Certificate.

Now Playing: Academy: Risk Management | Executive Brief

An active membership is required to access Info-Tech Academy
  • Course Modules: 4
  • Estimated Completion Time: 2-2.5 hours
  • Featured Analysts:
  • David Yackness, Sr. Research Director, CIO Practice
  • Gord Harrison, SVP of Research and Advisory

Workshop: Build an IT Risk Management Program

Workshops offer an easy way to accelerate your project. If you are unable to do the project yourself, and a Guided Implementation isn't enough, we offer low-cost delivery of our project workshops. We take you through every phase of your project and ensure that you have a roadmap in place to complete your project successfully.

Module 1: Review IT Risk Fundamentals and Governance

The Purpose

  • To assess current risk management maturity, develop goals, and establish IT risk governance.

Key Benefits Achieved

  • Identified obstacles to effective IT risk management.
  • Established attainable goals to increase maturity.
  • Clearly laid out risk management accountabilities and responsibilities for IT and business stakeholders.

Activities

Outputs

1.1

Assess current program maturity

  • Maturity Assessment
1.2

Complete RACI chart

  • Risk Management Program Manual
1.3

Create the IT risk council

1.4

Identify and engage key stakeholders

1.5

Add organization-specific risk scenarios

  • Risk Register
1.6

Identify risk events

Module 2: Identify IT Risks

The Purpose

  • Identify and assess all IT risks.

Key Benefits Achieved

  • Created a comprehensive list of all IT risk events.
  • Risk events prioritized according to risk severity – as defined by the business.

Activities

Outputs

2.1

Identify risk events (continued)

  • Finalized List of IT Risk Events
2.2

Augment risk event list using COBIT 5 processes

  • Risk Register
2.3

Determine the threshold for (un)acceptable risk

  • Risk Management Program Manual
2.4

Create impact and probability scales

2.5

Select a technique to measure reputational cost

2.6

Conduct risk severity level assessment

Module 3: Identify IT Risks (continued)

The Purpose

  • Prioritize risks, establish monitoring responsibilities, and develop risk responses for top risks.

Key Benefits Achieved

  • Risk monitoring responsibilities are established.
  • Risk response strategies have been identified for all key risks.

Activities

Outputs

3.1

Conduct risk severity level assessment

  • Risk Register
3.2

Document the proximity of the risk event

  • Risk Management Program Manual
3.3

Conduct expected cost assessment

3.4

Develop key risk indicators (KRIs) and escalation protocols

3.5

Root cause analysis

3.6

Identify and assess risk responses

  • Risk Event Action Plans

Module 4: Monitor, Report, and Respond to IT Risk

The Purpose

  • Assess and select risk responses for top risks and effectively communicate recommendations and priorities to the business.

Key Benefits Achieved

  • Thorough analysis has been conducted on the value and effectiveness of risk responses for high severity risk events.
  • Authoritative risk response recommendations can be made to senior leadership.
  • A finalized Risk Management Program Manual is ready for distribution to key stakeholders.

Activities

Outputs

4.1

Identify and assess risk responses

  • Risk Report
4.2

Risk response cost-benefit analysis

4.3

Create multi-year cost projections

4.4

Review techniques for embedding risk management in IT

  • Risk Management Program Manual
4.5

Finalize the Risk Report and Risk Management Program Manual

4.6

Transfer ownership of risk responses to project managers


Build an IT Risk Management Program

Mitigate the IT risks that could negatively impact your organization.

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

Build an IT Risk Management Program

Mitigate the IT risks that could negatively impact your organization.

EXECUTIVE BRIEF

Analyst Perspective

Siloed risks are risky business for any enterprise.

Photo of Valence Howden, Principal Research Director, CIO Practice.
Valence Howden
Principal Research Director, CIO Practice
Photo of Brittany Lutes, Senior Research Analyst, CIO Practice.
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.

Executive Summary

Your Challenge

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.

Common Obstacles

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.

Info-Tech’s Approach

  • 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.

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.

58% of organizations still lack a systematic and robust method to actually report on risks (Source: AICPA, 2021)

Data is an invaluable asset – ensure it’s protected

Case Studies

Logo for Cognyte.

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)

Logo for Facebook.

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)

Logo for MGM Resorts.

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.

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.

Only 12% of organizations are using risk as a strategic tool most or all of the time (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.

Multiple types of risk, 'Finance', 'IT', 'People', and 'Digital', funneling into 'ENTERPRISE RISKS'. 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.

Follow the steps of this blueprint to build or optimize your IT risk management program

Cycle of 'Goverance' beginning with '1. Identify', '2. Assess', '3. Respond', '4. Monitor', '5. Report'.

Start Here

PHASE 1
Review IT Risk Fundamentals and Governance
PHASE 2
Identify and Assess IT Risk
PHASE 3
Monitor, Report, and Respond to IT Risk

1.1

Review IT Risk Management Fundamentals

1.2

Establish a Risk Governance Framework

2.1

Identify IT Risks

2.2

Assess and Prioritize IT Risks

3.1

Monitor IT Risks and Develop Risk Responses

3.2

Report IT Risk Priorities

Integrate Risk and Use It to Your Advantage

Accelerate and optimize your organization by leveraging meaningful risk data to make intelligent enterprise risk decisions.

Risk management is more than checking an audit box or demonstrating project due diligence.

Risk Drivers
  • Audit & compliance
  • Preserve value & avoid loss
  • Previous risk impact driver
  • Major transformation
  • Strategic opportunities
Arrow pointing right. Only 7% of organizations are in a “leading” or “aspirational” level of risk maturity. (OECD, 2021) 63% of organizations struggle when it comes to defining their appetite toward strategy related risks. (“Global Risk Management Survey,” Deloitte, 2021) Late adopters of risk management were 70% more likely to use instinct over data or facts to inform an efficient process. (Clear Risk, 2020) 55% of organizations have little to no training on ERM to properly implement such practices. (AICPA, NC State Poole College of Management, 2021)
1. Assess Enterprise Risk Maturity 3. Build a Risk Management Program Plan 4. Establish Risk Management Processes 5. Implement a Risk Management Program
2. Determine Authority with Governance
Unfortunately, less than 50% of those in risk focused roles are also in a governance role where they have the authority to provide risk oversight. (Governance Institute of Australia, 2020)
IT can improve the maturity of the organization’s risk governance and help identify risk owners who have authority and accountability.

Governance and related decision making is optimized with integrated and aligned risk data.

List of 'Integrated Risk Maturity Categories': '1. Context & Strategic Direction', '2. Risk Culture and Authority', '3. Risk Management Process', and '4. Risk Program Optimization'. The five types of a risk in 'Enterprise Risk Management (ERM)': 'IT', 'Security', 'Digital', 'Vendor/TPRM', and 'Other'.

ERM incorporates the different types of risk, including IT, security, digital, vendor, and other risk types.

The program plan is meant to consider all the major risk types in a unified approach.

The 'Risk Process' cycle starting with '1. Identify', '2. Assess', '3. Respond', '4. Monitor', '5. Report', and back to the beginning. Implementation of an integrated risk management program requires ongoing access to risk data by those with decision making authority who can take action.

Blueprint deliverables

Each step of this blueprint is accompanied by supporting deliverables to help you accomplish your goals:

Key deliverable:

Risk Management Program Manual

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.

Sample of the key deliverable, Risk Manangement Program Fund.
Integrated Risk Maturity Assessment

Assess the organization's current maturity and readiness for integrated risk management (IRM).

Sample of the Integrated Risk Maturity Assessment blueprint. Centralized Risk Register

The repository for all the risks that have been identified within your environment.

Sample of the Centralized Risk Register blueprint.
Risk Costing Tool

A potential cost-benefit analysis of possible risk responses to determine a good method to move forward.

Sample of the Risk Costing Tool blueprint. Risk Report & Risk Event Action Plan

A method to report risk severity and hold risk owners accountable for chosen method of responding.

Samples of the Risk Report & Risk Event Action Plan blueprints.

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.

Logo for COSO.

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)

Logo for ISO.

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. (ISO 31000)

Logo for COBIT.

COBIT 2019’s IT functions were used to develop and refine our Ten IT Risk Categories used in our top-down risk identification methodology. (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:

Drivers External to IT
External Audit Internal Audit
Mandated by ERM
Occurrence of Risk Event
Demonstrating IT’s value to the business Proactive initiative
Emerging IT risk awareness
Grassroots Drivers

Blueprint benefits

IT 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.

Business Benefits

  • 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.

Info-Tech offers various levels of support to best suit your needs

DIY Toolkit

Guided Implementation

Workshop

Consulting

"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." "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." "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." "Our team does not have the time or the knowledge to take this project on. We need assistance through the entirety of this project."

Diagnostics and consistent frameworks used throughout all four options

Guided Implementation

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.

What does a typical GI on this topic look like?

    Phase 1

  • Call #1: Assess current risk maturity and organizational buy-in.
  • Call #2: Establish an IT risk council and determine IT risk management program goals.
  • Phase 2

  • Call #3: Identify the risk categories used to organize risk events.
  • Call #4: Identify the threshold for risk the organization can withstand.
  • Phase 3

  • 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.

Workshop Overview

Contact your account representative for more information.
workshops@infotech.com 1-888-670-8889

Day 1 Day 2 Day 3 Day 4 Day 5
Activities
Review IT Risk Fundamentals and Governance

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

Identify IT Risks

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

Assess IT Risks

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

Monitor, Report, and Respond to IT Risk

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

Next Steps and Wrap-Up (offsite)

5.1 Complete in-progress deliverables from previous four days

5.2 Set up review time for workshop deliverables and to discuss next steps

Outcomes
  1. Maturity Assessment
  2. Risk Management Program Manual
  1. Finalized List of IT Risk Events
  2. Risk Register
  3. Risk Management Program Manual
  1. Risk Register
  2. Risk Event Action Plans
  3. Risk Management Program Manual
  1. Risk Report
  2. Risk Management Program Manual
  1. Workshop Report
  2. Risk Management Program Manual

Build an IT Risk Management Program

Phase 1

Review IT Risk Fundamentals and Governance

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

Step 1.1

Review IT Risk Management Fundamentals

Activities
  • 1.1.1 Gain buy-in from senior leadership
  • 1.1.2 Assess current program maturity

This step involves the following participants:

  • IT executive leadership
  • Business executive leadership

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
Step 1.1 Step 1.2

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
  • Final Accountability
Senior Leadership Team Senior Leadership Team
  • Risk Governance
  • Risk Prioritization & Communication
ERM IT Risk Management
  • Risk Identification
  • Risk Assessment
  • Risk Monitoring
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.

Info-Tech’s IT risk management framework walks you through each step to achieve risk readiness

IT Risk Management Framework

Risk Governance
  • Optimize Risk Management Processes
  • Assess Risk Maturity
  • Measure the Success of the Program
A cycle surrounds the words 'Business Objectives', referring to the surrounding lists. On the top half is 'Communication', and the bottom is 'Monitoring'. Risk Identification
  • Engage Stakeholder Participation
  • Use Risk Identification Frameworks
  • Compile IT-Related Risks
Risk Response
  • Establish Monitoring Responsibilities
  • Perform Cost-Benefit Analysis
  • Report Risk Response Actions
Risk Assessment
  • Establish Thresholds for Unacceptable Risk
  • Calculate Expected Cost
  • Determine Risk Severity & Prioritize IT Risks

Effective IT risk management benefits

Obtain the support of the senior leadership team or IT steering committee by communicating how IT risk impacts their priorities.

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.

1.1.1 Gain buy-in from senior leadership

1-4 hours

Input: List of IT personnel and business stakeholders

Output: Buy-in from senior leadership for an IT risk management program

Materials: Risk Management Program Manual

Participants: IT executive leadership, Business executive leadership

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.

Integrated Risk Maturity Assessment

The purpose of the Integrated Risk Maturity Assessment is to assess the organization's current maturity and readiness for integrated risk management (IRM)

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
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.
Sample of the Integrated Risk Maturity Assessment deliverable.

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.

1.1.2 Assess current program maturity

1-4 hours

Input: List of IT personnel and business stakeholders

Output: Maturity scores across four key risk categories

Materials: Integrated Risk Maturity Assessment Tool

Participants: IT executive leadership, Business executive leadership

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.

Integrated Risk Maturity Categories

Semi-circle with colored points indicating four categories.

1

Context & Strategic Direction Understanding of the organization’s main objectives and how risk can support or enhance those objectives.

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.

3

Risk Management Process Determine if the current process to identify, assess, respond to, monitor, and report on risks is benefitting the organization.

4

Risk Program Optimization 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

Activities
  • 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

This step involves the following participants:

  • IT executive leadership
  • Business executive leadership

Outcomes of this step

  • 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

Step 1.1 Step 1.2

Create an IT risk governance framework that integrates with the business

Follow these best practices to make sure your requirements are solid:

  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

Challenges:
  • 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.

IT risk management success factors

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.

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.

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.

1.2.1 Identify obstacles and pain points

1-4 hours

Input: Integrated Risk Maturity Assessment

Output: Obstacles and pain points identified

Materials: IT Risk Management Success Factors

Participants: IT executive leadership, Business executive leadership

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

Replace the example pain points and opportunities with real scenarios in your organization.

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

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
  • 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:
    • Finance
    • Health care
    • Telecom
    • Government
    • Research
    • Education
Moderate
  • You have some compliance requirements, e.g.:
    • HIPAA
    • 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:
    • Government
    • Research
    • Education
Risk Averse
  • 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:
    • Finance
    • Healthcare
    • Telecom

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 to pursue its objectives and what levels of risk are deemed unacceptable. This is often called risk appetite.
Risk tolerant

Risk-tolerant organizations embrace the potential of accelerating growth and the attainment of business objectives by taking calculated risks.

Risk averse

Risk-averse organizations prefer consistent, gradual growth and goal attainment by embracing a more cautious stance toward risk.

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

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.

Unaware

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.

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.

1.2.3 Develop goals for the IT risk management program

1-4 hours

Input: Integrated Risk Maturity Assessment, Risk Culture, Pain Points and Opportunities

Output: Goals for the IT risk management program

Materials: Risk Management Program Manual

Participants: IT executive leadership, Business executive leadership

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.

1.2.4 Develop SMART project metrics

1-3 hours

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

Ensure that all success metrics are SMART 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:
    1. Name of the success metric
    2. Method for measuring success
    3. Baseline measurement
    4. Target measurement
    5. Actual measurements at various points throughout the process of improving the risk management program
    6. A deadline for each metric to meet the target measurement
Strong 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.

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.

Replace the example metrics with accurate KPIs or metrics for your organization.

Sample Metrics
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

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

Must be on the ITRC:

  • CFO
  • Senior representation from every business unit impacted by IT risk

1.2.5 Create the IT risk council

1-4 hours

Input: List of IT personnel and business stakeholders

Output: Goals for the IT risk management program

Materials: Risk Management Program Manual

Participants: CIO, CRO (if applicable), Senior Directors, Head of Operations

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.

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: 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.
Responsible Stakeholders who undertake the activity.
Accountable Stakeholders who are held responsible for failure or take credit for success.
Consulted Stakeholders whose opinions are sought.
Informed Stakeholders who receive updates.

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

Build an IT Risk Management Program

Phase 2

Identify and Assess IT Risk

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:

  • 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

Step 2.1

Identify IT Risks

Activities
  • 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

This step involves the following participants:

  • IT executive leadership
  • IT Risk Council
  • Business executive leadership
  • Business risk owners

Outcomes of this step

  • Participation of key stakeholders
  • Comprehensive list of IT risk events
Identify and Assess IT Risk
Step 2.1 Step 2.2

Get to know what you don’t know

  1. Engage the right stakeholders in risk identification.
  2. Employ Info-Tech’s top-down approach to risk identification.
  3. Augment your risk event list using alternative frameworks.
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
    • Number of business units represented
    • Number of meetings attended in person
    • 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.

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.

Prioritizing and Selecting Stakeholders

  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.

Enable IT to target risk holistically

Take a top-down approach to risk identification to guide brainstorming

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: 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.

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.

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
  • Negative PR
  • Consumers writing negative reviews
  • Employees writing negative reviews
IT Financial
  • Stock prices drop
  • Value of the organization is reduced
IT Strategic
  • Organization prioritizes innovation but remains focused on operational
  • Unable to access data to support strategic initiative
Operational
  • Enterprise architecture
  • Technology evaluation and selection
  • Capacity planning
  • Operational errors
Availability
  • Power outage
  • Increased data workload
  • Single source of truth
  • Lacking knowledge transfer processes for critical tasks
Performance
  • Network failure
  • Service levels not being met
  • Capacity overload
Compliance
  • Regulatory compliance
  • Standards compliance
  • Audit compliance
Security
  • Malware
  • Internally originated attack
Third Party
  • Vendor selection
  • Vendor management
  • Contract termination
Digital
  • No back-up process if automation fails

2.1.2 Identify risk events

1-4 hours

Input: IT risk categories

Output: Risk events identified and categorized

Materials: Risk Register Tool

Participants: IT risk council, Relevant business stakeholders, Representation from senior management team, Business risk owners, CRO (if applicable)

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.

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
  1. Managed IT Change Acceptance and Transitioning
  2. Managed Knowledge
  3. Managed Assets
  4. Managed Configuration
  5. Managed Projects
  6. Managed Operations
  7. Managed Service Requests and Incidents
  8. Managed Problems
  9. Managed Continuity
  10. Managed Security Services
  11. Managed Business Process Controls
  12. Managed Performance and Conformance Monitoring
  13. Managed System of Internal Control
  14. Managed Compliance with External Requirements
  15. Managed Assurance
  16. Ensured Governance Framework Setting and Maintenance
  17. Ensured Benefits Delivery
  18. Ensured Risk Optimization
  19. Ensured Resource Optimization
  20. Ensured Stakeholder Engagement

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.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.”

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.

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.

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.

List the following factors influencing the risk event:
  • Political factors
  • Economic factors
  • Social factors
  • Technological factors
  • Legal factors
  • Environmental factors
'PESTLE Analysis' presented as a wheel with the acronym's meanings surrounding the title. 'Political Factors', 'Economic Factors', 'Social Factors', 'Technological Factors', 'Legal Factors', and 'Environmental Factors'.

Step 2.2

Assess and Prioritize IT Risks

Activities
  • 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

This step involves the following participants:

  • IT risk council
  • Relevant business stakeholders
  • Representation from senior management team
  • Business risk owners

Outcomes of this step

  • Business-approved thresholds for unacceptable risk
  • Completed Risk Register Tool with risks prioritized according to severity
  • Expected cost calculations for high-priority risks

Identify and Assess IT Risk

Step 2.1 Step 2.2

Reveal the organization’s greatest IT threats and vulnerabilities

  1. Establish business-approved risk thresholds for acceptable and unacceptable risk.
  2. Conduct a streamlined assessment of all risks to separate acceptable and unacceptable risks.
  3. Perform a deeper, cost-based assessment of prioritized risks.
Key metrics:
  • 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

Info-Tech Insight

Risk is money. It’s impossible to make intelligent decisions about risks without knowing what their financial impact will be.

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

How much you expect a risk event to cost if it were to occur:

Likelihood of Risk Impact

e.g. $250,000 or “High”

X

Calibrated by how likely the risk is to occur:

Likelihood of Risk Occurrence

e.g. 10% or “Low”

=

Produces a dollar value or “severity level” for comparing risks:

Risk Severity

e.g. $25,000 or “Medium”
Which must be evaluated against thresholds for acceptable risk and the cost of risk responses.

Risk Tolerance
Risk Response

CBA
Cost-benefit analysis

Maintain the engagement of key stakeholders in the risk assessment process

1

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.

2

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.

3

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.

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.

Info-Tech recommends a two-level approach to risk assessment

Review the two levels of risk assessment offered in this blueprint.

Risk severity level assessment (mandatory)

1

Information

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

Negligible
Low
Moderate
High
Very High

X

Assess Likelihood

Negligible
Low
Moderate
High
Very High

=

Output


Risk Security Level:

Moderate

Example of a risk severity level assessment chart.
Chart risk events according to risk severity as this allows you to organize and prioritize IT risks.

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.

Info-Tech recommends a two-level approach to risk assessment (continued)

Expected cost assessment (optional)

2

Information

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

15%

Moderate

X

Assess Likelihood

$100,000

High

=

Output


Expected Cost:

$15,000

Expected cost is useful for conducting cost-benefit analysis and comparing IT risks to non-IT risks and other budget priorities 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?
  • 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

2.2.1 Determine the threshold for (un)acceptable risk

1-4 hours

Input: Risk events, Risk appetite

Output: Threshold for risk identified

Materials: Risk Register Tool, Risk Management Program Manual

Participants: IT risk council, Relevant business stakeholders, Representation from senior management team, Business risk owner

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

2.2.2 Create a financial impact assessment scale

1-4 hours

Input: Risk events, Risk threshold

Output: Financial impact scale created

Materials: Risk Register Tool, Risk Management Program Manual

Participants: IT risk council, Relevant business stakeholders, Representation from senior management team, Business risk owner

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 Overruns Scale for the use of cost assessment with dollar amounts associated with impact levels. '$250,000 - Extreme', '$100,000 - High', '$60,000 - Moderate', '$35,000 - Low', '$10,000 - Negligible'.

Project

Time (days)

20 days

Number of employees

8

Average cost per employee (per day)

$300

Estimated cost

$48,000
Service Outages

Service

Time (hours)

4 hours

Lost revenue (per hour)

$10,000

Estimated cost

$40,000

Impact scale

Low

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.

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.

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.

2.2.3 Select a technique to measure reputational cost (2 of 3)

1-3 hours
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.
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
  1. Then, determine (hypothetically) how much money the organization would be willing to spend to prevent the reputational cost from being incurred.
  2. Match this dollar value to the corresponding level on the impact scale created in Activity 2.2.2.

2.2.3 Select a technique to measure reputational cost (3 of 3)

1-3 hours

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:

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?
Example:
Scale for the use of cost assessment  of reputational impact with dimension combinations associated with impact levels. 'External, High Amp, (regulators, lawsuits) - Extreme', 'Internal, High Amp, (CEO) - Low', 'Internal, Low Amp (IT) - Negligible'.

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.)

Record the risk impact scale in section 5.3 of the Risk Management Program Manual

Scale to assess the likelihood that a risk event will occur. '80-99% - Extreme', '60-79% - High', '40-59% - Moderate' '20-39% - Low', '1-19% - Negligible'.

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.

2.2.5 Risk severity level assessment

6-10 hours

Input: Risk events identified

Output: Assessed the likelihood of occurrence and impact for all identified risk events

Materials: Risk Register Tool

Participants: IT risk council, Relevant business stakeholders, Representation from senior management team, Business risk owner

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):
  1. 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.
  2. 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.

Screenshot of a risk severity level assessment.

Identify current risk controls

Consider how IT is already addressing key risks.

Types of current risk control

Tactical controls

Apply to individual risks only.

Example: A tactical control for backup/replication failure is faster WAN lines.

Tactical risk control Strategic controls

Apply to multiple risks.

Example: A strategic control for backup/replication failure is implementing formal DR plans.

Strategic risk control
Risk event Risk event Risk event

Screenshot of the column headings on the risk severity level assessment with 'Current Controls' highlighted.
Consider both tactical and strategic controls already in place when filling out risk event information in the Risk Register Tool.

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.

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.

Screenshot of the column headings on the risk severity level assessment with 'Risk Owner' highlighted.

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.

Use Info-Tech’s Risk Costing Tool to calculate the expected cost of IT’s high-priority risks (optional)

Sample of the Risk Costing Tool.

Use this tool to:

  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.

2.2.6 Expected cost assessment (optional)

Assign likelihood and financial impact values to high-priority risks.

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:
    • There is general consensus on likelihood estimates.
    • There is general consensus on financial impact estimates.
    • 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


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)

Assign likelihood and financial impact values to high-priority risks.

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%.

Screenshot of the column headings on the risk severity level assessment with 'Optional Inherent Likelihood Parameters' and 'Optional Inherent Impact Parameters' highlighted.

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.

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.
Justifying Your Estimates:

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.

Build an IT Risk Management Program

Phase 3

Monitor, Respond, and Report on IT Risk

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:

  • 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
  • Relevant business stakeholders
  • Representation from senior management team
  • Risk business owner

Step 3.1

Monitor IT Risks and Develop Risk Responses

Activities
  • 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

This step involves the following participants:

  • IT risk council
  • Relevant business stakeholders
  • Representation from senior management team
  • Business risk owner

Outcomes of this step

  • Completed risk event action plans
  • Risk responses identified and assessed for top risks
  • Risk response selected for top risks

Monitor, Respond, and Report on IT Risk

Step 3.1 Step 3.2

Use Info-Tech’s Risk Event Action Plan to manage high-priority 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.

Risk Event Action Plan Sample of the Risk Event Action Plan deliverable.

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.

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:
    • Escalation to the risk owner (if delegated) or to a member of the senior leadership team.
    • Reporting to the IT risk council or IT steering committee.
    • Reassessment.
    • 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

Visualization of KRI development, from the 'Risk Event' to the 'Intermediate Steps' with 'KRI Measurements' to the image of a growing seed.

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 Risk event severity represented as a thermometer with levels 'Extreme', 'High', 'Moderate', 'Low', and 'Negligible'.
Bi-weekly reports to ITRC
Monthly reports to ITRC
Report to ITRC only if KRI thresholds triggered
No reports; reassessed bi-annually

Use Info-Tech’s tools to identify, analyze, and select risk responses

1

(Mandatory)
Tool

Screenshot of the Risk Register Tool.

Risk Register Tool

Information
  • 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.

2

(Optional)
Tool

Screenshot of the Risk Costing Tool.

Risk Costing Tool

Information
  • Continue your second-level risk analysis for top risks for which you calculated expected cost in section 2.2.
  • Activity 3.1.5:
    • Identify between one and four risk response options for each risk.
    • Develop precise values for residual likelihood and impact.
    • Compare expected cost of the risk event to expected residual cost.
    • Select the risk response to recommend to senior leadership and document it in the Risk Register Tool.

Determine the root cause of IT risks

Root cause analysis

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.

Concentric circles with 'Root Cause' at the center, 'Contributing Factors' around it, and 'Symptoms' on the outer circle.

Example of 'The Five Whys Methodology', tracing symptoms to their root cause. In 'Symptoms' we see 'Risk Event: Network outage', Why? 'Network congestion', Why? Then on to 'Contributing Factors' the answer is 'Inadequate bandwidth for latency-sensitive applications', Why? 'Increased business use of latency-sensitive applications', Why? And finally to the 'Root Cause', 'Business units rely on 'real-time' data gathered from latency-sensitive applications', 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

  • Infrastructure
  • Applications
  • Processes
  • Information/data
  • Personnel
  • Reputation
  • Operations
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

Decreasing the use of key apps contradicts business objectives.

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.

Replacing the vendor would reduce network outages at a relatively low cost.

Symptoms:
Network outage

Actors: All business units, network provider

Asset/resource: Network, business operations, employee productivity

Risk response:
Replace legacy systems.

X

Replacing legacy systems would be too costly.

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.
Stock photo of a person hikiing along a damp, foggy, valley path.

Pursue projects that reduce the likelihood or impact of the risk event

Risk Mitigation

  • 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.
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.
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.

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:

Process Improvement

Key processes that would most directly improve the risk profile:

  • Change Management
  • Project Management
  • Vendor Management
Infrastructure Management
  • Disaster Recovery Plan/Business Continuity Plan
  • Redundancy and Resilience
  • Preventative Maintenance
  • Physical Environment Security
Personnel
  • Greater staff depth in key areas
  • Increased discipline around documentation
  • Knowledge Management
  • Training
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

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

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.
Other Forms of Risk Transfer

Other forms of risk transfer include:

  • Self-insurance
    • Appropriate funds can be set aside in advance to address the financial impact of a risk event should it occur.
  • Warranties
  • Contractual transfer
    • The financial impact of a risk event can be transferred to a third party through clauses agreed to in a contract.
    • For example, a vendor can be contractually obligated to assume all costs resulting from failing to secure the organization’s data.
  • Example email addressing fields of an IT Risk Transfer to an insurance company.

Accept risks that fall below established thresholds

Risk Acceptance

Accepting a risk means tolerating the 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 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)

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 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.
Screenshot of the Risk Response cost-benefit-analysis from the Risk Costing Tool with 'Capital Expenditures' and 'Operating Expenditures' highlighted.

Record the results in the Risk Costing Tool.

3.1.4 Risk response cost-benefit analysis (continued)

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

Instructions:

  1. 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.
    • Screenshot of the Risk Response cost-benefit-analysis from the Risk Costing Tool with figured for 'Financial Impact' and 'Probability' highlighted. The tool will calculate the expected residual cost of the risk event: (Financial Impact x Likelihood) - Costs = Expected Residual Cost
  2. Select the highest value risk response and document it in the Risk Register Tool.
  3. 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.

3.1.5 Create multi-year cost projections (optional)

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

Sample charts on the cost of risk responses from the Risk Costing Tool.

Record the results in the Risk Costing Tool.

Step 3.2

Report IT Risk Priorities

Activities
  • 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

This step involves the following participants:

  • IT risk council
  • Relevant business stakeholders
  • Representation from senior management team

Outcomes of this step

  • Obtained approval for risk action plans
  • Communicated IT’s risk recommendations to senior leadership
  • Embedded risk management into day-to-day IT operations

Monitor, Respond, and Report on IT Risk

Step 3.1 Step 3.2

Effectively deliver IT risk expertise to the business

Communicate IT risk management in two directions:

  1. Up to senior leadership (and ERM if applicable)
  2. Down to IT employees (embedding risk awareness)
  3. Visualization of communicating Up to 'Senior Leadership' and Down to '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.

3.2.1 Obtain executive approval for risk action plans

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.
Sample of the Risk Event Action Plan template.

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.

3.2.2 Socialize 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:
  • An executive summary page highlighting the main takeaways for senior management:
    • A short summary of results from the most recent risk assessment
    • Dashboard
    • A list of top 10 risks ordered from most severe to least
  • Subsequent individual risk analyses (1 to 10)
    • Detailed risk assessment data
    • Risk responses
    • Risk response analysis
    • Multi-year cost projection (see the following slide)
    • Dashboard
    • Recommendations
Sample of the Risk Report template.

Risk Report

Pursue projects that reduce the likelihood or impact of the risk event

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

Make time for discussing project risks at every project kick-off.
  • A main benefit of including senior personnel from across IT in the ITRC is that they are able to disseminate the IT risk council’s findings to their respective practices.
  • At project kick-off meetings, schedule time to identify and assess project-specific risks.
  • Encourage the project team to identify strategies to reduce the likelihood and impact of those risks and document these in the project charter.
  • Lead by example by being clear and open about what constitutes acceptable and unacceptable risks.

Embed risk management with employee

Train IT staff on the ITRC’s planned responses to specific risk events.
  • If a response to a particular risk event is not to implement a project but rather to institute new policies or procedures, ensure that changes are communicated to employees and that they receive training.
Provide risk management education opportunities.
  • Remember that a more risk-aware IT employee provides more value to the organization.
  • Invest in your employees by encouraging them to pursue education opportunities like receiving risk management accreditation or providing them with educational experiences such as workshops, seminars, and eLearning.

Embedding risk management in the IT department is a full-time job (continued)

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.
  • Info-Tech 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.

3.2.3 Transfer 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.

Image of a hand giving a key to another hand and a circle split into quadrants of Governance with 'Governance of Risks' being put into 'Governance of Projects'.

3.2.4 Finalize 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.

Remember, the program manual is a living document that should be evolving alongside your risk management 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.

Sample of the Risk Management Program Manual. Risk Management Program Manual

“Upon completing the Info-Tech 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.” (Director of Security & Risk, Water Management Company)

Don’t allow your risk management program to flatline

54% of small businesses haven’t implemented controls to respond to the threat of cyber attacks (Source: Insurance Bureau of Canada, 2021)

Don’t be lulled into a false sense of security. It might be your greatest risk.

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 Info-Tech’s research on conducting periodic risk assessments and “health checks”:

Revive Your Risk Management Program With a Regular Health Check

  • Complete Info-Tech’s Risk Management Health Check to seize the momentum you created by building a robust IT risk management program and create a process for conducting periodic health checks and embedding ongoing risk management into every aspect of IT.
  • Our focus is on using data to make IT risk assessment less like an art and more like a science. Ongoing data-driven risk management is self-improving and grounded in historical data.

Appendix I: Familiarize yourself with key risk terminology

Review important risk management terms and definitions.

Risk

An uncertain event or set of events which, should it occur, will have an effect on the achievement of objectives. A risk consists of a combination of the likelihood of a perceived threat or opportunity occurring and the magnitude of its impact on objectives (Office of Government Commerce, 2007).

Threat

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

Vulnerability

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

Risk Management

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 environment for proactive decision making (Office of Government Commerce, 2007).

Risk Category

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

Risk Event

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

Risk Appetite

An organization’s attitude towards risk taking, which determines the amount of risk that it considers 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.

Enterprise Risk Management

(ERM) – A strategic business discipline that supports the achievement of an organization’s objectives by addressing the full spectrum of organizational risks and managing the combined impact of those risks as an interrelated risk portfolio (RIMS, 2015).

Appendix II: Likelihood vs. Frequency

Why we measure likelihood, 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 Likelihood.

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.

Likelihood is a numerical representation of the “degree of belief” that the risk event will occur in a given future timeframe (e.g. 25% likelihood 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 likelihood theory that historical data regarding the frequency of a risk event may have little bearing over the likelihood of that event happening in the future. Frequency is often an indication of future likelihood 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 two years, they ought to possess a much higher degree of belief that the risk event will occur within the next year.

Likelihood is a more comprehensive measurement of future likelihood, as frequency can be used to inform the selection of a likelihood value. The process of selecting intersubjective likelihood 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 three times over the next year has an expected impact of $30,000.

Appendix III: Should max impacts sway decision making?

Don’t just fixate on the most likely impact – be aware of high-impact outcomes.

During assessment, risks are evaluated according to their most likely financial impact.

  • For example, a service outage will likely last for two hours and may have an expected cost of $14,000.

Naturally, focusing on the most likely financial impact will exclude higher impacts that – while 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 likelihood 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-negligible likelihood values (likelihood values that you cannot ignore).
  • What you consider “non-negligible” will depend on your organizational risk tolerance/appetite.

Sometimes called Black Swan events or Fat-Tailed outcomes, high-impact events may occur when the far right of the likelihood distribution – or the “tail” – is thicker than a normal 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.

For risk events that contain non-negligible likelihoods (too high to be ignored) consider elevating the risk severity level or expected cost.

Figure 1 is a graph presenting a 'Normal Likelihood Distribution', the axes being 'Likelihood' and 'Financial Impact'.
Figure 2 is a graph presenting a 'Fat-Tailed Likelihood Distribution' with a point at the top of the parabola labelled 'Most Likely Impact' but with a much wider bottom labelled 'Fat-Tailed Outcomes', the axes being 'Likelihood' and 'Financial Impact'.

Leverage Info-Tech’s research on security and compliance risk to identify additional risk events

Title card of the Info-tech blueprint 'Take Control of Compliance Improvement to Conquer Every Audit' with subtitle 'Don't gamble recklessly with external compliance. Play a winning system and take calculated risks to stack the odds in your favor.


Take Control of Compliance Improvement to Conquer Every Audit

Info-Tech Insight

Don’t gamble recklessly with external compliance. Play a winning system and take calculated risks to stack the odds in your favor.

Take an agile approach to analyze your gaps and prioritize your remediations. You don’t always have to be fully compliant as long as your organization understands and can live with the consequences.

Stock photo of a woman sitting at a computer surrounded by rows of computers.


Develop and Implement a Security Risk Management Program

Info-Tech Insight

Security risk management equals cost effectiveness.

Time spent upfront identifying and prioritizing risks can mean the difference between spending too much and staying on budget.

Research Contributors and Experts

Sandi Conrad
Principal Research Director
Info-Tech Research Group

Christine Coz
Executive Counsellor
Info-Tech Research Group

Milena Litoiu
Principal Research Director
Info-Tech Research Group

Scott Magerfleisch
Executive Advisor
Info-Tech Research Group

Aadil Nanji
Research Director
Info-Tech Research Group

Andy Neill
Associate Vice-President of Research
Info-Tech Research Group

Daisha Pennie
IT Risk Management
Oklahoma State University

Ken Piddington
CIO and Executive Advisor
MRE Consulting

Frank Sewell
Research Director
Info-Tech Research Group

Andrew Sharpe
Research Director
Info-Tech Research Group

Chris Warner
Consulting Director- Security
Info-Tech Research Group

Sterling Bjorndahl
Director of IT Operations
eHealth Saskatchewan

Research Contributors and Experts

Ibrahim Abdel-Kader
Research Analyst
Info-Tech Research Group

Tamara Dwarika
Internal Auditor
A leading North American Utility

Anne Leroux
Director
ES Computer Training

Ian Mulholland
Research Director
Info-Tech Research Group

Michel Fossé
Consulting Services Manager
IBM Canada (LGS)

Petar Hristov
Research Director
Info-Tech Research Group

Steve Woodward
Research Director
CEO, Cloud Perspectives

*Plus 10 additional interviewees who wish to remain anonymous.

Bibliography

“2021 State of the CIO.” IDG, 28 January 2021. Web.

“4 Reasons Why CIOs Lose Their Jobs.” Silverton Consulting, 2012. Web.

Beasley, Mark, Bruce Branson, and Bonnie Hancock. “The State of Risk Oversight,” AICPA, April 2021. Web.

COBIT 2019. ISACA, 2019. Web.

“Cognyte jeopardized its database exposing 5 billion records, including earlier data breaches.” SecureBlink, 21 June 2021. Web.

Culp, Steve. “Accenture 2019 Global Risk Management Study, Financial Services Report.” Accenture, 2019. Web.

Curtis, Patchin, and Mark Carey. “Risk Assessment in Practice.” COSO Committee of Sponsoring Organizations of the Treadway Commission, Deloitte & Touche LLP, 2012. Web.

“Cyber Risk Management.” Insurance Bureau of Canada (IBC), 2022. Web.

Eccles, Robert G., Scott C. Newquist, and Roland Schatz. “Reputation and Its Risks.” Harvard Business Review, February 2007. Web.

Eden, C. and F. Ackermann. Making Strategy: The Journey of Strategic Management. Sage Publications, 1998.

“Enterprise Risk Management Maturity Model.” OECD, 9 February 2021. Web.

Ganguly, Saptarshi, Holger Harreis, Ben Margolis, and Kayvaun Rowshankish. “Digital Risks: Transforming risk management for the 2020s.” McKinsey & Company, 10 February 2017. Web.

“Governance Institute of Australia Risk Management Survey 2020.” Governance Institute of Australia, 2020. Web.

“Guidance on Enterprise Risk Management.” COSO, 2022. Web.

Henriquez, Maria. “The Top 10 Data Breaches of 2021” Security Magazine, 9 December 2021. Web.

Holmes, Aaron. “533 million Facebook users’ phone numbers and personal data have been leaked online.” Business Insider, 3 April 2021. Web.

Bibliography

“Integrated Risk and Compliance Management for Banks and Financial Services Organizations: Benefits of a Holistic Approach.” MetricStream, 2022. Web.

“ISACA’s Risk IT Framework Offers a Structured Methodology for Enterprises to Manage Information and Technology Risk.” ISACA, 25 June 2020. Web.

ISO 31000 Risk Management. ISO, 2018. Web.

Lawton, George. “10 Enterprise Risk Management Trends in 2022.” TechTarget, 2 February 2022. Web.

Levenson, Michael. “MGM Resorts Says Data Breach Exposed Some Guests’ Personal Information.” The New York Times, 19 February 2020. Web.

Management of Risk (M_o_R): Guidance for Practitioners. Office of Government Commerce, 2007. Web.

“Many small businesses vulnerable to cyber attacks.” Insurance Bureau of Canada (IBC), 5 October 2021.

Maxwell, Phil. “Why risk-informed decision-making matters.” EY, 3 December 2019. Web.

“Measuring and Mitigating Reputational Risk.” Marsh, September 2014. Web.

Natarajan, Aarthi. “The Top 6 Business Risks you should Prepare for in 2022.” Diligent, 22 December 2021. Web.

“Operational Risk Management Excellence – Get to Strong Survey: Executive Report.” KMPG and RMA, 2014. Web.

“Third-party risk is becoming a first priority challenge.” Deloitte, 2022. Web.

Thomas, Adam, and Dan Kinsella. “Extended Enterprise Risk Management Survey, 2020.” Deloitte, 2021. Web.

Treasury Board Secretariat. “Guide to Integrated Risk Management.” Government of Canada, 12 May 2016. Web.

Webb, Rebecca. “6 Reasons Data is Key for Risk Management.” ClearRisk, 13 January 2021. Web.

“What is Enterprise Risk Management (ERM)?” RIMS, 2015. Web.

Wiggins, Perry. “Do you spend enough time assessing strategic risks?” CFO, 26 January 2022. Web.

About Info-Tech

Info-Tech Research Group is the world’s fastest-growing information technology research and advisory company, proudly serving over 30,000 IT professionals.

We produce unbiased and highly relevant research to help CIOs and IT leaders make strategic, timely, and well-informed decisions. We partner closely with IT teams to provide everything they need, from actionable tools to analyst guidance, ensuring they deliver measurable results for their organizations.

Member Rating

9.5/10
Overall Impact

$69,299
Average $ Saved

13
Average Days Saved

After each Info-Tech experience, we ask our members to quantify the real-time savings, monetary impact, and project improvements our research helped them achieve.

Read what our members are saying

What Is a Blueprint?

A blueprint is designed to be a roadmap, containing a methodology and the tools and templates you need to solve your IT problems.

Each blueprint can be accompanied by a Guided Implementation that provides you access to our world-class analysts to help you get through the project.

Mitigate the IT risks that could negatively impact your organization.

Need Extra Help?
Speak With An Analyst

Get the help you need in this 3-phase advisory process. You'll receive 8 touchpoints with our researchers, all included in your membership.

Guided Implementation #1 - Review IT risk fundamentals and governance
  • Call #1 - Assess current risk maturity and organizational buy-in.
  • Call #2 - Establish an IT risk council and determine IT risk management program goals.

Guided Implementation #2 - Identify and assess IT risk
  • Call #1 - Identify the risk categories used to organize risk events.
  • Call #2 - Identify the threshold for risk the organization can withstand.
  • Call #3 - Prepare for risk assessment by selecting tools and methodologies.

Guided Implementation #3 - Monitor, respond, and report on IT risk
  • Call #1 - Create a method to assess risk event severity.
  • Call #2 - Establish a method to monitor priority risks and consider possible risk responses.
  • Call #3 - Communicate risk priorities to the business and implement risk management plan.

Authors

Valence Howden

Brittany Lutes

Ibrahim Abdel-Kader

Contributors

  • Daisha Pennie, IT Risk Management, Oklahoma State University
  • Ken Piddington CIO and Executive Advisor, MRE Consulting
  • Tamara Dwarika, Internal Auditor, A leading North American Utility
  • Anne Leroux, Director ES Computer Training
  • Michel Fossé, Consulting Services Manager, IBM Canada (LGS)
  • Steve Woodward, Research Director, CEO, Cloud Perspectives
  • 10 anonymous contributors
Visit our COVID-19 Resource Center and our Cost Management Center
Over 100 analysts waiting to take your call right now: 1-519-432-3550 x2019