Cloud Exit Testing in Practice: A Phased Approach for Financial Institutions

The adoption of cloud technologies in the financial sector continues to accelerate, delivering significant benefits in terms of scalability, flexibility, and security. At the same time, regulatory requirements are becoming increasingly stringent – including DORA and the expectations of the ECB and the Central Bank of Hungary (MNB). As a result, financial institutions using public cloud services are required to have not only a documented cloud exit strategy, but also tested and executable exit plans for their critical systems.

Although many organisations have prepared these documents to meet regulatory requirements, the plans themselves often remain untested. Consequently, they provide only limited assurance that the proposed exit can be successfully executed in practice.

Challenges of Exit Testing

The purpose of testing is to provide the institution with sufficient assurance regarding its exit capabilities. However, both the development of an exit plan and its subsequent testing can encounter several obstacles:

• Unclear regulatory expectations: Regulators do not explicitly specify what level of testing is considered sufficient for different types of systems.

• Defining the exit scope: Ideally, the exit plan should be developed during the system design phase. However, determining its scope can be complex. Which parts of the system should be tested, and to what depth, particularly when the system may continue to evolve during development?

• Lack of infrastructure: Depending on the organisation’s existing environment, preparing for the test may require a significant infrastructure development project before the test itself can be performed.

• Resource constraints: The resources required to conduct the test must not compromise the operation and availability of production systems.

Phased Exit Testing

To address these challenges, we apply a phased approach, gradually expanding both the scope and the range of activities to be performed.

• Strategy, planning and scope definition: In this phase, we assess the financial institution’s exit maturity. We review the existing workloads, technologies and architectural constraints that determine the available exit options. Based on this assessment, we design the target architecture and develop both the exit plan and the implementation plan. The availability of resources, the system components to be tested, the target infrastructure, and the volume and quality of the data all influence the scope.

• Implementation and execution: The selected test scope may require the target infrastructure to be established before testing can begin. If the financial institution already has the necessary technological prerequisites in place, the test can be executed directly in accordance with the exit plan.

• Documentation and scalability: Test reports are prepared, and supporting tools and templates are provided to facilitate future exit planning and testing activities. The objective is to make the test easy to repeat and extend over time.

A phased approach enables organisations to respond to regulatory expectations more quickly while establishing repeatable processes that can evolve alongside their systems. It also increases confidence in real-world exit scenarios and gives the teams involved valuable practical experience that can support the successful execution of an actual exit, if required.

Our Project Experience

In our work with financial institutions, we have repeatedly encountered situations in which organisations had exit plans in place for their critical systems, but had not yet tested their practical execution. Regulatory requirements and preparations for audits often make it necessary to determine, within a short timeframe, the potential exit route for systems running in the public cloud, the technologies that could replace the existing solutions, and the appropriate scope and depth of testing.

As a first step, institutions typically include only the components essential to business operations in the test scope. Testing is generally performed in a non-production environment using test data. Designing the target architecture and establishing the necessary infrastructure often require the involvement of external technology partners. Since building the infrastructure is usually the most time-consuming and costly part of the process, it is advisable to conduct a tabletop exercise in parallel.

Tabletop exercises can identify areas requiring refinement in both the exit plan and its implementation before technical execution begins. They also help assign responsibilities and clarify the steps and dependencies involved in the process. The resulting test report can provide tangible evidence during an audit that the institution not only has a documented plan, but has also begun validating it in a structured manner. This reduces regulatory risk and lays the groundwork for subsequent testing using data in an actual technology environment.

Key Takeaways

• Exit testing does not necessarily need to be carried out as a traditional waterfall project. An iterative approach enables the organisation to respond more quickly and flexibly.

• Identifying the technologies supporting critical functions at an early stage is essential, as they have a significant impact on the scope of exit testing.