Preparing for DORA, NIS2, and the new European push for cybersecurity

Media Thumbnail
  • 0.5
  • 1
  • 1.25
  • 1.5
  • 1.75
  • 2
This is a podcast episode titled, Preparing for DORA, NIS2, and the new European push for cybersecurity. The summary for this episode is: <p>With information and cybersecurity incidents growing in frequency and severity, regulators in the European Union are hard at work devising new rules designed to incentivize organizations to harden their cyber defenses.</p><p>On this episode of GRC &amp; Me, Megan Brown sits down with Wizz Air’s Andras Szabolcs, Cyber Risk Expert, and Peter Szigetvari, Operational Risk Expert, to break down the similarities and differences between two of these new European Union regulations — the Digital Operational Resilience Act, or DORA, and Network and Information Security Directive 2, or NIS2 — how they could affect nearly every company despite their official scope, and how organizations can prepare to comply with them using modern GRC technology.</p>

Megan Phee: Hi. This is Megan Phee with GRC& Me. Today I have the pleasure of sitting down with Andreas and Peter from Wizz Air. We talk about DORA, what it is and how it compares to NIS2. We talk about the concept of organizational responsibility, and when and why organizations should start now. And here's my conversation with Peter and Andreas. Hi. Welcome to the podcast, Andreas and Peter.

Andreas: Hi Megan.

Peter: Hi Megan.

Andreas: Thanks for having us.

Megan Phee: Of course. This is a really highly anticipated episode. I know what we're about to talk about today is something that I have been hearing about in all of the circles in which I've been at conferences, in customer meetings, even internally. Everyone wants to talk about DORA. What is it? How does it impact organizations inside and outside of the EU? What should we be doing as businesses to be DORA ready? We would love to hear from both of you because I don't want to steal the thunder, but you both are very well familiar with this topic, experts in this space. I would love for you both just spend a moment to share with our listeners a little bit about your background and what led you to lean in and really be such an influential aspect to the DORA, not only regulations but also this DORA conversation today. Andreas, I'll start with you. If you'll share a little bit about your background and your involvement in GRC, and then we'll pass it to you, Peter.

Andreas: Yeah. I started my GRC career, so to speak, at four big four companies here in Hungary doing mostly IT audits. I was basically involved in the compliance part of GRC at the beginning. Then, I moved to the US and I was working for Coca- Cola for their internal IT audit function where I was leading IT audits all around the globe on four continents. And then, I moved back to Hungary and I've been a freelancer since then. Now working for Wizz Air. It's a low- cost aviation company based in Budapest, Hungary. This is how DORA and NIS2 came into the picture as NIS2 that is basically the twin brother of DORA is inaudible for us as being an aviation company. We are critical infrastructure from this legislation perspective, and we need to get ready and we are using LogicGate to get ready for this.

Megan Phee: That's fantastic. I think a lot of folks will have a lot to learn from you today about how you were thinking about that and even how you went to market to research platforms and tools and resources for it. We'll come back to you, Andreas, on that. Peter, tell us about your background and then your connection to DORA.

Peter: I will start from the fireplace. Basically, I started my career approximately 20 years ago as IT operations manager. Worked for some international companies such as Cemex who is a concrete and aggregate giant and call center companies. At Cemex, I had a milestone in my career because when I was acting as an IT operations manager, I challenged the actual BC manager, and the director said, " Don't challenge, don't criticize, do it." I became a BC manager. In that time, that company hired an external consultancy company which is quite knowledgeable in this area and they recognize that I'm not good for IT manager, I am better for BC manager. I joined inaudible. It's a German company. Basically, I started my globetrotter freelancer life working for Lufthansa Systems, Deutsche Bank, inaudible. Once I gave up the freelancer life, I went to the European Commission for three years as security, as business continuity manager. After that period, I visited Germany for three years and I working for both Siemens Home Appliance group as a supply chain risk manager. After that, here I am. What is my relation with GRC? I had a feeling somewhere 10 years back that BCM is not enough for me. I want to see another management system such as information security and third party risk management or vendor management. I found a very good approach how to integrate those siloed management system. The answer was GRC. After that, I visited the OCEG who is the inventor of the GRC Red Burgundy book, and from that point I consider myself as a GRC guy. I would say I have seven years experience in GRC, and here at Wizz Air I try to spread the message and let's say my point of view about these complex topics. DORA, I think it's another point what I want to touch. Reading the preliminary specification of NIS2 and DORA looks very, very complex, but I think the best practice would be disassemble this complex stuff into the elementary building blocks such as BCM, third party risk management, information security management, because in my eyes DORA is nothing new. DORA is an integrated requirement of those three pillars, and basically the companies who are falling into the scope of DORA, financial institutions, they should have BCM in place for sure. They should have IT service continuity in place, information security and third party, but probably it's not integrated. Here came into the playground such a tool which is flexible enough to integrate the existing building blocks and practice governance over those elements.

Megan Phee: Fantastic. Okay. Well, we're going to touch a little bit more on the impact too that it'll provide businesses, but for those that are listening that are less familiar with DORA, the Digital Operational Resilience Act, it is as the gentleman have shared, it's a regulatory framework in the EU and it's going to combine a number of existing regulations with some new ones. My question to you both is, how do you think this will impact businesses both inside the EU, but then also globally outside the EU? Because similar to the GDPR, it is something that multinational organizations should be mindful of, should be ready for. How do you see this impacting not just organizations that operate in the EU but globally?

Peter: Basically, the tricky part of DORA, the original scope is a financial institution, but they are third party vendors and suppliers who are contributing into the critical financial services. They also have to be compliant. At the end of the day, the whole supply chain of the financial institution shall be covered, and I think would be very difficult to find a company who is not part of this game. The scope is bigger than it seems at the first look.

Megan Phee: Andreas, anything to add to that?

Andreas: Yeah. I would just refer to the NIS2 requirement that is very similar to DORA with different organizational scope because instead of finance institutions only in its scope, it covers all critical infrastructure companies, and similarly to DORA, it also has a cascading effect on the supply chain of these companies as supply chain security is also included in this requirement. The companies that fall into the scope of this regulatory requirement would need to make sure that their suppliers are also compliant with the requirements. If the supplier is outside the EU, the supplier still would need to comply with the requirements regardless of the territorial scope of this regulation in the EU.

Megan Phee: I've heard you both speak about that, and Peter, I know we talked about that, the influence, the origin of DORA and that connection to NIS, but we talked a little bit about comparatives. What are some differences between the two bills? I think the NIS2 for critical infrastructure is also in negotiations right now. What do you see as the difference between the two?

Peter: Basically, there are not a lot of difference. I would say 95% of the required controls are identical, but the reporting requirement is more stringent on the financial part, and the financial institution should or shall have more critical applications in terms of criticality level. Basically, NIS2 can cover the NIS2 scope and 95% of the financial institutions.

Andreas: What I would add on the top of this is that the tricky part is that these two regulations, DORA and NIS2 are EU level regulations. What these regulations say that each member state should formulate their local legal requirement based on the EU level requirement, and these member state level requirements are not there yet fully. For example, in Hungary on the 31st of May came out the NIS2 localized version in our local Hungarian legislation, but we don't have that for DORA yet. To see exactly the differences between the two, we would need to see the local member state level regulations. At this point, we just have the high level picture that the EU level regulations show us.

Megan Phee: Interesting. You both mentioned in your introductions your background and your evolution into GRC, the GRC market. In the GRC market, there is technology, there are platforms out there that help organizations provide process improvement to their programs. Why do you guys both think that GRC platforms or programs are vital for organizations who are facing DORA, NIS2, GDPR? What is it about having true digital inaudible or digital improvement, or what is it about improving or having visibility into your GRC program that might help organizations who are facing these regulatory requirements?

Peter: I think we can list some ugly use cases that can justify the need of some platform which is operating in an integral way. I saw several example when a technical expert reported something which was classified as red, and during the road up to the board level, the color just changed through yellow to green. The integrity somehow compromised during the reporting part. I think it's one real life example. Another example is if you are talking about the siloed management systems such as business continuity, information security, and I can list a lot of management systems. At some places, those management systems has an own separated supporting let's say tool which can be from Microsoft Excel to specific function, specific applications, but they are not integrated. Basically, each management systems somehow should be connected to the organization resources. What is that? It's a well- educated CMDB. Why should we duplicate those sources? We shouldn't. We should set up something centralized stuff which is running on an inaudible data source, and basically that's GRC. When we are talking about GRC, we can think that it's a complex stuff, but I think it's better if we simplify what is GRC. GRC is a risk- based decision- making that taking into account the risk and acting according to the risk decision. The GRC platform is supported with very customizable workflow. For me, that is GRC, whatever you can support with a unified platform and you can call it GRC.

Megan Phee: You mentioned something there. Andreas, do you want to share anything on that? You've looked at the market in this space and seen a lot of solutions.

Andreas: Yeah. Basically, just on top what Peter has mentioned, I would point out that in NIS2, it basically says that if a company is providing services in more than one member state of the EU, then this company would need to comply with all those local regulations related to NIS2 that are established in those member states. If I think about Wizz Air, the company that I work for now, Wizz Air provide services throughout Europe. We would need to probably comply with all those local regulations, maybe 17 different regulations, similar regulations, but probably not 100% exact same regulations. I think this is also a great benefit of using a tool like LogicGate. When we think about control compliance, then with LogicGate we can map out controls that are the same, and then we can establish this holy grail of control testing that we test once, and we comply with many control requirements. With this control mapping that can be achieved using LogicGate, we can reduce the work that we would need to do to ensure compliance with all those local regulations. I think it's a big benefit, and it would be really difficult to achieve the compliance without a GRC too for a company like Wizz Air that operates or provides services in many member states of the EU.

Megan Phee: Well, you both spoke about it. It's the efficiency gains, it's avoiding redundant work, it's also seeing the gaps of compliance, where are you across the different frameworks or your own bespoke regulations that you have. But also, Peter, you talked about it too, is bringing teams together, reducing the silos. I was just at a conference this week and everyone is echoing that. We still feel siloed. People feel siloed. They're not sharing information or data in a meaningful way to help make decisions in the business. I think you both spoke to some key value outcomes that customers and the market is looking for when you think about DORA readiness, but more importantly just GRC, the health of a GRC program and having a good visibility into the overall risk and compliance posture of the business. Andreas, staying with you for just a moment, when it does come to evaluating the market, you've identified a need or you're faced with an impending new legislation or requirement and you know you need to maybe change the way that you're running your program and processes today, you know you want to insert some technology to drive the efficiency and visibility. How do you go about evaluating tools, especially tools that are going to help you monitor and address compliance? It's a long process, I'm sure, to go about thinking about where to start. It probably requires support and validation from both technical business stakeholders and non- technical business stakeholders. How did Wizz Air go about this process? How did you navigate this evaluation?

Peter: Basically, before we jump into the details, I think it's very important to mention that of course we knew what we wanted, but we also knew what we didn't want. Basically, the driver of the listing, what we do not want, based on my former experience with other platforms, I've worked for years with other big GRC platform, and it was quite rigid. We didn't want to get rigid and non flexible enough platform. I think it was one driver. Of course, we wanted to have a modern platform which is SaaS of course, and we were looking for a flexibility and ability to customize the platform because we really want to be independent from the software developer. We don't want to wait for a response. We want to be able to own the system.

Andreas: I would just add another aspect to this, and that is price. Wizz Air is a ultra low- cost air carrier company and very cost sensitive, or better to say not cost sensitive but sensitive to the cost benefit ratio. We spent a lot of time on analyzing this. We did POCs with several products, and of course we got the pricing too. When we compared what the tool could provide for the value, then I think LogicGate came in first. That was also a decisive factor for us, a very good value to price ratio.

Peter: We wanted to have something future- proof, and here the risk quantification came into the ground. Currently, the old fashion risk management is the fashion, so to say. We wanted to have something that can work five years later when the maturity of the company reached that level when we can introduce risk quantification, and we also want to use risk quantification for educating the management. Currently, it's a nice to have, but we use it as a tool to change their imagination about the risk, what they should manage. In LogicGate, it's a built- in and excellent quality risk quantification module.

Megan Phee: I know you've shared that with our team before, Peter, about how... Cyber risk is only getting more complex. We're seeing it's more requirements of course, but just the importance of managing risk posture is just going to demand of us all working in GRC a higher level of understanding from all stakeholders and a higher level of support from all stakeholders. When it comes to the work that you're doing and where you see the maturity of the program going, the importance of having a common language, we talk about having a financial common language of the decisions that are being happen or the impact of risks within the business, that will just support and increase the speed of decision- making and competitive value positioning and all of that. I'm glad to see that you are thinking about that future proofing aspect. What advice do you have for folks who say, " Yeah. We really haven't thought about risk quantification yet or we're not ready for it?" Would you share any advice about what should they be thinking about or how maybe should they approach that within their own organization?

Andreas: I would have a starting thought for this, and then Peter I'm sure we'll have more. I think one of the ground rules here that currently Wizz Air and I think most companies as well are doing, reactive risk management in a sense that we are managing risks that we see appear, but we are not managing risk in a way that top management would establish the risk appetite of the company, and then we as risk managers would need to make sure that we are below that risk appetite or we are hitting the risk appetite and not higher than that. The only way to achieve that is with risk quantification because management wouldn't say that okay, my risk appetite is that we shouldn't have risk higher than medium because that just doesn't work. They would probably set a threshold amount, and then we would need to make sure that cyber risk is less than the amount that they established. The only way to achieve that is with risk quantification. I think this would be one important point for the future. I think this is where risk management is going, and I really think that risk quant is the only way to achieve this.

Megan Phee: Peter, what do you think on that?

Peter: I'm not an enemy of coloring red, yellow, green, but some months ago I composed a presentation which we are targeting this approach, and I raised simple question. What is the sum of two and three? I think the answer is simple, five, but try to add yellow and green. I think I said everything what I wanted.

Megan Phee: That's exactly it. Even earlier in the episode, you talked about how you observed in another organization where it was started as red, and then over time through the communication up to the board it changed, the color changed. Financial impact, you can measure it, you can monitor it and you can speak about it in common language. It's not red, it's not magenta, it's not orange. It's truly an actual financial impact to the business. You mentioned DORA is a combination of the aspects that strong cyber and risk programs should be doing today, business continuity, risk management, controls management. Let's say an organization's just a little less mature on their journey towards understanding DORA. Where should people go? What advice do you have about where folks can just follow along as this requirement evolved over time? As we saw with GDPR, it took different flavors in different nations. As you saw in the US we started to create different privacy perspectives for different states. Where do you recommend or where will you guys go to continue to learn about the evolution of DORA or iterations of DORA?

Peter: Basically, we learn from outside as well because the regulators listing the requirements for sure. In the same time, we have to educate the organization where we are working. I think we have to identify the root cause of the low level of maturity. I think the main root cause of the low level of maturity that a big company thinks that security somewhere in the basement and in the specific corner can take care, but it's not true because all of the aspect of DORA or other GRC elements are organizational responsibility, and you cannot manage organization- wide programs without centralized data and major workflow system. I think the big jump from the old- fashioned and old tooled management systems is something that relying on reliable database and very well- designed and as simple as possible workflows. In the same time, the whole organization will be involved and it will not be as painful as it was when some people in the basement in the specific corner try to do something.

Megan Phee: Andreas, how do you feel about that? Do you feel that this DORA readiness or this initiative does require organizational responsibility of cross functions across silos? Do you feel like it's going to be a collaborative effort?

Andreas: Yes, definitely. Starting from the point that management is made responsible for resiliency in NIS2, definitely. Similarly to the inaudible in the UK, now it's really management is made responsible for ensuring compliance with the requirements. I think this also has a cascading effect because if a CFO or I don't know, CEO is made responsible, he will definitely delegate this responsibility down the line, and then it would probably then hit operational management level as well. I'm quite sure about that because resilience is really everybody's job. It's not IT security, not cyber security, it's not IT operations, it's all around. It's definitely something that the whole organization will be affected by.

Megan Phee: Well, you just spoke about it. I think that is a hot topic and a desired state for so many organizations around the world, which is a state of operational resilience and a place of a proactive approach to security and risk and compliance. I love, Peter, what you had mentioned about you can't do this without centralized data and centralized workflow, getting people together, sharing information, and ideally one central resource. All right. For the topic for today, I just wanted to open it up to both of you, if there's any other aspects of DORA that you think would be interesting or important to leave our listeners with today as we close out our conversation, any final closing thoughts.

Peter: Yeah. If I can say something, it would be that I wouldn't afraid of the DORA requirements because as I stated, high percentage of the requirements shall be fulfilled at the moment. I think the key next step is the integration of the siloed elements. Basically, that's the main comment what I would add. I think if some organization choose GRC platform to support DORA, they will gain more benefit than they expect because of course, in a certain period of time they will support the management systems work operations, but the whole organization will reduce their frustration because the whole story became objective. Just imagine in the past or probably at some companies at the present, they can negotiate on the corridor, but with GRC platform which is operating on facts and driven by workflows, you cannot be angry on other people. You can see your task you have to fulfill and move forward. But in the past, yeah, hi, how are you? I have something in the risk register. What do you think? I think it's high. No. It's medium. At the end, it'll remain medium and nobody will touch it.

Andreas: Yeah. From my end, I'm really looking forward to see the local regulations coming out for the member states, both for DORA and NIS2 because I think that will be the point when you'll really know what is required and what we would need to comply with. Getting ready for that now, I think it's a good time to start because we still have more than a year or almost two years to get ready. If you don't start working on it now, we'll be probably in a bad position by the time the regulations come out because as Peter mentioned, most organizations falling under Dora or NIS2 are already required by some local legislations to comply with similar requirements. This is an integrated approach and putting the puzzle together takes time. I think it's a good time to start now, even though the local regulations are not out yet, but the skeleton is out. Based on that, I think that the work can be started and this is what I would propose to anyone who is affected by these two regulations.

Megan Phee: I think that's great advice. You'd rather be proactive and ready, have an understanding of where you are, a baseline understanding versus having to catch up and balancing the other priorities that the business has for you. Wonderful. Peter, Andreas, thank you for sharing your insights and your perspective on DORA as we continue to hear, learn more about DORA and to your point, the impact and the specific aspects to the member states. It'll be interesting to follow along. Thank you both for your time today, and we enjoyed our discussion.

Andreas: Thank you, Megan.

Megan Phee: To continue the conversation, follow LogicGate on LinkedIn and visit logicgate. com to check out our event. Join us live throughout Europe as we discuss how to prepare for DORA, and for those local to the UK, join us every third Thursday for GRC& Me here in London. Lastly, for our customers, you can visit Risk Cloud Exchange or to download our applications today to support your DORA readiness effort. Until the next time. This is Megan Phee with GRC& Me.


With information and cybersecurity incidents growing in frequency and severity, regulators in the European Union are hard at work devising new rules designed to incentivize organizations to harden their cyber defenses.

On this episode of GRC & Me, Megan Brown sits down with Wizz Air’s Andras Szabolcs, Cyber Risk Expert, and Peter Szigetvari, Operational Risk Expert, to break down the similarities and differences between two of these new European Union regulations — the Digital Operational Resilience Act, or DORA, and Network and Information Security Directive 2, or NIS2 — how they could affect nearly every company despite their official scope, and how organizations can prepare to comply with them using modern GRC technology.