How DORA will impact incident management at financial entities

The Digital Finance Strategy is a European directive that aims to support and develop digital finance in Europe whilst maintaining financial stability and consumer protection. There are three main components to the package:

1. Digital Operational Resilience Act (DORA)
2. Markets in Crypto-assets (MiCA) Regulation
3. A proposal on Distributed Ledger Technology (DLT)

In this blog post, we’ll attempt to summarise the 113-page DORA proposal, highlighting how it will apply to incident management at financial entities.

Side note: we also wrote a blog post about the other DORA, also known as the DevOps Research and Assessments.

What is DORA?

The proposed Digital Operational Resilience Act (DORA) was published by the European Commission to address the ever-increasing information and communications technology (ICT) risks inherent in the financial services sector. It aims to mitigate risks by enforcing a framework for operational resilience. More specifically, DORA aims to:

1. Introduce better ICT risk management and governance
2. Improve incident reporting (and information sharing)
3. Ensure strategies exist for managing ICT third-party risk
4. Implement "resilience" assessments (e.g. tests, methodologies, tools)

To frame why this is important, the European Commission estimates the cost of incidents in the EU financial sector to be up to €27 billion per year.

Will this apply to me?

The answer is likely yes if you operate in the financial services sector.

DORA will apply to various financial entities, including credit institutions, electronic money institutions, investment firms, insurance undertakings and reinsurance undertakings.

It will also apply to firms operating in the financial services that fall under "critical ICT third-party service providers" (e.g. cloud resources, data analytics, and audit).

DORA is expected to be published at the end of 2022, although no confirmed date exists.

Impact on incident management

Let’s dive into the two key chapters (Chapter 2 and 3) from the proposal and break down what they mean in the context of incident management.

ICT risk management

Chapter 2 details changes to ICT risk management processes. In summary, it asks financial institutions to:

• Increase the involvement of senior management in ICT-related incidents
• Identify business functions that are potential sources of ICT-related incidents
• Implement strategies and policies to ensure adequate protection of ICT systems
• Establish measures to bring ICT systems back online
• Communicate ICT-related incidents to clients, financial entities, and the public

The most relevant article (Article 10) clearly defines the proposed response and recovery requirements. More specifically, it highlights the importance of recording, responding, and communicating all incidents within the organization.

These core principles extend beyond responding to an incident and include frameworks for the post-incident learning process (such as post-mortems). The motivation is that with an increased focus on analysing root causes, financial entities will reduce the likelihood and severity of similar incidents going forwards.

Finally, DORA sets the expectation that senior management is involved with incident management. They will be required to report on incidents every year. In other words, the proposal highlights the need for accessible tooling for the entire organization (and not just SREs), allowing more parties to participate in the response process.

ICT-related incidents - management, classification and reporting

Chapter 3 gives tactical information on how the incident response process should be structured and covers topics such as classification and reporting. It details how financial intuitions should:

• Establish and apply incident management processes to identify, track, log, and categorise incidents
• Ensure incidents are classified according to shared criteria
• Report major ICT-related incidents to the competent authority using a harmonised report framework

The most important article in this chapter (Article 15) outlines the critical functions of the incident management process, building on the high-level framework in Chapter 2. Essential requirements include priority and severity, role assignment, and communication plans.

More specifically, DORA asks for very detailed information for the classification of incidents. The criteria heavily focus on capturing the impact (number of customers, financial implications) and severity.

There is an increased requirement for reporting incidents. Not only should this happen within incident teams, but incidents that fall under specific criteria should be reported to the relevant authority. There will be a standardised format for these reports, which aims to decrease administrative overheads (for the competent authority) whilst increasing cross-entity learnings by capturing and analysing common themes.

What happens if I'm not compliant?

The repercussions of not complying with the proposed changes are significant. At the extreme, this can result in temporary or permanent cessation of any practice or conduct that the authority considers necessary to prevent a repetition of the incident. Competent authorities will have supervisory, investigatory, and sanctioning powers.

For third-party ICT suppliers, DORA states that it could impose a non-compliance fine of up to 1% of daily worldwide turnover for no more than six months.

How can we help?

incident.io is a tool for managing all of your incidents. It's designed to be used across business functions. An incident can be quickly declared (by anyone, not just those with specialist knowledge!), decreasing the chance that things go unnoticed. incident.io encodes best practices into your communication tools, allowing you to keep internal parties updated via Slack and external parties updated via integrations with shortcuts to tools such as Statuspage (and more). You can also track actions and follow-ups as you're responding to ensure nothing gets missed.

Several features are particularly applicable to the DORA proposal:

• Insights let you explore incident data in several ways: a dashboard in your browser, a data export, or via a live API connection. By capturing this information in a single database, it's easier to analyse changes over time.
• Decision Flows allow you to encode Q&A flows into your incident response process. An incident responder can answer questions like “how many customers does this impact”, “what is the expected financial impact of this incident”, or any other necessary details and be told who they need to report to or other due diligence that may be necessary to comply with regulations.
• Workflows give you the ability to automate common processes based on specific triggers. Ship an email to a regulator when an incident is triggered, get reminded to share an intermediate report when an incident reaches are certain status or get a gentle nudge to write your post-mortem when the incident is closed - all possible with Workflows!
• Post-mortems can be created in 2-clicks, customised to include valuable information from the incident channel, and configured to match your required reporting formats.

Conclusion

DORA will significantly change how financial services are required to operate their incident management processes. From asking senior management to be more involved to ensuring that a plan exists for mitigating and responding to ICT-related incidents, DORA toughens the requirements for how financial entities must respond when things go wrong. More specifically, the ask is to supercharge processes for identifying, tracking, logging, categorising, and reporting incidents to the relevant regulators.

At incident.io, we believe in operational excellence and organizational resilience. These changes allow many financial organizations to review and improve their existing procedures, and we're here to help!

What next?

If you’re keen to discuss DORA in more detail, reach out to charlie@incident.io.