Digital Operational Resilience ActMeet DORA without building a resilience team first.
DORA holds EU financial entities, and the ICT providers they rely on, to one set of rules for ICT risk, incident reporting, resilience testing, and third-party oversight. A dedicated SecureSlate compliance lead maps your obligations, builds the ICT risk management framework and register of information, and gets incident reporting ready, while our compliance automation platform keeps evidence current for supervisors and customers. One fixed price covers the work.
DORA: 25 requirements, 10 ICT risk management, 4 Incident reporting, 4 Resilience testing, 6 Third-party risk, 1 Information sharing. 4 highlighted: Evidenced by included security scanning.
Evidenced by included security scanningScoped with your compliance lead
- Regulation
- (EU) 2022/2554, applies since January 2025
- Who it covers
- 20 types of EU financial entities and their ICT providers
- Certification
- None, supervised by financial authorities
The standard
DORA compliance is judged by supervisors and financial customers, not a certificate.
DORA, Regulation (EU) 2022/2554, has applied directly across the EU since 17 January 2025. Technical standards from the European Supervisory Authorities fill in the detail, and every requirement scales with your size, risk profile, and complexity.
Five pillars
ICT risk management, incident management and reporting, digital operational resilience testing, ICT third-party risk, and information sharing. The first pillar carries most of the work: a documented framework covering identification, protection, detection, response and recovery, backup, learning, and communication.
Tight incident reporting deadlines
A major ICT-related incident needs an initial notification within 4 hours of classifying it as major and no later than 24 hours after becoming aware of it, an intermediate report within 72 hours, and a final report within a month. Classification criteria come from the technical standards, so they have to be built into your process first.
Third parties inside the scope
Financial entities keep a register of information on every ICT service arrangement, put specific terms in those contracts, and plan exits for critical services. ICT providers meet DORA as contract clauses, audit rights, and incident assistance, and the most critical providers fall under direct EU oversight.
How it works
We build your DORA program with you, then keep it ready for supervisors and customers.
Four stages from the scoping call to a program you can evidence, with a named compliance lead accountable at every one.
Confirm your role and scope
We work out whether you are a financial entity, an ICT third-party service provider, or both, which functions are critical or important, and how proportionality and any simplified framework apply to you.
Run the gap assessment
Your compliance lead maps what you already run to each pillar, reusing ISO 27001, SOC 2, or NIS 2 controls where you have them, and ranks the gaps by supervisory risk and deadline.
Build the framework, register, and reporting
The ICT risk management framework, policies, backup and continuity testing, incident classification and reporting process, and register of information are put in place, with your contract terms checked against Article 30.
Test, report, and stay ready
Resilience testing runs on a schedule, controls are monitored continuously, and the management body receives the reporting it needs to approve and oversee the framework, so evidence is ready for a supervisor or a customer audit.
What is included
Everything DORA asks you to evidence, prepared before anyone asks.
DORA compliance software and the expert who runs it arrive together under one fixed price, so operational resilience does not become a side project for your engineers.
A dedicated compliance lead
One experienced practitioner owns your DORA program end to end. They scope your obligations, write the ICT risk management framework, prepare management reporting, and answer supervisor and customer questions, so your team approves instead of reading technical standards.
Pillar mapping and a gap assessment
Every DORA requirement mapped to the policies, controls, and evidence that meet it, with each gap scored, owned, and scheduled, and the work that already counts toward ISO 27001 or NIS 2 marked.
ICT providers and the register of information
ICT third-party providers inventoried, assessed before contracting, and reviewed on a schedule, with the details your register of information needs, including which providers support critical or important functions.
Evidence from the stack you already run
Connect your cloud provider, identity provider, code host, and devices once. Controls are tested continuously against live configuration, so evidence for a supervisory request or customer audit is current instead of assembled in a hurry.
Incident classification and reporting
Your compliance lead builds the incident management process with DORA's classification criteria, decision owners, and report templates for each deadline, then tests it with your team in a tabletop exercise.
A resilience testing program
Critical ICT systems tested at least yearly, combining the included vulnerability and code scanning with backup restoration and continuity tests, and every finding tracked to closure.
Included security scanning
Included security scanning evidences four DORA requirements.
Every engagement includes scanning across code, dependencies, cloud, and your public surface. Article 25 names vulnerability scans, open source analyses, and source code reviews among the tests it expects, so these findings count as evidence directly.
Art. 25 Testing of ICT tools and systems
Code security scanning
Repositories scanned for vulnerable code, with findings ranked by severity and traced to the line, which is the source code review Article 25 lists among resilience tests.
Art. 8 Identification, Art. 25 Testing of ICT tools and systems
Dependency and license risk
An SBOM for every repository, with vulnerable open source components flagged, covering the open source analysis Article 25 names and the software your systems depend on.
Art. 10 Detection, Art. 25 Testing of ICT tools and systems
Public surface monitoring
Your domains and forgotten subdomains scanned on a schedule and when you ship, giving recorded vulnerability scans and early detection of exposed services.
Art. 9 Protection and prevention
Secrets detection
API keys, tokens, and credentials committed to source code, found and pinpointed to the file and line, so strong authentication and access controls are not undermined in repositories.
Art. 10 Detection
Dark web monitoring
Company email addresses checked against known breach data, so compromised credentials are detected and reset before they are used against you.
Art. 9 Protection and prevention
Cloud misconfiguration checks
AWS, Azure, and GCP configurations checked through read-only access for risky settings in encryption, access, logging, and networking.
Beyond DORA
One DORA program that also serves your other frameworks.
DORA overlaps with the standards your customers and supervisors already recognize, so shared controls count more than once.
ISO 27001
The most common foundation for DORA's ICT risk management pillar. An ISMS covers much of it, though DORA adds reporting deadlines, resilience testing, and contract terms.
NIS 2
DORA is the sector-specific act for financial entities, so its rules apply instead of NIS 2's where they overlap. Groups with non-financial entities often run both.
SOC 2
ICT providers selling to banks and insurers are asked for a SOC 2 report alongside DORA contract terms. Access, change, vendor, and incident controls serve both.
PCI DSS
Payment and e-money institutions protect card data under PCI DSS while meeting DORA, and payment-related incidents follow DORA's reporting rules too.
GDPR
A major ICT incident involving personal data can trigger DORA reporting and a 72-hour GDPR breach notification, so one incident process should handle both.
NIST CSF
Groups with US operations often describe their program with the CSF. Its Identify, Protect, Detect, Respond, and Recover outcomes line up with DORA's ICT risk framework.
DORA guides
What DORA actually asks of your team
Three deep dives your team can read before the scoping call, from who is in scope to the full checklist.
5 pillars
The five pillars of DORA, with the owners and evidence behind each
20 types
Who needs to comply with DORA, from banks and insurers to ICT providers
4 hours
The DORA compliance checklist, pillar by pillar
Resources
Read up before your scoping call.
Practical guides to DORA, from what the regulation is to how it compares with NIS 2.
FAQs
What teams ask before starting DORA.
Twenty types of EU financial entities, including banks, payment and e-money institutions, investment firms, crypto-asset service providers, insurers, and fund managers, plus the ICT third-party service providers they rely on. ICT providers are mostly affected through their customers' contracts, and those designated as critical fall under direct oversight by the European Supervisory Authorities.
If EU financial entities use your service, yes. They must include specific terms in their contracts with you, such as where data is processed, service levels, help during ICT incidents, cooperation with authorities, and termination rights, with audit rights, participation in resilience testing, and exit support added for critical or important functions. They will also ask for evidence of your security and resilience.
For a major ICT-related incident: an initial notification within 4 hours of classifying it as major and no later than 24 hours after becoming aware of it, an intermediate report within 72 hours of the initial notification, and a final report within one month of the latest intermediate report. Classification follows criteria set in the regulatory technical standards.
A register of all contractual arrangements for ICT services provided by third parties, kept at entity, sub-consolidated, and consolidated level and made available to your competent authority. It records who provides each service, what it supports, and whether that function is critical or important.
Only if your competent authority identifies you for it, based on factors such as your systemic importance and ICT risk profile. Those entities run TLPT at least every three years. Every other in-scope entity still needs a resilience testing program, with critical ICT systems and applications tested at least yearly.
Not by itself. ISO 27001 covers much of the ICT risk management pillar, but DORA adds its own incident classification and reporting deadlines, resilience testing, the register of information, contractual provisions, and management body duties. Treat the ISMS as the foundation and map DORA's specific requirements on top.
The management body has ultimate responsibility for managing ICT risk. It defines, approves, and oversees the ICT risk management framework, approves the ICT business continuity policy and the ICT budget, and its members must keep their knowledge of ICT risk current through regular training.
No. DORA is enforced by financial supervisors, and Member States set the penalties. Customers may ask for an ISO 27001 certificate or a SOC 2 report as evidence of your controls, but neither replaces DORA compliance.
One fixed price agreed before work starts, covering the platform and the expert work. DORA has no certification fee, and any external testers you engage are paid directly. You leave the scoping call with the price.
Software gives you templates, integrations, and a dashboard, and your team still runs the program. A consultant brings the expertise, but evidence often stays manual once the engagement ends. SecureSlate combines both: a dedicated compliance lead who does the work, from scoping to incident reporting exercises, on a compliance automation platform, for one fixed price.
Find out what DORA means for your company
Bring your entity type, your critical ICT services, or the financial customer sending you DORA contract terms. You will leave the call with a gap summary, a plan, and a fixed price, whether or not you work with us.
