Build an IT Risk Management Program

Mitigate threats with a cost-focused approach to IT risk management.

ANALYST PERSPECTIVE

A good security practice is not enough to manage IT risk.

When most CIOs and IT leaders think of risk, their minds immediately jump to the latest security threat making headlines.

While security is an important part of IT risk, it is only one component. Risk across IT requires a holistic perspective, driven by the needs and priorities of the business. Failing to understand the true business ramifications of IT risk exposes the business to IT-related threats, or leads to overspending on low-priority initiatives. Like good leadership, risk management must be proactive, dynamic, and constantly improving. In the modern IT risk environment, hoping for the best is not an acceptable strategy for managing risk – and the line between optimism and negligence is razor thin.

Use this blueprint to build a right-sized, business-driven risk management program with minimal effort.

Scott Janz,

Consulting Analyst, CIO Advisory

Info-Tech Research Group

Our understanding of the problem

This Research Is Designed For:

• Any IT Leader responsible for IT risk management in their organization.
• Any CIO mandated to integrate IT risk management with their organization’s central risk management function or Enterprise Risk Management (ERM).
• Any IT Director or Manager undertaking a risk assessment.
• Any IT Director or Manager responding to or preparing for an IT audit.

This Research Will Also Assist:

• Enterprise Risk Management
• Senior Leadership

This Research Will Help You:

• Establish a comprehensive IT risk management program that exposes your IT risks.
• Create a strategy for managing and mitigating risks to meet your organization’s risk appetite.
• Quantify risk exposure in meaningful financial terms.
• Build business buy-in and shared accountability for business-impacting IT risks.

This Research Will Help Them:

• Develop consensus on organizational risk appetite.
• Establish a framework and metrics for acceptable risk tolerance.
• Align business and IT risk management objectives.
• Enable the business to make informed investments when managing IT risks.

Executive Summary

Situation

• Risk is unavoidable. Without a formal program to manage IT risk, you may be unaware of your severest IT risks.
• 66% of organizations do not formally manage IT risk (ESI International).
• IT risk is business risk – however, IT is often left to manage risk independently.

Complication

• Reacting to risks AFTER they occur can be costly and crippling, yet is one of the most common tactics used by IT departments.
• 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.

Resolution

• Stop leaving IT risk to chance. Transform your ad hoc IT risk management processes into a formalized, ongoing program and increase risk management success by 53% (Info-Tech Research Group, 2013, N=76).
• Take a proactive stance against IT threats and vulnerabilities by identifying and assessing IT’s greatest risks before they occur and have serious implications.
• Involve key stakeholders including the business senior management team to gain buy-in and to focus on IT risks that matter most to the organization.
• Share accountability for IT risk with business stakeholders and have them weigh-in on prioritizing investments in risk response activities.

Info-Tech Insight

1. IT risk is business risk.

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

2. Risk is money.

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

3. You don’t know what you don’t know.

And what you don’t know can hurt you. To find hidden risks, you must utilize a structured risk identification method.

Poor IT risk management is expensive

IT Risk Is Headline News

• Abandoned NHS IT system has cost £10bn so far

The Guardian

• RBS fined £56m over 'unacceptable' computer failure

BBC

• VTech Holdings: Data From 5 Million Customer Accounts Breached

The Wall Street Journal

• Target Now Says 70 Million People Hit in Data Breach

The Wall Street Journal

• Md. woman admits stealing millions from D.C. nonprofit

The Washington Post

• Virgin Blue sees up to $20m hit for reservation meltdown

The Australian

• Failed IT system wastes millions for MoD

Computer Business Review

• Finra Fines Scottrade $2.6 Million Over Electronic Records

The Wall Street Journal

Risk management is a top IT priority

Info-Tech’s Top 10 IT Improvement Priorities

1. Data Quality
2. IT Governance
3. Risk Management
4. Knowledge Management
5. Requirements Gathering
6. Manage Service Catalog
7. Organizational Change Management
8. Quality Management
9. Performance Measurement
10. Application Portfolio Management

Info-Tech asked over 2,500 IT professionals to rate, on a scale of 1 to 10, the importance of risk management and how effective they were at managing IT risks.

Importance of risk management:

• 8.3
• Above average importance

Effectiveness of risk management:

• 5.9
• Significantly below average effectiveness

For more information, see Info-Tech’s IT Management & Governance Diagnostic.

66% of organizations lack a formal risk management program (ESI International)

If you are like the majority of IT departments, you do not have a consistent and comprehensive strategy for managing IT risk.

Ad hoc approaches to managing risk fail because…

1. Ad hoc risk management is often reactionary.
• Without formalized procedures for managing IT risk, risk events are often “managed” after they have occurred.
• IT departments that spend most of their time putting out fires receive the lowest ratings for satisfaction and perceived value by business stakeholders.
2. Ad hoc risk management is often focused only on IT security.
• Organizations must respond to the entire spectrum of IT risk.
• A client who recently completed Info-Tech’s methodology for risk identification and assessment found that only 15 of the 135 IT risks identified were related to security and compliance.
3. Ad hoc risk management lacks alignment with business objectives.
• Many IT risk assessments fail to communicate IT risks in a way that compels the business to take action.
• 63% of CEOs indicate they want IT to provide better risk metrics (CIO-CEO Alignment survey data, Info-Tech Research Group).

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.

"Most IT departments aren’t thinking about formal risk management, and if they are, it’s back-of-the-napkin planning."

Ken Piddington, CIO & Executive Advisor, MRE Consulting

Unmanaged IT risk isn’t just bad for the organization, it’s also bad for your career

Take luck out of the equation

Hoping for the best” is not a risk management strategy. Take control of IT risk and avoid leaving your job security to chance

Source: Silverton Consulting

"If I wait until a risk event occurs, I might be out of a job before the business recovers."

– VP of Security and Risk, Energy Logistics Company

When business stakeholders are unaware of top IT threats, blame for project, security, disaster recovery, and system failures is usually assigned to the CIO and other senior IT managers.

When effectively integrated with business risk management,

IT risk management is your best job security policy.

Ensure that your greatest IT risks are on your radar

CASE STUDY

IT vendor risks may be your greatest business risks.

Focusing on internal IT security risks may not be enough to protect your organization from a breach. Learn from these organizations whose security breaches all originated from third-party vendors.

“AT&T data breaches revealed: 280K US customers exposed” (CNBC)

Employees at an IT service provider stole customer names and SSNs to request unlock codes for stolen phones. In 2015, AT&T agreed to settle with the FCC and pay a $25 M fine.

“Home Depot faces dozens of data breach lawsuits” (Fortune)

Hackers stole credentials from a third-party vendor to gain access to Home Depot’s network, stealing data from 56 million credit cards, as well as 53 million email addresses.

“868,000 Payment Cards, 330 Stores Hit in Goodwill Credit Card Breach” (Forbes)

Hackers breached the system of a cloud-based card processing service vendor, with the intrusion lasting more than 18 months. (KrebsOnSecurity)

Formalize risk management to increase your likelihood of success by 53%

Organizations that adopted formal risk programs increased their risk management success by 53%.

Risk management is a business enabler.

Line managers often see risk management as an impediment to their day-to-day function. But, in fact, the opposite is true. 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 competition because they will be aware of which risks to prepare for, which risks to ignore, and which risks to take.

Taking the initiative pays off. A security manager in the energy industry saved over $80,000 by developing an IT risk management program in-house instead of bringing in external consultants.

You don’t know what you don’t know…and what you don’t know can hurt you!

So find out using Info-Tech’s risk identification and risk assessment methodology.

Developed and tested directly with our clients, Info-Tech’s Risk Register Tool allows you to document and track a comprehensive list of IT risk events that may affect your organization.

• Assess risk severity using acceptability thresholds developed in collaboration with senior leadership.
• Identify and manage the top IT risks impacting the organization.

Use Info-Tech’s Risk Costing Tool to put a price on your top risks.

• Calculate the expected cost of anticipated risk events.
• Calculate the expected cost of alternative risk response actions.
• Project the costs of risk response actions over multiple years to inform risk response decisions.
• Conduct cost-benefit analyses for your top risks and select a risk response that offers the greatest value to the organization.

Info-Tech Insight

Risk is money. It’s impossible to make intelligent decisions about risks without knowing how much they cost. Use Info-Tech’s Risk Costing Tool to calculate and present the expected costs associated with accepting and responding to high-priority risk events.

IT risk is business risk – engage with the business to manage risk effectively

IT Risk is Business Risk

Therefore:

Accountability for IT risks and the decisions made to address them should be shared between IT and the business.

A robust risk management program accomplishes this by building permanent channels

between IT and the senior leadership team that enable risk information and recommendations to be easily communicated and acted upon.

Risk Report

Risk Event Action Plan

Organizations that were successful in gaining business involvement had approximately 59% more risk management success than organizations that did not.

Info-Tech Insight

The central goal of IT risk management is to provide clear and accurate interpretations of IT risk to the business regarding risk implications and response options. Ultimately, senior leadership is responsible for making decisions regarding all business 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

• 1.1 Review IT Risk Management Fundamentals
• 1.2 Establish a Risk Governance Framework

Phase 2

Identify and Assess IT Risk

• 2.1 Identify IT Risks
• 2.2 Assess and Prioritize IT Risks

Phase 3

Monitor, Communicate, and Respond to IT Risk

• 3.1 Monitor IT Risks and Develop Risk Responses
• 3.2 Communicate IT Risk Priorities

Use Info-Tech’s Risk Management Program Manual to build your customized risk management program

Phase-By-Phase Deliverables:

Phase 1

Review IT Risk Fundamentals and Governance:

1. Maturity Assessment
2. Stakeholder Map
3. IT Risk Council Charter

Phase 2

Identify and Assess IT Risk:

1. Acceptable Risk Thresholds
2. Risk Register (Standalone Deliverables)
3. Prioritized List of IT Risks

Phase 3

Monitor, Communicate, and Respond to IT Risk:

1. Risk Event Action Plan
2. Risk Reports (Standalone Deliverables)
3. IT Risk Recommendations

Use the tools and activities in each phase of the blueprint to create a comprehensive, customized program manual for the ongoing management of IT risk.

Risk Management Program Manual

Seize the potential of risk management to better align IT with the business

IT risk management is an opportunity to enhance IT’s profile in the eyes of the CEO, and to align IT with the organization’s strategic direction.

Risk is money, and minimizing risk is money saved. Use your risk management program to illustrate how IT creates value for the business.

Info-Tech Insight

Proactive risk management that translates IT risk into business language illustrates that IT decision-making is focused on how IT can add to and avoid detracting from business value.

Executive Brief case study – The board of a mid-sized, regional retailer asks IT to increase its risk management activities

CASE STUDY

Industry: Retail

Formalizing Risk Management

• During a disaster recovery planning session, the CIO received a mandate to improve IT’s risk management activities.
• Learning from past risk exposures, the CIO understood that risk management processes had to be formalized to ensure that activities were sustainable and that key risks were mitigated and reported on.
• To kick-start risk management, the CIO hired two Info-Tech Research Group analysts to accelerate the risk identification and assessment process.

The CIO was committed to identifying IT risks, presenting them proactively to the board, and getting their buy-in on risk responses. This ensured that when things went south, accountabilities are not directly relayed upon IT. – PMO Director

Completing Risk Management Activities

• A total of 96 critical risk events were identified and assigned appropriate risk owners to track and monitor risk events between annual assessments.
• The IT risk council assessed the severity of all 96 risk events cataloged in the risk portfolio. The exercise revealed:
• 26 Extreme Risk Events
• 22 Very-High Risk Events
• This analysis also revealed the highest risk area of IT:
• Security and Compliance Risks (26)
• It was determined that 28 projects were already underway and 24 new project requests needed to be created to tackle the top 31 IT risk events identified by the IT risk council.

Sustaining IT Risk Management

• To adequately mitigate key risks, the IT risk council determined that approximately $850,000 was needed to fund both new projects and projects already underway.
• The IT risk council presented their recommendations to the board of directors and successfully received needed funding.
• The IT risk council now meets on a quarterly basis to assess the risk portfolio and manage response projects.

One of the best outcomes of our Info-Tech engagement was the action plans that we received. This has helped keep the IT risk council on track and enables us to manage key IT risks that are being mitigated.– PMO Director

Appoint an owner of the IT risk management program and get started right now

Who should carry out this project?

The Ideal Risk Management Owner:

• Will have a comprehensive understanding of all IT functions, activities, and services.
• Will be able to lead a team of senior stakeholders.
• Will be an effective communicator and problem-solver with demonstrated ability to resolve conflicts and build relationships.
• Will have strong relationships with most areas and key executive stakeholders in the organization.
• Will have familiarity with risk management frameworks and methodologies.

Ideal Roles:

• CIO
• CRO
• Director of IT
• IT Risk Manager
• IT Security Manager
• IT Auditor

Primary Responsibilities:

1. Obtain approval for a permanent IT risk council, build the team, and lead regular meetings.
2. Communicate what IT is doing to proactively manage risk through its risk management program and serve as the primary point of contact for IT risk management.
3. Maintain ownership over all risk management processes, as well as the Risk Management Program Manual.

Benefit from industry-leading best practices

As a part of our research process, we utilized the M_o_R, RiskIT, and COBIT5 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.

The Government of the United Kingdom’s M_o_R framework provided best practices for IT risk governance, identification, and assessment.

M_o_R

RiskIT’s IT Risk Framework was modified to create Info-Tech’s IT Risk Management Framework.

RiskIT

COBIT5’s IT functions were used to develop and refine our Nine IT Risk Scenarios used in our top-down risk identification methodology.

COBIT5

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

DIY Toolkit

“Our team has already made this critical project a priority, and we have the time and capability, but some guidance along the way would be helpful.”

Guided Implementation

“Our team knows that we need to fix a process, but we need assistance to determine where to focus. Some check-ins along the way would help keep us on track.”

Workshop

“We need to hit the ground running and get this project kicked off immediately. Our team has the ability to take this over once we get a framework and strategy in place.”

Consulting

“Our team does not have the time or the knowledge to take this project on. We need assistance through the entirety of this project.”

Diagnostics and consistent frameworks used throughout all four options

Build a business-driven IT risk management program – project overview

Workshop overview

Contact your account representative or email Workshops@InfoTech.com for more information.

Phase 1

Review IT Risk Fundamentals and Governance

Build an IT Risk Management Program

Phase 1 outline

Call 1-888-670-8889 or email GuidedImplementations@InfoTech.com for more information

Complete these steps on your own, or call us to complete a guided implementation. A guided implementation is a series of 2-3 advisory calls that help you execute each phase of a project. They are included in most advisory memberships.

Guided Implementation 1: Review IT Risk Fundamentals and Governance

Proposed Time to Completion (in weeks): 2 weeks

Assess Current Maturity and Set Risk Management Program Goals

Start with an analyst kick off call:

• Discuss your objectives and organizational risk culture.
• Review your current risk management process maturity.

Then complete these activities…

• Develop risk management goals
• Develop SMART project metrics
• Create a stakeholder map

With these tools & templates:

Risk Management Program Manual

Engage Stakeholders and Establish an IT Risk Council

Review findings with analyst:

• Review key stakeholders and develop strategies to engage them.
• Discuss forming a permanent IT risk council.
• Define responsibilities and accountabilities.

Then complete these activities…

• Create the IT risk council
• Complete a RACI chart
• Engage key stakeholders in the risk identification process
• Add organization-specific risk scenarios

With these tools & templates:

Risk Management Program Manual

Phase 1 Results & Insights:

• Identified the current and target maturity of IT risk management.
• Established an IT risk council and began engaging key stakeholders in the IT risk management program.

Phase 1 (Section 1): Review IT Risk Management Fundamentals

Phase 1

Review IT Risk Fundamentals and Governance

• 1.1 Review IT Risk Management Fundamentals
• 1.2 Establish a Risk Governance Framework

Phase 2

Identify and Assess IT Risk

• 2.1 Identify IT Risks
• 2.2 Assess and Prioritize IT Risks

Phase 3

Monitor, Communicate, and Respond to IT Risk

• 3.1 Monitor IT Risks and Develop Risk Responses
• 3.2 Communicate IT Risk Priorities

OUTCOMES:

• Reviewed key IT principles and terminology
• Introduced to Info-Tech’s IT Risk Management Framework
• Gained understanding of the relationship between IT risk management and ERM
• Obtained the support of senior leadership

Abandon ad hoc risk management

Drivers of Formalized Risk Management:

Drivers External to IT

• External Audit
• Internal Audit
• Mandated by ERM

Grassroots Drivers

• Demonstrating IT’s value to the business
• Emerging IT risk awareness
• Proactive initiative

This section will provide you with a strong risk management foundation which will be valuable when building your IT risk management program.

This section covers the following IT risk fundamentals:

• 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

Realize the tangible IT and business benefits of a formal IT risk management program

Benefits of a Formal Risk Management Program for IT:

1. Increased on-time, in-scope, and on-budget completion of IT projects.
2. Meet the business’ service requirements.
3. Improved satisfaction of IT by senior leadership and business units.
4. Fewer resources wasted on fire-fighting.
5. Improved availability, integrity, and confidentiality of sensitive data.
6. More efficient use of resources.
7. Greater ability to respond to evolving threats.

Benefits of a Formal IT Risk Management Program for the Business:

1. Reduced operational surprises or failures.
2. Improved IT flexibility when responding to risk events and market fluctuations.
3. Reduced budget uncertainty.
4. Improved ability to make decisions when developing long-term strategies.
5. Improved stakeholder and shareholder confidence.
6. Achieved compliance with external regulations.
7. Competitive advantage over organizations with immature risk management practices.

Increase Risk Management Success by Implementing a Formal Program

Organizations with a formal risk management strategy had approximately 53% more risk management success than those who used an ad hoc approach.

Organizations with a formal risk management strategy were approximately 80% more successful in obtaining involvement from business stakeholders.

Familiarize yourself with key risk terminology

Review important risk management terms and definitions.

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 is business risk

Info-Tech Insight

The central goal of IT risk management is to provide clear and accurate interpretations of IT risk to the business regarding risk implications and response options. Ultimately, senior leadership is responsible for making decisions regarding all business risk.

ISACA’s COBIT 5 Methodology describes the relationship between IT risk and business risk:

“IT risk is business risk, specifically, the business risk associated with the use, ownership, operation, involvement, influence, and adoption of IT within an enterprise. IT risk consists of IT-related events that could potentially impact the business. IT risk can occur with both uncertain frequency and impact and creates challenges in meeting strategic goals and objectives.” (COBIT5)

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

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

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

Understand the four principles of IT risk management

Info-Tech’s Principles of IT Risk Management

1. Business alignment IT risk management must:
   1. reflect business priorities,
   2. be communicated in business terms, and
   3. integrate with enterprise risk management.
   Info-Tech Tools and Templates: Risk Report Risk Event Action Plan
2. Defined and enforced thresholds for (un)acceptable risk IT must work with the business to develop clearly defined risk thresholds that indicate if a risk requires a response action. Info-Tech Tools and Templates: Risk Register Tool
3. Cost-benefit analysis Risk-taking is neither inherently good nor bad. Determining which risks to accept and which risk responses to invest in requires a careful calculation of costs and benefits that must reflect the goals and risk appetite of the organization. Info-Tech Tools and Templates: Risk Costing Tool
4. Ongoing

Risk management is a program, not a project – there is no completion date. The IT threat landscape will not wait for you to catch up, so constant monitoring, identification, and assessment is necessary for you to avoid falling behind.

Info-Tech Tools and Templates:

See Info-Tech’s Revive Your Risk Management Program With a Regular Health Check blueprint.

Build a program manual as the cornerstone of your risk management program

Risk Management Program Manual

Use Info-Tech’s Risk Management Program Manual to document and communicate how IT risks are managed within your IT department.

• IT Risk Council Members
• Meeting and Activity Schedules
• Acceptable Risk Thresholds
• Risk Identification Methodologies
• Risk Event Action Plans
• Key Risk Indicators and Escalation Protocols
• Risk Reports

Risk Management Program Manual

Follow the steps in this blueprint to create your Risk Management Program Manual. This manual will house critical documents and outline all of the major activities of the risk management process. From risk identification to issue-tracking and escalation – create repeatable, iterative processes and document them in this central location. Use this document to:

• Standardize risk management processes.
• Communicate processes, timelines, and results to the central risk function or senior leadership.
• Enhance risk-awareness in IT.
• Train new hires in IT.
• Capture new knowledge from annual risk assessments.

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

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

Create a central risk folder to store all documents related to risk management

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

Build a central repository for risk-related documentation.

Use the folder to store:

1. The Risk Management Program Manual
2. Risk Event Action Plans for each risk event
3. Annual or bi-annual Risk Reports
4. The Risk Register
5. The Risk Costing Tool

Look for this symbol throughout the blueprint prompting you to upload a completed deliverable into the risk management folder.

Note: Responsibility for updating and managing this folder will be assigned in section 1.2 when building an IT risk council.

This central risk file should only be accessible by the IT risk council. This ensures governance around risk management and ensures that other individuals are not bypassing the IT risk council to add risks to the risk register or request funding from senior stakeholders to mitigate a risk.

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

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 Monitor IT Risks and Develop Risk Responses
• 3.2 Communicate IT Risk Priorities

ACTIVITIES:

1. 2.1 Assess current program maturity
2. 2.2 Identify obstacles and pain points
3. 2.3 Determine the risk culture of the organization
4. 2.4 Develop risk management goals
5. 2.5 Develop SMART Project Metrics
6. 2.6 Create a stakeholder map
7. 2.7 Create the IT risk council
8. 2.8 Complete a RACI chart

OUTCOMES:

Developed goals for the risk management program

Established the IT risk council

Assigned accountability and responsibility for risk management processes

Create an IT risk governance framework that integrates with the business

Risk Governance

Optimize Processes

Manage Stakeholders & Assign Accountability

Measure the Success of the Program

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

In this section:

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.

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.

Self-assess your current approach to risk management

Optimize Processes

1.2.1 Assess current risk management maturity

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

A. Governance

B. Identification

C. Assessment

D. Monitoring & Reporting

E. Response Development

Instructions:

1. Use Info-Tech’s maturity models on the next three slides to assess your maturity for all five processes. Compare your current practices to the definitions of ad hoc, defined, and optimized provided for each of the five processes and determine which label best describes your current practices.
2. Document the maturity level for each of the five processes in section 2.2 of the Risk Management Program Manual.
3. The Risk Management Program Manual provides sample current process practices that describe an optimized maturity level for each process (i.e. process best practices). Use these sample practices if they reflect your own, or revise them to describe your current state.

Risk Governance describes the development of mature risk management processes and institutions within the organization that encourage the formalization of risk management.

Document the process steps and current process practices of each risk management process in your Risk Management Program Manual.

Match the characteristics of your existing risk management processes to the table below (1 of 3)

(Continued) Match the characteristics of your existing risk management processes to the table below (2 of 3)

(Continued) Match the characteristics of your existing risk management processes to the table below (3 of 3)

Anticipate challenges to formalizing IT risk management

1.2.2 Identify obstacles and pain points

Anticipate potential challenges and “blind-spots” by determining which of these success factors are missing from your current situation.

IT Risk Management Success Factors

Support and sponsorship from senior leadership

• IT risk management has more success when initiated by a member of the senior leadership team or the board, rather than emerging from IT as a grassroots initiative.
• Sponsorship increases the likelihood that risk management is prioritized and receives the necessary resources and attention. It also ensures that IT risk accountability is assumed by senior leadership.

Organization size

• Smaller organizations can often institute a mature risk management program much more quickly than larger organizations.
• It is common for key personnel within smaller organizations to be responsible for multiple roles associated with risk management, making it easier to integrate IT and business risk management.
• Larger organizations may find it more difficult to integrate a more complex and dispersed network of individuals responsible for various risk management responsibilities.

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.

Instructions:

List the potential obstacles and missing success factors that you must overcome to effectively manage IT risk and build a risk management program. Use this list in Activity 1.2.4 to develop program goals.

Determine the risk culture of your organization

1.2.3 Determine the risk culture of the organization

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

Risk Tolerant

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

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

Info-Tech Insight

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

Develop goals for the IT risk management program

1.2.4 Develop risk management goals

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

Instructions:

1. In the Risk Management Program Manual, revise, replace, or add to the high-level goals provided.
2. Make sure that you have 3–5 high-level goals that reflect the current and targeted maturity of IT risk management processes.
3. Integrate potential obstacles, pain points, and insights from the organization’s risk culture.

Document your goals in section 2.4 of your Risk Management Program Manual

Attach metrics to your goals to gauge the success of the IT risk management program

Measure the Success of the Program

1.2.5 Develop SMART project metrics

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

Instructions:

1. Document a list of appropriate metrics to assess the success of the IT risk management program on a whiteboard.
2. Use the sample metrics listed in the table on the next slide as a starting point.
3. Fill in the chart to indicate the:

a) Name of the success metric.

b) Method for measuring success.

c) Baseline measurement.

d) Target measurement.

e) Actual measurements at various points throughout the process of improving the risk management program.

f) A deadline for each metric to meet the target measurement.

Ensure that all success metrics are SMART

(Continued) Attach metrics to your goals to gauge the success of the IT risk management program

1.2.5 Develop SMART project metrics

Sample Metrics

Include the frequency (i.e. per year, per week, per service) and unit of measurement ($, %) where applicable.

Identify the location of the relevant data, or the methodology for obtaining it.

Measure or approximate the current state and determine a goal for each metric.

Create a concrete deadline that affords you enough time to realize project gains.

Determine checkpoints to track progress and record the final measurement at the deadline.

Identify stakeholders and map them according to their influence over, and interest in, IT risk management

Manage Stakeholders

1.2.6 Create a stakeholder map

Relevant stakeholders can include individuals, groups, or entire business units.

Instructions:

1. Develop a list of stakeholders.
• A stakeholder is anyone affected by a decision and interested in its outcome (M_o_R, 2007).
2. Draw the 2x2 stakeholder map on a whiteboard and chart each stakeholder in the appropriate quadrant.
3. Take a picture of the whiteboard so you can reference the map when you create the IT risk council (Activity 1.2.7) and build the RACI chart (Activity 1.2.8).

Info-Tech Insight

Occasionally, groups or individuals outside of IT that have low interest in IT risk management should be highly interested, but are unaware of the impact that IT risk has on their objectives. Use tactics outlined in section 1.1 to bring them on board. For the sake of this exercise, map stakeholders according to how interested they should be.

Create the IT risk council (ITRC) using Info-Tech’s IT Risk Council Charter

1.2.7 Create the IT risk council

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 Council 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.
• Typically, mature risk management programs mandate monthly meetings.
3. In section 3.4, document members of the IT risk council.
• Typically, an effective council will have between 5 and 10 members.
• Leverage tips found here to encourage the participation of senior leadership.
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.

Must be on the ITRC:

• CIO
• CRO (if applicable)
• Senior Directors
• Security Officer
• Head of Operations

Should be on the ITRC:

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

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

Use Info-Tech’s Job Description – Chief Risk Officer to aid the CIO in formalizing your risk management program

Even without an appointed Chief Risk Officer (CRO), ensure that the required responsibilities are delegated to the appropriate members on the ITRC using Info-Tech’s Chief Risk Officer Job Description located in Appendix D of the Risk Management Program Manual.

Summary of CRO Responsibilities:

Strategy and Planning

• Work with the business to align IT with business unit security and compliance needs.
• Create and communicate strategies for risk responses.
• Classify and evaluate enterprise data assets.
• Project and track costs of risk management initiatives.
• Identify and deploy standard risk assessment models.

Acquisition and Deployment

• Assess all IT purchases to ensure they support security and compliance mandates.

Operational Management

• Track and measure the enterprise’s risk appetite.
• Review day-to-day management of IT security operations.
• Plan and oversee risk response projects.
• Develop and deliver risk awareness training for key staff and stakeholders.

CRO Job Description in the Risk Management Program Manual.

Assign risk management accountabilities and responsibilities to key stakeholders

1.2.8 Complete RACI chart

RACI diagrams are an effective way to describe how accountability and responsibility for particular roles, projects, and project tasks are distributed amongst stakeholders involved in IT risk management.

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

RACI is an acronym made up of four participatory roles:

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

Instructions:

1. Use the template provided on the following slide, and add key stakeholders identified in Activity 1.2.6 that do not appear.
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.

(Continued): Assign risk management accountabilities and responsibilities to key stakeholders

1.2.9 Complete RACI chart

Customize the RACI Chart by adding or subtracting rows.

Part 1: The board of a mid-sized, regional grocery retailer asks IT to increase its risk management activities

CASE STUDY

Industry

Retail Grocer

Call to Action

• The growth of a local retail grocer to a mid-sized regional grocery market prompted the board of directors to implement disaster recovery protocols.
• During a proactive disaster recovery planning session, the CIO of the 40-person IT department received a mandate to improve IT’s risk management activities.
• The CIO realized that to conduct successful risk management, they had to avoid:
1. Using inconsistent approaches to identify risks.
2. Misaligning IT’s risk recommendations with organizational priorities.
3. Not following through with risk responses.

Formalizing Risk Management

• Learning from past risk exposures, the CIO understood that risk management processes had to be formalized to ensure that activities were sustainable and that key risks were mitigated and reported on.
• A formalized, annual risk management process and IT risk council were implemented.

"The CIO was committed to identifying IT risks, presenting them proactively to the board, and getting their buy-in on risk responses. This ensured that when things went south, accountabilities are not directly relayed upon IT."

– PMO Director

Implementing an IT Risk Council

1. The CIO and the Application, Infrastructure, and PMO Directors formed an IT risk council that was responsible for:

a) Updating the risk management portfolio on a quarterly basis.

b) Maintaining a prioritized register of IT risks.

c) Presenting key risks and risk responses to the board.

d) Delegating risk ownership internally and overseeing appropriate risk responses when necessary.

" We defined a small IT risk council to avoid and limit the dilution of accountabilities of the group."

– PMO Director

Phase 1 Outcomes

Phase 1

Review IT Risk Fundamentals and Governance

1.1

1.2

1. Maturity Assessment
2. Stakeholder Map
3. IT Risk Council Charter

Phase 2

Identify and Assess IT Risk

• 2.1 Identify IT Risks
• 2.2 Assess and Prioritize IT Risks

Phase 3

Monitor, Communicate, and Respond to IT Risk

• 3.1 Monitor IT Risks and Develop Risk Responses
• 3.2 Communicate IT Risk Priorities

Phase 2

Identify and Assess IT Risk

Build an IT Risk Management Program

Phase 2 outline

Call 1-888-670-8889 or email GuidedImplementations@InfoTech.com for more information.

Complete these steps on your own, or call us to complete a guided implementation. A guided implementation is a series of 2-3 advisory calls that help you execute each phase of a project. They are included in most advisory memberships.

Guided Implementation 2: Identify and Assess IT Risk

Proposed Time to Completion (in weeks): 2 weeks

Identify IT Risks

Start with an analyst kick off call:

• Review organization-specific risk scenarios.
• Discuss risk identification techniques.
• Share common IT risk events.

Then complete these activities…

• Identify risk events.
• Augment risk event list using COBIT 5 processes.
• Determine the threshold for (un)acceptable risk.
• Create a financial impact assessment scale.
• Select a technique to measure reputational cost.
• Create a probability scale.

With these tools & templates:

• Risk Register Tool
• Risk Management Program Manual

Assess and Prioritize IT Risks

Review findings with analyst:

• Review risk event list, thresholds, and scales.
• Discuss risk assessment methodologies and best practices.
• Discuss business stakeholder engagement.

Then complete these activities…

• Conduct risk severity level assessment.
• Document the proximity of the risk event.
• Conduct expected cost assessment.

With these tools & templates:

• Risk Register Tool
• Risk Costing Tool
• Risk Management Program Manual

Phase 2 Results & Insights:

• A comprehensive list of all IT risks is developed and assessed.
• Risks are prioritized according to the severity of the risk, as defined by the business.

Phase 2 (Section 1): Identify IT Risks

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 Monitor IT Risks and Develop Risk Responses
• 3.2 Communicate IT Risk Priorities

ACTIVITIES:

2.1.1 Engage key stakeholders

2.1.2 Add organization-specific risk scenarios

2.1.3 Identify risk events

2.1.4 Augment risk event list using COBIT 5 processes

2.1.5 Conduct a PEST analysis

2.1.6 Input risks into the Risk Register Tool

OUTCOMES:

Participation of key stakeholders

Comprehensive list of IT risk events

Get to know what you don’t know

Risk Identification

Engage Stakeholder Participation

Utilize Risk Identification Frameworks

Compile IT-Related Risks

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

What you don’t know CAN hurt you.

In this section:

1. Engage the right stakeholders in risk identification.

By encouraging the participation of relevant business units and senior leadership in risk identification exercises, you significantly decrease the chances of omitting a key risk.

2. Employ Info-Tech’s top-down approach to risk identification.

The nine risk categories introduced in this section serve as useful signposts to guide brainstorming activities and organize risks according to IT’s core functions.

3. Augment your risk event list using alternative frameworks.

Be confident that no risk is able to slip through the cracks by evaluating your risk portfolio with all of the COBIT 5 IT processes.

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.

Ensure that all key risks are identified by engaging key business stakeholders

Engage Stakeholder Participation

Instructions:

1. Reach out to key business stakeholders identified in exercise 1.2.6 to participate in risk identification exercises.
2. If they are unable to attend, request that they review your completed risk register and provide feedback.
3. Document participants in section 5.1 of the Risk Management Program Manual.

Benefits of obtaining business involvement during the risk identification stage:

You will identify risk events that you had not considered or that you weren’t aware of.

• The business can offer perspectives on risks that IT may have overlooked.

You will identify risks more accurately.

• The business can reinforce IT’s knowledge about particular risks, and their overall impact on the organization.

Risk identification is an opportunity to raise awareness of IT risk management early in the process.

• IT will raise its credibility by actively addressing the business’ concern about risk.

Organizations that were able to engage the business in risk identification were 79% more successful in identifying all risks than organizations where business participation was minimal.

(Continued) Ensure that all key risks are identified by engaging key business stakeholders

2.1.1 Engage key stakeholders

Alternative Perspectives

All business units rely on the services and technologies that IT provides. They likely possess alternative perspectives on:

1. The value that IT provides to the business.
2. The corresponding business risk associated with the inability of IT to support business activities.

Prioritizing and Selecting Stakeholders

Obtaining the participation of every business unit may be a challenge. Prioritize stakeholders from the business using the following criteria:

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

Obtaining business involvement when identifying risk is important because it is often a pre-cursor to future business involvement during the risk assessment and risk response phases.

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

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.

Top-down risk identification enables IT to target risk holistically using Info-Tech’s nine risk categories

Compile IT-Related Risks

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 nine risk categories encapsulate the services, activities, responsibilities, and functions of most IT departments. Use these categories and the example risk scenarios provided as prompts to guide brainstorming and organize risks.

Risk Category: High-level groupings that describe risk pertaining to major IT functions. See the following slide for all nine 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 2–5 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.

Add risk scenarios to the examples provided under each risk category

2.1.2 Add organization-specific risk scenarios

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

Operations Risks

• Enterprise architecture
• Technology evaluation & selection
• Capacity planning
• Operational errors

Hardware Risks

• Hardware implementation errors
• Hardware configuration errors
• Hardware maintenance errors
• Hardware performance
• Theft
• Damage/destruction
• Hardware obsolescence

Software Risks

• Software implementation errors
• Software configuration
• Software maintenance
• Software performance
• Software obsolescence

Project Risks

• Project scoping
• Project quality
• Project time over-runs
• Project cost over-runs

Personnel Risks

• IT staffing
• IT skills and experience

Data Risks

• Data theft
• Data integrity
• Data confidentiality
• Data availability

Vendor Risks

• Vendor selection
• Vendor management
• Contract termination

Disaster & Business Continuity Risks

• Acts of nature (hurricane, etc.)
• Utility performance
• Industrial action
• System failure

Compliance & Security Risks

• Regulatory compliance
• Malware
• Externally originated attack
• Internally originated attack

Identify risk events

2.1.3 Identify risk events

Use Info-Tech’s risk categories and scenarios to brainstorm a comprehensive list of IT-related threats and vulnerabilities impacting your organization.

Instructions:

1. Prepare a large space on a whiteboard to document risk events.
2. List risk scenarios (organized by risk category) across the top of the whiteboard.
3. While the brainstorming process should be informal, assign one individual to guide the session and encourage equal participation from all participants to avoid having the exercise dominated by a few voices.
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.

Facilitator Tips

Tip: Assign an individual from the ITRC to take a photo of the whiteboard and then collect, organize, and store the sticky notes in a safe place until the risk is finalized and inputted into the Risk Register Tool.

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.

(Optional) Augment the risk event list using alternative processes

Utilize Risk Identification Frameworks

2.1.4 Augment the risk event list using COBIT 5 processes

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 5’s 37 IT processes and identify additional risk events.
2. Match risk events to the corresponding risk category and scenario and add them to the whiteboard.

Source: Cobitonline

1. Manage the IT Management Framework
2. Manage Strategy
3. Manage Enterprise Architecture
4. Manage Innovation
5. Manage Portfolio
6. Manage Budget and Costs
7. Manage Human Resources
8. Manage Relationships
9. Manage Service Agreements
10. Manage Suppliers
11. Manage Quality
12. Manage Risk
13. Manage Security
14. Manage Programs and Projects
15. Manage Requirements Definition
16. Manage Solutions Identification and Build
17. Manage Availability and Capacity
18. Manage Organizational Change Enablement
19. Manage Changes
20. Manage Change Acceptance and Transitioning
21. Manage Knowledge
22. Manage Assets
23. Manage Configuration
24. Manage Operations
25. Manage Service Requests and Incidents
26. Manage Problems
27. Manage Continuity
28. Manage Security Services
29. Manage Business Process Controls
30. Monitor, Evaluate, and Assess Performance and Conformance
31. Monitor, Evaluate, and Assess the System of Internal Control
32. Monitor, Evaluate, and Assess Compliance With External Requirements
33. Ensure Governance Framework Setting and Maintenance
34. Ensure Benefits Delivery
35. Ensure Risk Optimization
36. Resource Optimization
37. Stakeholder Transparency

(Optional) Finalize your risk register by conducting a PEST analysis

2.1.5 Conduct a PEST Analysis

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

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

Consider the External Environment

PEST Analysis

Despite efforts to encourage equal participation in the risk identification process, key risks may not have been shared in previous exercises.

Conduct a PEST analysis as a final safety net to ensure that all key risk events have been identified.

List the following factors influencing the risk event:

• Political factors
• Economic factors
• Social factors
• Technological factors
• Environmental factors

Avoid “Groupthink”

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.

Input risk events into the Risk Register Tool

2.1.6 Input risks into the Risk Register Tool

The finalized risk event list must be inputted into the Risk Register Tool to prepare for risk assessment.

Instructions:

1. Transcribe the risk event list from the whiteboard into the Risk Register Tool.
2. Transcribe the risk event list from the whiteboard into the Risk Register Tool.
• Consult the RACI chart located in section 4.1 of the Risk Management Program Manual.
3. Incorporate feedback and finalize the risk event list.
4. Select an individual from the ITRC to copy a finalized risk event list into the Risk Register Tool.

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

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.

Phase 2 (Section 2): Assess and Prioritize IT Risks

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 Monitor IT Risks and Develop Risk Responses
• 3.2 Communicate IT Risk Priorities

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

2.2.5 Risk severity level assessment

2.2.6 Document the proximity of the risk event

2.2.7 Expected cost assessment

OUTCOMES:

Business-approved thresholds for unacceptable risk

Completed Risk Register Tool with risks prioritized according to severity

Expected cost calculations for high-priority risks

Carefully assess the severity of each risk event to reveal the organization’s greatest IT threats and vulnerabilities

Risk Assessment

Establish Thresholds for Unacceptable Risk

Calculate Expected Cost

Determine Risk Severity & Prioritize IT 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 rigour
• 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

In this section:

Follow the steps to assess and prioritize IT risks.

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.

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.

Maintain the engagement of key stakeholders in the risk assessment process

Encourage the continued participation of business stakeholders to dramatically increase the success of risk assessment.

An Info-Tech survey found that only 40% of IT departments that assessed risks without business involvement perceived their risk assessment to be successful, while 97% of organizations that involved business stakeholders reported success.

Where business participation pays off most:

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

Involve members of the senior leadership team such as the CIO, CRO, CFO, and CEO in the threshold setting exercise.

(Continued) Maintain the engagement of key stakeholders in the risk assessment process

1. Don’t expect the business to participate in risk assessments, but use them as the final piece to the assessment puzzle.

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 and/or unacceptable risk.

2. Verify risk impact and likelihood assessments.

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. Take note of the business’ interests and where the business stakeholders focus their 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.

Finally, if the business won’t provide their time...

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

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 2-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 probability and impact “levels.”

Time required: 1–5 minutes per risk event.

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

• By creating a probability and impact assessment scale divided into 3–9 “levels” (sometimes referred to as “buckets”), you can evaluate every risk event quickly, while being confident that risks are being assessed accurately.
• In the following activities, you will create probability and impact scales that align with your organizational risk appetite and tolerance.
• Severity-level assessment is a “first pass” of your risk list, revealing your organization’s most severe IT risks, which can be assessed in greater detail by incorporating expected cost into your evaluation.

(Continued) Info-Tech recommends a 2-level approach to risk assessment

Expected cost assessment (optional)

2

Information

Number of risks: Only assess high-priority risks revealed by severity-level assessment.

Units of measurement: Use actual probability values (%) and impact costs ($).

Time required: 10–20 minutes per risk event.

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 probability values and precise impact estimates can be challenging and time-consuming.
• Some risk events may require extensive data-gathering and industry analysis.

Use Info-Tech’s Risk Register Tool to assess and prioritize IT risk events

Risk Register Tool

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.

In the following activities, you will:

1. Develop risk thresholds approved by the business.
2. Create scales for probability and impact.
3. Assess the probability and impact for all identified risk events.
4. Prioritize risk events according to risk severity.

Risk Register Tool

Identify a threshold for (un)acceptable risk

Establish Thresholds for Unacceptable Risk

2.2.1 Determine the threshold for (un)acceptable risk

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

Instructions:

There are times when the business needs to know about IT risks with high expected costs.

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 probability scales with this value in mind, ensuring that “high” or “extreme” risks are immediately communicated to senior leadership.

Do not consider IT budget restrictions when developing this number. The acceptable risk threshold should reflect the business’ tolerance/appetite for risk (review activity 1.2.3 if necessary).

• This threshold is typically based on the organization’s ability to absorb financial losses, and its tolerance/appetite towards risk.
• If your organization has ERM, adopt the existing acceptability threshold.

Record this threshold in section 5.3 of the Risk Management Program Manual.

Participants:

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

Create a financial impact assessment scale

2.2.2 Create a financial impact assessment scale

Instructions:

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

a. Typically, risk impacts are assessed on a scale of 1–5; however, some organizations may prefer to assess risks using 3, 7, or 9 point scales.

2. Ensure that the unacceptable risk threshold is reflected in the scale.

a. 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.
4. Record the risk impact scale in section 5.3 of the Risk Management Program Manual.

Participants:

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

Incorporate project overruns and service outages into financial impact scales

Time is money. Convert project overruns and service outages into costs.

Use the tables below to quickly convert impacts typically measured in units of time to financial cost. Replace the values in the table with those that reflect your own costs.

• While project overruns and service outages may have intangible impacts beyond the unexpected costs stemming from paying employees and lost revenue (such as adding complexity to project management and undermining the business’ confidence in IT), these measurements will provide adequate impact estimations for risk assessment.
• Remember, complex risk events can be analyzed further with an expected cost assessment.

Project Overruns

Service Outages

Incorporate reputational cost into risk assessments (1 of 3)

2.2.3 Select a technique to measure reputational cost

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

Reputational cost can take several forms, including the internal and external perception of:

A Brand likeability

B Product quality

C Leadership capability

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

Everything an organization does or says creates an indelible impression in the minds of its key stakeholders – senior management, employees, customers, local communities, investors, and so on. The sum total of all these interactions represents your reputation (Oliver Wyman).

– Richard Smith-Bingham, Director of Global Risk Center, Oliver Wyman

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

Incorporate reputational cost into risk assessments (2 of 3)

2.2.3 Select a technique to measure reputational cost

It is common for public sector or not-for-profit organizations to have difficulty putting a price tag on intangible reputational costs.

• For example, a government organization may be unable to directly quantify the cost of losing confidence and/or support of the public.
• A helpful technique is to reframe how reputation is assigned value.

Technique #2

Calculate the value of avoiding reputational cost:

1. Imagine that the particular risk event you are assessing has occurred. Describe the resulting reputational cost using qualitative language.

For example:

• A data breach which caused the unsanctioned disclosure of 2,000 client files has inflicted high reputational costs on the organization. These have impacted the organization in the following ways:
• Loss of organizational trust in IT
• IT’s reputation as a value provider to the organization is tarnished
• Loss of client trust in the organization
• Potential for a public reprimand of the organization by the government to restore public trust
2. Then, determine (hypothetically) how much money the organization would be willing to spend to prevent the reputational cost from being incurred.
3. Match this dollar value to the corresponding level on the impact scale created in Activity 2.2.2.

Incorporate reputational cost into risk assessments (3 of 3)

2.2.3 Select a technique to measure reputational cost

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

Technique #3

Create a parallel scale for reputational impact:

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?

Create a probability scale

2.2.4 Create a probability scale

Instructions:

1. Create a scale to assess the probability that a risk event will occur over a given period of time.

a) Info-Tech recommends assessing the probability that the risk event will occur over a period of one year (the IT risk council should be reassessing the risk event no less than once per year).

2. Ensure that the probability scale contains the same number of levels as the financial impact scale (3, 5, 7, or 9).
3. The example provided is likely to satisfy most IT departments – however, you may customize the distribution of probability values to reflect the organization’s aversion towards uncertainty.

a) For example, an extremely risk averse organization may consider any risk event with a probability greater than 20% to have a “High” probability 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.

Info-Tech Insight

Note: Info-Tech endorses the use of probability values (1–99%) rather than frequency (3 times per year) as a measurement of likelihood.

For an explanation of why probability values lead to more precise and robust risk assessment, see the Appendix.

Assess all identified risk events using the Risk Register Tool

Determine Risk Severity & Prioritize IT Risks

2.2.5 Risk severity level assessment

Assess the probability of occurrence and probable impact for all identified risk events.

Participants:

• IT risk council
• Relevant business stakeholders
• Representation from the senior leadership team

Instructions:

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

(Continued) Assess all identified risk events using the Risk Register Tool

2.2.5 Risk severity level assessment

Instructions (continued):

5. 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 this slide for advice on how to select a risk owner and information on their responsibilities.

6. As you input the first few probability 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 probable than a 1 hour web-services outage?

Tips for Selecting Probability Values:

Does ~10% sound right?

Test a probability estimate by assessing the truth of the following statements:

• The risk event will likely occur once in the next 10 years (if the environment remains nearly identical).
• If 10 organizations existed that were nearly identical to our own, it is likely that 1 out of 10 would experience the risk event this year.

Identify existing risk controls

Consider how IT is already addressing key risks.

Types of existing risk controls

Tactical controls

Apply to individual risks only.

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

Strategic controls

Apply to multiple risks.

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

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.

Risk Owner Responsibilities

Risk ownership means that an individual is responsible for the following activities:

• Monitoring the threat or vulnerability for changes in the probability of occurrence and/or probable 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.

Determine how timing impacts your risks

2.2.6 Determine the proximity of the risk event

Instructions:

1. Go through the register of risk events that have been assessed and identify risks where urgency and timing may impact the severity of the risk, and how it should be responded to.
• Focus on “High” and “Extreme” risks.
2. Describe the proximity of these risk events in the Risk Register Tool.
• For example: “The probability of the risk event will decrease when the new IT budget is released on January 1st.”
3. Use the following questions to help you construct proximity descriptions.
• Is the risk event specific to one particular point in time?
• Will the severity of the risk event increase over time?
• Will the severity of the risk event increase at one particular point in time?
• Will the severity of the risk event decrease over time?
• Will the severity of the risk event decrease at one particular point in time?
• Note: See examples on the following slide.

What is risk proximity?

The impact and probability of a risk event often fluctuate over time. The relationship between risk severity and time is called the proximity of the risk.

• These fluctuations are often unpredictable. However, occasionally you may possess knowledge about how time will impact a particular risk.
• While the risk severity assigned to each risk in the Risk Register Tool informs senior management about the relative importance of each risk event, the proximity description informs senior management about the urgency of the risk event and important timing considerations for implementing risk responses.
• For example, specific project risks only exist while the project is underway.
• The probability of a project overrun may be considerably higher during a specific project phase.

Understand how risk proximity can impact decision-making

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

Risk severity is constant.

E.g. Risk of losing key personnel.

Risk severity is concentrated at a particular point in time.

E.g. Risk of data breach leading up to new product launch.

Risk severity increases/decreases after a particular point in time.

E.g. Risk of project overrun after layoffs.

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

Risk Costing Tool

Use this tool to:

This section

1. Conduct a deeper analysis of severe risks.
• Determine specific probability 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.

Section 3.1

2. Assess the effectiveness of multiple risk responses for each risk event.
• Determine how proposed risk events will change the probability 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.

In the following activities, you will:

1. Select top risk events for expected cost assessment (approx. 10–15 risk events)
2. Determine probability values
3. Determine the probable financial impact
4. Determine the maximum financial impact
5. Calculate a risk event’s expected cost

Risk Costing Tool

(Optional) Assign probability and financial impact values to high-priority risks

Calculate Expected Cost

2.2.7 Expected cost assessment

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.

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 probability estimates.
• There is general consensus on financial impact estimates.
• Historical data exists to support estimates.

Record the list of risk events requiring second-level assessment in the Risk Costing Tool.

• Transfer the probability and impact levels for each event into the Risk Costing Tool using data from the Risk Register Tool.

(Continued) Assign probability and financial impact values to high-priority risks

2.2.7 Expected cost assessment

Instructions:

1. Go through the list of prioritized risks in the Risk Costing Tool one by one. On a whiteboard, indicate the probability and impact level (from the Risk Register Tool) for the risk event being assessed.
2. Go around the room and record probability values (1–99%) and impact values ($) from participants.
• Only record values from individuals that indicate that they are fairly confident with their estimates.
• Keep probability estimates to values that are multiples of five.
3. Estimate and record the maximum impact that the risk event could inflict.
• See Appendix II 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 probability 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 probability level “Moderate” (20–39%). Select a probability value of 30%.

Who should participate?

• Depending on the size of your IT risk council, you may want to consider conducting this exercise in a smaller group.
• Ideally, you should try to find the right balance between ensuring that the necessary experience and knowledge is in the room, while insulating the exercise from outlier opinions, noise, and distractions.

Employ common techniques to evaluate probability and impact

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

Intersubjective Probability

The goal of the expected cost assessment is to develop robust intersubjective estimates of probability 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.

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.

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 probability, probable 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.

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.

Part 2: The retailer hired a facilitator to conduct comprehensive risk identification and risk assessment

Part 2 of 3

Continued in the next phase

CASE STUDY

Industry:Retail Grocer

Launching Risk Identification

• To kick-start risk management, the CIO hired two Info-Tech Research Group analysts to accelerate the risk identification and assessment process.
• The facilitators and the IT risk council walked through Info-Tech’s nine IT risk categories. This exercise was augmented by reviewing COBIT processes and documenting relevant risk exposures.
• A total of 96 critical risk events were identified and assigned appropriate risk owners to track and monitor risk events between annual assessments.

Determining Risk Thresholds

• The IT risk council discussed organizational risk tolerance and appetite to determine scales for risk impact and probability, as well as a threshold for unacceptable risk.
• They selected the following scale for financial impact:
• Low: less than $20,000
• Moderate: less than $250,000
• Extreme: greater than $900,000
• They selected the following scale for probability:
• Low: less than 10%
• Moderate: less than 30%
• Extreme: greater than 50%
• The IT risk council presented thresholds to the board of directors and received approval.

Assessing Risk Severity

• The IT risk council and Info-Tech facilitators assessed the severity of all 96 risk events cataloged in the risk portfolio. The exercise revealed:
• 26 Extreme Risk Events
• 22 Very-High Risk Events
• The group followed this exercise by reviewing the distribution of risk events within each of Info-Tech’s nine IT risk categories.
• This analysis revealed their 3 highest risk areas of IT:
• Security and Compliance Risks (26)
• IT Governance Risks (17)
• IT Operational Risks (17)

Phase 2 Outcomes

Phase 1

Review IT Risk Fundamentals and Governance

1.1

1.2

1. Maturity Assessment
2. Stakeholder Map
3. IT Risk Council Charter

Phase 2

Identify and Assess IT Risk

1. Acceptable Risk Thresholds
2. Risk Register
3. Prioritized List of IT Risks

Phase 3

Monitor, Communicate, and Respond to IT Risk

• 3.1 Monitor IT Risks and Develop Risk Responses
• 3.2 Communicate IT Risk Priorities

Phase 3

Monitor, Communicate, and Respond to IT Risk

Build an IT Risk Management Program

Phase 3 outline

Call 1-888-670-8889 or email GuidedImplementations@InfoTech.com for more information.

Complete these steps on your own, or call us to complete a guided implementation. A guided implementation is a series of 2-3 advisory calls that help you execute each phase of a project. They are included in most advisory memberships.

Guided Implementation 3: Monitor, Communicate, and Respond to IT Risk

Proposed Time to Completion (in weeks): 1 week

Monitor IT Risks and Develop Risk Responses

Start with an analyst kick off call:

• Review and refine prioritized list of IT risks.
• Discuss risk monitoring roles and responsibilities.
• Analyze top risks and brainstorm risk response options.

Then complete these activities…

• Develop KRIs and escalation protocols.
• Conduct root cause analysis.
• Identify and assess risk responses.
• Conduct risk response cost-benefit analysis.

With these tools & templates:

• Risk Register Tool
• Risk Costing Tool
• Risk Management Program Manual
• Risk Event Action Plan

Communicate IT Risk Priorities

Review findings with analyst:

• Refine risk priorities and recommendations.
• Discuss gaining approval from senior leadership.
• Discuss transforming risk responses into projects.
• Discuss embedding a risk culture in IT.

Then complete these activities…

• Obtain executive approval for risk action plans.
• Publish the risk report.
• Transfer ownership of risk responses to project managers.
• Finalize the Risk Management Program Manual.

This is the content for Layout P Tag

• Risk Event Action Plan
• Risk Report
• Risk Management Program Manual

Phase 3 Results & Insights:

• IT risk recommendations are communicated to, and approved by, the business.
• The Risk Management Program Manual is published.

Phase 3 (Section 1): Monitor IT Risks and Develop Risk Responses

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 Monitor IT Risks and Develop Risk Responses
• 3.2 Communicate IT Risk Priorities

ACTIVITIES:

3.1.1 Develop key risk indicators (KRIs) and escalation protocols

3.1.2 Establish the reporting schedule

3.1.3 Root cause analysis

3.1.4 Identify contributing factors

3.1.5 Identify and assess risk responses

3.1.6 Risk response cost-benefit analysis

3.1.7 Create multi-year cost projections

OUTCOMES:

Completed risk event action plans

Risk responses identified and assessed for top risks

Risk response selected for top risks

Select the most effective response to your high-priority risks

Risk Response

Establish Monitoring Responsibilities

Perform Cost-Benefit Analysis

Identify Risk Response Actions

Key metrics:

• Number of top risks without an identified risk response.
• Percentage of risk events with a positive expected cost.
• Number and severity of realized risk events that were accepted by the business.
• Total number of risk responses assigned.
• Percentage of risk responses funded and turned into projects.
• Expected cost of implementing risk responses.
• True cost of implementing risk responses.
• Number of risk event action plans reviewed by senior leadership.

In this section:

1. Actively monitor threats and vulnerabilities.
2. Identify risk response actions that will address top risks.
3. Perform cost-benefit analyses to assess the effectiveness and appropriateness of risk responses.

Organizations with a formal program for managing IT risk were 31% more successful in mitigating risk than organizations with an ad hoc approach (Info-Tech Research Group, N=76 ).

Info-Tech Insight

Merely being aware of your greatest risks is not enough. IT departments with a formal program for managing risk are more successful because they possess mechanisms that turn risk priorities into fully-funded projects that have the support of the business.

Use Info-Tech’s Risk Event Action Plan to manage high-priority risks

Establish Monitoring Responsibilities

Risk Event Action Plan

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

Document the following information in the Risk Event Action Plan:

1. Risk event
2. Risk severity level
3. Risk owner
4. Key risk indicators (KRIs)
5. Delegation of risk monitoring responsibilities (if applicable)
6. Risk escalation protocols
7. Risk monitoring and reporting schedule
8. Risk response action to be taken
9. Leadership review and approval

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.

Risk Event Action Plan

Develop KRI metrics to track changes in risk severity

3.1.1 Develop key risk indicators (KRIs) and escalation protocols

Clearly document the risk owner and the individual(s) carrying out risk monitoring activities (delegates) in the Risk Event Action Plan.

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

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. Document KRIs, escalation thresholds, and escalation protocols for each risk in a 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 trip-wires 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.

(Continued): Develop KRI metrics to track changes in risk severity

3.1.1 Develop key risk indicators (KRIs) and escalation protocols

Example

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

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

Establish a schedule for monitoring risks

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 are constantly evolving.

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

Identify Risk Response Actions

Risk Register & Risk Costing Tool

1

[Mandatory]

Risk Register Tool

Information

• Develop risk responses for all risk events pre-populated on the “Risk Response” sheet of the Risk Register Tool.
• Document the root cause of the risk (Activity 3.1.3) and other contributing factors (Activity 3.1.4).
• Identify risk responses (Activity 3.1.5).
• Predict the effectiveness of the risk response (if implemented) by estimating the residual probability and impact of the risk (Activity 3.1.5).
• The tool will calculate the residual severity of the risk after applying the risk response.

2

[Optional]

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 1 and 4 risk response options for each risk.
• Develop precise values for residual probability 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

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

Document the root cause for each risk event in the Risk Register Tool.

The Five Whys Methodology

Identify factors that contribute to the severity of the risk

3.1.4 Identify contributing factors

Environmental factors interact with the root cause to increase the probability or impact of the risk event.

Which 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

Document contributing factors for each risk event in the Risk Register Tool.

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.

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

Replacing legacy systems would be too costly.

Identify risk responses and assess their effectiveness

Identify Risk Response Actions

3.1.5 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 probability of occurrence or the impact if the event were to occur.
• Document risk responses on the “Risk Responses” tabs of the Risk Register Tool.
• Indicate the type of risk response (avoidance, mitigation, transfer, or acceptance).
2. Assign each risk response action a residual probability level and a residual impact level.
• This is the same step performed in Activity 2.2.6, when initial probability and impact levels were determined – however, now you are estimating the probability and impact of the risk event AFTER the risk response action has been implemented successfully.
• 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 probability and impact levels
• Residual risk severity level

Review the following slides on the 4 Types of Risk Response to help complete the activity.

1. Avoidance
2. Mitigation
3. Transfer
4. Acceptance

Risk Register Tool

Take actions to avoid the risk entirely

1 Risk Avoidance

Risk Avoidance 101

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

Example

Risk event: Information security vulnerability from third-party cloud services provider.

• Risk avoidance action: Store all data in-house.
• Benefits sacrificed: Cost-savings, storage flexibility, etc.

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

2 Risk Mitigation

Risk Mitigation 101

• Risk mitigation actions are risk responses that reduce the probability and impact of the risk event.
• Risk mitigation actions can either be to implement new controls or enhance existing ones.

Risk Event: Data compromised by loss of mobile device.

Example 1

Most risk responses will reduce both the probability 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 probability 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 probability 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 probability that a device is compromised.

Example 3

Others will reduce the potential impact without decreasing its probability of occurring.

Example

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

(Continued) Pursue projects that reduce the likelihood or impact of the risk event

Use the following IT functions to guide your selection of risk mitigation actions:

A. Process Improvement

Key processes that would most directly improve the risk profile:

• Change Management
• Project Management
• Vendor Management

B. Personnel

• Greater staff depth in key areas
• Increased discipline around documentation
• Knowledge Management
• Training

C. Infrastructure Management

• Disaster Recovery Plan/Business Continuity Plan
• Redundancy & Resilience
• Preventative Maintenance
• Physical Environment Security

D. Rationalization and Simplification

This is a foundational activity, as complexity is a major source of risk:

• Application Rationalization – reducing the number of applications
• Data Management – reducing the volume and locations of data

Transfer risks to a third party

3 Risk Transfer

Risk transfer is 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 cyber-insurance.

Not all risks can be insured. Insurable risks typically possess the following 5 characteristics: (M_o_R, 2007)

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.

Accept risks that fall below established thresholds or are prohibitively expensive to address

4 Risk Acceptance

You may choose to accept a risk event for one of the following 3 reasons:

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

Accepting a risk means tolerating the expected cost of a risk event. It is a conscious and deliberate decision to retain the threat.

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.

An energy company takes a two-pronged approach to protect its systems from a single point of failure

CASE STUDY

Industry:Energy

Challenge

• Risk identification and assessment exercises revealed that the organization’s “mainframe” had a single point of failure.
• One employee had engineered the entire system with homegrown code. Without this individual, an outage or issue could trigger financial losses to the organization in the realm of hundreds of thousands of dollars.
• Reducing the probability and impact of this risk became the top priority for the IT risk team. However, the most effective response option – replacing the system – was extremely expensive, and its implementation would leave them vulnerable in the short term.

Solution

• The IT risk team recommended to senior leadership that they take a two-pronged approach to mitigate the risk:
• In the long term, the legacy system would need to be replaced. Implementing this project would likely take three years, so risk severity would remain high until that time.
• In the short term, the organization would bring in a third party to document “hot spots” and procedures for operating and troubleshooting the legacy system. This “bridging” solution would decrease the impact of a risk event until the system was replaced.

Results

• The senior management team adopted the recommendations made by the IT risk team.
• The “bridging” solution allowed them to postpone the system replacement project, giving the organization more time to plan and organize resources.

Ultimately, we knew the system would need to be replaced in a few years, but bringing in a third party to document procedures brought an immediate drop in residual risk.

– VP of Information Security

(Optional) Use Info-Tech’s Risk Costing Tool to analyze and select a risk response

Perform Cost-Benefit Analysis

3.1.6 Risk response cost-benefit analysis

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

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

Instructions:

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

Risk Costing Tool

(Continued) Use Info-Tech’s Risk Costing Tool to analyze and select a risk response

3.1.6 Risk response cost-benefit analysis

4. Estimate residual risk probability and financial impact for Year 1 with the risk response in place.

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

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

5. Select the highest value risk response and document it in the Risk Register Tool.

6. Document your analysis and recommendations in the Risk Event Action Plan.

Note: See Activity 3.1.7 to build multi-year cost projections for risk responses.

(Optional) Create multi-year cost projections with the Risk Costing Tool

3.1.7 Create multi-year cost projections

Select between risk response options by projecting their costs and benefits over multiple years.

• It can be difficult to choose between risk response options that require different payment schedules. A risk response project with costs spread out over more than one year (e.g. incremental upgrades to an IT system) may be more advantageous than a project with costs concentrated up-front that may cost less in the long-run (e.g. replacing the system).
• However, the impact that risk response projects have on reducing risk severity is not necessarily static. For example, an expensive project like replacing a system may drastically reduce the risk severity of a system failure. Whereas, incremental system upgrades may only marginally reduce risk severity in the short-term but reach similar levels as a full system replacement in a few years.

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

Instructions:

Calculate expected cost for multiple years using the Risk Costing Tool for:

• Risk events that are subject to change in severity over time.
• Risk responses that reduce the severity of the risk gradually.
• Risk responses that cannot be implemented immediately.

Copy/paste the graphs into the Risk Report and the Risk Event Action Plan for the risk event.

Part 3: To mitigate key risk events, the IT risk council receives additional project funding from its board

Part 3 of 3

CASE STUDY

Industry: Retail Grocer

Determining Risk Responses

• The IT risk council, with the help of Info-Tech facilitators, determined the appropriate risk responses for each risk event. Each risk was assigned one of the following courses of action:

a) Accept risk; no action needed.

b) Initiate risk mitigation project.

c) Take action to avoid the risk.

d) Insure risk.

• From this analysis, it was determined that 28 projects were already underway and 24 new project requests needed to be created to tackle the top 31 IT risk events identified by the IT risk council.

Requesting Funding for Risk Responses

• To adequately mitigate key risks, the IT risk council determined that approximately $850,000 was needed to fund both new projects and projects already underway.
• The IT risk council conducted cost-benefit analyses of risk responses. This was used to illustrate to the business the value of investing in the recommended risk response projects.
• The IT risk council presented their recommendations to the board of directors and successfully received needed funding.

Sustaining IT Risk Management

• To sustain risk management, the Info-Tech facilitators helped the IT risk council build two action plans; one to maintain momentum of risk management processes and a second to manage initiated risk response projects.
• The IT risk council now meets on a quarterly basis to assess the risk portfolio and manage response projects.

One of the best outcomes of our Info-Tech engagement was the action plans that we received. This has helped keep the IT risk council on track and enables us to manage key IT risks that are being mitigated.

– PMO Director

Phase 3 (Section 2): Communicate IT Risk Priorities

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 Monitor IT Risks and Develop Risk Responses
• 3.2 Communicate 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

OUTCOMES:

Obtained approval for risk action plans

Communicated IT’s risk recommendations to senior leadership

Embedded risk management into day-to-day IT operations

Effectively deliver IT risk expertise to the business and foster a culture of risk-awareness within IT

Communicate IT Risk Management in Two Directions

1. Up to senior leadership (and ERM if applicable)
2. Down to IT employees (embedding risk awareness)

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.

Obtain sign-off on risk event action plans

3.2.1 Obtain executive approval for risk action plans

Task:

All IT risks that were flagged for exceeding the organization’s severity thresholds must obtain sign-off by the CIO or another member of the senior leadership team.

• In the assessment phase, you evaluated risks using severity thresholds approved by the business and determined whether or not they justified a risk response.
• Whether your recommendation was to accept the risk or to analyze possible risk responses, the business should be made aware of most IT risks.

Best Practices and Key Benefits

Best practice is for all acceptable risks to also be signed-off by senior leadership. However, for ITRCs that brainstorm 100+ risks, this may not be possible. If this is the case, prioritize accepted risks that were assessed to be closest to the organization’s thresholds.

By receiving a stamp of approval for each key risk from senior management, you ensure that:

1. The organization is aware of important IT risks that may impact business objectives.
2. The organization supports the risk assessment conducted by the ITRC.
3. The organization supports the plan of action and monitoring responsibilities proposed by the ITRC.
4. If a risk event were to occur, the organization holds ultimate accountability.

Use Info-Tech’s Risk Report to communicate IT’s top risk recommendations to senior leadership

3.2.2 Publish the Risk Report

Create a succinct, impactful document that summarizes the outcomes of risk assessment and highlights the IT risk council’s top recommendations to the senior leadership team.

The Risk Report contains:

• 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

The closer IT gets to the board, the more visibility and money they're going to get to address IT risk. But you need to give the business some 'tools' so they care about IT risk.

– VP Security and Risk, Energy Logistics Company

Info-Tech Insight

Dashboards are visualizations that emphasize key data points and support recommendations. They serve as the headlines of the Risk Report, helping members of the senior leadership team to comprehend the gravity of IT risks, as well as the costs associated with accepting and responding to risks.

Use Info-Tech’s Risk Report.

Promote a culture of risk-awareness throughout IT

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

Benefits of risk-awareness:

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

Consequences of low risk-awareness:

• False confidence about the number of IT risks impacting the organization and their severity.
• Risk-relevant information is not communicated to the ITRC, which may result in inaccurate risk assessments.
• Confusion surrounding whose responsibility it is to consider how risk impacts IT decision-making.
• Uncertainty and panic when unanticipated risks impact the IT department and the organization.

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

Take concrete steps to increase risk-aware decision-making in IT.

The IT risk council plays an instrumental role in fostering a culture of risk-awareness throughout the IT department. In addition to periodic risk assessments, fulfilling reporting requirements, and undertaking ongoing monitoring responsibilities, members of the ITRC can take a number of actions to encourage other IT employees to adopt a risk-focused approach, particularly at the project planning stage.

Embed risk management in project planning

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

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

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

Encourage risk awareness by adjusting performance metrics and job titles.

Performance metrics:

Depending on the size of your IT department, and the amount of resources dedicated to ongoing risk management, you may consider embedding risk management responsibilities into the performance assessments of certain ITRC members or other IT personnel.

• Personalize the risk management program metrics you have documented in your Risk Management Program Manual.
• Evidence that KPIs are monitored and frequently reported is also a good indicator that risk owners are fulfilling their risk management responsibilities.

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.

Hand off risk responses to project managers

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, Create Project Management Success.

Create Project Management Success

Finalize the Risk Management Program Manual

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.

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

Primary Deliverable:

Risk Management Program Manual

Don’t get complacent and allow your risk management program to flatline

So you’ve identified the most important IT risks and implemented projects to protect IT and the business. Unfortunately, your risk assessment is already outdated.

Perform regular health checks to keep your finger on the pulse of the key risks threatening the business and your reputation.

To continue the momentum of your newly-forged IT risk management program, read 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.

82% of organizations reassess their IT risk portfolio only once per year or even less frequently (Protiviti).

23% of organizations describe their risk management processes as “Mature” or “Robust” (ERM Initiative).

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

It might be your greatest risk.

Phase 3 Outcomes

Phase 1

Review IT Risk Fundamentals and Governance

1.1

1.2

1. Maturity Assessment
2. Stakeholder Map
3. IT Risk Council Charter

Phase 2

Identify and Assess IT Risk

1. Acceptable Risk Thresholds
2. Risk Register
3. Prioritized list of IT risks

Phase 3

Monitor, Communicate, and Respond to IT Risk

1. Risk Event Action Plan
2. Risk Reports
3. IT Risk Recommendations

Bibliography

Curtis, Patchin, Mark Carey, and Deloitte & Touche LLP. 2012. “Risk Assessment in Practice.” Committee of Sponsoring Organizations of the Treadway Commission. Online. http://www.coso.org/-erm.htm

Eccles, Robert G., Scott C. Newquist, and Roland Schatz. 2007. “Reputation and Its Risks.” Harvard Business Review. February 2007 Issue. Online: https://hbr.org/2007/02/reputation-and-its-risks

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

ISACA. 2009. The Risk IT Framework. Online: http://www.isaca.org/knowledge-center/risk-it-it-risk-management/pages/default.aspx

ISACA. 2014. COBIT 5. Online: https://cobitonline.isaca.org/

KMPG and RMA. 2014. Operational Risk Management Excellence – Get to Strong Survey: Executive Report. Online: https://www.kpmg.com/US/en/services/Advisory/risk-and-compliance/financial-risk-management/Documents/orm-survey-report.pdf

Marsh. 2014. “Measuring and Mitigating Reputational Risk.” Marsh, The New Reality of Risk. Online. http://usa.marsh.com/Portals/9/Documents/Marsh%20September%202014%20NROR%20Reputation.pdf

Office of Government Commerce. 2007. Management of Risk: Guidance for Practitioners. London: TSO.

Silverton Consulting. 2012. “4 Reasons Why CIO’s Lose Their Jobs.” Silverton Consulting, Inc. StorInt Briefing. Online: http://learn.sungardas.com/rs/sungardavailabilitysvcslp/images/business-continuity-plan-why-cios-get-fired-GEN-WPS-078.pdf

Appendix I: Probability vs. Frequency

Why we measure likelihood using probability, not frequency:

The basic formula of Likelihood x Impact = Severity is a common methodology used across risk management frameworks. However, some frameworks measure likelihood using Frequency, rather than Probability.

Frequency is typically measured as the number of instances an event occurs over a given period of time (e.g. once per month).

• For risk assessment, historical data regarding the frequency of a risk event is commonly used to indicate the likelihood that the event will happen in the future.

Probability is a numerical representation of the “degree of belief” that the risk event will occur in a given future timeframe (e.g. 25% probability that the event will occur within the next year).

False Objectivity

While some may argue that frequency provides an objective measurement of likelihood, it is well-understood in the field of probability theory that historical data regarding the frequency of a risk event may have little bearing over the probability of that event happening in the future. Frequency is often an indication of future probability, but should not be considered an objective measurement of it.

Likelihood scales that use frequency underestimate the magnitude of risks that lack historical precedent. For example, an IT department that has never experienced a high-impact data breach would adopt a very low likelihood score using the frequentist approach. However, if all of the organization’s major competitors have suffered a major breach within the last 2 years, they ought to possess a much higher degree of belief that the risk event will occur within the next year.

Probability is a more comprehensive measurement of future likelihood, as frequency can be used to inform the selection of a probability value. The process of selecting intersubjective probability values will naturally internalize historical data such as the frequency that the event occurred in the past. Further, the frequency that the event is expected to occur in the future can be captured by the expected impact value. For example, a risk event that has an expected impact per occurrence of $10,000 that is expected to occur 3 times over the next year has an expected impact of $30,000.

Appendix II: Should max impacts sway decision-making?

Don’t just fixate on the most probable impact – be aware of high impact outcomes

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

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

Naturally, focusing on the most probable 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 probability for such an event may be well below 1%.

While the risk severity level assessment allows you to present impacts as a range of values (e.g. $50,000 to $75,000), the expected cost assessment requires you to select specific values.

• However, this analysis may fail to consider much higher potential impacts that have non-negligible probability values (probability 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 probability 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 probabilities (too high to be ignored) consider elevating the risk severity level or expected cost.

Research contributors and experts

Ken Piddington, CIO and Executive Advisor MRE Consulting

Ken Piddington is Chief Information Officer (CIO) and Executive Advisor at MRE Consulting. At MRE, Ken is responsible for defining and executing the company’s business technology strategy and heads their CxO advisory practice. Mr. Piddington is an experienced business leader and technology strategist with more than 20 years of transformation leadership experience gained as CIO and executive advisor for Fortune 1000 companies. Mr. Piddington uses his extensive experience in people leadership, business operations, and technology innovation to partner with CIOs, CxOs, and their leadership teams to help them develop effective plans and strategies to achieve meaningful results in their respective businesses.

Sterling Bjorndahl, Director of IT Operations eHealth Saskatchewan

Sterling Bjorndahl is the director of IT Operations for eHealth Saskatchewan, responsible for IT service provision to Saskatchewan’s health care authorities and infrastructure support for the provincial repositories that make up Saskatchewan’s Electronic Health Record. He is currently under part-time secondment to the Sun Country Regional Health Authority in the role of Acting Chief Information Officer.

(Continued) Research contributors and experts

Tamara Dwarika, Internal Auditor

Tamara is currently one of the key members of the internal audit group of a leading North American Utility. With over 10 years of internal audit, risk management, and information technology experience, Tamara is a seasoned professional who brings a unique perspective on IT Risk Management.

Other Contributors

Michel Fossé, Consulting Services Manager, IBM Canada (LGS)

Steve Woodward, CEO, Cloud Perspectives

Anne Leroux, Director, ES Computer Training

(Other interviews were conducted with experts and practitioners who chose to remain anonymous.)