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.

Valence Howden Principal Research Director, 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

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.

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

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		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.			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.		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.	Integrated Risk Maturity Assessment Assess the organization's current maturity and readiness for integrated risk management (IRM).		Centralized Risk Register The repository for all the risks that have been identified within your environment.
	Risk Costing Tool A potential cost-benefit analysis of possible risk responses to determine a good method to move forward.		Risk Report & Risk Event Action Plan A method to report risk severity and hold risk owners accountable for chosen method of responding.

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.

Abandon ad hoc risk management

Blueprint benefits

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

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

Build an IT Risk Management Program

Phase 1

Review IT Risk Fundamentals and Governance

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

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:

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

1.1.1 Gain buy-in from senior leadership

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.

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.

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

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

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

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.

1.2.2 Determine the risk culture of your organization

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

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:

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

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

1.2.4 Develop SMART project metrics (continued)

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.

Create the IT risk committee (ITRC)

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

A RACI diagram is a useful visualization that identifies redundancies and ensures that every role, project, or task has an accountable party.

1.2.6 Complete RACI chart (continued)

Assign risk management accountabilities and responsibilities to key stakeholders:

Build an IT Risk Management Program

Phase 2

Identify and Assess IT Risk

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

Get to know what you don’t know

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.

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.

2.1.1 Add organization-specific risk scenarios

Review Info-Tech’s ten IT risk categories and add risk scenarios to the examples provided.

2.1.2 Identify risk events

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)

Other industry-leading frameworks provide alternative ways of conceptualizing the functions and responsibilities of IT and may help you uncover additional risk events.

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)

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

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

Reveal the organization’s greatest IT threats and vulnerabilities

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

Maintain the engagement of key stakeholders in the risk assessment process

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)

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)

Conduct expected cost assessments for IT’s greatest risks.

For risk events warranting further analysis, translate risk severity levels into hard expected-cost numbers.

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

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

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

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

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

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:

2.2.4 Create a likelihood scale

1-3 hours

Instructions: 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). Ensure that the likelihood scale contains the same number of levels as the financial impact scale (3, 4, 5, 7, or 9). 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. 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

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)

Identify current risk controls

Consider how IT is already addressing key risks.

Types of current risk control

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.

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

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.

2.2.6 Expected cost assessment (continued)

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

Evaluate likelihood and impact

Refine your risk assessment process by developing more accurate measurements of likelihood and impact.

Build an IT Risk Management Program

Phase 3

Monitor, Respond, and Report on IT Risk

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

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

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

Document KRIs, escalation thresholds, and escalation protocols for each risk in a Risk Event Action Plan.

Developing KRIs for success

Examples of KRIs

• Number of resources who quit or were fired who had access to critical data
• Number of risk mitigation initiatives unfunded
• Changes in time horizon of mitigation implementation
• Number of employees who did not report phishing attempts
• Amount of time required to get critical operations access to necessary data
• Number of days it takes to implement a new regulation or compliance control

3.1.2 Establish the reporting schedule

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

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

Reporting	Risk Event
Weekly reports to ITRC
Bi-weekly reports to ITRC
Monthly reports to ITRC
Report to ITRC only if KRI thresholds triggered
No reports; reassessed bi-annually

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

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.

3.1.3 Identify and assess risk responses

Record the results in the Risk Event Action Plan.

Take actions to avoid the risk entirely

Risk Avoidance Risk avoidance involves taking evasive maneuvers to avoid the risk event. Risk avoidance targets risk likelihood, decreasing the likelihood of the risk event occurring. Since risk avoidance measures are fairly drastic, the likelihood is often reduced to negligible levels. However, risk avoidance response actions often sacrifice potential benefits to eliminate the possibility of the risk entirely. Typically, risk avoidance measures should only be taken for risk events with extremely high severity and when the severity (expected cost) of the risk event exceeds the cost (benefits sacrificed) of avoiding the risk. Example Risk event: Information security vulnerability from third-party cloud services provider. Risk avoidance action: Store all data in-house. Benefits sacrificed: Cost savings, storage flexibility, etc.

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

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.

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:

Transfer risks to a third party

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

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: 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). 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. Estimate the first-year cost for the risk response. This cost should reflect initial capital expenditures and first-year operating expenditures.

Record the results in the Risk Costing Tool.

3.1.4 Risk response cost-benefit analysis (continued)

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

Instructions:

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

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

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

Note: See Activity 3.1.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.

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

Effectively deliver IT risk expertise to the business

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: The organization is aware of important IT risks that may impact business objectives. The organization supports the risk assessment conducted by the ITRC. The organization supports the plan of action and monitoring responsibilities proposed by the ITRC. If a risk event were to occur, the organization holds ultimate accountability.

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

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.

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.

• Assign responsibility for executing the specific risk response action to a project manager.
• For advice on how to optimize project management, read Info-Tech’s blueprint Tailor IT Project Management Processes to Fit Your 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.

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.

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.

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

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

Research Contributors and Experts

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