With the promise of cost savings, greater flexibility and ability to scale, it is not surprising that companies are continuing to move their key business applications and data to the cloud. However it is important to consider potential concerns. In this article we look at 5 key issues you should consider when negotiating cloud contracts.
Introduction
While the cloud is hardly a new phenomenon, we have seen the transition to the cloud accelerate in recent years as the continued growth in the digital economy puts older business models under pressure, with particular challenges for companies who are unable to respond in an agile manner.
Having acted for many clients on strategic cloud transactions, there are a number of issues that we have seen cropping up with increasing regularity. In this article we look at a number of these issues and share some insights into how negotiations on these issues typically play out.
Set clear boundaries around vendors’ rights to access and use customer data.
1. Vendor use of customer data for analytics
A cloud vendor will typically seek rights to collect and use data about how their customers interact with their products and services. This data can help the vendor identify potential product improvements and, over time, deliver better and more useful or cost effective services to all of their customers.
Each individual customer, therefore, stands to indirectly benefit from this activity.
So where does the issue lie in this apparent win-win scenario? Well, often the vendor will frame its data rights very broadly. It may not always be clear where the limits lie, with ambiguity as to whether the vendor’s rights may extend to the customer’s own input data (as opposed to data generated by the vendor in the course of providing services for the customer) or to the use of the customer’s data for external purposes. Customers should be rightly wary of the ‘value leakage’ that they may experience if their cloud vendors have free rein to use their data.
In particular, customers should ensure that the cloud vendor’s right to access and use data is limited to:
- use for the vendor’s internal business purposes, ideally for the sole purpose of improving the vendor’s service offerings (and not for any commercialisation or other external use); and
- data about the customer’s interaction with the vendor’s service (and does not extend to the customer’s own data) in a form that is anonymised and aggregated and not capable of identifying the customer or its clients.
Consider vendor compliance costs – agree what can and can’t be passed on to the customer
2. Cost of complying with customer directions
It is fairly common for customers to require vendors to comply with their directions and policies. This might include compliance with the customer’s supplier code of conduct, health and safety policies and privacy policies and so on.
That may not be a problem for vendors that are delivering a fully customised service for the customer, where there are no technical constraints on the level of customisation and the cost of new customisations can be built into the service charges. However, it is problematic for cloud vendors whose business model may well depend on them being able to offer essentially the same service to multiple customers. In those cases a change for one customer to give effect to a customisation may break the business model or have flow on implications for a range of other customers.
There are a number of ways in which this may play out. The vendor may counter that they will comply with their own internal policies, which the customer is welcome to review in order to get comfortable that they are suitable for the customer’s risk profile, but that they cannot agree to different policies for individual customers. The customer may then want some contractual protection against the vendor changing its policies in a way that may have a material detrimental impact on the customer’s interests.
Alternatively, a more co-operative vendor may agree to comply with the customer’s existing policies after completing their own review to confirm that the customer’s policies are consistent with and do not require anything different to the vendor’s own internal policies. In that case, any subsequent changes by the customer will likely be subject to further negotiation / agreement. If the vendor agrees to comply with a customer policy, or subsequent change, that is materially different to its own then it will likely seek to recover the cost of doing so along with a right to refuse to comply (or to cease to provide the service) if the change would have a material impact on the vendor’s broader operations (e.g. by compromising platform security or creating a conflict with commitments to other customers).
Of course, a customer may not relish the prospect of additional compliance-related costs above the vendor’s ordinary service charges. In order to strike a fair balance, the customer should consider:
- applying a materiality threshold so that niggling or incidental costs are not passed through;
- requiring that the vendor substantiate any costs for which they are seeking recovery along with an express commitment to mitigate those costs where possible; and
- imposing a limitation on recovery of costs for changes that should be considered an ordinary cost of business for the vendor. The customer should not be subsidising costs that the vendor would have had to incur even if they weren’t providing services to the customer. For example, if there are changes that are necessary for the vendor to comply with a new law, or with a new industry standard or regulation, or simply in order to maintain alignment with industry practice, then the cost of those changes should be absorbed by the vendor rather than passed through to the customer.
Use super caps and sub caps to appropriately manage vendor liability.
3. Super caps for key categories of liability
Over the past few years, we have seen an increased push by vendors to cap their liability for certain categories of loss, including for privacy and data-related breaches.
While customers may have traditionally pushed for uncapped liability in these areas, the risk of large fines and other substantial damages, and the increasing cost of insurance, means that it may not be commercially viable for vendors to take on this risk in full. In addition, the vendor may take a principled approach that it is not appropriate for a customer to seek to externalise this business risk in its entirety simply by transitioning to a cloud environment.
Often the compromise is for the parties to agree on a separate ‘super cap’ or ‘sub cap’ where specific categories of liability are dealt with separately from other liabilities under the cloud contract. These separate caps may be either set by reference to a fixed dollar amount or to a proportionate measure, such as a multiple of fees paid or payable under the agreement or an applicable SOW, either over the life of the engagement or over a specific time period. The drafting of these liability arrangements, including the interaction with general liability caps, can be complex and will need to be carefully reviewed. As well as being wary of drafting traps, the customer will need to take care to ensure that:
- the caps that are specified are sufficient to provide meaningful protection for the customer in a ‘worst case’ breach scenario and if not, whether the customer’s own insurance can make up for the shortfall; and
- any exclusions in the contract do not present a bar to the customer recovering the most common types of loss that are likely to arise from a privacy or data-related breach, such as regulatory fines, customer claims, and costs of notifying end users and undertaking remedial works (e.g. restoring lost or corrupted data).
Be clear on who should be responsible for regulatory compliance costs.
4. Responsibility for regulatory compliance
When providing an industry-agnostic product, vendors have traditionally taken the position that the customer must remain responsible for ensuring compliance with industry-specific regulations. That can present a barrier to customers in heavily regulated sectors (e.g. financial services and energy) taking up new technology solutions.
However, where a vendor is specifically targeting a particular industry, or is offering a vertical offering specifically created to meet a particular business need within a specific industry sector, customers are increasingly expecting that vendors will at least share responsibility for compliance. It is reasonable to expect that the vendor will take on some of this burden and indeed to some extent it will become a price of entry as regulated customers may otherwise be blocked from engaging with the vendor. For example, we see customers increasingly gaining traction in seeking to flow down incident notification and other cyber security compliance obligations that arise under regulations such as the APRA Prudential Standard CPS 234 and Security of Critical Infrastructure legislation.
More mature vendors may even have their own pre-prepared contractual addenda that are designed to address regulatory concerns in specific sectors that they are targeting. In other cases, the customer may have a greater role to play in educating the vendor about the particular regulatory challenges they face. Either way, regulated customers need to take care that by engaging with a cloud vendor they will not be creating an insurmountable compliance gap.
To avoid information security standard standoffs, bring customer and vendor security specialists together early.
5. Tension between competing information security requirements
As cyber security remains a top level concern for many businesses, we have seen customers develop increasingly sophisticated internal information security control frameworks and requirements. However, when a customer attempts to impose its own internal requirements on a cloud vendor there is often tension. Most cloud vendors will have their own information security requirements that they follow and there may be little scope for them to change to suit individual customer needs.
Instead of engaging in a ‘battle of the forms’ the more productive path is often to encourage the information security experts on both sides to sit down together to map out how the customer’s internal requirements fit with the cloud vendor’s requirements. In many cases there will be significant overlap and, hopefully, alignment. Where there are divergences, the experts can then work together to assess whether they are material and if so whether there are operational work arounds or solutions that will address the customer’s requirement without breaking the vendor’s business model. This can be a painstaking process and it is important to commence the engagement early, as we have on multiple occasions seen an otherwise orderly negotiation almost be derailed when information security concerns are raised for the first time shortly before signing.
This is by no means an exhaustive list. However, we hope it will provide some useful pause for thought in your next cloud negotiation. We love talking all things cloud, so if you need help or would like to share some of the trends you have observed, give one of our Tech Law team a call.
Ever explored the prospect of entering the Chinese cloud market? The KWM China tech law team recently wrote on how international companies can understand and explore the opportunity China.
