Welcome to the KuppingerCole Analyst Chat. I'm your host. My name is Matthias Reinwarth, I'm the director of the Practice Identity and Access Management here at KuppingerCole Analysts. My guest today is Warwick Ashford. He is a Senior Analyst working from London together with KuppingerCole Analysts. Hi, Warwick.
Good afternoon, Matthias.
We want to talk about a topic and the name of the topic is DORA. And this sounds like a nice elderly lady or maybe a parrot, but both are false. So to start with, when we talk about DORA, what is it and why should we talk about it?
Well, it's just one of the newest pieces of legislation coming out of the European Union. It's part of a raft of legislation that they're trying to get Europe to be better suited to the kind of new digital world that we live in. And so there are lots and lots of other pieces of legislation like the Digital Act and the EU Chip Act, and there’s just kind of a whole long string of them, that are all kind of in the pipeline. But this one came into force in January this year, 2023. And although it's only coming into force in 2025, it's something that's going to take people a while to get ready for. And it's something that can, although it applies specifically to the financial sector, can be applied to any organization. It's just a good framework.
Okay. When we talk about the impact that DORA will have, you've mentioned financial industry. How big will be the impact? And if we compare it to GDPR, which was also a regulation from the EU, does it have the same level of impact?
I'm not sure that it will because, again, it's focused specifically on the financial sector. So it doesn't apply to all organizations. It's just those in the financial sector and the ICT providers. And, you know, so I don't think it's going to be a game changer like GDPR was. I don't think we're going to talk about it quite as much. But I mean, it brings everything into one place because some of the things that are covered by this new act were covered by the NIS directive and obviously its successor NIS2. But the other difference is that it's a regulation and it's not a directive. And, you know, the great thing about regulations is they apply automatically and uniformly to all European countries as soon as they come into force without the needing to be transposed into national law, which was, you know, the problem with NIS and now NIS2, is that it's going to be patchy. And that's what the European legislators were unhappy about, is that they didn't see protection for the financial services being uniform across the region. And so that's why I think they've made this now a regulation so that it's the same for everyone. And that's kind of part of the reason behind it is, is to kind of do away with uncertainty about, okay, which bit applies to me, which but doesn't apply to me, how am I going to do this? It's just all kind of under one thing, which is great. And yeah, and the other thing that's, that's different about it, it introduces this idea of operational resilience testing, which we can talk a bit about later, but it's something new where it's kind of forcing people to actually test their ability to do things under operating conditions.
Right. When we create, when somebody creates a new regulation, when there are new rules to be obeyed, there must be a reason for that. So what are the objectives that need to be achieved that were not covered with NIS, with NIS2, and which should be covered by international financial organizations?
I don't think it's a question of things that weren't covered, but it was - I felt that there were kind of gaps in it and it was inconsistently applied. So it was the consistency I think they were wanting to address most of all.
So what I've learned is that it's mainly about reducing financial disruption and increasing consumer protection. So what do organizations actually need to do to achieve that and what are maybe the challenges that they might encounter in implementing these regulations and following these regulations?
Well, the overall goal of the regulation is to strengthen the resilience and cybersecurity of EU financial entities, as we've said, and this includes banks, insurance companies, investment firms, data reporting providers and cloud service providers, and they want to streamline and improve previously existing rules. And they've added a few new requirements to improve the cybersecurity and to harmonize the cybersecurity regulations, as I was saying earlier. But the overall goal breaks down to three main objectives. So you've mentioned the first two, is reduce the administrative burden in terms of supervisory effectiveness and of the previous rules. And also they want to increase protection for consumers and investors. But I think the most important thing of the DORA is to reduce the risk of financial disruption due to ICT failures and cyber attacks because this was the concern, is that every organization now in the modern world depends on ICT services and technologies. And if they fail, then the organization fails. So there was this concern that if, if things in the financial sector fail, it's going to affect the entire EU region. And so that's why they've they've they've brought this legislation in. But you know, the point that I think I also made earlier was that this doesn't apply just to financial organizations. It applies to all organizations. We all got increasing attack services we're becoming all increasingly more reliant on ICT. And so that's why I think it's a great framework for all organizations to pay attention to. But the amount of work involved in achieving compliance or just to kind of get in line with it, could be considerable in light of the fact that the regulation requires organizations to focus on a digital resilience strategy. And this is going to be supported by a resilience framework that includes all the interconnected activities of the business. And they need to have a complete overview of the ICT ecosystem, the supporting critical business functions and an effective approach to business continuity, incident management and third party risk management. So this is to ensure that the necessary business support for all compliance related projects, it involves -, it’s quite a big undertaking and it needs to involve the board and other business leaders as early as possible in the planning process so that they're going to have time to do it by the enforcement date, which is in January 2025.
Right. And you've mentioned that implicitly several times, it's about reducing understanding or mitigating risk. So we're talking about ICT risk management. And this is something that I do as an advisor all the time. When somebody asks me, where should I start implementing measures?, I start, apply a risk based approach to top down. Start with the most pressing risks and then go down. But this requires risk management, understanding risk, measuring the risk. Are there any best practices that you could recommend that organizations should follow in applying ICT risk management?
Well, I think the important thing is that they've got to they have got to have an ICC risk management process. I think, you know, many organizations, they have risk management and it's just general. And but in recent years, we've been talking more about cyber risk management. And here we're talking about implementing an ICT risk management process. So this is now focusing on new technologies and new service providers and so this involves minimizing ICT risk through identifying and mitigating all the risks that you identify. And then you've got to adhere to a comprehensive risk management framework. So if there isn't one, you need to get one. And there are there is quite a bit of guidance in this legislation, to help with that. And then of course, there's the whole thing of testing, incident response and recovery capabilities, because again, the focus here is very strongly on recovery because it's about being able to kind of withstand any sort of disruption and recover from any sort of disruption. And this can involve regular security awareness training programs. And then organizations should then consider things like the deployment of risk identification and mitigation solutions. So if you think of a couple of the Leadership Compasses that I've been doing recently, like MDR and DLP and then also other things like EPR and XDR and ASM and SIEM and SOAR and incident response, all these things feed into this overall risk management capability, focusing on ICT.
Right. When I heard about DORA for the first time and I just quickly skimmed through the headlines, the first thing that really struck me was third party ICT risk management or third party risk management. And that is something that came across me here at KuppingerCole Analyst, some two years ago, and we called it cyber supply chain risk management, CSCRM. I think this has made its way into the regulation, making your suppliers do it at least as good as you should do it, right?
Yeah, I think this is an important thing because as you say, this is something we've been discussing about for a while and we've been advocating for a while. You're only as secure as your supply chain. And I think what we're seeing here is, they’re legislating for, you know, specifically to include third party risk as part of your overall comprehensive risk management framework. So, you know, let's just be aware that third party risk is an important risk to take care of. And then that includes adopting a third party risk management strategy and the important thing there, of course, is to review this regularly and make sure that it's up to date and that it can do the job. Another thing that the legislation also kind of introduces is this idea of keeping a record of all contractual agreements with ICT providers to make sure that you're not stuck. You know, if you assess your ICT provider as being not good enough in terms of your security requirements or whatever, you need to be able to exit that contract. So I think there's also a lot of emphasis now around, you know, you've got to be sure that you can evaluate your providers regularly and if they don't come up to scratch, you can leave. And that that's not going to disrupt the business because as I said earlier, it's all about making sure business continuity and there is no -, this is all part of this idea of resilience, that there's just no interruption to the business. And so, yeah, as I said, you've got to ensure that the contracts can be terminated if necessary and that there are exit strategies in place. And then, of course, you know, this is also something we've been around for a while, but only the big players seem to be doing it, is demanding risk assessments from all your third party suppliers and you say, okay, you're a supplier of mine and I rely on your service to deliver my service. And so I need to know what you're doing in terms of risk assessment on your side. And as you said earlier, you it does it match with what I need, does it match what I'm doing?
Right. There are a lot of great and interesting new concepts that made it through DORA into the organization. Another, and you've mentioned that already and I skipped across it, but I want to come back to that because I think this is really important: operational resilience testing. So not only writing down a piece of paper with some mitigating measures and some controls and hope it works, but it really requires the actual testing and proving that the resilience mechanisms actually do work. How can this testing really look like without interrupting the business but making sure that the results, the overall process is really showing that things will really work. How can you test something like that?
Well, obviously, it's going to be something on an ongoing basis. And I think that's also what this legislation requires of the companies that fall in scope. I think the basic testing is required at least once a year. So they put a test on all critical ICT systems and applications. But once again, it's something that requires the setting up of an operational resilience testing programs for all the tools and systems that you use. And I guess this can be part of the procurement process if, you know, if you're going to procure something, it's pointless buying or signing up to a new service until you've done the testing. And then, as you say, you know, it's more difficult to do it once it's up and running to not disturb the operations of the business. And what also this requires is to do the testing using an independent third party. So you can't just say, okay, you know, let's just test this - oh, yeah it's fine. It's got to be something that's through an independent third party. It's got to be certified and it's going to be accepted by the competent authorities. So that's also something worth noting. You also asked, what does it look like? So, I mean, this includes gap analysis, you know, we all haven’t got everything covered. It also includes physical security reviews. You have to look at things like physical access to ICT systems, is everyone who has access to these things, should they should they be getting access to it? How tightly is the access controlled? It's also about scanning software, source code reviews. Now is the source code, is everything in the source code okay? How much dependency is there on open source code? How much control do we have? It's also about compatibility testing. You know, will this work with the systems that I have? Will it cause any disruption? Is there any potential? If there is, you know, you've got put many mitigating factors in mitigation processes in place and then performance testing and then, of course, good old penetration testing, you know, how easy is this for the bad guys to get in? So those are all the components of this testing, and it's quite I think it's that's going to be the most significant change for a lot of organizations because I think, you know, things like source code reviews, typically that's not widely done. And so I think this is going to be something that organizations are going to struggle with quite a bit. And that's it's one of the hallmarks of this piece of legislation.
Right. I think there is a lot of work to do for organizations who really want to follow DORA and when they are using many online services or other ICT services provided by third parties. And of course, behind the third party is a third party, so that this is a daisy chain of services that interact with each other. So this only works if the chain is complete. There are lots of interesting concepts. I've mentioned that, and I want to highlight one final one, because this is something that many organizations typically are hesitant to implement. But DORA encourages financial institutions to share cyberthreat information within a trusted community and to use this information to get better with their own cybersecurity posture and to support the community with this information. So how can an organization actually do that? Sharing this information while protecting sensitive information of their own customers, of their own business, intellectual property, or whatever? How can that work out?
The legislation provides a little bit of guidance on this, but just to talk generally for a little bit. Again, this is something, this is best practice that we at KuppingerCole have been talking about for a couple of years and certainly is one of the prime things that comes up at EIC every year. That's our big event that we have. And we when we get together the, specifically the identity community where, you know, it's all about sharing information. And so this is great again to see legislation encouraging, as you say, communities to share this. Now once again, because this is the financial community within this context, you know, it's about encouraging financial entities to share with other financial entities, but it can be done on a broader community. So once again, the emphasis on the need for starting to plan now, 2025 may sound like a long time in the distance, but you know, you need to start putting processes in place now for sharing cyberthreat information with other financial entities, with other with other organizations if you're not in the scope of this thing. But of course, now you have to ensure that the information sharing arrangements protect potentially sensitive commercial and personal information. And this is what the actual legislations warns about and says, You know, you have to, you know, we encourage you to share, sharing is good, but you have to make sure that you've put arrangements in place to make sure that potentially sensitive information is protected. So it's about defining the conditions for participation of entities and the involvement of third party service providers and sort of operational procedures. You have to kind of, all these have to be defined. So again, don't waste time because this all has to be done. But the great news is that the Europe Board of Directors of the banking industries, cyber risk information sharing network FS-ISAC, has been set up and it will provide members with a single point of contact for coordinating cyber related information between financial entities. But again, in a wider application, there are ISAC groups in all -, in several different sectors. So if you are interested in sharing information with other organizations securely in a way that you know is going to be of mutual benefit, then you know, join one of your -, or join your industry ISAC and they will help coordinate that. So I think that's a great thing that now there's a European board of directors. So there is no issue with data going outside of Europe. It's all kind of contained within that and that the FS-ISAC has facilitated this.
Interesting to learn that. That's really a good point. So there has already work been started to share this information. You have worked on DORA from an analyst perspective, and you've created a document, an advisory note that covers DORA. And I think this is really an interesting work to read, and I highly recommend that. Once again, finance industry, insurances, banks are on the forefront of maintaining cybersecurity and governance, but you've mentioned that at the very beginning, what's in there should be relevant for almost any industry?
Yes, absolutely. I think that it's a great framework and it sort of highlights five key areas that organizations need to look at. And yeah, so going to have a look at my advisory notes and it'll help pull out the main sections of the legislation because I did go through the legislation. There is a lot of stuff there. There are hundreds of pages literally, but I've tried to distill the things that are most important and that'll be of most interest to organizations.
Right. And you've mentioned EIC as an event where people come together and talk about sharing information regarding identity and access management and the threats towards these systems up and out about interoperability. Of course, I cannot close down this episode without mentioning the cyberevolution, an event that will take in mid of November, which is more focusing on cybersecurity, which of course also will touch upon DORA when it comes to implementing cyber security, compliance mechanisms and modern ways of how to deal with that. So also this is highly recommended. Any final thoughts from your side before we close down?
No, I'm just looking forward to cyberevolution because as you say, there are a couple of sections on DORA, and a couple of presentations are there on DORA. But again, you can't we all going to be working to be building a cybersecurity community as we've built up an identity community and I encourage everybody to come along and take part and join up and learn what they can learn.
Absolutely. And this is what these events are for, also for just socializing, for getting to know people, finding peers, talking to them, learning from them, sharing information, as we just discussed. And if we have made... or if we have completed the task to bring the abbreviation DORA to the minds of our audience so that it's Digital Operational Resilience Act from the EU, then we have achieved something. Thank you very much, Warwick, for being my guest today and for going through all these pages and distilling out a 15 page Advisory Note that is really helpful. Thank you.
Thanks.
