**2.1 Resilience and resilience matrix**

The definition of resilience, standing in the background of the concept presented in this paper, has evolved along with the work on the development of the concept. It started with the definition of the resilience as *"The ability to anticipate, prepare for, and adapt to changing conditions and withstand, respond to, and recover rapidly from disruption".* The main amendment proposed afterward was the inclusion of the ability to understand risks (current and emerging), leading to the definition of *"Resilience as the ability to understand risks, anticipate, prepare for, and adapt to changing conditions and withstand, respond to, and recover rapidly from disruption"* [3]. In the final stage, the project adopted the elaborated definition of the resilience of an infrastructure is given below [4].

"*Resilience of an infrastructure is the ability to understand and anticipate the risks – including new/emerging risks – threatening the critical functionality of the infrastructure, prepare for anticipated or unexpected disruptive events, optimally absorb/withstand their impacts, respond and recover from them, and adapt/transform the infrastructure or its operation based on lessons learned, thus improving the infrastructure anti-fragility*."

This definition enabled the following main advantages:


*Resilience and Situational Awareness in Critical Infrastructure Protection… DOI: http://dx.doi.org/10.5772/intechopen.97810*

The definition allows analyzing the behavior of an infrastructure exposed to an adverse event over a "scenario timeline" and simultaneously assessing the functionality of an infrastructure over the "resilience cycle" as shown in **Figure 1**. While the decomposition over the time-axis, i.e., defining the "phases" of the resilience cycle, may be trivial, decomposition over the functionality axis is non-trivial as functionality might have different "dimensions" (see chapter 2.3). The SmartResilience concept proposes the decomposition over a 5 5 resilience matrix, defining 5 phases and 5 "dimensions".

The approach allows to represent the overall resilience cycle, and focus on single relevant issues. The issues, in turn, can be described by means of indicators and these can have values, thus, providing the possibility to quantitatively describe each "cell" of the resilience matrix (**Figure 2**).

Phase I, understand risks, is applicable prior to an adverse event. It emphasizes emerging risks and includes their early identification and monitoring; e.g. what could the "adverse event" be? This is followed by.

Phase II, anticipate/prepare, also applicable before the occurrence of an adverse event. It includes planning and proactive adaptation strategies, possibly also "smartness in preparation" [5].

Phase III, absorb/withstand, comes into action during the initial phase of the event and shall include the vulnerability analysis and the possible cascading/ripple effects; e.g. "how steep" is the absorption curve, and "how deep" down will it go?

Phase IV, respond/ recover, is related to getting the adverse event under control as soon as possible, influencing the "how long" will it last, question. Further, it

**Figure 1.**

*The 5 5 resilience matrix, mapping the critical infrastructure system functionality over 5 phases of the resilience cycle.*

#### **Figure 2.**

*Possible outcomes of case of an infrastructure exposed to an adverse event: Between improvement and complete failure.*

includes the post event recovery; e.g. "how steep up" is the recovery curve for normalization of the functionality? It is followed by.

Phase V, adapt/learn, which encompass all kinds of improvements made on the infrastructure and its environment; e.g. affecting "how well" the infrastructure is adapted after the event, and whether it is more resilient and "sustainable". The activities in this phase also lead to preparation for future events and hence, this resilience curve also exhibits a reoccurring cycle [5].

The dimensions help in categorizing the indicators. The system/physical dimension includes technological aspects, as well as the physical/technical networks being part of a given infrastructure, and the interconnectedness with other infrastructures and systems. The information/data dimension is related to the technical systems. The organizational/business dimension covers business-related aspects, financial and HR aspects as well as different types of respective organizational networks. The societal/political dimension encompasses broader societal and social contexts. Finally, the cognitive/decision-making dimension, accounts for perception aspects (e.g. perceptions of threats and vulnerabilities) [6].

#### **2.2 Difference and relationship between a risk matrix and a resilience matrix**

One should distinguish well between the risk matrix and the resilience matrix. Although similar in shape and appearance, their basic purpose and principles are different. The main purpose of a risk matrix is to show the position of a given risk (defined through its scenario) on a 2-dimensional "map", depicting the likelihood/ probability of a given risk and its possible impact/consequences. Risk is then, for a given scenario, calculated as the product of the two. The higher the probability/ likelihood, the higher the impacts/consequences – the higher the risk.

Risk-oriented standards (e.g. EN 16991:2018<sup>1</sup> [7]) provide detailed examples of how to use a risk matrix in given areas. Using a risk matrix (sometimes referred as "risk map"), one can easily compare e.g. two risks – provided that the likelihood/ probabilities and impact/consequences can be assessed.

Generally, the aggregation process for indicators in the method and the tool described (see **Figure 5**) here offer the following main aggregation options:

1.The simple aggregation of the indicators put on the common 0–5 scale

3.The JRC composite indicators and scoreboard (COIN) methodology<sup>3</sup>

In the concept, an "issue" is a general term referring to anything important in order to be resilient against severe threats such as terror attacks, cyber threats and extreme weather. It is telling what is important, e.g., it can be "training" performed in the anticipate/prepare phase. Obviously, the more indicators one chooses, the better the "coverage" of an issue is going to be (**Figure 5**), but it is also obvious that

2.The weighted aggregation as an extension of the simple method

4.The Fuzzy-AHP based weight determination [13]

*Example of a 5x5 resilience matrix (a) as compared to a risk matrix (b).*

*Resilience and Situational Awareness in Critical Infrastructure Protection…*

*DOI: http://dx.doi.org/10.5772/intechopen.97810*

**2.3 "Measuring" resilience by means of issues and indicators**

5.The ranking-based weight determination [11]

<sup>3</sup> https://ec.europa.eu/jrc/en/publication/coin-tool-user-guide

**Figure 3.**

**65**

The resilience matrix, on the other hand, serves to map the resilience of a system (e.g. a critical infrastructure such as a large power plant) during an adverse event (e.g. crisis, accident, cyber-attack, etc.). The time of the event is then usually subdivided into phases (**Figure 3(a)**), usually 4 or 5, of the event, from the time before the very event to the time after the event (the "resilience cycle"). The time of the event/ scenario (see also **Figure 4**) is thus, the first and the main dimension of the resilience matrix. As the adverse event, in a general case, will affect different areas of activities, e.g. business, society, information, management, etc. the event is usually looked at for each of them in terms of their own indicators. These areas are often (e.g. in EU projects such as InfraStress [2] or SmartResilience [1, 8–12]), called dimensions, and their number is usually chosen as equal to the number of phases. The result is then a matrix (the "resilience matrix", **Figure 3(a)**), mapping the resilience of the given system – e.g. suggesting the communication "dimension" in the response "phase" of the crisis management of COVID (e.g. in the UK2 ) was "poor" (**Figure 3(b)**).

In the approach presented here, we propose that the qualifier "poor" is linked to the measurable indicators (resilience indicators) such as e.g. reliability of numbers communicated to the public, statistic/sentiment in social media, survey results, etc. In such a case, the label "poor" is supported also by quantitative indicators and can be given an aggregated value (e.g. acc. to the value weight formula).

<sup>1</sup> https://www.cen.eu/news/brief-news/pages/news-2018-011.aspx (Convener A. Jovanovic).

<sup>2</sup> https://reutersinstitute.politics.ox.ac.uk/communications-coronavirus-crisis-lessons-second-wave

*Resilience and Situational Awareness in Critical Infrastructure Protection… DOI: http://dx.doi.org/10.5772/intechopen.97810*

#### **Figure 3.**

*Example of a 5x5 resilience matrix (a) as compared to a risk matrix (b).*

Generally, the aggregation process for indicators in the method and the tool described (see **Figure 5**) here offer the following main aggregation options:

1.The simple aggregation of the indicators put on the common 0–5 scale

2.The weighted aggregation as an extension of the simple method

3.The JRC composite indicators and scoreboard (COIN) methodology<sup>3</sup>

4.The Fuzzy-AHP based weight determination [13]

5.The ranking-based weight determination [11]

### **2.3 "Measuring" resilience by means of issues and indicators**

In the concept, an "issue" is a general term referring to anything important in order to be resilient against severe threats such as terror attacks, cyber threats and extreme weather. It is telling what is important, e.g., it can be "training" performed in the anticipate/prepare phase. Obviously, the more indicators one chooses, the better the "coverage" of an issue is going to be (**Figure 5**), but it is also obvious that

<sup>3</sup> https://ec.europa.eu/jrc/en/publication/coin-tool-user-guide

#### **Figure 4.**

*Functionality level of the smart critical infrastructure over scenario time – The value of the FL at a particular time is calculated by aggregating the relevant indicators scores starting from FL at t0 = 100%.*

the larger the number of indicators, the more complex their handling is going to be. The "way out" has two components and these would be:

• finding the "right number" of indicators acc. to the resilience problem tackled (in the usual engineering practice, managed by humans, 120–150 indicators are usually a maximum – the more critical the situation, the smaller the number; in absolute emergency situations humans can hardly look at more than 3 indicators), and

> values (e.g. numbers of accidents), or from big data analysis. Single, real values, from any of the above sources, in the methodology, can be yes/no questions, numbers, percentages, fuzzy numbers, or some other type. Once in the model, for the communication with the end-user, they are, in a general case, transferred into

*Issues measured by indicators (above), allow to make the bridge between a given, e.g. measured value of an*

One of the ways to use resilience issues and indicators practically [21], is to put them into "lists" (checklist) and in the concept it is done in a dynamic way, allowing to dynamically create checklist appropriate for a given case using available indicators or adding new ones to the list. In order to make the creation/drafting of these dynamic checklists (DCLs) easier and allow for comparison and benchmarking of results, the user is encouraged to use the list suggested by the concept, namely (**Figure 6**):

• The CORE DCLs, containing the indicators suggested for virtually all

• The RECOMMENDED DCLs, containing indicators suggested for the

• The USER's DCL, containing indicators specific for a particular infrastructure.

**2.4 Dynamic checklists of resilience issues and indicators**

*indicator, and the overall, final resilience index & ResilienceCube (below).*

*Resilience and Situational Awareness in Critical Infrastructure Protection…*

*DOI: http://dx.doi.org/10.5772/intechopen.97810*

the score, on a scale 0 to 5.

**Figure 5.**

infrastructures,

**67**

particular type of infrastructures and

• allowing to "drill-down" in cases when one or more indicators need further explanation.

In order to organize the analysis and enable drilling down to the base assessment elements, the selected scenario is segmented into six levels [1]. This practice is based on several previous methods, notably the ANL/Argonne method [14], the Leading Indicators of Organizational Health (LIOH) method [15–17], the US-DHS method [18], and the Resilience-based Early Warning Indicator (REWI) method [19]. The ANL/Argonne method for assessing a resilience index (RI) is structured in 5 levels, providing indicators on the lowest level and a similar hierarchy is used in the SmartResilience and InfraStress projects for assessing resilience levels, entering the indicators on level six.

The "resilience indicators" are mainly taken from current practices (standards, guidelines, reports, etc.) within safety and risk management, emergency preparedness, business continuity, etc. and in most cases, they exist already as safety indicators, risk indicators, or similar (e.g. those proposed by OECD, GRI, API, HSE, IAEA and other organizations). Collecting the indicators and applying the approach, the theoretical framework for variable selection, weighting, and aggregation must be defined [20] and the basis for this is the context of the assessment, or scenario. An example of a "resilience indicator data sheet" is given Appendix 1.

The values of indicators, often for one and the same indicators, can come from experts (e.g. as qualifiers – "high", "very low"", etc.), from measured or monitored *Resilience and Situational Awareness in Critical Infrastructure Protection… DOI: http://dx.doi.org/10.5772/intechopen.97810*

#### **Figure 5.**

*Issues measured by indicators (above), allow to make the bridge between a given, e.g. measured value of an indicator, and the overall, final resilience index & ResilienceCube (below).*

values (e.g. numbers of accidents), or from big data analysis. Single, real values, from any of the above sources, in the methodology, can be yes/no questions, numbers, percentages, fuzzy numbers, or some other type. Once in the model, for the communication with the end-user, they are, in a general case, transferred into the score, on a scale 0 to 5.
