Cloud and security · Banking
Disaster recovery and business continuity for financial systems
We design and test disaster recovery and business continuity for financial systems: recovery objectives set by business impact, architectures from backup and restore to active-active, consistent replication of ledgers and messages, payment flows that survive failover without double processing, and failover tests that prove the plan works. The bank knows how long it can be down and demonstrates it, and you own the runbooks and the code.
Checklist · Cloud and resilience
Cloud migration and resilience checklist for regulated firms
A checklist for regulated firms planning a cloud migration, a resilience programme or a security uplift: workload assessment, landing zone, data residency, resilience, security, delivery, third-party risk and evidence.- 01Eight areas that supervisors and auditors ask about, with testable checks.
- 02Resilience and recovery items that are easy to leave untested.
- 03Third-party, exit and data residency questions for the board.
- 04Seven questions to put to any vendor or engineering partner.
Free download
Get it on screen in a few seconds.
What the system does, module by module.
- 01
Business impact and tolerance
Identification of important business services and the maximum tolerable disruption for each, set with the business and agreed by management. - 02
Dependency mapping
Mapping of each service to the applications, data, networks, third parties and people it depends on, so recovery plans cover the whole chain. - 03
Recovery objectives
Recovery time and recovery point objectives per service, with the cost of each option, so the design matches the need and not a blanket rule. - 04
Resilient architecture patterns
Backup and restore, pilot light, warm standby and active-active designs chosen per service, across zones and regions as required. - 05
Data replication and consistency
Synchronous and asynchronous replication of databases and queues, with decisions on data loss and consistency across systems that must agree. - 06
Payment and transaction continuity
Idempotent processing, replay of in-flight messages and reconciliation after failover, so no payment is lost or processed twice. - 07
Failover and failback automation
Automated, rehearsed runbooks for failover and for returning to normal, with decision points and the controls to avoid split-brain. - 08
Testing programme
Scheduled component, application and full-service failover tests, severe but plausible scenarios, and measured results against objectives. - 09
Cyber and third-party scenarios
Recovery from ransomware and destructive attacks, and from the failure of a critical provider, with the alternative arrangements tested.
Reference architecture.
Standards and interfaces
What we design against.
- BCBS Principles for Operational Resilience
- The Basel Committee's principles on governance, mapping of critical operations, tolerance for disruption, testing and incident management.
- Supervisory operational resilience rules
- National and regional requirements on important business services and impact tolerances, such as those of the UK authorities, and DORA in the EU.
- ISO 22301
- Business continuity management systems standard for policy, planning, exercises and improvement.
- ISO/IEC 27031
- Guidelines for ICT readiness for business continuity.
- Payment system continuity requirements
- Rules of payment systems and schemes on availability, contingency and recovery for participants.
- Cloud provider resilience guidance
- Provider architecture guidance on zones, regions and shared responsibility for resilience.
Data model
The core entities.
- Important business service
- Description, owner, impact tolerance, dependencies and recovery strategy.
- Dependency
- Application, data store, network, provider or person, and the services it supports.
- Recovery objective
- RTO, RPO, tier, design pattern and the cost of the chosen option.
- Runbook
- Steps, roles, decision points, last review and last execution.
- Replication status
- Source, target, lag, consistency checks and alerts.
- Test and result
- Scenario, scope, measured recovery time and data loss, issues found and actions.
- Backup and restore verification
- Dataset, immutability status, last restore test and outcome.
When custom development is the right call.
Controls designed in, not added later.
Isolated recovery data
Backups are immutable and separated from production credentials, so an attacker who controls production cannot erase recovery.Access during failover
Emergency access is controlled, logged and time-limited, and does not weaken the security of the secondary site.Consistent security at the secondary site
The secondary environment has the same controls, patch level and monitoring as the primary.Decision authority
Who may declare a disaster and trigger failover is defined, with the decision recorded.Evidence of testing
Test plans, results and fixes are retained for management, audit and supervisors.
From discovery to a system you run.
- 01
Services, tolerances and dependencies
We identify the important services, agree tolerances with the business and map their dependencies end to end. - 02
Gap assessment and design
Current recovery capability is measured against the tolerances, and designs and costs are agreed per service. - 03
Build replication and automation
Replication, secondary environments and failover automation are built, starting with the most critical services. - 04
Test and fix
Component, application and full-service tests are run, measured against objectives, and weaknesses are fixed and retested. - 05
Operate the programme
Tests, reviews and reporting run on a cycle, and changes to systems trigger updates to the plans.
Relevant work
Where to see our work.
Common questions.
- How do you decide between active-active and backup and restore?
- By the service's impact tolerance and the cost of each option. Active-active suits the few services where minutes matter. Warm standby or restore from backup is enough for many others. We cost each choice so the decision is made on evidence.
- How do you avoid double payments after a failover?
- Every payment has a unique reference, and processing is idempotent. After failover, in-flight messages are replayed against that reference and reconciled with the scheme and the ledger, so none is lost or repeated.
- How often should we test?
- Component-level recovery tests run continuously or frequently, application failover tests regularly, and full-service tests at least annually, with extra tests after significant change. The programme is risk-based and agreed with risk and audit.
- Does cloud make disaster recovery easier?
- It makes building a secondary environment much easier and cheaper. It does not remove the need to design for consistency, test failover and plan for provider failure.
- Who owns the runbooks and automation?
- You do. The runbooks, the automation and the test records stay yours.