Operational resilience is no longer a compliance exercise. It is a delivery challenge.
The Digital Operational Resilience Act (DORA) sets a clear expectation: financial institutions must be able to withstand, respond to, and recover from Information and Communication Technology (ICT) disruption without impacting critical services. Under PRA, FCA, and ECB scrutiny, failure is not theoretical, it has regulatory, financial, and reputational consequences.
DORA introduces a unified framework across the EU, but most organisations are not starting from a clean slate. They are layering DORA requirements onto complex estates, fragmented governance, and programmes already under pressure.
This is where most firms struggle.
DORA is not difficult to understand. It is difficult to implement at scale, under pressure, across business and technology.
Brickendon is typically brought in where that gap exists; when delivery risk is high, timelines are fixed, and internal capability is stretched.
DORA requires firms to establish a robust, enterprise-wide ICT risk framework. In practice, most organisations already have one. The issue is that it is fragmented, inconsistently applied, or disconnected from delivery.
The challenge is not defining risk: it is embedding it into how programmes are actually run.
Effective implementation requires clear ownership, integration into governance, and alignment with real delivery activity. Where this is missing, risk frameworks become documentation exercises rather than operational controls.
This is a common failure point in programmes we are asked to stabilise: where risk exists on paper but not in execution
DORA introduces strict expectations around incident detection, classification, and reporting timelines.
Most organisations underestimate the operational impact of this. The challenge is not reporting, it is having the systems, processes, and governance in place to identify, assess, and escalate incidents quickly and consistently.
In high-pressure environments, delays in classification or escalation are common, particularly where accountability is unclear.
Programmes that succeed treat incident management as an operational capability, not a compliance requirement: integrated into delivery, with clear ownership and rapid decision-making.
Testing under DORA goes beyond standard assurance activity. It requires structured, scenario-based validation of resilience, including threat-led penetration testing for critical services.
The failure point here is execution. Testing is often treated as a periodic activity rather than a continuous input into programme delivery.
Results are documented but not acted on with sufficient pace.
In practice, effective resilience testing requires tight integration with delivery teams, rapid remediation cycles, and clear accountability for outcomes. Without this, testing highlights issues but does not reduce risk.
Third-party dependency is one of the most significant sources of operational risk in modern banking.
DORA formalises expectations around due diligence, contractual controls, monitoring, and exit planning. However, most organisations already struggle with visibility and control across their third-party landscape.
The issue is not awareness: it is execution.
We regularly see programmes where third-party risk is understood but not actively managed, particularly under time pressure. This creates exposure at the exact point where resilience is most critical.
Effective delivery requires third-party risk to be treated as a core part of the programme: not a parallel activity.
DORA encourages structured information sharing across institutions and regulators to strengthen collective resilience.
In reality, organisations are cautious, and sharing is often limited or inconsistent.
The challenge is balancing transparency, regulatory expectations, and data protection constraints, while ensuring that intelligence is actually used to improve resilience.
This is less a technical problem and more a governance and cultural one.
This is where most DORA programmes succeed or fail.
DORA places clear accountability on senior management for ICT risk and operational resilience. However, in many organisations, accountability remains diffused across functions.
Governance structures exist, but decision-making is slow, fragmented, or unclear.
This is a consistent pattern in underperforming programmes. Resetting governance, clarifying ownership, simplifying decision-making, and aligning business and technology: is often the single biggest driver of recovery.
Most institutions have BCP and DR frameworks in place. Under DORA, the expectation is that these are not only documented, but tested, current, and aligned to critical services.
The gap is typically between design and reality.
Plans exist, but are not operationally embedded. Testing is infrequent or superficial. Recovery capabilities are assumed rather than proven.
In high-risk environments, this is not sufficient. Resilience must be demonstrated, not described.
Training is often treated as a compliance requirement: completed, tracked, and reported.
In practice, resilience depends on how people behave under pressure.
Organisations that perform well invest in scenario-based training, simulations, and clear role definition for senior stakeholders. Those that do not tend to expose gaps during real incidents.
DORA introduces ongoing regulatory engagement, reporting, and scrutiny.
Most organisations focus on demonstrating compliance. The stronger ones focus on being able to evidence control: consistently, under pressure.
The difference is material.
Programmes that fail tend to prepare for audits. Programmes that succeed build audit readiness into day-to-day delivery.
Financial entities must comply with DORA requirements and cooperate with regulatory authorities. Key aspects within this requirement are:
| Regulation | Description |
| GDPR (General Data Protection Regulation) | Ensure financial institutions protect personal data and handle breaches properly, which overlaps with DORA’s ICT risk management and incident reporting requirements. |
| NIS2 (Network and Information Security Directive 2) | Establishes stricter cybersecurity standards for critical infrastructure, complementing DORA’s focus on digital resilience and third-party risk management. |
| PSD2 & PSD3 (Payment Services Directive 2 & 3) | Regulates digital payments and cybersecurity measures for financial services, ensuring alignment with DORA’s ICT security requirements. |
| Solvency II & Solvency II Review | Governs the risk and capital requirements of insurance companies, integrating operational risk considerations that overlap with DORA’s resilience requirements. |
| Basel III / CRD VI (Capital Requirements Directive VI) | Provides financial risk management guidelines, requiring banks to integrate operational resilience into their risk frameworks, aligning with DORA’s principles. |
| EBA, EIOPA, and ESMA Guidelines | The European Supervisory Authorities (ESAs) issue technical standards and guidelines, ensuring financial entities align their ICT risk management and outsourcing practices with DORA’s framework. |
DORA introduces a supervisory framework for critical third-party ICT service providers.
DORA’s operational resilience requirements are comprehensive and aim to ensure that financial entities can maintain continuity of services in the face of ICT-related disruptions. By focusing on risk management, incident reporting, testing, third-party oversight, and governance, DORA enhances the resilience of the financial sector. Financial entities must adopt a proactive and holistic approach to meet these requirements and ensure compliance.
This increases the complexity of managing third-party relationships, particularly where providers operate across multiple jurisdictions and regulatory regimes.
Financial institutions remain accountable. Reliance on third parties does not transfer responsibility.
This is a growing area of delivery risk, particularly in large-scale transformation programmes.
DORA is comprehensive, but the underlying challenge is not regulatory interpretation. It is execution.
Most organisations are attempting to deliver DORA alongside other major programmes, regulatory change, technology transformation, cost reduction. This creates competing priorities, resource constraints, and delivery risk.
This is typically when Brickendon is engaged.
We are brought in when programmes are under pressure, off-track, or too critical to fail. Our role is to take full accountability, stabilising delivery, resetting governance, and driving execution through to completion.
Brickendon is a specialist consulting firm focused on the delivery and recovery of complex programmes.
We work with Tier 1 banks and financial institutions where delivery risk is high, timelines are fixed, and failure is not an option: often under PRA, FCA, and ECB scrutiny.
We do not use leveraged teams. Every engagement is delivered by senior operators with deep experience in banking, regulation, and programme delivery.
Our focus is simple: take accountability, restore control, and deliver outcomes.
f your DORA programme is:
Then the risk is not compliance, it is delivery.
Brickendon supports organisations in delivering and recovering complex regulatory programmes, end to end.
Confidential. No obligation. Senior conversation from day one.: [email protected]
Sources: