Can you access your outsourced data

Financial regulators globally emphasise the importance of financial entities being operationally resilient, which includes the ability to manage and recover from disruptions caused by their service providers. The topic receives significant attention in the financial services sector because the sector is regulated, with the aim of promoting financial system stability. However, operational resilience and third-party risk are not, generally speaking, sector-specific concepts. All businesses should anticipate and plan for potential disruptions to their operations. All of them are dependent on third party technology and services, at least to some degree; and a large proportion of their service providers hold data without which the businesses would not be able to perform certain functions to the standards expected of them (or at all).

Here we look at:

• Why access to data held by service providers is critical for operational resilience.
• Regulatory expectations in this context (we do not consider the data protection aspects, which are beyond the scope of this publication).
• Drafting meaningful access to data provisions in technology and outsourcing contracts.
• Escrow to support data access.

• Why access to data held by service providers is critical
• Regulatory expectations
• Drafting meaningful access to data provisions
• Escrow to support data access
• Want more information?

Why access to data held by service providers is critical

Events impacting upon service providers can be temporary, such as the unavailability of a technology platform caused by emergency maintenance. Or they can be permanent, like the service provider shutting down due to insolvency. The potential impact of such disruptions depends on the nature of the service and its importance to an organisation's operations. The actual impact is largely determined by whether the organisation and its service providers have adequate business continuity and exit arrangements in place.

A key component of both business continuity and exit planning is ensuring that the business can access and use the data held by its service providers to continue performing the relevant function and (if necessary) transfer it to a new provider.

The scenarios above illustrate several points:

• In Scenario A, the quick activation of a business continuity plan for alternative data access and the support of the tech provider effectively mitigated the temporary disruption caused by unplanned system downtime.
• Disruptions caused by repeated emergency maintenance in Scenario B led to a planned (or unstressed) exit. There were exit provisions in the contract that gave Machines R Us sufficient time to make alternative arrangements, but it was not able to access its data without substantial additional and unanticipated cost.
• The tech provider's insolvency forced an unplanned (or stressed) exit in Scenario C. There may be potential legal routes available to Machines R Us to enforce its contractual exit rights, but it is unable to withstand long-term operational disruption.

Regulatory expectations

If Machines R Us was a bank or other financial services sector firm, it would be likely to be subject to regulatory requirements in relation to certain contractual provisions for its outsourcing and material technology contracts. These typically include appropriate business continuity and exit planning provisions. Some financial services sector regulators also impose express requirements on the financial entities within their jurisdiction to ensure access to the data held by their service providers.

For example:

• The UAE Central Bankrequires banks and insurers to ensure that their outsourcing agreements enable "unfettered access to all of [their] data for the duration of the agreement, including upon termination of the agreement".¹
• UK banks, insurers and other financial entitiesregulated by the UK's Prudential Regulation Authority (PRA) must include provisions in their material outsourcing agreements regarding the "accessibility and availability of relevant data and provisions to ensure that data owned by the firm can be accessed promptly in the case of the insolvency, resolution or discontinuation of business operations of the service provider"². Similar provisions should be included in third party arrangements that are not outsourcings where relevant, in line with the PRA's expectation to apply proportionate risk-based controls to such arrangements.³
• European financial entitiesthat are subject to the Digital Operational Resilience Act (DORA) must ensure that their contracts for ICT services include "provisions on ensuring access, recovery and return in an easily accessible format of personal and non-personal data processed by the financial entity in the event of the insolvency, resolution or discontinuation of the business operations of the ICT third-party service provider, or in the event of the termination of the contractual arrangements"⁴. There are similar provisions in the current European Banking Authority's (EBA) guidelines on outsourcing arrangements (and in the draft EBA guidelines on the sound management of third-party risk which are proposed to replace them).⁵

Outsourcing and tech contract templates tend to include obligations on the service provider that mirror the wording of these regulatory expectations. However, an effective provision ensuring access, recovery and return of data will need to say something more, particularly in the context of a stressed exit scenario.

Drafting meaningful access to data provisions

As a starting point, consider the type of contract and the extent to which data access is controlled by the service provider versus the customer:

• In a SaaS arrangement, for example, where customer personnel use a technology platform themselves, the customer should be able to view its data during the term of the contract by accessing the system. The ability to download / extract the data will depend on system functionality.
• In a business process outsourcing,on the other hand, some or all data may be accessible only by the service provider on its own technology, or by using technology procured from another third party.

The distinction highlighted above between what we may call "direct access" and "conditional access" is fundamental in determining what contractual protections are needed to support access to data. Many outsourcing arrangements involve a hybrid of these two models, and the contract will need to address multiple types of data access. Some examples follow.

Access to data during the term (business as usual)

Where customer personnel use the relevant platform (that is, direct access), continuous access to the data during the term should be supported by:

• High platform availability commitments and clear parameters on downtime for routine maintenance.
• Strong support service levels.
• Robust incident management and escalation procedures.

Where the data is controlled and handled by the service provider (that is, the customer only has conditional access), the contract should provide for data to be made available promptly on request and without additional cost to the customer. Business-critical data may need to be provided "immediately" or within a specific period from the request. Ancillary obligations supporting the prompt supply of data include:

• Keeping customer data segregated from other data, or at least in a manner that is easily identifiable as customer data.
• Using systems which allow for the efficient extraction, copying and transferring of data and (if needed) conversion to other formats.
• Using appropriate measures to ensure that data is not lost, damaged or corrupted.

If service provider personnel are using a third-party platform to perform the services, consider:

• The commitments offered by the third party to ensure continuous access.
• Whether or not the service provider excludes liability for problems with its third-party platforms.
• The service provider's contingency arrangements for accessing data to continue providing the services if the third-party platform is unavailable.
• The possibility of contracting directly with the third-party platform provider to ensure ongoing access if there are problems with the service provider.

Data format

Where a service provider is responsible for providing data, both during the term and on exit, the contract should expressly require that it is provided in a format that is accessible to the customer without having to license or purchase additional technology. There may be costs associated with data conversion, but these should be identified and commercially negotiated upfront. This applies whether the data will be transferred by the service provider or the customer is able to extract the data from a platform itself.

Access to data on termination

Most SaaS contracts specify that the customer is able to extract their data on termination, or for a short period of time after termination (e.g. 30 - 60 days). SaaS service providers often argue that nothing further is needed by way of exit provisions. This may be a sufficient period to extract data, but it is unlikely to be enough time to make alternative arrangements for replacing the platform in the event of an unplanned exit.

Such strict timeframes can be mitigated by providing for a minimum exit period during which the customer can continue using the platform after termination (like in Scenario B, above). It may come with commercial conditions, such as upfront payment of subscription fees if the contract has been terminated for the customer's breach.

If the platform does not have download functionality (which would be unusual), the contract should expressly require the service provider to supply the data in an accessible format on termination.

Business process outsourcing agreements should contain more detailed exit planning provisions for the transfer of the outsourced services, of which the migration of relevant data back to the customer or to a new supplier is a critical component.

Escrow to support data access

The contractual protections described above are predicated on the platform and the service provider still being available to comply with them. What happens if this is not the case, for reasons of insolvency or otherwise? While taking steps to enforce the relevant contractual rights (to receive data on exit) or to recover losses suffered as a result of data not being provided might be possible, such steps simply may not be swift enough to "keep the lights on" from an operational perspective (as Scenario C, above, illustrates).

To address such concerns at the outset, customers could consider implementing escrow arrangements. Software escrow is most typically thought of as a mechanism to ensure ongoing use of a business-critical system in the absence of the service provider. While this is correct, newer escrow models offer an added and often missed benefit: access to data.

Traditional source code escrow is of little use in the context of a cloud-based platform or SaaS because it cannot be operated independently of its hosting environment.

Escrow providers have developed new cloud escrow models to address this shortcoming. As at the date of publication, there are two main types of cloud escrow:

• The "access" model,where the service provider deposits only the access credentials to the existing environment in which the software is hosted, which is provided to the customer if a release event occurs.
• The "replicate" model,where the escrow provider sets up a separate mirrored instance of the cloud-based software in its hosted environment. If a release event occurs, the customer is given access to, and control of, the entire mirrored instance and everything in it.

The access model ensures that the customer is given access to the latest version of the code, environment and data. However, it:

• Is unlikely to be suitable in a multi-tenanted environment, where the service provider hosts a single instance of the software for all of its customers.
• Carries the risk of the service provider changing the credentials, or of there being a problem with the underlying environment (like in Scenario C, above, where the cloud provider suspended its services for non-payment).

These risks are not present in the replicate model, where the environment is managed by the escrow provider, but this model requires regular updating of the code and data in the replicated instance. Some escrow providers are able to do this automatically by maintaining a connection to the underlying instance.

Both models enable the customer to access the data hosted on the cloud-based platform. Cloud escrow:

• May therefore be a useful mechanism to support data access in the event of stressed exits from a service provider, even where the customer does not require long-term (or even temporary) access to the platform itself.
• Could also be used as a means to secure access to data in a planned exit where there is a difficulty in obtaining the data from the service provider. The release events would need to be carefully negotiated to allow for this.

Businesses who may be critically impacted by the loss of access to data on a cloud-based platform may therefore wish to investigate escrow as a potential mitigation strategy.

Want more information?

For more information in relation to:

• Technology legal and regulatory issues, see our knowledge hub, Inside Tech Law.
• Liability in relation to outsourcing and technology contracts, see our publication, Outsourcing insights.
• Regulatory compliance, contract remediation and outsourcing, see NRF Outsourcing Toolkit.

Footnotes