Below is a written version of our presentation to the Investment Association Resilience Forum1 on 3rd July in London. This version has been edited from the original presentation to suit a blog.
Resilience Mapping 101
For the context of today, we’re going to be diving into technology mapping, third party mapping, IT third party mapping.
So, what is resilience mapping? Fundamentally, it’s:
- Identifying the processes that underpin service delivery
- Identifying the resources that underpin those service delivery processes
- Identifying the owners of those resources and processes
- Documenting how they fit together
- Visualising how they fit together
Done correctly, mapping is a key value driver which connects the resilience programme and feeds several different areas:
- Risk Management: Mapping ensures that firms better identify risks, meaning that risk assessment and risk treatment measures are effective
- Scenario testing: Detailed mapping means that firms test accurate scenarios, producing focused results and ensures that the right data and right stakeholders are in the room
- Resilience strategy: Without in-depth mapping, a firm will be unclear on what gaps to close, their strategy may not provide guidance and future direction beyond March 2025
- Resilience investment: Remediation, financial investment and recruitment activities may lack direction as many things will be considered a priority without in-depth mapping
- Reporting: Resilience reporting, standards and controls which feed MI creation and decision-making through governance are not possible without mapping
But most importantly, mapping ensures that firms understand how and where Important Business Services (IBS) and Critical or Important Functions (CIF) are vulnerable.
The importance of understanding vulnerabilities
Identifying and understanding vulnerabilities is key to ensuring continued operation of any Important Business Service or Critical or Important Function.
Let’s consider two examples to demonstrate the point.
The James Webb Space Telescope2 is the largest space telescope ever built. It took USD 9 billion and approximately 20 years to build and was launched from French Guyana in December 2021.
The James Webb Space Telescope is now in deep space sending back the most incredible images which scientists hope will give us greater insight into the universe and our own galaxy, the Milky Way.
Resilience practitioners may be surprised to learn that this USD 9 billion telescope, was launched with a significant number of vulnerabilities: 344 Single Points of Failure to be exact. Over 200 of those vulnerabilities were situated in the sun shield alone. Many were mission critical.
And yet, the telescope was still launched because the programme leaders knew where they were vulnerable. They knew what needed to be done with each vulnerability, what could be mitigated, what could be worked around and what needed to be risk accepted (a surprisingly high number in fact).
How did they identify the vulnerabilities and Single Points of Failure? Everything was mapped to the resources that could fail!
Now let’s consider the example of the UK Home Office’s Border Force automated passport eGates.
It was May Bank holiday 2024 and thousands of UK passengers were returning home via UK airports after extended weekends away. On landing, passengers discovered that all automated passport entry gates at all UK airports had suffered a four-hour outage3 from around 8pm until after midnight.
Imagine the misery, the queues, the crying children, the crying adults.
The cause of this misery was a single WiFi outage4 which knocked out the key database communicating passenger security information to the passport eGates.
Manual workarounds were enacted but the size and lawlessness of some of the queues, reflect that those workarounds were inadequate and strongly suggest that this vulnerability, this Single Point of Failure, had not been previously identified.
Could better mapping have prevented such an incident? You bet!
Detailed mapping leads to clear identification and understanding of vulnerabilities and knowing where a firm is vulnerable is a good thing because something can be done about it. Some things do need to be risk accepted but others can be prevented or mitigated with the goal of maintaining mission critical activities.
FCA Operational Resilience mapping
FCA operational resilience regulation5 states that “A firm must identify and document the people, processes, technology, facilities and information necessary to deliver each of its important business services. This must be sufficient to allow the firm to identify vulnerabilities and remedy these as appropriate”.
The FCA is clear that good mapping feeds the identification of vulnerabilities.
In the FCA’s publication, “Operational resilience: insights and observations6 for firms”, they again confirm that “Detailed mapping should support the identification of vulnerabilities which may cause you to breach impact tolerance during an operational disruption.”
However, the same report then goes on to make further statements: “We expect your mapping of resources and processes to mature over time, to enable you to fully understand all the dependencies and interconnectivity required to deliver your important business services” and “As mapping and scenario testing matures, additional vulnerabilities may be identified which will require remediation”.
So why is the FCA encouraging firms to mature their mapping and go further to identify and address vulnerabilities?
It could be argued that they have reviewed a lot of programmes and have concerns about the current state of mapping, and they understand that only through more granular mapping can firms and the market truly understand where and how they are vulnerable and lay claim to resilience.
Although robust, the regulator statements combined with the outcome-based nature of the regulation do not challenge firms to go deeper, only to go deep enough “… to allow the firm to identify vulnerabilities”7.
We see this lack of depth play out in practice in many firms we’ve reviewed, where they stop mapping an Important Business Service, a process or a resource when they find a vulnerability, without mapping any further to potentially find out more.
A clear example is the third-party pillar. Many firms have completed mapping to identify where services, processes or resources are reliant on third parties. Most firms who have mapped to third parties have also found vulnerabilities in that third-party pillar.
But when we consider how many of those firms have mapped to fourth parties, the number reduces significantly.
This lack of depth was clearly illustrated in a recent UK Finance Webinar8 and blog post9: Data as a Defence. UK Finance is a member organisation, representing the interests of around 300 members across banks, building societies and retail finance firms.
UK Finance polling found that 40% of the market had not even mapped to the depth of applications and only 20% of the market had mapped any further to underlying infrastructure, servers, networks, databases etc.
That presents a potentially major resilience issue, because as we’ve already outlined in the Border Force example, outages often stem from underlying infrastructure, information assets and third-party technologies.
UK Finance’s results are a few years old now and you’d expect improvements to have taken place but with swathes of the UK Financial Services market interconnected through partnerships, products, services and suppliers, a more prescriptive mapping standard could be beneficial.
Consider the market in which your firm operates. What happens if a third of that market is not even mapping resources and finding vulnerabilities in the application layer? What happens if as an industry 80% of potential technology resources and vulnerabilities go undetected?
There’s a strong argument to say that those levels of undetected vulnerabilities could, given the right circumstances, have the potential to create a market-wide vulnerability given the interconnected nature of firms and services.
DORA mapping
DORA is tackling this mapping challenge head on.
It’s saying let’s make the market less vulnerable, let’s make individual firms less vulnerable and let’s make clients less vulnerable to resilience incidents by prescribing how firms should map and record ICT assets and third parties.
DORA takes a more holistic view of ICT threats to create a full understanding of ICT and ICT third-party vulnerabilities. At its heart is a firm-wide search and identification of vulnerabilities in ICT and ICT Third-Party Risk.
Yes, it has the keenest eye on those Critical or Important Functions which can impact the ongoing viability of a firm, impact the market, and impact consumers but in the first instance, firms must cast a broad net over internal functions, and internal and external services that could have a detrimental impact to safety and soundness, the market, and consumers.
Perhaps in contrast to the FCA and PRA, the ESAs regulating DORA feel that failing to map all ICT assets leads to unidentified vulnerabilities due to the interconnectedness of all systems.
To quote from the JC 2023/86 consultation10, “Focusing only on the risk management of ICT systems supporting critical or important functions could leave ICT systems not supporting critical or important functions exposed, potentially affecting the one supporting critical or important functions due to their interconnectedness.”
A quick look at Article 811 of EU 2022/2554, sees the same sense of depth and interconnectedness.
It states that firms must identify “…all ICT supported business functions… the information assets and ICT assets supporting those functions…”.
Firms must then “…identify all sources of ICT risk, and assess cyber threats and ICT vulnerabilities relevant to their ICT supported business functions, information assets and ICT assets…”
Firms must go deeper still and “…identify all information assets and ICT assets, including those on remote sites, network resources and hardware equipment…”
Finally, firms “…shall map those [ICT assets] considered critical” by documenting “…the configuration of those ICT and Information Assets and the links and interdependencies between the different information assets and ICT assets”.
Even smaller firms, in scope for the light DORA framework, “…shall identify all critical or important functions supported by ICT third-party service providers…” and “…must identify, classify and document all critical or important functions, the information assets and ICT assets supporting them and their interdependencies”.
So why is DORA prescribing firms to identify assets and map to this level of depth and detail?
Anecdotally, we’ve seen the news stories relating to hacked fish tanks12, hacked air conditioning13 units and are all aware of the growing connectivity of IoT devices (palm trees14, anyone?) and so seemingly innocuous elements of a firm’s network are vulnerable to resilience incidents and can fall prey to cyber-attacks.
More formally, the European Systemic Risk Board (ESRB) requested firms across the 14 EU member states to complete a survey of the most “Common Individual Vulnerabilities”15 for their Systemic Cyber Risk Paper in 2020. We can see from the table below that third-party and ICT vulnerabilities are the most recorded “Common Individual Vulnerabilities” across the surveyed firms.
| Common Individual Vulnerability (CIV) | Category |
| Insufficient industry oversight of third party suppliers and supply-chain | Weakness in process |
| Inadequate cyber hygiene | Weakness in process |
| Ineffective testing of people, processes and technology | Flaw in process |
| Insufficient cyber strategic planning and board level influence on cyber resilience | Weakness in process |
| Lack of investment in cyber threat intelligence | Gap in process |
| Presence of end of life systems | Susceptibility/flaw in asset |
| Technology centric focus underestimating responsibility of people and processes | Weakness in process |
| Organisational culture change needed for secure cyber security behaviours | Gap in process |
| Cyber undermines existing operational resilience arrangements | Weakness in control measures |
| High risk internet use requires better controls | Weakness in control measures |
| Firm scale and resources impact effective cyber risk management | Susceptibility in process |
| Insufficient credible third line of defence challenge in firms | Weakness in process |
| Cyber maturity targets not defined | Gap in process |
|
Source: ESRB (ESCG) |
|
The ESRB then went on to identify which of those Common Individual Vulnerabilities were likely to have caused a cyber incident16.
| Rank | Common Individual Vulnerability (CIV) | Causation | Prevalence |
| 1 | Insufficient industry oversight of third party suppliers and supply chain | Direct | 1 |
| 2 | Inadequate cyber hygiene | Direct | 2 |
| 3 | Ineffective testing of people, processes and technology | Direct | 5 |
| 4 | Insufficient cyber strategic planning and board level influence on cyber resilience | Indirect | 3 |
| 5 | Lack of investment in cyber threat intelligence | Indirect | 4 |
| 6 | Presence of end of life systems | Direct | 6 |
| 7 | Technology centric focus underestimating responsibility of people and processes | Indirect | 7 |
| 8 | Organisational culture change needed for secure cybersecurity behaviours | Indirect | 8 |
| 9 | Cyber undermines existing potential resilience arrangements | Direct | 9 |
| 10 | High risk internet use requires better controls | Direct | 12 |
| 11 | Firm scale and resources impact effective cyber risk management | Indirect | 10 |
| 12 | Insufficient credible third line of defence challenge in firms | Indirect | 11 |
| 13 | Cyber maturity targets not defined | Indirect | 13 |
|
Source: ESRB (ESCG) |
|||
As we can see, oversight of third parties and ICT third parties is again at the top of the list.
In our view, there is a very strong argument to make that five of the top ten listed vulnerabilities (1,3,6,7,10) could be directly improved through enhanced identification and mapping of resources and this is precisely why DORA is so prescriptive with its mapping requirements.
Using DORA to improve FCA operational resilience
For firms wishing to understand how to get started with DORA, our other blogs17 have outlined the practicalities18, including using existing capabilities and artefacts, and top down and bottom up approaches to mapping.
DORA is the Terminator19 of mapping, “it absolutely will not stop”.
Firms should consider how to apply DORA mapping requirements to improve and mature operational resilience mapping, and identification of vulnerabilities. By being prescriptive, DORA offers firms far greater visibility of all their vulnerabilities and firms can take DORA’s mapping principles and apply them across all resource pillars and processes.
That’s the lesson for UK firms. Use DORA’s mapping requirements as a template to mature your own operational resilience mapping.
You will find more vulnerabilities in processes, more vulnerabilities in resources, and more vulnerabilities in Important Business Services delivery.
As a result, you will have more resilient processes, more resilient resources, more resilient Important Business Services and a more resilient firm.
