Ciaran Flynn

Hello, my name is Ciaran Flynn, and I’m Head of Governance and Consulting Services here at Arthur Cox. Welcome to our new series of videos, which will cover the more nuanced and complex aspects of resilience. Over the course of the series, we will take a closer look at how firms can build resilience frameworks that are not only compliant with relevant regulations, but are also fit for purpose in today’s fast-moving environment. We’ll also look at how firms should prepare for something going wrong and how they should stress-test those resilience processes.

Resilience is becoming a strategic priority and increasingly the key differentiator between firms. With operating models growing ever more interconnected and disruptions from the likes of cyber threats and climate risks becoming ever more frequent and impactful, firms really need to be prepared to respond, recover, and adapt. In this series, we’ll explore the evolving regulatory landscape, including the growing influence of DORA and the Central Bank of Ireland’s revised cross-industry guidance on operational resilience. This revised guidance incorporates changes which have been informed by recent developments and ongoing industry insight, but are primarily focused on alignment and consistency with those DORA requirements. To support the series, we’ve developed the concise Resilience Playbook.

It summarises the key takeaways and offers practical tips to help you assess and enhance your resilience strategy. For more information, please visit arthurcox.com/resilience. Thank you.

Siobhán McBean

Hello, everyone, and welcome to the first video in our series exploring some of the more nuanced and complex aspects of resilience. My name is Siobhán McBean. I’m a partner in the Asset Management and Investment Funds Group here at Arthur Cox. To start off, I’m joined by my colleague Ciaran Flynn, who heads up our Governance and Consulting Services Group. So, Ciaran, plenty has happened since our last webinar in the area of resilience. Could you provide us with a quick update?

Ciaran Flynn

Absolutely, Siobhán. Thank you for having me here. Since we spoke in June, the Central Bank has somewhat unexpectedly published a revised version of the cross-industry guidance on Operational Resilience to incorporate changes which, in their own words, have been informed by recent developments and valuable ongoing industry engagement. Fundamentally, it is about bringing alignment and consistency with what DORA has introduced to the industry.

We’ve compared the new version with the previously existing cross-industry guidance, and there are three main points to highlight:

1. Separate frameworks – The CBI now expects firms to document both an operational resilience framework and an operational risk framework separately. While they emphasise that these documents should be aligned, they must remain distinct. Previously, a combined version would have been acceptable.
2. Different perspectives – The CBI defines a business service as external-facing with an identifiable external end user from an operational resilience perspective. Under DORA, however, firms must focus on all services supporting critical business functions, whether internal or external.
3. Proportional adoption of DORA – The CBI encourages all regulated entities to adopt DORA requirements proportionately, even if not formally in scope. In short, the CBI views DORA as best practice for ICT risk management and digital resilience, and expects firms to keep this in mind when addressing organisational risks.

Siobhán McBean

It sounds like the Central Bank is really trying to get firms to think about how they approach the various components of their wider resilience framework, and to ensure that their documentation is consistent and coherent across the board.

Ciaran Flynn

When approaching resilience holistically, we suggest clients consider five core pillars:

• Operational risk and business continuity
• Operational resilience
• Digital resilience (ICT risk management frameworks)
• Financial resilience
• Third-party risk management

Today, we’ll focus on the first three.

Operational risk and business continuity looks at an organisation’s authorisation and legislation. Operational risk is an all-encompassing term covering the impact when a process or system fails, whether due to manual error or system malfunction. Firms are asked to consider single points of failure while assuming everything else operates normally. For example, a business continuity plan might cover what happens if a key system goes down or a critical individual cannot perform their role.

It’s important to note that third-party risks, such as outsourcing or delegation, are considered key subcomponents of operational risk.

Operational resilience, by contrast, focuses on external-facing critical business services provided to identifiable end users, such as clients or investors. This lens does not assume a single point of failure but instead considers end-to-end delivery, only where failure could cause intolerable harm outside the organisation.

Digital resilience, under DORA, looks at end-to-end delivery of critical business functions, both internal and external. However, DORA is only concerned with ICT systems and applications supporting critical functions, or ICT third-party providers delivering those functions.

So, while these lenses overlap, each is distinct and can add to the compliance challenge for firms.

Siobhán McBean

A key gap in current regulations is the end-to-end delivery of non-ICT dependent, internal-facing services. Examples include oversight and governance activities such as compliance, risk management, and monitoring service providers. These are core functions for Irish regulated firms, yet they are not considered critical under operational resilience guidelines, nor ICT-dependent under DORA.

Firms must recognise that, even if legislation excludes these in-house services, they remain vital and should be planned for within a resilience framework. So, Ciaran, if we take a step back, what else should firms be thinking about when reviewing their broader resilience framework? How can they ensure they’re taking a holistic view?

Ciaran Flynn

Thanks, Siobhán. Firms that have already complied with the regulations and guidance we’ve discussed have most of the necessary work documented. What may be missing are plans for non-ICT dependent, internal-facing services.

For example, imagine a system outage at a service provider impacting a core business line. The provider should trigger its business continuity plan, implement workarounds, and restore functionality quickly. At the same time, the firm’s relationship manager should oversee how the incident is handled, ensuring alignment with the firm’s third-party management or outsourcing framework.

The question is whether both activities, the performance of the service and the oversight of the service, are being treated equally within resilience planning.

Based on my experience, most firms would probably say no. The disrupted core business line is likely categorised as a critical or important business service, with a tight recovery time objective (perhaps 4–24 hours) and high business impact. Oversight activities, however, are rarely treated with the same urgency, even though they are equally time-critical.

I would encourage firms to consider their governance and oversight activities, and how they would be performed if the network went down and access to email or video calls was lost.

Siobhán McBean

I think that’s a great point. For a firm to be truly resilient, it needs to identify all the functions, services, and activities it performs, regardless of whether they are ICT-dependent or not, or internal versus external-facing. Firms must ensure they have plans in place should something go wrong.

For example, we’re seeing more clients now building resilience requirements into senior leadership role descriptions, appointment letters, and management responsibility maps. Resilience can no longer be considered in a silo; instead, it must be integrated into how boards manage and govern their organisations more broadly.

In our next video in this resilience series, we’ll provide further practical guidance and advice on where to start when identifying business services and functions, and on the importance of mapping critical interdependencies and connectivities.

To accompany this series, we’ve created a concise Resilience Playbook which summarises what we’ve covered and shares additional practical tips and insights to support your resilience journey.

As ever, please feel free to get in touch with your usual Arthur Cox contact, or email us at [email protected] on any issues or topics we’ve discussed today. For more information, you can also visit our website at arthurcox.com/resilience.

Denise Murray

Hello, everybody, and welcome back to the resilience video series here at Arthur Cox. Today, we’re going to explore some of the more nuanced and complex aspects of resilience. For those of you who don’t know me, my name is Denise Murray, and I’m the Head of Financial Services Compliance and Regulatory Relations here at Arthur Cox and I’m joined today by Ciaran Flynn, who’s Head of our Governance and Consulting Services. What we’re going to do today is share with you some insights and thoughts on how firms might approach mapping the interdependencies and interconnectedness that support an organisation’s business services and their resilience position.

Ciaran Flynn

Great. Thanks very much, Denise. It’s a delight to be here. For a firm to be resilient, it must ensure the end-to-end delivery of all activities it supports, its internal and external-facing business services, and regardless of ICT dependencies, thinking about the interdependencies and interconnectedness between all of those things. This might seem like a daunting challenge.

Denise Murray

Thanks, Ciaran. I think it’s fair to say that resilience can feel overwhelming at times, particularly as new regulations continue to make reference and cross-reference back to resilience requirements but when we’re talking to firms and when I’m engaging with firms, we always talk about going back to basics. There’s no single prescribed requirement or starting point in terms of how you’re going to examine your regulations and your requirements in relation to resilience but what we do know is that the regulator, particularly the Central Bank of Ireland, takes an outcome-based approach. So that means firms have the flexibility to choose the identification method and methodology that suits their organisation as long as they can demonstrate that they’ve looked at, assessed, and managed the impacts of a disruption.

So maybe let’s take a moment to reflect on the Central Bank of Ireland’s actual expectations. Firstly, firms are required to have a level of detail that enables the identification of the resources and contributes to the delivery of each stage of the service and their importance. Secondly, the approach and level of granularity of mapping should be sufficient for a firm to identify vulnerabilities and key dependencies, to support testing of its ability to stay within the assigned impact tolerances for each critical and important business service.

Ciaran Flynn

Bit of a mouthful, but they’re our two guiding principles in the context of resilience. When we’re talking with clients, as you know, we usually suggest starting with two things: your authorisation legislation, what you’re licenced to do and your business continuity plans. That’s where you’ve already documented your department’s positions around issues that might impact your continuity. This gives a top-down and a bottom-up view of your operations, and that really positions you well then to start thinking about resilience.

If we take the top-down view first, every regulated firm has a list of services that they’re authorised to provide, essentially the reason why you exist. If we take a fund administrator, for example, the provision of fund administration services is a critical activity. But within that, you’ll find the nuances of the production of the NAV and also interfacing dependencies, such as the stock and cash reconciliations that support that. While the licenced activity gives you the starting point—the service—you really do have to drill in beyond that to understand the specific requirements that are involved in the end-to-end delivery of that service.

So when you’re doing that, you need to think about: what are your clients relying on? What are you relying on? What systems support your services? And what would cause those systems or processes to fail or indeed to harm you, your firm, or the clients that you service?

Then if we take the bottom-up approach, the business continuity plan really is a gold mine. Most firms have had these in place for a number of years. They’ve required their organisations’ departments to document how they keep things going if a system doesn’t work, if the office is closed and they can’t gain access, or if a key person is unavailable. Not everything that you will have included in your business continuity plan is going to be a critical service or a critical activity, but they give you a comprehensive view of what’s happening across your organisation, which ultimately speaks to resilience and bringing all that back into the regulations, then that’s going to allow you to think about the people, the processes, and the technology that supports your resilience position. If I link it back again to those very wordy regulations that we talked about a moment ago and the requirement for granularity, it’s really not about a box-ticking exercise. If you get into that granular level of detail and understanding in relation to the services and the components of those services, it enables you to pinpoint where you may have vulnerabilities, where your processes or your systems may not be as robust as you would need them to be, what controls you may need to put in place, and ultimately it will help you then determine what tolerances you have in the context of things going wrong with those services or processes.

Denise Murray

Maybe just a couple of further thoughts. When we’re focused on resilience, we often think of those people-process-technology requirements, and we sometimes overlook the governance and oversight. That’s really where we’re back into the regulation again. That’s important for firms operating, particularly under a delegated model or with lots of outsourcing relationships, third-party providers, the activities that take up a significant part of your day relate to the oversight of those activities, and they’re essential to your overall delivery and to your control environment. So when mapping services, it’s so important to include your oversight functions. They may not be time-critical in the same way as client-facing issues might be, but they are absolutely central to your resilience posture.

Ciaran Flynn

Thanks, Denise. I couldn’t agree more on that front and I think what firms should be striving towards is finding that sweet spot between identifying a service at too high a level, where every system, third party, process, and person in the organisation is mapped to it, or going too granular and identifying each step in each process as its own activity. It is really about finding that Goldilocks zone in the middle that’s just right for your firm, and that’s going to vary from firm to firm.

So once firms have identified their business services and functions using that top-down and bottom-up approach you outlined, Denise, they will have a complete list of services that they perform in-house as well as what services are performed by external third parties, subject to the firm’s ongoing oversight and monitoring, as you touched on. The next step will be for firms to identify, classify, and tag each of those services and functions as being critical or important business services subject to cross-industry guidance, and which are critical or important business functions, subject to DORA. We’ve outlined some of the key criteria which firms consider when it comes to criticality in our playbook but for the purpose of this video, we’re going to move on to the third stage of this process, which is mapping critical or important services and functions. When we’re talking about mapping, what we’re really talking about is identifying the relevant people, processes, information, technologies, facilities, and third parties which are required to deliver those critical services and functions, and how those dependencies might interact with each other.

This mapping process can take time, but it should be carried out by the employees who perform or support the relevant activity on a daily basis. There is no point in delegating this work. Similar to the identification process, you’re looking to strike that balance between it being too high level and too granular. I think Kraus-Reich remained that perfect example of an unknown vulnerability in this supply chain, which meant that firms were unprepared when something went wrong.

What that example highlighted, however, is that firms are reliant on their primary service providers to share details of their further dependencies on their fourth and fifth parties and that interconnectivity, as well as how they’re working towards resolving the vulnerabilities. I’m sure Microsoft had a large number of queries, shall we say, about their supply chain and vendor management when that particular incident occurred.

Denise Murray

For sure and maybe we’ll stay with that point for a moment because I think it’s quite important. When it comes to resilience, it’s often the most challenging area for firms—identifying and managing those third-party dependencies, particularly where the services are delivered, as you’ve just quite rightly called out there, through layers of subcontractors.

So really getting down into an understanding of how that’s being supported or how the service is being supported becomes even more complex for a firm that’s relatively a small client of a large service provider. In those cases, the risk isn’t just about the service being restored in the event of an issue. It’s about whether the service is restored in a fair way and within the time frames that you’ve planned for in your own analysis.

So as part of the identification, classification, and mapping process that we’ve just discussed, Ciaran, firms should be assessing the business impact of the service and setting clear recovery points and recovery times and objectives in that regard but if a critical service is outsourced, the firm is ultimately reliant on the provider to meet those objectives and to do so in a way that doesn’t prioritise larger clients at the expense of the smaller ones.

And that’s why the issue needs to be front and centre, not just during a crisis, but right from the start of the relationship. It should be considered during onboarding, built into due diligence, and reflected in the firm’s outsourcing strategy. The more dependent a firm is on external providers and the smaller its footprint in that provider’s ecosystem, the more it is exposed, and there may be some more issues if things go wrong further down the supply chain. And that exposure can have a direct impact on the firm’s ability to recover and maintain trust with its stakeholders.

Ciaran Flynn

Thanks, Denise. With that, we come to the end of this video on interconnectivity and interdependence of critical and important business functions and services. Our Resilience Playbook is a great source of information on this and further resilience topics. Join us next time for a video where we’ll deal with what happens when a real-life resilience event occurs and how you can deal with it. For more about all things resilience, please visit arthurcox.com/resilience

Denise Murray

Hello everyone, and welcome back to the Arthur Cox Resilience Video Series. My name is Denise Murray. I’m the Head of Financial Services, Compliance, and Regulatory Relations here at Arthur Cox. In our last video, we explored how you can document and map the interconnectedness and interdependencies that underpin your critical services. Today, we’re going to go a little bit further and we’re going to explore what happens when things go wrong. The shift to digital service delivery has fundamentally changed how firms build and manage their resilience frameworks, but it’s also changed the nature of the dependencies that firms face. In this session, I’m joined by my colleague, Ian Duffy, partner in our Technology and Innovation Group, and together we’re going to walk through how a firm might identify, respond to, and learn from an ICT-related incident. So, Ian, to get us started, could you walk us through some of the most common ways that firms typically identify or become aware of an ICT incident?

Ian Duffy

Yeah, thanks, Denise. Yeah, sure. Look, there are multiple different ways in which clients can identify incidents or become aware of them. And how that happens will, to a certain extent, depend on the nature of the incident. And to be honest, the structure of the client to a certain extent as well. For example, some incidents may originate as a result of a compromise in your supply chain. In that type of scenario, it’s pretty common for clients to become aware of it because they get notified by the relevant service provider. Conversely, it may be that an incident arises as a result of some human error. You could have a staff member clicking on a phishing email, for example. In that type of scenario, you may become aware of it because it’s self-reported. The relevant staff member will let you know, or it may be through your own monitoring of your systems, you actually see that that type of incident occurred. Another scenario, and perhaps the most dreaded of them all is a cyber-attack. That’s where a hacker effectively unlawfully accesses your ICT systems. They encrypt your data, and they issue a ransom demand for the decryption key.

It’s common in those types of scenarios for clients really only to become aware of the incident once they actually receive the ransom demand from the hacker. There’s a few different scenarios in terms of how an incident can occur, how a client can become aware of it, and the type of incident that can actually affect clients as well. There is a fair bit of variety there in terms of the nature of the incident. I guess in that vein, it’s also worth mentioning under legislation like DORA, the concept of an ICT-related incident is actually defined pretty broadly. Under DORA, it’s any incident that compromises the security of ICT systems and adversely impacts the integrity, the confidentiality, the security of services or data. From a client’s perspective, it’s important to ensure that your staff do actually have an understanding as to what actually constitutes an ICT-related incident, because doing so will help them not only from the perspective of being able to effectively identify these incidents and to mitigate their impact and effectively respond, but also in terms of actually being able to prevent certain types of incidents actually occurring in the first place.

Denise Murray

So knowing how the incident might come to light when we have had an incident, it’s been identified, what should we be thinking about or what should firms be thinking about in those first few moments, especially in terms of activating their response plans and engaging with the right people because we know it’s not just about assessing the damage.

Ian Duffy

Yeah, absolutely. Look, when a large-scale ICT incident does happen, I think in the first instance, it’s very much the case that clients should actually see at that point in time the value of the time and effort that they’ve invested into developing their structures, their controls around operational resilience, the ability to effectively respond to incidents, and really that effective response to a large-scale disruptive event is to a large degree focused on the effective deployment of a number of key policies and procedures. That’ll be things like your incident response plan, your crisis communication plan, your business continuity plan. Once you’ve actually deployed those different policies and procedures, it’s really important that key staff members understand what their role is in respect to them. Because to be candid, it’s not really enough just to write certain roles into a policy and assume that people will know what to do when the big incident does actually occur in practice. Really, what you want to do is ensure that those policies and procedures are battle-tested. That can be through things like tabletop exercises, other types of review and training, so that when the big ICT incident does actually happen, people understand this is what’s expected of me, this is my role, this is how as an organisation, we’re going to effectively respond and deal with this incident.

Another significant consideration when it comes to responding to ICT-related incidents is obviously regulatory reporting. From a DORA perspective, this will be focused on trying to establish really whether the incident satisfies the criteria and the thresholds to constitute a major ICT-related incident under DORA, which is reportable to the Central Bank. In simple terms, an ICT-related incident will be a major incident under DORA where it affects your critical services and it constitutes a successful malicious attack on your ICT systems that creates a risk of data loss, or it satisfies two of the other materiality thresholds prescribed by DORA. They relate to things like the number of clients affected, the number of transactions affected, duration of the incident, geographic spread, publicity, etc. If those materiality thresholds are satisfied, you will have to report the incident to the Central Bank on a staggered basis. The first phase of that will be an initial report, which needs to be made within 24 hours or within 4 hours of the incident actually being identified or within 4 hours of it being classified as major, if that doesn’t happen within the first 24 hours. After that, you’ll then have to submit an intermediate report.

The idea there is to provide a bit more information in relation to the incident to the Central Bank, and that has to happen within 72 hours of the initial report. Then thirdly, there’s a final report. That has to issue within one month of the incident, and that will include more substantive detail on the incident. It will be things like information on the cause analysis that’s being conducted, details of the costs associated with the incident, ultimately how the incident was resolved as well. In addition to those DORA regulatory reporting considerations, it’ll also be necessary to think about, well, do we actually need to report this incident under any other regimes? An obvious question to ask there is, is this incident a personal data breach that needs to be reported to the DPC pursuant to the GDPR? One helpful other point just to note when it comes to incident reporting is that if you are dealing with an ICT-related incident that affects payment-related data or payment-related services of, for example, a bank or any money institution, and you determine that it’s a major ICT-related incident that needs to be reported under DORA, hopefully that incident doesn’t also need to be reported under PSD2.

That’s good because there aren’t duplicative reporting obligations in that scenario.

Denise Murray

Lots of reporting, regulatory reporting, lots of consideration of the regulations, but there’s other practicalities as well, right. So maybe could you talk to us briefly about what they might look like?

Ian Duffy

Yeah, look, that’s absolutely the case, Denise. Look, after you’ve deployed the policies and procedures like we discussed, and you’ve thought about those regulatory considerations. There are multiple other practical steps that you need to think about when you’re dealing with a large-scale ICT-related incident. So for example, you’ll need to centralise your facts and then come up with a single version of the truth. You can use those facts and that information to then notify the board in relation to the incident and provide them with regular updates in relation to it as well. Also really key to reach out to your key external service providers at an early stage. So think about your provider of cyber insurance, also IT forensics, external counsel. In addition, if the incident occurred or originated in your supply chain, as a result of an act or something affecting one of your key ICT service providers, it’s really important to establish a clear line of communication with them at the earliest stage possible. So you get the information you need from them, you get relevant updates and regular updates, so as to help you effectively respond to the incident. Look, I think it’s probably implicit in all of what I’ve said there that really a key aspect of that effective response in taking those practical steps is ensuring that there are those clear lines of communication, both internally amongst key relevant staff and then upwards towards management and the board, but also outside the organisation to those key service providers.

Having that effective and clear line of communication to relevant parties will help in terms of your effective response, dealing with relevant regulatory reporting requirements and other relevant regulatory considerations.

Denise Murray

So we’ve had our incident. It’s clear that things are moving fast. We’re communicating and reporting really well. There’s a surge of activity. So teams are mobilised, systems are being assessed, there’s a response team put in place. I think probably, though, helpful just to reflect that it’s not just about that reactive response when we’re in that environment. I think what comes to mind for me in particular, Ian, is that you have to capture what you’re doing as you’re moving along. So that requirement to document what happened before, during, and after your disruption is just as important as those communication channels. It’s important maybe to spotlight that for a moment and maybe just pause on this particular point because it can be really, really difficult after the event to go back and document and remember what you knew at points in time that informed your decisions, that drove you through the process in what typically is quite a fast-moving, pacey environment. But nonetheless, the expectation is there that you will document and that you will have a good record, not just of your communications, but of how you managed during the process day to day.

And look, we always hope for a quick fix for issues, but unfortunately, that’s not often the reality. From experience, the scale of the effort that goes into managing the aftermath can be a little bit underestimated, whether that’s restoring the service or addressing the vulnerabilities and improving and enhancing arrangements and adopting or adapting to a new norm. What often sets firms apart, and you’ve mentioned this already, is that communication through the process, transparency being key, making sure stakeholders are managed and informed within the business through the board, because it’s not just about technical recovery. From my experience, it’s really about information, reassurance, and engagement with your key stakeholders. You’ve mentioned that, Ian, and that might be your board, it could be your regulators, external parties, but they need to know that you’re in control and that you’re aware of their concerns, that they’re being addressed, and particularly, I think, in financial services context. But interestingly, I think one of the really good examples we have recently is Marks & Spencer. The CEO, in that instance, used social media, which, let’s be frank, is probably their effective communication channel in good times, but they used that to keep their stakeholders up to date during their disruption.

Maybe a really good example to reflect on in terms of proactive engagement and evidencing that leadership to build trust and retain confidence.

Ian Duffy

Yeah, no, absolutely. Look, when you do get to the end of an incident and you’re getting back towards BAU and the incident is resolved. Obviously, there’s going to be a sigh of relief from all involved because these things are pretty intense. But to pick up on a thread you mentioned there, Denise, that’s not really the end of the road from a regulatory compliance perspective. There are multiple things that the affected firm needs to think about to ensure that they do see the journey through from a regulatory compliance perspective. One of those will be that final report to the CBI that we talked about in relation to the incident from a DORA perspective. So providing that information around the root cause analysis, providing information on how the incident was resolved, etc. There’s also requirements we need to be alive to under the CBI Operational Resilience Guidance as well. There is that expectation once you get to the end of the incident and it’s resolved and you’re looking back that you carry out a lessons learned session to figure out effectively what happened and how can we perhaps adapt in ways that help us to ensure that this doesn’t happen again, or if it does happen again, that we can respond more effectively.

As part of that, you should develop a set of predetermined questions that you ask yourself in that type of scenario. That will be things like, how did this incident actually occur? What vulnerabilities did it expose? How did it impact our critical services? How quickly and effectively did we respond and recover from this incident? Once you’ve done those final few steps, I guess the final thing you want to think about is any remedial actions you’re going to take off the back of that, right? Any remedial actions you are due to take, ultimately, you’ll want to make sure that they’re logged and that they’re monitored by senior management and the board so that there is that continuous improvement of your operational resilience profile. I guess if the incident did originate in your supply chain, which is a concept we’ve touched on a couple of times, you may need to think about, well, look, do we need to revisit our contract with the service provider? Do we need additional protections, controls, processes to try and help ensure that this doesn’t happen again through our supply chain, or that if it does, we’re better able and better prepared to respond to it?

Of course, look, when you get to the end of an incident, you also have to think about, well, how effective were all of our policies and procedures that we used in response to them? We have them on the shelf, they’re written down, they look great, but now they’ve actually been used in the real world and properly road-tested and were they effective or do they need to be adjusted and slightly adapted? So if something like this does happen again in the future, we have an even more effective process that we can roll out to help us respond to it.

Denise Murray

And that neatly takes us back to the starting line with policies and procedures that have been battle-tested and that are ready to be deployed the next time an incident occurs. And with that, we’ve come to the end of this video series today. And we’ve really explored what you do when you identify an incident, how you respond, and most importantly, how you learn from it. Our Resilience Playbook can provide you with some more information and it’s a useful resource as you are exploring your resilience frameworks and your resilience response. If you have any questions, please do reach out to us, to your usual Arthur Cox contact. Alternatively, you can send us an email at [email protected], or you can find more information on our website at arthurcox.com/resilience. Thank you very much, and see you next time.