sota.io
2026-04-16·15 min read·

DORA Art.11: ICT Business Continuity for Financial Services — BCP Policy, RTO/RPO Architecture, and Backup Strategy Developer Guide (2026)

The Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554) has applied in full since 17 January 2025. Article 11 is one of the most technically demanding provisions: it requires every in-scope financial entity to maintain, test, and activate an ICT Business Continuity Policy (BCP) — and to do so with documented, auditable evidence.

Unlike the NIS2 business continuity obligation (Art.21(2)(c)), which is written at a principles level, DORA Art.11 operates in a sector where regulators already have decades of operational resilience expectations. The ESA Joint Guidelines (JC 2023/83) published alongside DORA translate "ICT business continuity" into specific, quantified requirements: recovery time objectives in hours or minutes, backup schedules measured in hours, and annual testing cycles with documented findings.

This guide covers the Art.11 legal framework, critical business function identification, RTO/RPO calibration, backup architecture, DR plan requirements, testing obligations, and the DORA × NIS2 dual-compliance overlap — with a Python implementation and a 25-item audit checklist.

Who Must Comply with DORA Art.11?

DORA applies to a wide range of financial entities defined in Art.2. For Art.11 specifically, the obligation is graded by entity type under Art.11(11): proportionate for small and non-interconnected investment firms, payment institutions, e-money institutions, and small credit institutions; full for:

Software developers and SaaS providers are not directly in scope as financial entities — but if you provide ICT services to one of the above categories, your service level agreements, uptime guarantees, RTO/RPO commitments, and backup architecture are now subject to contractual audit rights under DORA Art.30. Your customer's compliance depends on your ability to demonstrate Art.11-aligned capabilities.

DORA Art.11 — The BCP Policy Framework

Art.11(1) requires financial entities to have "a comprehensive ICT business continuity policy as part of their ICT business continuity management system." The ESA Joint Guidelines (JC 2023/83, Art.68-79) specify what "comprehensive" means in practice.

The Seven Mandatory BCP Elements (Art.11(1)(a)-(g))

Art.11(1)(a): Critical or important functions (COFs) The BCP must identify all functions that, if disrupted, would cause material harm to the financial entity or its counterparties. This maps directly to the critical business function (CBF) methodology — see the next section.

Art.11(1)(b): Minimum service levels For each critical function, the BCP must state the minimum acceptable service level during disruption. This is not aspirational; it defines the threshold below which regulatory notification is triggered (DORA Art.19 major ICT incident reporting).

Art.11(1)(c): Recovery time objectives (RTOs) DORA does not prescribe a universal RTO. The ESA Guidelines require RTOs to be set based on impact analysis — and specifically require them to be achievable and tested. For Tier 1 systemically important functions (e.g., real-time payment processing), ESAs have informally referenced RTOs of 4 hours or less. For less critical functions, 24-72 hours may be proportionate.

Art.11(1)(d): Recovery point objectives (RPOs) RPOs define the maximum acceptable data loss measured in time. An RPO of 1 hour means you can tolerate losing up to 1 hour of transactions in the worst case. For payment systems, ESAs have referenced RPOs of 2-4 hours as a ceiling for critical functions — meaning synchronous or near-synchronous replication is often required.

Art.11(1)(e): Backup and restoration procedures The BCP must describe the backup strategy (type, frequency, location) and the tested restoration procedure. Backup schedules must be aligned to RPOs: if your RPO is 4 hours, your backup frequency must be at most 4 hours.

Art.11(1)(f): ICT disaster recovery plan (DR Plan) The DR Plan is a sub-document of the BCP covering the technical steps to restore ICT systems. Art.11(3) requires the DR Plan to be maintained and tested separately from the broader BCP.

Art.11(1)(g): Crisis communication plan The BCP must include a communication plan for major incidents: who notifies whom (internally and externally), escalation timelines, media communication protocols, and regulatory notification triggers (Art.19 timeline: 4h initial report, 72h intermediate, 1 month final).

Critical Business Function (CBF) Identification

The foundation of an Art.11-compliant BCP is an accurate CBF inventory. DORA does not define a universal methodology but the ESA Guidelines reference the impact tolerance approach used by the Bank of England's Operational Resilience framework — adapted for DORA's scope.

Step 1: Map Business Services to ICT Systems

Create a three-layer mapping:

  1. Business service (e.g., "Process SEPA Credit Transfers")
  2. ICT system supporting it (e.g., core banking system, payment gateway, message broker)
  3. ICT components (e.g., database server, application server, network link, HSM)

Step 2: Apply DORA Art.11 Materiality Criteria

A function is critical or important if disruption would:

Regulated activities (under MiFID II, PSD2, CRD) are automatically candidates for critical status.

Step 3: Set Impact Tolerances

For each CBF, document the maximum tolerable period of disruption (MTPD) — the point beyond which recovery is no longer feasible without permanent harm. The RTO must always be less than the MTPD.

CBF TypeIndicative MTPDIndicative RTO
Real-time payment processing2 hours1 hour
T+1 settlement functions8 hours4 hours
End-of-day batch processing24 hours12 hours
Reporting/regulatory submissions72 hours48 hours
Non-critical back-office5 business days3 business days

These are indicative. Supervisory expectations vary by entity size, interconnectedness, and supervisory authority (ECB SSM, national NCAs, ESMA, EIOPA).

RTO/RPO Architecture: What Does Compliance Actually Require?

The gap between a paper RTO and an achieved RTO is where most DORA Art.11 findings originate. NCAs expect to see:

  1. Documented RTO/RPO per CBF in the BCP
  2. Technical architecture that is capable of achieving those objectives
  3. Test evidence demonstrating actual achievement (not theoretical)

Achieving RTOs of 1-4 Hours: Technical Patterns

Hot Standby (Active-Active)

Warm Standby (Active-Passive with automated failover)

Cold Standby (Backup-based restore)

RPO and Backup Frequency

The backup frequency must be at most equal to the RPO:

RPORequired backup frequencyBackup type
≤ 15 minContinuous replicationStreaming replication / CDC
≤ 1 hourHourly snapshotsVolume snapshots / WAL archiving
≤ 4 hours4-hourly snapshotsScheduled snapshots
≤ 24 hoursDaily backupFull or incremental daily

For PostgreSQL-backed financial applications, WAL archiving to an object store (S3-compatible) satisfies continuous RPO requirements when combined with archive_command and restore_command configuration.

Three-Tier Backup Architecture (ESA Guidelines Alignment)

The ESA Joint Guidelines (JC 2023/83, Art.71) reference a multi-tier backup strategy that has become the de facto DORA audit expectation. The three tiers correspond to recovery speed and geographic separation:

Tier 1 — Operational Backup (Same-region, near-real-time)

Tier 2 — Regional Disaster Recovery (Cross-region, same country or EU)

Tier 3 — Long-Term Archive (Offline/Air-gapped, multi-year)

The DORA requirement is that this architecture is documented in the BCP, tested, and auditable. NCAs have focused on two specific failures in early DORA reviews: (1) Tier 3 backups that have never been test-restored, and (2) Tier 2 backups hosted in the same cloud account as the primary, negating their disaster recovery value.

ICT Disaster Recovery Plan (Art.11(3))

The DR Plan is a technical execution document distinct from the BCP strategic framework. DORA Art.11(3) requires it to be periodically tested and updated. The ESA Guidelines specify minimum DR Plan content:

Mandatory DR Plan Sections

1. Activation Criteria Define the specific technical and business conditions that trigger DR plan activation: which CBFs have failed, how long they have been unavailable, and who has authority to declare a disaster and activate recovery.

2. Roles and Responsibilities (RACI)

3. Technical Recovery Procedures (Step-by-step) For each CBF, document:

4. Communication Templates Pre-drafted messages for: client communication, NCA 4-hour initial notification, internal escalation. Pre-drafted templates reduce time-to-communicate during high-stress incident response.

5. Return-to-Normal Procedures DORA Art.11 is explicit that the DR Plan must cover return to normal operations — not just failover. Failback procedures are tested separately from failover and are often where recovery plans fail their first live test.

Testing Requirements (Art.11(6))

DORA Art.11(6) requires financial entities to "test the ICT business continuity plans at least once a year." The ESA Guidelines specify graduated testing requirements:

Minimum Annual Test Requirements

Test typeFrequencyScope
Tabletop exercise (walkthrough)Annual minimumFull BCP/DR Plan
Technical failover testAnnual minimumAll Tier 1 CBFs
Data restoration testAnnual minimumAll backup tiers
Crisis communication exerciseAnnual minimumAll communication plans

Additional Testing for Systemically Important Entities

Entities classified as systemically important by their NCA may face enhanced testing expectations:

Test Evidence Requirements

Every test must produce documented evidence:

  1. Test plan (objectives, scope, success criteria)
  2. Test execution log (timestamped, participant-signed)
  3. Actual vs. target RTO/RPO measurement
  4. Findings and deficiencies identified
  5. Remediation plan for identified gaps
  6. Management sign-off

NCAs have requested this documentation in early DORA supervisory reviews. Verbal confirmation of testing is not sufficient.

DORA × NIS2 Art.21(2)(c) Dual Compliance

Financial entities that are also NIS2 essential entities (banks with >€10M turnover and >50 employees are automatically essential under NIS2 Annex I) face dual obligations:

DimensionDORA Art.11NIS2 Art.21(2)(c)
Legal basisRegulation (EU) 2022/2554Directive (EU) 2022/2555
AuthorityLead NCA (ECB/national)National competent authority
ScopeICT systems supporting financial servicesNetwork and information systems
BCP requirementICT business continuity policy (specific)Business continuity (principles-based)
TestingAnnual minimum (Art.11(6))"Regular" (not time-specified)
BackupDocumented (Art.11(1)(e))Backup management (Art.21(2)(c))
Incident notification4h initial / 72h / 1 month (Art.19)24h / 72h (Art.23)
Lex specialisDORA is lex specialisNIS2 is lex generalis

The lex specialis principle means DORA compliance satisfies the NIS2 Art.21 requirement for ICT business continuity — if the DORA BCP covers the NIS2-relevant network and information systems. For financial entities, this is almost always the case. Document the mapping explicitly in your compliance register to avoid duplicate supervisory review.

Exception: The NIS2 competent authority (often different from the DORA NCA) may request separate NIS2 documentation. Maintain a mapping document showing: "DORA Art.11 BCP § [X] satisfies NIS2 Art.21(2)(c) requirement [Y]."

Python DORABusinessContinuityChecker

from dataclasses import dataclass, field
from enum import Enum
from typing import Optional
import datetime


class CriticalityTier(Enum):
    TIER1_CRITICAL = "tier1_critical"      # RTO ≤ 4h, RPO ≤ 2h
    TIER2_IMPORTANT = "tier2_important"    # RTO ≤ 24h, RPO ≤ 8h
    TIER3_STANDARD = "tier3_standard"      # RTO ≤ 72h, RPO ≤ 24h


class BackupTier(Enum):
    TIER1_OPERATIONAL = "tier1_operational"
    TIER2_REGIONAL_DR = "tier2_regional_dr"
    TIER3_ARCHIVE = "tier3_archive"


@dataclass
class CriticalBusinessFunction:
    name: str
    criticality: CriticalityTier
    target_rto_hours: float
    target_rpo_hours: float
    mtpd_hours: float
    backup_frequency_hours: float
    last_failover_test: Optional[datetime.date] = None
    last_restore_test: Optional[datetime.date] = None
    failover_achieved_rto_hours: Optional[float] = None
    failover_achieved_rpo_hours: Optional[float] = None


@dataclass
class BackupConfiguration:
    tier: BackupTier
    location: str
    frequency_hours: float
    retention_days: int
    is_immutable: bool
    is_geographically_separate: bool
    last_restore_test: Optional[datetime.date] = None
    restore_test_succeeded: bool = False


@dataclass
class BCPDocument:
    version: str
    last_reviewed: datetime.date
    next_review_due: datetime.date
    cbfs: list[CriticalBusinessFunction] = field(default_factory=list)
    backup_configs: list[BackupConfiguration] = field(default_factory=list)
    has_dr_plan: bool = False
    has_crisis_comms_plan: bool = False
    last_tabletop_exercise: Optional[datetime.date] = None
    last_full_failover_test: Optional[datetime.date] = None
    last_annual_test: Optional[datetime.date] = None


class DORABusinessContinuityChecker:
    """DORA Art.11 compliance checker for ICT Business Continuity."""

    ANNUAL_TEST_THRESHOLD_DAYS = 365
    REVIEW_CYCLE_DAYS = 365

    def check(self, bcp: BCPDocument) -> dict:
        findings = []
        score = 100

        findings.extend(self._check_bcp_completeness(bcp, score))
        findings.extend(self._check_cbf_rto_rpo(bcp))
        findings.extend(self._check_backup_architecture(bcp))
        findings.extend(self._check_testing(bcp))

        critical = [f for f in findings if f["severity"] == "critical"]
        high = [f for f in findings if f["severity"] == "high"]
        medium = [f for f in findings if f["severity"] == "medium"]

        score = max(0, 100 - len(critical) * 25 - len(high) * 10 - len(medium) * 5)

        return {
            "score": score,
            "compliant": score >= 80 and len(critical) == 0,
            "findings": findings,
            "summary": {
                "critical": len(critical),
                "high": len(high),
                "medium": len(medium),
                "cbf_count": len(bcp.cbfs),
                "backup_tiers": len(bcp.backup_configs),
            }
        }

    def _check_bcp_completeness(self, bcp: BCPDocument, score: int) -> list:
        findings = []
        today = datetime.date.today()

        if not bcp.has_dr_plan:
            findings.append({
                "finding": "No separate ICT Disaster Recovery Plan (DORA Art.11(3))",
                "severity": "critical",
                "article": "Art.11(3)"
            })

        if not bcp.has_crisis_comms_plan:
            findings.append({
                "finding": "Crisis communication plan missing from BCP (DORA Art.11(1)(g))",
                "severity": "high",
                "article": "Art.11(1)(g)"
            })

        if bcp.next_review_due < today:
            findings.append({
                "finding": f"BCP review overdue since {bcp.next_review_due} (DORA Art.11(5))",
                "severity": "high",
                "article": "Art.11(5)"
            })

        return findings

    def _check_cbf_rto_rpo(self, bcp: BCPDocument) -> list:
        findings = []
        today = datetime.date.today()

        tier_rto_limits = {
            CriticalityTier.TIER1_CRITICAL: 4.0,
            CriticalityTier.TIER2_IMPORTANT: 24.0,
            CriticalityTier.TIER3_STANDARD: 72.0,
        }
        tier_rpo_limits = {
            CriticalityTier.TIER1_CRITICAL: 2.0,
            CriticalityTier.TIER2_IMPORTANT: 8.0,
            CriticalityTier.TIER3_STANDARD: 24.0,
        }

        for cbf in bcp.cbfs:
            max_rto = tier_rto_limits[cbf.criticality]
            max_rpo = tier_rpo_limits[cbf.criticality]

            if cbf.target_rto_hours > max_rto:
                findings.append({
                    "finding": f"CBF '{cbf.name}': RTO {cbf.target_rto_hours}h exceeds {cbf.criticality.value} limit ({max_rto}h)",
                    "severity": "high",
                    "article": "Art.11(1)(c)"
                })

            if cbf.target_rpo_hours > max_rpo:
                findings.append({
                    "finding": f"CBF '{cbf.name}': RPO {cbf.target_rpo_hours}h exceeds {cbf.criticality.value} limit ({max_rpo}h)",
                    "severity": "high",
                    "article": "Art.11(1)(d)"
                })

            if cbf.target_rto_hours >= cbf.mtpd_hours:
                findings.append({
                    "finding": f"CBF '{cbf.name}': RTO ({cbf.target_rto_hours}h) must be less than MTPD ({cbf.mtpd_hours}h)",
                    "severity": "critical",
                    "article": "Art.11(1)(c)"
                })

            if cbf.backup_frequency_hours > cbf.target_rpo_hours:
                findings.append({
                    "finding": f"CBF '{cbf.name}': Backup frequency ({cbf.backup_frequency_hours}h) exceeds RPO ({cbf.target_rpo_hours}h)",
                    "severity": "critical",
                    "article": "Art.11(1)(e)"
                })

            if cbf.failover_achieved_rto_hours and cbf.failover_achieved_rto_hours > cbf.target_rto_hours:
                findings.append({
                    "finding": f"CBF '{cbf.name}': Last test achieved RTO {cbf.failover_achieved_rto_hours}h > target {cbf.target_rto_hours}h",
                    "severity": "critical",
                    "article": "Art.11(6)"
                })

            if cbf.last_failover_test:
                days_since = (today - cbf.last_failover_test).days
                if days_since > self.ANNUAL_TEST_THRESHOLD_DAYS:
                    findings.append({
                        "finding": f"CBF '{cbf.name}': Failover test overdue ({days_since} days since last test)",
                        "severity": "critical",
                        "article": "Art.11(6)"
                    })
            else:
                findings.append({
                    "finding": f"CBF '{cbf.name}': No failover test on record (DORA Art.11(6) requires annual testing)",
                    "severity": "critical",
                    "article": "Art.11(6)"
                })

        return findings

    def _check_backup_architecture(self, bcp: BCPDocument) -> list:
        findings = []
        tiers_present = {bc.tier for bc in bcp.backup_configs}
        today = datetime.date.today()

        if BackupTier.TIER1_OPERATIONAL not in tiers_present:
            findings.append({
                "finding": "No Tier 1 (operational) backup configuration documented",
                "severity": "critical",
                "article": "Art.11(1)(e)"
            })

        if BackupTier.TIER2_REGIONAL_DR not in tiers_present:
            findings.append({
                "finding": "No Tier 2 (regional DR) backup configuration — required for geographic resilience",
                "severity": "high",
                "article": "Art.11(1)(e)"
            })

        if BackupTier.TIER3_ARCHIVE not in tiers_present:
            findings.append({
                "finding": "No Tier 3 (long-term archive) backup — required for regulatory retention obligations",
                "severity": "medium",
                "article": "Art.11(1)(e)"
            })

        for bc in bcp.backup_configs:
            if not bc.is_immutable and bc.tier == BackupTier.TIER1_OPERATIONAL:
                findings.append({
                    "finding": f"Tier 1 backup at {bc.location} is not immutable — vulnerable to ransomware encryption",
                    "severity": "high",
                    "article": "Art.11(1)(e)"
                })

            if bc.tier == BackupTier.TIER2_REGIONAL_DR and not bc.is_geographically_separate:
                findings.append({
                    "finding": f"Tier 2 DR backup at {bc.location} is not geographically separate from primary",
                    "severity": "critical",
                    "article": "Art.11(1)(e)"
                })

            if not bc.last_restore_test or not bc.restore_test_succeeded:
                findings.append({
                    "finding": f"Backup tier {bc.tier.value} at {bc.location}: restore test missing or failed",
                    "severity": "high",
                    "article": "Art.11(6)"
                })

        return findings

    def _check_testing(self, bcp: BCPDocument) -> list:
        findings = []
        today = datetime.date.today()

        if not bcp.last_annual_test:
            findings.append({
                "finding": "No annual BCP/DR test on record (DORA Art.11(6) requires at least annual testing)",
                "severity": "critical",
                "article": "Art.11(6)"
            })
        else:
            days_since = (today - bcp.last_annual_test).days
            if days_since > self.ANNUAL_TEST_THRESHOLD_DAYS:
                findings.append({
                    "finding": f"Annual BCP test overdue: last test {days_since} days ago",
                    "severity": "critical",
                    "article": "Art.11(6)"
                })

        if not bcp.last_tabletop_exercise:
            findings.append({
                "finding": "No tabletop exercise on record — document walkthrough exercises",
                "severity": "medium",
                "article": "Art.11(6)"
            })

        return findings


# Example usage
if __name__ == "__main__":
    bcp = BCPDocument(
        version="2.1",
        last_reviewed=datetime.date(2025, 12, 1),
        next_review_due=datetime.date(2026, 12, 1),
        has_dr_plan=True,
        has_crisis_comms_plan=True,
        last_annual_test=datetime.date(2025, 11, 15),
        last_tabletop_exercise=datetime.date(2026, 1, 20),
        cbfs=[
            CriticalBusinessFunction(
                name="SEPA Credit Transfer Processing",
                criticality=CriticalityTier.TIER1_CRITICAL,
                target_rto_hours=2.0,
                target_rpo_hours=0.25,
                mtpd_hours=4.0,
                backup_frequency_hours=0.25,
                last_failover_test=datetime.date(2025, 11, 15),
                failover_achieved_rto_hours=1.8,
                failover_achieved_rpo_hours=0.2,
            ),
            CriticalBusinessFunction(
                name="Client Reporting Portal",
                criticality=CriticalityTier.TIER2_IMPORTANT,
                target_rto_hours=8.0,
                target_rpo_hours=4.0,
                mtpd_hours=24.0,
                backup_frequency_hours=4.0,
                last_failover_test=datetime.date(2025, 11, 15),
                failover_achieved_rto_hours=6.0,
                failover_achieved_rpo_hours=3.5,
            ),
        ],
        backup_configs=[
            BackupConfiguration(
                tier=BackupTier.TIER1_OPERATIONAL,
                location="eu-west-1-az-a",
                frequency_hours=0.25,
                retention_days=30,
                is_immutable=True,
                is_geographically_separate=False,
                last_restore_test=datetime.date(2026, 1, 10),
                restore_test_succeeded=True,
            ),
            BackupConfiguration(
                tier=BackupTier.TIER2_REGIONAL_DR,
                location="eu-central-1",
                frequency_hours=1.0,
                retention_days=90,
                is_immutable=True,
                is_geographically_separate=True,
                last_restore_test=datetime.date(2025, 11, 15),
                restore_test_succeeded=True,
            ),
            BackupConfiguration(
                tier=BackupTier.TIER3_ARCHIVE,
                location="offline-vault-frankfurt",
                frequency_hours=24.0,
                retention_days=2555,
                is_immutable=True,
                is_geographically_separate=True,
                last_restore_test=datetime.date(2025, 10, 1),
                restore_test_succeeded=True,
            ),
        ],
    )

    checker = DORABusinessContinuityChecker()
    result = checker.check(bcp)
    print(f"DORA Art.11 Score: {result['score']}/100")
    print(f"Compliant: {result['compliant']}")
    print(f"Findings: {result['summary']}")
    for f in result["findings"]:
        print(f"  [{f['severity'].upper()}] {f['article']}: {f['finding']}")

Common NCA Audit Failures (DORA Art.11)

Failure 1: RTO commitments not backed by architecture Financial entities commit to a 2-hour RTO in their BCP but have no hot standby or automated failover mechanism. NCAs calculate actual RTO from the DR Plan steps: if manual steps alone take 3 hours, the 2-hour RTO is not credible.

Failure 2: Tier 2 DR backup in the same cloud account as primary If ransomware encrypts the primary environment and has API access to the backup account, Tier 2 backups are worthless. Cross-account isolation (separate AWS accounts, separate GCP projects) is the minimum; separate cloud providers for Tier 2 is recommended.

Failure 3: Annual test conducted only as a tabletop exercise DORA Art.11(6) requires testing of the ICT business continuity plans — which NCAs interpret as requiring actual technical failover, not only discussion. A tabletop exercise counts as partial evidence but cannot substitute for a live failover test.

Failure 4: Backup tested but never restored end-to-end Restoring a database backup file is not the same as restoring a functioning application. The test must cover: backup retrieval, database restoration, application configuration update, connectivity verification, and a data integrity check. Many entities test the backup step but not the restoration-to-function step.

Failure 5: RTO measured from "disaster declared" not from "incident onset" Some entities measure RTO from the point at which the disaster is formally declared — which may be hours after the actual failure. NCAs measure RTO from incident detection. Build detection time into your RTO calculation.

Failure 6: No documented return-to-normal procedure Failing over to DR is only half the exercise. NCAs expect to see a tested failback procedure — returning operations to the primary environment after it is restored. Missing failback documentation is a medium finding but accumulates with other gaps.

25-Item DORA Art.11 Compliance Checklist

BCP Policy (Art.11(1))

ICT DR Plan (Art.11(3))

Backup Architecture (Art.11(1)(e))

Testing (Art.11(6))

See Also