A Cloud Service Provider Exit Strategy

The mergers and acquisitions of CSPs also lead to the potential need to move data from the cloud. The risk of financial instability for the provider should also be taken into consideration. Consequently, it is essential to consider the risk of supplier termination and how it could be formalized in an exit strategy to mitigate that risk. The following article will explore this topic. The article is divided into two parts: cloud solutions and what to be aware of in relation to software-as-a-service (SaaS) solutions.

Regulatory Background

Several regulations include content around the handling of suppliers and specifically the handling of data.

OECD

The Organisation for Economic Co-operation and Development (OECD) “Advisory Document on GLP & Cloud Computing – Supplement 1 to Document Number 17 on Application of GLP Principles to Computerised Systems” 1 contains the following text under section 5.3.3., Service Level Agreement (SLA): “Exit strategy: The SLA should clearly describe the test facility’s right to obtain all data and meta-data (including audit trails) in a readable and convertible format, in case the contract with the cloud service provider is terminated.”

US FDA and ISO

The US FDA’s 21 CFR part 11 2 focuses heavily on the integrity of cGMP data throughout its entire life cycle, which means a plan should be in place to repatriate data if there’s a possibility of the contract with a CSP terminating for whatever reason. Part 211.180(a)(b) of 21 CFR 3 requires that records be maintained for all components, drug product containers, closures, and labeling for at least one year after the expiration date. It is essential that data can be exported into a readable format under the appropriate controls to ensure data integrity. Similarly, 21 CFR part 820 4 and ISO 13485 5 require ongoing risk management where contract termination is a risk.

European Commission

The European Commission’s Annex 11 6 does not explicitly call out the need for an exit strategy in its guidance around suppliers and service providers. However, it does state that risk management should be applied throughout the life cycle of the computerized system, and this should consider patient safety, data integrity, and product quality. The termination of the contract with a service provider is a risk that should be considered.

Annex 11 Section 3.1

Section 3.1 states that a formal agreement must exist between the manufacturer and any third parties, and these agreements should include clear statements of the responsibilities of the third party. As one of the possible formal agreements, a quality agreement should cover all topics in accordance with a defined and established life cycle, such as how to export data when exiting the CSP.

Annex 11 Sections 7.1 and 17

Sections 7.1 and 17 cover requirements for data storage and archiving and require that access to data be ensured throughout the retention period. This will indirectly force the regulated company to be able to extract data as a part of the exit strategy.

Annex 11 Section 16

Section 16, Business Continuity, covers the availability of computerized systems that support critical processes. It states that provisions should be made to ensure continuity of support for those processes in the event of a system breakdown. Those provisions could include reverting to manual processes or making an alternative system available, or the same system available in an alternative location. The technical provision would be detailed in the application’s disaster recovery plan. The termination of the contract with a CSP would make the current solution unavailable and would trigger business continuity and disaster recovery plans.

Supplier Management

At the start of a supplier relationship, an exit strategy should be defined to ensure any needs will be included in the final contract, including addressing access to documentation after the exit has taken place. This ensures minimum business and customer disruption if the relationship is terminated and the ability to demonstrate compliance in inspections. The exit strategy should then be reviewed as part of the regulated company’s annual supplier reviews, or if there’s any other significant change in circumstances.

Where possible, an assessment or audit of the CSP and its quality and information management system should be conducted. This is to ensure that processes to provide support during an exit activity are in place and well implemented.

Contract

As with any contract, there are situations where either party may want to terminate the contract. From a CSP perspective, the only logical reason to terminate a contract is due to a breach of the customer agreement. For a customer, there are several reasons why you might want to end a relationship with a CSP. It could be some external influence that necessitates an exit, such as legal or regulatory changes. This decision could be related to the service, SLA, or finances.

Whatever the reason, the regulated company will usually have a period of time (stipulated in the clauses of the contract) to recover the content from the CSP before contract termination. The regulated company should assess the standard terms to determine if it includes sufficient time for them to recover their content and negotiate a change if required; for example, 30 days until all assets have been transferred.

Exit Strategy Components

As previously mentioned, the focus of exit strategies is ensuring that data can be retrieved from the CSP. Although the regulated company should certainly have business continuity plans and disaster recovery plans, from a regulatory perspective, the exit strategy should focus on the data. It should complement, but not duplicate, the business continuity and disaster recovery plans.

However, it is important to also note that the data must be readable. This may mean ensuring the application can be transferred so proprietary data can be read. The alternative solution is a validated migration of the data to an archive if that data is no longer actively used.

It should be highlighted that data includes all relevant metadata and audit trail information associated with the electronic records contained within the system. Special consideration may be required to ensure metadata and audit trail information remain readable and linked to the associated electronic record.

Furthermore, the CSP may have created records related to the installation of computer systems of qualification of the underlying infrastructure. The records must be accessible in a timely manner in case of an inspection.

When defining an exit strategy, it is important to apply a riskbased approach and critical thinking and to not overreact and overengineer a solution.

Risk Assessment

From a risk management perspective, the sudden termination of a contract with only 30 days to respond is unlikely but should still be considered in the exit strategy. The more likely trigger is a simple decision to change providers, in which case, the regulated company controls the timeline and the contract termination date.

When defining an exit strategy, it is important to apply a risk-based approach and critical thinking and to not overreact and overengineer a solution. For example, some interpret the need for an exit strategy as having another cloud provider waiting or having workloads spread across multiple providers, i.e., adopting a multicloud strategy. There are various reasons why a company may want to adopt a multicloud strategy, but the need for an exit strategy should not be one of them. However, if the regulated company already uses multiple CSPs, it can certainly leverage that as part of the strategy.

Trigger Scenarios

As mentioned, the trigger is either the CSP or the regulated company terminating the relationship, which results in either a short-term or long-term response. The following are some potential scenarios.

Long- or mid-term exit (more than six months of lead time):

• Exit CSP for strategic reasons (e.g., costs, performance, etc.)
• Exit CSP due to compliance or legal requirements (e.g., controls cannot be fulfilled)
• CSP terminates functionalities of individual cloud services (notice of deprecation)

Short-term exit (less than six months of lead time):

• Exit CSP due to infrastructure problems with the CSP (e.g., instability or network issues)
• Service termination initiated by CSP (proclamation)

Scenarios for long- or mid-term exits can be planned for ahead of time, and projected migrations of data and applications can be arranged on an individual basis. Data backup and configuration can be transferred at a specified time during the migration process. A data migration process should be managed and controlled within the quality management system (QMS) of the regulated company.

However, scenarios for a short-term exit might lead to sudden inaccessibility of the cloud services at a certain point of time, which is not under control of the regulated company. For these cases, it is essential to have a disaster recovery plan in place that employs techniques like frequent backups of relevant data. The topic of backup and restore is covered in other guidance, such as ISPE GAMP® 5: A Risk-Based Approach to Compliant GxP Computerized Systems (Second Edition), Appendix O9 7.

Another scenario potentially exists: the possibility of supplier liquidation or insolvency. This scenario is not discussed here because it is a part of the basic supplier assessment to evaluate the supplier business. It is covered in other guidance, such as GAMP® 5 (Second Edition), Appendix M2 7. If the regulated company decides to go with a high-risk supplier for that scenario, operational work instructions for handling that scenario should be implemented.

Data Repatriation and Workload Migration

The business continuity and disaster recovery plans should consider data and application backups and the ability to restore to a disaster recovery site. However, this may simply be another region of the same CSP. Extend the disaster recovery plan to include a contingency of restoring data to another CSP or on-premises. It is not necessary to always retain backups on another CSP or on-premises. However, have a plan in place to do so if required.

Similarly, restoration of system functionality in case of a disaster should already be in the disaster recovery plan. Workload migration is more complex than recovering the data, so any experience gained through an initial migration from on-premises to cloud should be leveraged to move workloads again.

How to Implement an Exit Strategy

The exit strategy should be anchored within the contract and existing documentation for the specific application. The general process consists of the following four steps (see Table 1).

Step 1

As part of the supplier assessment, the risk of the supplier not being able to reliably provide the service as agreed upon for the duration required should be assessed. A supplier must be approved to host workloads that process or store critical data. A supplier may be approved with residual risk, to be addressed in the next steps. The topic of supplier assessment is covered in other guidance, such as GAMP 5® (Second Edition), Appendix M2 7.

Step 2

If a supplier is approved, as much residual risk as possible should be addressed in the contract. The following points should be included in the contract.

Termination assistance

Explore including a clause confirming help from the CSP until the transfer to a replacement provider is complete. Or, more typically, a part of the engagement of a new CSP could be to help with the migration.

No withholding of data

Contracts tend to state the customer always retains ownership of their content. The contract should address the retention of access until the data can be moved.

Relief of data retention obligation

The CSP does not have an obligation for data retention. As such, it is always the responsibility of the regulated company, and therefore it is recommended to assess whether a clause should be added to the contract giving the regulated company extra days to recover data.

Destruction of customer data

The regulated company is responsible for the deletion of their data. Assurance for the effective deletion of customer data should be clarified and potentially included in the contract.

Provisioning of validation and qualification records

The regulated company must be able to demonstrate compliance of the services provided by the CSP via information from the CSP and how they meet the requirements of the technical and quality agreements. The contract should address the availability and provisioning of the records concerning the retention periods.

Step 3

With a contract in place, the portfolio of current or planned applications should be analyzed to identify those that process critical data stored at the CSP.

Step 4

For each identified application, an exit plan should be defined. This should be done by looking into the following details of the data and application:

• Amount of data (which potentially could lead to high migration times and related cost)
• Required validation and qualification records
• Necessity of migrating the application to maintain data readability
• The build time of the application, if required
• Country data boundaries
• Appropriate alternative CSP or data location
• An updated application documentation, such as a disaster recovery plan
• Test (continuously)

It may be worth considering performing this step early for a large or complex workload as an input to contracting.

Special Considerations for SAAS Solutions

A pharma company co-engaging with a SaaS provider must understand the platform model (“stack”) that supports the SaaS offering to fully understand the risks, mitigate them, and develop the associated exit strategy. When planning an exit strategy for a SaaS solution hosted in the cloud, it is important to consider the following key elements.

Data Backup and Export

Ensure that the regulated company has a mechanism in place to regularly back up data stored in the cloud. Additionally, make sure there are options to easily export data in a usable format that can be migrated to another system. Considerations should be given to what happens with the backup at the CSP after the regulated company has left the SaaS service: Will the old backup be removed?

Vendor Contract and Agreement Review

A thorough review of the contract and SLA with the cloud SaaS provider should be conducted to understand the terms and conditions related to termination and data retrieval. Any obligations, restrictions, or costs associated with the termination process should be identified.

Application Dependency Analysis

Assess the dependencies of the SaaS application, such as integration with other systems, customizations, or extensions. Identify potential challenges that may arise during the migration process and plan for how these dependencies will be handled or replaced in the new environment.

Alternative Provider Evaluation

Research and evaluate alternative cloud SaaS providers or on-premises solutions that could meet the business needs. Consider factors such as cost, functionality, scalability, security, and data management capabilities. Also consider regulatory requirements and policies in the QMS. Generally, all aspects that apply to “normal” software suppliers should be considered.

Migration Plan

Develop a detailed migration plan that outlines the steps required to transition from the existing cloud SaaS solution to the new environment. This plan should include timelines, resource allocation, data migration strategies, testing procedures, and contingency plans to mitigate potential risks. Special awareness should be given to the full stack. This is because SaaS requires a setup of infrastructure-as-a-service (IaaS) , platform-as-a-service (PaaS), and related parameters.

Communication with Stakeholders

Clearly communicate intentions and plans to stakeholders, including employees, customers, and any other parties affected by the transition. Provide regular updates throughout the process to manage expectations and address concerns.

Legal and Regulatory Compliance

Consider any legal and regulatory requirements that may impact the migration process. Ensure compliance with data protection and privacy laws, contractual obligations, and any industry-specific regulations applicable to your organization. Aspects like the ability to reprocess data might be tricky as well. If possible, standard export data formats like the Clinical Data Interchange Standards Consortium (CDISC) [8] (for Google cloud platform data) or E2B for safety data should be considered. Typically, a SaaS creates a higher amount of validation and qualification records, as it is installing and maintaining the computer system. These records are critical for demonstrating compliance and need to remain available.

Training and Support

Plan for training and support to enable a smooth transition for end users. This may include training sessions, documentation, or access to support resources to help users adapt to the new system.

Contingency Planning

Identify potential risks and develop contingency plans to address unforeseen circumstances during the migration process. Consider backup solutions, failover mechanisms, and fallback options to minimize any disruptions to business operations.

Metadata and Audit Trail

To ensure data integrity, compliance, and continuity, it is important to pay attention to metadata and audit trails when exiting a SaaS solution. The following elements should be considered.

Metadata documentation

Review and document the metadata associated with the SaaS solution. This includes information about data fields, data types, relationships, and any customizations or extensions. Understanding the metadata will help the regulated company ensure data integrity during the migration process and facilitate the mapping of data to a new system, if necessary. This is especially true if there is a legal need for maintaining the link between signatures and records.

Data retention and archival

Determine the duration for which the regulated company needs to retain audit logs and other relevant metadata. Ensure that the SaaS provider offers a mechanism to export and retain this data in a format that is usable and complies with any legal or regulatory requirements.

Audit trail export

Confirm that the SaaS solution provides an option to export comprehensive audit trails. These audit trails should capture critical events such as user activity, system changes, data access, and modifications. Exporting this data will be crucial for future compliance purposes, historical analysis, and potential audits.

Data ownership and access

Clarify the ownership and accessibility of metadata and audit trails after termination. Ensure that the regulated company has the necessary rights and permissions to access and retrieve this information, even after your subscription with the SaaS provider has ended (if possible).

Data encryption and security

Evaluate the security measures implemented by the SaaS provider to protect metadata and audit trails. Assess their data encryption practices, access controls, and data protection mechanisms to ensure the confidentiality and integrity of information during the exit process.

Data validation and verification

Perform a thorough validation and verification process when exporting metadata and audit trails from the SaaS solution. Check for data completeness, accuracy, and integrity to ensure that all necessary information is captured and transferred correctly.

Documentation and evidence

Maintain detailed documentation of the metadata and audit trails throughout the exit process. This documentation will serve as evidence of compliance, data integrity, and continuity if required in the future—and also fulfill GxP requirements for good documentation practice.

Third-integration

If the SaaS solution integrates with other systems or services, it must be ensured that the metadata and audit trails associated with those integrations are appropriately managed and migrated. Consider the impact on data flow and reporting capabilities when transitioning to a new solution.

Transition testing and verification

Before fully discontinuing the use of the SaaS solution, conduct thorough testing and verification of the migrated metadata and audit trails in the new environment. This step helps ensure that all data has been successfully migrated and is functioning as expected.

Conclusion

As this article discusses, the need for an exit strategy does not mean the need for overly complex and costly multicloud architectures. An exit strategy is a plan for taking care of data and business continuity. Its purpose is to comply with regulation and to support patient safety, product quality, and data integrity. Fundamentally, the strategy is to plan, mitigate the risk of contract termination as much as possible through contract clauses, and include contract termination as a trigger in business continuity and disaster recovery planning.