How DORA Will Affect Your Company’s Compliance Posture

Hi everybody, welcome to our webinar today. We’re going to be talking about how DORA will affect your company’s compliance posture. We’re going to get a little bit into the principles of the DORA Act, and we are going to show you how Radiant Logic can help speed up your time to compliance and the steps that you’re going to need to take to be ready for January 2025.

Today you’re going to hear from myself. My name is Leanne DeBurr. I’m in the product marketing department at Radiant Logic. You’ll also be hearing, for the most part, from my friend, Khadija Ellafrit. She’ll introduce herself.

Yes, hi everybody. My name is Khadija and I’ve been a professional services consultant for Radiant Logic for the past three years. My job is basically to help our customers implement and set up our software, and I also assist them in maintenance and in user training.

Very good. Okay, so let’s take a look here at the agenda we have going on for today. What you’re going to hear to start with is more about the DORA regulations, and we’re going to give you an introduction to that. Then we’re going to show you the impact of these DORA requirements on access rights. Third, we’ll look at how we can successfully address DORA requirements regarding user access governance, and how you can do that within your own companies.

So here we go. I think I’m going to pass it over to Khadija. She’s going to start off with an introduction about DORA.

Yes, that’s right, Leanne. First I wanted to explain to you all why DORA is a significant step for the European Union’s cybersecurity effort. The European Union noticed that many financial entities, many financial service companies, are facing contexts that include increasing volumes of cyber threats, along with new working contexts that may contribute to this increase, such as digitalization for their customers and remote working that has become more and more common over the past three years.

They are trying to address these increasing risks by setting up their own cyber‑defence frameworks and solutions, but they don’t have a common ground on how to implement those. That’s why the arrival of the DORA legislation, after previous efforts from the European Union that already released other pieces of legislation like GDPR and so on, is now a big recognition of cyber‑resilience and cyber risk as a higher priority for the financial services industry.

All right, can you give a few more details about this?

Of course. So what is DORA? The DORA acronym stands for Digital Operational Resilience Act, and the DORA regulation is a piece of regulation that aims at having financial services companies enforce higher cyber‑defence measures for their information systems.

Who does the DORA regulation apply to? DORA is setting up requirements mostly for FSI companies—financial services companies. It could be banks, asset‑management companies, crowdfunding companies, credit institutions, insurance companies, pension funds, etc. It applies either to European FSI companies or extra‑European FSI companies that have subsidiaries operating within the EU. So even American banks have to enforce DORA requirements when it comes to their European subsidiaries in France or in other European countries.

DORA also provides requirements for cyber‑resilience and risk management regarding another set of stakeholders, which is critical ICT service providers. So any information and communication technology service provider that operates for FSI companies, any ICT subcontractor for these financial services companies, falls in scope.

In terms of timeline, the DORA regulation was published in December 2022. The drafting of the regulation started back in 2020. FSI companies and ICT service providers have two years to enforce measures in order to be compliant with DORA requirements, because those requirements will go into effect on January 17, 2025. So we’re now in the space where it will go into effect about one year from the moment of this recording.

The purpose of the DORA regulation is to enforce both operational digital‑resilience measures among FSI companies for their information systems, and specific measures for risk management regarding ICT service providers and their own employees that are operating services for FSI companies.

So Khadija, can you tell us what types of solutions would be helpful in enforcing DORA?

Well, there’s no such thing as a single solution that would help a corporation enforce all DORA requirements. If you want to comply with DORA, you’ll have to rely on the whole cybersecurity ecosystem, which may include several topics such as penetration testing, data protection, infrastructure backup and restoration, or authentication.

Not only is there no single solution that could cover all the requirements, but DORA itself requires that FSI companies use a multi‑vendor approach. DORA explicitly states that FSI companies have to rely on several vendors in order to boost their resilience, so that in case they have one piece of software that is no longer maintained, sold, or available, they can rely on other software vendors in the market to cover for it.

As Radiant Logic, our main focus is on identity and access‑governance‑related controls.

That was a very thorough introduction, Khadija, thank you very much. But now can you tell us a little bit about what effect DORA will have on requirements around user access, governance, and compliance?

Yes, sure, Leanne. First we have to identify the main chapters that need to be addressed within the DORA regulation. For this study, I excluded the chapters that specify how the European authorities should work with this regulation. If we take the main chapters that apply to FSI companies and their third‑party service providers, we have four pillars that I’m going to detail now.

The first one is ICT risk management. The major novelty here is that DORA does not deal with business risks like financial risks or insurance‑related risks. It deals with ICT or IT risks that have to be handled specifically for financial‑services companies.

DORA requires FSI companies first to set up an ICT risk‑management framework. Each company has to draft a risk‑management plan where they identify all the risks applicable to their situation. They also have to set up governance related to those risks and identify the main stakeholders and committees, and provide them with the right KPIs and reporting in order to keep track of the risks and monitor them in the long run.

When it comes to user access, you really have to include user access governance as a full part of your risk‑management framework. In your corporate risk analysis regarding ICT risks, you’ll have several topics: risks regarding your network, your infrastructure, your business software, and you will have to include user access as one of your sections.

That implies that you will also need to set up dedicated governance regarding user‑access‑related risks. It may involve your IGA product owners, line managers, and business application owners, and all these people may need to be involved in the governance of user‑access‑related risks. It also means that KPIs and reporting have to be generated and refreshed periodically to keep track of these risks.

The second section deals with ICT incidents. DORA states that FSI companies will have to implement a process dedicated to ICT incident management. This process needs to lay out several steps, and DORA gives a whole ICT incident‑management approach that goes from the identification of an issue or anomaly all the way to troubleshooting and incident resolution.

During these steps, DORA specifically requires FSI companies to classify their ICT‑related incidents, in order to distinguish the most critical incidents from those that may be less critical. That is a major part of the ICT‑incident chapter in the DORA regulation. These requirements come with the need to provide reporting and information regarding past incidents to European supervisory authorities (ESAs).

There are several European agencies that are qualified to be ESAs: for example, the European Banking Authority for banks and credit institutions; ESMA, the European Securities and Markets Authority, overseeing activities for asset‑management or crowdfunding companies; and EIOPA, the European agency for insurance and pension funds, overseeing insurance companies and pension funds across Europe.

For the handling of ICT incidents, Radiant Logic can provide incredible insight on your user‑access anomalies: for example, what happens when you have a segregation‑of‑duties violation that could trigger internal fraud, when you have active accounts belonging to people who left your organization, or privileged access granted to people who shouldn’t have it. These can be considered anomalies and could trigger even more critical issues if people use undue access rights for malevolent purposes. The insight we provide on user‑access anomalies and their remediation can help address this section of the DORA requirements.

The third pillar of the DORA requirements is resilience testing. I’ll be a bit quicker on this part since Radiant Logic does not provide features regarding this chapter, as resilience testing is a whole other activity. DORA states that FSI companies need to set up a resilience‑testing program, with obligations such as relying periodically on external auditing companies, especially for corporations that perform their own resilience testing, at least once every three or four years. They also need to perform advanced testing programs such as threat‑led penetration testing.

The fourth and last pillar relates to risk management for ICT service providers, and in particular ICT critical service providers. Any ICT company that provides or operates services that help in the business‑critical aspects of FSI companies falls here. For these companies, DORA states that FSI companies must enforce dedicated controls on their ICT critical service contractors in two ways.

First, they need to perform specific due diligence in terms of ICT risks before contracting with them. For example, FSI companies will need to check that a given ICT critical provider is listed as an approved critical provider by the European Union, and that they are compliant with DORA and other requirements.

Then, after contracts have been signed, FSI companies are asked to create a dedicated risk‑management framework for these ICT critical providers. Access rights held by these contractors have to be a huge part of these frameworks. In that sense, Radiant Logic provides many controls and risk assessments that include specifics of contracting companies and external identities operating parts of your information system.

The third section of this fourth pillar deals more with the oversight of ICT providers by European supervisory authorities. It covers relationships between the EBA, ESMA, EIOPA, and these ICT critical providers. It’s more of a legal part of the regulation and less of a technical one, so our features are more helpful for the first two sections of this pillar.

Across these four pillars, there is one theme that always comes back: reporting and information sharing. DORA is a major legislation when it comes to providing information on cyber risks and cyber‑resilience to other stakeholders. FSI companies are asked to provide reporting and information on their cyber risks and resilience testing to multiple stakeholders.

In particular, DORA states that FSI companies must provide reporting that is also compliant with the national regulations they follow. Reports have to be shared with national authorities, with European agencies like those mentioned earlier, and—in the case of ICT incidents—when an FSI company faces a vulnerability that was not known to the general public, the European Union is considering systems for sharing vulnerability‑related information across FSI companies, so they can consult a common library of vulnerabilities.

That was a very thorough explanation of the four pillars of the DORA requirements. Thank you for that. Now, can you summarize where the RadiantOne platform, offered by Radiant Logic, can help meet these requirements?

Yes. If we zoom out on this overview, we can say that we provide help on most of the pillars regarding DORA requirements. We may not deal with resilience testing, because that’s a whole other topic, but within our activities we provide huge help regarding user‑access governance for all the other pillars.

We have ICT risk‑management features for user‑access governance. We provide features to help handle ICT and user‑access anomalies. We offer dedicated risk‑management features for external identities and contractors. And we provide a whole library of reports, analytics, and dashboards. You can make the most of both out‑of‑the‑box reporting features and your own customized dashboards that can be shared with management or other stakeholders.

So what main features on the RadiantOne platform help with DORA compliance?

That’s a great question. One of our modules is called Identity Analytics. The Identity Analytics module works by rebuilding the access chain. Our platform can ingest data coming from as many data sources as you’d like: directories, applications, unstructured‑data access, etc. We ingest all that and rebuild the links between identities and their links to organizations or divisions, all the way down to the accounts, group memberships, and the access rights they are granted, down to fine‑grained access rights.

We can provide a 360‑degree overview of a user’s access rights and of a whole division’s aggregated access rights. We are also able to refresh that view on a regular basis—once a month, once a week, and so on—and keep all these snapshots for as long as you need.

These features allow us to provide incredible value with other features that rely on that access chain. For example, we provide access review for accounts and access rights, monitoring for specific assets like unstructured‑data access or privileged‑access‑management vaults, segregation‑of‑duties controls, and other risk assessments for logical access. We also provide a library of reports and dashboards on user‑access‑related risks.

In addition, because we keep track of a user’s access‑rights history, you can use this history and the snapshots stored over time to perform forensic analysis on past incidents, and to check all the access rights that a user has accumulated over time, especially if you’ve had incidents involving undue access rights. With all these features, the RadiantOne platform can provide an operational response to DORA with minimal effort and within a few weeks.

So Khadija, how would you suggest that a company get started on a DORA project?

That’s a good question. For FSI companies, I would hope that most of them have started working on the DORA requirements since early 2023. But let’s assume that an FSI company hasn’t and is starting right now from scratch.

What I would advise is to start by mapping existing information‑system processes: do they already have a risk‑management framework, an incident‑management process, resilience‑testing programs, etc.? Keeping track of all existing processes within the corporation would take around one month.

Then, let’s assume it would take two months to perform a gap analysis, comparing existing processes on the one hand and DORA requirements on the other hand. That allows you to identify what’s missing: do you need to set up additional risk‑management frameworks or KPIs, enrich your incident‑management processes, or provide a new way of classifying incidents, etc.?

As soon as you’ve identified all your gaps regarding DORA requirements, I would assume it would take up to one month to define the path towards compliance. That takes the form of a roadmap that includes all the projects needed to reach DORA compliance, laid out in time so they can be prioritized within each team.

That leaves around eight months to actually implement these projects and apply the requirements that were found to be missing. This timeline means it would take up to one year to get compliant with DORA requirements, basically achieving compliance a few weeks before the date it actually kicks in in January 2025.

Thank you, our audience, for attending this webinar. Stay tuned for an upcoming webinar with more details about how you can start your own projects and make sure that you are compliant by January 17, 2025. Thank you for attending today. We’re here if you’d like to go on our website, radiantlogic.com, for any additional information or questions you have for us that you weren’t able to ask. We’d be glad to get back in touch with you. Thank you, Khadija, thank you everybody, and hopefully we’ll see you real soon.