What IT providers must learn from the air traffic shutdown

United Kingdom

This article was produced by Olswang LLP, which joined with CMS on 1 May 2017.

The connection might not seem obvious at first, but the recent trouble experienced by the UK's national air traffic service (NATS) is a timely reminder that commercial providers of IT services need to think carefully about ways to manage their exposure in the event of service interruptions.

Press coverage of the incident suggested that it was a seemingly innocuous error in a single line of code (buried within 4m lines of code) that brought London air traffic to a grinding halt last week. That so small an error could have such catastrophic consequences will come as no surprise to IT service providers, particularly those in the business of providing software as a service (SaaS), platforms as a service (PaaS), infrastructure as a service (IaaS) or, indeed, anything as a service (XaaS, in latest parlance).

If you supply software that is at the heart of another company's business and that software goes down, you have a problem. Likewise, if you provide cloud based services that host data central to another company's business and connectivity goes down, you have a problem. The IT business is risky, which means that service providers need to think about exposure management, ideally up-front when negotiating their contracts.

In the case of NATS, the vagaries of the airline industry may limit its financial exposure in a way that wouldn't be the case in a less regulated sector, where it would be at risk of claims from parties equivalent to the airlines (that lost profits by refunding fares and losing the opportunity to generate ancillary revenue - e.g. selling food and drinks on-board), airports (that missed out on landing fees, etc.) and end-users (i.e. passengers) whose plans were disrupted. It may even be liable to its direct customer for compensation paid by that customer to its own customers, to mitigate the effects of the disruption - which was recognised as a possibility in GB Gas Holdings (Centrica) v Accenture in 2009.

There are a multitude of mechanisms that service providers can deploy to manage these risks but paramount among them is a carefully drafted limitation and exclusion of liability clause in the services contract. Spelling out the types of loss for which the service provider is and is not assuming responsibility will go a long way to answering the key question in a claim for damages: is the loss that is being claimed properly recoverable? Of course, such clauses are only as good as the drafting, and the contested legal cases are littered with examples of ambiguously worded clauses being circumvented by the courts deciding what the parties "objectively intended". Even more so than with ordinary contractual provisions, limitation and exclusion clauses should be as clear and comprehensive as possible. They should also be negotiated - standard form clauses run the risk of being subject to a reasonableness test under the Unfair Contract Terms Act 1977, which could render them unenforceable.

It is also worth bearing in mind that although such clauses might define the scope of a service provider's exposure to their direct customer, they are unlikely to apply to limit or exclude liability to someone who is not party to the contract (for example, an end-user of the service that is being provided). In most cases, there will be no liability to a third party because of the absence of any direct contractual relationship, but there are circumstances where a tortuous duty of care might arise - for example, where the service provider knows that a third party will rely upon the service - in which case a failure by the service provider to exercise due care and skill might be actionable by the third party. In those cases, suppliers may look to minimise their exposure by other means, such as a full or partial indemnity from their customer against third party liability.

Taken altogether, there is much to think about for IT service providers when it comes to managing their exposure, both to their customers and the wider world. And as is often the case with these things, it is far better to do that thinking up front and deal with the problem before it arises, than to wait until some insidious line of code takes matters out of your own hands.