The million-dollar question: Europe’s FMIs get ready for DORA

Panos Kiziris

Thank you, Shreeji, for taking the time to answer my questions. The Digital Operational Resilience Act, DORA, was published in late December 2022, but it has an implementation deadline of mid-January 2025.

So that's less than 12 months as of today, which is coming fast, and it is a question of how prepared the different entities are. And when I say different entities, the ones that are affected by it are all the financial entities that operate within Europe. That captures FMIs as well, financial market infrastructures, whether CSDs, central security depositories, or central counterparties, CCPs.

From that perspective, from an FMI perspective, I’ve been talking over the last year with some CSDs in Europe, and it's been a mixed bag if I’m being honest. Most FMIs have already dealt with similar issues, or they have put in place a robust risk framework in general out of other regulations in Europe, whether it's EMEA or CSDR.

But DORA kind of changes things now, I guess, makes them more granular or more specific to certain risks. So my first question to you, Shreeji, would be ‘all right, the CSDs have a certain risk framework now in place because of CSDR, but how does that change because of DORA?’ Are there now more specific requirements that are coming in?

Shreeji Doshi

You’re spot on when you say that to a certain extent FMIs would not have experienced that great of an impact from DORA because there were already risk management principles that had been forced upon them by CSDR.

Additionally, there were also 2018 guidelines based on IOSCO guidelines, which is cyber resilience was an expectation of FMIs, that also had regulators pushing CSDs in individual markets to undertake some sort of cyber resilience already.

In principle there would be limited impact because of these two aspects. However, from what I have read about DORA, there are certain requirements that are fairly prescriptive, they're not related to generalised statements on the requirement level specifically.

And a couple of examples that come to mind are, firstly, that risk management should sit under either a control function or an audit function. Or you have certain clauses that need to go in ICT third-party contracts. It’s fairly prescriptive. How do you classify a significant incident?

Now, all of these would somewhat be implemented by the FMIs, but they might have to relook at the regulations to see that they’re covering all their bases on these prescriptive requirements coming out of DORA. For CSDs there are two very explicit requirements.

One of them is that they would report back their business continuity test results, that is, information and communication technology (ICT) business continuity test results, to the competent authority.

The second one is they will ensure that there is a secondary processing site available at a geographical distance to ensure the availability of two systems with capabilities, resources, functions and staffing arrangements already in place. So these are two specific requirements of CSDs. There is a requirement to have a recovery plan such that it enables them to recover all transactions at the disruption time so they can operate with certainty and complete settlement on the scheduled date.

Panos Kiziris

As I said, I've talked to some CSDs in Europe, they have done some initial gap assessment. They haven't disclosed many details to me, but my understanding is that they feel comfortable with their current risk framework and, obviously they've identified certain things that need to be adapted, but I think they echo what you just said – that maybe on that risk framework and governance aspect, they might not be as impacted.

However, I'm wondering, is there an explicit provision in DORA about risk appetite when it comes to ICT risks? Because DORA is all about ICT. It is all about information and communication technology. So does it tell financial entities and FMIs, ‘you have to have this level of risk appetite, or you have to define it in a certain way, and it has to be approved by certain people’?

Shreeji Doshi

It does not give an exact prescription as to how you go about defining risk appetite. What it basically is asking organisations to do is that, as part of their digital operational resilience strategy, there has to be an element of establishing a risk tolerance level for ICT risk, and this has to be aligned to that ERM framework, whereas ‘appetite’ is more broadly defined.

If you look at that specific requirement it’s breaking it down into two specific elements, right? One is that they have to now, from an ICT risk point of view, define response, but they also have to ensure that they are able to demonstrate that it's linked to the overall risk appetite of the organisation. Organisations adopt various ways to provide this correlation, but this would be something that someone would have to look into and see if they’re crossing all the t’s on this.

Additionally, this has to be approved by a management body. That's what it is saying. I've seen ICT risk responsibilities sit with a CISO from an approval point of view, or an organisation might have an information security risk body that looks into it – it's not like it rests with a dedicated management body.

So if ICT risk management is not already going to that level, it has to go to that level now.

Panos Kiziris

Is there, do you think, a case where a CSD might not have the appropriate person to approve that? So, they might not have a CISO, I'm trying to think of cases like that, but I think all of them must have someone in that position by now.

I'm just wondering whether you are aware of any exceptions.

Shreeji Doshi

The CISO would be there, I don't imagine an FMI wouldn’t have one, because they were already pushed by a lot of regulations to put that role in place. But where does the CISO report into and what are the roles and responsibilities of the CISO?

If the CISO is responsible for managing ICT risk, and it should be in their remit, the CISO has to sit under a control function, or a third-line of defence like an audit function. That reporting line has to be absolutely clear. The CISO cannot have reporting within the first line, meaning the CISO cannot report to a CIO or a CTO, it has to be within a CRO function or an internal audit function.

Panos Kiziris

You mentioned incident response. As with everything in Europe, there's always a varied approach and some CSDs might be doing it differently than others – more manually or more automatically. Is there a specific requirement within DORA about incident response?

Shreeji Doshi

A couple of things. It's bringing harmonisation on how you classify ‘significant incident’. It kind of lays down a taxonomy to do that. So a CSD in, let's say Belgium, versus a CSD in Bulgaria, classifying an incident as ‘significant’ should mean the same thing for both of them now because of DORA.

And I think if DORA manages that it will be its great achievement, as the competent authorities or the supervisory authorities would look at incidents reported to them from across Europe through the same lens.

Additionally, they are providing a timeline on reporting significant incidents, which is fairly prescriptive. You need to give me an initial report within the next timeframe. You need to ensure that in 72 hours you are able to report something, so on and so forth, and also providing as much detail as possible within this report, you need to consider all of these aspects.

That is separate from your basic ‘information collection’. Eventually, that's going to be beneficial for every EU Member State.

Panos Kiziris

Since we're talking about these more technical aspects, does DORA have specific requirements about technical testing that the FMIs, and the other financial entities, should be undertaking, for example, penetration testing?

I know most CSDs do some sort of penetration testing, but it's not consistently performed and some might be doing it only before they apply, and it changes all this they do it before and after their responses and the ways that they do it are varied. Is there a more consistent way described in DORA?

Shreeji Doshi

It is to an extent, and if a CSD does not do periodic penetration testing (pen testing) at a fixed frequency, I think it might be a challenge for them. Because there are various ways of performing digital operational resilience testing. Pen testing is one of them. There are multiple other ways, it's not just limited to pen tests. DORA’s requesting organisations to identify vulnerabilities or issues through numerous tests.

If a CSD has not matured enough to do this on a broad basis, on a fixed period basis, it might have a compliance challenge. Additionally, there is another requirement around threat-led penetration testing – meaning that they have to contextualise specific attack vectors impacting that specific region or that specific CSD and perform a test to see how their protective and defensive mechanisms react to such a threat.

I would assume that some mature CSDs are already doing this, but if there are some markets where the CSD has not undertaken this exercise, they would have to put in place something soon.

Panos Kiziris

Very interesting points, Shreeji, because I have to admit I wasn't aware of the extent of the testing that is prescribed in DORA.

This sounds very sophisticated for some of the CSDs that I know of, and I bet you they're not familiar with all these different types of testing. How big of a challenge do you think that's going to be for them? How can they adapt? How can they move forward with that?

Shreeji Doshi

There are a couple of ways and DORA provides guidance.

The regulators have said, OK, you could have an internal assessment team or a testing team, and there are guidelines as to what are the qualifications of such a testing team should be. Additionally, they can go for an external provider, which I believe are fairly common commodity now. There are many providers who offer these kind of services.

The CSD should be able to select from a variety of such providers. So at an execution level, it's not that challenging to address this gap, but it would require some investment, some budgetary allocations to do this on an ongoing basis.

Panos Kiziris

As with other regulations in Europe, this starts to sound like a costly exercise. And I'm thinking about CSDs where the whole IT department might be just one or two persons – are we looking at situations where the CSDs would have to invest more in people and technology because of DORA?

Shreeji Doshi

There will definitely be a need to invest in technology. If the size of your IT team or the information security team is fairly small, then you could leverage technology to augment your manpower to a certain extent, like running a risk management process or running third-party risk assessments.

And you would definitely need to look at the sourcing model. I think a very important point that DORA has brought in is that management body, that we spoke about earlier, is also tasked with ensuring that it has sufficient resources allocated for ensuring that the ICT risk management framework is adequately implemented. So they should be identifying gaps at the resourcing level, you know, at the management body level and taking that input in.

Panos Kiziris

Very interesting. Since we are talking about staff and budgeting, I know that some CSDs in Europe currently don't spend as much on training staff and especially when it comes to IT. They might train just risk staff or a very particular group of employees.

Is that changing under DORA? Are there specific requirements about training? And what about senior management? Is that captured by the training requirements?

Shreeji Doshi

I would widen the scope so it's not just training but it’s more awareness and having knowledge around ICT risks. The regulators expect some level of competency to sit within the management body and people who are tasked with managing ICT risk, that they understand the landscape, they understand the context.

It's bringing a level of awareness to those folks. And if the organisation is, I hate to use the term, but running a ‘tick the box exercise’, for example running one training session every year, that's not going to fly because they have to demonstrate that what they are doing is worthwhile and meaningful.

Panos Kiziris

As far as FMI preparedness is concerned, should they be doing anything when looking at DORA from the opposite side?

Some FMIs are themselves critical providers or third-party providers to other entities. So should they be looking at that and how they should be responding?

Shreeji Doshi

They are not considered to be ICT third parties under DORA. There are specific exclusions within DORA, and that’s one of them, those financial entities providing ICT services to other financial entities.

Panos Kiziris

Fantastic. That's clear. I had a question which I should have asked perhaps a bit earlier, about recording anomalies and events. And although we have talked about that a bit, I would like to expand the question because we know that CSDs have a risk register, they have a risk matrix, they monitor all the risk which they are exposed to and they assign criticality, they monitor incidents. So from a DORA perspective, within the DORA framework, do they need to have a different risk register just for these ICT risks? Can they put it into their general risk matrix and how should they record the anomalies, incidents, events that are happening, and should it happen manually, automatically, can they just have a spreadsheet?

Does DORA specify a more strict and structured way of doing it?

Shreeji Doshi

I'll break down the question in a couple of points. The first one was, does it go into an enterprise risk register, or a separate ICT risk register? From a practical and implementation point of view, in my experience, ICT risks are captured and recorded separately just purely because of volume, and there would be linkages to the enterprise risk register, but then it would be at some consolidated level with certain risk categories.

ICT risk should therefore be recorded separately from an enterprise risk point of view. On recording anomalies and incidents, now this is also a separate register, or inventory log, if you will, where this is logged as an event, as an incident. And there are specific processes that are designed to identify ‘what is the event to incident escalation path?’ and all of that.

But then risk is something that is supposed to happen in the future. And when we're talking about events and incidents, it is something that has occurred. Now if that incident that has been registered has the potential to create further risk, then it goes into the risk register, if you see what I mean. So we consider events and incidents as part of an issue log because that is something that already happened and risk is something that could possibly happen.

So again, it would be two separate registers.

Panos Kiziris

What happens if an entity is not compliant with DORA by mid-January 2025? Are there any penalties for noncompliance? Are there any sanctions?

Shreeji Doshi

What is clear at this stage is organisations have to be compliant by 17 January 2025.

The competent authorities or supervisory authorities will have to perform some sort of assessment of the entities after that date and that will take however long. So there will be a narrow window of time available for organisations that are still behind to buck up, but that is ‘unofficial’ if you like, and the official expectation is that everyone will be compliant by 17 January.

But, as I’ve said, the regulatory action may take time. Now, what happens if there is some sort of DORA noncompliance? There could be administrative fines that would be levied by these competent authorities.

The extent of these fines has been left to individual Member States and their competent authorities to determine. There could be public reprimands depending on the severity of non-compliance. There could even be orders to provide compensatory damages because of DORA non-compliance. So these are various tools that the competent authorities would have.

There is no single answer as to what would happen. But the idea is that there would be some sort of reputational risk as a result of non-compliance, and possibly even financial losses.

Panos Kiziris

Now the million dollar question: Do you think there will be an extension? I mean, we've seen quite frequently in Europe last-minute extensions of a year or two years when entities are in need of more time, let's say, to comply.

What do you think from experience, Shreeji? Because I would bet there will be an extension, but it will be an 11th hour one.

Shreeji Doshi

I would have loved to be able to guess this too, even a remotely educated guess. But my hunch is that there will not be any extension.

Panos Kiziris

Really?! OK, that's a very interesting take. We'll see. We won’t wager on it. But yeah, we’ll see next January!

Shreeji Doshi

It's a good bet to do, Panos, if you’re feeling lucky!