Digitalisation in the public sector: Software as a service

Welcome to the latest episode of Gowling WLG's Listen Up podcast, where we look at a range of topics trending in the legal and commercial landscapes.

Alexi Markham: Hi everyone, thanks for joining us today. This is the second in our series on digitalisation within the public sector, and just to recap the series is aimed at legal, commercial and policy teams who have not perhaps been historically involved in technology products but they are finding themselves increasingly pulled into the digital sphere when procuring and delivering public services and our objective really is to equip you with an overview of some of the key terminology that you might come across and some of the key legal issues that you are going to need to grapple which is sort of unique to the sector perhaps.

In this particular episode we are going to be looking at software as a service contract or SAS as they are known. As you are probably aware cloud and SAS has become one of the major ways in which IT services have been consumed over the last 10 and 15 years and indeed under the Government's Cloud First policy, government bodies are actually required to evaluate cloud solutions including SAS first before considering any other options, so it is a growing important market. It has many advantages, it is cheaper it is more scalable but there are some unique issues in terms of what comes up in the contracts compared to the traditional way that we consumed IT, particularly around the concept of ownership and Matt today is going to be talking to us in more detail about some of these issues.

Matt Harris: Thanks Alexi. In this session I am going to be focusing on the key features and principals of SAS and closing with a section on key issues in SAS contracts.

There are various forms of SAS and full or pure SAS as a hybrid. For the purpose of this session, we are going to focus in on the concept of SAS or pure SAS.

Software of the service is not new. The concept has been with us for many years. Market standard approach is to contracting have developed to reflect the way in which the technology operates.

Now, it is important to keep these in mind when drafting or reviewing contracts. Firstly, the customer has a right to use the service that relies on third party hardware, computing capacity and applications. Secondly, the provider has control over those applications. This enables the potential for a provider to offer a one-to-many service and finally the provider may store and process customer data within their own systems in order to provide the service to the customer.

In this final section I am going to focus on the key issues to look out for when drafting or reviewing SAS contracts. Building on our discussions around the principles, the customer is not going to own or access the software. For this reason, the customer simply requires a narrowed licence or right to benefit from the services provided over the internet. This is a key difference between an agreement for SAS and installed software. The provider is responsible for the development of the SAS and is the owner of the elements required to provide it. It is this approach that allows the provider to offer a one to many service that develops over time. Therefore, a SAS screen is highly unlikely to include a detailed specification and commitments by the provider to provide the services in accordance with that specification. This approach would potentially constrain the extent to which the provider can offer a one-to-many service and also develop their SAS offering. For this reason, it is more typical for a provider to commit to provide the SAS in accordance with a broad functional spec and to have rights to augment service over time. Now, this approach can be troubling to customers. Customers can be worried about the way in which the provider will develop the SAS and for this reason it has become commonplace for customers to seek a commitment from the provider that changes to the SAS will not materially degrade or weaken the functionality offered by the service.

In the context of pure SAS, the provider is offering a one-to-many service. Now, it might be possible for the customer to configure that service but development of the core SAS for a particular customer is less likely to be accommodated unless that customer is willing for the developments to be made available to all of the providers customers.

Customers may well upload confidential information into SAS platforms. Therefore, it is really important to ensure that any agreement for SAS contains robust confidentiality obligations and further, depending on the purpose of the SAS, personal data may well be uploaded and processed through the SAS platform in question. Any agreement for SAS which involves the processing of personal data must include appropriate provisions to govern the processing carried out by the SAS provider and by extension, this may mean that a customer wishes to explore the security commitments that a SAS provider can offer. For example, requirements for the SAS provider to hold certain accreditations such as ISO or Cyber Essentials. The purpose being to give the customer comfort about the security measures that the provider will take to protect the data that it uploads.

Finally, SAS providers are effectively offering an online service through which a customer's data can be processed and those providers are broadly speaking not going to moderate the content that is uploaded or take responsibility for that content so therefore it is commonplace in SAS contracts to see obligations upon the customer to avoid or prevent the instruction of certain information into the SAS platform. For example, offensive or even illegal material or material that infringes the intellectual property rights of a third party and it is pretty common as well for a provider to seek indemnity protection against claims arising from the introduction of such material into the platform.

In the context of SAS, the customer has no access to the software itself. For example, it cannot influence the code that drives the SAS and in turn cannot control whether that code infringes the IP rights of a third party. Control over the code sits squarely with the SAS provider. For this reason, it is market practice for the provider to indemnify the customer against third party claims that the SAS infringes the IP rights of a third party.

Now, the devil will be in the detail and the scope of the indemnity will determine whether this protection provided will be sufficient. The customer's ability to access the service is largely dependent on the provider. For this reason, it is important that any SAS agreement includes appropriate commitments from the provider in relation to the availability of the service.

It is market standard to see service level commitments concerning availability i.e. a commitment from the provider that the SAS will be available X percent of the time. It is important for a customer to check how availability is defined and also the carve outs from any availability commitment. Robust SAS contracts will also detail the remedies that apply in the event of a service level breach, such as service credits. Customers may also look to secure termination rights that apply in the event of persistent or catastrophic breaches of the service levels. Due to the nature of the service, the customer will be reliant on the provider to offer support should an issue arise in relation to the SAS.

A comprehensive SAS agreement should include detailed provisions relating to support. For example, detail on how to log a case and even who logged that case through to commitments on the provider on response times.

Finally, the agreement needs to consider what happens when the relationship ends. Afterall the SAS may contain the customers' confidential information or personal data for which it is a controller. A customer needs to have certainty over how its data will be returned on the expiry or termination of the agreement. For example, the mechanism for the return of data and the timescales. It may be that assistance is required from the SAS provider to facilitate this process or that self-service extraction tools are available. Either way, the customer needs to think ahead and ensure that the agreement captures the appropriate process.

Thanks very much for listening to this session.

Thanks for joining Gowling WLG for this podcast. If you enjoyed this episode, be sure to check out our website at gowlingwlg.com for more useful insights and resources and do not forget to subscribe to ensure you join us for our next episode.