Given today’s geopolitical rockiness and its instant ripple effects worldwide, many companies are deciding they can’t afford to be locked into services from a cloud vendor . Financial institutions in Europe, moreover, are legally required to prove that they can end their contracts with service providers for critical functions.
Planning an exit for financial companies and other organizations handling sensitive and high-volume workloads is complex. Doing so without interrupting business continuity adds to that complexity. But in offering cloud exit as a service (CEaaS for short), Schuberg Philis strategizes this dimension of the digital transformation and makes it stress-free.
Risk appetite and fine print
Whether a customer will one day quit its contract with its public cloud or that relationship will last a lifetime, our CEaaS hinges on our customer’s risk appetite. The starting point therefore is asking which services are essential for their operational continuity, value generation, and reputational health and determining what the associated risk appetite is. This approach is comparable to how we understand any other dimension of an organization: by listening to the IT questions while responding to them with business-bettering solutions.
After determining what would make our customers feel most comfortable in an exit scenario, we ensure they also have what they need for an exit – be it eventual or hypothetical. We see it as our duty to guide customers into compliance. Since the European Commission provisionally agreed on the Digital Operational Resilience Act (DORA) in May 2022 and it is expected to go into force by early 2023, banks and other financial organizations in Europe will soon have no choice but to prepare a plan. As DORA article 25.9 specifies: “Financial entities shall put in place exit strategies in order to take into account such risks that may emerge at the level of ICT third-party service provider .” And “Exit plans shall be comprehensive, documented and in accordance with the criteria referred to in Article 3a(2), sufficiently tested and reviewed periodically.”
Besides planning, we read the fine print, interpret it, and advise on taking action accordingly. To illustrate, we may have a customer who uses a public cloud service from an American US-headquartered company with datacenters in the EU. Our customer might have specifically elected to enter into its contract with the EU-based datacenters, ensuring that European law scopes over its agreement and thereby mitigates major risks that contracts under US law would be subjected to. However, because the cloud provider is an American company, there is never 0 risk. In such a scenario, if our customer decided to be totally risk-averse, we would advise their exit to a fully EU-located and EU-owned datacenter; if they had a less cautious appetite, we might advise migrating all mission-critical workloads to a local datacenter while still exploiting the American cloud provider’s breadth of readily available, affordable, innovative features for less critical workloads. That said, should another customer choose to migrate their mission-critical workloads to the public cloud of an American-headquartered company, there are viable risk-mitigating strategies that we can advise.
The strategy document
An important piece of our CEaaS is a document strategizing the customer’s exit. In concrete terms this outlines multiple possible reasons for, timelines to, and scopes of ending a relationship with a cloud vendor. Scenarios could range from a company needing to make what would be considered a graceful exit or, at the other extreme, an emergency exit. An example of the former is a company migrating over the course of nine months to another provider that offers a feature the current vendor does not. An example of the latter, albeit unlikely, is a swift move executed within a matter of days because a geopolitical event has led to a compromised digital environment.
Regardless, the strategy document details all the considerations that need to be made in designing an exit as well as the actual choices to be made upon an actual exit . Thus, we define functional and nonfunctional requirements, such as which cloud/s to involve, what to include and exclude in the scope, how to perform the exit, and whom to inform about the exit. Technical points include whether there would need to be network parts running on a different platform, user authentication, role-based access, use of hardware, a container service, or a dedicated connection from an own-premises datacenter directly to the cloud.
It should be noted, too, that while Schuberg Philis is hands-on in co-developing this plan, the customer ultimately sets the requirements and parameters. They remain the rightful owners of their own exit strategy and related documentation.
Testing, testing
Drills are fundamental to digital resilience, so testing is built into all our customer agreements. Testing the exit strategy verifies that an actual exit can occur within the right scope and the right amount of time. It ensures our high availability works, including when the auditor comes in and checks it . It also assures stakeholders, showing them just how the company can migrate a workload from one service provider, spin it up within a reasonable amount of time, have it run in another service provider, and function as it should. Because our strategy has been tested and approved by our customer’s business department, we know it is as functionally sound as it is technically sound.
We make a clear distinction between a tabletop assessment and technical testing. The tabletop assessment is meant to verify if techniques are available in the cloud to where a company will migrate or if the hardware complies with certain frameworks. Technical testing entails functionally proving that the workload can run on another cloud. It includes designing, implementing, commissioning, decommissioning, and executing disaster recoveries based on the requirements. For customers who use our own private cloud, sbp.cloud, testing is especially easy because we are dealing with our own hardware under our own control, the location and workloads of which we well know.
By running an exit test every year we can improve the exit strategy as a whole. The code stays intact, with each iteration presenting an opportunity to enlarge the scope. Since it is fully automated and deployed by code, it is reusable and easily expandable.
Intimacy and moving on
As a cloud-agnostic IT partner, we have running contracts with Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform. On behalf of our customers, we therefore handle the agreements and cloud financing, an activity that can otherwise prove to be a big hassle for small-use testing setups. Moreover, we free them from having to spend a lot of time and energy navigating what the public clouds can offer in the first place. That’s because we’re intimately acquainted with their services and stay up-to-date with features. At the same time, we can spare our customers from a vendor lock-in that doesn’t gel with their risk appetite.
So while an exit strategy may be implemented to satisfy risk appetite or abide by DORA rules, CEaaS comes naturally to us. It corresponds to our commitment to enable customers to be highly resilient. Resilience entails giving financial institutions all they need to deliver fast and failure-proof service to their end users. It guarantees that if their cloud vendor, in particular, were to underperform or be impacted by a local or global threat, their exit plan would make moving to another cloud simple and stress-free.
Another crucial component of exit is encouraging our customers and all their employees to embrace a flexible mindset. That manifests as moving technology with ease and exercising scaling capabilities when selecting another cloud provider. What’s more, it means not being excessively loyal toward technology choices or service providers – Schuberg Philis included. Inherent to our partnerships is the expectation that our customers continuously evaluate their relationship with us. And if ever they wish to leave our own cloud, we support them as they move onward. Indeed, we’ll give them nothing less than our 100% right through to their exit.
By Stefan Wessels Beljaars and Jos Vliegenthart