Überblick

Das Finanzmarktdigitalisierungsgesetz (FinmadiG) wurde am 27.12.2024 im Bundesgesetzblatt veröffentlicht und dient der nationalen Durchführung von DORA, MiCAR und der Geldtransferverordnung.

Wesentliche DORA-relevante Regelungen

Erweiterter Anwendungsbereich (§ 1a Abs. 2a KWG n.F.)

Ab 01.01.2027 fallen zusätzlich unter DORA:

Übergangsregelung (§ 65a Abs. 3 KWG n.F.)

Für die neu hinzukommenden Institute gilt:

• Ab 17.01.2025: Meldepflichten für schwerwiegende IKT-Vorfälle (Kapitel III DORA)
• Ab 01.01.2027: Voller IKT-Risikomanagementrahmen (für Kleinstunternehmen: vereinfachter Rahmen nach Art. 16)

Ablösung der xAIT-Rundschreiben

Sanktionierung

Das FinmadiG ermächtigt die BaFin zu:

Prüfpflichten

Praktische Implikationen

Für Bestandskunden im Finanzsektor

Die Kunden werden proaktiv auf BAUER GROUP zukommen mit:

1. Anfragen zum Informationsregister (Fact Sheet)
2. Vertragsanpassungen (DORA-Klauseln)
3. Audit-Rechte (Vor-Ort, Remote, durch Aufsicht)
4. SLA-Anpassungen (DORA-konforme Meldefristen)

Erweiterter Anwendungsbereich ab 2027

Durch die FinmadiG-Erweiterung fallen ab 01.01.2027 zusätzliche Unternehmensgruppen (u. a. Finanzdienstleistungsinstitute, Kryptowertpapierregisterführer) unter DORA und benötigen erstmals DORA-konforme IKT-Dienstleister.

Architektur der Verordnung

DORA ist nach dem Lamfalussy-Verfahren aufgebaut:

• Level 1 – Basisrechtsakt: Verordnung (EU) 2022/2554 (64 Artikel, 9 Kapitel)
• Level 2 – Konkretisierung: RTS (Regulatory Technical Standards), ITS (Implementing Technical Standards), Delegierte Rechtsakte
• Level 3 – Leitlinien: Joint Guidelines der ESAs (nicht rechtsverbindlich, aber Comply-or-Explain)

Pillar-Mapping

┌─────────────────────────────────────────────────────┐
│                    DORA (EU) 2022/2554               │
├──────────┬──────────┬──────────┬──────────┬─────────┤
│  P1      │  P2      │  P3      │  P4      │  P5     │
│  IKT-RM  │ Incident │ Testing  │ 3rd Party│ Info-   │
│          │ Meldung  │          │ Risk     │ austausch│
│ Art.5-16 │ Art.17-23│ Art.24-27│ Art.28-44│ Art.45  │
├──────────┼──────────┼──────────┼──────────┼─────────┤
│ RTS      │ RTS      │ RTS      │ RTS      │  (kein  │
│ 2024/1774│ 2024/1772│ 2025/1190│ 2024/1773│  RTS)   │
│          │ 2025/301 │          │ 2025/532 │         │
│          │ ITS      │          │ ITS      │         │
│          │ 2025/302 │          │ 2024/2956│         │
└──────────┴──────────┴──────────┴──────────┴─────────┘

Priorisierung für IKT-Dienstleister

BAUER GROUP hat die Umsetzung nach folgender Priorität durchgeführt:

Querverbindungen

Die Pillars stehen nicht isoliert:

• P1 (Risikomanagement) ist das Fundament für alle anderen Pillars
• P2 (Incident Reporting) erfordert die Klassifikationskriterien aus P1
• P3 (Testing) validiert die Maßnahmen aus P1
• P4 (Drittparteien) erfordert Integration in den Risikorahmen von P1
• P5 (Austausch) speist Erkenntnisse zurück in P1

Proportionalitätsprinzip

DORA berücksichtigt das Proportionalitätsprinzip: Anforderungen sollen im Verhältnis zur Größe, zum Risikoprofil und zur Komplexität der Finanzunternehmen stehen.

Vereinfachter IKT-Risikomanagementrahmen (Art. 16)

Kleinstunternehmen dürfen einen vereinfachten IKT-Risikomanagementrahmen anwenden. Dieser umfasst:

• Dokumentation aller IKT-unterstützten Geschäftsfunktionen und zugehörigen Risiken
• Schutz aller IKT-Systeme gegen die häufigsten Cyberbedrohungen
• Gewährleistung der physischen Sicherheit und des Umgebungsschutzes
• Zugangskontrolle zu IKT-Systemen
• Mechanismen zur zeitnahen Erkennung anomaler Aktivitäten
• Geschäftsfortführungsmaßnahmen und Backup-Strategien
• Review und Lessons Learned nach IKT-Vorfällen

Ausnahmen nach Unternehmensart

BaFin-Aufsichtsmitteilung (21.08.2025)

Die BaFin hat Hinweise zur Umsetzung des vereinfachten IKT-Risikomanagementrahmens veröffentlicht mit konkreten Dokumentationsanforderungen für berechtigte Unternehmen.

BAUER GROUP-Einordnung

BAUER GROUP als IKT-Dienstleister profitiert nicht direkt vom Proportionalitätsprinzip, da die Anforderungen indirekt über Kundenverträge kommen. Allerdings: Kunden, die dem vereinfachten Rahmen unterliegen, stellen geringere vertragliche Anforderungen – dies wird bei der Vertragsgestaltung durch abgestufte Vertragsmodule berücksichtigt.

Inhalt

Spezifiziert die Anforderungen an Threat Led Penetration Tests (TLPT):

• Kriterien zur Bestimmung TLPT-pflichtiger Unternehmen
• Scope der Tests (kritische Funktionen, Live-Produktivsysteme)
• Methodik basierend auf TIBER-EU (8 Phasen)
• Red/Blue/White Team Anforderungen
• Anbieterqualifikation für TLPT-Durchführende
• Timeline typisch 9–14 Monate
• Budget typisch 150.000–500.000 EUR

Frist: Erstmalige TLPT vor 17.01.2028 für systemrelevante Finanzunternehmen. Frequenz: Alle 3 Jahre.

BAUER GROUP-Relevanz

BAUER GROUP ist nicht TLPT-pflichtig, muss aber an TLPT-Tests von Kunden mitwirken und kooperieren (Art. 26 Abs. 4). Eine TLPT-Kooperationsklausel ist in allen Verträgen mit systemrelevanten Finanzunternehmen enthalten.

→ Details: P3: Resilienztests

Strategie zur Evidenz-Sicherung

Jede DORA-relevante Aktivität wird nachweisbar dokumentiert. Die Aufbewahrungsfrist beträgt mindestens 5 Jahre (Art. 19 Abs. 6 DORA).

Automatische Evidenz-Erhebung

Automatisierter Compliance-Report (Pseudocode)

# Pseudocode – Konzeptionelle Darstellung des monatlichen DORA Compliance Reports

def generate_monthly_report():
    report = {
        "period": current_month(),
        "sections": {
            "asset_inventory": {
                "total_assets": cmdb.count_assets(),
                "classified_critical": cmdb.count_assets(tag="dora:critical"),
                "completeness_pct": cmdb.completeness_score()
            },
            "vulnerabilities": {
                "critical": vuln_scanner.count("critical"),
                "high": vuln_scanner.count("high"),
                "remediation_rate": vuln_scanner.remediation_rate(),
                "mean_time_to_remediate": vuln_scanner.mttr()
            },
            "incidents": {
                "total": siem.count_incidents(),
                "major": siem.count_incidents(classification="MAJOR"),
                "mean_detection_time": siem.mean_detection_time(),
                "sla_compliance": siem.sla_compliance_rate()
            },
            "testing": {
                "vuln_scans_executed": ci.count_scans("vulnerability"),
                "sast_scans_executed": ci.count_scans("sast"),
                "pentest_status": pentest.status(),
                "bcp_test_status": bcp.last_test_status()
            },
            "contracts": {
                "total_financial_customers": crm.count_financial_customers(),
                "dora_compliant_contracts": crm.count_dora_compliant(),
                "compliance_rate_pct": crm.dora_compliance_rate()
            },
            "awareness": {
                "training_completion_pct": lms.completion_rate(),
                "overdue_trainings": lms.count_overdue()
            }
        }
    }

    render_report(report, format=["markdown", "pdf"])
    distribute(report, recipients=["management", "compliance"])

Audit-Readiness-Paket

Für Audits durch Kunden, Wirtschaftsprüfer oder BaFin stellt BAUER GROUP ein standardisiertes, DORA-artikelbezogenes Audit-Paket bereit. Das Paket ist so strukturiert, dass jeder Prüfungsbereich direkt den regulatorischen Anforderungen zugeordnet werden kann.

Paketstruktur

audit-package-[YYYY-MM]/
│
├── 00-management-summary/
│   ├── DORA-Compliance-Statement.pdf
│   ├── Scope-und-Anwendbarkeit.pdf
│   └── Kontaktdaten-Audit-Koordination.pdf
│
├── 01-governance/                              ── Art. 5 DORA
│   ├── IKT-Risikomanagement-Framework.pdf
│   ├── Governance-Struktur-Organigramm.pdf
│   ├── Beschlussprotokoll-Geschäftsleitung.pdf
│   ├── Rollenmatrix-IKT-Verantwortlichkeiten.pdf
│   └── Jährlicher-Review-Nachweis-[Jahr].pdf
│
├── 02-risikomanagement/                        ── Art. 6–16 DORA, RTS 2024/1774
│   ├── IKT-Risikoanalyse-[Jahr].pdf
│   ├── Asset-Inventar-Auszug.csv
│   ├── Kritikalitätsklassifizierung.pdf
│   ├── IKT-Sicherheitsrichtlinie.pdf
│   ├── Zugangskontrollrichtlinie.pdf
│   ├── Kryptografie-und-Verschlüsselungsrichtlinie.pdf
│   ├── Backup-und-Recovery-Richtlinie.pdf
│   ├── Patch-Management-Richtlinie.pdf
│   ├── BCP-Plan.pdf
│   ├── DRP-Plan.pdf
│   └── Kommunikationsplan.pdf
│
├── 03-incident-management/                     ── Art. 17–23 DORA, RTS 2024/1772, RTS 2025/301
│   ├── Incident-Response-Playbook.pdf
│   ├── Klassifizierungsschema-7-Kriterien.pdf
│   ├── Eskalationsmatrix.pdf
│   ├── SLA-Meldefristen-Dokumentation.pdf
│   ├── Pre-filled-XML-Template.xml
│   ├── Incident-Log-[Zeitraum].csv
│   └── Major-Incident-Reports/
│       └── [Incident-ID]-RCA-Report.pdf
│
├── 04-resilience-testing/                      ── Art. 24–27 DORA, RTS 2025/1190
│   ├── Testprogramm-Policy.pdf
│   ├── Vulnerability-Scan-Reports/
│   │   ├── Infrastruktur-Scan-[Monat].pdf
│   │   └── Container-Scan-[Monat].pdf
│   ├── SAST-Reports/
│   │   └── SAST-Summary-[Quartal].pdf
│   ├── Pentest-Report-[Jahr].pdf
│   ├── BCP-DRP-Testprotokoll-[Jahr].pdf
│   └── Performance-Baseline-[Jahr].pdf
│
├── 05-third-party-risk/                        ── Art. 28–44 DORA, RTS 2024/1773, ITS 2024/2956
│   ├── DORA-Vertragsklauseln-Template.pdf
│   ├── Vertragscompliance-Status-Matrix.csv
│   ├── Informationsregister-Datenpaket.json
│   ├── Subcontracting-Register.csv
│   ├── Exit-Strategie-Template.pdf
│   ├── Fact-Sheet-Template.pdf
│   └── Audit-Rechte-Nachweis.pdf
│
├── 06-awareness-und-kommunikation/             ── Art. 13–14 DORA
│   ├── Awareness-Programm-Übersicht.pdf
│   ├── Schulungsplan-[Jahr].pdf
│   ├── Teilnehmerlisten-und-Nachweise/
│   │   └── [Schulung]-Teilnahmebestätigung.pdf
│   └── Kommunikationsplan-IKT-Vorfälle.pdf
│
├── 07-zertifizierungen-und-nachweise/
│   ├── ISO-27001-Zertifikat.pdf
│   ├── SOC-2-Report.pdf (falls vorhanden)
│   └── [Weitere-Zertifikate].pdf
│
└── 08-anhang/
    ├── DORA-Artikelindex-Zuordnung.pdf
    ├── Glossar.pdf
    └── Änderungshistorie-Audit-Paket.pdf

Artikelzuordnung je Prüfungsbereich

Bereitstellungsprozess

Prinzip

Jede DORA-Anforderung wird als überprüfbarer Code oder maschinenlesbare Regel abgebildet. Compliance wird dadurch reproduzierbar, versioniert und auditierbar.

Policy-as-Code (OPA/Rego)

Sicherheitsrichtlinien als executable Policies:

# dora_policies.rego
package dora

# Art. 9: Verschlüsselung für Daten in Transit
deny[msg] {
    input.type == "ingress"
    not input.tls.enabled
    msg := "DORA Art. 9: TLS muss für alle Ingress-Verbindungen aktiviert sein"
}

# Art. 9: Zugangskontrolle - kein Default-Admin
deny[msg] {
    input.type == "user"
    input.username == "admin"
    input.default_password == true
    msg := "DORA RTS 2024/1774: Standard-Admin-Zugänge müssen deaktiviert sein"
}

# Art. 11: Backup RPO-Prüfung
warn[msg] {
    input.type == "backup_config"
    input.rpo_hours > 24
    msg := sprintf("DORA Art. 11: RPO von %dh überschreitet empfohlenen Wert (24h)", [input.rpo_hours])
}

Infrastructure-as-Code Compliance

IaC-Scanner für Terraform/IaC

# .checkov.yaml
framework:
  - terraform
check:
  - CKV_AWS_18   # S3 Logging
  - CKV_AWS_19   # S3 Encryption
  - CKV_AWS_145  # RDS Encryption
  - CKV_K8S_1    # Pod Security
custom_policies_dir: ./dora-policies/

DORA-spezifische Custom Checks

# Pseudocode – konzeptionelle Darstellung
# dora_check_encryption.py
from checkov.common.models.enums import CheckResult
from checkov.terraform.checks.resource.base_resource_check import BaseResourceCheck

class DoraEncryptionAtRest(BaseResourceCheck):
    """DORA Art. 9 / RTS 2024/1774: Verschlüsselung ruhender Daten"""
    
    def __init__(self):
        name = "DORA: Ensure encryption at rest is enabled"
        id = "CKV_DORA_001"
        supported_resources = ['aws_ebs_volume', 'aws_rds_instance', 'aws_s3_bucket']
        super().__init__(name=name, id=id, categories=[], supported_resources=supported_resources)

    def scan_resource_conf(self, conf):
        if conf.get("encrypted") == [True] or conf.get("storage_encrypted") == [True]:
            return CheckResult.PASSED
        return CheckResult.FAILED

CI/CD Integration

# .gitlab-ci.yml (DORA Compliance Gate)
dora-compliance:
  stage: security
  script:
    - trivy image --severity CRITICAL,HIGH --exit-code 1 $IMAGE
    - semgrep --config=p/owasp-top-ten --config=./dora-rules/ .
    - grype $IMAGE --fail-on critical
    - checkov -d ./infrastructure/ --config-file .checkov.yaml
  artifacts:
    reports:
      - trivy-report.json
      - semgrep-report.json
      - grype-report.json
      - checkov-report.json
    paths:
      - compliance-evidence/
    expire_in: 5 years  # DORA Aufbewahrungspflicht
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'

Git-basiertes Policy-Lifecycle

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│ Entwurf     │────►│ Review      │────►│ Genehmigung │
│ (Branch)    │     │ (MR Review) │     │ (Merge)     │
└─────────────┘     └─────────────┘     └─────────────┘
       │                   │                    │
       │              Kommentare           Git Tag
       │              Änderungen           v1.0.0
       │                                       │
       │                              ┌────────┴────────┐
       │                              │ Automatischer    │
       │                              │ Build → Deploy   │
       │                              │ → Interne Doku   │
       │                              └─────────────────┘

Jede Policy-Änderung:

1. Wird in einem Branch vorbereitet
2. Durchläuft Code-Review (Vier-Augen-Prinzip)
3. Wird nach Genehmigung gemerged
4. Erhält automatisch ein SemVer-Tag
5. Erzeugt automatisch einen Changelog-Eintrag
6. Wird automatisch auf der internen Doku-Site veröffentlicht

Automatisierte Incident-Verarbeitung

SIEM Alert
       │
       ▼
┌──────────────┐
│ Webhook      │ (SIEM → Workflow-Automation)
│ Receiver     │
└──────┬───────┘
       │
       ▼
┌──────────────┐
│ Classifier   │ 6 DORA-Kriterien prüfen
│ (Rule Engine)│ → MINOR / SIGNIFICANT / MAJOR
└──────┬───────┘
       │
       ├── MINOR ──────► Log & Monitor
       │
       ├── SIGNIFICANT ► Log + Notify Team Lead
       │
       └── MAJOR ──────► Eskalationskette:
                         1. Alerting-System (On-Call)
                         2. E-Mail GF
                         3. Kunden-Notification (Template)
                         4. Incident-Ticket (Ticketsystem)
                         5. Pre-fill BaFin XML Template

Workflow-Automation

{
  "nodes": [
    { "name": "Webhook", "type": "workflow-automation.webhook", "parameters": { "path": "dora-incident" } },
    { "name": "Classify", "type": "workflow-automation.function",
      "parameters": { "functionCode": "// 6-Kriterien Decision Tree\n// return MINOR|SIGNIFICANT|MAJOR" } },
    { "name": "Route", "type": "workflow-automation.switch",
      "parameters": { "rules": [
        { "value": "MAJOR", "output": 0 },
        { "value": "SIGNIFICANT", "output": 1 },
        { "value": "MINOR", "output": 2 }
      ]}},
    { "name": "Alerting-System", "type": "workflow-automation.pagerDuty" },
    { "name": "Email GF", "type": "workflow-automation.emailSend" },
    { "name": "Customer Notify", "type": "workflow-automation.emailSend",
      "parameters": { "template": "dora-incident-notification" } },
    { "name": "Create Ticket", "type": "workflow-automation.jira" },
    { "name": "Generate XML", "type": "workflow-automation.function",
      "parameters": { "functionCode": "// Pre-fill ITS 2025/302 XML template" } }
  ]
}

BaFin XML Template (ITS 2025/302)

<?xml version="1.0" encoding="UTF-8"?>
<IncidentReport xmlns="urn:dora:its:2025:302">
  <ReportType>INITIAL</ReportType>
  <ReportingEntity>
    <LEI>[BAUER GROUP-Kunde-LEI]</LEI>
    <Name>[Kundenname]</Name>
  </ReportingEntity>
  <IncidentDetails>
    <DetectionTimestamp>[ISO-8601]</DetectionTimestamp>
    <ClassificationTimestamp>[ISO-8601]</ClassificationTimestamp>
    <Description>[Auto-generated from SIEM alert]</Description>
    <AffectedServices>[Aus Asset-Inventar]</AffectedServices>
    <Classification>
      <ClientsAffected>[Anzahl]</ClientsAffected>
      <DowntimeHours>[Stunden]</DowntimeHours>
      <GeographicSpread>[Länder]</GeographicSpread>
      <DataLoss>[true/false]</DataLoss>
      <CriticalService>[true/false]</CriticalService>
      <EconomicImpact>[EUR]</EconomicImpact>
    </Classification>
  </IncidentDetails>
  <ImmediateActions>[Beschreibung]</ImmediateActions>
  <ContactPerson>
    <Name>[Mediensprecher]</Name>
    <Phone>[Telefon]</Phone>
    <Email>[E-Mail]</Email>
  </ContactPerson>
</IncidentReport>

Prinzip: Minimal Effort, Maximum Compliance

Die DORA-Umsetzung bei BAUER GROUP folgt dem Prinzip "Compliance-as-Code": Jede Anforderung wird so weit wie möglich automatisiert, Templates statt Prosa, Monitoring statt manuellem Reporting.

┌────────────────────────────────────────────────────┐
│              DORA Automation Stack                   │
├────────────────────────────────────────────────────┤
│  Layer 4: Reporting & Evidence                      │
│  ├── Automatisierte Compliance-Reports              │
│  ├── Audit-Trail (Git-basiert)                      │
│  └── Dashboard (Dashboard/Custom)                     │
├────────────────────────────────────────────────────┤
│  Layer 3: Detection & Response                      │
│  ├── SIEM (SIEM)                          │
│  ├── Incident Pipeline (Webhook → Classify → Alert)│
│  └── Pre-filled Meldetemplates (XML)               │
├────────────────────────────────────────────────────┤
│  Layer 2: Continuous Testing                        │
│  ├── Vulnerability Scanning (Vulnerability Scanner)      │
│  ├── SAST/DAST (SAST/DAST)                      │
│  ├── Dependency Scanning (Dependency-Scanner)                   │
│  └── Performance Testing (k6)                      │
├────────────────────────────────────────────────────┤
│  Layer 1: Asset & Risk Foundation                   │
│  ├── CMDB (CMDB/Custom)                          │
│  ├── IKT-Asset-Inventar (auto-discovered)          │
│  ├── Risk Register (Notion/Custom)                 │
│  └── Contract Register (CRM + Custom)          │
└────────────────────────────────────────────────────┘

Mapping: DORA-Anforderung → Automation

Komponenten im Detail

1. Asset Management (Layer 1)

# netbox-auto-discovery.yaml
# Cronjob: Wöchentlich
sources:
  - type: nmap
    scope: "10.0.0.0/8"
    frequency: weekly
  - type: ansible_facts
    scope: all_managed_hosts
    frequency: daily
  - type: kubernetes_api
    scope: all_clusters
    frequency: hourly
  - type: cloud_api
    provider: [hetzner, aws]
    frequency: daily

output:
  target: netbox
  create_missing: true
  update_existing: true
  tag: "auto-discovered"
  
classification:
  critical_functions:
    - tag: "dora:critical"
      criteria: "customer_facing OR financial_data"
    - tag: "dora:important"
      criteria: "internal_infrastructure"

2. Continuous Security Testing (Layer 2)

# CI/CD Pipeline Extension
stages:
  - name: dora-security-gate
    steps:
      - trivy image scan (CRITICAL/HIGH = block)
      - semgrep SAST (security rules)
      - grype SCA (CVE database)
      - checkov IaC scan (misconfig)
    evidence:
      store: s3://compliance-evidence/
      format: SARIF
      retention: 5y

3. Incident Pipeline (Layer 3)

# Pseudocode – konzeptionelle Darstellung
# incident_classifier.py (Pseudocode)
DORA_THRESHOLDS = {
    "affected_customers_pct": 10,    # > 10% = schwerwiegend
    "affected_customers_abs": 100000, # > 100k = schwerwiegend
    "downtime_hours": 2,              # > 2h kritische Dienste
    "geo_spread": 2,                  # >= 2 Mitgliedstaaten
    "data_loss": True,                # CIA betroffen
    "critical_service": True,         # Kritische Funktion
    "economic_impact_eur": 100000,    # > 100k EUR
}

def classify_incident(incident) -> str:
    """Klassifiziert nach 6 DORA-Kriterien."""
    criteria_met = 0
    for criterion, threshold in DORA_THRESHOLDS.items():
        if incident.get(criterion) >= threshold:
            criteria_met += 1
    
    if criteria_met >= 2:
        return "MAJOR"  # → Meldepflicht
    elif criteria_met == 1:
        return "SIGNIFICANT"  # → Monitoring
    else:
        return "MINOR"  # → Logging

4. Reporting & Evidence (Layer 4)

# compliance-report.yaml
# Generiert automatischen DORA-Compliance-Report
reports:
  - name: "monthly_compliance_status"
    frequency: monthly
    sections:
      - asset_inventory_completeness
      - open_vulnerabilities_by_severity
      - incident_statistics
      - test_execution_status
      - contract_compliance_status
    output: [markdown, pdf]
    recipients: [geschaeftsleitung, compliance]
    
  - name: "annual_dora_review"
    frequency: annually
    sections:
      - full_gap_analysis
      - risk_assessment_update
      - test_program_results
      - contract_register_summary
      - awareness_training_completion
      - improvement_roadmap
    output: [docx, pdf]
    recipients: [geschaeftsleitung, kunden]

Git-basiertes Policy Management

Alle DORA-relevanten Policies werden als Markdown im Git-Repository gepflegt:

policies/
├── IKT-Sicherheitsrichtlinie.md          # Art. 9
├── IKT-Risikomanagement-Framework.md     # Art. 6
├── Incident-Response-Policy.md           # Art. 17-19
├── Business-Continuity-Plan.md           # Art. 11
├── Disaster-Recovery-Plan.md             # Art. 12
├── Kommunikationsplan.md                 # Art. 14
├── Drittanbieter-Management-Policy.md    # Art. 28-30
├── Awareness-Schulungsplan.md            # Art. 13
├── Test-Programm.md                      # Art. 25
└── CHANGELOG.md                          # Audit-Trail

Vorteile:

• Vollständiger Audit-Trail (Git History)
• Review-Prozess über Merge Requests
• Automatische Versionierung (SemVer)
• Automatischer Build → Dokumentations-Deployment
• Diff-basierter jährlicher Review (was hat sich geändert?)

Aufwandsvergleich

DORA-konformes Monitoring (Art. 10)

Finanzunternehmen und ihre IKT-Dienstleister müssen Mechanismen zur zeitnahen Erkennung anomaler Aktivitäten implementieren.

Monitoring-Stack

┌────────────────────────────────────────────┐
│              Compliance-Dashboard              │
│  (DORA Compliance KPIs + Incident Status)  │
├──────────────┬──────────────┬──────────────┤
│   SIEM      │   Monitoring │   Loki       │
│   SIEM       │   Metrics    │   Logs       │
├──────────────┴──────────────┴──────────────┤
│              Alert Manager                  │
│  → Alerting-System → DORA Escalation    │
└────────────────────────────────────────────┘

DORA-spezifische Alert-Rules

# prometheus-dora-rules.yaml
groups:
  - name: dora_availability
    rules:
      - alert: DoraServiceUnavailable
        expr: up{dora_critical="true"} == 0
        for: 5m
        labels:
          severity: critical
          dora_criterion: "downtime"
        annotations:
          summary: "DORA-kritischer Dienst {{ $labels.instance }} nicht erreichbar"
          description: "Dienst ist seit > 5min ausgefallen. DORA Art. 18: Schwellwert Ausfallzeit > 2h."
          runbook: "https://docs.internal/dora/incident-response"

      - alert: DoraHighErrorRate
        expr: rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.05
        for: 10m
        labels:
          severity: warning
          dora_criterion: "service_quality"
        annotations:
          summary: "Erhöhte Fehlerrate auf {{ $labels.service }}"

  - name: dora_security
    rules:
      - alert: DoraUnauthorizedAccess
        expr: rate(auth_failures_total[5m]) > 10
        for: 2m
        labels:
          severity: critical
          dora_criterion: "data_breach"
        annotations:
          summary: "Möglicher Brute-Force-Angriff auf {{ $labels.service }}"

SIEM Rules

<!-- dora-custom-rules.xml -->
<group name="dora,">
  <rule id="100100" level="14">
    <if_sid>5710</if_sid>
    <match>DORA_CRITICAL_SYSTEM</match>
    <description>DORA: Sicherheitsvorfall auf kritischem System erkannt</description>
    <group>dora,critical,</group>
  </rule>

  <rule id="100101" level="12">
    <if_group>authentication_failure</if_group>
    <frequency>10</frequency>
    <timeframe>60</timeframe>
    <description>DORA Art. 10: Brute-Force-Versuch erkannt (>10 Fehlversuche/Min)</description>
    <group>dora,brute_force,</group>
  </rule>
</group>

DORA Compliance Dashboard (Dashboard)

Empfohlene Panels:

Ziel

Automatisierte Verwaltung und Export der Informationsregister-Daten (ITS 2024/2956) für alle Finanzsektor-Kunden.

Architektur

CRM                    BAUER GROUP Internal
┌──────────────┐              ┌──────────────┐
│ Deals        │              │ CMDB       │
│ (Kunden)     │──────────────│ (Assets)     │
├──────────────┤              ├──────────────┤
│ Custom Obj:  │              │ Service      │
│ DORA_Service │              │ Catalog      │
│ - LEI        │              │ Locations    │
│ - Services   │              │ Subcontract. │
│ - Locations  │              └──────┬───────┘
│ - SLAs       │                     │
└──────┬───────┘                     │
       │                             │
       ▼                             ▼
┌──────────────────────────────────────┐
│         Export Pipeline              │
│  (Node.js/Python Scheduled Job)     │
│                                     │
│  1. Fetch Customer Data (CRM)   │
│  2. Enrich with Asset Data (CMDB) │
│  3. Generate JSON/CSV per Customer  │
│  4. Validate against ITS schema     │
│  5. Send to Customer (Email/Portal) │
└──────────────────────────────────────┘

CRM Custom Object Schema

{
  "name": "dora_service",
  "labels": { "singular": "DORA Service", "plural": "DORA Services" },
  "properties": [
    { "name": "service_id", "label": "Service-ID", "type": "string" },
    { "name": "service_description", "label": "Dienstleistungsbeschreibung", "type": "string" },
    { "name": "criticality", "label": "Kritikalität", "type": "enumeration",
      "options": ["critical", "important", "standard"] },
    { "name": "data_processing_locations", "label": "Datenverarbeitungsstandorte", "type": "string" },
    { "name": "data_storage_locations", "label": "Datenspeicherungsstandorte", "type": "string" },
    { "name": "sla_availability", "label": "SLA Verfügbarkeit (%)", "type": "number" },
    { "name": "sla_response_time", "label": "SLA Response Time", "type": "string" },
    { "name": "subcontractors", "label": "Unterauftragnehmer", "type": "string" },
    { "name": "contract_start", "label": "Vertragsbeginn", "type": "date" },
    { "name": "contract_end", "label": "Vertragsende", "type": "date" },
    { "name": "exit_transition_months", "label": "Exit-Übergangsfrist (Monate)", "type": "number" },
    { "name": "last_audit_date", "label": "Letztes Audit", "type": "date" },
    { "name": "dora_compliant", "label": "DORA-konform", "type": "boolean" }
  ]
}

Export-Script

# Pseudocode – konzeptionelle Darstellung
#!/usr/bin/env python3
"""DORA Register Export – Generiert kundenspezifische Datenpakete."""

import json
from datetime import date
# CRM-Client initialisieren

def export_dora_register(customer_id: str) -> dict:
    """Exportiert DORA-Registerdaten für einen Kunden."""
    client = CRM(access_token=HUBSPOT_TOKEN)
    
    # Fetch associated DORA services
    services = client.crm.objects.search(
        object_type="dora_service",
        filter_groups=[{
            "filters": [{"propertyName": "customer_id", "operator": "EQ", "value": customer_id}]
        }]
    )
    
    return {
        "provider": BGI_PROVIDER_INFO,
        "services": [format_service(s) for s in services.results],
        "certifications": BGI_CERTIFICATIONS,
        "export_date": date.today().isoformat(),
        "schema_version": "ITS_2024_2956_v1"
    }

# Cron: Monatlich oder bei Änderung
# Notification: Email an Kundenansprechpartner

Jährlicher Review-Workflow

1. T-30d: Automatische Erinnerung an alle Finanzsektor-Kunden
2. T-14d: Export aktueller Registerdaten, Diff zum Vorjahr
3. T-7d: Interner Review, GF-Freigabe
4. T-0: Versand aktualisiertes Fact Sheet an alle Kunden

Vertragliche Anforderungen (Art. 30)

Alle Verträge mit IKT-Drittanbietern müssen die 8 Mindestvertragsinhalte enthalten. Für kritische/wichtige Funktionen gelten zusätzliche Anforderungen.

Vertragsmodul-System für BAUER GROUP

Modul A: Basis (alle Finanzsektor-Kunden)

• Dienstleistungsbeschreibung mit funktionaler Zuordnung
• Datenverarbeitungsstandorte
• SLA mit messbaren KPIs
• Datenzugang und -rückgabe
• Incident-Kooperationsklausel
• Audit-Rechte
• Kündigungsrechte
• Exit-Strategie

Modul B: Erweitert (kritische/wichtige Funktionen)

Zusätzlich zu Modul A:

• Vollständige Subcontracting-Kette offenlegen
• Standortänderungen nur mit Vorabgenehmigung
• Business Impact Analysis
• Notfall- und Kontinuitätsplanung spezifisch
• TLPT-Kooperationsklausel
• Regelmäßige Compliance-Nachweise

Vertragsprüfungs-Checkliste

## DORA Vertragsprüfung – Checkliste

**Vertrag:** ___________________
**Kunde:** ___________________
**Datum:** ___________________
**Prüfer:** ___________________

### Art. 30 Abs. 2 – Mindestinhalte
- [ ] (a) Klare und vollständige Beschreibung aller Funktionen/Dienste
- [ ] (a) Angabe, ob kritische/wichtige Funktion unterstützt wird
- [ ] (b) Standorte Datenverarbeitung und -speicherung
- [ ] (b) Vorabbenachrichtigungspflicht bei Standortänderung
- [ ] (c) Verfügbarkeits-, Authentizitäts-, Integritäts-, Vertraulichkeitsregelungen
- [ ] (d) Datenzugang, -rückgabe und -löschung bei Vertragsende
- [ ] (e) SLAs mit quantitativen und qualitativen KPIs
- [ ] (f) Kooperationspflicht bei IKT-Vorfällen
- [ ] (g) Kündigungsrechte und Mindestkündigungsfristen

### Art. 30 Abs. 3 – Zusätzlich bei kritischen Funktionen
- [ ] (a) Vollständige Dienstleistungsbeschreibung mit SLAs
- [ ] (b) Benachrichtigungspflichten und Meldefristen
- [ ] (c) Geschäftsfortführungs- und Notfallpläne
- [ ] (d) Mitwirkung bei TLPT
- [ ] (e) Uneingeschränkte Audit-Rechte (inkl. Aufsichtsbehörde)
- [ ] (f) Exit-Strategien mit Übergangsfristen
- [ ] (g) Subcontracting-Transparenz und -Genehmigung

### RTS 2025/532 – Subcontracting
- [ ] Due Diligence für Unterauftragnehmer dokumentiert
- [ ] Risikobewertung Subcontracting-Kette
- [ ] Vertragliche Durchgriffsmöglichkeiten
- [ ] Änderungs-/Genehmigungsprozess definiert

### Ergebnis
- [ ] ✅ Vollständig DORA-konform
- [ ] ⚠️ Anpassungsbedarf identifiziert (siehe Anlage)
- [ ] ❌ Wesentliche Lücken (Vertragsnachtrag erforderlich)

Bestandsvertrags-Migration

1. Inventarisierung: Alle aktiven Verträge mit Finanzsektor-Kunden aus CRM exportieren
2. Gap-Check: Jeden Vertrag gegen Checkliste prüfen
3. Priorisierung: Kritische Funktionen zuerst
4. Anpassung: Vertragsnachtrag oder Neuvertrag
5. Tracking: Status im CRM-Deal-Pipeline als Custom Property

BAIT/xAIT → DORA Mapping

Die Gap-Analyse bildet den Ausgangspunkt der DORA-Umsetzung. Für Unternehmen, die bisher nach BAIT/VAIT/ZAIT/KAIT aufgestellt waren, ist der Sprung zu DORA überschaubar – die wesentlichen Neuerungen liegen in Formalisierung, Governance und Drittparteienmanagement.

Gap-Matrix

Ergebnis-Zusammenfassung

Niedrige Gaps (bestehende Compliance ausreichend)

• IKT-Sicherheitsrichtlinien (Erweiterung)
• BCP/DRP (Formalisierung)
• Basistests (Erweiterung)

Mittlere Gaps (Anpassung erforderlich)

• Governance-Formalisierung
• Asset-Inventar mit Kritikalitätsklassifizierung
• Detection (SIEM-Ausbau)
• Kommunikationspläne
• Incident-Klassifikation

Hohe Gaps (Neuentwicklung nötig)

• Incident Reporting (neues Format, neue Fristen)
• Drittparteien-Informationsregister
• Vertragsanpassung alle Finanzsektor-Kunden
• Subcontracting-Governance

Nächste Schritte

→ Umsetzungs-Roadmap

BAUER GROUP als IKT-Drittanbieter unter DORA

BAUER GROUP fällt als IT-Dienstleister mit Kunden im Finanzsektor unter Art. 2 Abs. 1 Buchstabe u) DORA – IKT-Drittanbieter. Die Pflichten ergeben sich nicht direkt aus DORA, sondern indirekt über die Vertragsanforderungen der Finanzunternehmen (Art. 28–30).

Pflichten-Matrix

Direkte Pflichten (falls CTPP-Einstufung)

Indirekte Pflichten (über Kundenverträge)

Compliance-Nachweis BAUER GROUP

Umgesetzte Maßnahmen

• [x] DORA-Awareness im Management
• [x] Bestandsaufnahme Kunden im Finanzsektor
• [x] Identifikation betroffener Verträge
• [x] Vertragsklauseln-Template DORA-konform erstellt
• [x] Standardvertrag mit allen Mindestinhalten (Art. 30)
• [x] DORA Fact Sheet für Kunden (Registerinformationen)
• [x] SLA-Definitionen mit DORA-konformen KPIs
• [x] Exit-Strategie-Template
• [x] Subcontracting-Offenlegung
• [x] Incident-Response-Playbook mit DORA-Fristen
• [x] Asset-Inventar mit DORA-Klassifizierung
• [x] Vulnerability Management Pipeline
• [x] Awareness-Training für alle Mitarbeiter
• [x] BCP/DRP dokumentiert und getestet
• [x] Jährlicher Review IKT-Risikomanagementrahmen etabliert
• [ ] Jährliche Basistests (Schwachstellenscan, Pentest)
• [ ] Jährliche Aktualisierung Informationsregister-Daten
• [ ] Jährliche Awareness-Schulung
• [ ] Compliance-Report für Kunden

DORA Fact Sheet (Template für Kunden)

Standardisiertes Informationsblatt, das BAUER GROUP seinen Finanzkunden bereitstellt:

# DORA IKT-Drittanbieter – Informationsblatt

## Anbieteridentifikation
- **Firma:** BAUER GROUP
- **LEI:** [LEI einfügen]
- **Registernummer:** [HRx einfügen]
- **Anschrift:** [Adresse]
- **Ansprechpartner DORA:** [Name, E-Mail, Tel.]

## Dienstleistungen
- [Liste der für den Kunden erbrachten IKT-Dienste]
- Klassifizierung: [kritisch/wichtig/sonstig]

## Datenverarbeitungsstandorte
- **Primär:** Deutschland (Standort XY)
- **Backup/DR:** Deutschland (Standort YZ)
- **Cloud-Infrastruktur:** [Provider, Region]

## Subcontracting
- **Unterauftragnehmer:** [Liste oder "keine"]
- **Genehmigungsvorbehalt:** Ja, gemäß Vertrag

## Sicherheitsstandards
- **Zertifizierungen:** [ISO 27001, SOC 2, etc.]
- **Letzte Prüfung:** [Datum]
- **Nächste Prüfung:** [Datum]

## Incident Response
- **Interne Meldefrist an Kunden:** < 1 Stunde
- **24/7 Erreichbarkeit:** [Ja/Nein, Kontakt]
- **Kooperationszusage TLPT:** Ja

## Exit-Strategie
- **Übergangsfrist:** Mindestens 6 Monate
- **Datenformat Export:** [Formate]
- **Löschbestätigung:** Ja, schriftlich

## Letztes Update: [Datum]

Vertragliche Muster-Klauseln

Incident-Kooperation

Der Auftragnehmer verpflichtet sich, den Auftraggeber unverzüglich, spätestens jedoch innerhalb von 60 Minuten nach Feststellung eines IKT-bezogenen Vorfalls, der die vom Auftraggeber genutzten Dienste betrifft oder betreffen könnte, zu informieren. Der Auftragnehmer unterstützt den Auftraggeber bei der Klassifizierung, Dokumentation und Meldung des Vorfalls gemäß den Anforderungen der Verordnung (EU) 2022/2554 (DORA).

Audit-Rechte

Der Auftraggeber, dessen zuständige Aufsichtsbehörde sowie von diesen beauftragte Dritte haben das Recht, Vor-Ort-Inspektionen und Audits beim Auftragnehmer durchzuführen. Dies umfasst den uneingeschränkten Zugang zu Räumlichkeiten, Informationen, Systemen und Personal des Auftragnehmers, soweit dies für die Überprüfung der Einhaltung der vertraglichen und regulatorischen Anforderungen erforderlich ist. Der Auftragnehmer unterstützt diese Prüfungen aktiv und ohne unangemessene Verzögerung.

Exit-Klausel

Bei Beendigung des Vertrages gewährt der Auftragnehmer eine Übergangsfrist von mindestens 6 Monaten, während der alle Dienste zu unveränderten Konditionen fortgeführt werden. Der Auftragnehmer stellt dem Auftraggeber sämtliche Daten in einem marktüblichen, maschinenlesbaren Format zur Verfügung und bestätigt die vollständige Löschung nach erfolgter Datenübernahme schriftlich.

DORA-konformer Incident-Response-Prozess

Phasen

┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐
│1. Detect │──►│2. Classify│──►│3. Contain│──►│4. Report │──►│5. Recover│
│          │   │& Escalate│   │& Mitigate│   │& Notify  │   │& Review  │
└──────────┘   └──────────┘   └──────────┘   └──────────┘   └──────────┘
  T+0            T+30min        T+1h           T+1h (Kd)      Ongoing
                                               T+4h (BaFin)

Phase 1: Detection (T+0)

Automatisiert via SIEM/Monitoring:

• SIEM-Alerts → Incident-Queue
• Anomalie-Erkennung (ML-basiert oder regelbasiert)
• Externe Meldungen (Kunden, Partner, Behörden)

Verantwortlich: On-Call Engineer / SOC

Phase 2: Classify & Escalate (T+30min)

DORA-Klassifikation (6 Kriterien):

Ergebnis: ≥ 2 Kriterien = MAJOR → Meldepflicht

Eskalationsmatrix:

Phase 3: Contain & Mitigate (T+1h)

• Sofortmaßnahmen zur Schadensbegrenzung
• Isolierung betroffener Systeme
• Aktivierung von Workarounds/Redundanzen
• Forensische Sicherung (Beweismittel)

Phase 4: Report & Notify

An Kunden (T+1h nach Klassifizierung als MAJOR):

Betreff: [DORA-Meldung] IKT-Vorfall – [Kurzbeschreibung]

Sehr geehrte [Ansprechpartner],

hiermit informieren wir Sie gemäß unserer vertraglichen DORA-Kooperationspflicht
über einen IKT-bezogenen Vorfall:

Zeitpunkt der Erkennung: [Datum/Uhrzeit]
Betroffene Dienste: [Liste]
Aktuelle Einschätzung: [MAJOR/SIGNIFICANT]
Betroffene Kriterien: [Auflistung der 6 Kriterien mit Status]
Sofortmaßnahmen: [Beschreibung]
Nächste Schritte: [Timeline]
Ansprechpartner: [Name, Telefon, E-Mail]

Ein detaillierter Zwischenbericht folgt innerhalb von 24 Stunden.

Kunde an BaFin (T+4h):

• Kunde nutzt BaFin-Portal mit XML-Template (ITS 2025/302)
• BAUER GROUP liefert alle technischen Details

Phase 5: Recover & Review

• Wiederherstellung der betroffenen Dienste
• Zwischenbericht an Kunden (T+24h)
• Root Cause Analysis (T+2w)
• Abschlussbericht an Kunden (T+2–4w)
• Lessons Learned in IKT-Risikomanagement-Framework einarbeiten
• Anpassung der Detection-Rules falls nötig

Runbook-Template

# incident-runbook.yaml
runbook:
  id: "INC-TEMPLATE-001"
  version: "1.0"
  
  triggers:
    - siem_alert_critical
    - customer_report
    - external_notification
    
  steps:
    - name: "Triage"
      timeout: "30min"
      actions:
        - "Confirm incident is real (not false positive)"
        - "Identify affected systems and services"
        - "Run DORA classification checklist"
      decision:
        major: "goto escalation"
        significant: "goto monitoring"
        minor: "goto logging"
        
    - name: "Escalation"
      timeout: "15min"
      notifications:
        - channel: "pagerduty"
          target: "on-call-manager"
        - channel: "email"
          target: "geschaeftsleitung"
          template: "dora-escalation"
          
    - name: "Customer Notification"
      timeout: "60min"
      template: "dora-incident-notification"
      recipients: "affected_customers"
      
    - name: "Containment"
      parallel: true
      actions:
        - "Isolate affected systems"
        - "Activate failover/redundancy"
        - "Preserve forensic evidence"
        
    - name: "Resolution"
      actions:
        - "Implement fix"
        - "Verify fix"
        - "Restore service"
        
    - name: "Post-Incident"
      actions:
        - "Interim report to customers (T+24h)"
        - "Root Cause Analysis (T+2w)"
        - "Final report to customers (T+4w)"
        - "Update risk register"
        - "Update detection rules"
        - "Lessons learned session"

Anforderung (Art. 28 Abs. 3)

Finanzunternehmen müssen ein vollständiges Register aller vertraglichen Vereinbarungen mit IKT-Drittanbietern führen und regelmäßig aktualisieren.

Template-Struktur (ITS 2024/2956)

Das Informationsregister umfasst folgende Daten-Tabellen:

BAUER GROUP-Deliverable: Standardisiertes Datenpaket

Für jeden Kunden im Finanzsektor stellt BAUER GROUP ein standardisiertes Datenpaket bereit:

{
  "provider": {
    "name": "BAUER GROUP",
    "lei": "[LEI einfügen]",
    "registration_country": "DE",
    "address": "[Adresse]",
    "contact_dora": {
      "name": "[Name]",
      "email": "[E-Mail]",
      "phone": "[Telefon]"
    }
  },
  "services": [
    {
      "id": "SVC-001",
      "description": "Managed Hosting & Infrastructure",
      "supports_critical_function": true,
      "data_locations": {
        "processing": ["DE"],
        "storage": ["DE"],
        "backup": ["DE"]
      },
      "subcontractors": [],
      "sla": {
        "availability": "99.9%",
        "response_time": "< 15min (critical)",
        "mttr": "< 4h (critical)"
      }
    }
  ],
  "certifications": [
    {
      "type": "ISO 27001",
      "valid_until": "2027-01-01",
      "scope": "IT Operations & Software Development"
    }
  ],
  "audit_rights": true,
  "exit_strategy": {
    "transition_period_months": 6,
    "data_export_formats": ["SQL", "CSV", "JSON", "API"],
    "deletion_confirmation": true
  },
  "last_updated": "2025-01-15"
}

Automatisierung: CRM → Register-Export

Der Register-Export kann via CRM Custom Objects automatisiert werden:

1. Custom Object DORA_Service im CRM mit den oben genannten Feldern
2. Automatischer Export via CRM-API → JSON/CSV
3. Kunden-Portal oder automatisierter E-Mail-Versand bei Aktualisierungen
4. Jährlicher Review-Workflow als CRM-Automatisierung

→ Siehe Register-Automatisierung für die technische Umsetzung.

Umsetzungsübersicht für IKT-Dienstleister

Die Umsetzung folgte dem Prinzip: Was verursacht sofortigen Schaden bei Nichtbeachtung?

Q1 2025        Q2 2025        Q3 2025        Q4 2025        2026           2027
────┬──────────┬──────────────┬──────────────┬──────────────┬──────────────┬────►
    │          │              │              │              │              │
    │  ┌───────┴──────┐      │              │              │              │
    │  │ P2: Incident │      │              │              │              │
    │  │ Melde-Prozess│      │              │              │              │
    │  │ aufgesetzt   │      │              │              │              │
    │  └──────────────┘      │              │              │              │
    │          │              │              │              │              │
    │  ┌───────┴──────────────┴──────┐      │              │              │
    │  │ P4: Verträge angepasst,     │      │              │              │
    │  │ Informationsregister-Daten  │      │              │              │
    │  │ bereitgestellt (Deadline    │      │              │              │
    │  │ Kunden: 30.04.2025)         │      │              │              │
    │  └─────────────────────────────┘      │              │              │
    │                         │              │              │              │
    │                 ┌───────┴──────────────┴──────┐      │              │
    │                 │ P1: IKT-Risikomanagement-   │      │              │
    │                 │ Rahmen formalisiert,         │      │              │
    │                 │ Asset-Inventar, Policies     │      │              │
    │                 └────────────────────────────────┘    │              │
    │                                        │              │              │
    │                                ┌───────┴──────────────┴──────┐      │
    │                                │ P3: Testprogramm etabliert, │      │
    │                                │ Automatisierung ausgerollt  │      │
    │                                └─────────────────────────────┘      │
    │                                                       │              │
    │                                               ┌───────┴──────┐      │
    │                                               │ P5: Threat   │      │
    │                                               │ Intelligence │      │
    │                                               │ integriert   │      │
    │                                               └──────────────┘      │
    │                                                              ┌──────┴──┐
    │                                                              │FinmadiG │
    │                                                              │Erweiter.│
    │                                                              └─────────┘

Phase 1: Sofortmaßnahmen (Q1 2025) ✅

P2: Incident-Meldewesen

P4: Vertragliche Grundlagen

Phase 2: Vertragliche Anpassung (Q2 2025) ✅

P4: Register & Verträge

Phase 3: Operative Umsetzung (Q3–Q4 2025) ✅

P1: IKT-Risikomanagement

P3: Testprogramm

Phase 4: Laufender Betrieb (ab 2026) ✅

Laufende Aufwände (jährlich)

Sanktionsregime

DORA (Art. 50–52) und das FinmadiG sehen ein abgestuftes Sanktionsregime vor. DORA delegiert die Festlegung konkreter Sanktionshöhen an die Mitgliedstaaten – die nachfolgenden Angaben beziehen sich auf die deutsche Umsetzung (FinmadiG).

Gegen Finanzunternehmen (Art. 50–52 DORA, FinmadiG)

Gegen kritische IKT-Drittdienstleister (CTPPs, Art. 35 Abs. 8 DORA)

Gegen IKT-Dienstleister (nicht-CTPP)

Nicht-kritische IKT-Dienstleister wie BAUER GROUP unterliegen keiner direkten DORA-Sanktionierung. Die Konsequenzen sind indirekt:

Praxisrelevante Haftungsszenarien für BAUER GROUP

Verhältnis der Rechtsakte

DORA ist gemäß Art. 1 Abs. 2 ein sektorspezifischer Rechtsakt (lex specialis) im Sinne von Art. 4 der NIS2-Richtlinie. Das bedeutet:

• DORA hat Anwendungsvorrang gegenüber NIS2 in den Bereichen IKT-Risikomanagement und Meldewesen
• Finanzunternehmen bleiben Teil des NIS2-Ökosystems, wenden aber DORA-Anforderungen an
• IKT-Dienstleister, die sowohl Finanz- als auch andere Sektoren bedienen, können beiden Regelwerken unterliegen

Vergleichsmatrix

Überschneidungen für BAUER GROUP

Als IT-Dienstleister, der sowohl Finanz- als auch andere Sektoren bedient:

Synergieeffekte

Wer DORA vollständig umsetzt, hat folgende Anforderungen anderer Regelwerke automatisch mit abgedeckt:

• NIS2: ~80% der Anforderungen (Lücke: Sektorspezifische NIS2-Anforderungen)
• CRA: Teilweise (Produktsicherheit ist eigenständig)
• AI Act: Geringe Überschneidung (nur wenn KI in Finanzdienstleistungen eingesetzt wird)

Was ist DORA?

Der Digital Operational Resilience Act (Verordnung (EU) 2022/2554) schafft einen einheitlichen EU-weiten Rechtsrahmen für die digitale operationale Resilienz im Finanzsektor. Als EU-Verordnung gilt DORA unmittelbar in allen Mitgliedstaaten ohne nationale Umsetzung.

Die 5 Säulen (Pillars)

DORA strukturiert sich in fünf zentrale Anforderungsbereiche:

Relevanz für IKT-Dienstleister

BAUER GROUP als IKT-Dienstleister für Finanzunternehmen ist doppelt betroffen:

1. Indirekt – Kunden im Finanzsektor fordern DORA-konforme Vertragsgestaltung (Art. 28–30), Audit-Rechte, Exit-Strategien und Subcontracting-Transparenz
2. Potenziell direkt – Bei Einstufung als CTPP (Critical ICT Third-Party Provider) durch die ESAs greift das EU-Überwachungsrahmenwerk (Art. 31–44)

Die Strategie: Normkonformität nach außen demonstrieren (Vertragsklauseln, Zertifizierungen, Dokumentation) bei minimalem internem Aufwand (Automation, Templates, Compliance-as-Code).

Abgrenzung zu NIS2, CRA, AI Act

Schnellstart

1. Anwendungsbereich prüfen – Bin ich betroffen? Als Finanzunternehmen oder IKT-Dienstleister?
2. Proportionalität klären – Kleinstunternehmen, vereinfachter Rahmen?
3. Gap-Analyse durchführen – BAIT/VAIT/ZAIT → DORA Mapping
4. Roadmap erstellen – Priorisierung: P2 → P4 → P1 → P3 → P5
5. Automatisierung planen – Compliance-as-Code Strategie

Rechtsgrundlage

• DORA: Artikel 5–16 (Kapitel II)
• RTS: Delegierte Verordnung (EU) 2024/1774
• Vereinfachter Rahmen: Artikel 16 DORA (Kleinstunternehmen)

Kernanforderungen

Governance (Art. 5)

Das Leitungsorgan trägt die persönliche Verantwortung für:

• Festlegung, Genehmigung, Überwachung und Verantwortung der Umsetzung aller IKT-Risikomanagement-Maßnahmen
• Festlegung der Risikotoleranz für IKT-Risiken
• Genehmigung und regelmäßige Überprüfung der IKT-Geschäftsfortführungspolitik und -pläne
• Genehmigung und Überprüfung der IKT-Auditpläne und -ergebnisse
• Bereitstellung angemessener Haushaltsmittel

IKT-Risikomanagementrahmen (Art. 6)

Finanzunternehmen müssen einen umfassenden IKT-Risikomanagementrahmen aufbauen, der mindestens umfasst:

1. Strategien, Richtlinien, Verfahren – IKT-Protokolle und -Tools zum Schutz aller Informations- und IKT-Assets
2. Unabhängige Kontrollfunktion – Dedizierte Funktion für IKT-Risikomanagement
3. Jährliche Überprüfung – Dokumentierter Review-Prozess
4. Lessons Learned – Einbau von Erkenntnissen aus Vorfällen und Tests

Identifizierung (Art. 8)

• Vollständiges IKT-Asset-Inventar (Hardware, Software, Netzwerk)
• Identifizierung aller IKT-unterstützten Geschäftsfunktionen
• Mapping von Abhängigkeiten (intern/extern)
• Klassifizierung nach Kritikalität

Schutz & Prävention (Art. 9)

• Angemessene IKT-Sicherheitsrichtlinien
• Netzwerksicherheit, Verschlüsselung, Zugangskontrolle
• Patch Management
• Change Management
• Sicherheitsziele: Verfügbarkeit, Authentizität, Integrität, Vertraulichkeit

Erkennung (Art. 10)

• Mechanismen zur zeitnahen Erkennung anomaler Aktivitäten
• Multiple Verteidigungslinien
• Automatisierte Erkennungssysteme

Reaktion & Wiederherstellung (Art. 11–12)

• IKT-Geschäftsfortführungspolitik (BCP)
• Disaster Recovery Pläne (DRP)
• Backup-Richtlinien mit definierten RPO/RTO
• Regelmäßige Tests der Wiederherstellungspläne

Awareness & Schulung (Art. 13)

• Obligatorische Awareness-Programme für alle Mitarbeitenden und Geschäftsleitung
• Regelmäßige Schulungen zu IKT-Sicherheit
• Spezifische Programme für IKT-Personal

Kommunikation (Art. 14)

• Interne und externe Kommunikationspläne
• Mindestens eine Person als Mediensprecher für IKT-Vorfälle
• Kommunikationsstrategien für verschiedene Zielgruppen

RTS 2024/1774 – Detailanforderungen

Der RTS konkretisiert den IKT-Risikomanagementrahmen mit:

• IKT-Sicherheitsrichtlinien – Mindestinhalte definiert
• Zugangskontrollrichtlinien – Least Privilege, MFA, Privileged Access Management
• Kryptografie-Richtlinien – Verschlüsselungsstandards
• IKT-Projektmanagement – Sicherheit im SDLC
• IKT-Beschaffung – Sicherheitsanforderungen bei Procurement
• Physische Sicherheit – Zugangskontrollen, Umgebungsüberwachung
• Kapazitätsmanagement – Ressourcenplanung und -monitoring

Umsetzungsstrategie für IKT-Dienstleister

Minimum Viable Compliance

Für BAUER GROUP als IKT-Dienstleister sind die wichtigsten Deliverables:

Mapping BAIT → DORA

Rechtsgrundlage

• DORA: Artikel 17–23 (Kapitel III)
• RTS: 2024/1772 (Klassifikation), 2025/301 (Meldefristen/-inhalte)
• ITS: 2025/302 (Meldeformulare/-templates)
• Leitlinie: JC/GL/2024/34 (Kosten- und Verlustschätzung)

Klassifizierung von IKT-Vorfällen (Art. 18)

7 Klassifikationskriterien (RTS 2024/1772)

Ein Vorfall gilt als schwerwiegend, wenn mindestens 2 der 7 Kriterien die definierten Wesentlichkeitsschwellen überschreiten ODER ein einzelnes Kriterium die hohe Wesentlichkeitsschwelle erreicht. Die genauen Schwellwerte sind in RTS 2024/1772 definiert – die oben genannten Werte sind illustrativ.

Meldekette (Art. 19, RTS 2025/301)

3-Stufen-Meldeprozess

Vorfall erkannt
     │
     ▼
Klassifikation als "schwerwiegend"
     │
     ├── T+0h: Interne Eskalation
     │
     ├── T+4h ──► ERSTMELDUNG (Initial Notification)
     │             BaFin-Melde-Hub
     │             Minimal: Wer, Was, Wann, erste Einschätzung
     │
     ├── T+72h ─► ZWISCHENMELDUNG (Intermediate Report)
     │             Status-Update, Impact-Analyse
     │             Falls ungelöst: Aktionsplan mit Timeline
     │
     └── T+1M ──► ABSCHLUSSMELDUNG (Final Report)
                   Root Cause Analysis
                   Lessons Learned
                   Maßnahmen zur Verhinderung

Meldeformat (ITS 2025/302)

• XML-Format gemäß ITS-Template (standardisiert, maschinenlesbar)
• Authentifizierung über qualifizierte elektronische Zertifikate (eIDAS)
• Automatische Empfangsbestätigung mit eindeutiger Vorfallnummer
• BaFin fungiert als zentraler Melde-Hub in Deutschland

Freiwillige Meldung von Cyberbedrohungen (Art. 19 Abs. 2)

• Eigenes Meldeformular
• Freiwillig, aber empfohlen
• Weitergabe anonymisierter Informationen durch Behörden möglich

Umsetzung für IKT-Dienstleister

Pflichten gegenüber Kunden

Als IKT-Dienstleister ist BAUER GROUP kein direkter Meldepflichtiger, aber:

1. Vertragliche Meldepflicht – Kunden müssen binnen 4h melden; BAUER GROUP muss also schneller informieren
2. Unterstützungspflicht – Bereitstellung aller relevanten Informationen für die Meldung des Kunden
3. Kooperationspflicht – Vollständige Mitwirkung bei Root Cause Analysis

Empfohlene SLA-Struktur

Automatisierungspotenzial

Rechtsgrundlage

• DORA: Artikel 24–27 (Kapitel IV)
• RTS: 2025/1190 (TLPT – Inkrafttreten 08.07.2025)
• Rahmenwerk: TIBER-EU (Threat Intelligence-based Ethical Red Teaming)

Zwei Testkategorien

Basistests (Art. 25) – Obligatorisch für alle

Alle Finanzunternehmen müssen ein Testprogramm als integralen Bestandteil des IKT-Risikomanagementrahmens etablieren:

Fortgeschrittene Tests – TLPT (Art. 26–27)

Threat Led Penetration Tests sind nur für systemrelevante Finanzunternehmen mit hohem IKT-Reifegrad vorgesehen.

Testprogramm – Minimum für IKT-Dienstleister

Automatisierbares Basistestprogramm

# dora-test-schedule.yaml
test_program:
  vulnerability_scanning:
    tool: "OpenVAS/Vulnerability Scanner"
    frequency: "weekly"
    scope: "all_production_systems"
    automated: true
    
  dependency_scanning:
    tool: "Container Scanner"
    frequency: "daily"
    scope: "all_containers_and_packages"
    automated: true
    
  sast_scanning:
    tool: "SAST-Tool"
    frequency: "on_commit"
    scope: "all_repositories"
    automated: true
    
  penetration_testing:
    provider: "external"
    frequency: "annually"
    scope: "critical_systems"
    automated: false
    
  bcp_dr_testing:
    frequency: "annually"
    scope: "all_critical_services"
    automated: false
    last_test: null
    next_test: null
    
  network_assessment:
    tool: "Nmap/custom"
    frequency: "quarterly"
    scope: "all_network_segments"
    automated: true
    
  performance_testing:
    tool: "k6/Locust"
    frequency: "quarterly"
    scope: "customer_facing_services"
    automated: true

Evidence Collection

Jeder Test muss dokumentiert werden mit:

• Testdatum, -umfang, -methodik
• Findings (kategorisiert nach Kritikalität)
• Remediation Plan mit Fristen
• Nachweis der Behebung (Retest)
• Management Sign-off

→ Siehe Audit-Trail & Evidence für automatisierte Evidence Collection.

Rechtsgrundlage

• DORA: Artikel 28–44 (Kapitel V)
• RTS: 2024/1773 (Vertragsrichtlinie), 2025/532 (Subcontracting)
• ITS: 2024/2956 (Informationsregister-Templates)
• Delegierte Rechtsakte: 2024/1502 (CTPP-Einstufungskriterien), 2024/1505 (Überwachungsgebühren)
• Leitlinie: JC/GL/2024/36 (ESA-Zusammenarbeit)

Zwei Ebenen des P4

Ebene 1: Allgemeine Prinzipien (Art. 28–30)

Gelten für alle IKT-Drittanbieter-Beziehungen.

Ebene 2: EU-Überwachungsrahmenwerk (Art. 31–44)

Gilt nur für CTPPs (Critical Third-Party Providers) – die 19 von den ESAs benannten kritischen IKT-Drittdienstleister (u.a. AWS, Google Cloud, Microsoft Azure).

Informationsregister (Art. 28 Abs. 3)

Jedes Finanzunternehmen muss ein vollständiges Register aller IKT-Drittanbieter-Verträge führen.

Pflichtinhalte (ITS 2024/2956)

Einreichung bei BaFin

• Erstmalige Einreichung: 30.04.2025 (abgeschlossen)
• Regelmäßige Aktualisierung: Mindestens jährlich + bei wesentlichen Änderungen
• Format: Standardisierte Templates gemäß ITS 2024/2956

8 Mindestvertragsinhalte (Art. 30)

Verträge mit IKT-Drittanbietern müssen mindestens enthalten:

Zusätzlich bei kritischen/wichtigen Funktionen

• Vollständige Subcontracting-Kette offenlegen
• Standortänderungen vorab genehmigen lassen
• Business Impact Analysis des Ausfalls
• Notfall- und Kontinuitätsplanung

RTS 2025/532 – Subcontracting

Seit Inkrafttreten am 22.07.2025 gelten verschärfte Anforderungen für die Untervergabe:

• Due Diligence vor Beauftragung von Unterauftragnehmern
• Risikobewertung der gesamten Subcontracting-Kette
• Vertragliche Durchgriffsmöglichkeiten auf Unterauftragnehmer
• Genehmigungs- und Änderungsprozesse definiert
• Beendigungsverfahren mit Übergangsregelungen

CTPPs – EU-Überwachungsrahmenwerk (Art. 31–44)

Einstufungskriterien (EU 2024/1502)

Die ESAs stufen IKT-Drittdienstleister als kritisch ein basierend auf:

• Systemische Bedeutung für den Finanzsektor
• Substituierbarkeit der Dienste
• Anzahl und Bedeutung der betreuten Finanzunternehmen
• Abhängigkeitsgrad

Benannte CTPPs (Stand November 2025)

19 Technologieunternehmen wurden als CTPP eingestuft, darunter globale Cloud-Plattformen (AWS, Google Cloud, Microsoft Azure).

Pflichten der CTPPs

• Direkte Aufsicht durch Lead Overseer (einer der ESAs)
• Joint Examination Teams (JETs) für Vor-Ort-Inspektionen
• Regelmäßige Berichtspflichten an den Lead Overseer
• Überwachungsgebühren gemäß EU 2024/1505

BAUER GROUP als IKT-Dienstleister – Handlungsfelder

Vertragsanpassung (Priorität 1)

Bestehende und neue Verträge mit Finanzunternehmen müssen alle 8 Mindestvertragsinhalte abdecken:

## DORA-konforme Vertragsklauseln (Checklist)

- [ ] Vollständige Dienstleistungsbeschreibung mit funktionaler Zuordnung
- [ ] Verarbeitungsstandorte (inkl. Backup, DR-Sites)
- [ ] SLA mit messbaren KPIs (Verfügbarkeit, Response Time, MTTR)
- [ ] Datenzugang und -rückgabe bei Vertragsende (Format, Frist, Löschung)
- [ ] Incident-Kooperationsklausel (interne Meldefrist < 1h)
- [ ] Uneingeschränkte Audit-Rechte (vor Ort + remote, auch durch Aufsicht)
- [ ] Außerordentliches Kündigungsrecht bei Compliance-Verstößen
- [ ] Exit-Strategie mit Übergangsplan (min. 6 Monate)
- [ ] Subcontracting-Klausel (Genehmigungsvorbehalt, Transparenz)
- [ ] Standortänderungen nur mit Vorabgenehmigung

Informationsbereitstellung (Priorität 2)

BAUER GROUP muss den Kunden alle Informationen liefern, die diese für ihr Informationsregister benötigen:

• LEI/EUID von BAUER GROUP
• Vollständige Dienstleistungsklassifikation
• Datenverarbeitungsstandorte
• Subcontracting-Kette (falls vorhanden)
• Zertifizierungsnachweise (ISO 27001, SOC 2 etc.)

DORA-Readiness-Nachweis (Priorität 3)

Proaktive Demonstration der DORA-Konformität gegenüber Kunden:

• Standardisiertes Fact Sheet mit allen registerrelevanten Informationen
• DORA Compliance Statement (jährlich aktualisiert)
• Audit-Report oder Zertifizierung
• Incident Response SLA gemäß DORA-Fristen

Rechtsgrundlage

• DORA: Artikel 45 (Kapitel VI)
• Kein eigener RTS/ITS – Regelung direkt im Basisrechtsakt

Anforderungen

Freiwilliger Austausch (Art. 45)

Finanzunternehmen dürfen untereinander Vereinbarungen zum Austausch von Informationen und Erkenntnissen über Cyberbedrohungen treffen.

Voraussetzungen:

• Austausch innerhalb vertrauenswürdiger Gemeinschaften von Finanzunternehmen
• Wahrung der Vertraulichkeit und des Datenschutzes
• Benachrichtigung der zuständigen Behörde über Teilnahme
• Beachtung der Wettbewerbsvorschriften

Inhalte des Austauschs:

• Indicators of Compromise (IoCs)
• Taktiken, Techniken und Verfahren (TTPs)
• Sicherheitswarnungen
• Konfigurationswerkzeuge und -methoden

Behördliche Informationsbereitstellung

Die Aufsichtsbehörden stellen den Finanzunternehmen anonymisierte Informationen über:

• Relevante Cyberbedrohungen
• Schwachstelleninformationen
• Vorfalltrends

Finanzunternehmen müssen Mechanismen einrichten, um diese Informationen zu:

• Empfangen und verifizieren
• In die eigene Risikoanalyse einbeziehen
• Entsprechende Maßnahmen ergreifen

Sektorübergreifende Simulationsübungen

DORA sieht koordinierte Übungen zur Stärkung der sektorweiten Resilienz vor.

BAUER GROUP-Relevanz

Als IKT-Dienstleister ist P5 für BAUER GROUP niedrig priorisiert, aber strategisch relevant:

• Teilnahme an ISACs (Information Sharing and Analysis Centers) empfohlen
• Threat Intelligence Feeds in eigenes Monitoring integrieren
• Kunden proaktiv informieren über relevante Bedrohungen (Mehrwert-Service)

Automatisierung

Gemeinsame Leitlinien der ESAs

JC/GL/2024/34 – Kosten & Verluste

Leitlinie zur standardisierten Schätzung der aggregierten jährlichen Kosten und Verluste aus schwerwiegenden IKT-Vorfällen. Relevant für die wirtschaftliche Impact-Analyse bei Incident Reporting (Kriterium 6).

JC/GL/2024/36 – Überwachungskooperation

Leitlinie zur Zusammenarbeit und zum Informationsaustausch zwischen den ESAs und den nationalen Aufsichtsbehörden im Rahmen der CTPP-Überwachung.

Sonstige Dokumente

Übersicht: 27 Rechtstexte im DORA-Ökosystem

Das DORA-Rahmenwerk besteht aus dem Basisrechtsakt (Level 1), 12 delegierten Rechtsakten/technischen Standards (Level 2) und Leitlinien (Level 3).

Level 1 – Basisrechtsakte

Level 2 – Paket 1 (veröffentlicht 25.06.2024)

Level 2 – Paket 2 (veröffentlicht H2/2024 – H1/2025)

Level 2 – Überwachungsrahmenwerk

Level 3 – Leitlinien (Joint Guidelines)

Sonstige Dokumente

Pillar-Mapping

P1 (Art. 5-16)  → RTS 2024/1774
P2 (Art. 17-23) → RTS 2024/1772 + RTS 2025/301 + ITS 2025/302
P3 (Art. 24-27) → RTS 2025/1190
P4 (Art. 28-44) → RTS 2024/1773 + ITS 2024/2956 + RTS 2025/532
                   + Del.VO 2024/1502 + Del.VO 2024/1505
                   + RTS 2025/295 + RTS 2025/420
P5 (Art. 45)    → Kein eigener RTS/ITS

Offizielle Quellen

Inhalt

Standard-Templates für das Informationsregister über IKT-Drittanbieter-Verträge:

Identifier: LEI oder EUID (nach EU-Kommissionsentscheidung) Ersteinreichung BaFin: 30.04.2025

→ Details: Informationsregister | Register-Automatisierung

Inhalt

Standard-Formulare, Templates und Verfahren für:

• Meldung schwerwiegender IKT-bezogener Vorfälle
• Benachrichtigung über signifikante Cyberbedrohungen

Format: XML (standardisiert, maschinenlesbar) Authentifizierung: Qualifizierte elektronische Zertifikate (eIDAS) Empfangsbestätigung: Automatisch mit eindeutiger Vorfallnummer

→ XML-Template: Incident Pipeline

Inhalt

Spezifiziert die 7 Klassifikationskriterien für IKT-bezogene Vorfälle und Cyberbedrohungen:

1. Betroffene Kunden/Finanzgegenparteien
2. Reputationsauswirkungen
3. Ausfallzeit kritischer Dienste
4. Geografische Ausbreitung
5. Datenverlust (CIA-Triade)
6. Kritikalität betroffener Dienste
7. Wirtschaftliche Auswirkungen

Definiert Wesentlichkeitsschwellen und gibt praktische Beispiele für die Anwendung der Kriterien.

→ Details: P2: Incident Reporting

Inhalt

Detailliert die vertraglichen Mindestanforderungen an IKT-Dienstleisterverträge:

• 8 Pflichtklauseln (Art. 30 Abs. 2)
• Zusatzanforderungen bei kritischen/wichtigen Funktionen (Art. 30 Abs. 3)
• Audit-Rechte und Inspektionsbefugnisse
• Exit-Strategien und Datenmigration
• SLA-Anforderungen mit KPI-Definitionen
• Verhandlungsstrategien

→ Details: P4: Drittparteienrisiko | Vertragsmanagement

Inhalt

Der RTS spezifiziert den vollständigen IKT-Risikomanagementrahmen einschließlich:

• Governance – Rollen, Verantwortlichkeiten, Berichtslinien
• IKT-Asset-Inventar – Identifizierung, Klassifizierung, Dokumentation
• Risikobewertung – Methodik, Schwellwerte, Aktualisierung
• Sicherheitskontrollen – Zugangskontrolle, Kryptografie, Netzwerksicherheit
• BCP/DRP – Geschäftsfortführung, Disaster Recovery, RPO/RTO
• Vereinfachter Rahmen – Für Kleinstunternehmen nach Art. 16

Richtlinien (Mindestinhalte)

Der RTS definiert Mindestinhalte für folgende Richtlinien:

1. IKT-Sicherheitsrichtlinie
2. Zugangskontrollrichtlinie (inkl. MFA, PAM)
3. Kryptografie-Richtlinie
4. IKT-Projektmanagement-Richtlinie (SDLC-Sicherheit)
5. IKT-Beschaffungsrichtlinie
6. Physische Sicherheitsrichtlinie
7. Kapazitätsmanagement-Richtlinie
8. IKT-Änderungsmanagement-Richtlinie

BAUER GROUP-Relevanz

Als IKT-Dienstleister muss BAUER GROUP nachweisen können, dass die eigenen internen Prozesse diesen Standards entsprechen – insbesondere bei Audit-Anfragen von Finanzsektor-Kunden.

→ Umsetzungsdetails: P1: IKT-Risikomanagement

Inhalt

Harmonisierung der Überwachungstätigkeit über CTPPs:

• Informationspflichten bei freiwilliger CTPP-Bewerbung
• Informationsbereitstellung an den Lead Overseer
• Template für Subcontracting-Meldungen an Lead Overseer
• Bewertung der von CTPPs ergriffenen Maßnahmen

Für BAUER GROUP nicht direkt relevant (keine CTPP-Einstufung), aber relevant für das Verständnis der Aufsichtslandschaft.

Inhalt

Definiert Inhalte und Fristen der 3-stufigen Meldekette:

Sowie die freiwillige Meldung signifikanter Cyberbedrohungen.

Fristversäumnis = DORA-Verstoß → Sanktionen gemäß Art. 50–52 DORA i.V.m. nationaler Umsetzung (FinmadiG).

→ Details: P2: Incident Reporting | Incident Pipeline

Inhalt

Spezifiziert Zusammensetzung, Aufgaben und Arbeitsweise der Joint Examination Teams (JETs):

• Ausgewogene Beteiligung von ESA- und nationaler Aufsichtsbehörden-Personal
• Designierungsverfahren
• Aufgabenverteilung
• Arbeitsmodalitäten

Für BAUER GROUP nicht direkt relevant (betrifft nur CTPP-Aufsicht).

Hintergrund

Der ursprüngliche Entwurf wurde am 21.01.2025 von der EU-Kommission zurückgewiesen, da Art. 5 (Monitoring der Subcontracting-Kette) über das Mandat nach Art. 30(5) DORA hinausging. Nach Entfernung von Art. 5 und des zugehörigen Erwägungsgrundes erfolgte die Adoption am 24.03.2025.

Inhalt

Spezifiziert die Anforderungen an Finanzunternehmen bei der Untervergabe von IKT-Diensten:

• Due Diligence vor Beauftragung von Unterauftragnehmern
• Risikobewertung der Subcontracting-Kette
• Vertragliche Bedingungen für Untervergabe
• Genehmigungs- und Änderungsprozesse
• Beendigungsverfahren mit Übergangsregelungen

Betroffene Unternehmen (Art. 2 DORA)

DORA gilt für nahezu alle beaufsichtigten Finanzunternehmen des europäischen Finanzsektors:

Ausnahmen (Art. 2 Abs. 3 & 4 DORA)

Ausgenommen sind unter anderem:

• Verwalter alternativer Investmentfonds nach Art. 3 Abs. 2 AIFMD
• Versicherungs- und Rückversicherungsunternehmen nach Art. 4 der Solvency-II-RL (Ausnahme nach Größe)
• Bestimmte Versicherungsvermittler (Kleinstunternehmen, kleine und mittlere)
• Post-Trade-Infrastrukturen aus Drittstaaten (unter Bedingungen)

Unternehmenskategorisierung (Proportionalitätsprinzip)

FinmadiG-Erweiterung (ab 01.01.2027)

Das Finanzmarktdigitalisierungsgesetz erweitert in Deutschland den DORA-Anwendungsbereich auf:

• Finanzdienstleistungsinstitute (Leasing, Factoring)
• Kryptowertpapierregisterführer
• Zweigstellen nach § 53 KWG
• Versicherungsholdings (§ 7 Nr. 31, § 294 Abs. 4 VAG)
• Alle KWG-Institute, die nicht bereits nach Art. 2 DORA erfasst sind

Übergangsregelung: Meldepflichten (Kapitel III) gelten bereits seit 17.01.2025, voller IKT-Risikomanagementrahmen ab 01.01.2027. BAIT gelten übergangsweise bis 31.12.2026.

Chronologische Übersicht

Level 1 – Verordnung

Level 2 – RTS/ITS (chronologisch)

Key Deadlines

Level 3 – Leitlinien

BaFin-spezifische Termine

Die BaFin bietet jährlich Workshops zur Vorbereitung der Informationsregister-Einreichung an. Die nächste Einreichungsperiode für 2026 wird voraussichtlich im Q2 2026 stattfinden.

Kapitel I – Allgemeine Bestimmungen (Art. 1–4)

Kapitel II – IKT-Risikomanagement (Art. 5–16)

Kapitel III – Vorfallmanagement (Art. 17–23)

Kapitel IV – Resilienztests (Art. 24–27)

Kapitel V – Drittparteienrisiko (Art. 28–44)

Kapitel VI – Informationsaustausch (Art. 45)

Kapitel VII–IX (Art. 46–64)

Behörden, Übergangs- und Schlussbestimmungen.

Europäische Ebene

Nationale Ebene (Deutschland)

CTPP-Aufsicht

19 CTPPs wurden im November 2025 benannt (u.a. AWS, Google Cloud, Microsoft Azure). Jeder CTPP erhält einen Lead Overseer aus den ESAs, der die direkte Aufsicht führt.

Neue Anforderungen ohne BAIT-Pendant

Primärrechtsakte

Nationale Umsetzung (Deutschland)

BaFin-Veröffentlichungen

Abgelöste Regelwerke

Weiterführende Links

Vollständiges RTS/ITS-Verzeichnis → RTS & ITS Übersicht

Verfügbare Templates

Alle Templates sind als Code/Markdown im Repository verfügbar und können direkt in die eigene Infrastruktur übernommen werden.