Is ISO 27001 enough for DORA?

If you’re a CISO, DPO or cybersecurity expert, you can’t escape NIS2 (Network and Information Security 2) and DORA (Digital Operational Resilience Act), two major pieces of European Union cybersecurity legislation. 

Although DORA prevails over NIS2, the latter also targets banks and financial market infrastructure.    DORA prevails over NIS2, however, that does NOT mean that NIS2 does not apply to companies that are targeted by both.   DORA prevails in the areas of overlap, however, when it comes to areas of NIS2 that are not covered by DORA (for example Article 21 I. on Human Resources Security, or Article 21 J. on the use of MFA and encryption) NIS2 also applies to financial entities. 

This article explains the differences and overlaps between DORA and NIS2 and how ISO 27001, the main cybersecurity standard, makes a company compliant with DORA (and the non-overlapping parts of NIS2).

If you are interested in NIS2, see our article on NIS2 and ISO 27001.

DORA vs NIS

Directive vs regulation

NIS2 is a directive, whereas the DORA is a regulation.    A directive provides guidance for member states, who transposed into the national law for their country.  This process leaves room for interpretation and, to some extent, flexibility for the member states.   A regulation, on the other hand, applies unchanged in all member states as soon as it comes into force. It is a binding legislative act, and must be enforced in its entirety.

Dora however leaves room for member states to further refine the regulation, for example in the field of administrative and criminal sanctions. 

Effective dates

The DORA regulation will be applicable as it stands in all EU countries from its entry into force, scheduled for January 17, 2025 (24 months after its publication in the Official Journal of the EU). This date is clearly stated in Article 64 of DORA.   

The NIS2 Directive was published in the EU Official Journal on December 27, 2022, and member states have 21 months from that date to transpose it into national law, i.e., by October 2024.   It is generally assumed that there will be a transition or “grace” period of 12 to 24 months. 
 

Financial vs essential/important industries

DORA applies to 21 types of financial services providers referred to in Article 2.   These are: 

• Traditional organizations (banks, credit institutions, investment firms, insurance companies)
• More recent types of financial companies (payment organizations, e-money companies, crowdfunding platforms, (financial) data reporting companies, securitization repositories ).
• Intermediaries (of insurance products)
• ICT providers to the above types of companies

“Very small enterprises”, financial entities that employ fewer than ten persons and whose annual turnover and/or balance sheet total does not exceed EUR 2 million, are exempted.  For intermediaries, the exception is more extensive: companies with less than 250 employees or a turnover less than EUR 50 € million or a balance sheet of less than EUR 43 million are exempt.  

Although DORA prevails over NIS2 (refer to this article to understand which companies NIS2 applies to), the latter also targets banks and financial market infrastructure companies without much detail, to target types of companies that are not explicitly targeted by DORA.   Importantly, the fact that DORA prevails does NOT mean that NIS2 does not apply to companies that are targeted by both.   DORA prevails in the areas of overlap, however, when it comes to areas of NIS2 that are not covered by DORA (for example Article 21 I. on Human Resources Security, or Article 21 J. on the use of MFA and encryption) NIS2 also applies to financial entities. 

Sanctions

The DORA law provides for heavy financial penalties in the event of infringement. The regulation itself does not specify the penalty, it leaves it up to the national authorities.  The sanctions (both financial and criminal) should be “appropriate” and “proportional”.  Up to this date, in most EU countries, the penalty structure has not been decided yet. For reference, financial penalties associated with non-compliance with the General Data Protection Regulation (GDPR) can reach €20.000.000 in most severe cases or 4% of the total global turnover.

Critical third-party ICT service providers, who supply services to financial entities, could be fined up to 1% of their annual worldwide turnover if they are responsible for the non-compliance of their customers with the strict DORA standards.

Penalties under NIS2 are similar, with fines of up to 1% ("important" entities) or 2% ("essential" entities) of annual turnover.    This is one of the few differences between important and essential entities under NIS2.

Both under NIS2 and DORA, individuals and members of the management team of companies subject to NIS2/DORA may face criminal prosecution in case of negligence.  Penalties in this case must be determined by a judge.

Objectives

In several articles and blog posts, experts have expressed the differences between DORA and NIS 2.  The articles state that both have different objectives. NIS 2 focuses on the "harmonization of cybersecurity defence in the EU", while DORA primarily targets "resilience against cybersecurity attacks".    

And there are indeed some important differences between both: 

• Under DORA, incidents should be reported within four hours of classification or no later than 24 hours after detection. Under NIS send an early warning to the competent CSIRT, within 24 hours of learning about a significant incident, and should send a notification about the incident to the competent CSIRT, within 72 hours of learning about a significant incident.   The reporting requirement under DORA is thus more stringent.
• Under DORA, financial entities must inform their customers of incidents and significant cybersecurity threats, whereas NIS2 doesn’t required companies to report incidents to their customers.
• DORA is far more demanding when it comes to security testing: a resilience testing program at least once a year, and a threat-led penetration test at least every 3 years. NIS-2 requires security audits every two years.

However, we believe that DORA and NIS2 have more in common than differences, which translates into very similar processes, tools and procedures to be put in place to ensure compliance.   After all, better defence results in greater resilience.
 

DORA requirements and NIS2 overlap

These are the 5 pillars of the DORA regulation and their NIS2 equivalents:
 

1/ Information and Communication Technology (ICT) risk management

DORA requires senior management to take responsibility for ICT risk management, identify critical functions and establish a risk management framework based on international standards. This management framework must be reviewed annually.

→ NIS2 Article 20 requires management bodies of essential and important entities to approve cybersecurity risk-management measures taken and oversee its implementation.
→ NIS2 Article 21 (A) requires companies to define Policies on risk analysis and information system security.

This framework should include a cyber resilience strategy, regular audits to identify deficiencies, and cyber security training. All company employees, including members of management, should receive cybersecurity training appropriate to their position and responsibility.

→ NIS2 Article 21 (G) requires companies to implement Basic cyber hygiene practices and training for their employees.
 

2/ Reporting information and communication technology incidents

The DORA regulation requires financial entities to redact and transmit reports on information and communication technology incidents. The directive aims to harmonize incident detection and reporting across Europe.  

 → Similarly, article 23 of the NIS2 directive requires companies to report incidents to the competent authorities.

As mentioned above, reporting times for companies subject to DORA are more stringent.
 

 3/ Digital operational resilience tests

Financial institutions should conduct digital infrastructure resilience and vulnerability tests at least once a year, conducted by independent parties. These tests are designed to assess the targeted companies' ability to manage incidents and identify system weaknesses, using a risk-based approach.  Before implementing new services or upgrading existing services supporting their critical functions, vulnerability assessments are required to ensure the operational resilience of IT systems.

→ NIS  Article 21 (C). Organizations must plan for how they intend to ensure business continuity in the case of major cyber incidents. This plan should include considerations about system recovery, emergency procedures, and setting up a crisis response team.

→ NIS2 Article 21 (E). Requires companies to implement security assessments in network acquisition, development, and maintenance.

→ NIS2 Article 21 (F). Mandates businesses to implement policies and procedures to assess the effectiveness of the security measures implemented.

 4/ Third-party risk management

DORA extends obligations concerning the outsourcing of ICT services to third-party suppliers, requiring financial entities to manage the risks associated with these suppliers. They must assess contractual risks, terminate contracts with suppliers presenting cybersecurity risks, and produce an annual report on ICT agreements. The DORA regulation defines key principles for managing the risks associated with ICT suppliers.

→  NIS2 Article 21 (D) requires companies to implement supply chain risk management.  
While NIS2 emphasises the security aspect of third-party risk management and DORA focuses on overall risk management, the end goal of NIS2 is the same as DORA: to ensure business continuity of targeted businesses.

5/ Sharing information and intelligence

DORA encourages financial institutions to share information on cyber threats to reduce ICT-related risks. The regulation authorizes financial entities to establish information-sharing agreements while guaranteeing the protection of personal data.

→  NIS2 Article 29 mandates member states to ensure that the exchange of information on threats and incidents takes place within communities of essential and important entities, and where relevant, their suppliers or service providers.

DORA to ISO 27001 mapping

As with NIS2, ISO 27001 and its supporting Information Security Management System (ISMS) gives organizations the structure and building blocks to comply with DORA.    However, ISO 27001 certification is not a blank cheque for DORA compliance - it all boils down to how you implement the ISO standard.

The below table provides a mapping between DORA requirements and the non-overlapping NIS2  requirements, and ISO 27001:2022 (and ISO 27002:2022) controls.

We have to stress that not all DORA requirements are (fully) covered by ISO 27001/27002, so controls will have to be added or edited.

For companies subject to DORA, the following NIS2 requirements apply: 

Recommendations

Don’t forget ISO 27002

The ISO 27002 standard is a detailed supplementary guide to the security controls in the ISO 27001 framework.  ISO 27002 provides best-practices guidance on selecting and implementing the controls listed in ISO 27001, however, ISO 27002 controls (94 controls in the 2022 standard) aren’t compulsory to become 27001 certified. They are, at best, a reference set of information security controls that organizations can use.  Also, companies can only certify for ISO 27001, not for ISO 27002.

As shown in the above table, many ISO 27002 controls map to DORA requirements.  As such, while not required for obtaining the ISO 27001 certificate, (most of) ISO 27002 is mandatory for DORA compliance.

Business continuity is DORA’s objective, so ISO 22301 is a must

Under DORA, targeted financial entities must ensure continuity of operations in the event of an incident (which may be an incident other than a cyberattack or an incident at a critical supplier). Organizations must therefore implement a comprehensive resilience framework - which includes business continuity, disaster recovery and crisis management - to minimize disruptions.

If organizations have carefully implemented the above ISO27001 and ISO27002 controls related to business continuity and disaster recovery (5.29 and 5.30 as core), they could comply with DORA in this area.  However, organizations covered by DORA should consider adding ISO 22301 for business continuity management (BCM) of their critical functions. ISO 22301 is designed to help implement, maintain, and continuously improve business continuity processes for companies or specific business functions.  While some aspects of ISO 27001 include business continuity management, they do not define a process for implementing and maintaining BCM.  That's where the complementary standard ISO 22301 comes in.  Certification to this standard will contribute to compliance with DORA.

ISO 27036 provides a framework for Supply chain risk management 

In the context of DORA, it's not just important to pay attention to cybersecurity resilience throughout the supply chain.  Any threats to business continuity that could potentially spread throughout the supply chain need to be identified and mitigated. Consequently, the content of risk assessments can be revised to place greater emphasis on the business continuity measures implemented at the supplier.  The list of suppliers covered by third-party risk management can also be revised because, while ISO 27001 focuses more on the ICT supply chain, DORA's emphasis on general business continuity may require you to expand the list of suppliers assessed to non-ICT suppliers.  Obviously, the security of potential IT integrations (e.g. APIs) with these suppliers also needs to be considered.

ISO 27036 for supply chain risk management is a bit like ISO 22301 for business continuity. ISO 27001 does not define a process for implementing third-party risk. This is where ISO 27036 can help companies who have no experience/expertise in this area, or who want to use the standard to structure the activity.  ISO 27036 is not in itself mandatory for DORA compliance, but it will provide additional assurance.

Incident notification and communication is a major area of work

Cybercriminals operate across national borders. Consequently, DORA aims to improve cooperation and information sharing on cyber incidents across the European Union. As a result, there is an obligation to immediately report significant incidents to the competent authorities within the timeframes specified at the “Single EU Hub for the notification by financial entities of major ICT incidents” (as opposed to “as determined by individual member states” in the NIS2).  But that's not all.   Articles 16 to 23 of the DORA regulation detail the requirements for reporting incidents and notifying customers, stakeholders, company management and other financial entities.

The reporting describes the prescribed lead times for such reports:

• First report within 4 hours after classification, and maximum within 24 hours after discovery.   
• Intermediate report within 72 hours. 
• Full report within a month after notification.

This requirement has far-reaching implications and is only marginally covered by the ISO 27001/27002 standards.  For organizations subject to the GDPR, the implementation of Annex A 5.24 (Information Security Incident Management Planning and Preparation) requires notification procedures to be in place to report data breaches to authorities within 72 hours.  However, DORA (and NIS2) aims to report any security incident that poses a threat to business continuity within 24 hours. To report properly, companies must first have adequate detection, including initial analysis and forensics, and incident response.  Also, "military-style" internal reporting and decision-making processes must be in place to meet the 24-hour deadline.  These processes must not only be defined but they must also be tested to ensure they work as they should.

How Ceeyu can assist with DORA compliance

Ceeyu’s SaaS platform scans your network and the networks of a companies in the supply chain using automated active and passive scanning techniques like those hackers use, in search for software vulnerabilities and network weaknesses.  

Because not all security risks can be identified in an automated manner, Ceeyu also offers the possibility to carry out digital questionnaire-based audits.  This can be done by creating questionnaires tailored to the supplier, from a white sheet or starting from templates that Ceeyu makes available.  The completion of the questionnaire by the supplier and the follow-up of the process by the customer is done in a secure environment on the same SaaS platform. This enables a simple, central follow-up, entirely online and without the intervention of third parties. The closed platform guarantees the confidentiality of the survey, since only authorized persons have access to the application.    

In short, Ceeyu's SaaS platform automates third-party risk management and extends its scope, with a maximum focus on cost reduction and ease-of-use.

As such, Ceeyu contributes to fulfilling a considerable part of the requirements in Articles 28 to 44  of the DORA  regulation.