Financial Services Solutions

ICT Risk Management under DORA

ICT risk register, third-party register and incident reporting under DORA for financial services.

Art. 5-16 in Detail: What BaFin Examines

Articles 5 through 16 of the DORA regulation form the foundation of the entire regulatory framework. They define how financial entities must identify, assess, manage, and monitor their ICT risks. For BaFin, these articles are the primary examination area in DORA investigations. The expectation is clear: not just documentation but demonstrable implementation.

Art. 5 establishes the governance foundation. Your institution's management body bears overall responsibility for the ICT risk management framework. This does not mean mere acknowledgment but active steering: the management body must approve the ICT risk strategy, review it regularly, and adjust it as needed. It must ensure that sufficient resources (budget, personnel, technology) are allocated to ICT risk management. And it is personally liable if these duties are neglected.

Art. 6 specifies the ICT risk management framework itself. Your institution must maintain a documented framework that includes at minimum: an ICT risk strategy, an ICT risk appetite, policies for identifying and assessing ICT risks, procedures for treatment and monitoring, and clear roles and responsibilities. BaFin expects this framework to be actively lived, not filed away in a drawer. That means: regular reviews, documented changes, and evidence of implementation.

Art. 8 addresses the identification and classification of ICT assets. Every financial entity must maintain a complete, current inventory of all ICT assets. This includes hardware, software, network components, databases, and cloud services. Each asset must be classified: Who is the owner? Which business processes depend on it? What is its criticality? Without this inventory, a sound risk analysis is impossible.

Art. 9 and 10 deal with protection and prevention. Your institution must implement technical and organizational measures that correspond to the state of the art: patch and vulnerability management, access control following the least-privilege principle, network segmentation, encryption of sensitive data, and physical security for ICT infrastructure. BaFin examines not only whether these measures exist but whether they are effective and regularly tested.

Art. 11 requires business impact analyses and recovery plans. For every critical business function, it must be clearly defined: what is the maximum tolerable downtime (Recovery Time Objective)? How much data loss is acceptable (Recovery Point Objective)? Recovery plans must be regularly tested, and test results must be documented and reported to the management body.

Building the ICT Risk Register

The ICT risk register is the central management instrument for your ICT risk management under DORA. It is more than a simple list of risks. It is a structured, living document that maps the entire risk cycle: identification, assessment, treatment, and monitoring.

Register structure: Each risk entry should contain at minimum: a unique risk ID, a description of the risk, affected ICT assets and business processes, likelihood of occurrence, potential impact, the resulting risk score, the risk owner (by name and function), current treatment status, and defined mitigations. BaFin expects every risk to be assigned to a specific responsible person who is accountable for implementing the mitigations.

Risk assessment methodology: DORA does not prescribe a specific methodology, but BaFin expects a traceable, consistent assessment. A combination of qualitative assessment (risk matrix with likelihood and impact) and quantitative substantiation where possible has proven effective. For critical risks, you should run scenarios: what happens in the event of a complete core banking application outage for 24 hours? What are the financial and operational impacts of data loss at a cloud provider?

Classification: Your register should categorize risks into at least four levels: critical, high, medium, and low. Critical risks are those that, if they materialize, could substantially threaten your institution's business operations, such as a total payment processing outage or large-scale data loss. For each category, clear escalation paths and treatment deadlines must be defined.

Maintenance and review: The register is not a one-time project. DORA requires regular reviews, at least annually and additionally after material changes (new systems, outsourcings, security incidents). The management body must be informed about the current state of the register and top risks. A risk register that has not been updated for twelve months is a red flag for BaFin.

Third-Party Register under Art. 28

Art. 28 DORA requires every financial entity to maintain a complete register of all ICT third-party providers. This covers every external service provider that delivers ICT services for your institution: cloud providers, data centers, software vendors, managed service providers, as well as specialized fintech service providers and data suppliers.

The register must document for each provider at minimum: contract status, services provided, criticality of services for business processes, data location, subcontracting arrangements, and exit strategy. BaFin places particular emphasis on concentration risks: if a large portion of your critical IT infrastructure resides with a single provider (for example AWS or Azure), you must explicitly assess this risk and define mitigation measures. This may include alternative provider strategies, multi-cloud approaches, or contractually agreed backup solutions.

Due diligence requirements for ICT third-party providers are significantly stricter under DORA than under BAIT. Before contract conclusion, you must assess the provider's information security, contractually agree on audit rights, and ensure that the provider has implemented appropriate ICT risk management measures. For critical or important functions, enhanced requirements apply: BaFin must be informed in advance, and exit plans must be practically executable.

ICT risk management in real time

This is what the ICT risk register looks like in Kopexa. Select a framework, review risks, manage mitigations.

Discover risk management
RiskSeverityOwnerStatus
IT system outage risk
HighIT LeadIn Progress
Third-party dependency
MediumProcurementOpen
Cyber attacks
CriticalCISOIn Progress
Data loss
LowDPOMitigated
Compliance breach
MediumComplianceOpen

Incident Reporting under Art. 17-23

DORA's reporting obligations for ICT-related incidents are substantially more structured than previous regulations. Art. 17 first requires a robust process for detecting, managing, and reporting ICT incidents. This process must encompass clearly defined roles, escalation paths, and communication channels.

Art. 18 establishes the classification criteria for incidents. An ICT incident is classified as major when it exceeds certain thresholds: duration of the outage, number of affected clients, amount of financial damage, data loss, or impact on critical services. The specific thresholds are defined in the RTS/ITS.

Reporting deadlines are staggered. Within 4 hours of classification as major, an initial notification must be submitted to BaFin. Within 72 hours, a detailed interim report follows with root cause analysis and measures taken. The final report is due within one month of the incident and must comprehensively document the causes, impacts, and lessons learned. Your institution must maintain the technical infrastructure to submit these reports on time and in the formats required by BaFin.

How Kopexa Helps

The requirements of DORA Art. 5-16 are complex but manageable with the right tool support. Kopexa provides you with the tools you need to implement the DORA requirements in a structured manner:

  • ICT Risk Register: Build your risk register directly in Kopexa with preconfigured fields that match DORA requirements. Risk owners, mitigation tracking, and review cycles are built in.
  • Third-Party Overview: Manage your ICT third-party register with Kopexa. Capture contracts, criticality, data location, and concentration risks in one central place.
  • Policy Management: Create, version, and distribute policies with integrated approval workflows. Kopexa tracks who has read and acknowledged each policy.
  • Evidence Collection: Collect evidence for BaFin audits centrally. Each piece of evidence is linked to the relevant DORA article and exportable.

With Kopexa, you reduce the effort for DORA compliance by 40 to 60% compared to manual processes. Instead of spreadsheets and email chains, you work with an integrated platform that covers the entire compliance lifecycle.

Next Steps

Want to dive deeper into related topics? Here you will find further resources:

Let's assess where you stand together

Free & non-binding

By submitting, you agree to our Privacy Policy .