Cloud: How to Approach ‘Exit Management’ Compliance

‘Exit Management’ is a phrase becoming more familiar to regulated enterprises looking at regulatory compliance for public cloud. The term appears in guidelines like the UK’s FCA Cloud Guidelines 16/5 and the current consultation on outsourcing to cloud from the European Banking Association (EBA) and the principle is echoed in OCC Bulletins 2013-29 & 2017-7 as well as FFIEC Appendix J. None of the regulators provide much in the way of detail but they are asking FIs to be able to have test plans in place and the EBA is asking the FIs to show a set of key risk indicators which could trigger an exit. For many banks, in particular, Exit Management is becoming a major planning bottleneck for cloud strategies involving migration of material workloads and sensitive data.

Stay current on your favourite topics


What is Exit Management?

Simplistically, Exit Management means the complete withdrawal of one or more workloads from a specific cloud service. The inference is that the workload will migrate to another cloud provider or back in-house.

Exit Management is not the same as Availability Management, Disaster Recovery or BCP but should be treated as an extension of those disciplines (see table 1). The expectations are that Exit Management represents a more graceful exit, possibly within a 90-day timeframe and be triggered by a change in risk posture with the provider based on things like bankruptcy, service decline or cyber-related issues.

Key Risk Indicators

So what would trigger a firm to change its risk posture enough to warrant a full exit from a cloud provider? The EBA cloud consultation expects FIs to “develop key risk indicators that should identify unacceptable level of services”. We include a structure in table 2 below to help FIs respond to this request.

Solutions for Exit Management

Stay current on your favourite topics


The big question is how you solve for Exit Management and whether the regulators buy it. Recreating compute environments in different vendors or in an internal VMWare stack is relatively trivial but the problem becomes complex when needing to replicate large amounts of data (see Ian Tivey’s blog on Data Gravity) or using more proprietary stacks including PaaS, FaaS (function as a service) and SaaS services. How simple is it to recreate an HDInsight environment in AWS or how do you replicate workloads exploiting Lambda into Azure?

These issues are stalling the use of PaaS services for critical workloads in banking and causing big investments in multi-cloud capabilities. Table 3 outlines 4 different approaches being pursued in the industry.


The regulators are savvy to Exit Management being one of the primary challenges for FIs moving to public cloud. For simple workloads with reasonable amounts of data, the problems are solvable today with multi-cloud broker capabilities. For larger data movement, many firms are turning to colo providers with proximity relationships to the main cloud providers. Longer term, for more complex applications and true cloud native architectures exploiting PaaS and function as a service, we will need to see industry evolution around edge services or different service providers hosting full-service stacks from Azure, AWS and Google.

In the meantime, we recommend that FIs start to mature their Exit Management practices including KRI measurement, testing and decision governance (the decision to trigger an exit will likely be complex and cover multiple KRIs).

Would you like to know more about our work?

The author

Jim Oulton

Jim Oulton

Associate Partner, London

Jim is an accomplished distributed infrastructure specialist with almost 20 years’ experience with some of the most challenging application platform environments in financial services. He has enjoyed success on a variety of roles with Citihub Consulting, which have called on him to demonstrate a versatile blend of technical, commercial and organisational skills.