Pitfalls in ICT contracts part 6: relying on the Civil Code

ICT systems are now the beating heart of many organisations. From hospitals to transport companies, and from consultancy firms to financial institutions: a single bug, vulnerability or outage in an important ICT system can disrupt a business process or otherwise cause substantial financial loss. Appropriate contractual arrangements are therefore essential. In this blog series, we discuss common mistakes made when negotiating and entering into ICT contracts, with a view to protecting both customers and suppliers against undue risks.

Relying on the Dutch Civil Code

Breach, default, rescission, suspension of performance, liability: the Dutch Civil Code (DCC) covers all of these topics. Yet that is precisely where the pitfall lies. Anything not expressly agreed in a contract is, in effect, filled in automatically by the law. In ICT contracts, that can have undesirable consequences. The statutory rules are general and do not reflect the practical reality of ICT services.

A well-drafted ICT contract uses the DCC as its underlying basis, supplements it with concrete arrangements and, where necessary, deliberately departs from it. This blog discusses where things go wrong when too much reliance is placed on the DCC, and how to avoid that pitfall when drafting and reviewing ICT contracts.

Rescission

A first example where excessive reliance on the DCC can have unwanted consequences is rescission. In many ICT contracts, the statutory rescission regime in Article 6:271 DCC is excluded or modified. There is good reason for this.

Under the DCC, rescission gives rise to an obligation to undo performances already rendered. In the simple sale of a product, this is manageable. In ICT contracts, it usually is not. The customer has already used the service and the supplier has spent hours, configured systems, built interfaces or provided availability. A substantial part of those performances cannot be undone. The result: disputes about refunds, value compensation and who benefited from what.

There is also a financial risk. A refund following rescission is not damages. Many liability insurance policies do not cover that. The supplier may therefore face a substantial refund obligation that falls outside the policy coverage. This risk is still sometimes underestimated in contracting practice.

For that reason, ICT contracts often derogate from Article 6:271 DCC or exclude it entirely. The customer of course retains the right to claim damages if there is a legal basis for doing so, but the financial settlement does not automatically run through the statutory obligations for restitutions. If this is not addressed, the consequences of rescission are left to the DCC. And that is where the pitfall lies.

Interim termination

Article 7:408(1) DCC can also create a pitfall. This provision gives the customer under a contract for services the right to terminate the contract at any time.

The pitfall: parties assume that interim termination is not possible. That is not always correct. If an ICT contract qualifies as a contract for services, this statutory termination right may continue to operate in the background.

For suppliers, this can be a serious problem. ICT services are often structured around a particular contract term. Staff are scheduled, tooling is procured, licences are activated and infrastructure is set up. Pricing is often based on the expectation that the customer will purchase the services for a minimum period. If the customer then terminates early, a dispute may arise about the remuneration the supplier can still claim.

Therefore, suppliers are advised to exclude Article 7:408(1) DCC. The fact that a contract has expressly been entered into for a fixed term is not always sufficient. Courts sometimes hold that the parties have not been sufficiently explicit as to whether interim termination is possible, meaning that the customer can still terminate prematurely on that basis.

The lesson: do not let Article 7:408(1) DCC inadvertently determine the termination regime. Anyone wishing to agree a minimum term, fixed purchase commitment or limited right of interim termination should record this expressly. Otherwise, this statutory provision can still create surprises.

Duty to complain

ICT contracts often contain an acceptance procedure. That procedure governs the relationship between the parties. Sometimes, however, such a procedure is missing or is incomplete. Article 6:89 DCC then becomes relevant: a party that fails to complain in time about defective performance may lose the right to claim performance, cure or damages.

The pitfall for customers: issues are noticed internally but are not properly recorded or do not reach the right people, so no complaint is made to the supplier. Or the customer does not test properly, even though that could reasonably have been expected. The customer then fails to complain to the supplier in time. The supplier will readily invoke Article 6:89 DCC as a defence: the complaint was too late, so there is no claim.

Customers should therefore deal with this consciously. For example, by providing that Article 6:89 DCC does not apply, or that failure to complain in time does not bar a claim for performance or cure. This is particularly relevant where no acceptance procedure is in place.

Suspension of performance: a statutory pressure tool with major practical consequences

Suspension of performance is another area where parties often rely too readily on the DCC. Articles 6:52 DCC and 6:262 DCC provide a statutory basis for suspending obligations if the other party fails to perform. But in ICT contracts the question is not only whether suspension is legally possible. The more important question is what suspension means in practice.

Suspension of ICT services can have serious consequences. Think of taking a SaaS environment offline, blocking support, restricting access to data, stopping management activities or not installing security updates. For the supplier, suspension can be a logical pressure tool if invoices are unpaid. For the customer, suspension may come into play where the supplier seriously fails to perform. In both cases, suspension that is too quick or too broad can escalate the dispute.

That risk is often underestimated. A supplier that shuts off access to a business-critical application because of payment arrears may cause damage far exceeding the outstanding amount. Especially in healthcare, the public sector, financial services or other continuity-sensitive services, suspension can be disproportionate.

The DCC provides general frameworks, such as connection and proportionality, but for many ICT relationships these are too broad or too vague. Suspension should therefore be expressly regulated. Specify when suspension is permitted, what warning period applies, which obligations may not be suspended and what minimum continuity safeguards remain in place. Suspension is useful, but in ICT contracts it must be tightly delimited.

Getting this right can be complex. We are happy to help.