The DORA Act – How to be Compliant in 365 Days

Hello everybody, and thank you for joining us today for our webinar about the DORA Act and how you can be compliant with it in 365 days. During this presentation, please do not hesitate to put your questions in the question box and we will address the questions that we can get to before the end if we have time, and if not, we will write to you directly at your email address.

So, let’s get started. Who are you going to be speaking with? First you’re going to be hearing from myself. My name is Leanne Debeurre. I’m one of the Product Marketing Managers at Radiant Logic, and you will be hearing most of the time from my colleague, Khadija el Afrit, who is a Senior Technical Enablement Specialist. Khadija, can you say hello?

Yes, hi Leanne. Hi everybody, and thanks for joining our webinar.

Super. All right, so let’s get started. We’re going to take a look first at the agenda and what we’re going to talk about. We will first go over an introduction to the DORA regulation—what it’s about and what you need to know. Then we’re going to help you with some proposed steps on your user‑access‑governance piece, which is a part of DORA, so we’ll hone in on that area. At the end, we’ll give you a checklist and some outcomes that you can expect. We’ll go through these step by step with Khadija.

A quick introduction to DORA: if you’re not familiar with the word DORA, it stands for the Digital Operational Resilience Act. That has been shortened to DORA; it’s much easier to say it that way.

Who is affected by the DORA regulations? Financial companies operating in the European Union are the ones that will need to address this, as well as ICT critical service providers. However, remember that if you are a company that is not based in the European Union and you do business or you have an office, branch, or subsidiary in the European Union, you will also have to comply with these regulations.

When do they come into effect? They come into effect exactly one year from today. If you’re astute, you already have your calendars marked. One year from today you will have to be compliant with the DORA regulations, and our focus today is on the user‑access‑governance piece.

Let’s look at the proposed steps. We’ll give you a general outline, and then Khadija will go through, one by one, the various boxes. You have 365 days—actually 366, because this is a leap year, so you have one extra day—to work on this. Basically, your project over 365 days will look a bit like this.

For the first month, you’re going to map your existing information‑systems processes, the ones that you already have internally in your company. Then you’re going to take the next two months to do a gap analysis between what you’re currently doing and what the DORA requirements are. That will take you about eight weeks. Once you have that together, you will take one month to define the path from where you stand today to DORA compliance: how you’re going to get there. That will take your teams about one month.

Then you’ll have the remaining eight months to apply the requirements that you found in your gap analysis to your processes, so that you can be compliant on January 17, 2025.

Now we’re going to hand it over to Khadija. She’s going to walk through all of those steps in a little bit more detail.

Thank you, Leanne. Okay, so let’s get into the details. For each of the steps on the previous slide we displayed a ballpark timeline, but what you have to keep in mind is that you have to dedicate the major part of 2024 to project implementation, and have three to four months at the beginning for the first three steps I’m going to lay out now.

The first step applies if you’ve checked that your corporation is under the DORA scope. So if you’re a bank, an insurance company, a securities company, an investment firm, etc., then DORA is applicable to you. You also have to check which category you fall into, and whether you’re considered a micro‑enterprise or not, because the volume of requirements may be slightly different between small and major companies.

The other prerequisite before you dive into mapping is to make sure that the ICT process documents are available within your information system. During this first step, you will proceed with an inventory of all your existing information‑security processes: what are the existing processes for risk management, incident management, resilience testing, etc.?

For each process, you’ll establish an inventory of all related documents, tools, reports, dashboards, and platforms used by these processes. That will help you build a list and description of the processes that run within your company. It’s also important to have the latest version of the reports that are generated within each of these processes: your latest risk‑management KPIs, incident‑management KPIs, etc., so you can check whether they are compliant with DORA or will need enhancements.

Mapping your existing information‑security processes requires involvement from all the security team leads. DORA will cover information security, identity and access management, identity and access governance, but other streams such as the SOC, network security, IT‑risk management, etc., are also involved. For some critical applications you may also need to involve application‑management or domain‑management teams.

Once you have a mapping of your existing information‑security processes with an accurate inventory of documents and tools, you’re going to need the combination of that inventory and extensive knowledge of DORA requirements—both the core Act and each European agency’s technical requirements—to proceed with a gap analysis.

In the second step, you assess the DORA requirements and their coverage by your existing processes. Which DORA requirements are already covered, and which ones require processes or tools that are currently missing? This leads to the generation of a gap‑analysis report—a first version of it.

Along with the gap‑analysis report, it’s very important to generate a checklist and an action plan, to identify all items that need to be implemented or set up to cover the missing requirements. For identity and access governance, generating this report will need both the compliance team’s expertise—on the DORA Act, its requirements, and its calendar—and the IGA team’s knowledge of identity lifecycle, provisioning processes, and IGA tools used within the corporation.

Once this gap analysis has been performed and the documents have been shared with upper management and IT‑security team leads, you will establish the roadmap towards DORA compliance, hopefully with the help of an executive sponsor. It is very important to make sure that a sponsor is appointed to help with DORA compliance. Ideally, the sponsor is someone from the board—a COO, CISO, CIO, or Chief Risk Officer—but any board member with strong sensitivity to DORA compliance, IT resilience, and regulatory compliance can play that role.

During this third step, you establish the list of projects and their priorities regarding DORA compliance. For each project, you describe its scope and governance, and you may need to formalize and send out RFPs if you contract external firms, to understand budget and resource needs.

At the end of this step, you will have an extensive DORA‑compliance roadmap including project descriptions, a timeline, and the order in which you will execute the projects, including dependencies and budget/resource estimates for each of them. Establishing such a roadmap requires involvement from the compliance team, IT‑security team leads, and the executive sponsor.

At this stage you are about four months into the year, with a bit over eight months left before the DORA Act becomes effective. That’s when it’s time to roll out all the projects that are part of the roadmap, with approvals received from sponsorship and teams and resources made available.

During these eight months, you’ll work with all necessary stakeholders to roll out the projects, while providing periodic steering updates to sponsorship and upper management. Because there will be further technical requirements issued by European agencies during 2024, you will also need to update the gap‑analysis report.

We advised you to create a first version of the report at the beginning of the year, taking into account both the core DORA Act and the 2023 technical requirements from each agency: the European Banking Authority, ESMA for securities and markets, and EIOPA for insurance and pension funds. Drafts for these technical requirements are due now and should be published soon on their websites. There will be a second phase of consultation, and final versions are expected in July 2024. Since that comes mid‑year, it calls for an update to your gap‑analysis report and possibly some updates to the project timeline as well.

Once this is all done, you’ll get to the end of the year having implemented the missing DORA requirements and having a continuous tracking method for risks and incidents, hopefully leading to continuous improvement on ICT‑related risks. This rollout phase requires everyone’s involvement, from the compliance team and IT‑security leads and teams up to the executive sponsor.

So that’s basically how we would recommend you handle DORA compliance within a year.

That’s great, Khadija, thank you for all that explanation. Now, can you help us a little bit with what a checklist would look like and the outcomes of that work?

Yes, right, Leanne. The project steps we just introduced can be applied to all sorts of topics within cybersecurity. Here we’re going to focus on identity and access governance in particular. On the slide you can see a reminder of the main pillars of the DORA Act, which we already introduced in the previous webinar hosted in December.

Let’s dive into each of these pillars and see what they mean for identity and access governance.

The first pillar is related to risk‑management frameworks. The DORA Act states that financial companies need to implement a risk‑management framework for ICT‑related risks, and design relevant controls, dashboards, and KPIs to keep track of them. When it comes to user‑access governance, you need to ensure that the common risk‑management framework your company establishes includes a section dedicated to user‑access governance.

You need to have a list of permanent controls and associated dashboards that you track periodically, and a system of periodic access review that allows your teams to assess the relevance of users’ accesses and indicate when a specific access right needs to be deleted.

These are all features we can help with using the RadiantOne platform, in particular with our Identity Analytics features. We provide a library of over 150 permanent controls, an out‑of‑the‑box library of dashboards and analytics reports, and features for periodic access‑review campaigns that you can create from scratch using our web portal.

The second DORA pillar is incident management. DORA requests companies in financial services to come up with a full incident‑management process that includes classification of incidents, in addition to the whole lifecycle from identification to deletion and resolution.

For user‑access governance, you can consider illegitimate accesses as the anomaly or incident. Using our Identity Analytics capabilities, you can set up an identification‑to‑deletion pipeline for illegitimate access: they can be identified either as results from permanent controls or as revocation requests coming from periodic access‑review campaigns. Once identified, we provide a process to handle revocation or update of illegitimate accesses, especially for customers who interface our platform with their ITSM or incident‑management systems such as ServiceNow or Jira.

The third DORA pillar is information sharing. It is a requirement visible throughout the DORA Act across all pillars. DORA requires companies to ensure that they provide relevant KPIs, dashboards, and reports on all DORA streams and cybersecurity activities, and that these can be shared with internal upper management, national authorities, or European agencies depending on your activity—EBA for banking, EIOPA for insurance, ESMA for securities and markets.

For identities and entitlements, Radiant Logic provides observability through permanent controls and an extensive library of dashboards that can be shared out of the box. We also provide capabilities to design your own dashboards and reports, and to release them on a need‑to‑know basis to relevant stakeholders.

Resilience testing is another major aspect of DORA. It requires financial corporations to establish periodic resilience testing and threat‑based penetration testing on their information systems. This part is not directly linked to our user‑access‑governance activity; it is another topic. However, DORA asks financial corporations to make sure that data related to resilience testing is secure and access‑restricted. You need to mitigate the risk of data leakage regarding resilience‑testing protocols, datasets used, or result reports.

With our Identity Analytics offering, we can provide features to help you gain access control over resilience‑test data hosted in unstructured‑data folders, whether local shared folders or cloud‑based ones, so you can ensure that only the right people have access to these folders and data.

Last but not least, DORA also increases the need for risk management on third‑party critical ICT providers. Financial companies that rely on external service providers for ICT infrastructure need to come up with a dedicated risk‑management framework for these external users. Applied to user‑access governance, this means you need dedicated user‑access‑governance sections within this risk‑management framework for external identities, and a dedicated set of controls and reports regarding risk management around third‑party providers.

We can help by setting up permanent controls on contractors working within a financial corporation: for example, checking whether they have relevant access rights, whether there are data‑quality issues in their identity profiles, or whether their access should be restricted because they belong to a company that has not been listed as DORA‑compliant. The European Union will issue a registry of DORA‑compliant providers starting next year.

We can also provide extra features to customize your platform to help with the due‑diligence work your procurement teams will need to perform before contracting a new ICT service provider.

So, in a nutshell, this is what we recommend you keep track of when you set up your project or program approach towards DORA compliance, and to make sure that, when it comes to user‑access governance, you are abiding by the DORA Act by January 17, 2025.

That was excellent, Khadija, thanks for that. Would you be able to show us what this would look like in the platform itself?

Yes. I prepared a couple of screenshots to give you an idea of what we can provide with our Identity Analytics portal. On the left, you have an example of an application‑access‑rights review. Typically this is the kind of review you can set up on a yearly basis—or even more often if you’d like—either for DORA requirements or for any other regulatory‑compliance need.

On the right you can see an example of a dashboard that we provide out of the box, as part of our dashboard library. This dashboard gives you a complete overview of the repositories within a company. In this example, we have aggregated data about all repositories—Active Directory, LDAP directories, etc.—with the number of accounts and groups included in them. You also see a list of controls on accounts or group memberships, with security alerts generated when you go above certain thresholds. These are the controls appearing in red or yellow.

Within our Identity Analytics portal, you can click each of these components and get to the detailed list of all anomalies identified within those permanent controls. These are two examples of features we provide to help our customers set up an operational response to DORA with minimal effort.

Excellent. That’s wonderful. Thank you for all of that.

Thank you, Leanne, and thanks everybody for attending this webinar. Thank you, and have a good day.