The European Union’s (EU) new Digital Operational Resilience Act (DORA) is set to reshape how financial institutions handle their cybersecurity and operational risks. Taking effect in January 2025, DORA will impose a range of new standards and requirements. However, with detailed guidelines (level II texts) expected only by late 2024, firms face a tight timeline to meet compliance.
DORA’s comprehensive regulatory framework aims to enhance the cybersecurity and operational resilience of financial entities within the EU. By introducing uniform standards across the financial sector, it ensures consistency in cybersecurity practices and strengthens operational resilience.
Navigating DORA compliance webinar
DORA compliance involves rigorous oversight of third-party service providers. Doing so requires thorough due diligence and continuous monitoring of third-party relationships to identify risks. DORA also establishes a robust incident reporting framework, compelling firms to notify regulators of significant incidents. Financial institutions must conduct advanced testing of their digital operational resilience capabilities. Part of this includes through penetration testing, vulnerability assessments, and simulation exercises.
DORA emphasizes strong governance and risk management frameworks, pushing firms to establish clear cybersecurity policies approved and overseen by senior management. This comprehensive approach ensures that all employees understand the importance of operational resilience and fosters a culture of accountability.
Hosted by GRC World Forums, in partnership with Resolver, our webinar will help you prepare well in advance for the changes that lie ahead. Watch the replay, or download the presentation, to gain insights on:
- Preparing Early: Essential steps to prepare for the Digital Operational Resilience Act’s impact in January 2025 to meet tight implementation timelines.
- Adapting to New Requirements: Understanding how the Digital Operational Resilience Act will affect operations in the financial sector and how to ensure compliance from day one.
- Best Practices and Standards: Gain insights into the sound practices and global standards that will shape DORA’s implementation.
- Leveraging technology: Learn a frustration-free process with requirements mapping and automated controls to prepare for and attain DORA compliance.
Read more: Diving into the Digital Operational Resilience Act (DORA)
Q & A
I work in a global financial services company, is there or will there be a US equivalent of DORA?
Answered in webinar recording.
May the regulation have consequences for organizations that are not financial entities but which are a subsidiary of a financial entity?
Answered in webinar recording.
Can you highlight the key differences between DORA and SOC2 requirements?
SOC 2 is a cybersecurity compliance framework developed by the American Institute of Certified Public Accountants (AICPA). The primary purpose of SOC 2 is to ensure that third-party service providers store and process client data in a secure manner. As such, it is commonly used by organisations to attain a level of assurance over the security posture and practices of third party/suppliers.
While SOC2 compliance is good to have, and the activities/programs implemented to get it will help address some of DORA requirements, DORA is much broader and prescriptive. As such, we recommend reviewing the DORA text and underlying RTS/Guidelines in the context of your business/operations and current ICT program/practices, and the conduct a detailed gap assessment to identify ensuing uplift/remediation work required to ensure that DORA’s expectations are being met by your organisation.
How does DORA impact a UK firm with EU customers?
Answered in webinar recording.
What do service providers to financial institutions regulated by DORA need to consider and what actions should they take now?
Service providers should undertake their own review of DORA, particularly of the requirements their clients will have relating to compulsory clauses in contracts to prepare for the renegotiations. Specific provisions relating to access rights to data for the client and for their regulatory authority should be understood so that when the service provider is asked to honour those contractual commitments their operational setup allows them to do so.
Is UK 100% in line with DORA i.e. is all of DORA UK law?
Answered in webinar recording.
High level comparison between DORA vs. NIS2?
Both regulations are a result of European regulatory bodies increasingly viewing and pushing cyber / digital risk under a wider “Operational Resilience” umbrella. As such, NIS2 and DORA thus both aim to consolidate and harmonize the different aspects of Digital / Cyber Risk into broader Resiliency-themed regulations.
- DORA – focuses on financial industry with over 22,000 organisations in scope. Coming into force in January 2025.
- NIS2 – focuses on critical and essential services (e.g. power, water utilities etc), with over 100,000 organisations in scope. Coming into force in October 2024.
We are card processor (Master/Visa/DCI) and we are PCI DSS certified. We are not financial institution. Do we need DORA?
There is a broad list of organizations in scope of DORA, however there is also certain provisions for certain types of organizations which require less stringent adherence to its requirements. If in doubt about its applicability to your specific organization, we recommend consulting with your internal Legal and Compliance team in the first instance to assess this.
If we outsource majority of our IT services, to what extent are we bound by RTS1 directly and should we impose on our supplier to show evidence he has the relevant documentation as stated in RTS1?
Answered in webinar recording.
Will DORA be applicable for non-bank financial institutions?
The scope of DORA application is for all financial entities as defined in the texts. We would encourage you to review the regulations to confirm their applicability to your organization, our understanding is that NBFIs are in scope.
If we outsource majority of our IT services, to what extent are we bound by RTS1 directly and should we impose on our supplier to show evidence he has the relevant documentation as stated in RTS1?
It is the responsibility of each organization in scope of DORA to ensure their compliance. Where the majority of IT services are outsourced, it is still incumbent upon your organization to ensure and be able to demonstrate that your suppliers are adhering to DORA in the services they supply to you i.e. via the appropriate governance and oversight. This would include, inter alia, the population and maintenance of DORA third party registers, as well as appropriate metrics/SLAs with regards to the IT services that are being supplied.
Are autonomous security checks, i.e. procedured implemented by software processes 24/7) mentioned in the ICT procedures or elseware?
Autonomous security checks - vulnerability and secure configuration scanning for example – are required / stipulated within the DORA texts.
Are there specific guidelines on what incidents are deemed significant or is it upto the firms to determine this?
Yes, there are specific guidelines / criteria and materiality thresholds set out in DORA for determining major ICT- related incidents, which include: number and relevance of users/clients impacted, the criticality and duration of service downtime, geographical spread, type of data loss, severity of impact, as well as economic impact.
Is it the determination of the regulated financial services firm or does the third party ICT service provider have a say in the determination of whether the provider is a critical service provider?
When considering this point it is important to distinguish between two different concepts in DORA with regard to criticality of ICT service providers:
- Where an ICT provider is supporting an organization, it may be requested by the organisation to update contractual provisions to align with those laid down by DORA. Each FI in scope of DORA is responsible for defining the criticality of their 3rd party services (with the highest falling into/mapping to the category of “Critical and Important Functions”, and these must be determined by the individual entity themselves based on an assessment of their business operations; so not the responsibility of the provider themselves (however, the ensuing discussions could/would be collaborative).
- DORA also has a separate definition relating to regulatory supervision of ‘Critical third-party providers’. These are organizations which have a high concentration across the FS sector at a European level. These organizations, for example, include certain cloud providers, which will be subject to additional/separate regulatory oversight by the European Supervisory Authorities.
- These organizations will not have a say in this determination as to whether or not they are indeed critical third-party providers.
Could you expand on the respective roles & responsibilities of the key stakeholders to be involved in DORA implementation (CTO, COO, CISO, CRO)?
Answered in webinar recording.
We are a company providing Business Information for KYC, KYB and AML purposes, Credit Reports, Due Diligence reports. Is DORA applicable for our company?
You should look to confirm whether your organization would indeed meet the definition of an ICT Third Party Service Provider under DORA. ICT Third-Party Service Providers are firms providing digital and data services through ICT systems to one or more internal or external users on an ongoing basis. The definition of 'ICT' under DORA is rather broad, so it includes digital and data services provided through ICT systems.
Webinar Transcript
Read Transcript
Hannah Rossiter:
Hello, I hope you can all hear me and welcome to the session today being run by the three of us. You can see on the screen we'll get onto some introductions in a moment, but my colleagues and I are here to talk to you today about how you can prepare for a major new piece of legislation that's coming online within the EU, the Digital Operational Resilience Act, which is part of the EUS framework applicable to financial services firms.
We have, I think, a 60-minute slot and there will be some poll questions as we go through the session today. So make sure you are ready to answer some of the questions that we have for you today and we'll be giving you some feedback on the responses as we go through the presentation. If you have questions as we go, please make sure you put those in the chat.
We will do our best to respond to those very likely at the end of the session or in some follow-up that we can have when the session is over if we don't have time to do that. So your questions are very welcome today, some high level indications of what we're going to be talking about today. So we will, because we're talking about rules, we will be looking at the rules.
Stay with us for the first section where we're going to be talking about the regulatory framework, how it's come about, what it involves. But I think quite quickly we're going to get onto some of the challenges and the different aspects that we can support with. And towards the end, we're going to be talking about the different solutions that Resolver and Kroll together can assist with. So very, very briefly, and I think I'll give you Tiernan an opportunity and you Pooja always better to speak to yourself than have someone speak to you.
My name is Hannah Rossiter. I'm responsible for the firm's service offering in relation to financial services, compliance and regulation in EU and in the Middle East. And I've got around about 25 years plus track record helping financial services firms with their compliance and regulatory requirements.
Tiernan and over to you. Couple of words about yourself.
Tiernan Connolly:
Thanks Hannah. Hi everybody, my name is Tiernan Connolly. I'm Kroll Cyber Advisory Lead for EMEA and I'm based out of Dublin, Ireland. So yeah, I work with clients to help them understand and address security as well as the regulatory risk around cyber and tech and help them design and implement security strategies and programs.
Pooja Azhalavan:
Awesome. I'm Pooja and I work for Resolver. I'm a Senior Manager of Product Marketing based out of Toronto. So you can see we're all over the globe here. My role really constitutes working closely with our customer base, identifying pain points, challenges in market around GRC, and then feeding that back into our product teams to really build global world-class solutions that can help support your programs. So nice to meet you all.
Hannah Rossiter:
Brilliant, thank you. So just a reminder of who Kroll is, who Resolver is. We are part of the same group. Kroll acquired Resolver a couple of years back, and so we have a global I guess or comprehensive service offering which we can bring to the table. We have senior technical experts in the areas that you have in front of you today who work hand in hand with our colleagues and Resolver, very much skilled in providing risk management solutions and software solutions to clients in terms of risk management.
Enough about us, let's get onto the first poll of the session today and we'll try and give you some feedback on these responses which are going to take a little while to feed back to us. So the first question we have for you today is has your organization conducted a DORA gap assessment? You've got three possible answers here.
A is yes, B is no, and C is, I'm not sure. So please take time to just select the appropriate answer for your organization. And whilst you are doing that and our teams behind the scenes are putting the responses together, we'll move on and start having a look at what DORA compliance is and some of the high-level requirements that have come out of the Digital Operational Resilience Act.
It's a piece of legislation that's already in force came into force last year. The way that the rules have been structured is they're actually kick in and take effect for regulated entities for financial entities, financial services firms in January of next year, which is why this is an area of much interest this year because the implementation exercise is obviously something that's front of mind for anyone that's caught by the DORA framework, what's it trying to achieve?
DORA is the EU's proposal in terms of selecting, in terms of improving cybersecurity and operational resilience in the financial services sector. So it's no secret to anyone that increasingly financial services firms are targeted by subject cyber-attacks and that data and confidentiality is more and more important. EU making a regulatory push here to make sure that financial services firms are taking these risks seriously. And we'll see later the governance and third-party risk management requirements that are going to be generated through DORA.
There is a program of revision of the existing rule books also ongoing. So other financial services regulatory frameworks such as Solvency 2, MiFID 2, AIFM, soon AIFMD 2 all in the process of being revised and are going to be aligned so that DORA will integrate with those other directives. And so we'll have by the time we get to January next year, a fully integrated regulatory framework.
A lot of you will already be familiar with the way that the EU legislative process works. So we've got the level one text which have already come out, and then we have what are commonly referred to as RTS and ITS. So these are technical standards or guidance documents when you get further down that list or they give more and more detail on the types requirements that the firms are going to be subject to.
Sets of RTS that will come out in relation to DORA. One's already come out in January of this year and dealt with the topics that you can see here. So what functions are critical when provided by third party providers? What does the information, the register of information that you have to retain around these providers look like? And then more RTS coming out in July of this year containing a lot of the information or the points that we've listed here.
So some templates we're expecting to see in July and more detail around subcontracting arrangements, threat-led penetration testing. Our assessment as a firm is that we already have and the implementation exercises we're already starting mean that we've got good visibility even on the areas where perhaps we're still expecting more detail from the European Union, but the content and the exact detail of those requirements is still to arrive, but we've got a good sense of what that's going to look like.
The objectives are, as I've said, to try and promote increased safeguards within financial services firms against cyber-attacks, improve frameworks around ICT risks and make sure that that's harmonized across the European Union because up till now each individual member state had had different rules and different regimes in this area. So if we can go onto the next slide, we think around about 22,000 firms likely to be caught by DORA.
And so those firms, we've got some examples of those listed here. So if you're an asset management company, an investment firm, an insurance company if you're a digital asset service provider, also crypto firms also caught by these rules, credit rating agencies and also the ICT third-party service providers themselves are caught by the provisions in DORA.
And so it's a large population of firms that are going to have to get their arms around quite some new rules and regulations. There is however a proportionality principle applied throughout DORA, and there are two ways that firms can benefit from that. There is, and my colleague Tiernan is going to talk to this in a little bit more detail in a minute, but there is an exemption that's been defined for very, very small businesses which are referred to as micro enterprises. So they can effectively opt out of a lot of the heavy lifting in DORA.
And there's also for small and non-interconnected investment firms, there's a simplified framework that you can apply in terms of risk management for ICT. So there is on the lower end of the spectrum, if you are a small firm and you're worried about how complex an exercise this is going to be, and we'll talk about this in a little while, there is the possibility to look at either the exemption or the proportionality principle and see the extent to which you are going to be required to comply. One thing to note is that the application of DORA, so it's EU applicable rules, so all financial services firms authorized in and operating within the European Union are caught by.
This will also be caught by this then entities that are subject to specific regulation in the EU but happen to be part of a broader group maybe where the parent company is outside of the European Union. And we'll come back to this in a minute.
The issue around what to do if you're in a group setup and what's important to note is it's the individual entities themselves. So the independently authorized and regulated entity that is responsible for implementing a DORA framework that is suited to its own risks and businesses. It's not a sort of group wide application of the rules, it has to be done on an entity by entity basis.
So if we can go onto the next slide, this is really just to try and help visualize the main areas that DORA addresses. So a lot of what you'll see when you start looking at the detail of DORA is a focus on governance when dealing with these types of risks, identifying them correctly, identifying any mitigating controls and then making sure that the levels of residual risk are ones that the firm is happy to bear.
So that's a big part of it. And we'll see governance, policies, procedures, the sort of whole papering exercise of making sure that the rules have been understood and are properly implemented is a large part of what needs to go on incident reporting. Tina's going to talk to this in a bit more detail, but you'll be concerned at some of the timeframes that DORA imposes in terms of reporting requirements.
They are very tight indeed, digital operation, operational resilience testing is also a big part of making sure that on a regular basis you're testing your own infrastructure, you're doing so in a way that is giving you comfort but also giving the regulator comfort. Third-party risk is a key part also, and I'd probably say that along with the governance part is probably the key part of the workload that you're going to have ahead of you.
So there's lots of rules around contracting with and then ongoing monitoring and surveillance of the service that you're getting from third party providers and sharing of information, also reporting requirements, holding registers, all of those things are key parts of the rules. All of this together is intended, it shouldn't be seen as, and it's not intended as an additional burden on firms. It's actually there to promote and enhance the resilience of the individual businesses that you're each operating and running.
There is a shared understanding between the regulator and the sector that this should benefit everybody, clients, firms and the regulator authorities together. So I think we might have a moment now where we can just look back on the poll question results before I hand over to my colleague Tiernan who's going to talk to the next section. When we asked you the question around has your organization conducted a or a gap assessment, 31% of you responded yes, 47% responded no. And 22 were not sure.
So that's a short third. I would say that no, that one's happened and that means that two thirds of participants today are either no it hasn't or aren't sure whether it has, which is interesting because time is ticking on over to you to talk to the next section of our presentation, which is really focusing on some of the ICT risk management frameworks.
Tiernan Connolly:
Thank you, Hannah. So in this section we'll look at the first three pillars of DORA, which focus on ICT risk management, resiliency testing and internet reporting. So here DORA outlines specific requirements for organizations to embed a comprehensive risk management framework idea being ensure you've got operational resiliency for your ICT systems. This encompasses a mix of technical prescriptions and monitoring requirements to cover governance roles, responsibilities, as well as those policies and procedures that Hannah mentioned.
As well as on top of that you've got carry out a bunch of regular assessments as well and programs around these as well to make sure that they're running in a repeatable and evergreen manner. And then in the second pillar then we have of course those incident reporting requirements to the regulators. And then the big ticket item in pillar tree around resiliency testing is the threat led penetration testing, which we'll cover in a moment.
So first looking at that risk management pillar one section, this is covered in the level one DORA text as well as the more prescriptive regtech standards as well. And the reality here is many organizations should already have a lot of this covered in terms of the activities that are required because DORA compliance is essentially revising and expanding upon existing EBI guidelines around cyber and IT risk management.
One thing, however that does jump out is even greater emphasis for DORA as putting on the company's management body and board as being ultimately responsible for digital operation resilience and ICT risk management. So what does this mean? It's basically incumbent upon the management body to define, approve and ensure there's implementation and then oversee the ICT risk management framework and the digital operational resilience strategy. And they need to maintain what's described as sufficient knowledge so at all times of the risks and the measures that are in place to mitigate them.
So they also need to allocate responsibility for the monitoring of various risk domains such as third-party risk, for example, making sure that a designated senior manager is responsible for overseeing the related risk exposure. So in addition to this, and as you can see here on the right hand side this slide, there is quite a large number of policies and procedures that are required to be created or uplifted from DORA.
Many of these, a lot of you would probably have in place already such as incident management and asset management, but we're also seeing requirements for other specific policies and procedures in relation to wider ICT domains outside of cyber. So, for example, project management and also change management, which in some cases the regulators have oddly conflated the requirements for both of those together. Yeah, and then I think the other aspect is the formal processes.
It's really important to have formal around these and also conducting detailed risk assessments to make sure that they're working properly. But also door also requires detailed risk assessments following significant changes to your network infrastructure as well as specific requirement to at least annually risk assessed your usage of legacy technologies within the environment. Obviously because they represent much more security risks in relation to patches potentially not being available for example.
And then just to finalize and to tie in what Hannah was saying around this business resilience umbrella for these types of risks. We're seeing this pillar and the ICT risk management requirements here, including requirements to integrate cyber and tech risk into firm-wide business continuity processes. Testing business impact analysis as well as response and recovery plans. This is a clear sign that the regulators want cyber to be viewed and treated as an operational and business resiliency risk.
If we move on to the next slide, just quickly cover some of the ICT systems protocols and tools. We've listed out quite an large number of examples here, but in short, DORA compliance is expecting all these policies and processes that I've just mentioned are then used to support the establishment of appropriate tech cyber protection measures that when combined together ensure you've got sound network and infrastructure management. So what does this mean?
Essentially, you've got to implement repeatable evergreen programs for pretty much the full spectrum of security information security and domains like security awareness, patch management identity and access management, as well as monitoring the conducting of regular pen testing, vulnerability scanning, as well as less probably regular exercise such as tabletop exercises. These need to be clearly defined, designed and implemented with appropriate governance reporting and metrics over them to provide assurance of their effectiveness but also allow to identify and proactively any issues and escalate them to the appropriate folks as required.
So, moving on to the next slide here. We just dive a little bit deeper into some of those resiliency testing activities that DORA as expecting organizations to execute to be ready to identify vulnerability proactively, but also to respond to those inevitable incidents that will occur. These tests, the test results and the plans for executing these need to be clearly documented. The regulars need these to be what they often term is readily available for when they actually require them, or the national competent authorities ask questions around this.
This list here is not exhaustive, but some of the key activities to ensure your effectiveness of control include vulnerability scanning. That would tie in with patch management and hardening as well. You've got regular penetration testing and as well as incident response tabletop exercises, which are a really valuable means for rehearsing, educating and preparing internal stakeholders for a major cyber incident, for example.
And of course, there the third one across, we have the threat-led penetration testing, or TLPT for short. This is essentially a Red Team exercise and it's particularly relevant for if your organization is deemed significant under the ECBs Single Supervisory Mechanism. So that means you'd have to undergo one of these TLPTs at least every three years. And these are very tightly controlled assessments, simulating the techniques and tactics and procedures of real-life threat actors.
It's very important if you're in scope for TLPT to prepare and plan well in advance. You need to identify your critical or important functions. These are services that if the impact, it could have a material impact on your business or its clients or the markets or your clients or the markets. And then mapping out the underlying systems and processes that should be in scope for these types of tests. One final note on this as well is while there are specific methodologies for TLPTs that are shared in DORA, they also point to a European framework for threat-led penetration testing.
These are very specific guidelines, very prescriptive on how to not only conduct the test but also to identify and procure the threat intelligence and Red Team vendors as well just to carry that out. So yeah, very highly recommend getting ahead of that if you are in scope for that because they can take up to nine months to carry out and that's not including the remediation activities that would follow on from it. Moving quickly onto the next slide.
This is an overview of the door incident reporting requirements. Entities are required, as Hannah mentioned earlier, to report now to the regulator for all major incidents. So the impact is determined by considering what DORA's predefined criteria, which covers several different criteria and including the number of relevance of users and clients, the criticality of the service impact and the type of data as well that's been impacted.
The exact reporting requirements, the timeframes and the actual reporting templates have been published in the second batch of RTS and include an initial report needs to be sent within four hours, for example, after determining the incident of major, but in any event, within 24 hours of detecting the incident. Then following on from that, you've got an intermediate notification which is required 72 hours after they classifying the incident as major and then a final report is required outlining details of the incident resolution and root cause analysis.
These requirements, as you can see, represent quite a challenge and turnaround times for organizations. It would really require precise incident response plans along with pretty seamless coordination between incident response teams as well as the impacted business functions as well who will need to help classify these incidents.
It's important to know however that DORA is obviously trying to harmonize the reg landscape and reduce the burden for organizations. This incident report requirements are what's termed lex specialis for over PSD2 and NIS-2 for example, their reporting requirements. So essentially it subsumes and replaces those requirements for in scope financial institutions. Okay, I'll hand you back over to Hannah now to cover third party risk.
Hannah Rossiter:
Thank you. Thank you very much Tiernan. And so yeah, we'll have a look whilst you're reflecting on whether four hours is enough time to make the relevant report, let alone or certainly not enough time. If you're also then going to use that four hour window to determine whether it's critical or not, you'll have understood that where the challenges lie in some of these tight deadlines.
We are going to talk now a bit about the other area that represents quite a bit of the work that needs to be done in terms of door implementation, which is third-party risk management. So a lot of emphasis on first of all determining which services are going to be considered as critical service providers. And then once you've made your determination and you've got your subset of critical service providers accurately defined, then there are quite a lot of requirements that you're going to have to understand and then implement.
Now most financial services firms are not unfamiliar with the challenges of onboarding service providers and making sure that you're going through a proper due diligence exercise and a proper and that is then documented and that you then conducting ongoing monitoring. But the requirements in DORA go above and beyond some of what we've already seen in things like or other directives like MiFID or FMD and of course quite we'll have a high information security component to them.
Some of the areas here, you're not going to be surprised to see. There has to be proper documentation in place and proper governance and oversight of the relationship with the third-party due diligence and a selection process that has to be documented. Specific contractual provisions are required. We'll have a look at those later.
I think at one point we list them out for you on the slide, the minimum standards that that provider must adhere to and what's going to happen if they don't deliver and you need to move away from that provider.
There has to be a contractual ability for you to be able to end that relationship and select another provider in a way that doesn't prejudice the security of the information in the firm or your clients, the service that you're providing to clients.
And there'll have to be provisions and agreements with service providers that as a regulated entity you have access to and audit rights some on the data and the services that they provide to you. And those service providers will have to agree to that. I mentioned earlier that there are considerations when it comes to intergroup entities.
Now the regulatory take on who's responsible for door implementation, as Tiernan said earlier, it's the corporate offices and the senior management team at the regulated entity. And the supervisory approach will be to look at that regulated entity to ensure that it is DORA compliance.
But there are also complexities that will come in or other considerations that will come into play if you have other group entities who in fact on examination are considered to be providers of these services, they will also have to look to make sure that they are compliant and the relationship between those group entities is compliant with the door rules.
It's worth pointing out here that within the EU, and it's true actually more generally internationally, regulators don't make any distinction between services being provided from an arm’s length third party or services being provided from another group company. So as far as the national competent authorities is concerned within a specific EU member state, if your London entity is providing these critical services to one in Paris or Dublin, they have the same obligations in terms of compliance with DORA as a third-party that provides those same services on a commercial basis, on an arm’s length basis.
Now, proportionality principles will also apply here, but I think it's important to go away to today with the idea that there's no free pass if these services are provided into group, that they will be subject to as much scrutiny as if they have been provided by an external provider.
There's a requirement also under DORA for critical ICT third-party service providers who are established in a third country. So outside of the EU, they can only provide these services to EU regulated entities if they have a subsidiary that's set up within the EU and the actual rules require them to have one set up within 12 months of their appointment.
But in actual fact, what we're seeing is the main players in this sector have already 12, 18 months ago started along the path of making sure they have a presence for those that didn't already have one. So if we can look at the next slide, we'll look now at, I mentioned I'm afraid the text is a little bit small here, so a lot of different provisions here. You'll see over 15 or so requirements, things that have to go into the contract that you have with your third party provider.
This, as you can see, is going to require a major repapering exercise or at least a review of the contracts that you have with all your providers and is going to give rise to quite likely some considerable back and forth and renegotiation of these provisions.
Now when we're working with firms today trying to help them get through this process, it very often falls to external support, external council to come in and assist with this renegotiation exercise because it quickly becomes quite onerous. The challenge also today, given that the rules are not yet in effect and we don't have the benefit of any enforcement action or additional guidance as you often get after a couple of years of rules being enforced, is there is still some uncertainty as to some of the detail on some of the provisions, some of the requirements around the contractual provisions.
So that's likely to add further time and complexity to the negotiations with the third-party service providers that you are engaged with. A lot of what's required here is not new to people that are familiar with the requirements for onboarding critical service providers. There are restrictions around outsourcing or further outsourcing or delegation. You have to be specific around the governing laws and jurisdictions in the contract, particularly I mentioned this already, your rights as a regulated financial services firm to access data and recover information that the provider has held for you.
And there'll be detailed requirements in the contract around what reporting is required. So if we move on to the next slide, really here what we're trying to show is you've got two, three stages to the process selection and onboarding and offboarding. We are really in a due diligence or an exit strategy and that contractual phase is of primary importance and reviewing the contract if you are looking to terminate, but in the middle you've got requirements around ongoing assurance and monitoring of the provision of from these third party providers.
That's very much a key part of the regulator's expectations that you are able to demonstrate that you do that, excuse me, and that you're doing it in a way that you can evidence. I think Tiernan said a few minutes ago that mentioned the importance of documentation as a very basic rule. If you can't demonstrate it, if it's not written down, then it didn't happen as far as a regulator is concerned. So it's very important that you're putting an audit tail together, which means that you can show the annual review exercise that you've been through to support the ongoing assessment requirement. That's part of DORA.
We've tried to summarize here some of the information that firms are going to have to capture in an internal register that they need to keep. This is part of the requirements under the rules and you can see there's a lot of detail in here in terms of the insight into and granularity on the relationship that you have with the provider, the descriptions of the services that are being provided when the most recent assessments were taken place and these information registers we are already starting to understand they need to be prepared, kept up to date.
And I think the terminology that Tiernan referred to you earlier is kept readily available for NCAs within the EU. But actually what we're starting to see already is some of those national competent authorities are expressing the idea and in some cases actually saying that they will ask for access to those registers.
So be prepared, make sure that they are to the standard required that they are kept current and that you're not caught off guard by request from your NCA who says, please can you share your register with us. That is not the point in time where you will be able to put something that will pass muster together and hand it over Tiernan and back to you to talk about how proportionality comes in to DORA.
Tiernan Connolly:
Thanks. Thanks Hannah. So proportionality is you see this in this two requirements as well. That which is also coming into force into the EU shortly as well. This is a principle that is extremely important in DORA compliance. So it's important that you familiarize yourself with it and understand how you can leverage it and also to assess and plan your remediation activities.
As we've seen, DORA wants us all to assess and understand the risks that are facing our organization around ICT. Now the implementation of the associated countermeasures, however we can reply in a proportional manner that manner that's commensurate with those risks. So what does this mean in a practical sense? As you can see in this slide here, we've outlined the requirements for micro-enterprises versus full scope firms and how the benefit of flexibility that Hannah mentioned earlier can be used for micro-enterprises to apply that proportionality principle.
If you look at here, for example, they won't have to define specific roles and functions for overseeing risk, including third-party risk as well. Around crisis management, they've got less stringent rules. They won't need to conduct those risk and legacy assessments that I mentioned earlier as well, as well as they don't have to have formal monitoring of technology developments as well. This proportionality principle is actually peppered right throughout the door of text and the RTSs.
That aim is really to allow organizations to balance the appropriate implementation of those measures, which is extremely important. So you can focus on the specific risks your organization, and invest in the right security measures, where you can actually reduce the biggest risk to your organization and not try and boil the ocean from the beginning, which is quite a daunting task for anybody and ultimately an ineffective approach as well to risk management.
So if we move on to the next slide, we've got our second poll here. The question we have here for if you could answer is have you established whether your organization is a micro-enterprise or a full scope firm, or is this still to be done? The potential answers here are yes, no, not yet started or finding it difficult to understand the rules, which is understandable.
We'll come back to that in a moment, which we give you a chance to answer that. This is a quick slide just to give you some of the potential pitfalls and recommendations. Based on my experience of working with organizations and speaking to the regulators across Europe over the last few years, here are some key challenges that I'd recommend watching out for and planning for when delivering your DORA program.
So first one here is DORA compliance is very complex and wide ranging. Getting that stakeholder awareness and buy-in is critical. That means ensuring you're communicating, educating and gathering support from senior stakeholders and sponsors for your DORA compliance program. Ultimately, senior management, the board, are accountable for direct compliance, so it's in their own best interest that they know what's happening, what's required, and the complexity of some of these remediation tasks as well, as well as the resources that's required to ensure compliance.
Secondly, here we have DORA compliance requirements, especially around those RTSs that can be very prescriptive and actually very challenging to interpret as well in some instances. A top tip here, which Hannah just kind of covered as well, is when you're doing your gap analysis, clearly document your not only if it's a gap, yes or no, but what's your interpretation of that citation and its requirement.
And that'll help you not just for inspections in the future, but also for internal audits or second line compliance assessments as well. And then again, we've got proportionality there mentioned that earlier. Very important to understand that for planning and assessing out your gap assessments and remediation. And those third-party register templates, I can't emphasize enough, don't leave it to the last minute to try and prepare plan and get automation around the population and maintenance of those if possible.
Before even doing that, make sure you've got clear ownership as well within your organization who are accountable for those DORA registers. And then finally, very important, remember DORA compliance is ultimately all about improving your organization's security posture.
Don't just focus on compliance, tick boxing, ensuring the controls and processes that you're implementing are effective, risk driven and repeatable. And really that's the only way you're going to be able to demonstrate compliance as well on an ongoing basis. Very important to ensure you've got that governance and regular reporting and metrics and to be able to show that you can do that as well. Okay, thank you. So moving on then, we've got a second or the third poll here, which as well, which tying in with that slide it just went through over there.
What do you see as your organization's biggest challenge in achieving DORA compliance? Is it understanding the requirements? Requirements? Is it budget restraints for necessary technologies? Is it integrating new solutions with existing systems, the lack of skill personnel or managing different aspects of operational resilience? Or indeed, is it none of the above or something else? Yeah, if you could fill those out, that'd be great and we can come back to those in a few moments. Okay, thank you. I'll hand you back over to Hannah now.
Hannah Rossiter:
Thank you very much. Thanks Tiernan. So we've actually got the results. We've come at you with two consecutive polls, so bear with us, but we've actually got the results of the second poll perhaps Alicia, can we show the slide with the second poll questions on it so when I read out the answers we can, there we go. Thank you. So we asked you if you've established whether your organization is a micro enterprise or a full scope firm or does it still need to be done?
So the answer to that question was 53% of you have already established which side you fall, 11% have not done that exercise and 17% are not started yet, but it seems to be something that you are looking at. And 16, sorry, 19% the answer D appear to be engaged in that exercise but are struggling with it. So around about half of you already clear cut where you are and half either not looked at it yet or are trying to get to grips with it and finding it tricky.
Okay, so we'll come back to the answers to poll three when we get them. But before we do that, just a brief couple of words from me on what's the process that we take our clients through when we're going through this implementation exercise? Well, I'm back to poll two again. I guess the first thing we need to do is make sure we know which set rules is going to be applicable to you as a firm. And again, as Tiernan mentioned earlier, if in any doubt make sure you document the rationale and the reasoning. If you are in that percentage of firms who find it difficult to understand the rules, then get down on paper what the arguments are that support your decision to go either left or right thereafter. What we then tend to do with our clients is first of all, perform a gap assessment, exercise, work out how much work is to be done, where are the areas that are going to require a lot of attention.
And then once we've done that, we can put a roadmap in place which make sure we're covering off each of those individual areas. The final part of that exercise, that implementation exercise is very much to do with assisting firms to close those gaps. We do that with a combination of staff from our cyber team and also from our financial services team who work hand in hand to deliver those solutions to clients.
I'm going to hand over now to Pooja because we've spoken about how you can crack the nuts so to speak in terms of reporting up to your board and to your senior management team to say the implementation exercise is done for DORA, then you need to make sure that you stay compliant. And that's a different challenge I think and push going to talk to some of the solutions that we can offer in terms of ongoing compliance.
But just before we do that, we've got the answers to poll three, which was the question that we asked you. And Alicia, if you could just go back to the question for poll three. So we asked you what the biggest challenge you had in achieving DORA compliance and we had a range of answers here. I'm just going to try and see if there's any one answer that that comes out as being there seems to be significant challenge.
A third of you have said that the challenge that you have is understanding the requirements. That's the response that has the largest number of highest percentage of response. And then the second challenge seems to be managing the different aspects of operational resilience. After that we have coming in sort of close third altogether, budget constraints, integrating new solutions and lack of skilled personnel.
So it does seem to be the major challenge that's been identified is the complexity of the framework and the detail in some of the rules. I think given what we've seen date, that's probably true and understandable, but can be overcome and with the right support, I think you'll get there. So over to you Pooja to talk us through how Resolver and Kroll can help with the ongoing monitoring of some of these requirements.
Pooja Azhalavan:
Wonderful, thank you so much Hannah. Thanks Tiernan. I think we've got a great download on what is DORA, what is the impact, the implications of it. We've also seen how a little bit and maybe just high level, how Kroll can support you to set your program up for success to achieve that compliance as well. For this last segment, we'll talk a little bit on the technology side of things and how you can maintain compliance on an ongoing basis with the help of either automated technology, continuous controls, monitoring and all those that good stuff.
Diving right in for starters, the very comprehensive nature of DORA that we've seen, all those broad range of obligations that are included within this framework really fits well into an integrated technology solution that covers everything from governance to risk management to your compliance needs, especially if that solution is purpose built for financial institutions because there's a lot of GRC technologies out there, different industries use it for different purposes, but one that is really purpose built for financial institutions in the sense that your workflows are set up to really handle that unique regulatory demand that this particular industry has and any kind of operational complexities that come within that financial sector.
And just to, and Hannah mentioned earlier, those five overarching pillars of the solution of the framework, those different obligations can be contained even supplementing equally to a technology solution that serves one of those. Each of those pillars, sorry. So right from incident reporting to ICT risk management and compliance controls monitoring solutions, you also further have a third-party risk software that can supplement that also supplements the due diligence process.
And then finally you have solutions with that additional digital operational resilience testing capabilities like business continuity management that all just sort of come together in a very comprehensive solution. Next slide please. So I just want to touch very quickly on the challenge we have today with doing things in a more manual fashion.
Tiernan, I know you mentioned these legacy technologies that we're using. It comes with a lot of risks and I'm sure a lot of you still use spreadsheets the traditional way and it can be extremely challenging, extremely complex, especially as your organization scales. So things from delayed incident detection and reporting for example, because you're relying on employees to manually detect and report any kind of security incident. And some of these incidents can actually go undetected for an extended period of time. You're running that significant risk.
It's also prone to errors because again, being more manual, it can lead to say, for example, inaccurate assessments of your third-party risks. Assuming you're using manual spreadsheets to track your vendor compliance today, and for a small human error, you could be using, for example, an outdated risk assessment for a critical vendor. What that will result in is that the company's underestimating the vendor's actual risk profile, which is an oversight that could lead to a breach in DORA compliance and will eventually impact that operational readiness.
There's also the risk of incomplete or inaccurate compliance records because you're manually documenting everything. There's also an extensive need for having more team members, more headcount that can also be challenging, especially if you're a smaller FI. And then again, the difficulty in scaling that program.
So even if you do have a compliance program set up as your company grows or moves into multiple jurisdictions, it's going to add to more complexity and that sort of will result in delaying your compliance documentation and assessing any kind of new and emerging risks that come with it. So very quickly, a quick visual on our JSC platform. Sorry, the next slide. Thank you.
What integrated technology really looks like at Resolver, as you can see, sitting atop one unified platform, you can connect everything from your enterprise risk teams to your vendor risk teams, to your cyber risk teams. I know you were mentioning treating your cyber risk as your operational risk as part of your operational risk and resilience program. A unified solution like this that brings these different teams together that's sharing data amongst these different teams. So you have a centralized library of your risks, your controls, all the obligations and requirements that is visible to all these different stakeholders.
You're essentially breaking down the silos between these different functions and you're really unifying that governance risk and compliance together. And of course you also have separate internal controls software here you have internal audit as well if that's part of the process. In cases where if you have a separate issues management team, there is an independent application to be able to track issues more centrally as well.
I just want to reiterate that all your info security functions, so not just enterprise risk, but your IT risk functions can track incidents and really streamline that compliance assessment and workflows alongside the larger risk program of the organization. Alright, so I'm going to kick this off with the first solution here, your compliance management application.
Trying to reimagine what that compliance process looks like when you move from a manual to a more automated system, really what Resolver does is it leverages regulatory technology solutions out there in markets. So what we do is we pull in relevant regulators that are applicable to your business and create a comprehensive library of frameworks within your system because you're not just dealing with DORA or NIST 2, you're also handling a plethora of regulations in this industry right from AML BSA. It's endless, right? So having all of that in one place really solidifies your visibility and comprehension of all the compliance needs that your team requires in the organization.
Now, these requirements get mapped to your controls, to your policies, to your risks, and it creates that centralized library. Your second line function can really assign to the first line, whether it's your control owner or your requirement owner to get automated alerts whenever there's a regulatory change that happens and immediately highlight the need to come in and either document further controls or take some kind of action against that.
And they're also open to come into the system that is your first line team to come into the system and complete those compliance risk assessments, identify and track any issues and actions that are taken against any kind of weaker controls that are in place. You also have the option of aggregated reporting, so dashboards and reporting that can show you trend analysis, what open issues are there, what are the compliance gaps across the organization that helps you really track those high risk areas of the business and really address any kind of compliance gaps in different business units, especially if your organization is more global and spread out, that really does help give you that visibility and quick action and decision-making for your board as well.
Next slide please. Thank you. So, if you're curious, how does that system sort of work? The regulatory automation technology is really AI powered. They use NLP, or natural language processing, to do horizon scanning, track any regulatory change immediately send alerts and notifications, and then it's also helping you map that to your controls and policies and risks that identified action plans you might have.
Also, one of the good benefits of this is that it does the applicability filtering for you. So what is applicable to your product line, to your service, your business function, and then it kind of actions that out to your compliance requirements owners. That's just a background on how that regtech solution works and how it sort of filters into more comprehensive compliance management application end-to-end from tracking regulatory change to completing an assessment to tracking issues, open actions, and then finally the reporting side of things.
All right, we'll move to the next slide on the incident management side. Really when you see incident management, it really starts with everything from incident detection to your reporting in order to really bring that enhanced efficiency, timely resolution of your ICT incidents. In this case, it's crucial to really streamline the reporting communication and response process overall. Automated workflows can really expedite that reporting process. Systems like this can have your intake of incidents is through a seamless sort of intake portal, very easy to use for your first sign.
Anyone in the organization, different business process owners can go in summit, an incident from where they're sitting in the business. And this can also be done through email ingestion. You also have the option of more confidential reporting like hotline reporting systems that they can keep that anonymity if required. But also, in organizations where you're more comfortable using your existing systems like say Slack or teams to drop notes on what you're seeing, incidents you're tracking, you can integrate that with a solution like this to pull in those incidents in real time and send that over for triage to your second line.
At the triage state, you're really sorting and assigning that ownership and then creating that consolidated repository of all the different incidences and tracking any kind of changes in, you're also doing a lot of investigation at that point. Different investigation details get captured. And then finally also towards more analysis, the more incident analysis and root cause identification side of things where you're facilitating post-incident interviews, analyzing why that happened and that really sets you up for being more predictive as you sort of go forward.
So you're more proactive, you're predictively assessing what could happen and you're creating that resiliency that this whole topic is really about. That is sort of an incident management end-to-end solution. Next slide please. On the cyber risk and compliance side of things. Having more risk visibility, a system to track your different ICT risks, linking that back to your IT assets, to your threats, to your vulnerabilities that you've identified.
Again, I know I'm repeating myself a little bit, but centralizing your risk and controls repositories. So all your ICT risks are linked to your, not just your assets threats controls, but also linked to your business objectives. It's a nice way to sort of do reporting at the end of the quarter to see how things are tracking, what are the high risk areas of the business? Are you meeting objectives?
You also can set your risk appetite risk threshold level and measure it against that and see what business units are breaching that risk appetite, that risk threshold, and what action needs to be taken there. It also sort of really nicely feeds into also your audit teams because simplifying the audit process as well, they're able to focus on high-risk areas and tackle any kind of gaps in those spaces. The other benefit of having a central risk and compliance solution is risk assessment and scoring.
You're able to connect and communicate effectively with first line function and be able to prioritize your risk based on impact likelihood and then do continuous controls monitoring. I know we're at top of time, I think we definitely went over a little bit, but I'll just quickly wrap this up. Next slide please. You also have third-party risk due-diligence solutions. A very simplified vendor onboarding where you're able to automate your IT vendor screening and onboarding with the quick reliable alerts and validations.
This is where the Kroll and Resolver synergy and symbiotic relations comes in is when we work with the experts from the crow side and pre-build questionnaires that are based on years of working with clients like yourself and also using best practices in market to build out those questionnaires for you, especially if you're starting out your program, having those in your system to kick things off is always very helpful and valuable.
So ready to use questionnaires, assessment templates. You also have the opportunity conduct periodic due diligence, so regularly assessing and managing those risks from those different IT vendors and third parties so that you can keep on top of your compliance needs. The best part of it is obviously the automated workflows bit, and I'm sure that's the exciting piece here is to just be able to automate those risk assessments.
Being able to do continuous monitoring and having systems in place to say, okay, if this is the impact or this is the risk scoring that we have on something, what is an immediate next action step that needs to pop up there? So there's a lot of that that can be set up in a system like this and structure overall centralized and manage also your contracts and keep that documentation management very robust. You also have a nice audit trail in case people, different users do different things in the system you're tracking.
You have a nice audit trail to kind of track that. So staying very compliant at all times. Next slide. Amazing. And then finally on the business continuity management really ties everything in the ability to do resilience planning and testing. Being able to develop rigorous testing, testing of business continuity, operational resilience plans, being more prepared for any kind of disruption that comes about.
Also a very detailed business impact assessment analysis, able to identify critical functions, any kind of dependencies that it has, and then accurately prioritize any those regulatory efforts towards those high risk areas. And then real-time monitoring and reporting to be able to continuously monitor and report on the status of your resilience as an organization. Continuity measures that are put in place and real-time and to also facilitate continuous improvement overall.
I just want to summarize this, this is a Resolver Core platform. As you can see, there's an integration tier where you're using your own BI tools, power BI or any of those things. You have the ability to pull that data in, make it one source of truth. So you're tracking your risk data, your compliance, the controls data, but you're also connecting it back to your dashboards reports that you might have in your own systems. Of course, Resolver has its own robust dashboards as well. We are a no-code solution, meaning we're highly configurable. FIs can range from a variety of maturity levels. We fully and truly understand that your programs could be fully functioning just starting.
Our no-code solutions help you to configure your workflows, your reporting, and the entire application in fact, to exactly your business needs. It's also a very simple drag and drop process. So for users to use, be in the system, your risk team, your compliance team to be able in the system and do that themselves. Fairly easy to use solution there. And then a lot of strong integrations overall. So use Workato, you have 300 plus integrations with your own tech stack that you have today, making that more of a seamless transition from more manual to a system like this.
And with that, I will wrap it up, with Resolver Core, we believe in this enterprise resilience value chain. I'll keep this one simple. So it entails firstly, giving you the right tools, the right services, the support to be able to capture those risks, those incidents and those threats in real-time. You have the right solutions in place. And then with the power of data and reporting, you're able to aggregate that across business units, entities measured against your appetites thresholds, take necessary action. And then with added data visibility, you can build out your resilience plans and prepare for any kind of future incidents that you might have.
And then lastly, the efficiency that you're gaining through all of this. The ability to measure your net loss or monetary impact across the business can really help you drive strong business decisions, become a partner of the business. I know in this space we can tend to always be looked as the bad cop, but this sets you up for success in a way that you're not only complying to these regulations, but you're also proactively supporting the business and its objectives going forward.
Hannah Rossiter:
Thank you. That's very, very comprehensive. And whilst you were speaking, we've had over 20 questions that have come up and so I'm not sure we'll be able to deal with every single one of them, but where we can, we'll deal with them today and then if we can't, then we'll try and follow up individually with those of you that have asked a question. I think we've got some flexibility on timing. What I would suggest, I think there are a couple there that maybe Tiernan can talk to, and there are a couple that I've seen that I can talk to. There seem to be quite a lot of questions around applicability and scope of the rules.
We've had one question around whether DORA impacts a UK firm with EU customers, and we've had another question around what about DORA versus the UK's, the FDA's rules around digital operational resilience, which came into effect in 2022. Maybe just to address those, and I think there's a couple of questions that Tiernan is going to try and answer. There isn't a direct correlation unfortunately between the UK FCAs rules and those in DORA.
There's an awful lot of overlap. But of course as we're starting to understand post-Brexit, it might feel the same. It might, in fact, the requirements may to a great extent be very similar in some cases identical. But unfortunately you're going to have to go through the exercise of mapping out to see where the differences might be. So that I think is unfortunately task that all firms are going to have to, all firms are going to have to deal with.
And the question around how does DORA impact a UK firm with EU customers? If you are a UK regulated entity providing and you are providing services to investment services to clients within the European Union, then you need to be looking very carefully at what it is you're doing. I'm assuming that they are historical clients because ever since the decision to leave the European Union, Brexit took place and the European Commission have been very clear about the fact that provision of investment services to clients within the EU, from outside of the EU, which the UK now is something that is prohibited.
So when I see UK firms with EU customers, there may well be historic relationships in that case if we're talking about, but just be careful, I guess, make sure that you're looking at what you're doing and that you're not actively marketing for business within the European Union from the UK.
How does DORA impact a UK firm that has EU customers? Well, since this is, we look at it from a very strict perspective or the way that the regulators will look at it. These are EU rules. If you are not subject to EU rules as a regulated entity in the UK, then it is not something that you need to concern yourself about. I would say when I see that question, my concern would be perhaps of a different nature, making sure that the provision of services is happening in a way that isn't outside of the current regulatory framework. Tiernan. And are there a couple of questions there that you feel comfortable.
Tiernan Connolly:
Responding to? Yes, I can. Lots of great questions. Very interesting to see. Yeah, people are grappling with lots of stuff I'm familiar with as well. So yeah, I'll pick out a couple and promise to respond to the rest of them as well afterwards. The first question I see here is around, I work in a global financial services company. Is there, or will there be a US equivalent of DORA? Very good question.
As you've seen over the last several years, regulators around the world, including the US as well as the UK, they're already viewing and increasingly pushing organizations to consider cyber and tech risk under their larger organizational on business resiliency programs, which DORA is doing. Of course, yeah. And there is various levels of DORA-esque requirements in place in the UK, US for example. And yeah, we certainly know that regulatory bodies around the world are keeping a very close eye on DORA, which is pretty ambitious in combining all of these elements together.
They're keeping close eye on the implementation of this organization's compliance, as well as how is the European supervisory bodies, how are they going to actually maintain the oversight and supervision of this, given there's so many organizations in scope for it as well. Yeah. And then they will, it could be similar to GDPR where we see it went live in Europe and then regulators all over the world subsequently adopted similar around the world.
If you are globalized or global organization, definitely we're thinking about how doors, controls and processes can be scaled out beyond Europe as well to your other jurisdictions. I'll pick out one more as well. So there's another question here around can you expand upon the respective roles and responsibilities of the key stakeholders to be involved in DORA implementation? CTO, COO, CSO, and COO are given in the question as examples.
So there's no specific requirements in door around specific titles such as these. Every organization will have different roles and titles on your size and operating model, et cetera. It does point out, as I said before, the board's ultimately accountable for managing the ICT risk and it can delegate responsibility further and pretty much does in most cases for ongoing risk management activities to the appropriate senior management.
That could be for a big, large amount of DORA would be spread across, for example, traditional CTO and CSO roles, given the tech and cyber focus. But you've also, it's very important to bring in business resiliency leads as well as your third party or outsourcing lead as well. Yeah, there's significant requirements as you've seen peppered throughout the DO requirements that cover it, go into these demands.
Hannah Rossiter:
Okay. Thank you. Thanks very much, Tiernan. I think we've now got to an hour and twenty minutes on the session that was supposed to take an hour. So I think those questions that we haven't been able to respond to, we will do our very best to come back to you individually and follow up and try and give you the answers that you're looking for, particularly given the responses that we got.
Some of the poll questions, the complexity of the rules, it's a big mountain to climb. If we can contribute to that and help you get to a better sense of what the requirements are, we're very happy to do so. I think we'll finish up there and thank you to my colleagues who've supported today in getting this session set up and ready. Alicia, and thanks Tiernan and Pooja for your contributions.
Tiernan Connolly:
Thank you.