How I approach cloud contracts negotiations

I’ve been negotiating the legal aspects cloud service contracts for over 15 years. In most negotiations, I represent an SME vendor selling to a corporate customer. In this post, I highlight the principles that inform my approach these negotiations.

There won’t be much here of interest to experienced negotiators, but if you are new to this type of contract negotiation this post should give you an idea of what to expect; it may even help you to avoid some pitfalls.

Standardisation vs corporates

Standardisation is a basic aspect of cloud-based software services.

  • Standardisation of code means more features and more thorough testing of those features. 
  • Standardisation of security and resilience should, all else being equal, mean better security and resilience. 
  • Standardisation of implementation, training, support and service levels promotes efficiency, reducing cost and – in a properly functioning market - price. 
  • Last and perhaps least, standardisation of legal documentation should reduce legal fees and contract negotiation periods.

Corporates recognise the benefits of cloud services; they are however the sworn enemies of vendor standardisation. They often need special integrations and custom features. Their “non-negotiable” security and data processing policies often require that vendors submit to awkwardly specific rules and procedures. They want to define what services they will receive, when and how. As often as not, they have the money and bargaining power to get what they want.

The tension between the benefits of standardisation and special corporate requirements plays out in most cloud contract negotiations. For the lawyers, the issue first arises when selecting the base document for the contract negotiations.

On your marks

The choice of base document for contractual negotiations is, almost always, the biggest single influence on the outcome of legal negotiations. 

Lawyers and other contract professionals are expensive, and for all but the largest contracts external legal fees and/or internal legal resources will limit the person-hours spent on negotiations. Accordingly, the parties will focus on the key issues; and that will mean ignoring much else.

It follows that, in every case, vendors should try to persuade corporates to start with the vendors’ own standard T&Cs of service. This will be acceptable to some corporates in some circumstances, but often they will insist on providing the initial document, typically in the form of a master services agreement (MSA). 

Where an MSA is used, the corporate legal department will rarely put in the effort to adapt their own standard MSA to the vendors’ service; that will usually be the job of the vendor’s legal team. So, corporates accept that there will be some level of negotiation; they won’t usually insist upon using their MSA in unamended form.

That is not to say that corporates are generally flexible in negotiations.

A degree of inflexibility is to be expected. If a customer is being systematically unreasonable in contract negotiations, that may be a red flag, highlighting the possibility of systematic unreasonableness elsewhere in the relationship. However, advisers should take care not to identify unreasonableness where there is only a strong bargaining position, or a misunderstanding of the nature of the service, or bureaucratic inflexibility.

Changing MSAs

Ten years ago, the majority of MSAs that came across my desk were not adapted for cloud services. They often included radically inappropriate clauses, particularly in relation to licence scope and IPR ownership. Nowadays, however, MSAs usually take some account of cloud services, and some corporates use cloud service-specific versions of their standard MSAs.

Principles

Whether marking-up a corporate MSA or reviewing a corporate mark up of vendor T&Cs, there are seven principles that govern how I handle corporate contract negotiations.

The standardisation principle – In deciding to sell to corporates, a vendor will usually already have abandoned strict standardisation. However, that doesn’t mean that customer-specific processes and procedures are a good thing. To get the best result for a vendor, I need to know which elements of standardisation are up for negotiation, and which are not.  Typically, standardisation of legalistic clauses (e.g. of warranties, limits of liability or indemnities) is less important than standardisation of clauses which affect how a service is provided (e.g. SLAs). 

The minimisation principle – Legal negotiations with corporates involve protecting the client whilst making the minimum changes possible to the document. My clients will almost always ask for changes to be kept to a minimum; even if they don’t, I do - unless there is a good reason to do otherwise. In the context of cloud negotiations, this principle is in direct opposition to standardisation. Standardisation may be a good reason to resist minimisation.

The justification principle - Every change should be justified. Except for corrections of obvious errors, don’t assume that your opposite number will be able to intuit the reasoning behind a change.  Avoid justifications based on a business’s internal policies. Whilst mutuality can be a good basis for a change, avoid justifications based on generalised desires to improve the position of the vendor under the document. Improvement of a vendor's position may not be persuasive from a customer perspective!

The mitigation principle – This is an extension of the minimisation principle: rather than removing offensive drafting wholesale, it is often better to add extras or carve-out exceptions.  Also, the more specific a change is, the easier it will be to justify that change.

The deferment principle – In appropriate cases, take changes out of scope of the MSA. For example, the desired changes could be set out in an order or statement of work. Whilst the MSA may go to legal review, individual orders or SoWs may not. Large organisations need to be more concerned than small organisations about self-governance. Accordingly, they may accept a clause applied to specific circumstances that they will not accept as a default.

The charging principle – Wherever acceptable to the vendor, a corporate requirement to perform some ancillary obligations (such as co-operation with audits, provision of information or exit-related work) should be retained, subject to the vendor being entitled to charge the customer for the service. Again, a desire for standardisation may override this.

The risk principle – Avoid making changes to customer drafting, even to highly offensive provisions, if it doesn’t present any material risks to the vendor. In considering what presents a risk and what does not, ask the vendor about how the relationship may change in future. Also consider likely changes in the legal environment: the law governing technology contracts is more mutable than some other areas of law. 

Principles in practice

The standardisation principle is in direct conflict with the minimisation, mitigation, deferment and charging principles. For me, the right approach to a negotiation is the one that balances the principles in the way that brings the most benefit to the client.

Ultimately, what matters most, most of the time, is that vendor wins the contract. For this reason, standardisation usually falls before the other principles; and for this reason, it is well worth spending time trying to persuade corporates to use of the vendor’s standard documents as the starting point for negotiations.

If you're looking for a contract template relating to cloud services, see our cloud services T&Cs and SaaS T&Cs on Docular. The former are designed for standardised services, the latter for more flexible services. In relation to corporate customers, the more flexible SaaS T&Cs will typically represent a better starting point. 

Add new comment