ICT Risk Management Guidance

1. Introduction

1.1 Purpose

This guidance supports government organisations to implement a risk management process that enables critical information and communications technology (ICT) risks to be effectively identified, managed and governed.

1.2 Context

This guidance is an extension of the All-of-Government (AoG) ICT Operations Assurance Framework, which outlines the principles of good assurance.

All-of-Government (AoG) ICT Operations Assurance Framework

We recognise that many government organisations will have existing enterprise risk management frameworks in place. This guidance is not intended to replace these frameworks; it’s to provide practical help and advice to supplement these frameworks. In the first instance, you should adopt your enterprise risk management framework.

This guidance is based on the International Organisation for Standardization’s guidelines:

ISO 31000: 2018 Risk Management — Guidelines

As a guiding principle:

The term ‘ICT risk’ is used here to mean both traditional ICT risk as well as new and emerging risk resulting from adopting digital technologies.

1.3 Benefits of risk management

Government organisations are increasingly dependent on technology to deliver public services. At the same time, the traditional ICT function in government organisations is changing to support new ways of working, including a shift towards continuous delivery through Agile / DevOps approaches.

Now more than ever, managing ICT risk requires a well-coordinated, integrated approach that prioritises understanding the business impacts of ICT risk. Integrated ICT risk management means that government organisations are in a better position to achieve their strategic business outcomes as well as create opportunities to exceed them.

Effective risk management helps government organisations to:

• clarify objectives for how ICT supports business outcomes
• make sure critical ICT risks to service delivery are identified and effectively managed, avoiding operational surprises
• make risk-informed investment decisions based on a shared view of ICT risks and their potential business impacts
• prioritise the allocation of resources to areas of greatest risk
• be more responsive to new and emerging ICT risks.

1.4 Risk management principles

The purpose of risk management is the creation and protection of value. ISO 31000 sets out 8 principles of effective and efficient risk management:

1. Framework and processes should be customised and proportionate.
2. Appropriate and timely involvement of stakeholders is necessary.
3. Structured and comprehensive approach is required.
4. Risk management is an integral part of all organisational activities.
5. Risk management anticipates, detects, acknowledges and responds to changes.
6. Risk management explicitly considers any limitations of available information.
7. Human and cultural factors influence all aspects of risk management.
8. Risk management is continually improved through learning and experience.

Government organisations should adopt and adapt these principles to design, implement and operate a risk management process that is tailored to their organisation.

2. Risk governance, roles and responsibilities

Effective risk management depends on appropriate governance and oversight. Risk oversight covers both the risk management process as well as individual accountabilities for managing risk outcomes.

2.1 Three Lines of Defence model

It‘s essential you establish roles and responsibilities for effective risk management across the organisation. The 3 Lines of Defence model is a framework that is often used to clearly define risk management roles and responsibilities:

• The first line of defence is the day-to-day operational management processes and controls you have for identifying and managing ICT risks. This includes business management and line managers who are responsible for the design and implementation of business processes and controls.
• The second line of defence is the governance and oversight arrangements that exist for ongoing monitoring of ICT risks. This includes oversight functions that provide advice and guidance on how to make sure the correct organisational settings are in place for the business to manage risk – for example, Finance, Human Resources, Procurement, Security and Risk, Privacy, and so on.
• The third line of defence is the independent assurance you get from Internal Audit and third-party assurance providers, including External Audit, that ICT risks are effectively managed.

Figure 1 below shows an example of how the 3 Lines of Defence model can be applied to ICT security risk.

Detailed description of the image

The chart represents the three lines of defence and their roles.

1. Applications and Support System Manager: There is a documented procedure for patch management. Review of weekly patch management status report by Support Manager.
2. Security and risk manager: Level of patching and associated risk exposures reported on a monthly basis to the Security and Risk team. Quarterly security risk report to ICT leadership team.
3. Third party assurance provider: Annual security review of vulnerable systems.

2.2 Role of Executive Leadership team

The Executive Leadership team (ELT) has primary responsibility for risk governance and overseeing the top risks faced by the organisation. This includes making sure the risk management principles are embedded into the organisation’s risk management framework, governance, decision-making and reporting structures to promote a robust risk management culture.

ELT may delegate the monitoring of specific risks to other management or governance bodies within the organisation – for example, financial reporting, regulatory, ICT, health and safety, reputational risks, and so on. Ultimately, however, ELT remains accountable for effective risk management across the organisation.

2.3 Risk escalation

A key component of risk management and governance is knowing when to escalate risks to make sure they are managed at the right level within the organisation. A formal risk escalation process should identify who has the authority to accept the risk, based on the residual risk rating. Different types of risk (for example, strategic risk versus operational risk) may have different escalation paths.

3. Establishing the context

3.1 Operating environment

Establishing the context for the risk assessment will help you to define the purpose and scope, who needs to be involved and the risk rating criteria to be used. For example, the subject of the risk assessment may be the organisation as whole, a business unit, a programme or project, or a process.

At the organisational level, the risk context is typically informed by the overall strategic plan. The strategic plan defines the relationship between the organisation and its operating environment, identifying strengths, weaknesses, opportunities and threats.

At the business unit level, the risk context is set by the detailed objectives and business plans of the business unit in question. These are established as part of the planning process and they demonstrate how the business unit will support the achievement of strategic outcomes.

At the programme or project level, the risk context is determined by the specific investment objectives and the expected outcomes.

At the process level, the risk context is likely to be less formalised, but it’s important to make sure objectives are clearly understood and that risk rating criteria are appropriate to make the risk assessment meaningful.

In all cases, it’s important to start with a clear understanding of the operating environment, both internal and external, that may reasonably impact on the organisation. The operating environment should be regularly reviewed to make sure it remains current.

Below are some questions which may be helpful for establishing the risk context:

3.1.1 Inter-agency risks

Increasingly, government organisations must work together to deliver integrated citizen-centric services. This means that risk governance must extend beyond traditional organisational boundaries with explicit accountabilities for managing ‘system’ level risks in support of inter-agency, sector and AoG outcomes.

Where this is the case, the parties should agree on a lead agency that is responsible for making sure there is a common understanding of the risks involved and how they will be managed. This includes making sure there is a joint risk register and that it’s clear who owns which risk. This may require other government organisations to adopt the risk assessment process of the lead agency in order to provide compatible risk ratings and risk reporting.

3.2 Risk appetite

When establishing the context, you should also consider your risk appetite.

Risk appetite is the amount of risk that an organisation is willing to accept in the pursuit of its business objectives and outcomes. It represents an organisation’s attitude to particular risks, and takes into consideration the expectations of key stakeholders, such as Ministers, customers, third-party providers, staff and the public.

Risk appetite can be expressed as a series of boundaries or statements that have been appropriately authorised by ELT. It’s often reflected in the target risk rating for individual risks or categories of risk. This does not mean the target risk rating must always be Low.

An organisation may seek to encourage innovation, using digital technologies and new ways of working to support the delivery of new channels or services. As a result, the target risk rating for a new channel or service may be higher than for core products and services, where the organisation has a lower risk appetite.

To identify acceptable levels of risk, it’s important to hold discussions at the executive level in order to clearly communicate, assess and provide direction on what are acceptable levels of residual risk.

Risk appetite may change over time as new information and outcomes become available, and as stakeholder expectations evolve.

3.2.1 Risk tolerance

You should also consider risk tolerance when establishing the context of the risk assessment. Risk tolerance can be defined as the acceptable variance from the organisation’s risk appetite. Government organisations should determine acceptable tolerance limits and whether they are negotiable.

For example, an organisation may define a target that no critical system should have a service disruption of more than 1 working day. This could then be monitored and escalated based on a risk tolerance of no more than 2 working days for a service disruption.

You may need to set up an appropriate process for when a risk falls marginally outside the desired risk tolerance. In this scenario, clearly define why the risk should be accepted or managed – for example, the cost of further mitigation.

4. Risk assessment

The goal of the risk assessment process is to apply a consistent methodology for assessing the ICT risks faced by the organisation. It provides the foundation for effective risk management and makes sure significant ICT risks and their potential business impacts are identified and assessed in a timely manner.

The primary questions addressed by the risk assessment process are:

The risk assessment process covers 3 key activities:

• risk identification
• risk analysis
• risk evaluation

These are described in more detail below.

4.1 Risk identification

Once you have established the context for the risk assessment, the next step is to identify the ICT risks that threaten the achievement of your business objectives or that create an opportunity to exceed them. There are numerous risk identification techniques you can use:

• One-to-one interviews
• Group discussions / facilitated workshops
• Questionnaires / surveys
• Strengths, weaknesses, opportunities, threats (SWOT) analysis
• Dependency modelling
• External environment / horizon scanning
• Scenario analysis
• Process mapping

The techniques you use will vary depending on the nature of the risk assessment being performed. For example, at the business unit level you may use a combination of one-to-one interviews and then – to gain consensus – group discussion. The important thing is to find ways to consider all possible sources of ICT risk.

Example of an ICT risk universe (PDF 514KB)

4.1.1 Types of risk

In identifying and then subsequently managing risks, it can be helpful to consider different types of risk. There is no one standard classification system for different types of risk. As a minimum, you should identify strategic risks versus operational risks. This is because strategic risks and operational risks will likely be owned and managed at different levels within the organisation, and different escalation paths may be used.

4.1.2 How to state risks

There are 3 elements for stating risks. These are event, causes and consequences.

Figure 2: Elements of risk

1. Event: A risk event is defined as something that could prevent the achievement of an objective, milestone or target, or something that could create an opportunity to exceed any of these things.
2. Causes: The event may occur as a result of a number of causes that may be internal or external. Identifying the causes of a risk event will help you to better understand the risk and the interrelationships between different risks. This will help you put the right prevention strategies in place.
3. Consequences: The consequences describe the outcomes of the risk event, if it were to occur. These may include service interruption, or impacts on safety, costs, reputation and/or regulations. Understanding the consequences of risks allows you to make sure you have appropriate strategies for risk mitigation and/or recovery.

By acting on any one of these 3 elements, you can affect the risk rating.

4.1.3 Who owns a risk?

Make sure there is a single point of ownership for each risk. A risk owner should have the authority to influence the risk outcome and be held accountable for doing so. In many instances who owns the risk is clear.

However, conflicts and confusion over accountability can arise where risks cross functional boundaries, which can often be the case for ICT risks.

In selecting the most appropriate risk owner, it’s important to consider the source of the risk and the risk-bearing function, that is, the business unit that will be most impacted by the risk, should it occur. It’s best if the risk owner is someone in the risk-bearing function, as they will be incentivised to manage the risk effectively. However, the most important consideration is for the risk owner to have the authority to hold other business units accountable for managing their contribution to the risk outcome.

For example, a particular business unit is dependent on the availability of an ICT system that is critical for their work. The source of the risk is a failure of the system, which is influenced by the ICT function. However, it’s the business unit that is dependent on the system that bears the risk because it will be the one that is most impacted should the system fail. In this case, risk ownership lies with the business unit as it’s the business unit that defines the availability, continuity and recovery objectives for the system, and that will hold the ICT function responsible for meeting these.

4.2 Risk Analysis

Risk analysis involves 3 steps:

1. Assess the likelihood and impact of the risk occurring in the absence of mitigating controls. This is referred to as the inherent risk rating and should be based on normal circumstances, that is, the most probable case as opposed to the worst-case scenario.

Example of risk likelihood and impact rating criteria (PDF 656KB)

2. Identify and assess the effectiveness of the existing controls that are in place to mitigate the risk. Assessing control effectiveness accurately is important for making an accurate assessment of residual risk.

Example of control effectiveness ratings (PDF 454KB)

To assess the effectiveness of a control, the control needs to be evaluated on multiple levels, as illustrated by Figure 3 below.

Detailed description of the image

A square divided into quadrants, with an arrow moving from bottom left to top right.

The square is labelled with:

• • Top row: Preventative
  • Bottom row: Detective
  • Left column: Manual
  • Right column: Automated.

So the arrow goes from Manual/Detective up to Automated/Preventative. 

• Preventative controls stop the risk from occurring. These tend to be mostly automated actions performed by a system.
• Detective controls usually identify risks after they have occurred. These tend to be manual (some manual controls may rely on information generated by systems, but the control itself is still performed manually).

You should consider these factors when rating control effectiveness:

3. Assess the residual risk rating based on the effectiveness of the mitigating controls. As a rule, controls reduce the likelihood of the risk occurring. Some controls, however, reduce the impact of the risk once it has occurred – for example, a business continuity plan may reduce the impact of a natural disaster but not the likelihood of it occurring.

Although the first step of risk analysis will generally represent an artificial environment, when you consider it in conjunction with the second and third steps, it gives you a framework you can use to assess the existence and effectiveness of the controls that are believed to be in place.

Completing the first step can also lead to a re-assessment of whether the cost of these controls is still justified.

This 3-step risk analysis approach will help make sure all key risks are recorded and that judgments about the appropriate management of those risks are substantiated.

4.3 Risk evaluation

The final step in the risk assessment process is to evaluate whether the residual risk rating is acceptable or unacceptable. This is based on an assessment of the target risk rating.

The relationship between inherent, residual and target risk is shown in the heat map in Figure 4 below.

Detailed description of the image

This diagram shows the relationship between inherent, residual and target risk.

The diagram is a square, split into a grid pattern.

The vertical axis is labelled ‘likelihood’ and from bottom to top, each row is labelled: rare, unlikely, possible, likely and almost certain.

The horizontal axis is labelled ‘impact’ and from left to right, each column is labelled: insignificant, minor, moderate, major, severe.

Each square in the grid is coloured to show risk level.

• Green is low risk.
• Yellow is medium risk.
• Orange is high risk.
• Red is critical risk.

The overall effect is a gradient from green at the bottom left (rare and insignificant) to red at the top right (severe and almost certain).

The diagram includes labels for 3 points on the grid:

1. Inherent risk assessment is in the top right (severe and almost certain).
2. Residual risk assessment is lower and to the left (major and possible).
3. Target is lower and to the left again (minor and rare). It is also noted that the target is what is sought to be achieved to manage risk within its defined appetite.

An arrow points from inherent risk assessment to residual risk assessment. And a dotted arrow points from residual risk assessment to target.

The diagram includes questions related to particular parts.

1. On the arrow from inherent to residual risk: how much reliance do you place on residual controls to mitigate this risk?
2. On the residual risk assessment: Control effectiveness. Is the residual risk position good enough? Do we need to do more/less to mitigate this risk?
3. On the target: Are you happy with the end result after introducing new controls and mitigation?

A risk is considered ‘acceptable’ if the residual risk rating is equal to or less than the target risk rating. No further action is required beyond maintaining existing controls.

This does not mean the target risk rating must always be Low for the risk to be accepted. The evaluation of the target risk rating considers the:

• organisation’s overall appetite for the risk
• degree of control the organisation has over the risk
• cost, benefits and opportunities presented by the risk.

For example, a Medium residual risk related to a new digital channel or service may be deemed acceptable because the opportunities presented outweigh the threats to such a degree that the risk is justified.

5. Risk treatment

There are 4 ways to deal with a risk:

5.1 Risk improvement plan

Risk owners should develop a risk improvement plan whenever the residual risk rating is greater than the target risk rating. The risk improvement plan documents:

• the management actions to be taken to reduce the risk to an acceptable level
• the people responsible for implementing the actions
• due dates for completion.

The risk owner is ultimately responsible for the risk improvement plan but may delegate responsibility for implementing actions to others who have appropriate authorisation to do this.

5.2 Root cause analysis

When developing a risk improvement plan, it’s important to consider the root causes of the gap between the residual and target risk ratings and make sure management actions appropriately address these. You should review:

• the causes of the risks that have been identified as part of the risk assessment process
• the impact of the risks on other areas of responsibility
• third parties and their ability to control and mitigate the risk.

5.3 Cost-benefit analysis

Suggested management actions should be subject to a cost-benefit analysis in the same way as for other new initiatives. This is to make sure the actions are cost effective and will achieve the desired reduction in the risk rating.

6. Monitoring and reporting

Monitoring and reporting are essential steps in the risk management process. However, they should not be viewed as something separate or stand-alone. Instead, integrate risk monitoring and reporting into the regular rhythm of business performance measurement, reporting and governance.

6.1 Monitor risks

To make sure risk information remains current and dynamic, consider the following questions:

6.2 Establish metrics

Establish metrics to monitor key risks. In many instances, these will be existing Key Performance Indicators (KPIs), but they should also include leading indicators of risk. This will help to integrate risk information into business performance and support the flow of risk information up through the organisation to provide an early warning of a changing risk profile.

7. Communication and consultation

The goal of communication and consultation is to support good risk conversations that are based on relevant, accurate and timely information. Good risk conversations help to elicit information and manage stakeholder expectations for managing risk. This includes:

• helping to develop a common understanding of diverse views
• promoting timely action
• making sure effective risk management contributes to the achievement of strategic and business outcomes.

As such, communication and consultation should take place during each step of the risk management process. This should identify who should be involved in the assessment of risk, including those who will be involved in the treatment, monitoring and review of risk. It’s very rare that only 1 person will hold all the information needed to identify and manage risks to an activity or change. So, it’s important to identify the range of stakeholders, both internal and external, who will help develop a complete picture of the risks.

It’s also important to make sure all staff understand, in a way appropriate to their role, their responsibilities for managing risk. If you don’t achieve this, the organisation's risk culture may not be aligned to achieving successful business outcomes.

8. Engaging with the System Assurance team

8.1 Lifting risk management and assurance capability

The System Assurance team works collaboratively with government organisations to lift risk management and assurance capability. For more information, see:

Role of the System Assurance team

8.2 Guidance and templates

For further guidance and templates, including risk register and heat map templates, see:

Guidance and templates for ICT Operations Assurance

8.3 How to contact us

Contact the System Assurance team for ICT risk management and assurance advice.

Email: systemassurance@dia.govt.nz

Glossary of terms and abbreviations