Exoneration clauses in IT contracts: how far does the limitation of liability in the case of core obligations extend?

Why exoneration clauses in IT contracts are so important

For startups and scale-ups, IT is rarely an afterthought. SaaS tools, ERP environments, cloud infrastructure, data storage and managed services are often directly linked to daily operations. If such systems are delivered too late, do not function properly or fail, the damage is usually not limited to a technical incident. This quickly results in loss of turnover, delays in processes, additional costs for emergency measures and sometimes even business downtime.

Without a contractual limitation of liability, the starting point in Dutch contract law is firm. In principle, anyone who fails to comply with an agreement can be liable for all damage that can reasonably be attributed to that shortcoming. This includes not only direct financial loss, but also loss of profit. For IT suppliers, this can lead to significant financial exposure, especially when their services are deep in the customer's operations.

This explains why liability restrictions in IT contracts are market use. An exoneration clause is essentially an agreement by which the parties limit or exclude liability for damage. In practice, this is not a precondition, but an essential part of the commercial and legal distribution of risk.

At Startup-Recht, we regularly see that founders and legal teams mainly look at price, scope and implementation planning, while the liability regime only receives attention late in the negotiation. That is risky. Especially in tech contracts, the exoneration often tells more about the real deal than the commercial summary on the front cover.

What an exoneration clause usually regulates

A classic IT contract distinguishes between direct damage and indirect damage, often also referred to as consequential damage. Suppliers usually try to maximize liability for direct damage, for example up to the contract value or, in the case of continuous service, up to compensation over a year. A complete exclusion is often included for indirect damage.

That sounds clear, but there is immediately an important legal point of attention. Indeed, concepts such as direct damage and indirect damage are not spelled out in the law. If parties use these terms without properly defining them, there is room for interpretation. This is particularly relevant because the legal literature and case law argue that direct damage, if that term is not specified, can be interpreted broadly. This can also include damage that a supplier just thought he would keep out, including lost profit.

For startups and scale-ups, this is more than semantics. A direct damage cap can only really be assessed if you know what constitutes direct damage. An exclusion of consequential damages sounds vendor-friendly, but says less than many teams think when the rest of the clause is unclear. Conversely, a client sometimes believes that he has negotiated reasonable protection, while in reality important claims remain out of reach.

In addition to caps and exclusions, you often see additional exceptions. Many exoneration clauses state that the restriction does not apply, or is less far-reaching, in the event of intent or gross negligence on the part of the supplier. Damage due to death or injury and damage due to infringement of intellectual property rights are also often treated separately. This shows that an exoneration clause is not an absolute shield, but a nuanced arrangement that can work out differently per claim category and situation.

There is something else to add. An exoneration usually does not stand alone. The liability risk is also influenced by other contractual buttons, such as whether deadlines are fatal or just target dates, whether there is an obligation to make an effort or an obligation to achieve results, how the force majeure regime is set up, which service levels apply and whether a supplier has the chance to repair defects first. Acceptance regulations also play a part in this. So if you only look at the exoneration article, you often only see part of the legal picture.

Why clients can also have an interest in limiting liability

It may sound counterintuitive, but a client does not necessarily have an interest in unlimited liability on the part of their IT supplier. If a supplier runs completely open-ended risk towards all its customers, this can put pressure on that supplier's business operations. High claims from other customers can affect investments in support, innovation or continuity. In the extreme case, a serious claim for damages can even threaten the continuity of the supplier itself.

For a startup or scale-up, this is not a theoretical point. Those who depend on one software partner, hosting party or managed service provider also have an interest in keeping that party financially afloat. That does not mean that every broad exoneration is reasonable. It does mean that the discussion is not black and white. A workable liability regime is about balance: sufficient protection for the customer, without a risk allocation that becomes uninsurable or commercially unfeasible for the supplier.

This is also reflected in the practice of insurance. In many cases, IT suppliers can insure themselves against professional liability. That is why contracts are regularly linked to the insured amount, or the supplier is required to be adequately insured. At the same time, insurability in itself is not a reason why suppliers simply extend their liability. The absence of insurance also does not automatically make invoking an exoneration impossible.

Does an exoneration also apply if the supplier breaches a core obligation?

This is the question that comes up sooner or later in many negotiations. A startup often wants to prevent a supplier from hiding behind a liability limitation if the heart of the service fails. Think of backups, security, hosting, availability of a business-critical application or the proper functioning of an agreed integration.

The idea behind this is understandable. If a supplier fails to meet what is essential for the customer, it feels uncomfortable that the damage will then be contractually cut off. However, this does not automatically mean that an exoneration clause does not last.

The Supreme Court has confirmed that the mere fact that a shortcoming affects the core of the performance is in itself insufficient to consider invoking an exoneration clause unacceptable. In other words: even in the case of core obligations, an exoneration can in principle be valid and enforceable. This is an important starting point for contract practice between professional parties.

For startups and scale-ups, this is a reality check. So it is not enough to say during negotiations that something is a core obligation. If you want a different liability regime to apply to this, you must explicitly and concretely include this in the contract. Otherwise, the general exoneration usually remains applicable, even to parts that are operationally vital.

When can a judge override an exoneration clause anyway?

The fact that exonerations are in principle admissible does not mean that they are unassailable. Dutch law does have correction mechanisms. Under circumstances, invoking an exoneration clause may be unacceptable according to the standards of fairness and fairness. The case law refers to a number of familiar points of view, such as the gravity of the error, the nature and seriousness of the interests involved, the content of the agreement, the position of the parties, how the clause was concluded and the extent to which the other party was aware of the scope of the clause.

It is important, however, that judges are cautious about this. In fact, this reluctance applies strongly to relationships between professional parties. The starting point remains freedom of contract. Only special circumstances can make an exoneration inapplicable.

A striking example from recent case law concerned an IT service provider that was responsible for making backups, while a new server appeared not to be included in the backup system. After a crash, crucial business data was lost and business operations largely came to a standstill. The judge disapplied the exoneration clause in that case. This included the fact that the supplier had failed to comply with a core obligation, that reports left the customer under the assumption that everything was in order and that the limitation of liability was disproportionate to the damage caused.

This statement shows that the combination of circumstances can be decisive. Not only the fact that it is a core obligation, but also the nature of the errors, the expectations raised and the further context can be decisive. At the same time, this statement should not be read too quickly as a new main rule. In other recent IT cases, recourse to exoneration remained in place, even when it came to essential contractual obligations.

What does the recent line in the case law say?

The common thread is clear: exoneration clauses are rarely set aside by the courts in IT disputes between professional parties. This also applies when the shortcoming affects what parties consider to be the core of the service.

In practice, it is particularly important that recent case law does not show a broad shift towards declaring exonerations of core obligations invalid. On the contrary, the dominant line remains that such clauses remain in force unless there is an exceptional set of circumstances. A recent ruling invalidating the exoneration therefore seems to be an exception rather than the new starting point.

This is relevant for any startup that trusts a judge to correct a hard liability clause later. That strategy is uncertain. Litigating about the reasonableness of an exoneration is costly, time-consuming and actually highly dependent on the circumstances. It is better to structure the contract beforehand in such a way that the outcome does not entirely depend on a subsequent judicial correction.

What this means in concrete terms for startups and scale-ups

Don't just name core obligations, link them to consequences

Many contracts mention critical services in the scope or in an SLA, but do not attach a separate liability regime to them. That is usually too thin. If backup management, incident response, availability or data retention is really crucial for the company, the contract should also clarify what happens if things go wrong there. Otherwise, such an obligation still falls under the general cap and exclusions.

Define claims carefully

A distinction between direct and indirect damage only works if that distinction is useful. Unclear terms provide space for discussion when the damage has already occurred. This is undesirable for growth companies, because it is precisely then that speed and clarity are needed. Therefore, have not only the amount of the cap assessed, but also the definitions that determine what damage is and is not recoverable.

Look beyond the exoneration article

In practice, liability risks are often distributed earlier in the contract. Is a deadline fatal or indicative? Is it an obligation to achieve results or just an obligation to make an effort? How does recovery work? When does absenteeism occur? What does the acceptance scheme say? How much space does a supplier get within the SLA before there is a shortcoming? These provisions can be at least as important as the exoneration itself.

Don't let critical processes just exist on paper

The discussed case law on backups underlines how sensitive this is. For tech companies that rely on data and continuity, it is not enough for a supplier to contractually promise to make backups. The question is also how verifiable that promise is. Reporting, verification and recovery procedures therefore deserve serious attention. Contractual protection is stronger when operational reality matches it.

Be extra vigilant about privacy and processing relationships

The GDPR often also plays a part in IT contracts, for example in the relationship between controller and processor. This is where legal uncertainty still exists about the scope to contractually limit liability. Prudence is therefore appropriate. Anyone who processes or has personal data processed would be wise not to separate liability clauses from the privacy agreements in the rest of the contract.

An exoneration does not remove all incentives to comply

It is sometimes thought that a supplier with a large exoneration is hardly at risk anymore. That picture is not entirely correct. Even if liability for damage is contractually limited, the customer retains other rights. Think of compliance, possibly with means of pressure, and dissolution and cancellation. An exoneration therefore does not remove every legal incentive to perform correctly.

This is an important point of nuance for startups. A contract does not have to solve everything through compensation. Sometimes it is more operationally valuable to make strong agreements about recovery, escalation, service levels, audit options and exit than to only focus on a theoretically high liability maximum.

Conclusion: freedom of contract is the starting point, not the end point

Exoneration clauses are not the exception in IT contracts between professional parties, but the norm. This is easy to explain, because the potential damage caused by failed IT can be significant and suppliers want to keep their risk manageable. The case law shows that such clauses usually last, even when a core obligation fails.

This is a clear lesson for startups and scale-ups. Do not rely on a judge to correct an adverse exoneration later. Those who purchase business-critical IT must negotiate sharply beforehand about which obligations are really essential, what damage should remain recoverable and how the rest of the contract supports that risk. An exoneration clause is then not a legal detail, but a core part of your risk strategy.

‍