DORA-Compliance für IT-Entscheider: Technische Anforderungen und Azure-Implementierungsleitfaden

Der Digital Operational Resilience Act stellt die bedeutendste regulatorische Veränderung in der Finanzdienstleistungs-IT seit der DSGVO dar. Anders als frühere Regulierungen, die sich primär auf den Datenschutz konzentrierten, zielt DORA auf die operationelle Resilienz der digitalen Infrastruktur selbst ab. Für IT-Entscheider im Finanzsektor ist dies keine Checkbox-Übung — es erfordert grundlegende Änderungen in der Art und Weise, wie Sie Ihre Cloud-Umgebungen architekturieren, überwachen, testen und steuern.

Dieser Leitfaden gliedert DORA in seine fünf Säulen, ordnet jede konkreten Azure-Implementierungsmustern zu und liefert einen realistischen Zeitplan für die Erreichung der Compliance.

Die fünf Säulen von DORA

DORA ist um fünf miteinander verbundene Säulen strukturiert. Jede erfordert spezifische technische Kontrollen, die gegenüber Regulierungsbehörden nachweisbar sein müssen.

Säule 1: ICT-Risikomanagement-Framework

DORA schreibt ein umfassendes ICT-Risikomanagement-Framework vor, das in das Gesamtrisikomanagement integriert sein muss. Dies ist kein separates Dokument — es muss in operative Prozesse eingebettet sein.

Zentrale Anforderungen:

• Identifizierung und Klassifizierung aller ICT-Assets, Systeme und Abhängigkeiten
• Kontinuierliche Risikobewertung von ICT-Systemen, die kritische oder wichtige Funktionen unterstützen
• Implementierung von Schutz- und Präventionsmaßnahmen proportional zum Risiko
• Einrichtung von Erkennungsmechanismen für anomale Aktivitäten
• Pflege von Business-Continuity- und Disaster-Recovery-Plänen spezifisch für ICT-Störungen

Azure-Implementierung:

Die Grundlage ist ein vollständiges Asset-Inventar. Azure Resource Graph liefert abfragbare Metadaten über alle Subscriptions. Kombinieren Sie dies mit dem Asset-Inventar von Microsoft Defender for Cloud für eine sicherheitsangereicherte Ansicht.

// Azure Resource Graph Query — alle Ressourcen mit Sicherheitsstatus
Resources
| where type != "microsoft.resources/subscriptions"
| join kind=leftouter (
    securityresources
    | where type == "microsoft.security/assessments"
    | extend resourceId = tostring(properties.resourceDetails.Id)
) on $left.id == $right.resourceId
| project name, type, location, subscriptionId, riskLevel=properties1.status.code

Für die kontinuierliche Risikobewertung aktivieren Sie Microsoft Defender for Cloud mit dem Defender CSPM-Plan. Konfigurieren Sie Governance-Regeln für die automatische Zuweisung von Verantwortlichkeiten:

• Kritische Findings: 7-Tage-Remediation-SLA
• Hohe Findings: 14-Tage-Remediation-SLA
• Mittlere Findings: 30-Tage-Remediation-SLA

Ordnen Sie jede kritische Geschäftsfunktion ihren unterstützenden Azure-Ressourcen zu, unter Verwendung von Azure Service Map und Application Insights Dependency Tracking. Dies liefert die Abhängigkeitskette, nach der Regulierungsbehörden fragen werden.

Säule 2: ICT-bezogenes Incident Management

DORA erfordert einen strukturierten Incident-Management-Prozess mit spezifischen Klassifizierungskriterien, Eskalationsverfahren und verpflichtender Meldung an zuständige Behörden innerhalb strenger Fristen.

Zentrale Anforderungen:

• Klassifizierung von Incidents anhand der DORA-Kriterien: Anzahl betroffener Kunden, geografische Verbreitung, Datenverlust, Kritikalität betroffener Services, wirtschaftliche Auswirkungen, Dauer
• Einreichung der Erstmeldung an die zuständige Behörde innerhalb von 4 Stunden nach Klassifizierung eines schwerwiegenden ICT-bezogenen Incidents
• Einreichung eines Zwischenberichts innerhalb von 72 Stunden
• Einreichung eines Abschlussberichts innerhalb eines Monats

Azure-Implementierung:

Microsoft Sentinel ist der Anker für das DORA-Incident-Management. Erstellen Sie ein dediziertes DORA-Incident-Klassifizierungs-Workbook, das Incidents automatisch gegen DORA-Kriterien bewertet.

Konfigurieren Sie Sentinel Analytics Rules zur Erkennung und Klassifizierung von Incidents:

• Automation Rules, die auslösen, wenn spezifische Bedingungen DORA-Schwellenwerte für schwerwiegende Incidents erreichen
• Playbooks (Logic Apps), die Incident-Berichte vorausfüllen und an das Compliance-Team weiterleiten
• Watchlists mit DORA-Klassifizierungsschwellenwerten und Kontaktdaten der zuständigen Behörden

Die Meldekette sollte so weit wie möglich automatisiert sein:

Säule 3: Digital Operational Resilience Testing

Diese Säule erfordert regelmäßige Tests Ihrer ICT-Systeme, von grundlegenden Tests bis hin zu fortgeschrittenen Threat-Led Penetration Tests (TLPT) für bedeutende Finanzunternehmen.

Zentrale Anforderungen:

• Grundlegende Tests mindestens jährlich: Vulnerability Scanning, Netzwerksicherheitsbewertungen, Gap-Analysen, Software Composition Analysis, Performance-Tests
• Fortgeschrittene TLPT für bedeutende Unternehmen mindestens alle drei Jahre, durchgeführt von qualifizierten externen Testern unter Verwendung von Frameworks wie TIBER-EU
• Testergebnisse müssen in das Risikomanagement-Framework zurückfließen

Azure-Implementierung:

Für grundlegende Tests erstellen Sie eine kontinuierliche Test-Pipeline:

• Vulnerability Scanning: Microsoft Defender for Cloud's integrierter Qualys-Scanner für VMs, Defender for Containers für Container-Images und Defender for SQL für Datenbank-Schwachstellen
• Netzwerksicherheitsbewertung: Azure Network Watcher's NSG Flow Log-Analyse kombiniert mit Defender for Cloud's Netzwerktopologie-Ansicht
• Software Composition Analysis: GitHub Advanced Security oder Azure DevOps mit aktiviertem Dependency Scanning in jeder Pipeline

Für Resilience Testing bietet Azure Chaos Studio kontrollierte Fault Injection:

{
  "type": "Microsoft.Chaos/experiments",
  "properties": {
    "selectors": [
      {
        "type": "List",
        "id": "selector1",
        "targets": [
          {
            "id": "/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Compute/virtualMachines/{vm}/providers/Microsoft.Chaos/targets/microsoft-agent",
            "type": "ChaosTarget"
          }
        ]
      }
    ],
    "steps": [
      {
        "name": "Step1",
        "branches": [
          {
            "name": "Branch1",
            "actions": [
              {
                "type": "continuous",
                "name": "urn:csci:microsoft:agent:cpuPressure/1.0",
                "duration": "PT10M",
                "parameters": [
                  { "key": "pressureLevel", "value": "95" }
                ],
                "selectorId": "selector1"
              }
            ]
          }
        ]
      }
    ]
  }
}

Führen Sie Chaos-Experimente monatlich gegen Non-Production und quartalsweise gegen Production durch (innerhalb von Wartungsfenstern). Dokumentieren Sie jedes Experiment mit Hypothese, Ausführungsnachweis und Remediationsmaßnahmen.

Säule 4: Third-Party-ICT-Risikomanagement

DORA erlegt direkte Verpflichtungen auf, wie Finanzunternehmen ihre ICT-Drittanbieter managen müssen, einschließlich vertraglicher Anforderungen, Konzentrationsrisikoanalyse und Exit-Strategien.

Zentrale Anforderungen:

• Pflege eines Registers aller ICT-Drittanbieter-Vereinbarungen
• Durchführung von Due Diligence und Risikobewertungen vor Vertragsabschluss
• Aufnahme verpflichtender vertraglicher Bestimmungen (Datenstandort, Prüfungsrechte, Exit-Strategien, Unterauftragsketten)
• Überwachung des Konzentrationsrisikos auf Unternehmens- und Sektorebene
• Pflege gangbarer Exit-Strategien für alle kritischen ICT-Anbieter

Azure-Implementierung:

Für Microsoft Azure selbst als Drittanbieter dokumentieren Sie das Shared-Responsibility-Modell explizit. Microsoft veröffentlicht DORA-spezifische Compliance-Dokumentation — laden Sie diese herunter und integrieren Sie sie in Ihr Drittanbieter-Register.

Für das breitere Drittanbieter-Register erstellen Sie einen strukturierten Datensatz:

• Verwenden Sie den API-Katalog von Azure API Management zur Inventarisierung aller externen API-Abhängigkeiten
• Nutzen Sie Azure DevOps oder GitHub Dependency Graphs zur Abbildung der Software-Supply-Chain-Anbieter
• Pflegen Sie ein SharePoint- oder datenbankbasiertes Register mit den von DORA vorgeschriebenen Feldern: Anbietername, erbrachte Services, Kritikalitätsbewertung, Datenstandorte, Vertragsablauf, Exit-Plan-Status

Säule 5: Information Sharing

DORA ermutigt (verpflichtet aber die meisten Unternehmen nicht) zur Teilnahme an Threat-Intelligence-Sharing-Vereinbarungen.

Azure-Implementierung:

• Verbinden Sie Sentinel mit der Microsoft Threat Intelligence Community
• Abonnieren Sie sektorspezifische ISAC-Feeds und integrieren Sie diese in Sentinel's Threat Intelligence Blade
• Nutzen Sie Sentinel's Threat Intelligence Workbook zur Verfolgung von Indikator-Volumen und Erkennungsraten
• Etablieren Sie eine formelle Information-Sharing-Vereinbarung mit gleichrangigen Institutionen

Implementierungs-Timeline

Ein realistischer DORA-Implementierungs-Zeitplan fuer eine Organisation, die von einem moderaten Reifegrad startet:

Monate 1-2: Assessment und Gap-Analyse

• Inventarisierung aller ICT-Assets und Drittanbieter-Vereinbarungen
• Bewertung des Ist-Zustands gegen jede DORA-Säule
• Identifizierung von Gaps und Priorisierung nach regulatorischem Risiko

Monate 3-4: Grundlagen

• Deployment von Defender for Cloud über alle Subscriptions mit Defender CSPM
• Aktivierung von Sentinel mit DORA-spezifischen Analytics Rules
• Etablierung des Incident-Klassifizierungs- und Meldeworkflows
• Beginn der Befüllung des Drittanbieter-Registers

Monate 5-8: Aufbau

• Implementierung des Resilience-Testing-Programms (Chaos Studio Experiments)
• Aufbau automatisierter Compliance-Reporting-Dashboards
• Konfiguration von Governance-Regeln mit Remediation-SLAs
• Durchführung der ersten Vulnerability-Assessment-Runde und Remediation kritischer Findings

Monate 9-10: Test und Validierung

• Durchführung vollständiger Incident-Response-Übungen mit Simulation schwerwiegender DORA-Incidents
• Ausführung von Chaos-Experimenten gegen Production
• Validierung der Meldefristen (4 Stunden, 72 Stunden, 1 Monat)
• Durchführung von Tabletop-Übungen zu Third-Party-Exit-Strategien

Monate 11-12: Steady State und Audit-Readiness

• Zusammenstellung von Evidenz-Paketen für jede Säule
• Durchführung eines internen Audits gegen DORA-Anforderungen
• Behebung von Findings und Übergang in den kontinuierlichen Monitoring-Modus
• Einbindung externer Assessoren bei Bedarf

Azure Policy für Continuous Compliance

Definieren Sie eine benutzerdefinierte Azure Policy Initiative, die Ihre DORA-Kontrollanforderungen kodifiziert. Dies bietet kontinuierliches Compliance-Scoring und verhindert Drift.

Wichtige Policies:

• Defender for Cloud muss aktiviert sein auf allen Subscriptions
• Diagnostic Settings müssen konfiguriert sein für alle kritischen Ressourcen
• Network Security Groups dürfen keinen uneingeschränkten Zugang auf Management-Ports erlauben
• Storage Accounts müssen Verschlüsselung mit Customer-Managed Keys für als kritisch klassifizierte Daten erzwingen
• Key Vault muss Soft Delete und Purge Protection aktiviert haben
• SQL-Datenbanken müssen Auditing aktiviert haben
• Container Registries dürfen keinen anonymen Pull erlauben

Häufige Fallstricke

DORA als Dokumentationsübung behandeln. Regulierungsbehörden werden nach Nachweisen operativer Kontrollen fragen, nicht nur nach Policies. Jede Kontrolle muss Monitoring, Alerting und Ausführungsnachweise haben.

Das ICT-Drittanbieter-Register ignorieren. Viele Organisationen unterschätzen den Umfang. Jedes SaaS-Tool, jede API-Integration und jeder Managed-Service-Provider zählt. Beginnen Sie früh mit der Inventarisierung.

Das 4-Stunden-Erstmeldungsfenster unterschätzen. Vier Stunden von der Klassifizierung (nicht von der Erkennung) bis zur Meldung ist knapp. Ohne Automatisierung werden Sie es verfehlen. Bauen und testen Sie die automatisierte Meldekette, bevor Sie sie benötigen.

Exit-Strategien vernachlässigen. DORA erfordert gangbare Exit-Pläne für alle kritischen ICT-Anbieter. Das bedeutet, Sie müssen nachweisen, dass Sie innerhalb eines angemessenen Zeitrahmens von Azure (oder jedem kritischen Anbieter) migrieren können. Dokumentieren Sie den Plan, schätzen Sie die Kosten und testen Sie mindestens den Datenexport-Teil.

Fazit

DORA-Compliance ist kein einmaliges Projekt. Es erfordert nachhaltige operative Disziplin, kontinuierliches Monitoring und regelmäßige Tests. Die Azure-Plattform bietet starke native Werkzeuge für jede Säule, aber die Werkzeuge allein sind keine Compliance — Sie brauchen die Prozesse, Governance und Kultur, damit es funktioniert.

Wenn Sie DORA-Compliance navigieren und erfahrene Beratung zu Architektur, Tooling und regulatorischer Strategie benötigen, kontaktieren Sie uns unter mbrahim@conceptualise.de. Wir helfen Finanzinstituten, resiliente, konforme Cloud-Umgebungen aufzubauen, die Regulierungsbehörden zufriedenstellen, ohne die operative Geschwindigkeit zu opfern.