Safeguard
Compliance•

DORA: what is it and who needs to comply?

DORA is the EU regulation on digital operational resilience for financial entities, applying since 17 January 2025. What it covers and a first plan.

Safeguard Security Team
4 min read

DORA, the Digital Operational Resilience Act, is an EU regulation that sets common rules on ICT risk for financial entities. It entered into force on 16 January 2023 and has applied since 17 January 2025. Financial entities in scope must comply, and their critical ICT suppliers come under oversight.

This is an explainer, not legal advice. Safeguard holds no DORA certification, and nobody can certify DORA compliance by buying a tool. Check scope with counsel.

What does the regulator say it is for?

ESMA's DORA page says the act aims to strengthen the ICT security of financial entities and make sure the European financial sector can stay resilient in the event of a severe operational digital disruption. It brings harmonized rules for more than 20 different types of financial entities, of which 12 are in ESMA's remit.

The reason given is dependence. Financial firms rely more and more on ICT tools and rely on ICT service providers, which are not always supervised like financial entities. Unmanaged ICT risk can disrupt financial services and affect other entities, sectors and the wider economy.

What are the pillars?

ESMA's page lists six topics, which correspond to the usual pillars:

  • ICT risk management. A framework with principles and requirements.
  • ICT third party risk management. Mitigating ICT third party risk, with key contractual provisions.
  • Digital operational resilience testing. A testing programme that includes a range of tests, up to advanced testing.
  • ICT related incidents. Managing incidents and notifying competent authorities about major incidents and significant cyber threats.
  • Information sharing. Exchange of intelligence on cyber threats.
  • Oversight of critical third party providers. An oversight framework for ICT providers designated as critical by the European Supervisory Authorities.

The legal basis is Regulation (EU) 2022/2554, with Directive (EU) 2022/2556 alongside it. Level 2 technical standards fill in detail, including RTS on ICT risk management, on contractual arrangements for ICT services supporting critical or important functions, on subcontracting, on threat led penetration testing and on incident classification, plus ITS on templates for the register of information.

Who needs it?

Financial entities within the regulation's scope, across the sectors the ESAs supervise. If you are an ICT service provider to those entities, you are not exempt in practice: your customers must manage you as third party risk and put required contract terms in place, and the most critical providers can be designated for direct oversight. Whether you are a financial entity or a provider is a question for counsel, and the answer can depend on the services you offer.

Where does the software supply chain fit?

Third party risk management reaches software. A financial firm must understand which ICT services support critical or important functions, who provides them and what sits beneath them. Practical evidence includes an inventory of software and services, SBOMs from key suppliers, records of vulnerability handling and a view of concentration risk, where many functions depend on one provider.

Incident reporting also leans on inventory. You cannot classify and report an incident quickly if you do not know which systems and suppliers are involved.

What should a first plan look like?

Start with scope and mapping, not with tools. Identify critical or important functions. Map the ICT assets and providers behind them. Compare against the RTS requirements. Build the register of information, which ESMA's page lists as having its own technical standard. Then address gaps in testing, incident process and contracts.

What to do

  1. Confirm with counsel whether you are a financial entity in scope or an ICT provider to one.
  2. List critical or important functions and the systems and suppliers behind each.
  3. Start the register of information with a named owner and a refresh schedule.
  4. Review supplier contracts against the RTS on contractual arrangements.
  5. Define incident classification and who notifies the authority, and rehearse it.
  6. Plan a resilience testing programme, including how advanced tests would be scoped.
  7. Request SBOMs and vulnerability handling commitments from key software suppliers.
  8. Assign a board level owner and report progress regularly.

Quick check

When does DORA apply?

ESMA states it entered into force on 16 January 2023 and applies from 17 January 2025.

Does DORA affect non-financial software vendors?

Indirectly yes. Financial customers must manage them as ICT third party risk, and the most critical providers can be designated for oversight.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.