DORA Compliance: Requirements, Checklist, and Human Risk

DORA compliance affects IT, risk management, and people. Find out which requirements apply and how human risk management strengthens your resilience. 

Contents

1. What Is DORA Compliance?
2. Who Does DORA Apply To?
3. 5 Compliance Requirements
4. DORA Test: Checklist
5. Human Risk at DORA
6. How Security Awareness Training Helps
7. AWS, Microsoft, Google & More: DORA Resources

DORA Compliance at a Glance

• DORA compliance affects IT, security, risk management, and senior management
• Whether your organisation is in scope depends on its financial role, ICT relevance, and provider status
• The five areas of focus are ICT risk management, incident reporting, digital operational resilience testing, third-party oversight, and information sharing
• Human risk can contribute to DORA-relevant ICT incidents through phishing, social engineering, and unsafe routines
• The SoSafe Human Risk Management Dashboard makes human risk measurable and supports audit conversations

What DORA Compliance Is and What It Means for IT Teams

For a financial organisation, DORA compliance comes down to two things: staying in control of digital risk, and being able to demonstrate it. Day to day, that means risk assessments, incident reports, planned resilience tests, and ongoing monitoring of ICT third-party providers. ‘DORA compliance framework’ is common shorthand for this, though it undersells what’s actually at stake: unlike a voluntary standard such as ISO 27001, this is EU law, and the requirements aren’t optional.

In everyday workflows, that’s where DORA compliance stops being abstract. None of this should come at the cost of speed: reporting channels, training, and documentation need to work without slowing teams down. In everyday tools such as Microsoft 365 or Google Workspace, for example, this should tie in directly with existing processes in email, chat, and collaboration platforms.

Who Must Comply with DORA

Organisations operating in the EU financial sector are almost certainly in scope for DORA compliance. The same is true for ICT third-party providers supporting these organisations. This includes, among others:

• Banks, payment institutions, and e-money institutions
• Investment firms, trading venues, and central counterparties
• Insurers, reinsurers, and institutions for occupational retirement provision
• Fund managers, management companies, and AIFMs
• Crypto-asset service providers
• Credit rating agencies, data reporting service providers, and administrators of critical benchmarks
• Crowdfunding service providers and securitisation repositories
• ICT third-party providers, such as cloud, software, or IT service providers for financial organisations
• DORA compliance therefore doesn’t just concern your own organisation. Anyone aiming to be DORA compliant also needs to know their critical digital dependencies. Our DORA guide provides a detailed breakdown of who is affected.

The Five Core Areas of DORA Requirements in Daily IT Operations

DORA compliance requirements are organised around five areas that must work together in practice. Senior management is accountable for oversight and governance. IT, security, and risk management must ensure that processes, evidence, and responsibilities work reliably when it matters most.

ICT Risk Management

ICT risk management means knowing, assessing, reducing, and regularly reviewing risks. This requires clear roles, up-to-date risk data, and traceable measures. Without this foundation, DORA compliance can’t be demonstrated.

Incident Management

Major ICT incidents must be detected immediately, assessed quickly and accurately, and reported to the relevant authority. Reliable ICT incident management depends on fixed reporting channels and clear responsibilities that hold up under pressure.

Digital Operational Resilience Testing

An organisation that doesn’t test is only guessing. That’s why all systems, controls, and contingency processes must be tested regularly. Testing is the only way to confirm whether procedures actually work under real-world conditions.

Monitoring ICT Third-Party Providers

When cloud, software, or IT service providers support critical processes, organisations need to know and manage these dependencies. That’s why DORA compliance requires documenting contracts, risks, and responsibilities.

Using Cyber Threat Information

Collecting threat intelligence without acting on it wastes its value. Under DORA, organisations are expected to feed cyber threat insights directly into their protective measures and processes, and can also choose to share relevant intelligence with other financial entities on a voluntary basis.

DORA Test: Checklist for Your First Review

By “DORA test,” we mean an internal preliminary review here, not an official regulatory audit procedure. This short DORA compliance checklist helps IT and security teams identify the key points for DORA compliance. It doesn’t replace legal advice and isn’t exhaustive.

1. Executive Governance and Risk Management
   Are responsibilities, risks, and controls documented and known to senior management?
2. Incident Reporting and Detection
   Does your organisation detect major ICT incidents early enough? Do the relevant teams know when and how to report them?
3. Digital Operational Resilience Testing
   Do you test systems, controls, and contingency processes regularly? Are results and next steps documented?
4. Third-Party Risk and Information Registers
   Are critical ICT third-party providers, dependencies, and contracts recorded? Is this information up to date?
5. Human Risk Management and Security Awareness
   Do employees recognise phishing, social engineering, and suspicious requests? Do they know where to report them?

Our detailed DORA compliance checklist is also available as a PDF. It includes additional checkpoints for teams preparing to run their DORA test properly.

Why Human Risk Matters for DORA Compliance

ICT incidents often start the same way: a phishing link gets clicked, a social engineering attempt succeeds, or someone simply makes a mistake. That’s where human risk management comes in. It puts numbers on a risk that’s often invisible, creates evidence auditors can use, and covers what technical controls alone can’t. 

How Security Awareness Training Strengthens DORA Compliance

Article 13 of DORA requires financial organisations to run regular ICT security awareness programmes, covering all employees, including senior management. Ticking this box with a once-a-year mandatory training session doesn’t meet the spirit of the requirement.

According to the ENISA Threat Landscape 2025, phishing is the most common entry point for attacks, accounting for around 60 percent of observed cases. Training that runs regularly, addresses behaviour directly, and uses simulations changes that. For DORA compliance, effectiveness also needs to be demonstrable: participation rates, test results, and progress reports show auditors that the programme actually works, not just that it exists.

AWS, Microsoft, Google, and More: Official DORA Resources from Major Providers

Anyone who needs to document and assess ICT third-party providers for DORA compliance can’t avoid the official resources these providers publish. The major cloud and software providers offer their own DORA resources, including guides, contract addenda, and mapping documents.

• AWS DORA Compliance: a user guide, a Level 1 workbook, and a DORA Financial Services Addendum for contract-related questions
• Microsoft DORA Compliance: resources in the Microsoft Trust Center, including Compliance Manager templates for ICT third-party risk
• Google Cloud DORA Compliance: a compliance page with FAQs, mapping documents, and updated contract clauses aligned with Article 30
• Salesforce DORA Compliance: an FAQ document and DORA mapping for all relevant Salesforce services, including Slack and MuleSoft
• Atlassian DORA Compliance: a guide to Atlassian’s approach to DORA, including responsibilities under the shared responsibility model

These provider documents are a good starting point for your own risk analysis, but they don’t replace it. Contracts, dependencies, and responsibilities still need to be assessed, documented, and kept up to date internally.