Operational Resilience and DORA Compliance: Beyond the Checkbox
Operational resilience isn't a compliance exercise. It's an engineering discipline. DORA has been live since January 2025. The UK's operational resilience framework required firms to be operating within impact tolerances by March 2025. Regulators are now examining whether your resilience is real or performative.
I'm Abdul Baruwa, founder of kaano.io. I build and operate critical financial technology — CHAPS and BACS payment systems, insurance underwriting platforms, claims processing engines. Systems where downtime isn't an inconvenience. It's a regulatory event.
Most DORA compliance consultants come from a risk and governance background. They'll map your important business services, define impact tolerances, and produce documentation that satisfies the immediate regulatory ask. That's necessary. But it's not sufficient.
Real operational resilience lives in your architecture, your deployment pipelines, your incident response, your data recovery, and your third-party dependency management. It's engineering work. That's what kaano.io brings.
Why Operational Resilience Is an Engineering Problem
Scenario Testing Exposes Architectural Gaps
When you simulate a cloud provider outage or a critical vendor failure, the questions become technical: Can your system failover? How fast? What data do you lose? Can your team actually execute the recovery runbook, or was it written by someone who's never touched production?
Third-Party Risk Is a Technology Problem
DORA's ICT third-party risk management requirements force you to understand — at an architectural level — how your critical vendors' systems connect to yours, what happens when they fail, and whether your contracts actually give you the exit options you need.
Incident Response Isn't a Document
DORA requires ICT incident classification, reporting within tight timeframes, and root cause analysis. If your incident response is a PDF in SharePoint, you'll fail the first real test. You need automated detection, structured classification, and rehearsed response — built into your operations, not bolted on.
Our Approach
I work at the intersection of regulation and engineering. My approach starts with what the regulators require and builds the technical reality to meet it.
Assessment: Where You Actually Stand (2–3 weeks)
I review your important business service mappings, impact tolerances, and current resilience posture — then test them against your actual architecture. Not your architecture diagrams. Your running systems. The output is an honest gap analysis that tells you what's real and what's theatre.
Architecture: Building Genuine Resilience (4–8 weeks)
For each gap, I design practical solutions. Failover architectures. Data recovery strategies. Third-party contingency plans. Monitoring and alerting that actually detects degradation before it becomes an outage. Everything is sized, prioritized, and mapped to specific DORA articles or PRA/FCA requirements.
Implementation Support: Making It Real (ongoing)
I work alongside your engineering teams to implement resilience improvements. I review code, challenge deployment strategies, design chaos engineering tests, and help you build the muscle memory that makes resilience operational rather than theoretical.
Who This Is For
- Heads of Operational Resilience at UK-regulated financial institutions who need technical depth behind their compliance frameworks
- CTOs and Engineering Directors who know their resilience documentation doesn't match their architectural reality
- Compliance teams preparing for PRA/FCA supervisory reviews or DORA examinations who need someone who can translate between regulatory language and engineering action
- Insurance firms and MGAs subject to Solvency II operational resilience expectations and increasingly exposed to DORA through group-level requirements
- Payment service providers where a single outage can trigger regulatory scrutiny and reputational damage
What You Get
| Deliverable | Detail |
|---|---|
| Resilience gap analysis | Assessment of current operational resilience posture against DORA articles and UK PRA/FCA requirements — tested against actual architecture, not documentation |
| Scenario testing design | Realistic failure scenarios mapped to your important business services, with expected outcomes and pass/fail criteria |
| Resilience architecture | Specific technical designs for failover, recovery, monitoring, and third-party contingency — prioritized by regulatory risk |
| ICT incident response framework | Classification taxonomy, reporting workflows, escalation paths, and tooling recommendations aligned to DORA reporting timelines |
| Third-party risk assessment | Architectural analysis of critical ICT third-party dependencies with concentration risk identification and exit strategy options |
| Implementation roadmap | Phased delivery plan with regulatory milestone alignment and effort sizing |
Why kaano.io, Not a Big Four
The large consultancies will sell you a framework. Frameworks are useful. But when the regulator asks "can you actually recover this service within your impact tolerance?" — the answer is in your infrastructure, not your framework.
I build the systems that operational resilience frameworks are supposed to protect. Payment processing. Insurance platforms. Event-driven architectures. I know what breaks, why it breaks, and how to design systems that degrade gracefully instead of failing catastrophically.
Operational resilience from someone who operates.