Liability Caps in Technology Contracts: Market Ranges and Negotiation Guide

Limitation of liability clauses are not boilerplate in technology contracts. They decide how risk is allocated if software fails, data is mishandled, an implementation overruns or a customer suffers operational disruption.

This guide explains how liability caps are commonly structured and negotiated in SaaS, software and IT services contracts under English law, including market ranges, UCTA reasonableness, excluded losses, data protection, cybersecurity and IP risks.

Introduction

Limitation of liability clauses are often among the most heavily negotiated provisions in technology contracts. They determine how much money may be recoverable if, for example, software fails, an implementation overruns, confidential data is mishandled, an integration breaks, or a customer suffers operational disruption.

In simple terms, a liability cap is the maximum amount one party can be required to pay if something goes wrong under the contract. For founders, scale-ups, technology suppliers, SaaS providers, IT consultants, enterprise customers and investors, these clauses are not boilerplate. They are commercial risk-allocation tools.

A well-drafted clause can keep exposure proportionate to the contract value, available insurance and the supplier’s margin. A poorly drafted clause can leave one party exposed to disproportionate claims, or leave the other with little practical remedy.

In English law contracts, the starting point is freedom of contract. However, that freedom is not unlimited. Certain liabilities cannot lawfully be excluded or limited, while others can only be limited subject to statutory controls, including the Unfair Contract Terms Act 1977 and, in some cases, the Misrepresentation Act 1967. Unclear wording may also be interpreted in a way one party did not intend.

For technology contracts, the key question is rarely, “What is the standard cap?” The better question is: “What cap makes commercial, legal and insurance sense for this particular contract?”

Why liability clauses matter in technology contracts

Technology contracts can create losses far greater than the fees paid. A SaaS subscription worth £30,000 per year might support important operational functions, and a serious failure may cause disruption well beyond the subscription value.

This mismatch is why limitation clauses are negotiated so closely. Suppliers want to avoid unlimited exposure for services priced on limited margins. Customers want to know that, if the supplier’s failure causes serious harm, the contract gives them a realistic route to compensation.

Technology contracts also involve layered risks. A single arrangement may cover software licensing, hosting, support, implementation, data processing, cybersecurity, intellectual property, confidentiality, service levels, third-party integrations and professional advice. The appropriate cap for ordinary service failures may therefore differ from the appropriate cap for data protection breaches, confidentiality breaches or IP infringement.

Drafting detail matters. Small differences can affect whether a cap applies once, separately to each claim, annually, by cause of action, by category, or to all claims in aggregate. That is why the mechanics of the clause matter as much as the headline figure.

Common commercial positions

There is no fixed market standard for liability caps in technology contracts. The appropriate position depends on the contract type, bargaining power, deal value, customer dependency, available insurance, data risk and whether the terms are negotiated or imposed as standard terms.

The following are common commercial positions in business-to-business technology contracts, not legal standards:

• Low-risk SaaS and standard subscriptions: suppliers often propose a cap equal to fees paid in the previous 12 months. For platforms with multiple modules or tiers, the cap may be limited to the amount paid for the affected service.
• Mid-market software and IT services: caps often sit between 100% and 200% of annual fees. Customers may push for more where implementation risk is meaningful, downtime could cause significant disruption, or the supplier controls key technical outcomes.
• Implementation and transformation projects: bespoke development, ERP implementation, digital transformation and migration projects usually need more careful treatment. A cap based only on annual fees may be too low where the main risk arises during implementation. Caps may instead be tied to total project fees, committed fees, milestone payments, a multiple of fees, or separate implementation and support caps.
• Data protection, confidentiality and cybersecurity: these risks are often carved out from the general cap or given a higher separate cap. The appropriate position depends on the parties’ roles, data sensitivity, security obligations and available insurance.
• Intellectual property infringement: customers often ask for IP infringement indemnities to be uncapped or subject to a higher cap. Suppliers usually seek to cap this risk, exclude customer-caused infringement, and control the defence and settlement of any claim.

These commercial positions are only starting points. A “market” cap can still be wrong where the contract involves sensitive data, mission-critical systems, regulated operations, aggressive deadlines or unusually low fees relative to the customer’s potential loss.

Liabilities That Cannot Be Excluded or Limited

Some liabilities cannot lawfully be excluded or limited, while others can only be limited if statutory controls are satisfied. Under UCTA, liability for death or personal injury resulting from negligence cannot be excluded or restricted. Any clause attempting to do so will generally be ineffective.

Liability for fraud cannot be excluded by an effective contractual clause. The same is generally true for fraudulent misrepresentation. For that reason, contracts commonly state that nothing in the agreement excludes or limits liability for fraud, fraudulent misrepresentation, death or personal injury caused by negligence, or any other liability which cannot lawfully be excluded or limited.

This carve-out wording helps avoid arguments that the cap was intended to apply to liabilities that cannot lawfully be capped. It also shows that the clause is aimed at legitimate commercial risk allocation, not avoidance of core legal responsibility.

Other liabilities need more nuance. Liability for negligence causing financial loss may be limited, but the wording may need to satisfy the UCTA reasonableness test. Clauses limiting liability for misrepresentation also require care: under section 3 of the Misrepresentation Act 1967, terms excluding or restricting liability for misrepresentation, or limiting remedies for it, are only effective if they satisfy the UCTA reasonableness test. In practice, the wording should be specific, proportionate and justifiable.

UCTA and the Reasonableness Test

The Unfair Contract Terms Act 1977, usually known as UCTA, is central to many business limitation clauses. Where UCTA applies, the relevant exclusion or limitation must satisfy the statutory reasonableness test.

UCTA is particularly important where a party contracts on standard terms. Many technology suppliers use standard SaaS terms, online terms of service, order forms and master services agreements. If those terms heavily restrict the customer’s remedies, the supplier may need to show that the restriction is reasonable.

Reasonableness is fact-sensitive. Relevant factors can include:

• the parties’ relative bargaining power;
• whether the customer knew, or should have known, about the term;
• whether the customer had a real opportunity to negotiate;
• whether the overall bargain was fair;
• whether the supplier could insure against the risk.

Wide exclusions will not always be upheld simply because the contract is business-to-business or the parties are commercially sophisticated. The broader the exclusion, the greater the risk that a customer will argue it has been left without any realistic remedy.

For suppliers, the point is not to avoid caps. It is to draft them with evidence and commercial logic in mind. A supplier is in a stronger position if it can explain why the cap is proportionate to the fees, scope of service, risk profile, insurance and price offered.

How Liability Caps Are Structured

A liability cap can be drafted in several ways, and the structure often matters as much as the amount. Ambiguity can lead to disputes, particularly where there are multiple breaches, claims or contract years.

Whether a cap applies to claims “under”, “in connection with”, or “arising out of” a contract depends on the wording used. These phrases may affect the scope of the cap, especially where claims are brought in contract, tort, misrepresentation, indemnity or breach of statutory duty.

Common structures include:

• Aggregate cap: one maximum amount for all claims under the contract, or all claims within a defined category. This gives suppliers certainty over total exposure, but customers may object if one early issue could exhaust the cap.
• Per-claim cap: a separate cap for each claim. This can favour customers, but may create arguments about whether multiple issues are separate claims or part of the same claim. Suppliers often resist this unless there is an overall aggregate ceiling.
• Annual cap: a cap applying by contract year, often by reference to fees paid or payable in that year. This can work well for ongoing SaaS, support and managed services contracts, but may be less suitable for one-off implementation projects.
• Fees-paid or fees-payable cap: a “fees paid” cap may be very low early in the contract, just when implementation and onboarding risk is highest. A “fees payable” or committed fees cap may produce a different commercial outcome.
• Separate higher caps: higher caps are often used for confidentiality, data protection, cybersecurity, IP infringement, indemnities or regulatory losses. This allows ordinary contractual liability to remain proportionate while giving the customer greater protection for higher-impact risks.

The High Court’s decision in Drax Energy Solutions Ltd v Wipro Ltd illustrates how much turns on precise drafting. The court treated the wording as imposing a single aggregate cap, limiting Wipro’s liability to about £11.5 million for all claims. The case underlines the need to state clearly whether a cap applies to all claims collectively, to each claim, to each contract year, or to each category of liability.

Losses Commonly Excluded in Technology Contracts

Technology suppliers commonly exclude certain categories of loss. These exclusions usually sit alongside the financial cap and can be more important than the cap itself. A high cap may offer limited protection if the customer’s most likely losses are excluded.

Common exclusions include loss of profit, revenue, anticipated savings, business, goodwill, business interruption, and indirect or consequential loss. Business interruption losses need careful treatment because, depending on the wording and facts, they may be direct or indirect. Loss or corruption of data is also often excluded, although restoration or recovery obligations are often negotiated separately.

In English law, “consequential loss” usually means loss falling within the second limb of Hadley v Baxendale, not every loss that follows from a breach. A supplier may think it has excluded all major commercial losses, while a customer may still expect to recover foreseeable direct losses.

Customers should check whether the contract expressly preserves or excludes wasted expenditure, replacement system costs, migration costs, additional staff costs, workaround costs and data restoration costs. If the supplier will not accept exposure for lost profits, wider business interruption or other categories of loss, the contract should say so clearly.

How Customers Should Negotiate Liability Caps

Customers should start with a practical question: if the supplier materially fails to perform, what protection do we actually have? The answer depends on how important the system is, what losses are likely, and whether the exclusions remove the remedies the customer would need.

A low cap may be acceptable for peripheral software. It is more problematic where the system supports customer service, regulated reporting, payment flows, stock management, clinical records, financial records or core operations. A cap of 200% of fees may still have limited value if loss or corruption of data, business interruption, wasted expenditure and replacement costs are excluded.

Practical negotiation points include:

• Ask for risk-based higher caps: a modest cap for ordinary service failures may be acceptable if higher caps apply to data protection, confidentiality, security and IP infringement.
• Protect implementation risk: in development or implementation projects, a cap based on fees paid in the previous 12 months may not reflect the customer’s wider project investment. Total project fees, committed fees or an implementation-specific cap may be more appropriate.
• Test real scenarios: if the platform is unavailable, data is corrupted, or workaround software is needed, the contract should make clear which losses and costs are recoverable.
• Review insurance evidence: insurance should not automatically dictate the cap, but it is relevant. Customers may ask what cover is held, what risks are covered and whether project-specific cover is available.

Customers should not assume that “market standard” means “safe”. Market positions are often shaped by bargaining power, not the customer’s specific risk profile.

How Suppliers Should Negotiate Liability Caps

Suppliers have legitimate reasons to limit liability. Most technology suppliers price their services by reference to subscription fees, usage, support commitments and anticipated margin, not on the basis that one customer contract could threaten the whole business.

The best supplier-side strategy is to present a position that looks fair, insurable and commercially justified, rather than simply insisting on the lowest possible cap.

Suppliers should consider:

• Align the cap with pricing and scope: if the customer wants a higher cap commensurate with deal size, risk profile and insurance cover, the price may need to reflect that. A low-fee SaaS subscription will often justify a lower cap than a bespoke, mission-critical outsourcing arrangement.
• Use separate caps: a single low cap for all liabilities can create customer resistance and may be vulnerable if it leaves serious breaches with little practical consequence. Separate caps for general liability, data protection, confidentiality and IP can be more balanced.
• Keep wording consistent: avoid mixing references to “claims”, “liability”, “events”, “causes of action” and “contract years” without explaining how they interact.
• Preserve operational controls: for IP indemnities, data incidents and third-party claims, suppliers should usually require prompt notification, control over defence, customer cooperation and exclusions for misuse or unauthorised modifications.

Suppliers using standard terms should be especially careful. If a limitation clause appears overly one-sided, particularly where the customer had little realistic ability to negotiate, it may invite challenge under UCTA.

Data, AI and cybersecurity

Data protection, cybersecurity and AI have made liability clauses more complex. Customers are concerned about regulatory exposure, operational disruption and reputational harm, while suppliers are wary of open-ended liability for incidents involving customer systems, third-party infrastructure, user error or sophisticated cyberattacks.

Where personal data is involved, the liability clause should align with the data processing agreement. It should state whether data protection liabilities fall within the general cap, have a separate higher cap, or are uncapped. The same applies to cyber incident response costs, regulatory support, notification costs, forensic investigation and remediation work.

AI-related contracts require particular care. If software produces outputs used in decision-making, content creation, customer support, recruitment, finance or compliance, the parties should allocate responsibility for inaccurate outputs, biased outputs, IP infringement allegations, misuse of training data and failure to follow usage restrictions. Standard SaaS limitation wording may need to be adapted.

The answer is rarely to make every AI or cyber risk uncapped. A better approach is to map the risk and allocate it clearly. For example, a supplier might accept a higher cap for losses caused by its failure to meet agreed security controls, while excluding liability for the customer’s unauthorised use, weak access controls or failure to apply recommended settings.

Common mistakes

Many disputes over limitation clauses arise not because the parties failed to negotiate, but because they focused on the headline cap and missed the definitions, exclusions, carve-outs and mechanics.

Common mistakes include:

• treating the cap as the whole answer, without considering exclusions of loss, indemnities, service credits, warranties, insurance, termination rights and data processing obligations;
• using unclear cap mechanics, such as “per claim”, “per event”, “arising from”, “related claims” or “in aggregate”, without explaining how related failures are grouped;
• copying US-style wording into English law contracts, where concepts such as consequential damages, indemnities, warranties and statutory controls may operate differently;
• assuming UCTA is irrelevant because the contract is business-to-business;
• relying on insurance without checking whether the policy actually responds to the relevant risk.

If the supplier relies on insurance to justify its cap, the contract should be checked against the actual policy. Professional indemnity, cyber, public liability and technology errors and omissions policies may have exclusions, sub-limits, notification requirements and territorial restrictions. A contractual cap that assumes cover exists may be dangerous if the policy does not respond.

Negotiation strategies that work

The most successful negotiations usually move away from positional bargaining. Rather than one side saying “one times fees” and the other saying “unlimited liability”, both sides should identify the risks that justify different treatment.

A sensible negotiation often starts with a risk table:

• What could go wrong?
• Who controls that risk?
• What is the likely loss?
• Is the risk insurable?
• Is the fee sufficient to justify the exposure?
• Has the customer created any dependency that the supplier cannot reasonably underwrite?

For example, a supplier may fairly argue that it should not be liable for the customer’s entire lost profits if the customer chooses to run its whole business on a low-cost SaaS tool without buying enhanced support. Equally, a customer may fairly argue that a supplier handling sensitive personal data should not limit all liability to one month’s fees.

A balanced clause may include a general cap of 100% to 200% of annual fees, a higher cap for data protection and confidentiality, a separate IP infringement indemnity, clear exclusions for remote business losses, and express recoverability for specified direct costs such as data restoration or replacement services. The exact position depends on the contract, but the parties should be able to explain why the agreed cap fits the deal.

When to take legal advice

Legal advice is especially important before signing a technology contract where the platform is business-critical, the contract value is material, personal data is involved, implementation services are being provided, or either party is relying on standard terms. Once a dispute arises, the wording may already have determined the commercial outcome.

Customers should seek advice before accepting a low liability cap, broad exclusions of loss, service credits as an exclusive remedy, or terms that exclude liability for loss or corruption of data, security failures or IP claims. Suppliers should seek advice when updating standard terms, selling to larger customers, contracting internationally, processing sensitive data, or accepting customer procurement terms.

The cost of reviewing and negotiating the clause is usually modest compared with the cost of arguing about it later. In technology disputes, limitation clauses are often decisive because they can determine whether a claim is worth pursuing or defending. Early advice can reduce uncertainty, preserve commercial relationships and help both parties manage risk if something goes wrong.

How can we help

We will respond to most enquiries with both an indicative scope of work and a fee estimate, as well as the offer of a complimentary 20-minute discovery video call to discuss your issues and how we can help, before sending a more considered formal fee estimate via email.

In some limited cases, if you would just like initial advice and guidance on a call, we may instead offer a fixed fee appointment (commonly charged between £280 and £500 + VAT) whereby we will review the information you provide, hold a video call consultation and then follow up with an advisory email (as well as a fee estimate for any further work identified)

Please email wewillhelp@jonathanlea.net or call us on 01444 708640 as a first step. We first need an overview of the background and your issues, together with any significant documents, to provide an indicative scope of work and fee estimate. 

 

* VAT is charged at 20%

This article is intended for general information only, applies to the law at the time of publication, is not specific to the facts of your case and is not intended to be a replacement for legal advice. It is recommended that specific professional advice is sought before relying on any of the information given. © Jonathan Lea Limited.  

Photo by Luca Bravo on Unsplash