EU regulation · Digital resilience in the financial sector
Sightadel guides you through the requirements of the DORA Regulation – from ICT risk management and the reporting of major incidents to the register of information. With industry templates drawn from many years of consulting practice, AI as drafting help and real consultants for the difficult parts.
What it is about
The Digital Operational Resilience Act (DORA) is an EU regulation and has applied directly since 17 January 2025, without any national implementing act. It requires financial entities to be able to withstand, detect, report and recover from serious ICT disruptions – and to prove this at any time. In Germany, supervision lies with the Federal Financial Supervisory Authority (BaFin).
The regulation rests on five pillars: ICT risk management with clear accountability of the management body, handling and reporting of ICT-related incidents, digital operational resilience testing, management of ICT third-party risk including the register of information, and voluntary sharing of threat information. Technical standards from the European Supervisory Authorities specify many of the details.
For financial entities, DORA is the more specific law (lex specialis) in relation to NIS2. Its content overlaps strongly with an ISMS under ISO 27001. What is mainly missing there is the register of information, DORA's own incident classification with its reporting deadlines, and the requirements for contracts with ICT service providers.
More on the matching software: DORA software, with features, rollout and prices.
The basics are in place, but the register, incident classification or testing programme are still spreadsheets and intentions. Supervisors are now asking for evidence, not plans.
DORA applies according to the principle of proportionality. Certain smaller entities can use a simplified framework – but you still need the evidence.
You are not supervised yourself, but your clients must include you in their register of information, agree contractual clauses and assess you. The requirements reach you through the contract.
Testing programme under Art. 24–25
DORA requires all financial entities to have a risk-based testing programme, including vulnerability assessments, scans and penetration tests. Together with veyrisk, we offer the tests you need. You record planning, results and the remediation of findings in Sightadel. Threat-led penetration testing (TLPT) under Art. 26 is not covered.
Financial entities building or extending their testing programme under DORA
The scope and frequency of the tests depend on your risk assessment. You receive a quote after a short conversation.
Request testsRequirements
Summarised in our own words. The original text in its current version is always authoritative.
The management body is responsible for ICT risk, approves the framework, keeps its knowledge up to date and provides resources. The framework is documented and reviewed regularly.
In SightadelGuiding questions on roles, strategy and approval. The template provides a draft of the framework; you set the risk appetite and responsibilities. Management training is tracked with expiry dates.
Know critical functions, ICT assets and dependencies, implement protective measures such as access and change management, and detect anomalies early.
In SightadelGuided questions per requirement with answer options, linked evidence and comments. Evidence from ISO 27001 can be reused directly.
ICT response and recovery plans, backup policies and tested restoration.
In SightadelRestore tests as a recurring cycle with a record. If a test record expires, it appears on the dashboard before internal audit finds it.
Record ICT-related incidents, classify them according to uniform criteria and recognise major incidents as such.
In SightadelControls on process, roles, classification criteria and incident register. The criteria are documented in advance, not only when an incident occurs.
Initial notification to the supervisor within a few hours of classification as major, no later than 24 hours after becoming aware, followed by an intermediate report and a final report.
In SightadelReporting channels, responsible persons and deputies are recorded; differences from NIS2 in when the deadlines start are kept clearly separate.
A risk-based testing programme for everyone. Entities identified by the supervisor additionally carry out threat-led penetration testing (TLPT) at least every three years.
In SightadelTesting programme as a cycle; findings become issues with a deadline and an owner. The TLPT itself is carried out by specialist testers; Sightadel records planning, results and remediation.
A strategy for third-party risk, assessment before contract signature, exit strategies and a complete register of information covering all ICT contracts, to be submitted to the supervisor.
In SightadelIn the Vendors module you record service providers, supported functions, criticality and evidence with validity dates. The register grows out of day-to-day upkeep, not out of a collection drive before the reference date.
Contracts contain minimum content, such as a description of services, data processing locations, audit and access rights, termination rights and support during incidents.
In SightadelControls per contract element, linked to the service provider. Missing clauses become action items for the next round of contract negotiations.
Financial entities may exchange threat information within trusted communities and notify the supervisor of their participation.
In SightadelParticipation, rules and the notification to the supervisor are filed as evidence.
Process
Six to twelve months to close existing gaps. If you have an ISMS that is actually lived, you will be faster. The register of information and the contract amendments usually set the pace.
Clarify which obligations apply, whether the simplified framework is an option and which functions are critical or important.
Work through the 50 requirements step by step and map existing evidence from the ISMS, business continuity management and procurement.
Record service providers, contracts, supported functions and subcontractors. In our experience the most time-consuming part, because no contract folder holds all the details.
Define classification criteria, responsibilities and reporting channels, and run through them once.
Action plans with owners and due dates. Contract amendments often take the longest, because the other party has to cooperate.
Carry out the testing programme, review the framework, keep the register up to date. After that, these steps recur as a cycle.
Ready to start
Clarify these questions early and you save weeks later on. In Sightadel they are set up as your first tasks.
Division of work
If software filled everything in, the standard would not serve its purpose – and the auditor would notice. That is why it is clearly defined what stays with you.
From practice
From many years of consulting and certification practice: these are the points that cost the most time or lead to nonconformities in the audit.
If you only fill in the register of information before the annual submission, you search for the same details again every year. Maintain service providers and contracts continuously, as soon as they are engaged or changed.
If almost all functions are critical, the classification loses its value. If there are too few, contracts and tests are missing. Derive the classification from a traceable business impact analysis and have management approve it.
Under time pressure, an incident is recognised as major too late and the reporting deadline expires. Record criteria, thresholds, responsible persons and deputies in advance and run through the process at least once a year.
Missing mandatory clauses are identified but not followed up. Define for each service provider when the gap will be closed, for example at the next renewal, and record this as a task with a deadline.
A circular to the executive board does not replace a resolution. Have the framework, risk appetite and policies formally approved and document the training of management body members.
An exit strategy that nobody has checked will not help in an emergency. For providers of critical functions, check whether alternatives, data return and transition periods are realistic, and update the strategy when contracts change.
One piece of evidence, several frameworks
We deliberately do not give a percentage – it depends on your scope. Where requirements overlap, one piece of evidence is attached to all of them.
ICT risk management, access control, backup and incident handling build on the same foundations. The register of information has no equivalent in ISO 27001.
NIS2For financial entities, DORA takes precedence. Many measures coincide. The reporting deadlines differ in their starting point: DORA ties them to classification, NIS2 to awareness.
BSI C5A cloud provider's C5 attestation is valuable evidence when assessing that service provider. It does not replace your own risk assessment.
GDPRTechnical and organisational measures and data processing agreements draw on the same service provider data. One incident can trigger several reporting obligations.
Audit and evidence
In Germany, supervision lies with BaFin; critical ICT third-party service providers are additionally overseen directly by the European Supervisory Authorities. On top of that come statutory auditors, internal audit and clients who assess you as a service provider. Sightadel does not certify and does not replace regulatory advice.
Anyone carrying out an audit gets their own access in Sightadel and can never delete anything. The activity log shows completely who did what and when. As a service provider, you show your clients certificates, documents and subcontractors in the Trust Center instead of answering every questionnaire individually. ISO 27001 is a proven, structured foundation, but not mandatory. For external audits, you choose an auditor from our independent partner network or one of your own. No commission is paid for audits – neither to us nor to the partners.
To the independent auditor networkThe regulation itself sets out the principles. The details are in regulatory and implementing technical standards drafted by the European Supervisory Authorities and adopted by the European Commission. Anyone implementing DORA therefore always works with several texts in parallel. The most important cover the ICT risk management framework and its simplified version, the classification of incidents and cyber threats, the content, formats and deadlines of incident reports, threat-led penetration testing, the templates for the register of information, the policy on ICT services supporting critical or important functions, and subcontracting.
In practice this means: the regulation says you must classify an incident. Only the standard names the criteria, such as clients affected, duration, geographical spread, data losses and economic impact, and defines when an incident counts as major. The same applies to the register: which fields it has and how it is structured follows from the templates in the implementing standard.
In addition there are guidelines and Q&As from the European Supervisory Authorities as well as BaFin publications, for example on reporting channels and submission windows. These texts change more often than the regulation. In Sightadel, every control is linked to the article it relates to. Where a standard specifies details, the control names the expected evidence. If in doubt, check the authoritative version with the supervisor.
The register is the part of DORA that most entities underestimated. It does not simply require a list of contracts, but a structured register: which ICT service the entity obtains from whom, under which contract, for which function, whether that function is critical or important, where data is processed, how easily the service provider could be replaced, and which subcontractors sit behind it in the chain. The register is kept at the level of the individual entity and, for groups, on a consolidated basis.
BaFin requests the register once a year as at a reference date. Submission takes place via its reporting and publishing platform within a set time window. For the 2026 submission, this window was in March. A register only counts as submitted once it passes the validation rules of the European Supervisory Authorities. Missing service provider identifiers or contradictory information on functions lead to rejections. The European Supervisory Authorities also use the registers to designate critical ICT third-party service providers for direct EU oversight.
The real work is not in filling it in, but in gathering the information. Details are scattered across contracts, procurement, IT and the business units. If you only update the register for the reference date, you start your search from scratch every year. Sightadel therefore starts with the Vendors module: every service provider is maintained with contract, supported functions, criticality, locations and evidence as soon as it is engaged. New contracts, terminations and changed subcontractors are recorded there in everyday work, not in spring.
DORA mainly costs the time of people who are already fully stretched: information security, business continuity management, procurement, legal, internal audit and management. The Sightadel licence for DORA is charged monthly per edition, with discounts for multiple frameworks and advance payment. You can find all prices and a calculator on our pricing page.
External costs arise elsewhere and are invoiced by the respective providers themselves. In our experience, three items drive them most. First, contract amendments with service providers, often with legal support. Second, the testing programme, especially if you are identified for TLPT: a threat-led test with threat analysis, red team and closure work is a project lasting months. Third, collecting data for the register when contract records are incomplete.
Where you can save: if you run an ISMS under ISO 27001, you do not have to reinvent risk management, access control, backup and incident handling. In Sightadel, existing evidence is attached to both frameworks. We deliberately do not give a figure for the overlap, because it depends on the scope. Consulting for the difficult parts, such as determining critical or important functions, can be booked as a package in the app when needed.
DORA explicitly places responsibility for ICT risk in the hands of the management body. It defines and approves the framework, sets the roles, determines the risk appetite for ICT risk, approves the policies on business continuity and third parties, provides the budget and undergoes regular training. The work can be delegated, the responsibility cannot. Audits therefore ask what management has decided, how it is kept informed and which training its members can prove they have completed.
In Germany, BaFin penalises breaches under national supervisory law, which was amended to implement DORA's sanction requirements. Possible measures include orders, fines and, for serious shortcomings, further supervisory action. Critical ICT third-party service providers are subject to direct oversight by a European lead overseer, which issues recommendations and can impose periodic penalty payments calculated on the basis of average daily worldwide turnover.
Besides supervision, the civil law side matters. An unmanaged service provider failure, a late report or an untested backup can raise questions of damages towards clients and of liability towards management. How this is to be assessed in an individual case is something to clarify with your legal adviser. Sightadel does not provide legal advice, but ensures that resolutions, training and decisions are documented with a date and an owner.
The regulation does not give an exhaustive list, but a clear core follows from the regulation and the standards. It includes the documented ICT risk management framework together with the digital operational resilience strategy, policies on information security, access and change management and vulnerability management, an ICT business continuity policy with response and recovery plans, backup policies with evidence of tested restoration, an incident management process with classification criteria and an incident register, the testing programme with results, the strategy on ICT third-party risk, the register of information and exit strategies for service providers supporting critical or important functions.
The framework must be reviewed at least once a year, and also after major incidents and after findings from tests or audits. A report is prepared on this review, which the supervisor can request. Just as important is evidence that the documents are actually lived: approvals, training records, records of restore tests, remediated findings from tests and internal audit.
In Sightadel, each of these documents is assigned to a control, with version, approval and expiry date. If a piece of evidence expires, such as an annual restore test, it appears on the dashboard as an open item. That way the picture is complete not only on the audit date.
Every financial entity that does not fall under the simplified framework needs a risk-based digital operational resilience testing programme. Depending on the environment, this includes vulnerability assessments and scans, source code reviews, scenario-based tests, compatibility and performance tests, end-to-end tests and penetration tests. Systems supporting critical or important functions are tested appropriately at least once a year. Testers must be independent, whether internal or external.
Threat-led penetration testing, TLPT for short, only applies to entities identified for it by the supervisor and then usually takes place every three years. It follows its own technical standard, which is based on the European TIBER framework. A TLPT runs on live production systems and comprises a threat analysis, a covert attack by a red team and a joint closure phase. The supervisor accompanies the test and confirms at the end that it has been carried out.
The time after the test is often underestimated. Findings must be assessed, prioritised and remediated within deadlines, and the supervisor wants to see the progress. In Sightadel, every finding becomes an issue with an owner and a due date. The test itself is carried out by specialist testers; Sightadel records planning, results and remediation.
For financial entities, DORA is the more specific law in relation to NIS2. They meet their cybersecurity obligations through DORA, not twice. In groups with companies outside the financial sector, both regimes can apply side by side. It then pays to maintain measures and evidence only once and map them to both.
For entities within the scope of DORA, BaFin's previous IT circulars for banks, insurers, investment management companies and payment institutions have been superseded by the regulation. BaFin has published guidance on how existing requirements, for example on outsourcing management outside ICT, relate to DORA. Which parts continue to apply in your organisation should be clarified before the gap analysis.
ISO 27001 is not mandatory, but a proven framework. A certificate shows that a management system is running which supports DORA to a large extent. What DORA additionally requires is mainly the register, reporting deadlines, contract content and the testing programme. Attestations such as BSI C5 or SOC 2 from your service providers are valuable evidence when assessing them, but do not replace your own risk assessment.
What it costs
You only pay for the frameworks you actually need. The editions differ in capacity and response time, not in subject-matter scope. If you run several frameworks, you save permanently. All prices, discounts and a calculator are on the pricing page.
The certification or audit body invoices its fees directly to you. If needed, you can add consulting as a package in the app.
Working materials
↓DORA – implementation and evidence checklistChecklist · XLSX, PDFPractical aids, not legal advice.
Terms
Yes, if you are a financial entity within the meaning of the regulation – for example a credit institution, payment or e-money institution, investment firm, insurer, fund manager or crypto-asset service provider. As an ICT service provider to such entities, the requirements reach you through the contract, even if you are not supervised yourself.
Sanctions are based on national supervisory law. BaFin can order measures and impose fines. For critical ICT third-party service providers, the European Supervisory Authorities provide for their own periodic penalty payments. Responsibility for ICT risk lies explicitly with the management body.
No. DORA is a supervised regulation, not a certifiable standard. You demonstrate implementation to BaFin and your auditors. ISO 27001 certificates or C5 attestations help as evidence, but do not replace that demonstration.
For a major ICT-related incident: initial notification no later than four hours after classification and in any case no later than 24 hours after becoming aware, intermediate report within 72 hours, final report within one month. The exact reference points are set out in the technical standards.
A complete register of all contracts for ICT services, at the level of the individual entity and the group, with supported functions and subcontractors. It must be kept up to date and submitted to the supervisor regularly. The required information usually has to be gathered from contracts, procurement and operations.
Only if the supervisor identifies you for it. Then at least every three years. Everyone else needs a risk-based testing programme with vulnerability assessments, penetration tests and similar tests.
For financial entities, DORA takes precedence as the more specific law. You meet your cybersecurity obligations there. Sightadel serves both through the same evidence if parts of your group fall under NIS2.
No, deliberately not. The AI provides drafts from industry templates and helps with wording. You decide on critical functions, risk appetite and classification yourself – and that is exactly what the supervisor examines.
Once a year as at a reference date, within a time window set by BaFin, via its reporting and publishing platform. For 2026, the window was in March. The register must pass the validation rules of the European Supervisory Authorities. BaFin publishes the current dates.
For entities within the scope of DORA, BaFin's previous IT circulars have been superseded by the regulation. BaFin has published guidance on how existing requirements relate to DORA. Clarify before the gap analysis which parts continue to apply in your organisation.
14 days, full access, no payment details. Everything you set up carries over into the paid plan.
