Mitigating cloud risks

Helen Davenport: Good morning everyone and welcome to the second in our series of IT Masterclass webinars developed specifically for in-house counsel. Thank you to all of you who are joining us and I can see the number of participants. There are more joining as I am speaking so that is great. I am Helen Davenport, a partner in the commercial litigation team at Gowling WLG and I will be chairing our session today on mitigating risks in the Cloud. I am joined by partner, Jocelyn Paulley, who heads up our IT Team in the UK and her specialist areas of expertise cover IT agreements, data protection, data-centres and telecommunications. In terms of housekeeping before we begin, Jocelyn is very happy to take questions as go so please do put any questions that occur to you in the Q&A box, and we will also pick up any remaining questions at the end of the session. I also confirm that this session will be recorded and available after the event and it will be circulated to you as well. Those details covered I will hand over to Jocelyn.

Jocelyn Paulley: Thanks Helen. The pandemic has really shown us how much we all rely on online services to live our lives in these days when physical contact and being out of the house is something of a challenge. We rely on being online to work, socialise, do our life admin, and have webinars like this and attend conferences. I can hold a work meeting. As lawyers, we can remotely sign legal documents. We can all do our online banking, order our groceries, you can see your doctor, entertain the children with TV streaming, have your social life, doing quizzes and parties and even, as I discovered during lockdown, have a bat consultation if you really need to remotely. The benefits of this system are clearly evident to all in our personal lives and of course from the point of those enterprises providing those services. This is not something that has suddenly happened. There has clearly been a growing trend for businesses to move their services online and there was actually some research out in May this year, so just at the beginning of the pandemic where it suggested that last year was actually a key milestone for IT Cloud services on the basis that at that point enterprise spending on Cloud infrastructure for the first time out-stripped spending on your traditional data-centre hardware and software type services. As part of a growing trend even industries that are larger and more entrenched in their ways, like banking, had been moving some of their core systems, those big main frames that they run, increasingly online and if you look at new parts of the banking industry like the challenger banks, they operate entirely online providing their services to their customers through the Cloud without any high street presence at all. But this is not something that has happened suddenly. The trend has been going that way to put more and more online within well-established industries and enterprise and of course the pandemic has accelerated that. So even those businesses that were not connected directly with their customers through the internet have suddenly looked to set up e-commerce sites, looked to enable click and collect facilities, restaurants that let you book in and order your meals online to limit that face to face contact. We have seen more and more workload being pushed over the internet.

Experts now think that by the end of 2020 as much as 67% of enterprise infrastructure will be delivered by Cloud services and about 82% of the entire workload will sit on the Cloud. So from an enterprise point of view there are clearly big advantages to using Cloud in times like these, but also more generally to deliver services faster and more flexibly. They are relatively straightforward to set up compared to traditional IT implementation where it would have a long immobilisation period and transition and testing. These services, you go online click a few buttons, except some terms and conditions and then you are up and running. They are quick to set up and maybe most importantly they require little or no CAPEX spend so departments looking to use online services can simply deploy their OPEX spend that they have access to for whatever they need that year without having to go and apply for specific funds. It is very easy for them to deploy. Most businesses have taken up Cloud services in such great volume, such enthusiasm; does that mean that the risks we were looking at maybe five, six, seven years ago have all gone away? With that point this is still quite a new technology, nervousness around using it and what it means, it always seems like big steps to put your system and your data into Cloud. Now everyone is embracing it quite enthusiastically. Does that mean that that has changed? The answer of course is no. There are still risk there, but as we have become more familiar with the technology and how it works and how you investigate them, then that has become easier and is seen as a less risky approach for businesses to adopt Cloud services.

So given all this background and what is going on, we thought it was worth a session to refresh on what those risks look like and how you might go about mitigating them in your contracts. But before we jump into what the risks are I thought it was worth a brief slide on what we mean by the Cloud and what Cloud services are. It is not a term of science. This is much more a term of art. Different people will give you different answers to the question what is the Cloud? You can break it down in to some component parts and it does mean as well that it is really important when someone in your business comes to you and says we want to use some Cloud services that you do drill down with them to make sure both you and they understand exactly what you are buying, because the risks I am going to talk about will vary in degree depending on what type of Cloud the organisation wants to use.

So broadly what we mean, you are talking about servers, running software that is delivered remotely to you, usually over the internet for a level of connectivity. Those services are not directly located in the same building and places, they are remote. They are physical services, just machines like you would normally have, hardware running your applications on. Nowadays though they are also very clever and become virtual as well as being physical service so one real machine might be pretending to be four or eight servers. They act as if they are more and you might be accessing a part of that one physical server. As I said those servers are remote, they are not sat with you and so your get access to some kind of connectivity usually just over the publicly available internet so public infrastructure, although you might have in some scenarios some private connections that starts to look less like a Cloud than if you are not receiving this over the internet.

So that is what the physical structure looks like, but then there are different ways in which it can be set up. It is really important to establish which type of cloud you are going to be using for any particular service. Cloud in its pure sense is what we call a public Cloud. There is one instance of software which all customers have access to and use that same functionality all running on the same piece of software. There might be bits you can tweak around that, if you think Gmail you can set up your own folders or you can have your own tailored background there but fundamentally are using the same functionalities that the operators are maintaining in the same way for everyone who is using it. At the other end of the scale we have what they call a private Cloud. So there the instance of software that you are accessing is only ever going to be accessed by you. So it is a much more tailored environment, you have much more individual control because you are the only customers that the operator is supporting that infrastructure for and depending how far you take that it starts to almost drop out of Cloud and become just a managed assisted service more like in traditional outsourcing world, and then you could have some kind of hybrid either because you as an organisation used both public Clouds or for any particular service where it has been structured, you are accessing part of a public Cloud and part of a private Cloud alongside it. Whatever sort of Cloud you are using it is really important to remember that this isn't one provider that you are engaging with to receive that service. If you think of it as a technology stack where at the bottom you have a data-centre was the physical infrastructure that is space, power and cooling. Someone comes along and puts their servers into it, might give you an infrastructure as the services where they have that more compute power sat there for you to then deploy on to. There might be others who provide a platform as a service so you have got a Microsoft Windows operating level or Linux, whatever environment you are in, or you might be contracting at the top of that stack to get access to an application or particular functionality that is sat on someone's platform and someone's infrastructure and someone's data-centre. Now depending on where you are contracting in that stack you might actually be touching a range of provider services to get the thing you actually want, the functionality you are looking for.

I think this is also an increasingly complex environment, not just because of that stack but because if you think about a traditional IT range of suppliers, there would have been lots of those absolutely for all the different software and hardware element that a hardware organisation is using, everyone who is supporting those, your implementers, your integrators and everyone who supports and the Cloud world is just the same. Thales did some research and they say that four out of five companies actually have two or more of those infrastructure as a server or platform as a service providers, so you are at the lowest level in the stack. The vast majority so about 86% have more than 11 SAAS providers so the highest level and about a third of companies have 50 or more SAAS providers. That is a huge number of providers that you are engaging with and particularly complex when you then think that at that highest SAAS level there is a whole stack of providers, beneath them that are ultimately enabling the service that you are receiving. I am also saying it is complex because we have seen the growth of what is called shadow IT. So that is the idea that because these Cloud services are so easy to deploy and contractual and the departments are just using their OPEX they have in their pocket so to speak - pre-approved spend. They are just going out and contracting the bits of these services and they are deployed and not controlled centrally by the IT function, so an organisation's central IT does not necessarily have a hand on all these extra bits of Cloud services that might be being used by a department, not as something wrong with their use but it is a fact that that is invisible to the organisation. So particularly thinking about from a data angle you do not have a handle on all the third parties who might be touching or seeing your data and that starts to create extra risks and complexity there.

We are going to look at in the session what are the risks in using Cloud services. I am going to look at risks specifically for Cloud so, there are different risks to just using software so even using the traditional outsource supplier, but the degree of those risks and quite how you mitigate them will vary depending on whether you are using a public or private Cloud which is why it is so important at the start of any engagement by understanding what type of service you are using so that you can correctly assess the risks that might occur.

The first one I am going to look at is the one I think that comes to most people's minds when you start to talk about Cloud cyber-security. That term in itself covers quite a range of risks. I think we are talking about everything from security standards, so the Cloud providers own policy or the industry recognised standard they might be following. We are thinking about external threats, so malicious targeted attacks on particular enterprises or particular Cloud providers and obviously we are seeing increasingly sophisticated natures of those attacks in the way that they are working themselves into organisations. Thinking about viruses that occur in very commonly used software. You think about WannaCry issues in SQL databases that are embedded into so many software processes. They post a risk particularly where you as an organisation are not familiar with the precise bits of software that might be being used to provide a service to you, and also if you are using a Cloud service provider than in itself just make it a more tempting target for anyone looking to cause mischief, because rather than having to go through lots of effort to target maybe 100 companies, a cyber-criminal can just go straight to a Cloud provider and therefore their chaos will be multiplied across that entire Cloud provider's customer base.

What can we do around cyber-security to make ourselves feel more secured and reassured? Well the very fact of using a Cloud service provider is mitigation in itself to some extent. Think about it, your enterprises, your reason of being and your mission in life is to deliver your services to customers, whatever that might be, food or clothing or banking or telecoms. You are not experts in cyber-security as a speciality in itself, whereas the Cloud provider security is one of the fundamental things that they are providing to clients so they are actually arguably in a better position to bang up to date with what the latest threats are and the best way to address them.

It is important to establish what that level of security is, and you do sometimes see a bit of a tussle between a customer's security and the supplier's security policy and working out whose is going to apply. Usually though particularly, and definitely in a public environment because is what the operator provides for all of its customers, it will be the case that the customer's security team taking the operator's policy, working through it to see that they are comfortable it provides sufficient levels of security for the nature of data as a type of service that you are looking to procure, and then contracting on that basis. It is important to make sure the contract does clearly reference and incorporate whoever's security policy you agree between you are going to apply. You do see in some Cloud service contracts very woolly references to security but from a legal point of view you want certainty of knowing what that policy is and what it says and where it can be found. There is a bit of a trade-off here, you do have to be careful not to tie it down too tightly, as lawyers we like certainty, but cyber security is not something that is static. There are new risks emerging all the time, is it cyber-criminals become more inventive and find new flaws and therefore security practice is obviously update to work out how to address and mitigate those technical risks so whilst you want the certainty in your contract of knowing what the security measures are you need to include language to allow those measures to improve and build over time, language talking about the quality - not providing a lesser level of support that you contracted for on day one, and you probably want an assurance that that security will always comply with good and straight practice as well to allow the supplier to do what they do best and actually keep improving the security measures that are apply to those services.

You can look at different levels of security as well. We see in some Cloud contracts that security actually becomes linked to payments and charging because some suppliers can offer different levels of security for particular environments, and that is a service for which the customer pays. So that is always a question to ask to understand can you enhance security if you think the basic level was being offered is insufficient, understanding that probably comes with a charging consequence. We have seen this though get really quite tricky where the Cloud provider and the customer had different views on what an appropriate level of security might be in a data protection context, so the Cloud operator is actually uncomfortable with their GPR obligations to provide appropriate security because they were being told by the customer on the other hand that the customer only wanted to pay for this level of security whereas the Cloud operator thought it should be this level, given the nature of the personal data that is going to be in that Cloud and that was a charging point issue between the two sides that we had to resolve, whilst making sure that the GDPR obligations were also fulfilled. You can also think about additional levels of security from a customer side in terms of additional things you can do around the Cloud or things that you can control within your own environment which might bolster the security provided by the cloud operator.

Now whatever security measures you agree to put in place it is critical that as a customer you are notified if there are any breaches or are any issues. Clearly it will be the operator's responsibility to work out what has gone wrong and to put it right, but you need to know so that you can have influence over things so press releases and public relations side of any breach and obviously communicating to your customers to let them know what has happened, what has been done about it and to make sure that they are reassured that they are not at any risk or if they are what they can do about it. So you could only be in that position if you have provisions of acquiring the operator to let you know what happened, to keep you updated to make sure that you can then talk to the public and to your customers.

Your IT department might normally want to do things like penetration tests on any providers that the engage with so that you get some first-hand assurance that security has actually been put in place and to see how robust it is. For Cloud providers though that can be quite a challenge if their entire customer base doing friendly attacks on their environment and that creates a risk in itself so it is really important to understand whether or not your provider would allow this or if you need particular conditions to that. We have seen separate penetration testing agreements and permissions so that the Cloud providers are aware the customer is going to do it, and the customer is free to do that without the provider thinking they are actually been attacked and pushing them out and shutting them down. Or you might find the Cloud provider arranges its own penetration test and then issues some kind of report to its customers to show them what the outcome was and prove the level of robustness of its security.

With similar issue around audits, customers will often want to carry out an audit, a security set up in a physical onsite way or by doing some active testing audit advice issuing due diligence questionnaires. Again from a Cloud provider who is offering an infrastructure across a very large numbers of customers. That can be prohibitive and would mean they were just being audited on every single day of the year by one customer or another, more particularly the hyper-scalers,  they will engage their own independent third party auditor who would then audit and issue the report for the benefit of all customers so they have had comfort on the level of security and rigour that is being applied but without having to do that audit individually themselves.

Insurance is an obvious topic that springs to mind in terms of cyber-security. What cyber insurance does the operator have? That is a whole topic in itself, which is why we have a separate IT Masterclass session on insurance so I shall not say much more about that. I will briefly say thought encryption because that is the other word that springs to mind when people start to talk about security, it is one of the measures that the Cloud operator might use in terms of securing their system but again it is a detailed question. Certainly not all types of encryption are equal. There is weak and strong encryption. You might be encrypting data in transit or static data once it is being stored, and there are different cost implications for applying different levels of encryption as well. So again you can't just either presume that a Cloud operator encrypts data when it is moving around and wants to look within their environment, it might actually not be necessary or might not be the best way of protecting their data.

The next one I want to talk about is the lack of physical control so whereas in traditional outsourcing you might be allowing your outsource provider to have access to all your systems and all your data, often those systems will still be within your own physical control. You won't have a third party necessarily running it for you, whereas here you have actually given over that physical access to a third party. The servers on which it is running, they are not on your site or even on sites that you control and the servers themselves are not owned by you it's all third party owned, third party controlled, so it can feel like that data is very remote and out of your control. The way you can make yourself feel more in touch with that is by making sure that you do have access rights to go and access the data centres where that data is being held, and making sure that within the contracts that you know and you have rights to go and access your space within the data centre sometimes customers actually site engineers within data centres with the benefit that these are people who understand your specific systems rather than relying maybe on data centre staff who service the entire data centre and all the customers who might be sited there. Obviously pre-contract due diligence visits to understand the nature of the facility in which the data will be housed and what physical security there is around those data centres, because often you will be one tenant or one customer within that environment where there will be many others who legitimately have a right to be there and you will want to see how that is controlled, you'll also want to know for when your own people go with a pre-vetting procedures do you need an induction, all those kind of issues so that when an issue does arise and you need quick access you know how you are going to do that.

Reporting an audit right, similarly you can ask for that around the physical control and access measures but again because of the shared nature of the infrastructure it is unlikely a Cloud provider will want all customers to be able to regularly come and physically audit them. But I think, maybe because I'm a lawyer, that one of the biggest comforts here is that we do have some helpful law on the relationship between physical control and the data. I think there is a misconception that may be widely held, that data is owned by a company if it is data about your customers, your systems, your finances, there is a legal right of ownership and that is not the case. Data is not like intellectual property, where there is a legal beneficial title to the intellectual property around creations. You do not have that same proprietary right in data itself, and if you think about it that must be right because otherwise all the facts about the world and the way it works must be owned by someone and then there would have to be some kind of structure to allow others to access and use that doesn't exist. And it is not just lawyers extrapolating concepts, there is actually some case law. A case from 1979 found that information was not property and couldn't be stolen under the Theft Act, and then more recently from 2014 the Court of Appeal so an even higher authority found that you could not exercise a lien over a database so a service provider which had not been paid by its customer was holding on to its customers database and saying well we are going to hold this as a lien until you pay us, and the Court said a lien is a proprietary right you cannot exercise that over data. That is helpful in this scenario because it gives a little more comfort although someone else is physically holding and controlling your data they cannot use that as some kind of hold over you so well we've got your data and therefore that puts us in a strong position against you the customer whose data it is. Having said that though do watch the contractual provisions because you will typically see clauses that say that unless the provider has been paid in full the customer will not be able to get data back, maybe at the end of the contract, or there is a suspension right if payments are not paid on time because that if of course the biggest stick that a provider has over its customer so whilst the law is comforting watch the contract terms that go into contracts for Cloud services.

Alongside the lack of physical control you also want to think about geographically where is my data going to reside in the world? If it were in your basement or one of your properties you would know where it was. With the Cloud service it could be located anywhere in the world, even if you are contracting with an English based company, so you want to work out where the data is going to be and from that you then need to think about are there any local laws that might apply that mean that Government or law enforcement agencies have local mandatory rights to access that data. Are you comfortable with that risk given the nature of the data you might be putting into that Cloud service. You would also want to think about enforceability, if something went wrong and you had to go to the extent of getting an English Court judgment how easy would it be to go and enforce that judgment particularly if you are thinking about access to your data. If there is an issue with your provider and you eventually have an order saying the data has to be handed over you want to know that that order will be enforced in the jurisdiction that your data is residing. You also need to identify if you have international transfers from a data protection point of view to make sure you put the right measures in place. So although the data could be located anywhere you can look to contractually limit where it is located. The big providers, Azure and AWS they let you nominate a region of data centres in which your data will reside so not necessarily just one facility but a number of facilities within a region. There are very good reasons why they want that flexibility due to the way their systems are structured for their own resilience and load balancing, but you get the comfort as a customer that you had had some level of certainty over where the data is going to go and therefore you can assess those rights about local law access and enforceability. Obviously there is a range of legal due diligence to do there to establish that and think about those things before you enter into the contract, because once you are in it, it would then be very hard if not impossible to say actually no I don't want my data going to that particular location as that is the way the service provider is set up to provide their services. From a GDPR point of view you need to know where the data is to establish if this an international transfer and then discussions with the provider about what safeguards and adequacy measures they put in place to do that in a compliant fashion. Following trends too obviously transfers, understanding contractual clauses particularly to the US have become a little more complicated, so you need to make sure your Cloud providers are responding to that and dealing with those issues. In the contracts that we have seen being negotiated since the judgment in July and now although providers have not always quite got to the point of updating their terms before they are issued when we have asked the question we have received positive responses that they are looking to either bolster their standard contractual clauses or look at getting binding corporate rules approved or using other mechanisms.

So if you have your data sat physically with another provider in another location you might be more worried about confidentiality breaches and feel there is greater potential for there to be a breach because your data is residing within a third party, within their infrastructure so there is greater potential in the course of transferring that data between your own provider and that remote access that that could be misused abused or data could be intercepted when travelling between the two parties, or you might see a risk in the fact that the Cloud service provider's own employees could access that environment, probably quite properly for support and maintenance activities or fixing issues when they arise, but that might seem like a point of weakness in the structure. So to deal with that I think this is largely a legal and contractual response. There are some more practical measures, as a client you can make sure that you maintain admin access rights so you at least have the right to appoint who else has access and you can see within the provider who their super-users are for support roles, and you could then have access to the access log so you know who has been in and out of the systems and at what time.

There may be other practical measures that in the particular scenario you want to put in place for the nature of the system that you are procuring, but you certainly want to make sure that contractually you have really clear confidentiality clauses that specify that all the material and data that you put into the system, that is generated through the use of the system that the supply can access in the course of providing services, all of that has a label of confidentiality over it and that the provider cannot do anything else with it other than provide the services to you.

The interesting development we are seeing here is providers pushing the boundaries of what they can do with that data that resides within their environments, particularly starting talking about how they might want to reuse that data in an ammonised, aggregated way in order to commercialise the data that is sat within their environment. So typically the provider might be providing services to customers in a particular sector, they are aware they sat on a huge volume of data that relates to a particular sector. They could conduct some analysis over that, they could spot trends, look for issues. They might be able to gain some insights that they could then take back to the industry possibly on a commercial basis and generate money from all that data that is residing within their environment. I have had clients come to us saying I have become alive to the fact that the provider is either doing this or wants to do and can they do that under the terms of the contract? Certainly older contracts barely ever had clauses in saying clearly either positively or negatively that providers could do this. Increasingly we are seeing Cloud providers standard terms given permission to do this, so it is clearly stated, but in the absence of any clause saying either way, you do fall back on the confidentiality clause but the providers run the argument that well if I'm using the data in a way that does not identify you Mr Customer A, then how is that going to cause any harm and so how would you ever bring a claim against me for breach of confidence because there is no harm been caused? So it is something of a grey area unless you have a clause that specifically states one way or the other, and certainly if we are active on these we will put in a clause and talk about the issue with clients and you can determine whether or not you are comfortable with that risk or certainty depending on what the Cloud provider's terms say.

Exit is an interesting one to talk about in terms of Cloud services. Here your data is all sat with that external provider so there is a risk around getting that data within your own environment, which is different from all the other risks we usually think about in terms of the smooth handover and knowledge transfer. You want to watch to ensure that the provider is not going to automatically delete any of your data when the contract ends. You need to work out how you are going to get that data back from the provider, and get it back in format that if something that you can use again that will be compatible with other environments, and that's why this term vendor lock-in becomes relevant because it might be that the vendor has ended up structuring your day in a particular way that it is either hard to extract or it is expensive to extract or is expensive to reformat into a form that you could actually use again within your own organisation or with a future provider. As with anything you need to think about this from the start, not just at the point of exit. It is worth finding out from your provider if you can do what I term self-help, can I help myself to copies of my data through the life of the contract, which might want to do for business continuity reasons as well, but it obviously means on exit you are not reliant on the provider doing something for you. You can actually actively go in there and do it yourself. You can of course have classic exit assistance obligations to, that they do have to reformat that data or they do have to provide it to you in a particular format. I would always suggest that you do state format that is something has to be agreed between you or it has to be specified file format or a common file format like a CSV file so you have that certainty. We have seen disputes where the customers are saying, my provider is saying I can have my data back but it will cost me x because they have to reformat it out of their own systems and into something else and that is a costly exercise. Always better to be clear up front how that is going to work.

I often get questions about can data be put in escrow so obviously a business continuity risk but also potentially useful on exit. You do now see the classic escrow providers, so the likes of NCC and Iron Mountain, do offer data in escrow services so it exists. The question of course is it appropriate for the type of service that I am running, because if this is a real time system where data changes every day or minute by minute even, then holding data in escrow is going to be of limited value if that is data from a week last Monday but there has been 10 days since and a huge amount of data will have changed so getting yourself back to that point would still be a really expensive exercise. But if this is maybe a reporting system where actually you run a report once a month using the Cloud service it might make sense then to take that snapshot of data, put that in escrow and then you have got it there if something goes wrong in the next month. So it all comes down to context.

This idea of vendor lock-in, I think you can address in a couple of ways. Sometimes the issue is that there some vendor IP ends up being inextricably bound in with the data in the way that they formatted it, or set it up in a database, or the way they are using it within their systems and they say well you just cannot give it like that someone else because that would give a competitor an insight into how we run our systems and they are uncomfortable with that. So making sure you understand how they are using the data and the life of the contract and then the format in which you will then get back. Also I put this idea into service manuals so if you are going to appoint a new Cloud provider do you need to know how in a processed kind of sense your existing provider has been running the service? If you have taken the view as an organisation that you just wanted to buy a vanilla Cloud service and you are actually going to reshape your own internal processes or maybe processer that are customer facing to match how a particular Cloud service provider provided a service in a process sense. It might then be really important to have some kind of manual written down of how that is done to give to a new Cloud provider to say this is how it happened before, this is what our customers see, what we expect to happen so you have that continuity from one provider to another.

So I have mentioned business continuity a couple of times there in the course of taking about exit and this is a topic in its own right to think about. The risks here are that your data is physically sat with someone else so what happens if they suffer some kind of disaster separately to you, or what happens if just that connection between you and them goes down and you cannot get that access to your data because you can't call for it at that point in time. So do you understand what the plan is? Unlike a traditional outsourcing where you would expect your provider to create a business continuity plan possible bespoke specific for you and the particular service they are providing. Here a shared infrastructure environment that is highly unlikely to be the case because the provider is running one system for all its customers. So you need to work out what is the plan, how might it sit with you plan and think about it both in the sense of the system and service it has been provided and the data that is within that environment depending on whether or not this Cloud service is the sole repository of your data or whether or actually it is pulled from other sources that you hold and control centrally, so access to the data itself, it is not such an issue.

In terms of mitigations, you might see it as a mitigation in itself that you are using the Cloud provider because then in your organisation in location A suffers some kind of disaster that might not apply to your provider in location B. That in itself might actually be a benefit rather than a risk. You do need to work out who is responsible for business continuity. Some Cloud services offer a level of business continuity as part of their whole service package, or some might have optionally as a chargeable service, or some might not offer it all but rarely when you look at a Cloud service contract do you see it called out a clause heading like you would do in an outsourcing contract and very rarely see it in any kind of service description or standard documentation, so you have to ask the question to understand what the position is an what the provider will be able to do. In a way that particularly the bigger providers offer these services, some level of business continuity is just part of what they offer because they have such a large number and range and structure of other data centres. They do geo-replicate systems. The whole point there is resilience so if they have an issue at one location, they can shut it down and bring the system up somewhere else. But you need to understand is that something your provider offers, is it within their technical capability and structure or is it something I am paying for extra or as the customer would it be up to you to know that if this provider fails, actually I have another copy of my data somewhere else, or I have done that self-help and taken a copy of the data myself so I could run some other manual process or something as an interim measure whilst my provider deals with whatever their issue is.

And finally the supply chain issue. So I talked at the start about how with SAAS, PAAS, IAAS you have a contract stack. There is a whole chain of suppliers who are actually providing the service to you. Particularly if you are contracting for the SAAS, the software as a service that chain is not very transparent. It is not clear how many subcontractors are involved and who they are using. There is probably either the contract science or subcontracting or it says that the provider can use whoever they need to subcontract any of their obligations. It is important to understand who is in that stack so that you can assess all the things you would want to in any procurement with a provider you are entering a contract for anything material, looking at financial stabilities, you can be alert to any insolvency risks, and also as and when breaches occur knowing who should be talking to and whose responsibility it might have been to provide a particular bit of a service. So at the start of the process there is certainly an element of due diligence to ask these questions and make sure that you understand from the beginning who is involved, which organisations are providing this overall service to you. You can try asking during the life of the contract if there are changes to those subcontractors that those are notified to you. Very, very unlikely that you will be able to say I want to give my consent to that, because again your operator is providing a shared infrastructure, they cannot have all their customers having the right to consent to who they use as subcontractors.

You could think though, and this very much depends on whether you are using a public or a private Cloud, whether it is appropriate at the end of the contract you could ask the novation of any subcontracts to you. That is only going to work in a scenario where your Cloud provider or your SAAS has actually gone off and contracted something that was more specifically for you, but we have seen that maybe where you are working with smaller organisations that provide a level of business continuity and to take some risk away, you can ask that the subcontract is novated to you if the contract with your Cloud provider comes to an end so you have some level of assurance around business continuity. You also want to know who is in the chain to understand which other organisations have access to your data and are handling it, so if there are insolvencies that you see in the press you will know whether your service is ultimately being affected. If you think years back to when the 2e2 data centre went insolvent and a lot of people suddenly became aware that they were actually involved in the contract stack that a SAAS provider was relying on to provide a service so customers did not even know that they had an issue until that insolvency happened and the SAAS provider came saying we now need to think about what we do about 2e2 because they have gone bust and actually your data was sat there, sorry you did not know about that Mr Customer. It also helps to have a technical understanding of who is doing what particularly around issues like security, different lawers of that platform. We have had different people being responsible for different parts of security and if there has been a security breach, it is helpful as a customer to know who you were actually talking to, who was responsible for that part of the security service.

We often see this supply chain issue come up in scenarios where we are engaging with large companies who are often system developers or integrators and are designing and building a service for a customer that is going to be run on a Cloud infrastructure and we ask the question, well do you actually own this Cloud infrastructure or are you prime contractor if you like using another subcontractor? You would be amazed how often the people were talking to at the prime contractor do not know the answer to that question and it takes them quite a while to come back with the answer and then when they do this they say oh yes actually there are Azure or AWS terms that we need to try and shove into our contract at the schedule which then obviously conflicts the front end terms, have different limits of liability, have different exclusions and it ends up being quite a mess. In some this transactions has caused a significant delay to what we though was nearly closed because of the length of time it has taken that prime contractor to come back with the answer to the question. So again it is something I would always ask really on, to understand are you my prime contractor going to provide this to me under some kind of umbrella agreement you have with your big Cloud providers and which you might use for lots of customers, or are you going to set up something specifically for me in which case you might be trying to pass through any risks in your Cloud service contract direct to me? I need to understand how that fits into my overall risk profile and how it fits with the rest of my contract.

Bringing all of that together it is so important at the start of any of these procurements to understand the full context about what Cloud is going to be involved in this procurement. Is it public, is it private, is it some kind of hybrid and drill down into how does it work, is it just one instance of software, lots of people are using, are we customising it, are we adding bits on to a base piece of software, how does that work? Then looking and understanding the data and the service we are going to be receiving from that provider, the data you are going to be putting into their environment, how sensitive is it, do we have other copies of it somewhere else are we always going to be able to get access to it? You can then do this risk assessment to balance the benefits and the risks of using the system and work out whether these are acceptable risks and what mitigations you might need to put in place.

You are almost inevitably going to be dealing on vendor standard terms for a lot of these systems, because they will be specific to their set up so it does mean they need reading very closely because they will always be very supplier friendly and you need to watch for things like automatic deletion of data on exit for suspension rights, or not saying anything about reusing your data in an anonymised form. Often increasingly with IT software contracts these will be layered, you'll have some master terms, you will have some product specific terms, you will have some additional terms if you are in the UK or the US so putting all that together needs really careful close review and I would always say just ask questions. Supplier standard terms do not say some things deliberately because they want freedoms or it a negotiation point that they do not want to raise, so make sure you continue to ask questions so that you can make sure that you are comfortable with all the risks and advise your business appropriately.

I have put together a list of the risks just on the final slides. You can see them all together and I am now very happy to take any questions. Helen?

Helen: so Jocelyn you talked about earlier in the presentation the risks of Cloud providers potentially wanting to use data for their own purposes. A question specifically around are you seeing clients being able to negotiate a commercial return on granting of rights to Cloud providers to use their data for analytics or AI purposes?

Jocelyn: That's something very topical because we are talking about with various clients in terms of commercialising data sets. I think specifically in a Cloud environment here, I have not seen a customer raise it with a Cloud provider. Where you are just receiving a generic service so say from sales force or someone like that,  I have not seen a customer manage to negotiate with them to say if you are going to go off and do things with my data I want a return on it, but I do think that is a much better conversation to be having than just to find out that they are doing it behind the scenes and commercialising it and you are missing out. So I definitely think it is a conversation to have but no I have not seen anyway actually be able to do that as yet.

Helen: And so there was one that is a topic related question. In your experience how do your clients feel about terms allowing anonymised use of the data?

Jocelyn: It is very sector specific and dependent on the nature of the data that has gone into the service, though some Cloud providers would say well the benefit of our service is that actually we learn things from every client we work with, we take that learning and knowledge and we put it back into our system and we improve, and that is a set part of what you are paying for when you engage with their system. So that kind of scenario people are quite comfortable with it and that is generally where it known up front that the provider re-uses sort of knowledge and expertise and data in that way. On the flip side if it not that kind of scenario and it is something that the provider wants to do more covertly, I think even if clients would not have an issue with it if they knew that was going, the fact that it was being done without their knowledge I think can be more damaging to the relationship overall and create a feeling of nervousness. I have seen a range of responses in different climbs on that but it does very much depend on sector and the type of data that you are dealing with.

Helen: Thank you Jocelyn and one question I think on a very different topic and that might be the last question that we have got time to take. This is around changes to sub-processor sub-contractor changes to those provisions and that is it appropriate for those changes to be placed on a website as opposed to proactively notifying customers?

Jocelyn: In a GDPR sense if you have given a general permission for a supplier to engage sub-processors and it says in the contract that they will notify you through a notification on a website then I think that would satisfy the criteria. I think from a compliance point of view that would tick the boxes. Proactive notification is probably something that the customer would prefer, and it depends I think on how the operator systems are set up, whether that is something they can do for customers or whether they use that website functionality or the website can then ping an automatic alert to a customer to say this has been updated. I think it does come back to whether you have given that general consent because if you have then it is possibly more up to the customer to make sure it knows what subcontractors are being used if that information is made available by the operator.

Helen: It touches on a point you made earlier about visibility of that stack. I'm conscious of time so I probably ought to bring us to a close now. The first thing to say is thank you to Jocelyn for all of your insights, really helpful. Thank you to everyone for joining us. If there are any more questions, I am sure that Jocelyn will be more than happy for you to reach out to her directly and actually as I am speaking there are a couple more questions that have come in as well so we will try and pick those up and come back to you.

The next IT Masterclass is the one that Jocelyn mentioned during the course of the session so it will be on cyber insurance and cyber security. That is on 4 November. I will be speaking at that session and will also be joined by Susannah Fink, a legal director in our commercial litigation team who is an insurance specialist so if you can make it, please do sign up if you have not already.

Thank you again.