IT Supply Chain Issues - ThinkHouse

Jocelyn Paulley: Hello my name's Jocelyn Paulley and I am a Partner in the Commercial IT and Outsourcing Team at Gowling WLG. In today's webinar we are looking at disruption in IT contracts; that involves briefly understanding what makes up an IT supply contract or an IT stack, looking at what types of disruption might hit that and the effect that it might have and then looking at the mitigations and protections that you can include in contracts or encourage your business to think about to protect against those risks.

The one thing we will not cover today is cyber breaches. We have covered the effect of cyber breaches on an IT supply chain in other webinars.

So for IT we tend not to talk about a 'supply chain' but a 'stack', representing the idea you have a number of services that effectively sit on top of each other to provide an end user with the functionality that they access through a piece of software, so you have the SaaS layer which is an application running on top of one or more platforms which could be things like a Facebook or an SAP or at a lower level an operating system on a server. You then have the infrastructure which is the servers and the hardware also often provided as a service and then at the bottom of the stack you have the datacentres and the power so the physical locations from which these environments are run.

The key difference here with a physical product supply chain is that all of these have to be operating all time in real time at the point at which the user wishes to engage with an IT solution unlike a product supply chain where a product is passed along over a period of time before it gets to the end user.

So in order to assess the risks of that stack you need to know factually who is part of it, so doing due diligence on a stack to establish the nature and the names of the companies that are part of that stack, to understand what part of the services each of them provides because that might be significant for things like security considerations and where in the world they are providing it from because it might be a simple buying decision that you do not buy services from a particular territory, maybe because of the sector rules or because you are concerned about unrest in that country, or because you are concerned about other regulatory impacts or even issues like enforcement and clearly the level of diligence that you carry out will depend on whether you are buying a pre-existing IT stack which comes to you as it is and you take it or leave it if you do not like the risks or whether you are building a bespoke product and you can be more selective about the players in that stack.

So what types of disruption could affect an IT supply chain? Obviously someone becoming insolvent where the effects on the service might either be that you simply cannot access the service you have procured or that you can access it but the data that should be sat within it is not there because it is being held by someone hosting the data lower in the stack and may be they are the one who has become insolvent.

Issues we see there are where liquidators trying to extract value for a business hold customers to ransom in order to access their software and their systems or we see parties terminating contracts with suppliers although ultimately that probably does not mitigate against the effect of the insolvency.

Force majeure is something we have talked about a lot more over the last couple of years than we ever thought we would, arguably has less immediate impact on IT supply chains given that this is automated software that can run without human intervention but there are of course issues around support and development of environments where you do need that human input so after time there will certainly be some impact. Contractually there is obviously relief for the party affected by the force majeure event and losses lie where they fall so it does not actually help parties mitigate if they are affected by a force majeure.

Licence infringements are bespoke and unique to IT environments. The effects will vary depending on the nature of the infringement and the nature of the software that it affects. Contractually these scenarios are well dealt with and in some level of detail where there will be obligations on suppliers to try to find workarounds to mitigate the effect of the infringement. If that cannot be done a customer may have a termination right and there is usually financial protection for a customer through an indemnity, certainly against the third party infringement claim and potentially also the wider damage to their business.

And finally poor service performance, sort of more normal disruption, catered for in a contract through service levels with credits payable if there is a breach and often a termination right for a material service level failure.

So once you have done your due diligence to assess the nature of the stack that you are buying, the players in that stack and what the particular risks are in your scenario you can then think about a range of mitigations and protections to try to handle those risks. Not all of these will be relevant in all scenarios and not all will be suited to all risks but it is a good idea to have an overview and to think of all the questions that you might need to raise with suppliers early on in a procurement so that you can work out which of these are appropriate contractual protections you want to include in terms and which are things that the business need to be aware of and to build into their operations going forwards.

So firstly escrow, this is where you have a specialist escrow provider and a tripartite agreement between them, the licensee and the licensor where the source code to the software is held by the escrow provider and released on certain trigger events. The risk with escrow is always that the source code which is held in escrow is either not up to date or is deficient in some way and does not actually enable you to stand up to the environment again and to run and operate the software or that the documentation is not sufficiently detailed to understand someone coming to the software cold to tell them how to operate it.

In a SaaS environment to the additional consideration is the data that is held within that environment. A traditional source code SaaS agreement will not also pick up the data that is being handled by the system, escrow providers are aware of this and have amended terms and come up with new agreements where they will take cuts of the data from within an environment and keep those in escrow in the same way as they would the source code but you would obviously need to have entered into the right terms with escrow providers for that to happen.

Escrow is a very useful interim solution but it is interim. It is designed to ensure that at the point at which a supplier fails, customer can continue to use software but ultimately the intention would be for a customer to re-procure and buy a solution from the supplier that is still existing in the market.

You could look to more operational types of resilience so understanding from the supplier how their system is specified and how it has been built because sometimes you find there is resilience inherently within the way they are built; that looks different at different levels of the stack and commercially there might be an impact as well. If it is built into a service it might be a more expensive service or there may be cheaper services where there is an optional extra to have that level of resilience there in the background.

There is clearly a crossover there with disaster recovery and business continuity plans where you do see, in larger contracts, requirements on suppliers to have those plans so it is effectively built into and part of the service that the customer is paying for. Contracts often give some clarity on those plans being created and signed off by customers and tested with some frequency so everyone has confidence in how they will apply and sometimes the contract also speaks to the customers own BCP and DR plans to require the supplier to engage in those exercises so the customer can see from a holistic point of view across its IT estate how those disasters might affect and how the exercises might run.

Also important in this context are back-ups of data, something that is often not well documented in contracts and may be something that a supplier does do again as part of their resilience and the nature of their service, but it is advisable to have the conversation so you have certainty whether it is something the supplier has built into their service or whether that is something that the customer ought to be doing manually through the supply system or something that can be added on and bought in addition and then obviously contractualised so you know at what points data will be backed up and how long those back-ups will be kept.

Step-in is a measure you will often see in larger outsourcing contracts, a useful looking protection for a customer to have comfort it could actually takeover a service for an interim time if a supplier appears to be unable to deal with a particular issue. Not such a useful remedy and difficult in a Cloud environment where there is a shared infrastructure and you are not the only customer using that service as most customers will not suddenly want to find they are responsible for providing that Cloud service to other customers in equivalence of their positions and also because the best you can normally hope for is to achieve a step-in at a management level so still using a supplier's employees at a lower level and their resources, their systems, because it would not be possible for a customer to suddenly spring all of that up and operate it itself.

I think exit provisions are a really important mitigation to help facilitate a smooth transfer from an outgoing to an incoming supplier because if you have those obligations in the contract there is a clear path as to what both parties are expected to do and need to contribute and even more useful if the clauses sets some principles around pricing so that at this point where the customer has little commercial leverage over its outgoing supplier there is not a difficult conversation about fees for exist also because the customer really does need their outgoing supplier to engage at this point to help make that exit as smooth as it can be. So important to have clauses that set out the key activities each party will need to undertake and possibly even more importantly the documentation that the supplier will provide to the customer, so documentation being descriptions of services, operational manuals, user guides, so the customer has a good degree of detail about what has been provided previously or important touch points with the customer that they can pass over to an incoming supplier.

Talking about data again, provisions setting out return of data are key so it is clear how the customer gets its data back within its possession and in what format it is in, so it is something the customer can easily re-use and re-integrate and the timing of when that would happen and this is one to watch for in supplier standard terms where the usual provision is you will see the supplier having a right to delete customer data within a period following termination which if you read between the lines means that the customer actually needs to go in and itself take a copy of its data before that deletion happens.

Often in a supply chain a customer will try to protect itself by flowing down provisions, particularly policies around things like security or sustainability or anti-bribery, but if you are buying into an existing SaaS then all those things will already have been set and built by the SaaS provider and the customer must instead ask for how those things are dealt with in that supply chain and review those policies and then decide whether or not it wishes to buy the SaaS as a whole.

Also though important to be alive to the fact that terms might be flowed up through a chain particularly in a situation where a customer is creating a bespoke environment, suppliers at the top end of that chain will have relationships with others lower down the chain and if it is not something holistic that is being packaged up and put out to the market then it is quite common for those top end level suppliers to flow up terms from the lower level suppliers and this can often happen quite late in the negotiation and those terms tend to contain different warranties and exclusions and liabilities which cut across the terms you have been negotiating to date and upset the flow of the negotiation.

Flow down is also important operationally not just legally particularly in areas like service levels for support. A customer will want comfort that if there is a priority one event that needs dealing with in a very short period of time that they can see how that obligation flows down a supply chain so each supplier is bound to come back within a timescale that rolls up altogether to still being a short remedy period for the customer.

And finally there are self-help provisions that customers can undertake outside of the contract and I have mentioned a few already such as proactively accessing data held by a supplier and taking their own copies. If systems are particularly significant it could still be commercially worthwhile for a customer to have an alternative supplier contracted with some kind of standby system or taking copies of systems at intervals such that it could be stood up if required, and again the documentation. We often put clauses in contracts requiring suppliers to provide a customer operations manual or specifications of their systems so customers have some detail on how those things operate if that supplier were to fail.

So the takeaways from the sessions are to do your due diligence on your IT stacks, you understand who is involved and where in the world they are and what they are providing, so you can work out what the risks might be in your particular context and then think about what the appropriate mitigations are and include the right terms in your contracts.

That is all very well for new procurements but for all of your existing estate my advice would be to do due diligence now so you have a good register and oversight of what suppliers you are using and where in the world they are so that when these unexpected events happen and the business come needing to know how, well does this affect us before how it affects us, you have a clear point of reference that you can go to that saves all those initial questions being asked under a lot of time pressure and make a smoother way to providing some certainty for the business.

Thank you.