With cloud adoption on the rise in the banking sector, operational resiliency is under the spotlight. Banks and financial authorities alike are keen to ensure the transition to cloud is secure and doesn’t harm customers or result in disruption.
Public cloud use is inherently reliant on third party cloud providers. In the UK, the Financial Conduct Authority (FCA) considers this use of cloud services a form of outsourcing. It has strict rules surrounding arrangements of this nature when they’re used to deliver important business functions:
“We expect your firm to be operationally resilient by having a comprehensive understanding and mapping of the people, processes, technology, facilities and information necessary to deliver each of your important business services. This includes people and other dependencies such as third parties. Your firm should assess the risks and controls in place to ensure it is operationally resilient.”
It’s not just UK-based banks and authorities that are alert to this matter. At a global level, banking organisations are increasingly asking ‘how do I go multi-cloud?’. This is rarely due to limitations or issues with their current cloud provider. Rather, it’s seen as an insurance policy to ensure resilience if something goes wrong.
Sometimes the worst does happen. In the UK when UKCloud was placed into compulsory liquidation we were called on to help a public sector client move to a new provider at very short notice. While this is unlikely to happen to Amazon Web Services (AWS), Azure, or Google Cloud, there could be other situations that demand a sudden exit. These might include a cloud provider’s launch of a competitive banking offering, new regulatory requirements, or a conflict of interest that cannot be resolved.
European Banking Authority Guidance on Cloud
The European Banking Authority (EBA) has published detailed recommendations on outsourcing to cloud providers. Its guidance specifically refers to a bank’s ability to exit such arrangements if necessary “without undue disruption to its provision of services or adverse effects on its compliance with the regulatory regime and without detriment to the continuity and quality of its provision of services to clients”.
EBA makes three key points in relation to this, suggesting that any bank using a third-party cloud provider should:
- Develop and implement exit plans that are comprehensive, documented and sufficiently tested where appropriate;
- Identify alternative solutions and develop transition plans to enable it to remove and transfer existing activities and data from the cloud service provider to these solutions in a controlled and sufficiently tested manner, taking into account data location issues and maintenance of business continuity during the transition phase;
- Ensure that the outsourcing agreement includes an obligation on the cloud service provider to sufficiently support the outsourcing institution in the orderly transfer of the activity to another service provider or to the direct management of the outsourcing institution in the event of the termination of the outsourcing agreement.
While these guidelines have been prepared with European banking in mind, the principles are relevant to banks operating in any part of the world. The Federal Financial Institutions Examination Council (FFIEC) in the US published a statement on risk management for cloud computing services which says inherent risks should be comprehensively evaluated, with control mechanisms clearly identified and residual risks at acceptable levels. More specifically, it states that financial institutions should have in place “an exit strategy and de-conversion plan or strategy for the cloud services.” Australia and other regions have similar recommendations in place or under development.
How to Devise a Cloud Exit Strategy
So, what actions should a bank take to ensure it can move to an alternative cloud provider quickly and seamlessly should the need arise?
The first step is to understand exactly what a cloud exit strategy would entail based on the systems required to serve customers and operate the business. This involves a thorough review of the systems in use, and their reliance on outsourced providers.
We’ve previously supported customers undertaking this process, working with them to identify workloads in scope, then determine components within each workload and any interfaces between them. From here, we look at finding alternatives to cloud-native products and services that would be covered by the exit strategy. For instance, if a bank is using AWS DynamoDB or Azure Cosmos DB, a suitable database-as-a-service offering from a third party might be identified. It may be advisable to migrate to this alternative service on a ‘just in case’ basis, refactoring tools and components so there would be limited disruption in the event of a wholesale exit from the current cloud provider.
Not all components will require a like-for-like replacement. Containers could run on either Azure AKS or AWS EKS, with minimal modification. However, where data is involved, thought must be given to how it is synchronised between clouds/locations. If key components are deployed using CI/CD tools, the easiest way to keep code in sync may be to retool and deploy to multiple cloud platforms.
Ten Factors to Consider
It’s not just workloads themselves that need to be considered when devising an exit strategy. Many factors must be accounted for in a multi-cloud context or a cloud-to-cloud migration:
- Security: How do you move data securely? How do you share secrets and identities between clouds?
- Logs: Where do you store logs? How do you write to them? How are you going to query them centrally?
- Monitoring: Can you (or should you) use the same monitoring services? Do you need to change installed agents? Do you need to open new firewall ports?
- Tagging: Does your tagging strategy need to be adopted to work on another cloud?
- Change management: What is the impact on your change management systems and processes? How will you ensure the change advisory board (CAB) understand this?
- Impact on developers: What will the change mean to the tools and systems used by your developers? What additional steps, tests, checks, and events will need to be created and included in your processes?
- Patching: How should you adapt your patching process? Can you use the same patching systems, or do you need to use an additional or replacement system? Can you meet (or potentially exceed) the same service level agreements (SLAs)?
- Security incident response: How can you respond to an incident in the new platform? If you use third parties, have you ensured they have the necessary access and tools for the new environment?
- Backups: What do you need to backup in the new cloud? What can you backup from one cloud to another? What implications will there be for transfer charges?
- Network connectivity: What connectivity do you need, from other clouds and other physical locations? What about internet access? How will you manage security and how will your monitor it?
This is not an exhaustive list, but it indicates the complexity of multi-cloud and cloud exit strategies. While a multi-cloud approach helps improve operational resilience in the banking sector, getting it right requires extensive cloud expertise.
Here at Sourced Group an Amdocs Company we’ve worked with banks all over the world, helping them adopt cloud at scale in a compliant manner. Find out about our governance and compliance services here. And check out some of our banking case studies here.
Greg is a Consultant at Sourced Group with over 20 years of industry experience. This has primarily been in the areas of infrastructure management, end-user compute, virtualization, databases, and cloud computing. Greg worked with end point management and on-premise virtualization for many years before moving on to helping customers move to, and adapt to the cloud. Greg is passionate about serverless, and also helping teams transition from legacy ways of working. Greg has also been recognised as an AWS Ambassador since 2021.
