IM Engineer Study Notes
← Back to list
Security & Privacy
#DORA#디지털 운영 복원력#ICT 위험관리#금융 보안#제3자 위험#CTPP#Regulation (EU) 2022/2554
Last updated · 2026-09-29

Managing Financial Digital Operational Resilience under EU DORA

1. Overview

A. Definition and background

The Digital Operational Resilience Act (DORA) is the European Union regulation for the financial sector, Regulation (EU) 2022/2554, requiring financial entities to manage ICT risk holistically, sustain and recover services through disruptions and cyberattacks, and control dependencies on ICT third parties.

Financial services are interconnected: payments, trading, credit, insurance claims, and market infrastructures can propagate one provider's ICT failure to many institutions and customers. Growing dependence on cloud, data-center, and critical software providers means that an individual firm's security controls alone cannot adequately address ecosystem-wide concentration risk and cascading outages. DORA therefore expands security incident response into lifecycle management of digital operational resilience.

DORA was adopted in 2022 as Regulation (EU) 2022/2554 and has applied since 17 January 2025. It brings together ICT risk management, reporting of major ICT-related incidents, digital operational resilience testing, ICT third-party risk management, and information sharing. A professional engineer should interpret it not as a legal checklist alone, but as an operating architecture linking business services, assets, suppliers, recovery objectives, and evidence.

B. Objectives and applicability

Resilience under DORA does not mean that disruptions never occur. It means being able to detect, respond, and recover when prevention fails, limit customer impact to an acceptable level, and improve controls through lessons learned. Information security, business continuity, IT service management, procurement, and outsourcing governance must therefore align around the same critical business services.

The scope covers a broad range of financial entities, including banks, payment and e-money institutions, investment firms, insurers, and market infrastructures; entity types and exemptions must be assessed against Article 2 of the Regulation. An ICT provider is not automatically subject to the same direct obligations merely because it serves a financial institution. Financial entities must manage provider risk, while critical ICT third-party providers (CTPPs) separately designated by the European Supervisory Authorities (ESAs) fall within an EU-level oversight framework.

Organizations outside Europe may still be affected by contracts, risk-management requests, audit evidence, incident notifications, or recovery obligations when serving EU financial entities or their ICT supply chains. Korean companies should prepare for customer requirements on security, incident notice, and evidence of recovery irrespective of whether they are directly in scope. The legal position of a non-EU provider and its detailed obligations depend on the contractual parties and applicable conditions; verify them with legal counsel and competent-supervisor guidance.

2. DORA reference architecture and resilience management

DORA implementation should begin with a dependency map from important business services to technology assets and suppliers, rather than simply allocating clauses to departments. Business impact analysis establishes tolerable interruption, data-loss limits, customer and market impact, and recovery priorities. Connecting these criteria to ICT inventories, risk scenarios, controls, testing, incident reporting, and recovery plans makes it possible to explain which business outcome each control protects.

flowchart TB
  A["Critical business services and impact analysis"] --> B["ICT assets, data, and supplier dependencies"]
  B --> C["ICT risk management framework"]
  C --> D["Protection, detection, response, and recovery controls"]
  D --> E["Incident classification, reporting, and communication"]
  D --> F["Resilience testing and improvement"]
  B --> G["Third-party risk, contracts, and subcontractor management"]
  E --> H["Management review and remediation"]
  F --> H
  G --> H
  H --> C

A. ICT risk management and governance

Financial entities must treat ICT risk as part of enterprise risk management and establish clear accountability, policies, roles, and reporting lines. Board and senior-management accountability is not eliminated by delegating work to technology teams; management approves resilience objectives for important services and oversees implementation. In practice, service owners, security, ICT operations, risk, business continuity, procurement, and internal audit need shared terminology and evidence.

The risk-management framework repeatedly identifies business functions and supporting information and ICT assets, assesses threats, vulnerabilities, and impact, and selects protection, detection, response, and recovery controls. An asset inventory must cover more than servers and networks: data flows, identities, software components, cloud regions, outsourced operations, and backup-recovery paths also matter. Review dependency maps and risk assessments after material configuration changes, mergers, acquisitions, or provider substitutions.

Controls must address recoverability and decision speed as well as confidentiality, integrity, and availability. Multi-region deployment can help with a regional outage, but it is not an independent recovery path if the same credentials, control plane, or data corruption affect both regions. For each risk scenario, verify the linkage among prevention, detection signals, isolation, alternative operation, and recovery validation.

B. Incident management and reporting

Incident response starts by combining technical alerts with business impact. The same server error has different severity, reporting paths, and customer effects when it causes a brief delay in an internal development environment versus a prolonged interruption to payments or trading. The entity should define classification criteria and owners and escalate incidents quickly when they cross established thresholds.

DORA standardizes the handling and reporting of major ICT-related incidents and significant cyber threats. Classification should reflect affected customers, transactions and services, duration, geographic spread, data integrity, and economic impact in line with the Regulation and technical standards. Record facts and timelines for initial, intermediate, and final reports, including root cause, actions, and recovery status; do not present uncertain early information as established fact.

Response involves security monitoring, service management, business owners, legal and compliance, privacy, providers, and supervisory contacts. Provider contracts should establish incident-notification timelines, preservation of logs and evidence, investigation cooperation, downstream-provider notification, and recovery assistance. After closure, assign owners and deadlines for root-cause actions and apply lessons to similar services and suppliers.

C. Digital operational resilience testing

Testing validates whether controls work under real business conditions, not whether a policy exists. Intensity should be proportionate to service criticality and risk, ranging from basic checks and vulnerability assessments to scenario-based testing, recovery exercises, and independent review. The test environment should reflect key production dependencies, permissions, and data paths without carelessly damaging live services.

The scope may include ICT systems and applications, infrastructure, data centers, networks, personnel, and third-party services supporting critical assets. A recovery exercise should go beyond confirming that a backup was created: it should test restoration in a clean environment, data consistency, and whether business owners can approve a real failover. Record findings with severity, business impact, remediation owner, and retest criteria.

Threat-led penetration testing (TLPT) simulates advanced attacks against critical functions using current threat intelligence. It is distinct from routine vulnerability scans and is not a universal test that every financial entity must perform on the same cycle; designated entities conduct it under competent-authority oversight. Scope, risk controls, tester independence, provider participation, and sharing of results must follow applicable rules, technical standards, and supervisory guidance.

D. ICT third-party risk and CTPP oversight

Outsourcing transfers neither risk ownership nor accountability; it expands the entity's exposure. Financial entities manage the full service lifecycle: due diligence, criticality and concentration assessment, contracting, continuous monitoring, exit, and transition. For services supporting critical or important functions, assess provider substitutability, data portability, subcontracting, jurisdiction, audit rights, and recovery dependencies in advance.

Entities maintain a register of information on ICT third-party contractual arrangements and trace service, provider, and subcontractor relationships at entity and group levels. The register is not merely a procurement list; it is a data foundation for concentration-risk analysis, critical-function dependencies, substitutability, and supervisory reporting. Consistent service identifiers and provider master data prevent fragmented records from delaying reporting and impact analysis.

Designation and oversight of CTPPs is an EU-level supervisory function, distinct from each financial entity's own provider-risk management. The ESAs assess sector-wide importance and interconnectedness under the Regulation and designation criteria, and a Lead Overseer coordinates oversight of designated providers. This does not transfer an entity's provider-management responsibilities to supervisors: each entity remains accountable for its own risk assessment, contracts, controls, and recovery.

3. Implementation architecture and operating procedures

An actionable implementation model designs governance and technical data flows together. If the service catalog, CMDB, data lineage, contract repository, risk system, ITSM, SIEM, and recovery platform use unrelated identifiers, it is difficult to connect an incident or test result to a critical business service. Common service, provider, and asset IDs and owner data are prerequisites for automation.

sequenceDiagram
  participant BUS as Business service owner
  participant GRC as Risk and regulatory management
  participant IT as ICT operations and security
  participant V as Provider management
  participant TEST as Testing and recovery
  BUS->>GRC: Register critical services and impact tolerances
  GRC->>IT: Assign controls and risk scenarios
  GRC->>V: Request provider, contract, and register data
  IT->>TEST: Provide recovery scenarios and scope
  TEST-->>GRC: Return results, defects, and retest evidence
  IT-->>BUS: Report service status and recovery impact
  V-->>GRC: Notify provider changes, incidents, and subcontractors
  GRC-->>BUS: Request residual-risk and remediation decisions

A. Business-service-centered data model

A technology inventory alone cannot establish compliance or resilience. Build a dependency graph across services, business functions, data, applications, infrastructure, and providers to identify which customer processes depend on a cloud region or identity service. Link each node to an owner, criticality, recovery objective, data classification, supplier, contract, test result, and review date.

For example, an international-transfer service may depend on the customer channel, authentication, fraud detection, payment-network connectivity, a cloud database, and external messaging. Technical recovery of each component does not guarantee recovery of the end-to-end service. Design business-level recovery scenarios that account for dependency order, manual workarounds, regulatory constraints, and customer communication. When business impact changes, update technical recovery priority and the criticality of supplier relationships.

B. Evidence automation and change management

Linking policies, risk assessments, inventories, incident records, test results, and supplier contracts in an evidence catalog improves supervisory response and audit reproducibility. Automated collection is useful for observable facts such as configuration changes, vulnerability status, backup success, test completion, and provider status. However, do not approve residual risk based on an automated score alone; a responsible owner must review business impact and exceptions.

Change management should include business-service impact, security and recovery controls, provider notification, documentation updates, testing, and approval. For example, moving a database to another region or provider requires more than changing connection settings: reassess data migration, key management, backup restoration, latency, and contractual cross-border constraints. Linking material changes to resilience testing or risk review at release approval reduces the gap between regulatory documents and live operations.

C. Service recovery and crisis decisions

Recovery objectives should be derived from business impact and risk appetite, not chosen arbitrarily at server level. Recovery time objectives (RTOs) and recovery point objectives (RPOs) reflect service dependencies, data replay, customer and market loss, and operating cost. Technical recovery is not complete until business-data consistency, transaction reprocessing, customer communication, and reconciliation are addressed.

During a crisis, an authorized incident commander prioritizes isolation, alternate operation, provider escalation, data restoration, and customer notification. Automation can accelerate detection and repetitive tasks, but irreversible actions such as stopping transactions or rolling back data require approvals and safeguards. Measure decision delays and approval conflicts in exercises; otherwise optimization may reduce only technical recovery time.

4. Comparison with related frameworks

DORA overlaps with cybersecurity, business continuity, and outsourcing controls, but uniquely aligns digital resilience for finance through a directly applicable sector regulation. Having an international standard or general security framework does not automatically fulfill DORA obligations. Conversely, mapping existing controls and evidence to DORA reduces duplication and avoids creating an isolated compliance operation.

Dimension DORA ISO/IEC 27001 Traditional BCP/DR
Primary aim ICT operational resilience in finance Continual improvement of an ISMS Continuity and recovery during disruption
Normative form EU law and related technical standards Voluntary international standard/certification Depends on policy, standards, and contracts
Core scope Risk, incident reporting, tests, third parties, sharing Information-security risks and controls Business impact, workarounds, recovery
Accountability Financial-entity management and obligations Organization's management system and owners Business and IT recovery leaders
Practical relationship Adds regulatory duties over shared evidence Reusable security-control foundation Connects recovery capability and exercises

These differences do not imply that one framework is universally superior. ISO/IEC 27001 supports systematic information-security management, while BCP/DR focuses on continuity planning during disruption. DORA makes incident reporting, resilience testing, and financial-institution/provider relationships supervisory obligations; mapping existing controls to it is a practical way to find gaps.

A. Industry scenarios

Assume a hypothetical European bank cannot process mobile payments and transfers after a major cloud-region outage. Its service dependency graph identifies fallback paths for authentication, the transaction ledger, fraud detection, and notifications; impact tolerances guide failover, restricted operation, and recovery order. The incident team records impact by time, transaction volume, data consistency, and customer communication, while the provider supplies investigation, logs, and recovery support under contract.

A second scenario is a material change in a critical SaaS provider's subcontracting arrangement. The bank uses its provider register and critical-service dependencies to identify affected functions and reassess data locations, subcontractors, audit rights, and transition support. If immediate replacement is impossible, it defines compensating controls and an exit strategy and names the owner who accepts residual risk.

A third scenario occurs when daily backups succeed but a recovery test finds that the key-management service shares the same failure domain, making the backups undecryptable. Backup-success metrics alone do not prove resilience; exercises must test independent credentials, key recovery, and data integrity. Feeding findings into procurement terms and architecture standards reduces the chance of the same weakness recurring in another service.

5. Advanced topic: oversight and operational maturity after DORA applies

DORA has applied since 17 January 2025; it does not mean that every financial entity must implement controls and tests at the same scale. Apply proportionality while making control intensity explainable in view of important services, size, risk profile, and complexity. Smaller entities still need clear ownership and controls for critical-service assets, suppliers, incidents, and recovery; simplification is not an exemption to ignore material risk.

Distinguish each entity's contractual risk management from the ESAs' direct oversight of CTPPs. Oversight of critical providers addresses concentration risk across the financial ecosystem, but every financial entity remains responsible for its own provider assessment, selection, contracts, continuity, and exit plan. As of 2026, ESMA's DORA oversight guidance provides official information on designation, Lead Overseers, and the oversight framework; check that guidance and competent-authority notices for current designations and supervisory status.

Supervisory readiness should mature from collecting documents just before an audit to continuously capturing evidence that controls operate. When change approvals, recovery exercises, incident timelines, and provider-register updates share service identifiers, they support both regulatory reporting and management risk decisions. The objective is not to retain every available datum: apply data minimization, retention rules, and access controls to evidence design.

6. Considerations and implications

A. Integrate compliance with service recovery

Documents and policies alone do not improve operational resilience. Test controls and recovery exercises against real critical-service disruption scenarios, then turn weaknesses into funded improvements in staffing, budgets, and architecture.

B. Proportionality and consistency

Proportionality to size and complexity is necessary, but inconsistent definitions of critical services and risk appetite make group oversight and comparison difficult. Use a layered model with a minimum common taxonomy and control principles, then manage entity-specific risks as extensions.

C. Provider concentration and exit strategy

Adding multiple providers does not always reduce risk. If providers share identity, DNS, network connectivity, management consoles, or subcontractors, they may still share a failure point. Test substitutability across data migration, business reconstruction, contract termination, and workforce transition; revise unrealistic exit plans regularly.

D. Test safety and independence

Design penetration tests and recovery exercises with scope, authorization, stop conditions, and evidence protection to avoid outages or exposure of customer data. When critical systems or providers participate, coordination, independence, and conflict-of-interest controls matter; close findings through retesting.

E. Management accountability and frontline authority

Management approves resilience objectives and risk, while responders need real authority to isolate services and start recovery during a crisis. Exercise contact trees, deputies, approval limits, and customer and supervisory notification responsibilities to reduce organizational bottlenecks.

F. Data quality and automation

If inventories, provider registers, incident classifications, or test records are inaccurate, automation merely produces incorrect reports faster. Define data owners, update timing, validation rules, and lineage between systems of record and evidence stores. Automated decisions must not replace accountable human approval or an explainable exception process.

G. Response for Korean financial entities and technology companies

Korean entities doing business with EU financial markets should assess both legal applicability and customer outsourcing, security, and incident-notification requirements contract by contract. Technology providers should treat security evidence, service dependencies, subcontracting, incident notice, and recovery support as part of product operations. A professional engineer should propose a phased roadmap balancing regulatory response with customer service levels, technical debt, and operating cost rather than ending with short-term documentation.

References

In one line: DORA integrates financial entities' ICT risk, incidents, testing, and third-party dependencies around business services so critical functions can continue or recover through disruption and demonstrate ecosystem resilience.