DORA & eramba: Resilience Management (Updated 2026)
As of early 2026, the Digital Operational Resilience Act (DORA) is under active enforcement. Eramba serves as the central “Governance Brain” to track compliance across all five pillars.
We structured this document based on the 4 pillars and for each one of them briefly described what eramba can and can not do.
- ICT-Related Incident Reporting
- Digital Operational Resilience Testing
- ICT Third-Party Risk Management
- Information Sharing
It is important to note that while DORA is a European-wide directive, each country has its own particularities regarding best practices and how organisations are audited (by whom, how often, etc.). Therefore, this guide works everywhere, but there may be specific differences in each country.
A big deal in DORA is the “Register of Information” (Pillar 4), a very complicated set of CSV-ish files formatted by the NCAs (National Competent Authority) that must be submited every year and “upon request”. eramba can not help you here, this files have a very complicated structure and submission is not automated (as of end of 2025).
We provide a summary of the files and related articles as part of the:
- * Register of Information
And as a final piece of help we provide you the full list of Articles and in which ones eramba can fully or partially help and with which use case.
- * Compliance Analysis & Summary
1 - ICT Risk Management Framework (Arts. 5–16)
DORA requires a framework owned by the Board that identifies, protects, and recovers ICT assets.
What eramba CAN do:
- Board Accountability: Use the Policy Module to store ICT strategies and the Awareness Module to track mandatory Board cybersecurity training and policy acknowledgments.
- Asset Context (Not Inventory): Use the Asset Module to categorize “Data,” “Hardware,” and “Software” assets. Crucially, link these to Business Units and Processes to define “Critical or Important Functions” (CIF).
- Multi-Method Risk (Art. 6): Build DORA-specific risk methodologies in the Risk Module. It supports Asset, Third-Party, and Business Risk, allowing you to use custom matrixes (Impact x Likelihood).
- The “Problem vs. Solution” Mapping: Link Risks (Problems) to Internal Controls and Policies (Solutions). This creates a live map showing exactly which control mitigates which DORA requirement.
The RTS (Regulatory Technical Standards) does not mandate how risk calculation must be performed, but it does require certain specifications, all supported by Eramba (likelihood and impact; quantitative or qualitative approaches are acceptable; and annual reviews).
What eramba CANNOT do:
- Technical Asset Discovery: eramba is not a network scanner. It cannot automatically “find” new servers. It is a database that should be synced with your CMDB (e.g., Jira, ServiceNow) via REST API.
- Automated Hardening: It cannot “push” a configuration change to a firewall or encrypt a drive. It only audits that these activities were done.
2 - ICT-Related Incident Reporting (Arts. 17–23)
Standardizes the classification and reporting of “Major” incidents within tight windows.
What eramba CAN do:
- Automated Workflows: Use the Incident Module to enforce a lifecycle. Use Dynamic Status to automatically move an incident to “Major” if specific custom fields (e.g., users affected > 10%) are triggered.
- SLA & Timeline Management: Set Notifications (Email/REST) triggered by the “Date of Classification.” You can configure alerts for the 4-hour (Initial), 72-hour (Intermediate), and 1-month (Final) deadlines.
- Technical Integration: It can receive incident data automatically from your SIEM (Splunk, Sentinel) via the REST API, initiating the GRC workflow without manual entry.
What eramba CANNOT do:
- Direct Regulatory Submission: eramba cannot “e-file” the report to the ESA/National Authority. You must export the incident data to the required regulatory template (Excel/CSV).
The reason we cannot automatically submit incidents to NCAs (National Competent Authorities) is that you will most likely want to review what is sent. Additionally, these authorities use a proprietary xBRL-CSV formatted file (ITS 2025/302 and the EBA/ESMA DPM 4.0 technical packages), which cannot be submitted over REST (at least not in all EU countries).
3 - Digital Operational Resilience Testing (Arts. 24–27)
Proving systems can handle “worst-case scenarios” through annual testing and TLPT.
What eramba CAN do:
- Audit & Maintenance Sub-Modules: Use the Internal Control Module to distinguish between Audits (Testing if it works) and Maintenance (Keeping it running, e.g., monthly patch reviews).
- Testing Program Management: Schedule recurring “Audits” for all ICT controls. eramba sends automated evidence requests to technical owners.
- Gap & Finding Management: Any failed test automatically creates a Finding in the Audit Findings Module. You can then track Corrective Actions (Projects) with strict deadlines to prove remediation to auditors.
What eramba CANNOT do:
- Vulnerability Scanning: It does not replace Nessus or Qualys. It consumes their results to track the management of the vulnerabilities they find.
4 - ICT Third-Party Risk Management (Arts. 28–44)
Management of the supply chain, including contractual clauses and the Register of Information.
What eramba CAN do:
- Online Assessments (OAs): This is eramba’s core for Pillar 4. You can send automated Questionnaires (via the OA Module) to vendors. Responses automatically update the vendor’s risk score and can trigger Findings for non-compliance.
- Register of Information (RoI): Use the Third Party Module to store the mandatory vendor metadata. Use Custom Fields to track fourth-party (sub-contractor) dependencies.
- Contract Review Lifecycles: Track “Right to Audit” and “Exit Strategy” clauses. eramba triggers notifications months before a contract expires to ensure DORA clauses are updated.
What eramba CANNOT do:
- Supply Chain “Discovery”: It won’t find your shadow-IT SaaS vendors. You must import them or link eramba to your procurement system/CASB.
5 - Information Sharing (Art. 45)
Voluntary exchange of cyber-threat intelligence (CTI) within the financial community.
What eramba CAN do:
- Membership & Evidence: Track your participation in ISACs or sharing forums in the Third Party Module. Use the Compliance Analysis module to store meeting minutes as “Evidence” of active engagement.
- Intelligence Distribution: Use the Awareness Module to push “Lessons Learned” from external sources to your internal technical teams.
What eramba CANNOT do:
- Live Threat Intelligence Feed: It is not a Threat Intelligence Platform (TIP). It does not ingest STIX/TAXII feeds directly to block IPs.
Register of Information
| Pillar | Article | What the file must contain (Brief) | Number of Fields | Related RT’s |
|---|---|---|---|---|
| 4 | 28(3) | Reporting Entity: Info on the firm maintaining the register. | 13 | RT.01.01 |
| 4 | 28(3) | Group Structure: Info on all entities within the scope of consolidation. | 11 | RT.01.02 |
| 4 | 28(3) | Branches: List of branches receiving ICT services. | 9 | RT.01.03 |
| 4 | 28(3) | Contracts (General): High-level data on ICT contractual arrangements. | 31 | RT.02.01 |
| 4 | 28(3) | Contracts (Specific): Detailed dates, data location, and sensitive data flags. | 22 | RT.02.02 |
| 4 | 28(3) | Intra-group Contracts: Connections between group and non-group providers. | 12 | RT.02.03 |
| 4 | 28(3) | Contract Signatories: Entities that legally signed the arrangement. | 19 | RT.03.01 |
| 4 | 28(3) | Provider Identifiers: Legal names, LEI, and “Parent” company details. | 18 | RT.03.02 |
| 4 | 28(3) | Service Signatories: Identification of specific group providers. | 15 | RT.03.03 |
| 4 | 28(3) | Service Users: Which specific legal entity is using which ICT service. | 12 | RT.04.01 |
| 4 | 28(3) | Service Categories: Classification of the ICT services provided. | 13 | RT.05.01 |
| 4 | 28(9) | Supply Chain (4th Parties): Identification of critical subcontractors. | 17 | RT.05.02 |
| 4 | 28(3) | Functions Identification: List of critical or important functions (CIF). | 12 | RT.06.01 |
| 4 | 28(3) | Risk Assessments: Audit dates, exit plan flags, and substitutability. | 14 | RT.07.01 |
| 4 | — | Definitions: Technical look-up table for data consistency. | 7 | RT.99.01 |
Compliance Analysis
The following table summarises DORA requirements and which modules in Eramba can help you. At the end of the table, we provide a text summary.
| Chapter / Pillar | Articles | Requirement Brief | eramba Support | Primary Use Case(s) |
|---|---|---|---|---|
| Pillar 1: ICT Risk Management | 5.1 - 6.5 | Governance, Framework & Ownership | Fully | Compliance Management, Risk Management |
| 7.1 - 8.4 | Identification, Assets & Systems | Partially | Compliance Management, Internal Controls | |
| 9.1 - 9.4 | Protection & Prevention (MFA, Encryption) | Partially | Data Privacy, Account Reviews, Internal Controls | |
| 10.1 - 11.7 | Detection & Business Continuity | Fully | Compliance Management, Internal Controls | |
| Pillar 2: Incident Reporting | 17.1 - 18.4 | Incident Classification & Mgmt | Fully | Incident Management, Compliance Management |
| 19.1 - 23.3 | Regulatory Reporting & Timelines | Fully | Incident Management, Compliance Management | |
| Pillar 3: Resilience Testing | 24.1 - 25.6 | Basic Testing & Vulnerability Mgmt | Fully | Internal Controls, Compliance Management |
| 26.1 - 27.5 | Advanced Testing (TLPT) | Fully | Risk Management, Compliance Management | |
| Pillar 4: Third-Party Risk | 28.1 - 29.6 | TPRM Strategy & Register of Info | Fully | Compliance Management, Online Assessments |
| 30.1 - 30.5 | Mandatory Contractual Clauses | Fully | Compliance Management, Online Assessments | |
| Pillar 5: Info Sharing | 45.1 - 45.4 | Cyber Threat Intelligence Exchange | Partially | Compliance Management, Risk Management |
Fully Supported
-
Compliance Management: Every item in your CSV file (e.g., Article 5.1, 5.2.a) can be uploaded into eramba as a “Compliance Requirement.” You then map these directly to your internal policies and controls to track fulfillment percentages for auditors.
-
Incident Management (Pillar 2): eramba’s native module handles the lifecycle of an incident. You can use custom fields to calculate “Major Incident” status and set notifications for the 4h/72h/1m reporting deadlines.
-
Online Assessments (Pillar 4): This module is designed to send automated DORA-specific questionnaires to your third-party providers, pulling their risk data directly back into your register.
-
Internal Controls (Pillar 3): You use this to schedule recurring audits of your security controls. If a DORA test fails, eramba automatically creates a “Finding” and a “Corrective Action.”
Partially Supported
-
Identification & Systems (Pillar 1): eramba provides the database to store your asset inventory and link it to business processes (BIA), but it cannot discover the hardware on your network. You must import this data or sync via REST API.
-
Protection & Prevention (Pillar 1): eramba tracks that you have an encryption policy (Data Privacy) and audits its effectiveness, but it does not perform the technical encryption or block access itself.
-
Information Sharing (Pillar 5): eramba acts as the record-keeper for your participation in sharing communities but does not provide the real-time technical feed of threat data.
Specific Use Case Mapping
-
Risk Management: Used for Article 6 (ICT Risk Framework) to calculate impact/likelihood scores.
-
Compliance Management: Used for all Chapters to map the CSV requirements to evidence.
-
Incident Management: Used exclusively for Chapter 3 (Articles 17-23).
-
Data Privacy: Used for Article 12 (Data Protection) and tracking GDPR-related DORA requirements.
-
Online Assessments: Used for Chapter 5 (TPRM) to audit vendors.
-
Account Reviews: Used for Article 9 (Access Rights) to perform periodic “User Access Reviews.”
-
Internal Controls: Used for Pillar 3 testing and Pillar 1 control audits.