DORA or NIS2?

The NIS2 framework has been covered in several other articles, so we will start by explaining the DORA framework in brief.

DORA

The Digital Operational Resilience Act (DORA) specifically targets the financial sector, addressing the need for robust ICT risk management.?

The DORA framework is regulated by Regulation 2022/2554 by the EU.

In the case of both DORA and NIS2 the general feeling of rules and regulations as roadblocks does not hold true.

These frameworks are the guidelines for safety. If you are not compliant you are essentially not safe.?

You can use both frameworks as a stepping stone for added value in your business instead as an obstacle for your operation.

The 5 pillars can be elaborated as follows:

1 - Risk management: It is the aim of the DORA-regulation that financial entities should have a robust, well-documented ICT risk management framework in order to ensure digital operational resilience.

The business continuity policies and disaster recovery plans must specifically address cyber security, and they also need to consider the key functions that have been outsourced or are delivered through arrangements with ICT third-party service providers.

2 - Incident reporting: ?The DORA regulation foresees a harmonization of reporting under different frameworks such as GDPR, NIS2, e-IDAS, SSM, PSD2, etc. There are no concrete guidelines in the regulation yet, however the vision is to centralize the reporting of major ICT-related incidents to set up a single EU hub for major ICT-related incident reporting by financial entities. Here the guidelines for NIS2 can be used as a starting point.

3 - Digital operational resilience testing: Financial entities should regularly do? comprehensive digital operational resilience testing. The aim is at least annually. The DORA regulation also has a specific provision requiring that the company ensures the inclusion of ICT third-party providers in their testing. Threat-led penetration testing is to be undertaken at least every three years.

4 - ICT third-party risk: In the DORA regulation the management of ICT third-party risk is an integral component of the ICT risk management framework. DORA requires that critical ICT third-party providers should be under supervision of the European supervisory authorities that oversee the financial industry. So the financial entity should ensure that not only are third-party providers assessed in relation to cyber security, but that the critical third-party providers actually also comply with DORA.

5 - Information sharing: DORA includes sharing of cyberthreats to collectively learn from incidents. Voluntary information sharing should take place through information-sharing arrangements in trusted communities. Financial entities will be asked to notify their competent authorities of their participation in such information-sharing arrangements, so that the supervisory authorities can ensure a proper balance between cybersecurity and privacy protection.

The Difference Between NIS2 and DORA

While both NIS2 and DORA aim to enhance cybersecurity, their scopes and application differ.?

NIS2 has a broader sectoral coverage, imposing cybersecurity measures across various critical sectors.?

DORA, however, is specifically tailored for the financial sector, with a concentrated focus on ICT risks.?

NIS2 sets a baseline for cybersecurity across multiple sectors, while DORA provides a targeted approach for financial entities, offering a more detailed set of rules.

For the Financial Sector in general both frameworks will simultaneously apply, so most financial institutions will have to adhere to both NIS2 and DORA.

The European Commission guidelines clarify when to use DORA and NIS2. Where sector-specific rules like DORA exist, and are at least equivalent or more stringent than NIS2, DORA's provisions take precedence.?

For entities in the financial sector, DORA is the primary regulatory framework, however supplemented by NIS2 where DORA is less stringent.

Assessing your maturity to DORA and NIS2 using a Compliance Assessment Tool

In effect what you need to do to be compliant in both frameworks is to assess the maturity of your current cyber security environment, and then identify the gaps in relation to the regulation.?

Then you need to decide on actions to become compliant. You then need to implement these and document what you have done all the way.

QCA’s compliance Assessment Tool helps you to do the gap-analysis, which you should do regularly.?

The tool will help you make an audit-trail which shows your actions and the maturity status over time. This will document your work before the authorities, and that you have addressed your weaknesses consistently over time.?

This repetitive gap-analysis, in other words, will document your compliance, when you face an audit from the regulators; whether this is an unannounced audit or an audit following a cyber incident, you will be prepared.

?

In addition you will be able to tailor the tools to your incident reporting needs, which is a good idea to do well in advance of an actual cyber attack, as the requirements for reporting come with extremely short deadlines. Not reporting is also a violation of compliance with the two frameworks.

Further information?

If you want to know more about DORA or NIS2 and how to assess your cyber security resilience then do not hesitate to contact QCA:

https://quantumcyberanalytics.com/

You can also see below for 49 areas to cover in the DORA framework.

Some areas to consider under DORA

The following list is not exhaustive, however it will give you an idea of the areas that at least need to be covered besides a good Risk Management framework.

The 49 generic areas to consider with a reference to the article in the DORA framework:

1 - Establish a regular backup schedule for critical data

Article 12 - Backup policies and procedures, restoration and recovery procedures and methods

2 - Store backups in multiple locations (offsite and/or cloud-based storage)

Article 12 - Backup policies and procedures, restoration and recovery procedures and methods

3 - Implement a versioning system to track and restore previous versions of data

Article 12 - Backup policies and procedures, restoration and recovery procedures and methods

4 - Encrypt backups to protect sensitive data

Article 9 - Protection and prevention

5 - Test backup and recovery processes periodically to ensure data integrity

Article 25 - Testing of ICT tools and systems

6 - Implement redundant network connections to prevent single points of failure

Article 7 - ICT systems, protocols and tools

7 - Use load balancers to distribute traffic evenly across resources

Article 7 - ICT systems, protocols and tools

8 - Employ network failover solutions (e.g., redundant routers, switches)

Article 7 - ICT systems, protocols and tools

9 - Monitor network performance and latency to detect potential issues

Article 10 - Detection

10 - Test network redundancy and failover processes to ensure proper functioning

Article 25 - Testing of ICT tools and systems

11 - Implement a Monitoring System to Track the Health and Performance of Cloud Infrastructure

Article 10 - Detection

12 - Set Up Alerts for Critical Events and Performance Thresholds

Article 10 - Detection

13 - Monitor Resource Usage to Identify Potential Bottlenecks and Capacity Issues

Article 10 - Detection

14 - Establish a Centralized Logging System to Collect and Analyze Logs from Various Components

Article 13 - Learning and evolving

15 - Regularly Review Monitoring Data to Identify Trends and Improve Infrastructure Resilience

Article 13 - Learning and evolving

16 - Develop a formal incident response plan, including roles and responsibilities

Article 11 - Response and recovery

17 - Establish a communication plan for internal and external stakeholders during incidents

Article 14 - Communication

18 - Perform regular incident response drills to test and refine the plan

Article 11 - Response and recovery

19 - Document lessons learned from incidents and update the incident response plan accordingly

Article 13 - Learning and evolving

20 - Provide training for staff on incident response processes and best practices

Article 13 - Learning and evolving

21 - Regularly assess infrastructure capacity and plan for growth

Article 9 - Protection and prevention

22 - Implement auto-scaling strategies to handle fluctuating workloads

Article 9 - Protection and prevention

23 - Use load testing to identify capacity limits and potential bottlenecks

Article 9 - Protection and prevention

24 - Monitor resource usage to anticipate and address potential capacity issues

Article 9 - Protection and prevention

25 - Review and update capacity plans based on changing business requirements and growth

Article 9 - Protection and prevention

26 - Implement strong authentication and authorization mechanisms

Article 9 - Protection and prevention

27 - Regularly review and update user access permissions

Article 9 - Protection and prevention

28 - Apply security patches and updates promptly

Article 7 - ICT systems, protocols and tools

29 - Conduct regular vulnerability assessments and penetration testing

Article 25 - Testing of ICT tools and systems

30 - Design applications to be stateless and horizontally scalable

Article 7 - ICT systems, protocols and tools

31 - Implement circuit breakers and retries to handle transient faults

Article 7 - ICT systems, protocols and tools

32 - Use health checks and load balancing to distribute traffic among instances

Article 7 - ICT systems, protocols and tools

33 - Isolate application components to limit the impact of failures

Article 7 - ICT systems, protocols and tools

34 - Monitor application performance and error rates to identify potential issues

Article 10 - Detection

35 - Deploy infrastructure across multiple data centers or availability zones

Article 12 - Backup policies and procedures, restoration and recovery procedures and methods

36 - Use geo-replication to store data redundantly across different regions

Article 12 - Backup policies and procedures, restoration and recovery procedures and methods

37 - Implement global load balancing to distribute traffic across data centers

Article 7 - ICT systems, protocols and tools

38 - Test failover processes between data centers to ensure smooth recovery

Article 25 - Testing of ICT tools and systems

39 - Regularly review and update data center redundancy strategies based on evolving needs

Article 13 - Learning and evolving

40 - Conduct regular disaster recovery and failover tests

Article 25 - Testing of ICT tools and systems

41 - Use chaos engineering techniques to simulate failures and test system resilience

Article 25 - Testing of ICT tools and systems

42 - Test backup and recovery processes to validate data integrity

Article 12 - Backup policies and procedures, restoration and recovery procedures and methods

43 - Perform load and stress tests to identify capacity limits and potential bottlenecks

Article 25 - Testing of ICT tools and systems

44 - Use the results of testing to inform updates and improvements to infrastructure resilience

Article 13 - Learning and evolving

45 - Document architecture, processes, and best practices for cloud resilience

Article 13 - Learning and evolving

46 - Maintain a centralized knowledge base for easy access to documentation

Article 13 - Learning and evolving

47 - Regularly review and update documentation to reflect changes and improvements

Article 13 - Learning and evolving

48 - Encourage knowledge sharing and collaboration among team members

Article 13 - Learning and evolving

49 - Provide training and resources to help staff stay informed about resilience

Article 13 - Learning and evolving

Learn more at:

https://quantumcyberanalytics.com/