The Digital Operational Resilience Act (DORA) - A Comprehensive Guide for the Financial Sector

Josef Bergt

2023

Introduction

In this article, an overview on the Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, aimed at fortifying cybersecurity within the financial sector, is provided. The article’s goal is to provide an overview article for Chief Information Security Officers (CISOs), Data Protection Officers (DPOs), and legal departments, elucidating the intricacies of DORA compliance.

The Essence of DORA Regulation

DORA (EU Regulation No. 2022/2554), is designed to elevate cybersecurity standards in financial entities like banks and credit institutions. Its coexistence with the NIS2 Directive (Network and Information Systems Directive or Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union), another crucial EU cybersecurity mandate, gives rise to the question of legal precedence. Here, DORA emerges as 'lex specialis' to NIS2, implying that its specific regulations take precedence in the realm of digital finance. This regulatory interplay emphasizes DORA's role in refining and augmenting the broader cybersecurity framework laid out in NIS2.

DORA's Purpose and Definition

At the core of DORA, as articulated in its Recitals 35 and 105, is the ambition to achieve a high level of digital operational resilience for regulated financial entities. This term encapsulates a financial entity's capability to uphold its operational integrity and reliability amidst disruptions. DORA mandates financial entities to transcend beyond mere defense mechanisms, advocating for a robust resilience framework that ensures the continuity and quality of financial services, even in the face of cyber disruptions.

DORA's Implementation Timeline

The enactment of the DORA Regulation is slated for January 17, 2025, marking a 24-month preparation window post its publication in the Official Journal of the EU. Prior to its full implementation, the European Supervisory Authorities (ESAs) and the European Union Agency for Cybersecurity (ENISA) are expected to articulate common draft regulatory technical standards by January 17, 2024, elucidating various legislative components.

Sanctions under DORA

DORA's approach to sanctions is more nuanced compared to NIS2. While NIS2 stipulates quantified administrative fines, DORA endows member states and their competent authorities with the discretion to determine sanctions, including pecuniary measures, to ensure continued legal compliance.

DORA Compliance

Addressing the 'how' of DORA compliance is critical. The following overview is structured to guide entities through a systematic preparation process for DORA compliance, ahead of the January 17, 2025 deadline.

Understanding the Digital Operational Resilience Act (DORA) is paramount for entities operating within the financial sector of the European Union. This comprehensive legislation, as outlined in its Article 2, applies to a diverse array of 21 types of financial entities. It is imperative for these entities to discern whether they fall under DORA's scope to ensure appropriate compliance strategies are in place. The entities encompassed are:

  • Credit Institutions: These are traditional banks and similar financial institutions that offer credit facilities.
  • Payment Institutions: This category includes all institutions engaged in payment processing, including those exempted under Directive (EU) 2015/2366 (PSD2).
  • Account Information Service Providers: Entities that provide consolidated information on one or more payment accounts.
  • Electronic Money Institutions: Including those exempted under Directive 2009/110/EC (EMD2), these institutions issue and manage electronic money.
  • Investment Firms: Firms involved in securities trading and related services.
  • Crypto-Asset Service Providers and Issuers of Asset-Referenced Tokens: Entities dealing with cryptocurrencies and related financial products.
  • Central Securities Depositories: Institutions that hold and administer securities and enable securities transactions to be processed.
  • Central Counterparties: Entities that facilitate transactions between various entities in the financial markets.
  • Trading Venues: This includes stock exchanges and other platforms where financial instruments are traded.
  • Trade Repositories: Entities that maintain records of derivatives contracts.
  • Managers of Alternative Investment Funds: Entities managing investments in alternative assets.
  • Management Companies: Companies that manage investment funds.
  • Data Reporting Service Providers: Entities providing data and reporting services in financial markets.
  • Insurance and Reinsurance Undertakings: Companies involved in insurance and reinsurance businesses.
  • Insurance Intermediaries, Reinsurance Intermediaries, and Ancillary Insurance Intermediaries: Agents and brokers in the insurance market.
  • Institutions for Occupational Retirement Provision: Entities managing occupational pension schemes.
  • Credit Rating Agencies: Agencies that provide credit ratings for various financial entities.
  • Administrators of Critical Benchmarks: Entities responsible for setting benchmarks that are critical to financial markets.
  • Crowdfunding Service Providers: Platforms that facilitate crowdfunding for various purposes.
  • Securitisation Repositories: Entities dealing with the documentation and reporting of securitizations.
  • ICT Third-Party Service Providers: Providers of information and communication technology services to financial entities.

Exemptions from DORA

Article 2(3) of DORA lists certain entities that are exempt from its regulations. These include:

  • Managers of Alternative Investment Funds: As referred to in Article 3(2) of Directive 2011/61/EU (AIFMD).
  • Insurance and Reinsurance Undertakings: As specified in Article 4 of Directive 2009/138/EC (Solvency II).
  • Small-Scale Institutions for Occupational Retirement Provision: Operating pension schemes with no more than 15 members.
  • Certain Natural or Legal Persons: Exempted under Articles 2 and 3 of Directive 2014/65/EU (MiFID II).
  • Small Insurance Intermediaries: Defined in Article 4(60) of DORA as employing fewer than 10 persons with an annual turnover or balance sheet that does not exceed 2 million euros.
  • Post Office Giro Institutions: As defined in Article 2(5), point (3), of Directive 2013/36/EU (CRD IV).

Additionally, Member States have the discretion to exempt specific national credit or investment entities, as referenced in Article 2(5) of Directive 2013/36/EU.

From its scope, it becomes increasingly evident that the legislation is not merely a regulatory directive but a strategic blueprint for enhancing digital resilience in the financial sector. 

In-depth Analysis of DORA’s Requirements

DORA sets forth a suite of requirements for financial entities in its Art. 1(1), focusing on several key areas:

  • ICT Risk Management: At the core of DORA's requirements is the establishment of a robust ICT risk management framework. This framework should be comprehensive, well-documented, and integrated into the overall risk management system of the financial entity.
  • Reporting of ICT-Related Incidents: There is a mandatory obligation to report major ICT-related incidents to competent authorities. This also extends to the voluntary reporting of significant cyber threats.
  • Operational and Security Incident Reporting: Besides ICT incidents, major operational or security payment-related incidents must also be reported to the relevant authorities.
  • Digital Operational Resilience Testing: DORA mandates regular testing of digital operational resilience to ensure the effectiveness of implemented strategies and systems.
  • Information and Intelligence Sharing: Sharing information and intelligence about cyber threats and vulnerabilities is another critical requirement.
  • Management of ICT Third-Party Risk: Measures must be in place for managing risks associated with ICT third-party service providers.
  • Contractual Arrangements with ICT Providers: There are specific requirements regarding contractual arrangements between financial entities and ICT third-party service providers.

Creating an ICT Risk Management Framework

DORA, particularly in Article 6(1), emphasizes the imperative need for a sound, comprehensive and well documented ICT risk management framework. This framework must be capable of addressing ICT risks swiftly and efficiently, thereby ensuring a high level of digital operational resilience. An ICT risk, as defined in Article 3(5) DORA, is any identifiable circumstance related to the use of network and information systems that could compromise security and operations.

Protection of Software, Hardware, and Data

The framework must encompass strategies to protect both information and ICT assets. These assets include tangible and intangible information assets, software, hardware, and data centers. The protection of data is particularly emphasized, recognizing its critical importance in the digital realm.

Essential Components of the ICT Risk Management Framework

As per Article 6 DORA, the ICT risk management framework must include:

  • Strategies, policies, and procedures for protecting all information and ICT assets, including software, hardware, and servers.
  • Protection of physical components and infrastructure, such as premises and data centers.

This framework is not static; it must be reviewed and updated regularly, at least annually, following major ICT-related incidents, supervisory instructions, or conclusions derived from resilience testing or audit processes.

Implementing an Information Security Management System (ISMS) Aligned with DORA

The implementation of an ISMS is not a mere compliance requirement but a strategic imperative to enhance the digital resilience of financial organizations.

  • Essence of ISMS: An ISMS is instrumental in structuring an entity’s information security management through a systemic approach. It significantly reduces digital risks by establishing a robust framework that encapsulates all aspects of information security.
  • ISO 27001 Certification: While NIS2 envisages future European certification frameworks for cybersecurity, ISO 27001 remains the gold standard for establishing an ISMS. Attaining ISO 27001 certification is a rigorous process that demands substantial organizational commitment. It should, therefore, be a priority for any Chief Information Security Officer (CISO) engaged with DORA compliance.

Simplified ICT Risk Management Framework

Article 16 of DORA introduces the concept of a 'simplified ICT risk management framework' for designated entities. This framework is a streamlined version of the mandatory management framework required by the regulation. Entities eligible for this simplified framework include small and non-interconnected investment firms, payment and electronic money institutions exempt under specific EU directives, and small institutions for occupational retirement provision.

Adoption of the Three Lines of Defense (3LoD) Model

The 3LoD model is a pivotal component of DORA, ensuring an organizational separation of responsibilities and risk governance. This model comprises:

  • First Line of Defense: Operational teams directly involved in risk management. For example, a development team might embed cybersecurity by design principles in their processes.
  • Second Line of Defense: Functions like risk management and compliance, overseen by roles such as the CISO. This layer is responsible for monitoring and implementing the entity’s overall risk management strategy.
  • Third Line of Defense: Independent internal auditors who verify the effectiveness of the first two lines of defense, ensuring comprehensive control of risk management application.

Entity Responsibility in Outsourcing

DORA permits the outsourcing of tasks related to verifying compliance with ICT risk management requirements (Art. 6(10) DORA). However, it emphasizes that the financial entity retains full responsibility for this verification. Outsourcing does not absolve the entity of its obligations or liabilities.

Crafting a Digital Operational Resilience Strategy

A digital operational resilience strategy is a companion to the ICT risk management framework. This strategy should be practical, outlining methods to address risks and achieve specific objectives. Key components of this resilience strategy, as dictated by Article 6(8) DORA, include:

  • Aligning the framework with the business strategy and objectives.
  • Establishing ICT risk tolerance levels in sync with the financial entity's risk appetite.
  • Setting clear information security objectives with measurable indicators.
  • Outlining the ICT reference architecture and necessary adaptations.
  • Detailing mechanisms for detecting, preventing, and protecting against ICT-related incidents.
  • Evidencing the effectiveness of digital operational resilience measures.
  • Implementing resilience testing and outlining a communication strategy for ICT-related incidents.

For large-scale organizations, a global multi-vendor strategy might be feasible, necessitating a detailed rationale and clear elucidation of dependencies on various suppliers.

Monitoring and Improving Digital Operational Resilience

  • Effective Strategy Monitoring: Article 13 of DORA mandates financial entities to continuously monitor the effectiveness of their digital operational resilience strategy. This involves tracking the evolution of ICT risks and analyzing the frequency, types, magnitude, and evolution of incidents, particularly cyber attacks.
  • Continuous Improvement: The resilience strategy should be improved continuously through lessons learned from various sources, including post-incident reviews, difficulties in activating business continuity plans, surveillance of cyber threats, and operational resilience tests. An annual report to the management body must encapsulate these findings and recommendations.

Data Protection and Resilience Mechanisms

  • Minimum Protection and Resilience Requirements: Article 9 DORA stipulates that the solutions and processes implemented must ensure the security of data transfer, minimize risks such as data corruption or loss, unauthorized access, and technical flaws. Additionally, they must ensure sound network and infrastructure management, including mechanisms to isolate affected information assets in case of cyberattacks.
  • Network Segmentation: The infrastructure must be designed to enable immediate disconnection or segmentation, particularly for interconnected financial processes, to prevent contagion.

Documentation of Policies

Financial entities are required to document various policies pursuant to Art 9 DORA, including:

  • Information Security Policy: Defining rules to protect the availability, authenticity, integrity, and confidentiality of assets and data.
  • Access Restriction Policies: Based on functions, roles, and missions.
  • Authentication and Encryption Policies: Including protocols for strong authentication mechanisms and encryption key protection.
  • ICT Change Management Policies: Focused on software, hardware, firmware components, systems, or security parameters. These should be risk-assessment-based and part of the overall change management process.
  • Patch and Update Policies: Comprehensive documentation for patches and updates is essential.

Detection Solutions Implementation

Financial entities must install effective detection solutions for anomalies, incidents, and cyberattacks. These solutions, as per Article 10 DORA, must include:

  • Multiple Layers of Control: With defined alert thresholds and criteria to trigger incident response processes.
  • Regular Testing: Ensuring the effectiveness of the detection mechanisms.

ICT Business Continuity Policy

As mandated by Article 11 DORA, financial entities must establish a comprehensive ICT business continuity policy. This policy should enable:

  • Continuity of Critical Functions: Ensuring the ongoing operation of critical or important functions.
  • Effective Incident Response: Quick and effective responses to ICT-related incidents, prioritizing resumption of activities and recovery actions.
  • Activation of Tailored Plans: Dedicated plans for each incident type to contain and prevent further damage.
  • Crisis Management: Including communication measures for internal teams, external stakeholders, and relevant authorities.

Testing and Record-Keeping

  • Regular Testing of Continuity Plans: These plans must be tested at least annually, after significant changes to ICT systems, and crisis communication plans.
  • Record-Keeping: In the event of a disruption, entities must keep accessible records of activities and provide estimates of costs and losses incurred by major incidents to competent authorities.

Backup, Restoration, and Recovery Procedures

Backup, restoration, and recovery procedures, crisis communication plans, and incident management processes are vital components for financial entities to maintain operational integrity in the face of digital disruptions.

  • Robust Backup Policies: Art. 12 DORA necessitates that financial entities establish comprehensive backup policies and procedures. These policies must delineate the scope of the data covered, the frequency of backups, and the minimum requirements based on data criticality and confidentiality.
  • Effective Restoration and Recovery: The act of activating a backup system must not compromise data security. Art. 12 DORA also mandates redundant ICT capacities to ensure continuity in case the primary system fails. In terms of restoration, segregation between backup systems and source systems is crucial.
  • Periodic Testing of Procedures: All backup, restoration, and recovery procedures must undergo regular testing to ensure their effectiveness and compliance with DORA's guidelines.

Crisis Communication Plans

  • Development of Communication Plans: Article 14 of DORA emphasizes the importance of having crisis communication plans for both internal and external stakeholders. These plans are essential for responsible disclosure of major ICT-related incidents or vulnerabilities.
  • Designation of a Crisis Communications Officer: Assigning a responsible individual for implementing the communication strategy during ICT-related incidents is a critical requirement of DORA.

Incident Management Process

  • Comprehensive Incident Management: Financial entities are required to implement an incident management process that is integrated with the ICT business continuity policy and resilience strategy. This process should encompass early warning indicators, procedures for incident identification, categorization, and response.
  • Incident Classification: Incidents must be classified based on criteria like client impact, duration, geographical spread, data losses, service criticality, and economic impact.
  • Mandatory Post-Incident Reviews: Following major incidents, organizations are required to conduct thorough reviews to assess the effectiveness of their response and make necessary adjustments.

Defining Major Incidents and Significant Cyber Threats

  • Major ICT-Related Incident: As defined in Article 3(10) of DORA, a major ICT-related incident is one that significantly impacts the network and information systems supporting critical or important functions of a financial entity.
  • Significant Cyber Threat: Article 3(13) DORA describes this as a cyber threat with technical characteristics indicating potential to result in a major ICT-related incident or a significant operational or security payment-related incident.

Drafting and Documenting an Incident Response Plan

Creating an Incident Response Plan (IRP): This is a foundational step in the incident management process. The IRP must be comprehensive and align with DORA's response obligations.

Understanding Response Obligations to Competent Authorities

  • Identifying the Competent Authority: The competent authority may vary for different financial entities, as outlined in Article 46 of DORA. Entities must determine their specific competent authority based on their operational jurisdiction and scope.
  • Dual Response Obligation: Under Article 19(1) DORA, states may impose a dual response obligation on financial entities, requiring them to report to both the competent authority under DORA and the CSIRT (Computer Security Incident Response Teams) designated under NIS2.

Managing Customer Communications During Incidents

  • Response Obligations to Customers: In the event of a major ICT-related incident impacting clients' financial interests, DORA requires entities to inform clients without undue delay, as per Article 19(3) DORA. This includes communication about the incident and mitigation measures taken.
  • Crisis Communication Plans: The implementation of effective crisis communication plans is essential for managing customer outreach and maintaining trust and transparency during incidents.

Monitoring Cyber Threats

Monitoring cyber threats, sharing cyber threat information, and conducting digital operational resilience testing are integral to ensuring a robust cybersecurity posture for financial entities.

  • Continuous and Collective Monitoring: Financial entities must maintain a vigilant and continuous monitoring of the cyber threat landscape, beyond just relying on resources like the annual OWASP (Open Web Application Security Project) Top 10. DORA, in Article 13, emphasizes the need for financial entities to have the capability to gather information on vulnerabilities and cyber threats and monitor technological developments.
  • Internal Intelligence Unit: Setting up an internal unit dedicated to cyber intelligence can be highly beneficial. This unit should consist of individuals knowledgeable in cyber topics and engage in regular sharing of findings.

Annual Report on Major Incidents in the Financial Sector

Article 22 DORA mandates the European Supervisory Authorities (ESAs) to publish an annual, anonymized, aggregated report on major ICT incidents in the financial sector. This report will provide vital statistics and insights for cyber intelligence in the financial sector.

Cyber Threat Information Sharing Among Financial Institutions

Mutual Assistance Encouraged by DORA: Chapter VI of DORA promotes the creation of arrangements among financial entities for sharing cyber threat information. This sharing should enhance digital operational resilience and occur within trusted communities, respecting business confidentiality and compliance with regulations like the GDPR.

Conducting Digital Operational Resilience Testing

  • Mapping Information Systems: Before performing resilience tests, a comprehensive mapping of the information system is essential. This allows for the classification of assets by criticality and risk level.
  • Annual Resilience Testing Program: As per Article 24(6) DORA, financial entities must conduct appropriate tests at least yearly on all ICT systems and applications supporting critical or important functions. The testing program should be risk-based and encompass various assessments and methodologies.
  • Types of Resilience Tests: Article 25 DORA outlines various test typologies, including vulnerability assessments, network security assessments, physical security reviews, source code reviews, and penetration testing. These tests can be performed in-house or by external vendors.
  • Vulnerability Operations Center (VOC): For entities opting for external service providers for security tests, options like Vulnerability Disclosure Programs (VDP), Pentest as a Service, and Bug Bounty programs are viable choices. These services must comply with DORA requirements.
  • Continuing our comprehensive exploration of the Digital Operational Resilience Act (DORA), we delve deeper into the realms of penetration testing as a service, bug bounty programs, vulnerability remediation, secure development methodologies, and threat-based penetration tests. These aspects are pivotal in fortifying the cybersecurity posture of financial entities.

Pentest as a Service

Digitization of Pentesting Activities: Emerging service providers offer penetration tests as a service, facilitating the digitization of penetration testing, offering real-time results and faster initiation compared to traditional methods. This approach streamlines the process, benefiting both internal red teams and external researchers. a red team constitutes a group that adopts the role of an adversary, conducting either a physical or digital incursion against a firm under the firm's own guidance. Subsequent to this infiltration attempt, the team relays its findings back to the organization. This process is designed to assist the organization in fortifying its defensive measures.

Bug Bounty Programs

Advanced Level Security Assessment: When traditional penetration tests reach their limits, Bug Bounty programs engage ethical hackers to test systems comprehensively. This approach follows a pay-per-result model, uncovering complex and high-risk vulnerabilities.

DORA: Obligation to Remediate All Discovered Vulnerabilities

  • Comprehensive Remediation: DORA mandates in its Art. 24(5) that all vulnerabilities discovered during testing must be addressed, including those classified as low or medium; exemptions apply for microenterprises. This requires close collaboration with development teams and CTOs.
  • Integration of Remediation into Schedules: Remediation should be a scheduled task for technical teams, not an afterthought. Regular remediation sessions like a weekly or monthly Bug Day may be effective in implementing this.

Encouraging Secure Development Methods

  • Cybersecurity by Design: Building security into products and services from inception is critical. This approach is advocated by both NIS2 and the EU Cybersecurity Act of June 2019 (Regulation (EU) 2019/881 n ENISA (the European Union Agency for Cybersecurity) and on information and communications technology cybersecurity certification).
  • Role of CISO in Promoting Secure Development: While a CISO may not directly train dev teams in secure practices, raising awareness and collaborating with SOC (Security Operations Center) teams and internal security experts may be beneficial.

Vulnerability Operations Center (VOC) for Collaborative Efforts

  • Breaking Down Barriers: VOCs aim to dissolve the traditional separation between development and security teams by bringing them and other teams together. It fosters a collaborative environment where vulnerability detection is a collective effort.

Planning Threat-Based Penetration Tests (TLPT)

  • Entities Subject to Advanced Security Testing: Competent authorities, as per Article 26(8) of DORA, are tasked with identifying financial entities required to perform TLPT. This is based on impact-related factors, financial stability concerns, and the ICT risk profile of the entity.
  • Nature of TLPT: Defined in Article 3(17), TLPT is a framework that mimics real-life threat actors' tactics, delivering a controlled, intelligence-led (red team) test of the financial entity’s critical live production systems.

Mandatory Criteria for Threat-Based Penetration Testing

  • Comprehensive Test Coverage: The test must cover several or all critical or important functions of the financial entity, as per Article 26 of DORA.
  • Scope and Approval: The scope is defined by the entity but requires approval from competent authorities. If third-party ICT services are included, the entity must ensure their participation, maintaining full responsibility.
  • Live Environment Testing: Testing must be conducted in live production environments, with a frequency of at least every three years, subject to adjustment based on the entity's risk profile.
  • Post-Test Requirements: After testing, a summary of findings, corrective action plans, and evidence of compliance with requirements must be submitted to the competent authorities.
  • 'Pooled Testing' for ICT Service Providers: Under certain conditions, an ICT service provider can conduct a pooled TLPT involving several financial entities, with the test directed by a designated entity.

TIBER-EU Framework for Operational Requirements

  • Guidelines for TLPT: DORA sets guidelines for threat-based penetration testing, while the TIBER-EU (Threat Intelligence-based Ethical Red Teaming) framework provides detailed operational requirements for the scope, methodologies, and phases of the test.
  • Implementation Across EU Countries: The TIBER-EU framework is being implemented in various EU countries, each with its adaptation, such as TIBER-DE (Germany), TIBER-AT (Austria) etc.
  • Future Developments: No certification agency currently exists in Europe for TIBER-EU test providers, but accreditations are expected to become clearer in the coming years.

Choosing an External Tester for TLPT

  • Internal vs. External Testers: Financial entities can use internal testers, but every third test must involve an external tester. Large credit institutions must always rely on external testers.
  • Tester Requirements: As outlined in Article 27 DORA, testers must meet high standards of suitability, technical capability, adherence to ethical frameworks, and have appropriate professional indemnity insurances.

Educating and Training on Cybersecurity

  • Importance of Training for All Levels: Training for cybersecurity is crucial for both executives and employees, as human error or negligence poses a significant risk.
  • Mandatory Training Under DORA: DORA mandates in its Art. 13(6) comprehensive digital operational resilience training for all employees and senior management staff, emphasizing the importance of ICT security awareness.
  • Role of CISO in Training Programs: The CISO, in conjunction with HR and division managers, should guide the selection and implementation of training programs, ensuring relevance and effectiveness.

Assess and Manage ICT Third-Party Risks

  • Emphasis on Supply Chain Security: Aligned with NIS2, DORA places significant emphasis on managing risks associated with ICT service providers. This involves both CISOs and legal departments, as many requirements influence the contractual aspects of collaborations.
  • ICT Third-Party Risk Strategy: Article 28(2) DORA mandates the creation and regular review of a strategy for managing ICT third-party risk. This includes policies on using services that support critical or important functions and regular reviews by the management body.
  • Maintenance of a Provider Register: Financial entities must maintain and update a register detailing all contractual arrangements with ICT third-party service providers, distinguishing those supporting critical functions.
  • Guidelines Before Contractual Agreements: Before entering into agreements with ICT service providers, entities must assess several factors, including risks related to the arrangement and due diligence on the provider, as outlined in Article 28(4) DORA.
  • Exit Strategies for Key Providers: As per Article 28(8) DORA, entities must have documented exit strategies for services supporting critical functions, including alternative solutions and transition plans.

Critical Providers and ESA Supervision

Identification by ESAs: The ESAs have the authority to declare certain ICT service providers as critical, subjecting them to a primary supervisor. This regulatory framework spans Articles 31 through 44 of DORA.

Preparing for DORA Implementation

  • Focus Areas for Compliance: Entities within the scope of DORA should prioritize the ICT risk management framework, digital operational resilience testing, and ICT third-party risks management.
  • Drafting and Implementation of Policies: The regulation necessitates a methodological approach to drafting and implementing mandatory policies. This includes a digital operational resilience strategy, an ICT business continuity policy, and incident management processes.
  • Security Testing Requirements: Entities must conduct digital operational resilience tests annually and, where applicable, threat-based penetration tests every three years in compliance with the TIBER-EU framework.
  • Managing Third-Party ICT Service Providers: This involves detailed management and documentation of the collaboration, from contractual obligations to exit strategies.

Source: Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector and amending Regulations (EC) No 1060/2009, (EU) No 648/2012, (EU) No 600/2014, (EU) No 909/2014 and (EU) 2016/1011 (Text with EEA relevance) aka DORA.

Executive Summary:

  • DORA's Legal Context: It is a specific law under the EU legislation, focusing on cybersecurity in the financial sector, and takes precedence over the general NIS2 Directive in relevant areas.
  • Purpose of DORA: To enhance digital operational resilience, ensuring the integrity and reliability of financial services, particularly during cyber disruptions.
  • Implementation Timeline: DORA will become effective from January 17, 2025, with draft regulatory technical standards expected by early 2024.
  • Sanctioning Framework: DORA allows member states to determine appropriate sanctions for non-compliance, which can include financial penalties.
  • Action Plan for Compliance: A detailed checklist provides a structured approach for entities to prepare for DORA compliance.
  • DORA's Wide Reach: Affects a broad spectrum of financial entities, emphasizing the EU's commitment to digital resilience.
  • Specific Exemptions: Understanding exemptions is crucial for entities to determine their compliance requirements.
  • Member States' Discretionary Power: National regulatory contexts play a significant role in the application of DORA.
  • Comprehensive ICT Risk Management: DORA mandates a robust framework for managing ICT risks as part of the overall risk management system.
  • Incident Reporting and Resilience Testing: Mandatory reporting of ICT-related incidents and regular testing of digital operational resilience are crucial.
  • Ongoing Framework Updates: The ICT risk management framework must be periodically updated to remain effective and compliant.
  • DORA's Strategic Requirements: Outlines specific areas of focus for financial entities to enhance their digital operational resilience.
  • ICT Risk Management Framework: A central aspect of DORA, requiring a comprehensive approach to managing ICT risks.
  • Dynamic Framework Maintenance: Necessitates regular updates and reviews to ensure continual compliance and resilience.
  • Strategic Implementation of ISMS: Aligning with international standards like ISO 27001 is pivotal for effective risk management under DORA.
  • Eligibility for Simplified Framework: Understanding which entities qualify for the simplified framework is crucial.
  • Effective Risk Governance: Adopting the 3LoD model ensures a structured approach to risk governance.
  • Outsourcing Dynamics: Financial entities must understand the implications of outsourcing on their compliance responsibilities.
  • Resilience Strategy Essentials: Developing a strategy that encompasses all facets of digital operational resilience is imperative.
  • Strategic Monitoring for Digital Resilience: Continuous evaluation and improvement of resilience strategies.
  • Minimum Standards for Asset Protection: Adhering to DORA's requirements to safeguard data and infrastructure.
  • Necessity of Effective Detection Solutions: Implementing advanced detection capabilities.
  • Business Continuity as a Priority: Establishing and testing robust business continuity plans.
  • Importance of Documentation and Testing: Maintaining comprehensive records and conducting regular tests.
  • Establishing Comprehensive Backup and Recovery Procedures: Essential for minimizing disruptions and maintaining data integrity.
  • Developing and Implementing Crisis Communication Plans: Critical for managing external and internal communications during incidents.
  • Incident Management and Classification: Necessary for timely identification, response, and mitigation of ICT-related incidents.
  • Robust Backup and Recovery Policies: Ensuring data protection and system redundancy.
  • Effective Crisis Communication: Assigning responsibilities and developing plans for incident-related communications.
  • Incident Management and Post-Incident Analysis: Establishing processes for incident management and conducting post-incident reviews to improve future responses.
  • Defining Major Incidents and Cyber Threats: Essential for understanding the scope and impact of incidents under DORA.
  • Drafting an Effective IRP: A critical component of incident management, ensuring preparedness and compliance.
  • Navigating Response Obligations: Understanding the specific requirements for reporting to competent authorities.
  • Effective Customer Communication: Managing communications with clients in the event of major incidents is crucial for maintaining client trust and adherence to DORA's mandates.
  • Major Incident and Cyber Threat Definitions: Clarity on these definitions guides entities in recognizing and responding to significant events.
  • IRP Development: Ensuring that the IRP is comprehensive and in line with DORA's requirements.
  • Competent Authority Response Obligations: Identifying and understanding the entity's obligations towards different regulatory bodies.
  • Customer Communication During Incidents: Proactively managing communications with customers during major incidents or cyber threats.
  • Robust Cyber Threat Monitoring: Essential for staying ahead of evolving cyber threats.
  • Importance of Information Sharing: Sharing cyber threat intelligence among financial institutions can significantly enhance collective digital resilience.
  • Mandatory Resilience Testing: Regular testing of digital operational resilience is a core requirement under DORA.
  • Continuous Cyber Threat Monitoring: Establishing mechanisms for ongoing vigilance against cyber threats.
  • Annual ESAs Report: Utilizing the ESAs' annual report as a key resource for cyber intelligence.
  • Collaborative Information Sharing: Fostering trusted networks for sharing cyber threat information.
  • Comprehensive Resilience Testing: Implementing a detailed testing program to ensure the resilience of critical ICT systems.
  • Efficiency of Pentest as a Service: Streamlining penetration testing processes for enhanced efficiency.
  • Effectiveness of Bug Bounty Programs: Engaging ethical hackers for comprehensive system testing.
  • Mandatory Vulnerability Remediation: Ensuring all detected vulnerabilities are addressed in compliance with DORA.
  • Promotion of Secure Development Practices: Integrating cybersecurity from the initial stages of product and service development.
  • Collaborative Approach in SOC/VOC: Bridging the gap between development and security teams for better vulnerability management.
  • Digitized Penetration Testing: Offering efficient and effective penetration testing services.
  • Advanced Security Assessments Through Bug Bounty: Utilizing ethical hackers to discover complex vulnerabilities.
  • Comprehensive Approach to Vulnerability Remediation: Prioritizing the remediation of all vulnerabilities.
  • Encouraging Cybersecurity by Design: Advocating for secure development methodologies.
  • TLPT for Enhanced Security Testing: Implementing threat-based penetration tests for entities with a significant impact on the financial sector.
  • Rigorous TLPT Criteria: Adhering to DORA's specified criteria for thorough and effective threat-based penetration testing.
  • Operational Guidelines by TIBER-EU: Leveraging the TIBER-EU framework for detailed operational requirements in penetration testing.
  • Choosing Qualified External Testers: Ensuring that external testers meet the high standards set by DORA.
  • Cybersecurity Training for All: Emphasizing the necessity of comprehensive cybersecurity training across all levels of the organization.
  • Comprehensive Coverage in TLPT: Ensuring that penetration tests cover critical functions and are approved by competent authorities.
  • Adherence to TIBER-EU Framework: Utilizing this framework for operational guidance in conducting TLPT.
  • Importance of Educating Staff in Cybersecurity: Implementing mandatory training programs to enhance the overall cybersecurity posture of the entity.
  • Robust Management of ICT Third-Party Risks: Emphasizing the significance of managing risks related to ICT service providers.
  • Strategic Approach to Risk Management: The necessity of developing a comprehensive strategy for managing ICT third-party risk.
  • Comprehensive Record Keeping and Contractual Guidelines: Maintaining detailed records of contractual arrangements and following strict guidelines before entering into agreements.
  • Prioritization of ICT Third-Party Risk Management: Focusing on supply chain security and risk management strategies.
  • Focus on Security Testing and Third-Party Management: Ensuring regular testing and thorough management of third-party service providers.