What DORA requirements apply to a financial entity today?
DORA has applied since 17 January 2025, and a customer, contract or regulator that now asks for proof of compliance is asking for evidence against obligations that sit in the Regulation itself plus its delegated and implementing regulations. The Regulation sets the principles and the five areas of obligation, while the technical standards add the detail, specific measures and frequencies. Your first task is to build one list of obligations from both layers, because a gap analysis that stops at the Regulation will miss requirements that the standards make concrete.
Which obligations bind you depends on three things: the type of financial entity you are under Article 2(1), your size and risk profile, and the ICT services you buy or provide. Article 4(1) applies the proportionality principle to the ICT risk management chapter, so a small firm and a large bank do not carry identical duties. The organization owns its controls and makes the decisions about how they are designed and run. An implementation partner can prepare systems, configurations and evidence, but only your competent authority supervises compliance, and only independent reviewers you appoint assess your controls. Ask any firm offering DORA help to confirm in writing which parts it prepares and which parts it does not perform.
DORA sets no certification scheme, so no auditor can issue a document stating that your entity is DORA compliant. Supervisors check your documents, registers, test results and governance records during their supervisory activity, using the powers in Article 50. Plan for that reality by mapping each obligation to a named owner, a current document and a dated record that shows the work was done. Confirm with your competent authority which supervisory expectations and reporting formats apply to your entity type, since national practice shapes how requests arrive.
Which five areas of DORA do the requirements fall into?
DORA groups its obligations into chapters that each cover one part of operational resilience. Read together, they run from how an entity governs its own ICT risk, through how it handles incidents and tests its defenses, to how it manages the providers it depends on and answers to supervisors.
ICT risk management
Chapter II (Articles 5 to 16) requires the management body to own an ICT risk management framework and a digital operational resilience strategy, then to identify, protect, detect, respond to and recover from ICT risks. Entities must keep an information security policy, continuity and recovery plans, backup policies and crisis communication plans, and review them on a set cycle. Proportionality under Article 4 scales this effort, so check which simplified obligations apply to your entity.
ICT-related incident management
Chapter III (Articles 17 to 23) requires a documented incident management process that detects, classifies and records ICT-related incidents and cyber threats. Entities must report major incidents to their competent authority within set deadlines and notify clients where an incident affects them. Confirm your classification criteria and reporting channels before an incident occurs, because the deadlines start running from detection.
Digital operational resilience testing
Chapter IV (Articles 24 to 27) requires a risk-based testing programme covering all ICT tools and systems, with testing of systems that support critical or important functions at least yearly. Certain larger entities must also run threat-led penetration testing at a defined cycle, using accredited testers. Keep records of test scope, findings and remediation, since supervisors will ask for them.
ICT third-party risk
Chapter V (Articles 28 to 44) requires entities to manage the risk of every ICT service provider, including cloud and open-source platform vendors that run inside their environment. Entities must keep a third-party risk strategy, a register of information, due diligence, mandatory contract clauses, audit rights and tested exit plans. Oversight of critical providers sits with the European Supervisory Authorities, so confirm which of your providers may be designated critical.
Information sharing
Chapter VI (Article 45) allows financial entities to exchange cyber threat information and intelligence among themselves, within trusted communities, to improve their defenses. The article sets conditions for how that exchange must protect sensitive data and fit within the entity's own risk management. Decide whether your entity will join such arrangements and how it will handle the information it receives.
Supervision and penalties
Chapter VII (Articles 46 to 56) sets out which national competent authority supervises each type of financial entity, what powers it holds, and the administrative penalties and remedial measures member states must provide. This is the enforcement layer that checks the other four areas. Supervisors assess evidence rather than issuing a certificate, so keep documents current and ready to produce.
Which technical standards detail each DORA area?
Chapter II of the Regulation sets the ICT risk management principles, from governance and the risk framework to backup, learning and communication. Delegated Regulation (EU) 2024/1774 supplies the detailed security expectations that sit under those principles, covering areas such as logging, vulnerability management, networks, access and change. The Regulation frames these as proportionate to the entity's size and risk profile, so the standard is best read as a set of expected controls to be scaled, not a uniform checklist.
- Detailed security measures: The standard sets out specific expectations for encryption, logging, patching, network controls and access management that the Regulation only states in principle.
- Higher frequencies for critical systems: For systems supporting critical or important functions, it sets shorter review cycles, including weekly automated vulnerability scanning and access rights reviews at least every six months.
- Proportionality in practice: The standard sets its requirements against the entity's risk profile, so teams should document which measures apply in full and which are scaled.
- Evidence expectations: Each measure implies records a supervisor can request, such as scan results, access review sign-offs and configuration baselines.
Confirm the current article numbers and frequencies on EUR-Lex before you map them to your controls, because a gap analysis built on a superseded text will miss requirements.
Article 28(3) of the Regulation requires financial entities to keep a register of information on their contractual arrangements for ICT services. Implementing Regulation (EU) 2024/2956 defines the structure of that register, setting out the templates and the data each record must contain. It turns a general duty to keep records into a fixed data model that can be submitted to supervisors and reused across entities.
- Standard templates: The implementing regulation defines the templates used to record each contractual arrangement, so the data is consistent across the sector.
- Identifier and data quality rules: It sets how providers, entities and arrangements must be identified and how the data must be validated.
- Reporting cycle: The register is submitted to competent authorities, which pass information on to the European Supervisory Authorities on an annual cycle.
- Link to contract management: Each contractual arrangement in the register must trace back to a contract, so procurement and legal records need to feed the register.
Confirm the template count, submission channels and deadlines against the regulation and your competent authority's guidance, since these can change.
Chapter IV of the Regulation requires testing and, for certain entities, threat-led penetration testing (TLPT). Delegated Regulation (EU) 2025/1190 details how TLPT must be run, covering the phases, the requirements for testers and threat intelligence providers, and the steps that lead to the attestation. It is the standard that turns a general testing duty into a structured, intelligence-led exercise.
- Phases and deadlines: The standard sets out the preparation, testing and closure phases and the timing expected between them.
- Tester requirements: It describes what internal and external testers must have in terms of skills, independence and insurance.
- Threat intelligence: It sets requirements for the threat intelligence used to shape the scenarios.
- Attestation: Competent authorities issue the attestation that a TLPT met the requirements, which is the only authority-issued attestation the Regulation provides for.
Confirm which entities are in scope for TLPT and the current phase deadlines with your competent authority before you plan a test.
Several other standards add detail to specific parts of the Regulation. Delegated Regulations (EU) 2024/1772 and 2024/1773 deal with incident classification and reporting, while 2025/301 and 2025/532 cover further reporting and oversight matters. On the third-party side, Implementing Regulation (EU) 2025/302 supports the rules on ICT services and oversight. Each one fills a specific gap, so your gap analysis should read the standard that applies to the article you are testing.
- Incident classification: The standards on classification set the criteria and thresholds used to decide whether an incident is major.
- Incident reporting content: Reporting standards define the content, templates and timing of the notifications to competent authorities.
- Oversight of critical providers: Oversight standards govern how the ESAs assess critical ICT third-party providers.
- Subcontracting and ICT services policy: Third-party standards set expectations for the policy and conditions on subcontracting.
Confirm the exact scope of each of these standards on EUR-Lex, because their titles and reach are easy to confuse.
The list of technical standards is not fixed in a single document, and new or amended texts appear as the European Supervisory Authorities and the Commission progress their work. A complete picture needs the Regulation read alongside every delegated and implementing regulation adopted under it. Treat any list in an internal document, including this one, as a starting point to verify.
- Start with the Regulation: Read the Regulation's articles on each area, since they name the standards that detail them.
- Search EUR-Lex by reference: Confirm each delegated and implementing regulation number, its date and whether it has been amended.
- Record the version you used: Keep a dated reference list so your evidence matches the texts in force at the time of assessment.
- Watch pending changes: The Commission's review and the proposed Digital Omnibus could change obligations, so note the status of each pending item.
Before starting a gap analysis, confirm the full list of standards on EUR-Lex and in your competent authority's guidance.
Which documents and yearly activities does DORA require?
This table lists the documents DORA requires financial entities to prepare and the activities the Regulation expects at least once a year, with the article that names each one. Read the frequency column first to see which items are one-time documents that must be kept current and which are recurring activities an assessor will expect to see repeated, with dated records.
| Requirement | Article that names it | Frequency |
|---|---|---|
| ICT risk management framework and digital operational resilience strategy | Article 6 | Documented once, reviewed at least yearly |
| Information security policy | Article 9(4)(a) | Documented, kept current |
| ICT business continuity policy and response and recovery plans | Article 11 | Documented, kept current, tested yearly |
| Backup policies and procedures | Article 12 | Documented, kept current |
| Crisis communication plans | Article 14 | Documented, kept current |
| Incident management process | Article 17 | Documented, kept current |
| Digital operational resilience testing programme | Article 24 | Documented, with yearly testing of critical or important systems |
| ICT third-party risk strategy, register of information and exit plans | Article 28 | Documented, register kept current, exit plans tested |
| Framework review report | Article 6(5) | Yearly |
| Review of classification of functions and assets and of risk scenarios | Article 8(1) and 8(2) | Yearly |
| Legacy system risk assessment | Article 8(7) | Yearly |
| Testing of continuity and recovery plans | Article 11(6) | Yearly |
| Senior ICT staff reporting to the management body | Article 13(5) | Yearly |
| Testing of systems supporting critical or important functions | Article 24(6) | Yearly |
How proportionality changes the DORA requirements for smaller firms
Article 4(1) applies the ICT risk management chapter in line with proportionality. The four factors below set how deep the work goes, while the higher frequencies in the technical standards apply regardless of size wherever systems support critical or important functions.
Entity size
Size is the first factor Article 4(1) names. A smaller entity with fewer systems, fewer staff and a narrower set of services can usually document its ICT risk framework in a shorter form and run reviews with a smaller team. Size does not remove any article, so each obligation still needs an owner, a document and evidence. Ask your competent authority how it reads size in supervisory practice before you scale down.
Overall risk profile
Risk profile asks how exposed the entity is to ICT failure, cyber threats and third-party dependence. An entity with high exposure, such as one that depends on a few providers for payments or customer data, should expect deeper risk assessments, more frequent scenario reviews and closer monitoring of its ICT providers. A low-exposure entity can focus its effort on the risks its own register actually shows. Document the rationale for each depth decision.
Nature of services
The kind of service decides which functions are critical or important, and therefore which systems fall under the strictest requirements. A firm whose core service depends on real-time transaction processing will carry more testing, recovery and continuity work than one offering advisory services with the same headcount. Map each service to its functions before you decide where the proportionate effort goes, and record that mapping for supervisors.
Scale and complexity
Scale and complexity cover the volume of transactions, the number of systems, the depth of integrations and the degree of outsourcing. Two entities of the same size can differ widely here, for example one running a single hosted platform and another running a multi-cloud estate with many interconnected services. Complexity tends to raise the work on asset inventories, network documentation and change control. Confirm with your supervisor how these factors combine in your case.
Fixed frequencies for critical systems
Proportionality does not reduce the timing rules in Delegated Regulation (EU) 2024/1774 for systems that support critical or important functions. Weekly automated vulnerability scanning applies under Article 10, firewall rule checks must happen at least every 6 months under Article 13, and access rights reviews at least every 6 months under Article 21. Confirm which simplified regime applies to your entity type before you set your calendar.
Why no auditor can certify DORA compliance, and what supervisors check instead
DORA sets no certification scheme. No auditor, consultancy or certification body can issue a certificate stating that a financial entity is DORA compliant. Competent authorities supervise compliance directly, using the supervisory powers in Article 50, and they decide for themselves what evidence to request and what to conclude from it. For the organization, this means the question to answer is not which certificate to buy but whether the evidence it can produce would satisfy its competent authority on inspection. Any offer of a DORA certificate, seal or badge should be treated as a sales claim that the regulation does not support, and procurement teams should ask the vendor which authority, if any, recognizes it.
In practice, supervisors ask for the documents and records the Regulation and its technical standards require: the ICT risk management framework and information security policy, the register of information, the testing programme and test results, the framework review report, and internal audit findings on the ICT risk framework. They also examine whether these records show the activities that must recur, such as annual reviews and testing of systems supporting critical or important functions. Independent reviewers can test individual controls against these expectations and report their findings to the organization, which is useful preparation. However, their report is an input to the organization's own assurance, not a DORA certificate, and the organization owns the conclusions it draws from it.
The one document an authority issues under DORA is the attestation that a threat-led penetration test met the requirements set out in Article 26(7). It confirms a specific test, not the entity's overall compliance, and it is produced within the threat-led testing process rather than sold as a standalone product. Entities that must run this testing should confirm with their competent authority which attestation process applies to them and what it covers. Before engaging any reviewer, the reader should ask for a written statement of what the report will and will not state, and confirm that the work will be reported as an assessment of controls rather than as a DORA compliance certificate.
How to turn DORA requirements into an evidence file a supervisor can read
This sequence turns the Regulation and its technical standards into one organized, versioned evidence file that maps each obligation to an owner, a control and a record. The file lets the entity answer a supervisor's request without rebuilding its position from scratch.
Confirm scope and entity type
Start by establishing which legal entity is in scope, which of the 20 types of financial entity listed in Article 2(1) it belongs to, and whether it is identified as an essential or important entity under NIS2 for the purposes of Article 1(2). Record any proportionality position under Article 4(1), covering size, risk profile and the nature of services. The compliance lead, with legal counsel, signs off a scope statement. The step is done when the scope statement names the competent authority and lists the obligations that apply to the entity.
Map each requirement to an owner and control
Build a requirements register that lists each DORA article, its applicable delegated or implementing regulation, and the control that meets it. Assign one accountable owner per requirement, such as the CISO for ICT risk management or the head of procurement for third-party contracts. Mark gaps where no control exists. An implementation partner can prepare this register, but the entity owns each control and each owner's name. The step is done when every applicable requirement has an owner, a control and a status.
Collect the policies and registers DORA names
Gather the documents the Regulation names, including the ICT risk management framework and digital operational resilience strategy, the information security policy, the continuity and recovery plans, backup policies, crisis communication plans, the incident management process, the testing programme, the ICT third-party risk strategy, the register of information and exit plans. Check each document against the requirement it supports, and confirm the approving body. The step is done when every named document exists, has an owner and an approval date, and points to the requirement it serves.
Run and record the yearly activities
Schedule the activities DORA requires at least yearly, such as the framework review, the review of function and asset classification and risk scenarios, the legacy system risk assessment, continuity plan testing, the report from senior ICT staff to the management body and testing of systems supporting critical or important functions. Delegated Regulation (EU) 2024/1774 sets higher frequencies for some controls, so check those separately. Each activity produces a dated record with attendees, findings and decisions. The step is done when each yearly activity has a completed record for the current cycle.
Test the controls and log the results
Test whether each control works as the documented design says it should. Use a sample of systems, the logs and tickets that the control produces, and the test steps defined in the testing programme. Record the test date, tester, scope, result and any exception. Route failed tests into remediation tracking with an owner and a target date set by the entity. The step is done when each control in the register has at least one test record and each exception has a tracked remediation item.
Keep a version history for supervisory requests
Store every policy, register, plan, test record and board report in a controlled repository with version numbers, change logs and approval records. Keep the state of each document as it was at each approval date, so the entity can show what was in force at a given time. Confirm retention periods with the competent authority and legal counsel. The step is done when the entity can retrieve any requirement's documents and records for a past date within a short, agreed period, and a sample request has been rehearsed.
Who owns each DORA requirement and who can help with it
The financial entity in scope of DORA owns its ICT risk management framework, its controls, its incident process and its contracts with ICT providers. The management body approves the policies, carries responsibility for the framework and must keep itself informed about ICT risk. The entity also decides which functions and assets are critical or important, because that classification drives the stricter testing, contract and reporting duties that follow.
- Policy approval: The management body approves the ICT risk management framework, the information security policy and the resilience strategy, and records that approval.
- Classification decisions: The entity identifies critical or important functions and reviews that classification at least yearly, as the Regulation requires.
- Operating controls: Staff run access reviews, backups, monitoring, incident handling and continuity exercises, and can show the results on request.
- Provider oversight: The entity keeps the register of information, negotiates contract clauses, runs due diligence and maintains tested exit plans for each ICT service.
- Accountable sign-off: Internal audit and senior ICT staff reporting give the management body the evidence it needs to stand behind the figures.
Before engaging any outside party, confirm which person in the entity signs off each document and who holds the decision on critical or important functions.
An implementation partner such as DeployOpen plans, implements, customizes, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, which may be its cloud accounts, data centers or air-gapped networks. For DORA, that work typically helps the entity build systems, controls and evidence that the entity then owns. The partner does not issue reports, attestations or certificates, and it does not decide the entity's risk appetite or classification.
- Planning and build: The partner can design the configuration, logging, backup and access setup for the platforms that support the entity's functions, within a written scope.
- Hardening and testing support: Security testing of applications, APIs and infrastructure can be scoped as a separate engagement, with findings handled by the entity.
- Documentation: The partner can draft technical runbooks and system descriptions that the entity reviews, adopts and maintains.
- Evidence preparation: Logs, configuration exports and test records can be organized so the entity can present them to its supervisor or independent reviewer.
- Retainers: Ongoing support, upgrades and continuous testing can run under a retainer after the fixed-scope work ends.
Before signing, ask the partner to show the written scope, the deliverables, who owns each artifact and which tasks remain with the entity.
The national competent authority for each type of financial entity supervises DORA compliance, using the powers in Article 50. The ECB supervises significant credit institutions, and the ESAs oversee critical ICT third-party providers as Lead Overseers. DORA sets no certification scheme, so no auditor can certify an entity as DORA compliant. Independent reviewers such as internal audit or external assessors give the entity assurance, but their work does not replace supervision.
- Supervisory review: Authorities can request policies, registers, test results, incident records and contracts, and assess them against the Regulation and its technical standards.
- Threat-led testing attestation: For threat-led penetration testing, the authority-issued attestation under Article 26(7) is the only formal document the Regulation provides for.
- Internal audit: Audit reviews of the framework and of the testing programme give the management body and supervisors evidence of independent challenge.
- External assurance: An independent assessor can test controls against the entity's own documented requirements, but its report is not a DORA certificate.
- Evidence readiness: The entity should be able to show its documents and records in a consistent form without waiting for a request.
Before engaging an external reviewer, confirm with your supervisor which evidence it expects and whether the reviewer's report will be accepted as part of that evidence.
Frequently asked questions about DORA requirements
Which DORA requirements apply to a small financial entity?
Every in-scope financial entity must meet the core obligations of DORA, but Article 4(1) requires Chapter II (ICT risk management) to be applied in line with proportionality. That principle takes into account the entity's size, overall risk profile, and the nature, scale and complexity of its services, activities and operations. In practice, a small firm still needs a documented ICT risk framework, an incident management process, a testing programme and contract terms for its ICT providers, but the depth and frequency of each can be smaller. Whether a simplified regime or microenterprise treatment applies depends on the entity type and member state options, so confirm your classification with your competent authority before scoping the work.
How much effort do DORA documents and yearly activities take?
Effort depends on how many ICT systems, critical or important functions and ICT providers the entity runs, and on how much of its existing security program it can reuse. The Regulation names a set of documents, including the ICT risk management framework, the information security policy, continuity and recovery plans, backup policies, the incident management process, the testing programme and the register of information. It also requires recurring activities at least yearly, such as the framework review, review of the classification of functions and assets, testing of continuity and recovery plans, and testing of systems supporting critical or important functions. Delegated Regulation (EU) 2024/1774 sets higher frequencies for some controls, including weekly automated vulnerability scanning for assets supporting critical or important functions. Ask any partner to map each document and activity to a named owner and a calendar before quoting.
Must an ICT provider meet DORA directly?
Financial entities carry the primary DORA obligations, but the contracts they sign shape what providers must do. Entities must include specific terms in ICT service agreements, cover subcontracting conditions, secure audit rights, and keep the register of information current. Providers therefore usually face these obligations indirectly through their customers' contracts. Separately, critical ICT third-party service providers can be designated by the European Supervisory Authorities and overseen directly as Lead Overseer supervision applies to them under Articles 31 to 44. Check whether a provider has been designated critical, and confirm which contract clauses it has accepted, before relying on it for an important function.
Is there a DORA certificate that proves compliance?
No. DORA sets no certification scheme, and no auditor or certification body can certify an entity as DORA compliant. Competent authorities supervise compliance using the powers in Article 50. The only authority-issued attestation the Regulation provides for is the attestation that a threat-led penetration test met the requirements under Article 26(7). Evidence that supervisors can request includes the policies, the framework review report, test results, internal audit findings and the register of information. Be cautious with any vendor or consultant who sells a DORA certificate or seal, since no such document exists under the Regulation.
What does the work need from the internal team?
An external partner can prepare systems, controls and evidence, but the organization must own its decisions. The management body must approve and oversee the ICT risk framework and related policies, and senior ICT staff must report to it at least yearly under Article 13(5). Internal teams typically need to supply an accurate asset and service inventory, business owners who can classify critical or important functions, access to infrastructure and logs, and staff who will operate the processes after handover. Ask a partner to state in writing which tasks it performs and which remain with your staff, along with the time those staff will need to commit.
Can we do the DORA work ourselves?
A capable team can implement DORA without outside help, especially a smaller entity with a limited set of ICT services and an existing security management program. The main risks are gaps in the classification of functions, incomplete contract clauses, untested continuity plans and evidence that is scattered or undated. Entities that lack in-house testing or documentation experience often bring in a partner for a gap analysis first, then decide which remediation work to keep internal. Whichever route you choose, the decision and accountability stay with your management body and your competent authority.
Which parts of DORA are usually outsourced?
Organizations most often outsource work that needs specialized skills or independent capacity. Common examples include a gap analysis against the Regulation and its technical standards, preparation of the register of information data, technical hardening and logging of self-hosted platforms, vulnerability scanning and penetration testing, and building test evidence packs. Threat-led penetration testing is typically delivered by accredited testers, and the scope and testers must meet the requirements of Delegated Regulation (EU) 2025/1190. Cost depends mainly on the number of systems, the depth of testing and the number of ICT providers involved. Ask every quote to separate one-time setup from recurring activities, and to state what the entity must still provide.
How DeployOpen maps DORA requirements to systems and evidence
DeployOpen approaches DORA requirements as a systems and evidence problem: each obligation in the Regulation and its technical standards is traced to a control in the financial entity's own infrastructure and to the record that proves it. Our role is to prepare systems, controls and documentation, while the organization owns its compliance decisions and independent assessors remain responsible for any formal review.
How we scope
- We agree a written scope listing the DORA chapters, ICT systems and entities covered before any work starts.
- We map the obligations that apply to your entity type and proportionality position against the Regulation and its technical standards.
- Engagements are fixed-scope, with deliverables and timelines confirmed in writing, and a quote follows from that scope.
How we build
- We implement self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks.
- We configure logging, access, backup, vulnerability scanning and change controls so the ICT risk management requirements produce usable records.
- We integrate these controls with your existing monitoring and incident tooling and test that the evidence they generate is complete.
How we hand over
- We deliver the system documentation, control descriptions and evidence collection procedures that your staff and assessors can follow.
- We prepare the policy, register and recurring review artifacts that the organization reviews, approves and signs off under its own governance.
- We support your team in running the first review cycle so ownership of the controls transfers to your staff.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing.
- Retainers can cover recurring activities such as framework reviews, vulnerability scanning follow-up and access rights reviews.
- Supervisors and independent assessors receive evidence from your organization, while DeployOpen prepares that evidence but does not issue any audit report or certificate.
