Sightadel

Software · DORA

DORA software for ongoing supervision.
Not just for the next reporting date.

DORA software should prove that your institution complies with the Digital Operational Resilience Act: ICT risk management with responsibility of the management body, handling and reporting of incidents, resilience testing and management of ICT third parties including the register of information. This page shows what software must do for this, what to look for when choosing it and how Sightadel puts it into practice.

Starting point

What matters when choosing software.

DORA has applied to financial entities across the EU since January 2025. The regulation rests on five pillars: ICT risk management, handling and reporting of ICT-related incidents, digital operational resilience testing, management of ICT third-party risk and voluntary sharing of threat information. Technical standards of the European supervisory authorities set out the details; in Germany, the Federal Financial Supervisory Authority (BaFin) is responsible for supervision. There is no DORA certificate.

For software, four requirements are particularly decisive. The management body approves the ICT risk management framework and bears responsibility (Art. 5–6). Incidents are classified according to uniform criteria, major ones are reported, the initial notification no later than 24 hours after becoming aware (Art. 17–19). A risk-based testing programme applies to all, and certain entities additionally carry out threat-led penetration testing at least every three years (Art. 24–27). And the register of information records all contracts with ICT service providers (Art. 28).

The register is usually the most time-consuming part, because the information is not complete in any contract folder. DORA software should let it emerge from ongoing maintenance of the service providers, not from a collection exercise before the reporting date. Decisions such as risk appetite, the classification of critical or important functions and exit strategies stay with the management body.

Why now

Typical reasons to tackle the topic.

01

Annual submission of the register

BaFin requests the register of information once a year as at a reporting date. If you only update it shortly beforehand, you search from scratch every year.

02

Review by internal audit, statutory auditor or supervisor

They ask about the framework, its annual review, test results and how findings were worked through. Dated records count, not declarations of intent.

03

New or changed ICT service provider

Before the contract is concluded, a risk assessment and a review of the contract content under Art. 30 are required. Afterwards, the service provider has to go into the register.

04

Moving away from project spreadsheets

The first wave ran as a project with spreadsheets and shared drive folders. That is rarely enough for ongoing operation.

Relevant frameworks

What applies – and what it specifically requires here.

Summarised in our own words, not legal advice. The original text in its current version is authoritative.

DORAMandatory

For financial entities in the EU. In Sightadel 50 requirements with article reference and expected evidence. Closing existing gaps typically takes six to twelve months. There is a simplified framework for certain smaller entities.

View framework →
ISO/IEC 27001Recommended

ICT risk management, access control, backup and incident handling build on the same foundations. The register of information has no equivalent in ISO 27001.

View framework →
NIS2Depends on the situation

For financial entities, DORA takes precedence. Many measures overlap; the reporting deadlines differ in their starting point: DORA is tied to the classification, NIS2 to becoming aware.

View framework →
BSI C5:2026Depends on the situation

A cloud provider's C5 attestation is valuable evidence when assessing that service provider. It does not replace your own risk assessment.

View framework →
GDPRMandatory

Technical measures and data processing agreements draw on the same service provider data. One incident can trigger several reporting obligations.

View framework →

Recommended order

Where to start – and what comes next.

  1. 1

    Classification and scope

    Clarify which obligations apply, whether the simplified framework is an option and which functions are critical or important.

  2. 2

    Gap analysis

    Work through the 50 requirements step by step and map existing evidence from the ISMS, business continuity management and purchasing.

  3. 3

    Service providers and register

    Record service providers, contracts, supported functions and subcontractors. Existing lists come in via Excel import.

  4. 4

    Incident process and reporting channels

    Define classification criteria, responsibilities and reporting channels and run through them once.

  5. 5

    Close gaps and adapt contracts

    Action plans with owners and deadlines. Contract amendments often take longest, because the other side has to play along.

  6. 6

    Test and review

    Carry out the testing programme, review the framework annually, keep the register up to date. After that, these steps recur as a cycle.

Selection

What to look for when choosing DORA software

Many tools cover individual pillars, such as only the register or only incident management. Check whether the software holds all obligations together and suits your size.

Article reference for each requirement

Each requirement should refer to the article of the regulation and name the expected evidence. That way, questions from internal audit can be mapped directly.

Register from ongoing maintenance

Service providers, contracts, supported functions and criticality should be maintained in one place. The register must not be a separate reporting-date project.

Separate reporting deadlines

If you also report under NIS2 or the GDPR, you need a clean separation of the starting points. DORA is tied to the classification as major, NIS2 to becoming aware.

Testing programme with tracking of findings

Tests should be planned as recurring dates and findings tracked with a deadline and an owner. The threat-led test itself is carried out by specialised testers.

Evidence from the management body

Approval of the framework, decisions and management training should be filed with a date. They come first in every review.

Proportionality

A small institution has the same obligation, but does not need the same apparatus as a major bank. Make sure the software can be used without a long introduction.

Effort and duration

An honest estimate.

Small institution under the simplified framework3–6 months
Up to a robust body of evidence. Less documentation, but the register, incident reporting and contracts still apply. The deciding factor is usually the number of service providers.
Institution with an existing ISMS4–8 months
Risk management and incident handling are in place. The effort lies in the register, contract amendments and the testing programme.
Institution without a structured ISMS6–12 months
Framework, policies, processes and register are largely built from scratch. Contract amendments often take longest.

The ranges are based on experience, not a commitment. The register of information and the contract amendments usually set the pace, not the software.

What you license · typically Professional

A typical institution runs DORA together with ISO 27001 as a foundation in the Professional edition. With many ICT service providers or several subsidiaries, Enterprise is the right choice. If ISO 27001 is included, DORA permanently costs less.

Licence per framework, minimum term one year, payable monthly or annually. You will find all prices, discounts and a calculator on the pricing page. Fees of a certification or audit body are charged separately.

Questions and answers

Questions about DORA software

More in our FAQ or directly via our contact form.

Do I need software for DORA?

The regulation does not prescribe software. It requires a documented framework, a complete register of information, traceable incident handling and a testing programme. With few service providers, spreadsheets will do. With many contracts, several people involved and annual submission, a system pays off.

Excel or DORA software?

Many institutions used spreadsheets for the first submission. Every contract change, every new service provider and every test then has to be added by hand. Existing lists can be imported into Sightadel.

How much does DORA software cost?

Sightadel is licensed per framework and edition, annually. The current amounts are on the pricing page. If ISO 27001 is already licensed, DORA permanently costs less. You can try it free for 14 days, without payment details.

Does the software replace consultants or auditors?

No. Sightadel guides you through the requirements and records the status. You choose consultants from the partner network in the app or bring your own. Reviews by internal audit, statutory auditors and supervisors remain unaffected. Sightadel does not certify and receives no commission.

What does the management body decide itself?

It approves the ICT risk management framework, sets the risk appetite, decides on the classification of critical or important functions and provides resources. Sightadel provides drafts and records the decisions with a date. The management body makes the decisions itself.

Does Sightadel carry out threat-led penetration testing?

No. TLPT is carried out by specialised testers. Sightadel records planning, results and how the findings are worked through. More on the requirements on the page on DORA.

Where is our data stored?

Sightadel is developed in Germany and operated in Germany.

Content reviewed by experts on 10 October 2026 · Not legal advice. The standard or law in its current version is authoritative.

Start with one standard.

14 days, full access, no payment details. Everything you set up carries over into the paid plan.