13 DORA (Digital Operational Resilience Act)

Financial institutions depend on technology for almost every critical business service.

Examples include:

Online Banking

Payments

Trading

Insurance Platforms

Investment Services

Clearing

Settlement

Customer Authentication

Cloud Infrastructure

Data Processing

This creates a critical regulatory question:

What Happens
When Technology Fails?

A financial institution may have strong cybersecurity controls and still experience:

Cloud Outage

Ransomware

Network Failure

Third-Party Failure

Software Defect

Identity Platform Failure

Data Corruption

Cyberattack

For this reason, the European Union introduced the:

Digital Operational
Resilience Act

commonly known as:

DORA

DORA focuses on whether financial entities can:

Prevent
      ↓
Withstand
      ↓
Respond
      ↓
Recover
      ↓
Learn

from serious ICT disruptions.

DORA applies from 17 January 2025 and establishes common digital-operational-resilience requirements across the EU financial sector. (Eur-Lex)

Learning Objectives

By the end of this lesson, you will be able to:

• explain the purpose of DORA.

• understand why digital operational resilience is important.

• identify major categories of financial entities subject to DORA.

• understand ICT risk-management requirements.

• understand management-body accountability.

• identify critical and important business functions.

• understand ICT asset management.

• understand ICT dependency mapping.

• understand ICT protection and prevention.

• understand detection capabilities.

• understand business continuity and disaster recovery.

• understand backup and restoration requirements.

• understand ICT-related incident management.

• understand major ICT incident classification.

• understand regulatory incident reporting.

• understand significant cyber-threat notification.

• understand operational-resilience testing.

• understand vulnerability testing.

• understand scenario testing.

• understand threat-led penetration testing.

• understand TLPT scope and governance.

• understand ICT third-party risk management.

• understand critical or important functions.

• understand contractual requirements.

• understand subcontracting risk.

• understand concentration risk.

• understand exit strategies.

• understand the DORA Register of Information.

• understand oversight of critical ICT third-party providers.

• understand information-sharing arrangements.

• understand DORA evidence and assurance.

• build a DORA compliance program.

• integrate DORA with ISO 27001, ISO 22301, NIST, TPRM, and enterprise GRC.

1. What Is DORA?

DORA is:

Regulation (EU)
2022/2554

on digital operational resilience for the financial sector.

Its central objective is to create a:

High Common Level
of Digital Operational
Resilience

across financial entities in the European Union.

DORA establishes requirements relating to:

ICT Risk Management

ICT Incident Reporting

Operational Resilience Testing

ICT Third-Party Risk

Threat Information Sharing

and introduces oversight for certain critical ICT third-party providers. (Eur-Lex)

2. Why DORA Was Introduced

Financial stability historically focused heavily on:

Capital

Liquidity

Credit Risk

Market Risk

But modern financial institutions depend equally on:

Technology

A major ICT outage can stop:

Payments

Trading

Customer Services

Settlement

Claims Processing

even if the institution remains financially healthy.

3. The Digital Operational Resilience Problem

Consider:

Bank
      ↓
Cloud Provider
      ↓
Identity Provider
      ↓
Payment Platform
      ↓
External Data Provider

A failure at any layer may disrupt the financial service.

Therefore:

Financial Resilience
      +
Technology Resilience
      =
Operational Resilience

4. DORA’s Core Pillars

A practical way to understand DORA is through five major areas:

1 ICT Risk Management

2 ICT Incident Management
  & Reporting

3 Digital Operational
  Resilience Testing

4 ICT Third-Party
  Risk Management

5 Information Sharing

There is also an important:

Critical ICT
Third-Party Provider
Oversight Framework

5. Who Does DORA Apply To?

DORA covers a wide range of EU financial-sector entities.

Examples include various:

Credit Institutions

Payment Institutions

Investment Firms

Insurance Undertakings

Reinsurance Undertakings

Crypto-Asset Service Providers

Central Securities Depositories

Trading Venues

Central Counterparties

Fund Managers

Credit Rating Agencies

and other financial entities defined by the regulation.

Always determine exact legal applicability for the organization being assessed.

6. Proportionality

DORA applies a principle of:

Proportionality

Requirements should be implemented considering factors such as:

Size

Risk Profile

Business Complexity

Services

ICT Environment

This does not mean:

Small Entity
=
No Requirements

It means implementation should reflect the entity’s risk and complexity.

7. Management Body Accountability

One of DORA’s most important governance principles is that ICT risk is not simply:

The CISO's Problem

The management body has responsibility for defining, approving, overseeing, and remaining accountable for the ICT risk-management framework.

Conceptually:

Board / Management Body
        ↓
ICT Risk Governance
        ↓
Policies
        ↓
Controls
        ↓
Monitoring
        ↓
Resilience

8. Management Responsibilities

Leadership should understand:

Critical ICT Risks

Critical Systems

Major Incidents

Third-Party Dependencies

Resilience Testing

Recovery Capability

Material Findings

9. ICT Risk Management Framework

Financial entities should establish a comprehensive:

ICT Risk
Management Framework

Conceptually:

Governance
      ↓
Identify
      ↓
Protect
      ↓
Detect
      ↓
Respond
      ↓
Recover
      ↓
Learn

10. ICT Risk Governance

The framework should establish:

Roles

Responsibilities

Policies

Risk Methodology

Controls

Monitoring

Reporting

11. ICT Risk Register

A structured register may include:

Risk ID

ICT Service

Business Function

Risk Scenario

Likelihood

Impact

Existing Controls

Residual Risk

Risk Owner

Treatment

12. Example ICT Risk

Risk:

Failure of the primary
cloud region could disrupt
online banking and payment
processing.

Controls:

Multi-AZ

Secondary Region

Backup

Failover

Recovery Testing

13. ICT Assets

Organizations should understand their ICT assets.

Examples:

Applications

Servers

Databases

Cloud Resources

Networks

Endpoints

APIs

Security Tools

14. Asset Inventory

Maintain:

Asset

Owner

Location

Business Service

Criticality

Dependencies

Lifecycle Status

15. Why Inventory Matters

You cannot manage resilience for:

Technology
You Do Not Know Exists

Unknown assets create:

Unknown Risk

Unknown Vulnerability

Unknown Dependency

Unknown Recovery Need

16. ICT Dependencies

DORA encourages organizations to understand how critical functions depend on ICT.

Example:

Payment Service
      ↓
Payment Application
      ↓
Database
      ↓
Cloud Platform
      ↓
Identity Provider
      ↓
Network

17. Critical or Important Functions

A major DORA concept is:

Critical or
Important Function

A function may be critical or important where disruption could materially impair:

Financial Performance

Continuity of Services

Regulatory Compliance

Soundness of Operations

The exact assessment should follow DORA and applicable regulatory standards.

18. Critical Function Register

Maintain:

Function

Business Owner

ICT Systems

Third Parties

RTO

RPO

Criticality

19. Business Service Mapping

Start from:

Business Function

not merely:

Server

Example:

Card Payments
      ↓
Payment Gateway
      ↓
Fraud Platform
      ↓
Database
      ↓
Cloud

20. ICT Dependency Mapping

Map:

People

Applications

Infrastructure

Data

Cloud Providers

Networks

Third Parties

supporting each critical service.

21. Single Points of Failure

Identify:

One Component
      ↓
Failure
      ↓
Critical Service Stops

Examples:

Single Cloud Region

Single Identity Provider

Single Network Provider

Single Critical Vendor

22. Protection and Prevention

ICT risk-management controls should protect systems against:

Unauthorized Access

Cyberattacks

Malware

Configuration Errors

Data Loss

System Failure

23. Access Control

Controls should include:

Authentication

Authorization

Least Privilege

MFA

Privileged Access

Periodic Review

24. Privileged Access

Privileged accounts require stronger governance.

Use:

PAM

MFA

Approval

Session Monitoring

Time-Bound Access

Access Reviews

25. Network Security

Controls may include:

Segmentation

Firewalls

IDS / IPS

Secure Remote Access

Network Monitoring

26. Configuration Management

Establish secure baselines for:

Operating Systems

Cloud

Applications

Databases

Network Devices

27. Configuration Drift

Approved Baseline
      ↓
Unauthorized Change
      ↓
Security Exposure

Continuous monitoring helps identify drift.

28. Vulnerability Management

Use:

Discover
      ↓
Prioritize
      ↓
Remediate
      ↓
Validate

29. Vulnerability Prioritization

Consider:

Severity

Exploitability

Asset Criticality

Threat Intelligence

Exposure

Business Impact

30. Patch Management

Patch Available
      ↓
Risk Assessment
      ↓
Test
      ↓
Approve
      ↓
Deploy
      ↓
Verify

31. Detection

Financial entities should maintain capabilities to detect anomalous activity.

Examples:

SOC

SIEM

EDR

NDR

Cloud Monitoring

Application Monitoring

32. Security Telemetry

Collect from:

Identity

Cloud

Endpoints

Networks

Applications

Databases

Critical Third Parties

33. Logging Coverage

Measure:

Critical Systems
Sending Logs
────────────── × 100
Critical Systems

34. Detection Use Cases

Examples:

Credential Compromise

Malware

Privilege Escalation

Unusual Data Transfer

Cloud Misconfiguration

System Failure

Service Degradation

35. ICT Business Continuity

DORA strongly connects cybersecurity with business continuity.

A financial institution should prepare for:

Cyberattack

Technology Failure

Cloud Outage

Network Failure

Data Corruption

Vendor Failure

36. ICT Business Continuity Policy

The policy should establish:

Response

Recovery

Roles

Communication

Testing

Escalation

37. Business Impact Analysis

Identify:

Critical Functions

Maximum Disruption

Dependencies

Recovery Priorities

38. Recovery Time Objective

RTO
=
How Quickly
Must Service
Recover?

39. Recovery Point Objective

RPO
=
How Much Data
Loss Is Acceptable?

40. Backup Requirements

Backups should be:

Protected

Available

Secure

Recoverable

Tested

41. Backup Is Not Resilience

Backup Exists

does not prove:

Service Can Recover

42. Recovery Testing

Test:

Restore Capability

Application Recovery

Data Integrity

Dependencies

RTO

RPO

43. Cyber Recovery

During ransomware:

Production
Compromised

Recovery must consider:

Can We Trust
the Backups?

Can We Build
a Clean Environment?

Are Credentials
Compromised?

44. ICT Incident Management

Organizations should establish a structured process for ICT incidents.

Detect
      ↓
Record
      ↓
Classify
      ↓
Respond
      ↓
Recover
      ↓
Report
      ↓
Learn

45. ICT Incident Register

Maintain:

Incident ID

Date

Service

Impact

Cause

Severity

Response

Recovery

Regulatory Status

46. Major ICT-Related Incidents

Not every event requires regulatory reporting.

DORA establishes criteria for determining:

Major ICT-Related
Incident

Classification considers regulatory criteria defined through DORA and supporting technical standards.

47. Incident Classification Factors

Relevant factors can include:

Customers Affected

Duration

Geographic Spread

Economic Impact

Data Loss

Service Criticality

Use the current applicable technical standards when classifying formally.

48. Incident Reporting

Major ICT-related incidents must be reported to the relevant competent authority through the DORA reporting framework.

Conceptually:

Incident
      ↓
Classification
      ↓
Major?
     / \
   No   Yes
         ↓
Regulatory Reporting

49. Reporting Lifecycle

The regulatory framework includes staged reporting such as:

Initial Notification
      ↓
Intermediate Reporting
      ↓
Final Report

The detailed content and timing are specified through DORA’s regulatory and implementing technical standards. (Finance)

50. Regulatory Notification Matrix

Maintain:

Incident Type

Threshold

Authority

Initial Notification

Intermediate Report

Final Report

Owner

51. Significant Cyber Threats

DORA also provides for voluntary notification of certain:

Significant
Cyber Threats

where applicable.

52. Incident Communication

Stakeholders may include:

Competent Authority

Customers

Business Partners

Board

Law Enforcement

Third Parties

depending on the event.

53. Lessons Learned

After major incidents:

Incident
      ↓
Root Cause
      ↓
Control Failure
      ↓
Corrective Action
      ↓
Retest

54. Digital Operational Resilience Testing

DORA requires financial entities to establish a:

Digital Operational
Resilience Testing
Program

The purpose is to validate:

Are Our Systems
Actually Resilient?

55. Testing Types

Testing can include:

Vulnerability Assessment

Network Security Testing

Scenario Testing

Application Testing

Penetration Testing

Recovery Testing

Performance Testing

depending on risk and applicability.

56. Testing Lifecycle

Define Scope
      ↓
Test
      ↓
Findings
      ↓
Risk Rating
      ↓
Remediation
      ↓
Retest

57. Critical Systems

Higher-risk systems require stronger testing.

Examples:

Payment Platform

Trading Platform

Authentication

Settlement Systems

Critical Cloud Infrastructure

58. Threat-Led Penetration Testing

Certain financial entities may be required to perform:

Threat-Led
Penetration Testing

or:

TLPT

The detailed criteria, scope, methodology, tester requirements, remediation and supervisory cooperation are specified through DORA technical standards. (ESMA)

59. What Is TLPT?

TLPT simulates realistic attacker behavior based on:

Threat Intelligence

rather than only scanning for vulnerabilities.

Conceptually:

Threat Intelligence
      ↓
Realistic Attack Scenario
      ↓
Critical Production Systems
      ↓
Detection & Response
      ↓
Resilience Assessment

60. TLPT vs Traditional Penetration Testing

Traditional test:

Find Vulnerabilities

TLPT:

Can a Realistic
Threat Actor
Compromise a
Critical Function?

61. TLPT Scope

Scope may include:

Critical Functions

Applications

Infrastructure

People

Processes

Third Parties

where relevant.

62. Threat Intelligence

TLPT scenarios should reflect:

Relevant Threat Actors

Attack Techniques

Industry Threats

Entity-Specific Risks

63. Red Team

The red team simulates the attacker.

Activities may involve authorized:

Reconnaissance

Initial Access

Privilege Escalation

Lateral Movement

Objective Execution

within approved rules.

64. Blue Team

The blue team represents defenders.

It should:

Detect

Investigate

Contain

Respond

65. Purple-Team Learning

After testing:

Red Team Findings
      +
Blue Team Response
      ↓
Control Improvement

66. TLPT Governance

Define:

Scope

Authorization

Risk Controls

Testers

Escalation

Evidence

Remediation

67. TLPT Findings

Findings should result in:

Root Cause

Risk

Control Improvement

Owner

Deadline

Retest

68. ICT Third-Party Risk

One of DORA’s strongest areas is:

ICT Third-Party
Risk Management

Financial institutions depend heavily on:

Cloud Providers

SaaS

Data Providers

Managed Services

Telecommunications

Security Providers

69. Outsourcing Does Not Remove Responsibility

Important:

Outsource ICT
      ≠
Outsource Accountability

Financial entities remain responsible for managing ICT risk associated with third parties.

70. ICT Third-Party Strategy

Organizations should establish an ICT third-party-risk strategy, particularly for services supporting critical or important functions. DORA requires relevant entities to regularly review those risks. (Eur-Lex)

71. Vendor Inventory

Maintain:

Provider

Service

Business Function

Criticality

Data

Location

Contract

Subcontractors

72. Criticality Assessment

Ask:

If This
Provider Fails,
What Happens?

73. Critical ICT Provider Example

Online Banking
      ↓
Cloud Provider
      ↓
Failure
      ↓
Banking Service
Unavailable

74. Due Diligence

Before contracting:

Business Need
      ↓
Risk Assessment
      ↓
Security Assessment
      ↓
Resilience Assessment
      ↓
Contract Review
      ↓
Approval

75. Third-Party Risk Factors

Evaluate:

Security

Resilience

Data

Location

Subcontracting

Concentration

Financial Stability

Exit Capability

76. Contractual Arrangements

DORA requires financial entities to manage contractual arrangements with ICT providers carefully.

Contracts should address applicable areas such as:

Services

Locations

Security

Data

Incident Support

Audit

Access

Termination

Exit

with enhanced requirements where critical or important functions are supported.

77. Right to Audit

Organizations may require appropriate:

Access

Inspection

Audit Rights

depending on the service and DORA requirements.

78. Incident Cooperation

Contracts should support:

Incident Notification

Investigation

Information Sharing

Recovery

79. Data Location

Understand:

Where Data
Is Processed

Where It
Is Stored

Where Backups
Exist

80. Subcontracting

Cloud and SaaS providers often rely on:

Subcontractors

Example:

Financial Entity
      ↓
SaaS Provider
      ↓
Cloud Provider
      ↓
Managed Database

81. Subcontracting Risk

Ask:

Who Is
the Subcontractor?

What Service?

What Data?

Which Critical
Function?

Can the Provider
Change Subcontractors?

82. Critical Subcontractors

Particular attention is required where subcontractors support:

Critical or
Important Functions

The EU has developed specific DORA technical standards concerning subcontracting of ICT services supporting such functions. (European Banking Authority)

83. Concentration Risk

DORA requires organizations to understand whether too much critical dependency exists with:

One Provider

One Cloud

One Region

One Technology

84. Concentration Example

Payments

Trading

Insurance Platform

Customer Portal

all depend on:

One Cloud Provider

This may create:

Systemic
Dependency Risk

85. Concentration Analysis

Evaluate:

Number of
Critical Functions

Provider Dependency

Alternative Providers

Migration Complexity

Data Portability

86. Exit Strategy

Critical ICT services should have practical exit planning.

Ask:

Can We Leave
the Provider?

87. Exit Plan

Document:

Trigger

Alternative Service

Data Migration

Timeline

Resources

Data Return

Deletion

Testing

88. Exit Is More Than a Contract Clause

A contract stating:

We Can Terminate

does not prove:

We Can Migrate
the Service

89. Exit Testing

For critical services:

Exit Plan
      ↓
Scenario Exercise
      ↓
Dependencies
      ↓
Capability Gaps

90. Register of Information

A major DORA artifact is the:

Register
of Information

Financial entities must maintain and update information relating to contractual arrangements for ICT services provided by ICT third-party providers. (European Banking Authority)

91. Why the Register Matters

It gives organizations and supervisors visibility into:

Which Providers?

Which Services?

Which Functions?

Which Contracts?

Which Subcontractors?

Which Locations?

Which Critical Dependencies?

92. Register Structure

The official ITS defines standardized templates for maintaining the Register of Information. (European Banking Authority)

A simplified internal view might contain:

Entity

Provider

Contract

ICT Service

Business Function

Criticality

Country

Subcontractor

Termination

93. Register Levels

Depending on organizational structure, information may need to be maintained at:

Entity

Sub-Consolidated

Consolidated

levels where applicable. (Eur-Lex)

94. Register Governance

Assign:

Register Owner

Data Owners

Validation Frequency

Change Process

Quality Checks

95. Register Data Quality

Weak:

Vendor:
Microsoft

Better:

Provider

Specific ICT Service

Contract

Entity

Function

Location

Criticality

96. Procurement Integration

New contract:

Procurement
      ↓
ICT Service?
      ↓
DORA Applicability
      ↓
Register Update

97. Contract Change

Contract Amendment
      ↓
Service Changed?
      ↓
Critical Function Changed?
      ↓
Register Update

98. Critical ICT Third-Party Providers

DORA creates EU-level oversight for certain:

Critical ICT
Third-Party
Service Providers

or:

CTPPs

99. Critical Provider Oversight

The European Supervisory Authorities — EBA, EIOPA, and ESMA — participate in the EU oversight framework, with Lead Overseers responsible for designated critical ICT third-party providers. (European Banking Authority)

100. Why CTPP Oversight Matters

A major provider can support:

Hundreds of
Financial Institutions

A failure could therefore create:

Sector-Wide
Operational Risk

101. Critical Provider Example

Cloud Provider
      ↓
Bank A
Bank B
Insurer C
Investment Firm D

A large-scale outage can affect many entities simultaneously.

102. Systemic Third-Party Risk

This creates:

Individual
Vendor Risk
      +
Sector
Concentration Risk

103. Information Sharing

DORA supports voluntary arrangements for sharing:

Cyber Threat Information

Indicators of Compromise

Tactics

Techniques

Vulnerabilities

subject to applicable safeguards.

104. Why Information Sharing Helps

Institution A
Detects Threat
      ↓
Shares Intelligence
      ↓
Institution B
Blocks Attack

105. Threat Intelligence

A mature financial institution uses:

Internal Threat Data

Industry Intelligence

Government Advisories

Vendor Intelligence

Peer Sharing

106. DORA and ISO 27001

ISO 27001 provides:

Information Security
Management System

DORA adds financial-sector regulatory requirements around:

Operational Resilience

ICT Incidents

Testing

Third Parties

Regulatory Reporting

107. DORA and ISO 22301

ISO 22301 focuses on:

Business Continuity

DORA places continuity within a broader:

Digital Operational
Resilience

model.

108. DORA and NIST CSF

NIST CSF:

Govern
Identify
Protect
Detect
Respond
Recover

can support many DORA cybersecurity capabilities.

109. DORA and Third-Party Risk

Traditional TPRM:

Security Assessment

DORA expands this into:

Security

Resilience

Contracts

Subcontractors

Concentration

Exit

Register of Information

110. DORA and Cloud Governance

Cloud governance should consider:

Shared Responsibility

Regions

Availability

Data Location

Subprocessors

Concentration

Exit

111. DORA Common Control Framework

Example:

Enterprise Control
IAM-001
Privileged MFA
      ↓
DORA
      ↓
ISO 27001
      ↓
NIST
      ↓
SOC 2

112. Operational Resilience Control Framework

Another enterprise control:

RES-001

Critical Services
Must Have Tested
Recovery Capability

supports:

DORA

ISO 22301

BCM

Technology Risk

113. DORA Compliance Lifecycle

Determine Applicability
      ↓
Identify Requirements
      ↓
Map Functions
      ↓
Map ICT Assets
      ↓
Map Third Parties
      ↓
Implement Controls
      ↓
Test Resilience
      ↓
Monitor
      ↓
Report
      ↓
Improve

114. Phase 1 — Applicability

Determine:

Legal Entity

Financial Entity Type

Jurisdiction

Applicable DORA
Requirements

115. Phase 2 — Governance

Establish:

Management Accountability

ICT Risk Framework

Policies

Roles

Reporting

116. Phase 3 — Critical Functions

Identify:

Business Services

Critical Functions

Dependencies

Owners

117. Phase 4 — ICT Assets

Map:

Applications

Infrastructure

Data

Cloud

Networks

118. Phase 5 — Third Parties

Map:

ICT Providers

Contracts

Services

Subcontractors

Critical Functions

119. Phase 6 — Controls

Implement:

IAM

Security

Monitoring

Resilience

Incident Response

Vulnerability Management

120. Phase 7 — Testing

Perform:

Security Testing

Recovery Testing

Scenario Testing

TLPT
where applicable

121. Phase 8 — Continuous Monitoring

Monitor:

ICT Risk

Control Failures

Incidents

Vulnerabilities

Third Parties

Resilience

122. Phase 9 — Regulatory Reporting

Maintain:

Incident Reporting

Register of Information

Supervisory Responses

Evidence

123. Phase 10 — Improvement

Use:

Incidents

Tests

Audits

Findings

Threat Intelligence

to improve resilience.

124. DORA Evidence

Evidence may include:

ICT Risk Policy

Asset Inventory

Dependency Maps

BCP

DR Plans

Recovery Tests

Incident Reports

Vulnerability Reports

Contracts

Third-Party Assessments

Register of Information

TLPT Reports

125. Evidence Traceability

DORA Requirement
      ↓
Enterprise Control
      ↓
Owner
      ↓
Implementation
      ↓
Evidence
      ↓
Testing

126. DORA Requirement Register

Maintain:

Article / Requirement

Obligation

Applicability

Enterprise Control

Owner

Evidence

Status

127. DORA Gap Register

Track:

Gap ID

Requirement

Current State

Risk

Owner

Action

Due Date

Status

128. Example Gap

Requirement:

Critical ICT
Provider Exit Plan

Current:

Termination Clause
Only

Gap:

No Operational
Migration Strategy

129. Treatment

Develop Exit Plan

Identify Alternative

Test Data Export

Estimate Migration Time

Exercise Scenario

130. DORA Dashboard

Example:

DORA RESILIENCE DASHBOARD

Critical Functions              38

Critical ICT Providers          14

Major ICT Incidents              2

Critical Open ICT Risks          5

Failed Resilience Tests          3

Overdue Third-Party Actions      6

Exit Plans Not Tested            4

Illustrative only.

131. ICT Risk Dashboard

Track:

Critical ICT Risks

Risk Trend

Control Failures

Vulnerabilities

Service Availability

132. Third-Party Dashboard

Track:

Critical Providers

Critical Functions Supported

Open Vendor Findings

Subcontractor Changes

Concentration Risk

Exit Readiness

133. Incident Dashboard

Track:

ICT Incidents

Major Incidents

Regulatory Reports

Recovery Time

Root Causes

Repeat Incidents

134. Resilience Dashboard

Track:

Recovery Tests

RTO Achievement

RPO Achievement

Scenario Tests

TLPT Findings

Overdue Remediation

135. Board Reporting

Management-body reporting should answer:

Which Critical
Services Are at Risk?

Which ICT Risks
Are Above Appetite?

Which Third Parties
Create Concentration Risk?

Which Tests Failed?

Which Major Incidents
Occurred?

Can We Recover?

What Decision
Is Required?

136. Avoid Percentage-Only Reporting

Weak:

DORA Compliance
97%

may hide:

Critical Payment
Recovery Test
Failed

or:

No Exit Plan
for Critical Cloud
Provider

137. Common Mistake — Treat DORA as Cybersecurity Only

DORA includes:

Cybersecurity
      +
Technology Risk
      +
Continuity
      +
Third-Party Risk
      +
Operational Resilience

138. Common Mistake — Treat It as an IT Project

DORA requires involvement from:

Management

Business

Risk

Technology

Security

Procurement

Legal

Audit

139. Common Mistake — Start With Controls

First understand:

Critical Functions

ICT Assets

Dependencies

Providers

Then determine controls.

140. Common Mistake — Asset Inventory Without Business Mapping

Knowing:

10,000 Servers

is less useful than knowing:

Which Servers
Support Payments?

141. Common Mistake — BCP Exists Therefore Resilient

Ask:

When Was It
Last Tested?

142. Common Mistake — RTO Exists Only in Spreadsheet

Actual:

RTO:
2 Hours

Test:

Recovery:
8 Hours

creates material risk.

143. Common Mistake — Vendor Has ISO Certificate

DORA requires more than:

Security Certification

It also considers:

Resilience

Contracts

Criticality

Subcontractors

Exit

Concentration

144. Common Mistake — Cloud Contract Equals Exit Plan

A legal termination clause does not demonstrate operational exit capability.

145. Common Mistake — Ignore Subcontractors

Your direct provider may depend on:

Cloud

Database

Network

Security Provider

supporting your critical function.

146. Common Mistake — No Register Governance

If the Register of Information is built only:

Before Regulator
Submission

it will quickly become outdated.

147. Common Mistake — Procurement Is Disconnected

Every new ICT contract should trigger:

DORA Review

148. Common Mistake — Incident Team Does Not Know Reporting Rules

During a major incident:

What Must
We Report?

should already be defined.

149. Common Mistake — TLPT Equals Vulnerability Scan

TLPT is:

Threat-Led

Scenario-Based

Realistic

Critical-Function Focused

not merely automated scanning.

150. Common Mistake — Findings Are Not Retested

Test
      ↓
Finding
      ↓
Fix

is incomplete.

Use:

Test
      ↓
Finding
      ↓
Fix
      ↓
Retest

151. End-to-End Example — EU Bank

Organization:

European Bank

Critical services:

Online Banking

Payments

Cards

Customer Authentication

152. Step 1 — Critical Functions

Identify:

Payments

as a critical function.

153. Step 2 — Dependencies

Payments
      ↓
Payment Application
      ↓
Database
      ↓
Cloud Provider
      ↓
Identity Provider
      ↓
Network

154. Step 3 — ICT Risks

Risks include:

Cloud Outage

Identity Failure

Ransomware

Data Corruption

Vendor Failure

155. Step 4 — Controls

Implement:

MFA

Segmentation

Monitoring

Backup

Failover

Incident Response

156. Step 5 — Recovery

Requirement:

RTO
2 Hours

Test result:

Actual Recovery
4.5 Hours

Gap:

Recovery Capability
Does Not Meet
Business Requirement

157. Step 6 — Treatment

Automate Failover

Improve Runbook

Increase Replication

Retest

158. Step 7 — Third Party

Cloud provider supports:

Critical Function

Therefore perform enhanced:

Due Diligence

Contract Review

Concentration Analysis

Exit Planning

159. Step 8 — Register

Record:

Provider

Service

Contract

Critical Function

Location

Subcontractors

160. Step 9 — Testing

Perform resilience testing.

If selected:

TLPT

tests whether realistic attackers could compromise the critical function.

161. Step 10 — Management Reporting

Report:

Recovery Gap

Cloud Concentration Risk

TLPT Findings

Third-Party Exit Risk

162. End-to-End Example — Critical SaaS Provider

Financial entity uses:

SaaS Trading Platform

Vendor supports:

Critical Investment
Service

163. Vendor Assessment

Evaluate:

Security

Availability

BCP

DR

Subcontractors

Locations

Incident Response

Exit

164. Concentration

Vendor hosts on:

Cloud Provider A

Financial entity already uses Provider A for:

Payments

CRM

Analytics

Identity

This creates:

Cloud Concentration
Risk

165. Treatment

Possible options:

Alternative Provider

Multi-Cloud

Resilience Controls

Contract Protection

Exit Planning

Risk Acceptance

166. End-to-End Example — Major ICT Incident

Scenario:

08:00
Identity Platform Failure

08:15
Customers Unable to Login

08:30
Payments Impacted

09:00
Incident Escalated

167. Incident Response

Detect
      ↓
Classify
      ↓
Contain
      ↓
Activate Continuity
      ↓
Recover

168. Regulatory Assessment

Determine:

Does Incident Meet
Major ICT Incident
Criteria?

If yes:

Regulatory Reporting
Workflow

is activated.

169. Lessons Learned

Root cause:

Identity Provider
Configuration Error

Improvement:

Change Control

Secondary Authentication

Monitoring

Recovery Testing

170. DORA Operating Model

Management Body
      ↓
Digital Operational
Resilience Governance
      ↓
ICT Risk Management
      ↓
Critical Functions
      ↓
ICT Assets
      ↓
Third Parties
      ↓
Controls
      ↓
Testing
      ↓
Incident Management
      ↓
Continuous Monitoring
      ↓
Regulatory Assurance

171. Three Lines Model

First Line
Business / ICT
      ↓
Own Risk & Controls

Second Line
Risk / GRC
      ↓
Oversight & Challenge

Third Line
Internal Audit
      ↓
Independent Assurance

DORA technical standards also reinforce appropriate segregation and independence of control and internal-audit functions. (Eur-Lex)

DORA Readiness Checklist

Governance

• DORA applicability determined.

• management-body accountability documented.

• ICT risk-management framework approved.

• roles defined.

• policies established.

• reporting to management established.

Critical Functions

• critical or important functions identified.

• business owners assigned.

• ICT dependencies mapped.

• third-party dependencies mapped.

• criticality reviewed periodically.

ICT Assets

• asset inventory maintained.

• applications inventoried.

• cloud assets inventoried.

• networks inventoried.

• data dependencies understood.

• asset owners assigned.

ICT Risk

• ICT risks identified.

• likelihood and impact assessed.

• controls identified.

• residual risks determined.

• risk owners assigned.

• risks above appetite escalated.

Security Controls

• IAM controls established.

• MFA implemented.

• privileged access governed.

• network security established.

• secure configurations maintained.

• vulnerability management implemented.

• patch management implemented.

Detection

• critical logs collected.

• SIEM or equivalent monitoring established.

• endpoint detection established.

• cloud monitoring established.

• detection use cases maintained.

• logging coverage measured.

Continuity & Recovery

• ICT BCP maintained.

• critical services mapped.

• RTO established.

• RPO established.

• backup strategy maintained.

• recovery tested.

• cyber-recovery scenarios tested.

• test gaps remediated.

Incident Management

• incident process established.

• ICT incident register maintained.

• major-incident criteria implemented.

• regulatory reporting workflow defined.

• notification responsibilities assigned.

• communication procedures established.

• lessons learned tracked.

Resilience Testing

• testing program established.

• critical systems prioritized.

• vulnerability testing performed.

• scenario testing performed.

• recovery testing performed.

• findings remediated.

• retesting completed.

TLPT

• TLPT applicability assessed.

• critical functions scoped.

• tester governance established.

• threat intelligence incorporated.

• testing authorized.

• findings documented.

• remediation tracked.

• retesting performed where required.

Third-Party Risk

• ICT provider inventory maintained.

• provider criticality assessed.

• critical-function dependencies identified.

• due diligence performed.

• contracts reviewed.

• subcontractors assessed.

• concentration risk assessed.

• exit strategies established.

Register of Information

• Register of Information established.

• contracts mapped.

• ICT services mapped.

• providers identified.

• critical functions mapped.

• data quality controls established.

• register updated after changes.

• consolidated reporting supported where applicable.

Audit & Assurance

• DORA requirement register maintained.

• controls mapped.

• evidence retained.

• internal testing performed.

• audit independence maintained.

• findings tracked.

• overdue remediation escalated.

DORA Deliverables

After completing this lesson, you should be able to create:

01 DORA Applicability Assessment

02 DORA Regulatory Requirement Register

03 Digital Operational Resilience Governance Model

04 DORA RACI

05 Critical / Important Function Register

06 ICT Asset Inventory

07 ICT Dependency Map

08 ICT Risk Register

09 ICT Control Framework

10 ICT Business Continuity Plan

11 ICT Disaster Recovery Plan

12 Recovery Test Register

13 ICT Incident Register

14 Major Incident Classification Matrix

15 Regulatory Incident Reporting Matrix

16 Digital Operational Resilience Testing Plan

17 TLPT Applicability Assessment

18 TLPT Governance Plan

19 ICT Third-Party Inventory

20 ICT Provider Criticality Assessment

21 DORA Contract Compliance Matrix

22 Subcontractor Register

23 ICT Concentration Risk Register

24 ICT Exit Strategy Register

25 DORA Register of Information

26 DORA Gap Register

27 DORA Remediation Tracker

28 Digital Operational Resilience Dashboard

29 ICT Third-Party Risk Dashboard

30 Executive DORA Dashboard

Practical Activity — Identify Critical Functions

Scenario:

European Bank

Services:

Online Banking

Card Payments

Mortgage Portal

HR System

Marketing Platform

Internal Wiki

Classify each as:

Critical / Important

Supporting

Noncritical

Then identify:

Business Owner

Applications

Cloud Providers

Data

RTO

RPO

Practical Activity — Build an ICT Dependency Map

For:

Card Payments

map:

Application

Database

Identity

Network

Cloud

Fraud Provider

Payment Processor

Support Provider

Identify:

Single Points
of Failure

Practical Activity — Major ICT Incident Classification

Scenario:

Online Banking
Unavailable

Duration:
4 Hours

Customers:
150,000

Payment Processing:
Partially Affected

Cause:
Cloud Networking Failure

Assess:

Customer Impact

Duration

Service Criticality

Economic Impact

Geographic Impact

Data Impact

Then determine whether the incident should be escalated for formal DORA major-incident classification using the applicable criteria.

Practical Activity — Build a Register of Information

For the following providers:

AWS

Microsoft 365

Payment SaaS

Fraud Detection Provider

Identity Provider

document:

Provider

ICT Service

Contract

Entity

Critical Function

Country

Subcontractors

Exit Provision

Owner

Practical Activity — Assess Concentration Risk

Scenario:

AWS Supports:

Online Banking

Payments

Customer Analytics

Risk Platform

Backup

Assess:

Dependency

Criticality

Region Dependency

Alternative Providers

Migration Complexity

Exit Time

Determine whether material concentration risk exists.

Practical Activity — Build a Vendor Exit Strategy

Critical provider:

Customer Identity
SaaS Platform

Develop:

Exit Trigger

Alternative Provider

Data Export

Migration Steps

Parallel Operation

Testing

Timeline

Resources

Data Deletion

Practical Activity — Design a Resilience Test

Critical function:

Online Payments

Scenario:

Primary Cloud Region
Unavailable

Test:

Detection

Failover

Communication

Recovery

RTO

RPO

Third-Party Coordination

Document:

Expected Result

Actual Result

Gap

Root Cause

Remediation

Retest

Practical Activity — TLPT Scenario

Critical function:

Digital Banking

Threat intelligence indicates:

Financially Motivated
Threat Group

Targets:
VPN
Privileged Accounts
Cloud Identity

Develop an authorized high-level TLPT plan covering:

Threat Scenario

Critical Function

Test Scope

Red Team

Blue Team

Rules of Engagement

Success Criteria

Findings

Remediation

DORA GRC Mindset

When working with DORA, ask:

Does DORA
Apply to Us?

Which Legal Entity
Is in Scope?

What Does
the Management Body
Need to Oversee?

Which Business
Functions Are Critical?

Which ICT Systems
Support Them?

Which Data
Supports Them?

Which Third Parties
Support Them?

Do We Know
Every ICT Asset?

Are Dependencies
Mapped?

Where Are
Single Points
of Failure?

Which ICT Risks
Could Disrupt
Critical Services?

Are Those Risks
Within Appetite?

Are Security
Controls Effective?

Is Privileged Access
Controlled?

Are Vulnerabilities
Continuously Managed?

Can We Detect
ICT Failures?

Can We Detect
Cyberattacks?

Are Critical Logs
Available?

Can the Business
Continue During
an ICT Disruption?

What Is
the RTO?

What Is
the RPO?

Have We
Actually Tested
Recovery?

Can We Recover
from Ransomware?

Are Backups
Trusted?

How Do We
Classify ICT Incidents?

What Makes
an Incident Major?

Who Decides
Whether to Report?

Are Reporting
Timelines Embedded
in the Playbook?

Do We Maintain
an ICT Incident
Register?

What Resilience
Testing Do We
Perform?

Which Critical
Systems Are Tested?

Are We Subject
to TLPT?

Does TLPT
Reflect Real Threats?

Are Findings
Remediated?

Are Fixes
Retested?

Which ICT Providers
Support Critical
Functions?

Have We
Performed Due Diligence?

Do Contracts
Meet DORA
Requirements?

Which Subcontractors
Are Involved?

Where Are
Services Performed?

Do We Have
Cloud Concentration Risk?

Can We
Leave the Provider?

Is the Exit Plan
Actually Executable?

Have We
Tested It?

Is the Register
of Information
Accurate?

Is Procurement
Updating It?

Do We Know
Which Providers
Could Create
Sector-Wide Risk?

Can Controls
Map to ISO 27001,
ISO 22301,
NIST and
other frameworks?

What Does
the Board Need
to Know?

Which Risks
Require Action?

Which Resilience
Tests Failed?

Which Providers
Create Material Risk?

What Decision
Is Required?

Are We
Compliant with DORA?

Or Can We
Actually Keep
Critical Financial
Services Running
During Serious
ICT Disruption?

That is the mindset of a GRC professional managing Digital Operational Resilience under DORA.

Key Takeaways

• DORA is Regulation (EU) 2022/2554.

• It has applied since 17 January 2025.

• DORA establishes a common digital-operational-resilience framework for the EU financial sector.

• DORA is broader than traditional cybersecurity compliance.

• Its major areas include ICT risk management, incident management and reporting, resilience testing, ICT third-party risk, information sharing, and critical-provider oversight.

• Management bodies have significant accountability for ICT risk governance.

• Financial entities should identify critical or important functions.

• ICT assets and dependencies supporting those functions should be mapped.

• Accurate ICT asset inventories are foundational to resilience.

• Security controls should protect against both cyberattacks and technology failures.

• Detection capabilities should cover critical ICT environments.

• Business continuity and disaster recovery are fundamental components of digital operational resilience.

• RTO and RPO requirements should reflect business impact.

• Recovery capability must be tested rather than assumed.

• Cyber recovery should consider whether compromised infrastructure and backups can be trusted.

• ICT-related incidents require structured classification.

• Major ICT incidents can trigger regulatory reporting.

• DORA’s supporting technical standards define detailed incident-reporting content and timelines.

• Digital operational-resilience testing should validate whether controls and recovery capabilities work.

• Certain entities may be required to conduct threat-led penetration testing.

• TLPT is based on realistic threat intelligence and critical-business-function scenarios.

• Third-party ICT risk is one of DORA’s most important governance areas.

• Outsourcing ICT does not outsource the financial entity’s accountability.

• Contracts supporting critical or important functions require stronger governance.

• Subcontractor dependencies should be understood.

• Concentration risk should be analyzed across important ICT providers.

• Critical providers require practical exit strategies.

• DORA requires financial entities to maintain a Register of Information for ICT contractual arrangements.

• The EU technical standards provide standardized templates for that register.

• Critical ICT third-party providers can be subject to EU-level oversight.

• DORA can integrate with ISO 27001, ISO 22301, NIST CSF, cloud governance, TPRM, and enterprise risk management.

• Mature DORA programs focus on whether critical services can withstand and recover from disruption rather than simply measuring compliance percentages.

Knowledge Check

Before continuing, make sure you can answer:

1. What is DORA?

2. When did DORA become applicable?

3. Why was DORA introduced?

4. What is digital operational resilience?

5. What are DORA’s major pillars?

6. Which types of financial entities can fall within DORA?

7. What does proportionality mean?

8. What is the management body’s role?

9. What is an ICT risk-management framework?

10. Why is ICT asset inventory important?

11. What is an ICT dependency?

12. What is a critical or important function?

13. Why should business functions be mapped to technology?

14. What is a single point of failure?

15. What security capabilities support DORA?

16. Why is detection important?

17. How does business continuity support DORA?

18. What is RTO?

19. What is RPO?

20. Why does backup alone not prove resilience?

21. What is cyber recovery?

22. What is an ICT-related incident?

23. What is a major ICT-related incident?

24. What factors can influence incident classification?

25. What is staged regulatory incident reporting?

26. What is a significant cyber threat?

27. What is digital operational-resilience testing?

28. What types of testing can support DORA?

29. What is TLPT?

30. How does TLPT differ from normal penetration testing?

31. Why is threat intelligence important in TLPT?

32. What is ICT third-party risk?

33. Why does outsourcing not eliminate accountability?

34. What is a critical ICT provider dependency?

35. Why are contractual requirements important?

36. Why should subcontractors be identified?

37. What is ICT concentration risk?

38. What is a provider exit strategy?

39. Why should exit capability be tested?

40. What is the DORA Register of Information?

41. Why must the Register of Information stay current?

42. What information does the register help organizations understand?

43. What is a critical ICT third-party provider?

44. Why does DORA establish provider oversight?

45. What role do EBA, EIOPA, and ESMA play?

46. How can information sharing improve resilience?

47. How can ISO 27001 support DORA?

48. How can ISO 22301 support DORA?

49. Why should board reporting focus on material resilience gaps?

50. What makes a mature DORA program effective?

What’s Next?

➡️ Next: 14 — NIS2 Directive

In the next lesson, you will move from financial-sector digital operational resilience into the European Union’s broader cybersecurity framework for essential and important entities across critical sectors.

You will learn how NIS2 connects:

Cybersecurity Governance
        ↓
Risk Management
        ↓
Critical Services
        ↓
Security Controls
        ↓
Supply Chain Security
        ↓
Incident Handling
        ↓
Business Continuity
        ↓
Incident Reporting
        ↓
Executive Accountability

You will explore:

NIS2 Directive

Essential Entities

Important Entities

Cyber Risk Management

Management-Body Accountability

Incident Handling

Business Continuity

Crisis Management

Supply Chain Security

Vulnerability Management

Cryptography

Access Control

Multi-Factor Authentication

Security Awareness

Incident Reporting

Early Warning

Incident Notification

Final Reporting

Supervision

Enforcement

and understand how NIS2 extends cybersecurity governance beyond the financial sector into areas such as:

Energy

Transport

Banking

Healthcare

Digital Infrastructure

Cloud Services

Managed Services

Public Administration

Manufacturing

Postal Services

Research

Other Critical Sectors

The major question will change from:

Can a Financial
Institution Remain
Digitally Resilient?

to:

How Does the EU
Protect Essential
and Important
Services Across
the Wider Economy?

➡️ Next: 14 — NIS2 Directive

The main current DORA implementation details used above are grounded in the regulation itself and the adopted EU technical standards, including the Register of Information templates and the technical standards covering major ICT-incident reporting and TLPT. :contentReference[oaicite:12]{index=12}