Cloud and security · Banking
Core banking and payments cloud migration
We plan and carry out core banking and payments cloud migration for banks and payment firms: assessment of workloads, a secure landing zone, phased migration with data and cutover rehearsals, resilience designed for the criticality of the services, and the exit plans and evidence that supervisors expect. Critical systems move without a leap of faith, and you own the infrastructure code and the runbooks.
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
Workload assessment and strategy
Classification of each system by criticality, data sensitivity, latency needs and dependencies, with a recommendation to rehost, replatform, refactor, retain or retire. - 02
Landing zone and guardrails
A secure multi-account foundation with identity, networking, logging, encryption and policy controls set before any workload arrives. - 03
Network and connectivity
Private connectivity to data centres, payment networks and partners, segmentation between environments and controlled internet access. - 04
Data migration and residency
Phased movement of databases and files with replication, validation and reconciliation, and placement of data in the regions that law and policy permit. - 05
Resilience architecture
Multi-zone and, where required, multi-region designs with recovery objectives matched to each service, tested before go-live. - 06
Security and key management
Identity and privileged access, encryption with customer-managed keys, secrets handling, vulnerability management and security monitoring integrated with the bank's operations. - 07
Platform engineering and automation
Infrastructure defined as code, repeatable environments, automated deployment and configuration, and a platform that application teams can use safely. - 08
Cutover and parallel run
Rehearsed cutover plans with rollback, parallel runs with reconciliation and a clear decision point for each step. - 09
Third-party risk, exit and evidence
Exit strategies and tested portability, concentration risk analysis, and the documentation and evidence for regulators, auditors and the board.
Reference architecture.
Standards and interfaces
What we design against.
- Supervisory outsourcing and cloud guidance
- For example HKMA guidance on outsourcing and technology risk management, the EBA outsourcing guidelines, DORA for EU institutions and MAS technology risk guidelines, which set expectations for due diligence, controls and exit.
- ISO/IEC 27001, 27017 and 27018
- Information security management and cloud-specific controls, including protection of personal data in public cloud.
- CSA Cloud Controls Matrix
- A cloud security control framework used to assess providers and design shared responsibilities.
- PCI DSS 4.0.1
- Requirements for cardholder data environments in cloud and hybrid designs.
- Well-architected frameworks
- Reliability, security, performance, cost and operational excellence principles from the major providers, applied as design reviews.
- Data protection and residency law
- Rules on where personal and banking data may be stored and accessed.
Data model
The core entities.
- Workload
- System, owner, criticality, data classes, dependencies and migration strategy.
- Environment and account
- Purpose, region, network, owner, guardrails applied and cost centre.
- Migration wave
- Workloads, plan, rehearsals, readiness criteria, cutover date and outcome.
- Control and evidence
- Requirement, control, test, result and the evidence file.
- Recovery objective
- Service, RTO, RPO, design, last test and result.
- Provider dependency
- Service, provider, criticality, concentration, exit plan and test.
- Risk and exception
- Description, owner, mitigation, approval and expiry.
When custom development is the right call.
Controls designed in, not added later.
Identity first
Strong identity, least privilege and just-in-time privileged access across the cloud estate, integrated with the bank's directory.Customer-managed encryption
Encryption at rest and in transit with keys controlled by the bank, and separation of duties for key management.Guardrails as code
Policy that prevents insecure configuration, such as public storage or unencrypted databases, enforced automatically.Central logging and detection
Logs from every account and service into the bank's security operations, with detections tuned to the cloud.Tested resilience and exit
Recovery and exit procedures are exercised, and the results reported to risk and supervisors.
From discovery to a system you run.
- 01
Assessment and strategy
We inventory workloads, dependencies, data and regulatory constraints with architecture, risk and operations, and agree the target model and sequence. - 02
Landing zone and controls
The secure foundation, connectivity and monitoring are built and tested, and the control evidence is prepared for risk and supervisors. - 03
Pilot workload
A low-risk workload moves first, proving the foundation, the migration tooling and the operations model. - 04
Migrate in waves
Workloads move in waves with rehearsals, parallel runs and reconciliation, with the most critical services after the practice is proven. - 05
Operate, optimise and exit-test
Operations, cost and resilience are tuned, and exit and recovery plans are tested on a schedule.
Relevant work
Where to see our work.
Common questions.
- Will our supervisor allow core banking in the cloud?
- Supervisors in most jurisdictions permit it with conditions: due diligence on the provider, strong controls, tested resilience, exit plans and notification or consultation for material arrangements. We prepare the evidence and support your discussions with the supervisor.
- Do we have to move everything?
- No. A hybrid estate is normal. We recommend per workload, and often start with channels, data platforms and development environments before the ledger.
- How do you avoid lock-in to one cloud provider?
- By using open standards where they matter, containerised workloads, infrastructure code that is portable in design, and an exit plan that is tested, including for the services that cannot be made fully portable.
- How do you keep a payment system running during migration?
- By running old and new in parallel, replicating and reconciling data, rehearsing cutover and having a defined rollback, so the decision to switch is based on evidence.
- Who owns the infrastructure code and runbooks?
- You do. The code, the runbooks and the documentation stay yours.