Overview

The Finanzmarktdigitalisierungsgesetz (Financial Markets Digitalisation Act, FinmadiG) was published in the Federal Law Gazette on 27.12.2024 and serves as the national implementation measure for DORA, MiCAR, and the Funds Transfer Regulation.

Key DORA-Relevant Provisions

Extended Scope of Application (Section 1a(2a) KWG, as amended)

From 01.01.2027, the following are additionally subject to DORA:

Transitional Provision (Section 65a(3) KWG, as amended)

For the newly included institutions:

• From 17.01.2025: Reporting obligations for major ICT-related incidents (Chapter III DORA)
• From 01.01.2027: Full ICT risk management framework (for microenterprises: simplified framework under Art. 16)

Replacement of the xAIT Circulars

Sanctions

FinmadiG empowers BaFin to impose:

Audit Obligations

Practical Implications

For Existing Financial Sector Clients

Clients will proactively approach BAUER GROUP with:

1. Requests for information register data (fact sheet)
2. Contract amendments (DORA clauses)
3. Audit rights (on-site, remote, by supervisory authority)
4. SLA adjustments (DORA-compliant reporting deadlines)

Extended Scope from 2027

The FinmadiG extension brings additional entity groups (including financial services institutions, crypto securities register operators) under DORA from 01.01.2027, requiring DORA-compliant ICT service providers for the first time.

Architecture of the Regulation

DORA follows the Lamfalussy process:

• Level 1 – Base legal act: Regulation (EU) 2022/2554 (64 articles, 9 chapters)
• Level 2 – Specification: RTS (Regulatory Technical Standards), ITS (Implementing Technical Standards), Delegated Acts
• Level 3 – Guidelines: Joint Guidelines of the ESAs (not legally binding, but comply-or-explain)

Pillar Mapping

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

Prioritisation for ICT Service Providers

BAUER GROUP implemented the pillars in the following priority order:

Interdependencies

The pillars do not stand in isolation:

• P1 (Risk Management) is the foundation for all other pillars
• P2 (Incident Reporting) requires the classification criteria from P1
• P3 (Testing) validates the measures from P1
• P4 (Third Parties) requires integration into the risk framework of P1
• P5 (Sharing) feeds insights back into P1

Proportionality Principle

DORA takes the proportionality principle into account: requirements shall be proportionate to the size, risk profile, and complexity of financial entities.

Simplified ICT Risk Management Framework (Art. 16)

Microenterprises may apply a simplified ICT risk management framework. This includes:

• Documentation of all ICT-supported business functions and associated risks
• Protection of all ICT systems against the most common cyber threats
• Ensuring physical security and environmental protection
• Access control for ICT systems
• Mechanisms for timely detection of anomalous activities
• Business continuity measures and backup strategies
• Review and lessons learned following ICT incidents

Exemptions by Entity Type

BaFin Supervisory Communication (21.08.2025)

BaFin has published guidance on implementing the simplified ICT risk management framework, including specific documentation requirements for eligible entities.

BAUER GROUP Classification

BAUER GROUP as an ICT service provider does not directly benefit from the proportionality principle, as the requirements are imposed indirectly through client contracts. However: clients subject to the simplified framework impose less demanding contractual requirements – this is addressed through tiered contract modules.

Content

Specifies the requirements for Threat Led Penetration Tests (TLPT):

• Criteria for determining entities subject to TLPT
• Scope of tests (critical functions, live production systems)
• Methodology based on TIBER-EU (8 phases)
• Red/blue/white team requirements
• Provider qualification for TLPT testers
• Timeline typically 9–14 months
• Budget typically EUR 150,000–500,000

Deadline: First TLPT before 17.01.2028 for systemically important financial entities. Frequency: Every 3 years.

BAUER GROUP Relevance

BAUER GROUP is not subject to TLPT obligations, but must participate in and cooperate with TLPT tests of clients (Art. 26(4)). A TLPT cooperation clause is included in all contracts with systemically important financial entities.

→ Details: P3: Resilience Testing

Evidence Collection Strategy

Every DORA-relevant activity is documented with verifiable evidence. The retention period is at least 5 years (Art. 19(6) DORA).

Automatic Evidence Collection

Automated Compliance Report (Pseudocode)

# Pseudocode – Conceptual structure of the monthly DORA compliance report

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 Package

For audits by clients, audit firms, or BaFin, BAUER GROUP provides a standardised, DORA-article-referenced audit package. The package is structured so that each audit area maps directly to the applicable regulatory requirements.

Package Structure

audit-package-[YYYY-MM]/
│
├── 00-management-summary/
│   ├── DORA-Compliance-Statement.pdf
│   ├── Scope-and-Applicability.pdf
│   └── Audit-Coordination-Contacts.pdf
│
├── 01-governance/                              ── Art. 5 DORA
│   ├── ICT-Risk-Management-Framework.pdf
│   ├── Governance-Structure-Orgchart.pdf
│   ├── Management-Board-Resolutions.pdf
│   ├── Role-Matrix-ICT-Responsibilities.pdf
│   └── Annual-Review-Evidence-[Year].pdf
│
├── 02-risk-management/                         ── Art. 6–16 DORA, RTS 2024/1774
│   ├── ICT-Risk-Analysis-[Year].pdf
│   ├── Asset-Inventory-Extract.csv
│   ├── Criticality-Classification.pdf
│   ├── ICT-Security-Policy.pdf
│   ├── Access-Control-Policy.pdf
│   ├── Cryptography-and-Encryption-Policy.pdf
│   ├── Backup-and-Recovery-Policy.pdf
│   ├── Patch-Management-Policy.pdf
│   ├── BCP-Plan.pdf
│   ├── DRP-Plan.pdf
│   └── Communication-Plan.pdf
│
├── 03-incident-management/                     ── Art. 17–23 DORA, RTS 2024/1772, RTS 2025/301
│   ├── Incident-Response-Playbook.pdf
│   ├── Classification-Schema-7-Criteria.pdf
│   ├── Escalation-Matrix.pdf
│   ├── SLA-Reporting-Deadlines-Documentation.pdf
│   ├── Pre-filled-XML-Template.xml
│   ├── Incident-Log-[Period].csv
│   └── Major-Incident-Reports/
│       └── [Incident-ID]-RCA-Report.pdf
│
├── 04-resilience-testing/                      ── Art. 24–27 DORA, RTS 2025/1190
│   ├── Test-Programme-Policy.pdf
│   ├── Vulnerability-Scan-Reports/
│   │   ├── Infrastructure-Scan-[Month].pdf
│   │   └── Container-Scan-[Month].pdf
│   ├── SAST-Reports/
│   │   └── SAST-Summary-[Quarter].pdf
│   ├── Pentest-Report-[Year].pdf
│   ├── BCP-DRP-Test-Protocol-[Year].pdf
│   └── Performance-Baseline-[Year].pdf
│
├── 05-third-party-risk/                        ── Art. 28–44 DORA, RTS 2024/1773, ITS 2024/2956
│   ├── DORA-Contract-Clauses-Template.pdf
│   ├── Contract-Compliance-Status-Matrix.csv
│   ├── Information-Register-Data-Package.json
│   ├── Subcontracting-Register.csv
│   ├── Exit-Strategy-Template.pdf
│   ├── Fact-Sheet-Template.pdf
│   └── Audit-Rights-Evidence.pdf
│
├── 06-awareness-and-communication/             ── Art. 13–14 DORA
│   ├── Awareness-Programme-Overview.pdf
│   ├── Training-Plan-[Year].pdf
│   ├── Attendance-Records-and-Certificates/
│   │   └── [Training]-Attendance-Confirmation.pdf
│   └── Communication-Plan-ICT-Incidents.pdf
│
├── 07-certifications-and-evidence/
│   ├── ISO-27001-Certificate.pdf
│   ├── SOC-2-Report.pdf (if applicable)
│   └── [Additional-Certificates].pdf
│
└── 08-appendix/
    ├── DORA-Article-Index-Mapping.pdf
    ├── Glossary.pdf
    └── Audit-Package-Change-History.pdf

Article Mapping per Audit Area

Provision Process

Principle

Every DORA requirement is represented as verifiable code or machine-readable rules. Compliance thereby becomes reproducible, versioned, and auditable.

Policy-as-Code (OPA/Rego)

Security policies as executable policies:

# dora_policies.rego
package dora

# Art. 9: Encryption for data in transit
deny[msg] {
    input.type == "ingress"
    not input.tls.enabled
    msg := "DORA Art. 9: TLS must be enabled for all ingress connections"
}

# Art. 9: Access control - no default admin
deny[msg] {
    input.type == "user"
    input.username == "admin"
    input.default_password == true
    msg := "DORA RTS 2024/1774: Default admin accounts must be disabled"
}

# Art. 11: Backup RPO check
warn[msg] {
    input.type == "backup_config"
    input.rpo_hours > 24
    msg := sprintf("DORA Art. 11: RPO of %dh exceeds recommended value (24h)", [input.rpo_hours])
}

Infrastructure-as-Code Compliance

IaC-Scanner for 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-Specific Custom Checks

# Pseudocode – conceptual representation
# 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: Encryption of data at rest"""

    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 retention obligation
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'

Git-Based Policy Lifecycle

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│ Draft       │────►│ Review      │────►│ Approval    │
│ (branch)    │     │ (MR review) │     │ (merge)     │
└─────────────┘     └─────────────┘     └─────────────┘
       │                   │                    │
       │              Comments             Git tag
       │              Changes              v1.0.0
       │                                       │
       │                              ┌────────┴────────┐
       │                              │ Automatic        │
       │                              │ build → deploy   │
       │                              │ → internal docs  │
       │                              └─────────────────┘

Each policy change:

1. Is prepared in a branch
2. Undergoes code review (four-eyes principle)
3. Is merged after approval
4. Automatically receives a SemVer tag
5. Automatically generates a changelog entry
6. Is automatically published on the internal documentation site

Automated Incident Processing

SIEM Alert
       │
       ▼
┌──────────────┐
│ Webhook      │ (SIEM → Workflow-Automation)
│ Receiver     │
└──────┬───────┘
       │
       ▼
┌──────────────┐
│ Classifier   │ Check 6 DORA criteria
│ (Rule Engine)│ → MINOR / SIGNIFICANT / MAJOR
└──────┬───────┘
       │
       ├── MINOR ──────► Log & Monitor
       │
       ├── SIGNIFICANT ► Log + Notify Team Lead
       │
       └── MAJOR ──────► Escalation chain:
                         1. Alerting-System (On-Call)
                         2. Email management
                         3. Client 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-criteria 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 Management", "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-Client-LEI]</LEI>
    <Name>[Client name]</Name>
  </ReportingEntity>
  <IncidentDetails>
    <DetectionTimestamp>[ISO-8601]</DetectionTimestamp>
    <ClassificationTimestamp>[ISO-8601]</ClassificationTimestamp>
    <Description>[Auto-generated from SIEM alert]</Description>
    <AffectedServices>[From asset inventory]</AffectedServices>
    <Classification>
      <ClientsAffected>[Count]</ClientsAffected>
      <DowntimeHours>[Hours]</DowntimeHours>
      <GeographicSpread>[Countries]</GeographicSpread>
      <DataLoss>[true/false]</DataLoss>
      <CriticalService>[true/false]</CriticalService>
      <EconomicImpact>[EUR]</EconomicImpact>
    </Classification>
  </IncidentDetails>
  <ImmediateActions>[Description]</ImmediateActions>
  <ContactPerson>
    <Name>[Media spokesperson]</Name>
    <Phone>[Phone]</Phone>
    <Email>[Email]</Email>
  </ContactPerson>
</IncidentReport>

Principle: Minimal Effort, Maximum Compliance

BAUER GROUP's DORA implementation follows the principle of "compliance-as-code": every requirement is automated as far as possible, templates instead of prose, monitoring instead of manual reporting.

┌────────────────────────────────────────────────────┐
│              DORA Automation Stack                   │
├────────────────────────────────────────────────────┤
│  Layer 4: Reporting & Evidence                      │
│  ├── Automated compliance reports                   │
│  ├── Audit trail (Git-based)                        │
│  └── Dashboard (Dashboard/custom)                     │
├────────────────────────────────────────────────────┤
│  Layer 3: Detection & Response                      │
│  ├── SIEM (SIEM)                          │
│  ├── Incident pipeline (webhook → classify → alert)│
│  └── Pre-filled reporting templates (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)                          │
│  ├── ICT asset inventory (auto-discovered)         │
│  ├── Risk register (Notion/custom)                 │
│  └── Contract register (CRM + custom)          │
└────────────────────────────────────────────────────┘

Mapping: DORA Requirement → Automation

Components in Detail

1. Asset Management (Layer 1)

# netbox-auto-discovery.yaml
# Cron job: weekly
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 – conceptual representation
# incident_classifier.py (pseudocode)
DORA_THRESHOLDS = {
    "affected_customers_pct": 10,    # > 10% = major
    "affected_customers_abs": 100000, # > 100k = major
    "downtime_hours": 2,              # > 2h critical services
    "geo_spread": 2,                  # >= 2 Member States
    "data_loss": True,                # CIA affected
    "critical_service": True,         # Critical function
    "economic_impact_eur": 100000,    # > EUR 100k
}

def classify_incident(incident) -> str:
    """Classifies according to 6 DORA criteria."""
    criteria_met = 0
    for criterion, threshold in DORA_THRESHOLDS.items():
        if incident.get(criterion) >= threshold:
            criteria_met += 1

    if criteria_met >= 2:
        return "MAJOR"  # → reporting obligation
    elif criteria_met == 1:
        return "SIGNIFICANT"  # → monitoring
    else:
        return "MINOR"  # → logging

4. Reporting & Evidence (Layer 4)

# compliance-report.yaml
# Generates automated 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: [management, 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: [management, clients]

Git-Based Policy Management

All DORA-relevant policies are maintained as Markdown in the Git repository:

policies/
├── ICT-Security-Policy.md                # Art. 9
├── ICT-Risk-Management-Framework.md      # Art. 6
├── Incident-Response-Policy.md           # Art. 17-19
├── Business-Continuity-Plan.md           # Art. 11
├── Disaster-Recovery-Plan.md             # Art. 12
├── Communication-Plan.md                 # Art. 14
├── Third-Party-Management-Policy.md      # Art. 28-30
├── Awareness-Training-Plan.md            # Art. 13
├── Test-Programme.md                     # Art. 25
└── CHANGELOG.md                          # Audit trail

Benefits:

• Complete audit trail (Git history)
• Review process via merge requests
• Automatic versioning (SemVer)
• Automatic build → documentation deployment
• Diff-based annual review (what has changed?)

Effort Comparison

DORA-Compliant Monitoring (Art. 10)

Financial entities and their ICT service providers must implement mechanisms for timely detection of anomalous activities.

Monitoring Stack

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

DORA-Specific 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-critical service {{ $labels.instance }} unreachable"
          description: "Service has been down for > 5min. DORA Art. 18: Downtime threshold > 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: "Elevated error rate on {{ $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: "Possible brute-force attack on {{ $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: Security incident detected on critical system</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 attempt detected (>10 failures/min)</description>
    <group>dora,brute_force,</group>
  </rule>
</group>

DORA Compliance Dashboard (Dashboard)

Recommended panels:

Objective

Automated management and export of information register data (ITS 2024/2956) for all financial sector clients.

Architecture

CRM                    BAUER GROUP Internal
┌──────────────┐              ┌──────────────┐
│ Deals        │              │ CMDB       │
│ (Clients)    │──────────────│ (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": "Service Description", "type": "string" },
    { "name": "criticality", "label": "Criticality", "type": "enumeration",
      "options": ["critical", "important", "standard"] },
    { "name": "data_processing_locations", "label": "Data Processing Locations", "type": "string" },
    { "name": "data_storage_locations", "label": "Data Storage Locations", "type": "string" },
    { "name": "sla_availability", "label": "SLA Availability (%)", "type": "number" },
    { "name": "sla_response_time", "label": "SLA Response Time", "type": "string" },
    { "name": "subcontractors", "label": "Subcontractors", "type": "string" },
    { "name": "contract_start", "label": "Contract Start", "type": "date" },
    { "name": "contract_end", "label": "Contract End", "type": "date" },
    { "name": "exit_transition_months", "label": "Exit Transition Period (Months)", "type": "number" },
    { "name": "last_audit_date", "label": "Last Audit", "type": "date" },
    { "name": "dora_compliant", "label": "DORA Compliant", "type": "boolean" }
  ]
}

Export Script

# Pseudocode – conceptual representation
#!/usr/bin/env python3
"""DORA Register Export – Generates client-specific data packages."""

import json
from datetime import date
# CRM-Client initialisieren

def export_dora_register(customer_id: str) -> dict:
    """Exports DORA register data for a client."""
    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: monthly or upon change
# Notification: email to client contact person

Annual Review Workflow

1. T-30d: Automatic reminder to all financial sector clients
2. T-14d: Export current register data, diff against previous year
3. T-7d: Internal review, management approval
4. T-0: Send updated fact sheet to all clients

Contractual Requirements (Art. 30)

All contracts with ICT third-party service providers must contain the 8 minimum contractual requirements. Additional requirements apply for critical/important functions.

Contract Module System for BAUER GROUP

Module A: Baseline (all financial sector clients)

• Service description with functional mapping
• Data processing locations
• SLA with measurable KPIs
• Data access and return
• Incident cooperation clause
• Audit rights
• Termination rights
• Exit strategy

Module B: Extended (critical/important functions)

In addition to Module A:

• Disclose complete subcontracting chain
• Location changes only with prior approval
• Business impact analysis
• Specific emergency and continuity planning
• TLPT cooperation clause
• Regular compliance evidence

Contract Review Checklist

## DORA Contract Review – Checklist

**Contract:** ___________________
**Client:** ___________________
**Date:** ___________________
**Reviewer:** ___________________

### Art. 30(2) – Minimum Requirements
- [ ] (a) Clear and complete description of all functions/services
- [ ] (a) Statement whether critical/important function is supported
- [ ] (b) Data processing and storage locations
- [ ] (b) Prior notification obligation for location changes
- [ ] (c) Availability, authenticity, integrity, confidentiality provisions
- [ ] (d) Data access, return, and deletion upon contract termination
- [ ] (e) SLAs with quantitative and qualitative KPIs
- [ ] (f) Cooperation obligation for ICT incidents
- [ ] (g) Termination rights and minimum notice periods

### Art. 30(3) – Additional for Critical Functions
- [ ] (a) Complete service description with SLAs
- [ ] (b) Notification obligations and reporting deadlines
- [ ] (c) Business continuity and emergency plans
- [ ] (d) Participation in TLPT
- [ ] (e) Unrestricted audit rights (incl. supervisory authority)
- [ ] (f) Exit strategies with transition periods
- [ ] (g) Subcontracting transparency and approval

### RTS 2025/532 – Subcontracting
- [ ] Due diligence for subcontractors documented
- [ ] Risk assessment of subcontracting chain
- [ ] Contractual pass-through rights
- [ ] Change/approval process defined

### Result
- [ ] ✅ Fully DORA-compliant
- [ ] ⚠️ Adjustment needed (see appendix)
- [ ] ❌ Material gaps (contract amendment required)

Legacy Contract Migration

1. Inventory: Export all active contracts with financial sector clients aus dem CRM
2. Gap check: Review each contract against checklist
3. Prioritisation: Critical functions first
4. Adjustment: Contract amendment or new contract
5. Tracking: Status in CRM-Pipeline as custom property

BAIT/xAIT → DORA Mapping

The gap analysis is the starting point for DORA implementation. For organisations previously aligned with BAIT/VAIT/ZAIT/KAIT, the leap to DORA is manageable – the key changes lie in formalisation, governance, and third-party management.

Gap Matrix

Results Summary

Low Gaps (existing compliance sufficient)

• ICT security policies (extension)
• BCP/DRP (formalisation)
• Baseline tests (extension)

Medium Gaps (adjustment required)

• Governance formalisation
• Asset inventory with criticality classification
• Detection (SIEM expansion)
• Communication plans
• Incident classification

High Gaps (new development required)

• Incident reporting (new format, new deadlines)
• Third-party information register
• Contract adjustment for all financial sector clients
• Subcontracting governance

Next Steps

→ Implementation Roadmap

BAUER GROUP as ICT Third-Party Provider Under DORA

BAUER GROUP as an IT service provider with clients in the financial sector falls under Art. 2(1)(u) DORA – ICT third-party service providers. The obligations do not arise directly from DORA but indirectly through the contractual requirements of financial entities (Art. 28–30).

Obligations Matrix

Direct Obligations (if designated as CTPP)

Indirect Obligations (through client contracts)

Compliance Status BAUER GROUP

Implemented Measures

• [x] DORA awareness in management
• [x] Inventory of financial sector clients
• [x] Identification of affected contracts
• [x] DORA-compliant contract clauses template created
• [x] Standard contract with all minimum requirements (Art. 30)
• [x] DORA fact sheet for clients (register information)
• [x] SLA definitions with DORA-compliant KPIs
• [x] Exit strategy template
• [x] Subcontracting disclosure
• [x] Incident response playbook with DORA deadlines
• [x] Asset inventory with DORA classification
• [x] Vulnerability management pipeline
• [x] Awareness training for all employees
• [x] BCP/DRP documented and tested
• [x] Annual review of ICT risk management framework established
• [ ] Annual baseline tests (vulnerability scan, pentest)
• [ ] Annual update of information register data
• [ ] Annual awareness training
• [ ] Compliance report for clients

DORA Fact Sheet (Template for Clients)

Standardised information sheet that BAUER GROUP provides to its financial sector clients:

# DORA ICT Third-Party Provider – Information Sheet

## Provider Identification
- **Company:** BAUER GROUP
- **LEI:** [insert LEI]
- **Registration number:** [insert HRx]
- **Address:** [address]
- **DORA contact person:** [name, email, phone]

## Services
- [List of ICT services provided to the client]
- Classification: [critical/important/other]

## Data Processing Locations
- **Primary:** Germany (location XY)
- **Backup/DR:** Germany (location YZ)
- **Cloud infrastructure:** [provider, region]

## Subcontracting
- **Subcontractors:** [list or "none"]
- **Approval requirement:** Yes, per contract

## Security Standards
- **Certifications:** [ISO 27001, SOC 2, etc.]
- **Last audit:** [date]
- **Next audit:** [date]

## Incident Response
- **Internal reporting deadline to clients:** < 1 hour
- **24/7 availability:** [Yes/No, contact]
- **TLPT cooperation commitment:** Yes

## Exit Strategy
- **Transition period:** Minimum 6 months
- **Data export format:** [formats]
- **Deletion confirmation:** Yes, in writing

## Last updated: [date]

Model Contract Clauses

Incident Cooperation

The contractor undertakes to inform the client without undue delay, but no later than 60 minutes after detecting an ICT-related incident that affects or may affect the services used by the client. The contractor shall support the client in classifying, documenting, and reporting the incident in accordance with the requirements of Regulation (EU) 2022/2554 (DORA).

Audit Rights

The client, its competent supervisory authority, and third parties appointed by them shall have the right to conduct on-site inspections and audits at the contractor's premises. This includes unrestricted access to the contractor's premises, information, systems, and personnel, insofar as this is necessary for verifying compliance with contractual and regulatory requirements. The contractor shall actively support these audits without undue delay.

Exit Clause

Upon termination of the contract, the contractor shall grant a transition period of at least 6 months, during which all services shall be continued under unchanged conditions. The contractor shall make all data available to the client in a commonly used, machine-readable format and shall confirm the complete deletion of data in writing upon completion of data transfer.

DORA-Compliant Incident Response Process

Phases

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

Phase 1: Detection (T+0)

Automated via SIEM/monitoring:

• SIEM-Alerts → incident queue
• Anomaly detection (ML-based or rule-based)
• External reports (clients, partners, authorities)

Responsible: On-call engineer / SOC

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

DORA classification (6 criteria):

Result: ≥ 2 criteria = MAJOR → reporting obligation

Escalation matrix:

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

• Immediate measures to limit damage
• Isolation of affected systems
• Activation of workarounds/redundancies
• Forensic preservation (evidence)

Phase 4: Report & Notify

To clients (T+1h after MAJOR classification):

Subject: [DORA Notification] ICT Incident – [Brief Description]

Dear [contact person],

we hereby inform you pursuant to our contractual DORA cooperation obligation
about an ICT-related incident:

Time of detection: [date/time]
Affected services: [list]
Current assessment: [MAJOR/SIGNIFICANT]
Criteria affected: [listing of 6 criteria with status]
Immediate measures: [description]
Next steps: [timeline]
Contact person: [name, phone, email]

A detailed interim report will follow within 24 hours.

Client to BaFin (T+4h):

• Client uses BaFin portal with XML template (ITS 2025/302)
• BAUER GROUP provides all technical details

Phase 5: Recover & Review

• Restore affected services
• Interim report to clients (T+24h)
• Root cause analysis (T+2w)
• Final report to clients (T+2–4w)
• Incorporate lessons learned into ICT risk management framework
• Adjust detection rules if necessary

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: "management"
          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"

Requirement (Art. 28(3))

Financial entities must maintain a complete register of all contractual arrangements with ICT third-party service providers and update it regularly.

Template Structure (ITS 2024/2956)

The information register comprises the following data tables:

BAUER GROUP Deliverable: Standardised Data Package

For each client in the financial sector, BAUER GROUP provides a standardised data package:

{
  "provider": {
    "name": "BAUER GROUP",
    "lei": "[insert LEI]",
    "registration_country": "DE",
    "address": "[address]",
    "contact_dora": {
      "name": "[name]",
      "email": "[email]",
      "phone": "[phone]"
    }
  },
  "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"
}

Automation: CRM → Register Export

The register export can be automated via CRM Custom Objects:

1. Custom object DORA_Service im CRM with the fields listed above
2. Automated export via CRM-API → JSON/CSV
3. Client portal or automated email dispatch upon updates
4. Annual review workflow as CRM-Workflow

→ See Register Automation for the technical implementation.

Implementation Overview for ICT Service Providers

Implementation followed the principle: What causes immediate harm if not addressed?

Q1 2025        Q2 2025        Q3 2025        Q4 2025        2026           2027
────┬──────────┬──────────────┬──────────────┬──────────────┬──────────────┬────►
    │          │              │              │              │              │
    │  ┌───────┴──────┐      │              │              │              │
    │  │ P2: Incident │      │              │              │              │
    │  │ reporting    │      │              │              │              │
    │  │ process set  │      │              │              │              │
    │  │ up           │      │              │              │              │
    │  └──────────────┘      │              │              │              │
    │          │              │              │              │              │
    │  ┌───────┴──────────────┴──────┐      │              │              │
    │  │ P4: Contracts adjusted,     │      │              │              │
    │  │ information register data   │      │              │              │
    │  │ provided (client deadline:  │      │              │              │
    │  │ 30.04.2025)                 │      │              │              │
    │  └─────────────────────────────┘      │              │              │
    │                         │              │              │              │
    │                 ┌───────┴──────────────┴──────┐      │              │
    │                 │ P1: ICT risk management      │      │              │
    │                 │ framework formalised,         │      │              │
    │                 │ asset inventory, policies     │      │              │
    │                 └────────────────────────────────┘    │              │
    │                                        │              │              │
    │                                ┌───────┴──────────────┴──────┐      │
    │                                │ P3: Test programme           │      │
    │                                │ established, automation      │      │
    │                                │ rolled out                   │      │
    │                                └─────────────────────────────┘      │
    │                                                       │              │
    │                                               ┌───────┴──────┐      │
    │                                               │ P5: Threat   │      │
    │                                               │ intelligence │      │
    │                                               │ integrated   │      │
    │                                               └──────────────┘      │
    │                                                              ┌──────┴──┐
    │                                                              │FinmadiG │
    │                                                              │Extension│
    │                                                              └─────────┘

Phase 1: Immediate Actions (Q1 2025) ✅

P2: Incident Reporting

P4: Contractual Foundations

Phase 2: Contract Adjustment (Q2 2025) ✅

P4: Register & Contracts

Phase 3: Operational Implementation (Q3–Q4 2025) ✅

P1: ICT Risk Management

P3: Test Programme

Phase 4: Ongoing Operations (from 2026) ✅

Ongoing Effort (annually)

Sanctions Regime

DORA (Art. 50–52) and FinmadiG provide for a graduated sanctions regime. DORA delegates the determination of specific sanction amounts to Member States – the following figures refer to the German implementation (FinmadiG).

Against Financial Entities (Art. 50–52 DORA, FinmadiG)

Against Critical ICT Third-Party Service Providers (CTPPs, Art. 35(8) DORA)

Against ICT Service Providers (non-CTPP)

Non-critical ICT service providers like BAUER GROUP are not subject to direct DORA sanctions. The consequences are indirect:

Practical Liability Scenarios for BAUER GROUP

Relationship Between the Legal Acts

Pursuant to Art. 1(2), DORA is a sector-specific legal act (lex specialis) within the meaning of Art. 4 of the NIS2 Directive. This means:

• DORA takes precedence over NIS2 in the areas of ICT risk management and incident reporting
• Financial entities remain part of the NIS2 ecosystem but apply DORA requirements
• ICT service providers serving both financial and other sectors may be subject to both regulatory frameworks

Comparison Matrix

Overlaps for BAUER GROUP

As an IT service provider serving both financial and other sectors:

Synergy Effects

Organisations that fully implement DORA have automatically covered the following requirements of other regulatory frameworks:

• NIS2: ~80% of requirements (gap: sector-specific NIS2 requirements)
• CRA: Partially (product safety is standalone)
• AI Act: Limited overlap (only when AI is used in financial services)

What is DORA?

The Digital Operational Resilience Act (Regulation (EU) 2022/2554) establishes a uniform EU-wide legal framework for digital operational resilience in the financial sector. As an EU Regulation, DORA is directly applicable in all Member States without the need for national transposition.

The 5 Pillars

DORA is structured around five core areas of requirements:

Relevance for ICT Service Providers

BAUER GROUP as an ICT service provider for financial entities is affected in two ways:

1. Indirectly – Clients in the financial sector demand DORA-compliant contractual arrangements (Art. 28–30), audit rights, exit strategies, and subcontracting transparency
2. Potentially directly – If designated as a CTPP (Critical ICT Third-Party Provider) by the ESAs, the EU oversight framework applies (Art. 31–44)

The strategy: Demonstrate regulatory compliance externally (contractual clauses, certifications, documentation) with minimal internal effort (automation, templates, compliance-as-code).

Distinction from NIS2, CRA, AI Act

Quick Start

1. Check scope of application – Am I affected? As a financial entity or ICT service provider?
2. Clarify proportionality – Microenterprise, simplified framework?
3. Conduct gap analysis – BAIT/VAIT/ZAIT to DORA mapping
4. Create roadmap – Prioritisation: P2 → P4 → P1 → P3 → P5
5. Plan automation – Compliance-as-code strategy

Legal Basis

• DORA: Articles 5–16 (Chapter II)
• RTS: Delegated Regulation (EU) 2024/1774
• Simplified framework: Article 16 DORA (microenterprises)

Core Requirements

Governance (Art. 5)

The management body bears personal responsibility for:

• Defining, approving, overseeing, and being accountable for the implementation of all ICT risk management measures
• Setting the risk tolerance for ICT risks
• Approving and periodically reviewing the ICT business continuity policy and plans
• Approving and reviewing ICT audit plans and results
• Allocating adequate budget resources

ICT Risk Management Framework (Art. 6)

Financial entities must establish a comprehensive ICT risk management framework that includes at a minimum:

1. Strategies, policies, procedures – ICT protocols and tools for the protection of all information and ICT assets
2. Independent control function – Dedicated function for ICT risk management
3. Annual review – Documented review process
4. Lessons learned – Integration of findings from incidents and tests

Identification (Art. 8)

• Complete ICT asset inventory (hardware, software, network)
• Identification of all ICT-supported business functions
• Mapping of dependencies (internal/external)
• Classification by criticality

Protection & Prevention (Art. 9)

• Appropriate ICT security policies
• Network security, encryption, access control
• Patch management
• Change management
• Security objectives: Availability, authenticity, integrity, confidentiality

Detection (Art. 10)

• Mechanisms for timely detection of anomalous activities
• Multiple lines of defence
• Automated detection systems

Response & Recovery (Art. 11–12)

• ICT business continuity policy (BCP)
• Disaster recovery plans (DRP)
• Backup policies with defined RPO/RTO
• Regular testing of recovery plans

Awareness & Training (Art. 13)

• Mandatory awareness programmes for all staff and management
• Regular training on ICT security
• Specific programmes for ICT personnel

Communication (Art. 14)

• Internal and external communication plans
• At least one designated media spokesperson for ICT incidents
• Communication strategies for different audiences

RTS 2024/1774 – Detailed Requirements

The RTS specifies the ICT risk management framework with:

• ICT security policies – Minimum content defined
• Access control policies – Least privilege, MFA, privileged access management
• Cryptography policies – Encryption standards
• ICT project management – Security in the SDLC
• ICT procurement – Security requirements in procurement
• Physical security – Access controls, environmental monitoring
• Capacity management – Resource planning and monitoring

Implementation Strategy for ICT Service Providers

Minimum Viable Compliance

For BAUER GROUP as an ICT service provider, the key deliverables are:

Mapping BAIT → DORA

Legal Basis

• DORA: Articles 17–23 (Chapter III)
• RTS: 2024/1772 (Classification), 2025/301 (Reporting deadlines/content)
• ITS: 2025/302 (Reporting forms/templates)
• Guideline: JC/GL/2024/34 (Cost and loss estimation)

Classification of ICT Incidents (Art. 18)

7 Classification Criteria (RTS 2024/1772)

An incident is classified as major if at least 2 of the 7 criteria exceed the defined materiality thresholds OR a single criterion reaches the high materiality threshold. The precise thresholds are defined in RTS 2024/1772 – the values above are illustrative.

Reporting Chain (Art. 19, RTS 2025/301)

3-Stage Reporting Process

Incident detected
     │
     ▼
Classification as "major"
     │
     ├── T+0h: Internal escalation
     │
     ├── T+4h ──► INITIAL NOTIFICATION
     │             BaFin Reporting Hub
     │             Minimum: Who, What, When, initial assessment
     │
     ├── T+72h ─► INTERMEDIATE REPORT
     │             Status update, impact analysis
     │             If unresolved: action plan with timeline
     │
     └── T+1M ──► FINAL REPORT
                   Root cause analysis
                   Lessons learned
                   Preventive measures

Reporting Format (ITS 2025/302)

• XML format according to ITS template (standardised, machine-readable)
• Authentication via qualified electronic certificates (eIDAS)
• Automatic acknowledgement of receipt with unique incident number
• BaFin serves as the central reporting hub in Germany

Voluntary Reporting of Cyber Threats (Art. 19(2))

• Dedicated reporting form
• Voluntary, but recommended
• Anonymised information may be shared by authorities

Implementation for ICT Service Providers

Obligations Towards Clients

As an ICT service provider, BAUER GROUP is not a direct reporting entity, but:

1. Contractual reporting obligation – Clients must report within 4h; BAUER GROUP must therefore inform them faster
2. Support obligation – Providing all relevant information for the client's report
3. Cooperation obligation – Full participation in root cause analysis

Recommended SLA Structure

Automation Potential

Legal Basis

• DORA: Articles 24–27 (Chapter IV)
• RTS: 2025/1190 (TLPT – entry into force 08.07.2025)
• Framework: TIBER-EU (Threat Intelligence-based Ethical Red Teaming)

Two Test Categories

Baseline Tests (Art. 25) – Mandatory for All

All financial entities must establish a test programme as an integral part of the ICT risk management framework:

Advanced Tests – TLPT (Art. 26–27)

Threat Led Penetration Tests are only required for systemically important financial entities with a high ICT maturity level.

Test Programme – Minimum for ICT Service Providers

Automatable Baseline Test Programme

# 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

Each test must be documented with:

• Test date, scope, methodology
• Findings (categorised by criticality)
• Remediation plan with deadlines
• Proof of remediation (retest)
• Management sign-off

→ See Audit Trail & Evidence for automated evidence collection.

Legal Basis

• DORA: Articles 28–44 (Chapter V)
• RTS: 2024/1773 (Contractual policy), 2025/532 (Subcontracting)
• ITS: 2024/2956 (Information register templates)
• Delegated acts: 2024/1502 (CTPP designation criteria), 2024/1505 (Oversight fees)
• Guideline: JC/GL/2024/36 (ESA cooperation)

Two Levels of P4

Level 1: General Principles (Art. 28–30)

Apply to all ICT third-party service provider relationships.

Level 2: EU Oversight Framework (Art. 31–44)

Applies only to CTPPs (Critical Third-Party Providers) – the 19 critical ICT third-party service providers designated by the ESAs (including AWS, Google Cloud, Microsoft Azure).

Information Register (Art. 28(3))

Every financial entity must maintain a complete register of all ICT third-party service provider contracts and update it regularly.

Mandatory Content (ITS 2024/2956)

Submission to BaFin

• First-time submission: 30.04.2025 (completed)
• Regular updates: At least annually + upon material changes
• Format: Standardised templates per ITS 2024/2956

8 Minimum Contractual Requirements (Art. 30)

Contracts with ICT third-party service providers must contain at a minimum:

Additional Requirements for Critical/Important Functions

• Disclose complete subcontracting chain
• Obtain prior approval for location changes
• Business impact analysis of outage
• Emergency and continuity planning

RTS 2025/532 – Subcontracting

Since entry into force on 22.07.2025, stricter requirements apply to sub-outsourcing:

• Due diligence before engaging subcontractors
• Risk assessment of the entire subcontracting chain
• Contractual pass-through rights to subcontractors
• Approval and change processes defined
• Termination procedures with transition arrangements

CTPPs – EU Oversight Framework (Art. 31–44)

Designation Criteria (EU 2024/1502)

The ESAs designate ICT third-party service providers as critical based on:

• Systemic importance for the financial sector
• Substitutability of services
• Number and significance of served financial entities
• Degree of dependency

Designated CTPPs (as of November 2025)

19 technology companies have been designated as CTPPs, including global cloud platforms (AWS, Google Cloud, Microsoft Azure).

CTPP Obligations

• Direct supervision by Lead Overseer (one of the ESAs)
• Joint Examination Teams (JETs) for on-site inspections
• Regular reporting obligations to the Lead Overseer
• Oversight fees per EU 2024/1505

BAUER GROUP as ICT Service Provider – Action Items

Contract Adjustment (Priority 1)

Existing and new contracts with financial entities must cover all 8 minimum contractual requirements:

## DORA-Compliant Contract Clauses (Checklist)

- [ ] Complete service description with functional mapping
- [ ] Processing locations (incl. backup, DR sites)
- [ ] SLA with measurable KPIs (availability, response time, MTTR)
- [ ] Data access and return upon contract termination (format, deadline, deletion)
- [ ] Incident cooperation clause (internal reporting deadline < 1h)
- [ ] Unrestricted audit rights (on-site + remote, including by supervisory authority)
- [ ] Extraordinary termination right for compliance violations
- [ ] Exit strategy with transition plan (min. 6 months)
- [ ] Subcontracting clause (approval requirement, transparency)
- [ ] Location changes only with prior approval

Information Provision (Priority 2)

BAUER GROUP must provide clients with all information they need for their information register:

• LEI/EUID of BAUER GROUP
• Complete service classification
• Data processing locations
• Subcontracting chain (if applicable)
• Certification evidence (ISO 27001, SOC 2, etc.)

DORA Readiness Evidence (Priority 3)

Proactive demonstration of DORA compliance to clients:

• Standardised fact sheet with all register-relevant information
• DORA compliance statement (updated annually)
• Audit report or certification
• Incident response SLA per DORA deadlines

Legal Basis

• DORA: Article 45 (Chapter VI)
• No dedicated RTS/ITS – Regulated directly in the base legal act

Requirements

Voluntary Sharing (Art. 45)

Financial entities may enter into mutual arrangements for the exchange of information and intelligence on cyber threats.

Prerequisites:

• Exchange within trusted communities of financial entities
• Preservation of confidentiality and data protection
• Notification of the competent authority about participation
• Compliance with competition rules

Content of exchange:

• Indicators of Compromise (IoCs)
• Tactics, Techniques, and Procedures (TTPs)
• Security alerts
• Configuration tools and methods

Regulatory Information Provision

Supervisory authorities provide financial entities with anonymised information on:

• Relevant cyber threats
• Vulnerability information
• Incident trends

Financial entities must establish mechanisms to:

• Receive and verify this information
• Incorporate it into their own risk analysis
• Take appropriate measures

Cross-Sector Simulation Exercises

DORA provides for coordinated exercises to strengthen sector-wide resilience.

BAUER GROUP Relevance

As an ICT service provider, P5 is low priority for BAUER GROUP, but strategically relevant:

• Participation in ISACs (Information Sharing and Analysis Centers) recommended
• Threat intelligence feeds integrated into own monitoring
• Proactively inform clients about relevant threats (value-added service)

Automation

Joint ESA Guidelines

JC/GL/2024/34 – Costs & Losses

Guideline on the standardised estimation of aggregated annual costs and losses from major ICT-related incidents. Relevant for the economic impact analysis in incident reporting (criterion 6).

JC/GL/2024/36 – Oversight Cooperation

Guideline on cooperation and information sharing between the ESAs and national supervisory authorities within the framework of CTPP oversight.

Other Documents

Overview: 27 Legal Texts in the DORA Ecosystem

The DORA framework consists of the base legal act (Level 1), 12 delegated acts/technical standards (Level 2), and guidelines (Level 3).

Level 1 – Base Legal Acts

Level 2 – Package 1 (published 25.06.2024)

Level 2 – Package 2 (published H2/2024 – H1/2025)

Level 2 – Oversight Framework

Level 3 – Guidelines (Joint Guidelines)

Other Documents

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. Reg. 2024/1502 + Del. Reg. 2024/1505
                   + RTS 2025/295 + RTS 2025/420
P5 (Art. 45)    → No dedicated RTS/ITS

Official Sources

Content

Standard templates for the information register of ICT third-party service provider contracts:

Identifier: LEI or EUID (per EU Commission decision) First submission to BaFin: 30.04.2025

→ Details: Information Register | Register Automation

Content

Standard forms, templates, and procedures for:

• Reporting major ICT-related incidents
• Notification of significant cyber threats

Format: XML (standardised, machine-readable) Authentication: Qualified electronic certificates (eIDAS) Acknowledgement of receipt: Automatic with unique incident number

→ XML template: Incident Pipeline

Content

Specifies the 7 classification criteria for ICT-related incidents and cyber threats:

1. Affected clients/financial counterparties
2. Reputational impact
3. Downtime of critical services
4. Geographic spread
5. Data loss (CIA triad)
6. Criticality of affected services
7. Economic impact

Defines materiality thresholds and provides practical examples for applying the criteria.

→ Details: P2: Incident Reporting

Content

Details the minimum contractual requirements for ICT service provider contracts:

• 8 mandatory clauses (Art. 30(2))
• Additional requirements for critical/important functions (Art. 30(3))
• Audit rights and inspection powers
• Exit strategies and data migration
• SLA requirements with KPI definitions
• Negotiation strategies

→ Details: P4: Third-Party Risk | Contract Management

Content

The RTS specifies the complete ICT risk management framework including:

• Governance – Roles, responsibilities, reporting lines
• ICT asset inventory – Identification, classification, documentation
• Risk assessment – Methodology, thresholds, updates
• Security controls – Access control, cryptography, network security
• BCP/DRP – Business continuity, disaster recovery, RPO/RTO
• Simplified framework – For microenterprises under Art. 16

Policies (Minimum Content)

The RTS defines minimum content for the following policies:

1. ICT security policy
2. Access control policy (incl. MFA, PAM)
3. Cryptography policy
4. ICT project management policy (SDLC security)
5. ICT procurement policy
6. Physical security policy
7. Capacity management policy
8. ICT change management policy

BAUER GROUP Relevance

As an ICT service provider, BAUER GROUP must be able to demonstrate that its own internal processes comply with these standards – particularly in response to audit requests from financial sector clients.

→ Implementation details: P1: ICT Risk Management

Content

Harmonisation of oversight activities over CTPPs:

• Information obligations for voluntary CTPP applications
• Information provision to the Lead Overseer
• Template for subcontracting notifications to the Lead Overseer
• Assessment of measures taken by CTPPs

Not directly relevant for BAUER GROUP (no CTPP designation), but relevant for understanding the supervisory landscape.

Content

Defines the content and deadlines of the 3-stage reporting chain:

As well as voluntary reporting of significant cyber threats.

Missing a deadline = DORA violation → sanctions per Art. 50–52 DORA in conjunction with national implementation (FinmadiG).

→ Details: P2: Incident Reporting | Incident Pipeline

Content

Specifies the composition, tasks, and working arrangements of Joint Examination Teams (JETs):

• Balanced participation of ESA and national supervisory authority staff
• Designation procedures
• Task allocation
• Working modalities

Not directly relevant for BAUER GROUP (concerns CTPP oversight only).

Background

The original draft was rejected by the EU Commission on 21.01.2025, as Art. 5 (monitoring of the subcontracting chain) exceeded the mandate under Art. 30(5) DORA. After removal of Art. 5 and the related recital, adoption took place on 24.03.2025.

Content

Specifies the requirements for financial entities when sub-outsourcing ICT services:

• Due diligence before engaging subcontractors
• Risk assessment of the subcontracting chain
• Contractual conditions for sub-outsourcing
• Approval and change processes
• Termination procedures with transition arrangements

Affected Entities (Art. 2 DORA)

DORA applies to virtually all supervised financial entities in the European financial sector:

Exemptions (Art. 2(3) & (4) DORA)

Exempt are, among others:

• Managers of alternative investment funds under Art. 3(2) AIFMD
• Insurance and reinsurance undertakings under Art. 4 of the Solvency II Directive (size-based exemption)
• Certain insurance intermediaries (microenterprises, small and medium-sized)
• Post-trade infrastructures from third countries (subject to conditions)

Entity Categorisation (Proportionality Principle)

FinmadiG Extension (from 01.01.2027)

The Finanzmarktdigitalisierungsgesetz (Financial Markets Digitalisation Act) extends the DORA scope of application in Germany to:

• Financial services institutions (leasing, factoring)
• Crypto securities register operators
• Branches under Section 53 KWG (German Banking Act)
• Insurance holding companies (Section 7 No. 31, Section 294(4) VAG)
• All KWG institutions not already covered under Art. 2 DORA

Transitional provision: Reporting obligations (Chapter III) have been applicable since 17.01.2025; full ICT risk management framework from 01.01.2027. BAIT applies transitionally until 31.12.2026.

Chronological Overview

Level 1 – Regulation

Level 2 – RTS/ITS (Chronological)

Key Deadlines

Level 3 – Guidelines

BaFin-Specific Dates

BaFin offers annual workshops to prepare for the information register submission. The next submission period for 2026 is expected to take place in Q2 2026.

Chapter I – General Provisions (Art. 1–4)

Chapter II – ICT Risk Management (Art. 5–16)

Chapter III – Incident Management (Art. 17–23)

Chapter IV – Resilience Testing (Art. 24–27)

Chapter V – Third-Party Risk (Art. 28–44)

Chapter VI – Information Sharing (Art. 45)

Chapters VII–IX (Art. 46–64)

Authorities, transitional and final provisions.

European Level

National Level (Germany)

CTPP Oversight

19 CTPPs were designated in November 2025 (including AWS, Google Cloud, Microsoft Azure). Each CTPP is assigned a Lead Overseer from the ESAs who exercises direct supervision.

New Requirements Without BAIT Equivalent

Primary Legal Acts

National Implementation (Germany)

BaFin Publications

Superseded Regulatory Frameworks

Further Links

Complete RTS/ITS directory → RTS & ITS Overview

Available Templates

All templates are available as code/Markdown in the repository and can be directly adopted into your own infrastructure.