Cloud computing is no
longer ‘new’ (and indeed can be seen as itself being rebadged from earlier
forms of remote hosted/ASP style offerings). However, what is apparent is the continuing growth in size and sophistication of
cloud deals, both in the private and public cloud space. With this comes an
increased focus on the contractual and commercial terms, and a continuing
challenge for perceived norms on both the customer and supplier side of the
fence.
The Developing Market
For a long time, deals
appeared to mostly fall into two categories:
(a) public
cloud offerings on a ‘one to many’ basis (where suppliers showed little
appetite to depart from standard terms of business, whether because of the need
to have the contract terms reflect the common delivery model or simply by
reason of a reluctance to take on additional contract risk)
(b) private
cloud arrangements which were bespoke/specific to one (usually larger) client,
where the contract terms would be fully negotiated in much the same way as a
managed service/outsource style contract would be, and would frequently be
based on the customer’s proposed contract terms
Both of these models do,
of course, still exist and indeed have increasingly replaced more traditional
forms of on-premise licence and support arrangements. However, we have also
seen variants which can create more of a challenge when it comes to the
negotiation of contract terms. These include:
(i) ‘ERP
in the cloud’ style deals, where far more business critical systems are
proposed to be run remotely, and where the relevant software licensor is taking
on both implementation and hosting services/responsibilities for the first
time; and
(ii) private
cloud services which – whilst ‘dedicated’ to the relevant customer in the sense
that there will be discrete instances of the relevant software and very often
segregated servers/racks as well, will nonetheless be provided from shared data
centres and using shared networks, which can impact upon the supplier’s ability
to meet the specific service requirement of the customer whilst also
necessitating a few supplier mandated requirements too
So, in the light of
these developments, what forms of contractual challenges are we seeing?
Key Contractual Challenges
·
Warranty Protections
In the
context of standard contract terms sent out by vendors of public cloud
solutions (eg the likes of AWS, Microsoft Azure etc), it would be common to see
provisions whereby the service provider would warrant only to use ‘reasonable
endeavours’ to correct any non-compliance with specifications, and on the basis
that if such non-compliances could not be readily resolved, then the sole remedy of the customer would be to
terminate that aspect of the cloud service and receive a pro rata refund. A similar approach is often applied to
alleged IP infringements.
Whilst such an approach might pass muster for a ‘take
it or leave it’ commodity style cloud offering, it would clearly not be
acceptable for a customer who is seeking to use the cloud for more business
critical applications and services. Accordingly, we now commonly see the
acceptance of an obligation upon the service provider to correct warranty
defects as being independent of any separate right to claim compensation for
related losses.
·
Compliance with Laws
As the
customer will be dependent upon the cloud services provider to ensure that the
relevant services are provided in such a way as to enable the customer to
comply with its legal obligations, it is not surprising that the contract terms
related to compliance with law and regulation are increasingly subject to
negotiation (despite many cloud service providers initially arguing that all
they offered was ‘a service’ and that it would then be for the client to do the
mapping against its relevant obligations).
We
have seen a considerable deviation in approach in this regard, depending on the
nature of the cloud services (where bespoke modifications can be more readily
accommodated); for private cloud services, the service provider can
commit to maintenance of compliance with laws, and the key area of debate is
instead centred on who has to monitor and interpret the new requirements, and
thereafter bear the cost of any resulting changes. For public cloud services (and even for ‘private’
cloud services which are based on distinct instances of a particular product
which the service provider wants to keep in line with its ‘core’ product), the
willingness of the service provider to commit to compliance with laws may be
limited to those which are specific to it as a service provider, or potentially
to the laws of a particular sector or function which the cloud services are
particularly focused upon. The customer
may then face a difficult challenge in the event that sector- specific
requirements proceed in a direction which is potentially at odds with the cloud
solution it has commissioned.
·
GDPR/data protection compliance
With
data being so central to cloud-based services, data protection related
provisions receive a significant degree of attention when it comes to
negotiating the associated contract terms.
Many
of the cloud services standard terms we have seen are very carefully crafted by
the service provider so as to emphasise their role as data processor rather
than controller, and to thus emphasise the fact that the majority of statutory
obligations remain with the client (at least until the advent of the GDPR). However, many customers are wise to this and
will at least push back to get the service provider to take on the relevant
security obligations vis a vis appropriate technical and organisational
measures to safeguard data from unauthorised access or alteration.
Service
providers can point out in this regard that they will not necessarily know
what data the customer is asking them to host or process via the relevant
cloud service, and so they are in no position to judge what measures should be
taken. Indeed, it is possible that the
advent of GDPR may add a new twist in this regard, with service providers
instead asking the customer to warrant that the security
arrangements are adequate for the customer’s purposes, and to indemnify the
service provider against any future claims if they are ruled not to be!
·
Decommissioning and Disposal Costs
A
customer organisation will in the past have had to deal with the costs of
decommissioning and disposing of redundant hardware. In the context of a cloud
transformation programme, therefore, it may be tempting to leave the associated
effort and cost of this out of the equation, when calculating the business
case. However, the reality is that the pace of decommissioning and disposal
will be likely to have been relatively steady in the past (and indeed many
organisations will have delayed decommissioning and ‘sweated their assets’ for
longer than might be ideal). If therefore there is to be a ‘spike’ in
decommissioning as a supplier implements a cloud solution instead as part of a
more root and branch transformation programme, the costs associated with that
will have to be carefully considered, and budgeted for accordingly. For example, might the supplier incur the
costs initially, but on the basis of amortising them across the lifetime of the
contract thereafter to mitigate against the customer’s cashflow hit?
Even in
deals thought to be ‘private’ cloud based there may still be elements of this
requirement – for example, if a service provider is servicing multiple clients
from a single datacentre, then any changes to such datacentre’s generic
infrastructure or networks would need to be adhered to by all of the relevant customers.
·
Supplier Mandated Changes
For
truly public cloud services, it is usually the case that the contract terms
will reserve for the service provider the right to make changes to the service
descriptions. Where the services are delivered communally to multiple clients
and need to evolve to remain competitive, this makes eminent sense. However, we
have increasingly seen service providers willing to modify/mitigate this
approach, eg by committing only to improve the services offered, or at
least to not make any ‘material’ reductions in what has gone before, and/or to
offer termination rights for the customer if it does not agree with the changes
being made.
On
some larger deals, we have also seen SaaS providers willing to commit to
maintain set functionality for minimum
periods, and/or to continue with an agreed upgrade/development path.
·
Suspension and Termination Rights
In
many forms of standard cloud services deals promulgated by service providers,
we have seen both termination and suspension rights drafted so as to set the
bar at a very low level, in some
cases so low that even the slightest mis-step may give rise to a loss of
service for the customer. However, as
the size and reach of cloud service offerings has expanded, customers have
increasingly focussed on the breadth of such rights and sought to narrow them;
after all, it has become the norm in outsourcing contracts for the service
provider’s sole right of termination
to be non-payment of fees, and it could be agreed that the customer’s degree of
reliance upon a cloud based service may actually be greater than for a ‘traditionally’ outsourced one (where there may
be assets, contracts and staff who can be more readily re-transferred back to
the customer or a replacement supplier).
·
Liability Exclusions
Liability
provisions is another key area of the contract where standard cloud services
seem to have ‘dialled back’ the extent of risk that they are willing to take
on. Aside from attaching the liability
limits to the fees paid for just the part
of the services which proved defective (rather than the charges as a whole), we
have seen blanket exclusions of data related losses, applications of the cap to
(traditionally unlimited) IP and confidentiality related claims, and even exclusions
of losses relating to the costs of reprocuring replacement services (which must
surely be amongst the most direct of direct losses, in the context of a
termination event). A typical
justification for this approach from a public cloud service provider would be
that it would not be able to take on more significant degrees of liability as,
if something went ‘wrong’ with its solution, then the problem would probably affect multiple customers (if not all of them)
and accordingly the provider would be exposed to multiple related claims which could
literally bankrupt the service provider by reason of a single default.
·
Prime Contractor/Supply Chain Challenges
We
have seen a number of deals which in previous times may have been approached as
outsource-style contracts with a service-orientated prime contractor, who may
then subcontract or sublicense elements of the
overall solution. However, many SaaS providers are either reluctant to
accept the flow down of contract risk from the prime contract, or seek to
position themselves as the first point of contact with the customer. The risk
scenario for the former option is problematic for the prime contractor, who may
then feel ‘trapped’ between the contract
expectations of the customer and what it can flow down to the cloud service
provider (eg in terms of warranty or service-level commitments, liability caps
etc). The second scenario may equally
pose more of a challenge for the customer, who may have an unpleasant surprise
when comparing the proposed SaaS contract terms against those it is used to
achieving for similar, non-cloud based services. By way of example, we recently
advised a major client who was considering a cloud services deal valued
(potentially) in the hundreds of millions of pounds, and who was then shocked
to find the potential suppliers refusing to respond to their draft contract
terms, and directing them instead to a web link to their standard cloud
services terms, available to the world at large and where (for example) the
sole remedy for the customer in the event that the SaaS solution did not work
(after the customer would have spent tens of millions of pounds on
implementation, etc) would be to get a refund of pre-paid fees.
·
Audit Rights
An
organisation which entrusts its core functions and data to the cloud will be
understandably concerned to ensure that all of the contractually promised
safeguards are in fact being implemented.
Having an effective audit right is key to this.
In a
private cloud environment which is dedicated to a single client, this is easy to accommodate. However, the moment one ventures into
environments which are used to support multiple clients, difficulties can
emerge. The service provider will
understandably then want to ensure that any audit undertaken by Client A does
not impact upon the services it provides to Clients B, C and D from the service
data centre.
This
is sensible and reasonable. However,
recent regulatory guidance in the UK (eg the FCA’s FG 16/5 note on Cloud
Contracts) suggested that ‘unrestricted’ audit access might be required … and
it remains to be seen quite how literally this requirement/guidance will be
interpreted.
For
public cloud services, it is unlikely that any customer-specific audit right
will be granted at all. However,
customers can still expect the service provider to undertake regular generic
audits using an independent third party, such that the resulting audit report
can then be made available to all customers; we have seen this approach
taken on occasion, albeit that it is fair to say that many service providers
are still resistant to it!
Conclusion
The
business benefits of cloud solutions are so manifest and substantial that there
is ever greater momentum in favour of their implementation, and for more and
more substantial and business critical functions. However, at the same time, we are seeing a
rapid development of the contracting models for such solutions, and
particularly for private and/or hybrid cloud models, and we can expect this
state of flux to persist for some time to come.
Kit
Burden is Head of the Technology and Sourcing Group at DLA Piper and an SCL
Fellow.
If you are interested in contributing an article to SCL please read these guidelines: https://www.scl.org/about/contributing
