Created by Claudiu Tabac - © 2026
This material is open for educational and research use. Commercial use without explicit permission from the author is not allowed.
DORA Lens (ECIL-DORA)
Evaluating Digital Operational Resilience in Regulated Financial Services
Understanding the DORA Lens Framework
What is the DORA Lens?
The DORA Lens interprets the ECIL through the critical perspective of Digital Operational Resilience in regulated financial environments. This framework evaluates whether your organization can withstand, respond to, and recover from ICT-related disruptions-including cyber incidents, system failures, and third-party outages-without jeopardizing critical services.
Unlike traditional security assessments that focus on theoretical robustness, DORA evaluates operational survivability under real-world stress conditions. It doesn't redefine security capabilities but rather stress-tests them against resilience and continuity expectations that matter when systems fail.
Core Purpose
The DORA Lens serves four essential functions for financial institutions:
  • Interpret DORA obligations through established shared security capabilities
  • Emphasize resilience, continuity, and recovery performance under operational stress
  • Connect technical security controls directly to business service availability
  • Enable regulator-ready reasoning and documentation without unnecessary control duplication
This approach ensures your security investments translate into demonstrable operational resilience-the currency that matters to supervisors and stakeholders alike.
How DORA Evaluates Security Capabilities
Governance of ICT Risk
Board-level oversight, accountability structures, and integration of ICT risk into enterprise risk management frameworks
Prevention & Detection
Proactive controls, monitoring capabilities, and early warning systems that identify threats before they escalate
Recovery & Continuity
Restoration capabilities, business continuity procedures, and validated recovery time objectives under stress
Resilience Testing
Scenario-based testing, stress validation, and continuous improvement based on test outcomes and incidents
Third-Party Risk
Vendor governance, concentration risk management, and exit strategies for critical ICT service providers
DORA focuses on end-to-end resilience of ICT-supported services, emphasizing performance under disruption rather than steady-state operation. This lens evaluates whether your controls actually work when pressure is applied-when systems fail, attackers strike, or dependencies break down.
Relationship to ECIL Capability Model
The DORA Lens doesn't create new security capabilities-it evaluates existing ones through a resilience-focused perspective. Under this lens, Security Capability Clusters from the ECIL framework are assessed based on their real-world performance characteristics.
Contribution to Service Continuity
Does this capability directly support the continuation of critical business services during ICT disruptions? Can it maintain essential functions when infrastructure is compromised?
Operational Performance Under Stress
Does this capability function effectively during incident scenarios, system degradation, or heightened threat conditions? Has it been validated through testing?
Integration Between Capabilities
How effectively do prevention, detection, and recovery capabilities work together? Are there clear escalation paths and coordinated response procedures?
Governance of Dependencies
Are critical dependencies identified, monitored, and governed? Does management have visibility into concentration risks and single points of failure?

Key Principle: Capabilities that fail under pressure fail under DORA. Theoretical controls that cannot be demonstrated through testing or validated through incident response are insufficient for regulatory expectations.
DORA Interpretation Domains
DORA requirements are interpreted in ECIL through four coherent domains, organized by resilience intent rather than regulatory article numbering. This structure reflects how organizations actually manage operational resilience-through integrated capabilities rather than isolated compliance checkboxes.
ICT Risk Management
Evaluates whether ICT risks are identified, governed, and managed across the organization with clear ownership and accountability
Detection, Response & Recovery
Assesses the organization's ability to detect incidents quickly, respond effectively, and restore critical services to operational status
Testing & Resilience Validation
Validates that resilience is proven through rigorous testing programs rather than assumed based on design documentation
ICT Third-Party Risk
Governs external ICT dependencies as resilience risks with appropriate oversight, contractual controls, and exit planning
Each domain addresses a critical dimension of operational resilience. Together, they create a comprehensive framework for evaluating an organization's ability to survive and recover from ICT disruptions while maintaining critical services for customers and counterparties.
ICT Risk Management & Third-Party Risk
ICT Risk Management Domain
This domain evaluates whether ICT risks are systematically identified, governed, and managed across the entire organization. It establishes the foundation for resilience by ensuring risks are visible to decision-makers and integrated into enterprise risk frameworks.
Key Focus Areas
  • ICT Risk Governance: Board-level oversight, clear ownership structures, and accountability for ICT risk decisions
  • Risk Identification: Comprehensive inventories of assets, services, and dependencies with appropriate classification
  • Preventive Measures: Controls designed to reduce likelihood and impact of ICT-related disruptions
  • Enterprise Integration: Connection between ICT risk, operational risk, and overall enterprise risk management
ICT Third-Party Risk Domain
This domain evaluates whether external ICT dependencies are governed as resilience risks, not merely procurement or vendor management issues. It addresses concentration risk, substitutability, and the organization's ability to maintain services if critical providers fail.
Key Focus Areas
  • Critical Provider Identification: Clear determination of which ICT service providers support critical or important functions
  • Risk-Based Governance: Proportionate oversight based on criticality, complexity, and concentration
  • Contractual Resilience: Service level agreements, audit rights, and exit provisions embedded in contracts
  • Monitoring & Exit Planning: Ongoing performance oversight and viable substitution strategies
Detection, Response & Testing Domains
01
Detection of ICT-Related Incidents
Monitoring systems, threat intelligence, and early warning capabilities that identify anomalies, attacks, or system degradation before they escalate into major disruptions
02
Coordinated Incident Response
Clear procedures, defined roles, escalation paths, and decision-making authorities that enable rapid, coordinated action when incidents occur
03
Recovery and Restoration
Validated capabilities to restore critical services within defined recovery time objectives, with fallback options if primary recovery paths fail
04
Learning and Continuous Improvement
Post-incident analysis, root cause identification, and systematic improvement of controls, procedures, and resilience capabilities

Testing & Resilience Validation
This domain evaluates whether resilience is validated through rigorous testing programs, not merely assumed based on documentation. DORA requires organizations to prove their capabilities work under stress through scenario-based testing, business continuity drills, and disaster recovery validation.
BC/DR Testing
Regular testing of business continuity and disaster recovery plans with documented results and remediation of identified gaps
Scenario Testing
Advanced testing using realistic attack scenarios, multi-failure conditions, and stress conditions that challenge assumptions
Recovery Validation
Verification that recovery time and recovery point objectives can actually be achieved under operational conditions
Evidence & Supervisory Expectations
DORA places extraordinary emphasis on demonstrable resilience-not theoretical frameworks or compliance documentation. Supervisors assess what actually happens when things go wrong, evaluating organizations based on their proven ability to maintain or rapidly restore critical services under adverse conditions.
1
Service Continuity
Can critical services continue operating during ICT disruptions? Is there evidence of successful service maintenance during past incidents?
2
Testing Results
What do resilience tests reveal? Are recovery objectives achievable? Have identified weaknesses been remediated?
3
Incident Performance
How has the organization performed during actual incidents? Were detection, response, and recovery capabilities effective?
4
Third-Party Governance
Are critical ICT providers identified and monitored? Do contracts include appropriate resilience requirements and exit provisions?

Supervisory Perspective: Regulators are fundamentally interested in one question: "What happens when things go wrong?" They assess resilience through incident outcomes, test results, and the organization's ability to demonstrate-not merely document, operational survivability.
Common Failure Patterns Under DORA
Organizations often discover their resilience gaps only under supervisory review or actual disruption. Understanding common failure patterns helps institutions proactively address weaknesses before they become regulatory findings or operational crises.
Prevention-Recovery Imbalance
Strong preventive controls and security monitoring, but weak or untested recovery capabilities. Organizations invest heavily in preventing incidents but cannot restore services quickly when prevention fails.
Untested Assumptions
Business continuity and disaster recovery plans exist on paper but have never been validated through realistic testing. Recovery time objectives are aspirational rather than proven.
Third-Party Concentration
Overreliance on single ICT providers without viable alternatives or exit strategies. Lack of visibility into subcontracting chains and fourth-party dependencies.
Incident Management Gaps
Lack of management visibility during incidents, unclear escalation paths, and poor coordination between technical teams and business leadership during crisis situations.
"DORA failures typically expose operational fragility rather than missing security controls. Organizations may have extensive control frameworks that look comprehensive in steady-state but cannot deliver resilience under pressure."
These patterns share a common theme: the gap between documented capabilities and operational reality. Addressing them requires moving beyond compliance checkboxes to genuine resilience validation through testing, incident response experience, and continuous improvement.
Using the DORA Lens Effectively
Practical Applications
The DORA Lens provides a structured approach to evaluating and communicating operational resilience across your organization. Use this framework to bridge the gap between technical security capabilities and business resilience outcomes that matter to executives, boards, and regulators.
Assess Operational Resilience
Evaluate resilience across critical services and business functions, identifying gaps between documented controls and operational reality
Prepare for Supervisory Review
Develop evidence-based responses to regulatory inquiries and supervisory assessments with clear linkages to DORA requirements
Align Governance Structures
Integrate security, business continuity, and third-party risk management into a coherent resilience governance framework
Executive Communication
Explain resilience posture to senior management and boards using business outcomes rather than technical controls
The Essential Question
Can you keep operating when ICT fails?
This question sits at the heart of DORA. The lens helps you answer it with evidence, testing results, and demonstrated capabilities-not assumptions or documentation.

Created by Claudiu Tabac — © 2026
This material is open for educational and research use. Commercial use without explicit permission from the author is not allowed.