DORA guide: understanding and applying the regulation

DORA key requirements and implementation best practices

ICT risk management

The management of risks related to ICT (Information and Communication Technology) is a crucial aspect of DORA compliance. The regulation requires financial entities to identify, assess and mitigate the risks associated with their IT systems and digital infrastructure. The aim is to guarantee business continuity in the face of major incidents and to ensure solid operational resilience.

Identification and assessment of ICT risks

Risk identification is the first step in the ICT risk management process. It involves an in-depth analysis of all the internal and external vulnerabilities that could affect the security, performance and availability of the company’s critical systems. The main types of risk to consider are:

• External risks linked to cyberattacks: threats such as phishing, ransomware, DDoS (denial-of-service attacks) and intrusion attempts by hackers. These threats are particularly dangerous because they can severely disrupt the company’s operations.
• Internal risks: these include human error, flaws in system configuration, and a lack of follow-up in applying security patches. These risks, often underestimated, account for a significant share of security incidents.
• Risks linked to dependency on ICT providers: many companies outsource some of their ICT infrastructure or services, which introduces additional risks. Subcontractors can be targets for attacks, and a failure on their part can compromise the integrity of the main entity’s systems.

To carry out this risk identification, it is essential to have a complete map of ICT systems and in-depth knowledge of the network architecture, databases, applications and third-party tools used by the organisation. This approach makes it possible to build a framework that prioritises risks according to their likelihood of occurrence and their potential impact.

Key steps for identifying ICT risks:

• Carry out a complete audit of ICT systems and digital infrastructure.
• Run vulnerability analyses regularly using automated tools.
• Continuously monitor emerging threats and adjust risk assessments accordingly.
• Take sector-specific risks into account: some financial companies are more exposed to specific threats depending on their size, structure or partners.

Appropriate security measures: best practices and concrete examples

Once the risks have been identified and assessed, it is imperative to put appropriate security measures in place to reduce the likelihood of them materialising. These measures must be adapted to the size of the entity and the complexity of its systems. Here are the main recommended practices for securing ICT infrastructure:

• Network segmentation: this technique consists of dividing internal networks into several distinct segments to limit the spread of threats. If one section is compromised, the rest of the network can remain secure. Concrete example: a bank could separate the internal network used by its employees from the one accessible to customers. That way, a compromise of the customer network would not spread to sensitive internal systems.
• Strengthened access controls: access to critical systems must be strictly controlled using robust authentication methods such as multi-factor authentication (MFA). This reduces the risk of cybercriminals accessing systems if an employee’s credentials are compromised. Concrete example: in an asset management company, only certain employees with specific rights can access customer data or critical financial systems. In addition, role-based access control can restrict this access even further.
• Data encryption: it is essential to protect sensitive data, whether in transit or at rest, with advanced encryption solutions. This guarantees that even in the event of an intrusion, stolen information cannot be exploited. Concrete example: banking transactions and customer data can be encrypted using protocols such as SSL/TLS to prevent them from being intercepted or modified while being transferred over the internet.
• Backup and recovery: to deal with attacks such as ransomware, companies must put regular backup systems in place. These backups must be tested regularly to make sure they can be used when needed. Concrete example: a bank makes daily backups of all its transactional data. These backups are stored on offline servers, which makes it possible to restore the data quickly if the main systems are compromised.
• Regular system updates: security patch management is a critical element. It is essential to roll out updates quickly across all systems to fix the flaws exploited by cybercriminals. Concrete example: a financial institution sets up a strict policy requiring critical updates to be installed within 24 hours on all critical systems.
• Continuous employee training: employees are often the weakest link in the security chain. Regular training on cybersecurity best practices, such as recognising phishing emails or social engineering attempts, is indispensable. Concrete example: an insurance company holds monthly awareness sessions in which employees learn to identify phishing attempts and how to behave in suspicious situations.

Recommended tools and methodologies

To support the implementation of these security measures, companies must rely on specialised tools and proven methodologies to manage ICT risks on an ongoing basis. Here are a few recommended solutions:

• Vulnerability management tools: tools such as Tenable Nessus or Qualys scan IT infrastructure to identify vulnerabilities and security flaws. They generate detailed reports that help security managers prioritise the actions to take.
• SIEM (Security Information and Event Management): a SIEM such as Splunk or IBM QRadar centralises security events from several sources (system logs, firewalls, servers, etc.) to identify abnormal behaviour and trigger alerts. This enables rapid detection of ongoing incidents. These tools help companies carry out proactive monitoring, a central element of DORA compliance.
• ISO 27005: this ICT risk management framework provides a structured methodology for identifying, assessing, treating and monitoring risks. It is aligned with other information security standards, such as ISO 27001, which provides an overall framework for managing information security management systems (ISMS).
• NIST Framework: the NIST Cybersecurity Framework is another international reference for ICT risk management. It offers a step-by-step guide to assessing and improving the security of IT systems.

Adopting these tools and methodologies gives organisations a complete view of their security posture, allows them to manage ICT risks proactively and to comply with DORA requirements. As well as guaranteeing business continuity, these practices increase resilience to cyber threats, thereby reducing the potential consequences of an incident.

ICT incident management

ICT incident management is another essential aspect of the DORA regulation. This requirement aims to ensure that financial entities and their ICT providers have effective mechanisms to detect, respond to and resolve incidents likely to disrupt their activities. Incidents can include cyberattacks, outages of critical systems or even human errors that have an impact on the security of information.

Incident detection, escalation and resolution procedures

Effective ICT incident management relies on well-defined, formalised procedures. These procedures must be established so that incidents can be responded to quickly, while minimising their impact on the organisation. Here are the essential steps to follow:

• Proactive incident detection: using system monitoring tools and SIEM (Security Information and Event Management) solutions makes it possible to detect anomalies or unusual activity that may indicate a system compromise. Incidents must be identified as early as possible to prevent them from spreading. Concrete example: a bank uses a SIEM to monitor its network and critical systems in real time. Automatic alerts are triggered when unusual activity, such as unauthorised access or an abnormal data flow, is detected.
• Incident escalation: when incidents are identified, they must be escalated quickly to the right team or the right manager according to the severity of the incident. Escalation procedures must be clearly defined to avoid any delay in handling the situation. This includes plans for determining incident severity levels (minor, major, critical) and response plans specific to each level. Concrete example: when an intrusion attempt is detected on a financial institution’s network, the incident is immediately reported to the security team, which decides on the measures to take, such as isolating the network segment concerned to limit the impact.
• Rapid incident resolution: once the incident has been reported, teams must step in to contain the threat and restore the affected systems as quickly as possible. This may include closing compromised access, restoring data from backups or quarantining infected systems. Major incidents require coordinated management across several departments (IT, legal, compliance, etc.) to ensure effective resolution. Concrete example: if ransomware is detected in a system of an asset management company, the incident response team immediately triggers its emergency plan: systems are taken offline, backups are restored, and an investigation is carried out to understand the origin of the attack.

Major incident simulation exercises: typical scenarios and lessons learned

The DORA regulation also encourages companies to carry out simulation exercises to test their ability to handle major ICT incidents. These exercises make it possible to prepare teams to react effectively in a crisis situation and to identify the weak points in incident management procedures.

Typical scenarios include:

• Cyberattack simulations: these can include ransomware attacks, system intrusions or attempts to steal sensitive data.
• Critical system outages: these simulations assess the company’s ability to maintain continuity of operations when a central system goes down.
• Data loss incidents: test the ability to react to the loss or to the corruption of data, including restoration from backups.

Lessons learned: the results of these simulations provide valuable information on the weaknesses of systems and incident management processes. They help improve emergency plans and make sure that best practices are properly applied.

Concrete example: an insurance company organises a simulation exercise of a ransomware attack. The exercise reveals that the data restoration procedure is too slow. Following this exercise, the incident management team decides to improve its backup tools to reduce restoration time.

Emergency plan and crisis communication templates

In the event of a critical incident, having an emergency plan is essential to minimise disruption. A good emergency plan must cover several aspects:

• Identification of responsible parties: each team member must know their role in a crisis.
• System prioritisation: identify which systems must be restored first to ensure the continuity of critical services.
• Containment procedures: determine the actions to take to prevent the incident from spreading to other systems or networks.

At the same time, a crisis communication plan must be put in place. It is essential to communicate quickly and effectively with internal and external stakeholders. This includes:

• Informing internal teams of the situation in real time to coordinate the incident response.
• Notifying regulators and competent authorities in line with legal obligations, in particular in the event of theft of sensitive data or incidents affecting critical systems.
• Communication with customers and partners: in the event of a significant impact, it is essential to reassure customers and partners while being transparent about the situation and the measures taken to resolve it. Concrete example: when an external ICT service provider is compromised, a bank immediately activates its crisis communication plan, informing its customers that their data is protected and that corrective measures have been taken to minimise the impact.

Resilience and integrity testing

The DORA regulation requires financial entities to carry out resilience tests to make sure their information systems are robust enough to withstand cyber threats and operational disruptions. These tests, often called stress tests, aim to assess the ability of systems to withstand emergency situations, such as major cyberattacks, outages of critical systems or incidents linked to external providers.

Penetration and intrusion testing: best practices and tools

Penetration tests, or “pentests”, are essential for identifying hidden vulnerabilities in information systems. They consist of simulating real attacks to assess the security of ICT infrastructure.

Best practices for pentests include:

• Carrying out regular tests: at least once a year or after each major update.
• Using specialised tools: such as Metasploit or Burp Suite, which can simulate complex attacks.
• Working with external experts: to benefit from independent and objective expertise.

Security and resilience audits: assessment grids and key indicators

In addition to penetration tests, DORA requires regular security and resilience audits to be carried out. These audits assess the compliance of information systems with established security standards and make sure that the measures in place guarantee continuity of operations in the event of major disruption.

Resilience audits assess the entity’s ability to maintain its critical functions and to restore services after a serious incident. Here are the key steps for carrying out a security audit that meets DORA requirements:

• Risk assessment grids: use analysis grids based on recognised standards, such as ISO 27001, to assess systems. This makes it possible to measure the degree of compliance and prioritise corrective actions.
• Key performance indicators (KPIs): set up indicators to track audit results and the progress made in implementing recommendations. Essential KPIs include:
  • The number of vulnerabilities identified and fixed.
  • The reaction time to security incidents.
  • The frequency and effectiveness of data backup and restoration tests. Concrete example: during a resilience audit, an insurance company discovers that its backup systems do not allow critical data to be restored quickly. An action plan is immediately put in place to strengthen the backup infrastructure.

Examples of audit reports and action plans

At the end of each audit, a detailed report must be written. This document gives an overview of the vulnerabilities identified, the levels of compliance achieved, and the measures to take to improve the security and resilience of systems. Here are the main components of an effective audit report:

• Executive summary: give an overview of the findings, with emphasis on the major risks that require priority action.
• Description of vulnerabilities: details of the security flaws discovered during penetration tests or resilience audits.
• Security recommendations: proposed measures to mitigate the risks identified, including technical, organisational or procedural solutions.
• Action plan: set deadlines and priorities for implementing the corrective actions. The plan must include KPIs to measure the effectiveness of the measures taken.

Example report: an audit carried out for a banking institution identifies several flaws in the management of access to sensitive data. The report recommends deploying an identity and access management (IAM) solution to strengthen credential security and limit access to critical data.

The results of these audits must be followed by concrete action plans. Each recommendation must be associated with a deadline and an owner responsible for implementing it. Documenting the measures taken also makes it possible to prove compliance during inspections by regulatory authorities.

ICT outsourcing

ICT (Information and Communication Technology) outsourcing represents a major issue for compliance with the DORA regulation. Financial entities often call on external providers to outsource part of their ICT infrastructure or services, such as cloud computing, data management, or even cybersecurity services. DORA imposes strict obligations concerning the management of the risks linked to this outsourcing, in order to guarantee that the providers meet the same security and resilience standards as the main entities.

Assessing subcontractor risks: questionnaires and analysis grids

Before contracting with an ICT provider, companies must carry out an in-depth assessment of the risks associated with this outsourcing. This involves assessing the provider’s ability to guarantee security, continuity of services and operational resilience.

One of the best practices for assessing providers is to submit a security and resilience questionnaire to them. This questionnaire gathers precise information on:

• The security measures in place: firewalls, access control, data encryption, etc.
• Incident management procedures: how does the provider react in the event of an incident or attack?
• Resilience and business continuity testing: does the provider run resilience tests on its own systems to guarantee continuity of services?
• Compliance with international standards: ISO 27001, ISO 22301 (business continuity management), or other standards specific to the financial sector. Concrete example: a bank wants to outsource its data storage to a cloud computing solution. Before choosing a provider, it submits a detailed questionnaire to assess its ability to secure sensitive data and ensure the resilience of its infrastructure against cyberattacks.

In addition to questionnaires, analysis grids can be used to measure providers’ potential risks. These grids assign a score to each aspect of security and resilience, making it possible to prioritise risks and make informed decisions when choosing a provider.

Contractual security and resilience clauses: templates and examples

Once a provider has been selected, contractual clauses play a key role in formalising security and resilience obligations. It is essential to include specific clauses in contracts to guarantee that the provider complies with the requirements of the DORA regulation.

The most important contractual clauses include:

• Security obligations: the provider must commit to implementing specific security measures, such as data encryption, network segmentation or intrusion detection solutions.
• Regular security tests and audits: contracts must stipulate that the provider is subject to regular security audits, as well as penetration tests to check the robustness of its systems. In addition, the main entity must have the right to carry out independent audits to make sure the provider complies with security standards.
• Incident management plan: the contract must set out the provider’s obligations in the event of an incident, including incident notification deadlines, escalation procedures and remediation measures.
• Business continuity commitments: the provider must guarantee that its services will remain available even in the event of major disruption (outage, attack, disaster). Service level agreements (SLAs) must specify the time frames for restoring services in the event of an incident. Concrete example: an asset management company includes a clause in its contract with a cloud provider requiring the provider to carry out annual resilience tests. If this obligation is not met, the company can terminate the contract without penalties.

Monitoring and control of subcontractors: indicators and reporting

Managing outsourcing risks does not stop when the contract is signed. It is crucial to set up regular monitoring mechanisms to make sure providers meet their contractual obligations and maintain a high level of security and resilience.

Financial entities must define key performance indicators (KPIs) to assess the services delivered by their subcontractors. The most relevant KPIs can include:

• Compliance with SLAs (service level agreements): response time in the event of an incident, availability of services, time frames for restoring critical systems.
• The number and severity of security incidents occurring at the provider.
• The results of security audits and tests carried out by the provider or by independent third parties.
• Compliance with security updates and patches: make sure the provider applies security updates within the agreed time frames to fix the vulnerabilities discovered.

In addition, it is important to set up regular reporting with providers, to discuss recent incidents, security improvements and any adjustments to contractual agreements.

Concrete example: a financial services company sets up a dashboard to track the performance of its ICT providers, including indicators such as the number of incidents reported, the duration of service interruptions, and the results of resilience tests. This dashboard is reviewed quarterly with the providers during performance review meetings.

Monitoring and reporting

Continuous monitoring and regular reporting are key elements of DORA compliance. They allow financial entities to track the security status of their systems in real time, identify incidents quickly and report on their performance to the competent authorities. These mechanisms aim to strengthen transparency and to facilitate the proactive management of ICT risks.

Security and resilience key performance indicators (KPIs): examples and dashboards

To monitor the security and resilience of information systems, it is essential to set up key performance indicators (KPIs). These KPIs must be tracked regularly through dashboards, giving decision-makers an overview of potential risks and security flaws. Here are a few examples of relevant indicators for DORA compliance:

• Mean time to respond to incidents (MTTR): this indicator measures how quickly security teams detect, escalate and resolve security incidents. A low MTTR indicates a better ability to react quickly to threats.
• Number of security incidents: this KPI tracks the total number of incidents identified over a given period, as well as their nature (minor incidents, critical incidents). It measures the effectiveness of detection and response systems.
• Availability of critical systems: it is crucial to track the availability rate of the systems essential to the company’s business, in particular those linked to financial services and sensitive data. An availability rate close to 100 % indicates good management of operational resilience.
• Percentage of security patches applied on time: this indicator tracks vulnerability management by measuring the organisation’s ability to apply security patches quickly after flaws are discovered.
• Resilience test results: this KPI assesses system performance through the results of penetration tests, security audits and incident simulations. It gives a clear view of the robustness of ICT infrastructure.

Dashboards must be designed to offer a simple and accessible view of these KPIs to security managers and IT teams, but also to senior management. These dashboards make it possible to track how risks evolve in real time and to prioritise the actions to take to improve security and resilience.

Concrete example: a banking institution uses an interactive dashboard to track its security KPIs in real time. This dashboard includes automatic alerts when the incident response time exceeds a certain threshold, which makes it possible to adjust resources quickly.

Templates for reports to competent authorities

Under DORA, companies must also submit regular reports to the competent authorities, in particular in the event of major incidents. These reports serve to demonstrate that the organisation has properly implemented the required security and resilience measures and that it manages its ICT risks effectively.

Here are the key elements to include in a report to regulators:

• Description of security incidents: the report must provide a detailed account of each critical incident that occurred, including the nature of the incident, its origin, and its consequences for the company’s systems and activities.
• Corrective actions taken: the report must document all the measures taken to remedy the incident, such as isolating compromised systems, restoring data from backups or fixing the security flaws exploited.
• Impact on activities and customers: it is essential to provide an assessment of the incident’s impact on financial services, customer data or other critical aspects of operations. Regulators must be informed of any significant disruption that could affect the proper functioning of the company or the security of information.
• Results of security audits and tests: the report can also include the results of penetration tests, security audits or incident simulations carried out during the reporting period. These elements allow the authorities to make sure that the entity is properly applying the security recommendations and standards required by DORA. Concrete example: after suffering a cyberattack, an asset management company writes a detailed report for the financial regulators. In it, the company describes the attack, the measures taken to isolate the compromised systems, the impact on customers, and the actions planned to strengthen security in the future.

These reports must be provided regularly to the competent authorities, in line with the deadlines set out in the DORA regulation. They are important evidence of the entity’s compliance with security and resilience requirements.

Key stakeholder roles and responsibilities

Compliance with the DORA regulation relies on a clear organisation of roles and responsibilities within the company. The various stakeholders involved in ICT risk management, cybersecurity and operational resilience must work closely together to protect information systems and ensure continuity of services. DORA requires each role to be clearly defined and the stakeholders concerned to have a precise understanding of their responsibilities.

Responsibilities of the CISO, DPO, Risk Manager, Compliance Officer and Resilience Lead

Each function within the organisation plays a specific role in implementing and managing DORA compliance. Here are the responsibilities of each key stakeholder:

• CISO (Chief Information Security Officer): the CISO is on the front line for ensuring the security of ICT infrastructure. Their main responsibilities include:
  • The management of ICT-related risks.
  • The implementation of technical security measures to protect systems and data.
  • The supervision of penetration tests and security audits.
  • Coordination with incident management teams to ensure a rapid response in the event of a cyberattack.
  • Concrete example: a bank’s CISO is responsible for putting in place a response plan for critical incidents, including network isolation measures in the event of an intrusion.
• DPO (Data Protection Officer): the DPO makes sure the company complies with data protection regulations (such as the GDPR). The role complements that of the CISO, focusing specifically on the management of personal data:
  • Ensure that data processing systems comply with regulations.
  • Coordinate cybersecurity efforts with the CISO to protect sensitive data.
  • Handle reporting to the authorities in the event of a data breach.
  • Concrete example: the DPO of an asset management company works with the CISO to make sure customer information is encrypted and that privacy policies are respected.
• Risk Manager: the Risk Manager oversees risk management across the whole organisation, including ICT-related risks. The Risk Manager must:
  • Identify and assess strategic and operational risks.
  • Implement risk mitigation plans.
  • Coordinate ICT risk assessments with the CISO.
  • Concrete example: the Risk Manager works with the IT teams to assess the financial impact of a major service interruption caused by an outage or a cyberattack.
• Compliance Officer: the Compliance Officer makes sure the organisation complies with all the regulations in force, including DORA. Their responsibilities include:
  • Continuous monitoring of the company’s compliance with DORA.
  • Drafting the compliance reports intended for the competent authorities.
  • Setting up internal processes to guarantee that practices are updated in line with new regulations.
  • Concrete example: the Compliance Officer of a financial institution draws up a reporting calendar to keep the authorities regularly informed of the company’s compliance with DORA.
• Resilience Lead: this role is crucial for ensuring business continuity in the event of a major incident. The Resilience Lead’s mission is to:
  • Develop and implement business continuity plans (BCP) and disaster recovery plans (DRP).
  • Coordinate resilience tests to assess the organisation’s ability to maintain its services in the event of disruption.
  • Supervise crisis simulations to prepare the company to respond quickly and effectively to incidents.
  • Concrete example: the Resilience Lead organises annual cyberattack simulation exercises to test the company’s ability to keep operating in a major crisis.

Coordination and reporting between the different stakeholders

Implementing DORA requires close collaboration between these different stakeholders. Poor coordination can lead to gaps in the management of risks or to delays in the response to incidents. To ensure a smooth and effective management of security and compliance, it is essential to define clear coordination mechanisms.

The key points of coordination include:

• Regular meetings between the security, risk and compliance teams to track progress, identify weaknesses and adjust incident management processes.
• Setting up shared reporting: each stakeholder must provide regular reports on their area of responsibility (system security, data management, risk management, etc.). These reports are then centralised and analysed to give an overall view of the organisation’s security and resilience posture.
• Monitoring incidents and risks: teams must share information on detected incidents, emerging risks and security audit results. This makes it possible to guarantee that each stakeholder is aware of current threats and can adapt their actions accordingly. Concrete example: a financial institution holds monthly meetings between the CISO, the DPO and the Risk Manager to review recent security incidents, assess upcoming risks and adjust action plans according to the priorities identified.

Effective coordination between these stakeholders makes it possible to ensure that the company meets the regulatory obligations of DORA, while maintaining optimal security and minimising the impact of ICT incidents.

Deploying a DORA compliance programme

Implementing a compliance programme for the DORA regulation is a complex process that requires careful planning, dedicated resources and close collaboration between the company’s various departments. The aim is to guarantee that every aspect of the regulation is met, from ICT risk management through to continuous monitoring and communication with the authorities. In this section, we detail the key steps to achieving DORA compliance and propose action plan templates to help you in this process.

Key steps of a DORA compliance project

Implementing a DORA compliance programme involves following a series of structured steps. Here are the main steps for carrying out this project successfully:

1. Initial risk assessment:
   • The first step is to carry out a complete analysis of the ICT risks to which the company is exposed. This assessment must include the identification of internal vulnerabilities (human error, software flaws) and external threats (cyberattacks, natural disasters).
   • The risk assessment must also take into account the risks linked to external ICT providers.
   • Concrete example: an asset management company begins its DORA compliance project by carrying out an in-depth analysis of its IT systems and ICT service suppliers. The assessment reveals several security flaws in the cloud infrastructure it uses.
2. Drawing up an action plan:
   • Based on the results of the initial assessment, the company must create a detailed action plan to fix the vulnerabilities identified and strengthen its defences. This plan must include specific objectives, priorities, owners and deadlines.
   • The action plan must be aligned with DORA requirements, in particular with regard to incident management, resilience testing, subcontractor oversight and business continuity.
   • Concrete example: the institution’s action plan identifies the critical systems that need immediate fixes, while setting a timetable for testing the resilience of the outsourced cloud infrastructure.
3. Implementing security and resilience measures:
   • The next step is to implement the security and resilience measures set out in the action plan. This can include:
     • Strengthening intrusion detection and real-time monitoring systems.
     • Improving data backup procedures and recovery policies.
     • Carrying out penetration tests and security audits to assess the robustness of ICT infrastructure.
   • Concrete example: the IT team deploys a security incident management solution (SIEM) that centralises alerts in real time and facilitates early threat detection.
4. Employee training and awareness:
   • An essential part of DORA compliance concerns employee training. All staff, whether or not they are directly involved in managing ICT systems, must be trained in cybersecurity best practices and incident management procedures.
   • The teams responsible for risk management, security and compliance must also be trained to understand the specifics of DORA and know how to react in the event of an incident.
   • Concrete example: a financial services company holds monthly workshops to raise its employees’ awareness of security best practices, teaching them to recognise phishing attempts and to report incidents quickly.
5. Continuous monitoring and reporting:
   • Once the measures are in place, it is essential to continuously monitor system security and operational resilience. This includes setting up KPI tracking dashboards, incident management and regular communication with the competent authorities.
   • Internal reporting must be carried out regularly, and reports to regulators must be produced in line with DORA requirements.
   • Concrete example: the institution deploys a dashboard to track incidents and vulnerabilities, with automatic alerts when resolution deadlines are missed.

Action plan and progress tracking templates

An effective DORA compliance programme requires a clear action plan and a tracking system to assess progress and adjust strategies as needed. Here is an example of a structured action plan:

• Objective: strengthen the security of ICT systems to comply with the DORA regulation.
• Priorities:
  1. Update intrusion detection systems within the next 3 months.
  2. Resilience test of the cloud infrastructure within the next 6 months.
  3. Train incident management teams on the new SIEM tools and crisis management procedures.
  4. Annual security audit carried out by a third party to validate compliance with DORA requirements.
• Owners: each task is assigned to a specific owner (CISO, Risk Manager, Resilience Lead, etc.).
• Deadlines: each action must be completed within precise time frames, with regular checks to assess how the work is progressing.
• Progress tracking: quarterly reviews make it possible to adjust the action plan according to the results obtained and the incidents encountered.

At the same time, it is important to set up a KPI tracking system to measure the effectiveness of the actions undertaken. Here are a few tracking indicators to include:

• Mean incident reaction time.
• Percentage of vulnerabilities fixed on time.
• Penetration test results and security audit results.
• Availability rate of critical systems.

Advice and lessons learned on key success factors

DORA compliance can present significant challenges for companies, but several key success factors can help guarantee a smooth transition:

• Involve all stakeholders from the start: the compliance programme must not be managed solely by the CISO or the IT team. All departments, in particular the legal teams, risk managers, HR and senior management, must be involved to guarantee that DORA compliance is an organisational priority.
• Invest in the right tools: technologies such as SIEM, identity management solutions (IAM) and vulnerability analysis tools are indispensable for continuous system monitoring and for guaranteeing resilience against threats.
• Test and adjust resilience plans regularly: operational resilience is not only tested during a real incident. Incident simulations must be organised regularly to identify gaps in crisis management procedures and adjust plans accordingly.
• Communicate regularly with regulators: it is essential to maintain close relations with the competent authorities, making sure that reports are provided on time and that any change to systems or processes is communicated proactively. Concrete example: a bank organises a crisis simulation twice a year to test its disaster recovery plans and make sure each team is ready to react in the event of a critical incident.

In conclusion, the DORA regulation imposes strict requirements on ICT risk management, operational resilience and compliance for financial and digital entities in Europe. By following the steps described in this guide and adopting security best practices, companies will not only be able to comply with DORA, but also strengthen their resilience against growing cyber threats.