An IT services agreement is the contract under which a provider delivers technology services to your business: managed IT, software development, hosting, support or a combination. Under Dutch law it is usually a contract for services (overeenkomst van opdracht) under Book 7 of the Dutch Civil Code (Burgerlijk Wetboek, BW), but it becomes a contract for work (aanneming van werk) where the provider must deliver a defined result.
That classification decides a great deal. It determines whether the provider owes best efforts or a result, whether you can end the contract early, and what happens when a deadline is missed. Below we go through the clauses that matter most, in the order in which they usually cause disputes.
What kind of contract is an IT services agreement under Dutch law?
In most cases it is a contract for services, in which the provider owes best efforts. Only where the contract clearly promises a defined outcome does the provider owe a result.
Dutch law distinguishes two types of obligation that English-language IT contracts often blur. An obligation of best efforts (inspanningsverbintenis) requires the provider to work with the care of a reasonably competent professional. It is breached only if the provider fell short of that standard. An obligation of result (resultaatsverbintenis) requires a defined outcome. If that outcome is not delivered, the provider is in breach, however much effort it made.
Providers draft for the first, while clients assume the second. The word “deliver”, used loosely, does not settle the question. Dutch courts decide it by interpretation: they look at the wording, the negotiations, the expertise of the parties and the commercial purpose. If you are buying a working system by a fixed date, the contract must say that delivery of that system by that date is an obligation of result. It should also say that acceptance is measured against defined criteria. If both parties genuinely mean best efforts, the contract should say that too, and set out how effort will be measured.
How does classification affect termination?
It decides who may end the contract and on what terms. Under a contract for services, the client may in principle terminate at any time.
According to article 7:408 BW, the client may terminate a contract for services at any time. The provider is then entitled to reasonable remuneration for the work done (article 7:411 BW). That right cannot be excluded where the client is a private individual. Between businesses it can be, and provider terms routinely exclude or restrict it. A provider that has taken on the assignment in the course of its business may itself only terminate for compelling reasons (gewichtige redenen). If you read the termination clause against those default rules, you can see immediately who the contract was drafted for. Our guide to the contract for services sets out the statutory rules in more detail.
Which document does what?
An IT engagement is rarely one document. You will usually find a framework agreement, one or more statements of work, a service level agreement, a data processing agreement and the provider’s general terms and conditions.
The framework agreement sets out the legal terms. The statements of work or service descriptions set out what is actually being delivered. The service level agreement sets the performance standards. The data processing agreement applies where personal data are involved, and the provider’s general terms sit underneath all of it. State the order of precedence between these documents expressly. They contradict one another more often than not, and the clause that resolves the contradiction can be worth more than any individual term.
How do you define scope, acceptance and change control?
Describe the tasks, not the category of service, and list what is excluded. Then agree how deliverables are tested and how changes are approved.
The scope clause is where most disputes begin. “Managed network services” is not a scope; it is a category. A workable description says what is monitored and at what hours, what is patched and how often, and how many endpoints and users are covered. It also says what is included in onboarding and offboarding, which incidents are in scope, what is explicitly excluded, and what happens when volumes grow beyond the assumed baseline.
Exclusions matter as much as inclusions, and reliable providers welcome them. The usual candidates are out-of-hours emergency work, hardware procurement, third-party software licences, on-site visits, data recovery after client error, and support for systems the provider did not install. Where these are excluded, the contract should also state the rate at which they will be charged if they are needed.
When do you need an acceptance procedure?
Whenever something is built rather than merely operated. Without one, it is unclear when the provider has actually delivered.
Set out who tests, against which criteria and within what period. Define what counts as a defect and in which severity class it falls. Agree how many correction rounds the provider gets, what happens if you do not test within the period, and what the consequence of definitive rejection is. Deemed acceptance clauses, under which the deliverable counts as accepted if you do not respond in time, are standard in provider terms and generally enforceable. The answer is not to fight them in principle. Make the period realistic, and let it start only when the provider has actually delivered something testable.
Why is change control part of the same problem?
Because every substantial IT engagement changes during its life. Without a procedure, you end up arguing later about what was agreed.
Without a procedure, changes are agreed by email between people who cannot bind their organisations. The dispute at the end is then about what was agreed in March. A short procedure prevents most of that. It names who may request a change and who must approve it, explains how the change is priced, and states that no change takes effect until both parties have signed it.
What should a service level agreement contain?
A usable SLA states the metric, how and over what period it is measured, what is excluded and what happens on failure. Each of those elements can quietly empty a headline number of meaning.
If the scope says what is done, the service level agreement says how well it is done. Look at each element separately, because the headline figure only matters once the details are known.
Take availability. A guarantee of 99.9 per cent sounds impressive and still allows roughly 43 minutes of downtime in a 30-day month; 99 per cent allows more than seven hours. The figure only means something once you know three things:
- what is measured: availability of the platform is not the same as availability of your application;
- what is excluded: planned maintenance windows, third-party network failures and force majeure are normally carved out;
- who measures it: a provider reporting on its own performance, without an agreed tool or an audit right, is effectively marking its own homework.
Response and resolution targets need the same treatment. “Response” usually means acknowledgement rather than a fix. A fifteen-minute response target is worth little without a resolution target beside it. Both depend on the severity classification. Define critical, high, medium and low incidents in terms of business impact rather than technical symptoms, and give yourself a route to escalate a wrong classification.
What is a service credit really worth?
As compensation, very little. What matters is whether credits are your only remedy and whether persistent failure gives you a right to terminate.
Service credits are the standard remedy: a percentage of the monthly fee refunded when a target is missed. They are useful as a management signal and almost worthless as compensation. They are capped at a fraction of a fee that is itself small compared with the loss a serious outage can cause. Two points therefore matter.
First, check whether the credits are the exclusive remedy. A clause stating that service credits are the “sole and exclusive remedy” for missed service levels removes your right to claim damages. In many SLAs that is the most important sentence. Second, check whether persistent failure gives you a right to terminate, typically after a set number of breaches in a rolling period. A client with only credits and no termination right has no real leverage.
How should fees and payment be set out?
Describe the pricing model, the indexation and the invoicing precisely. Where the contract is silent, the Dutch statutory rules on late payment fill the gap.
State the pricing model: fixed fee, per user, per device, per ticket, time and materials, or a combination, and what each includes. Name the index and the review date for price increases, rather than allowing annual increases at the provider’s discretion. State when invoices are issued, what they must specify and when payment falls due.
Dutch rules implementing the European Late Payment Directive apply to IT contracts as they do to any business contract. According to article 6:119a BW, payment between businesses falls due within 30 days where no period is agreed. A longer period may be agreed, but a period of more than 60 days is void if it is grossly unfair to the creditor. Once payment is late, statutory commercial interest runs automatically. The creditor can also claim collection costs, with a minimum of €40 (article 6:96 BW).
Providers often add a right to suspend the service on non-payment. That right is lawful in principle, but it is a blunt instrument in IT, where suspension can take your business offline. Qualify it with a notice period and an exception for amounts that are genuinely in dispute.
Can you negotiate the provider’s standard terms?
Yes, more often than clients assume, particularly on the liability cap and the SLA remedies. Two Dutch rules on general terms also help you.
Nearly every Dutch IT provider declares its general terms and conditions (algemene voorwaarden) applicable. In this sector many use the standard terms published by the industry association. These terms are professionally drafted and strongly provider-oriented: best-efforts obligations, short complaint periods, liability capped at part of the contract sum, and broad exclusions of consequential loss.
The first rule concerns the duty to inform. The user of general terms must give the other party a reasonable opportunity to read them before or when the contract is concluded, in practice by supplying them. If it does not, individual clauses can be annulled (articles 6:233 and 6:234 BW). The second rule concerns the battle of the forms. Where both parties refer to their own terms, Dutch law follows the “first shot” rule in article 6:225(3) BW: the terms referred to first apply, unless the other party expressly rejects them. That is the opposite of the position in several other legal systems. Our guides on general terms and conditions explained and on the five most common mistakes in international commercial contracts show how that works in practice.
Who owns the software and the source code?
The person who created it, not the party who paid for it. You only acquire the copyright if it is assigned to you in writing and delivered by deed.
Paying for software does not make you its owner. Under the Dutch Copyright Act (Auteurswet), the person who creates a work is the author and holds the copyright. No rule transfers ownership to whoever commissioned or paid for the work. There are two exceptions. Where an employee creates the work as part of their duties, the employer is deemed to be the author (article 7 Auteurswet). Where a legal entity publishes a work as its own without naming a natural person as the author, that entity is deemed to be the author (article 8 Auteurswet). Neither exception covers the ordinary case of a client engaging an external provider or a freelance developer.
So the assignment must be agreed expressly. According to article 2(3) Auteurswet, an agreement transferring copyright or granting an exclusive licence must be made in writing, and the transfer itself requires a deed (akte) intended for that purpose. A clause in the agreement stating that the client acquires all intellectual property rights in the deliverables, signed by both parties, does the job. An invoice or a verbal understanding does not. Document any transfer of rights in a database in the same way.
How do you separate background, foreground and third-party material?
Give each category its own rule: a licence for background material, ownership of foreground material, and a warranty for third-party and open source components.
Background material is what the provider brings with it: its frameworks, libraries, tools and standard modules. The provider keeps ownership and you receive a licence. Define the scope, duration, territory and transferability of that licence. Foreground material is what is created specifically for you; ownership normally transfers on full payment. Third-party and open source components carry their own licences. The provider should warrant which components are used and on what terms, because a copyleft licence embedded in bespoke software can impose obligations you never intended. Our guide to the open source software licence in the Netherlands explains those obligations.
When do you need source code escrow?
When your business depends on software you do not own. Escrow gives you access to the source code if the provider can no longer maintain it.
With escrow, the source code and build documentation are deposited with an escrow agent. They are released to you on defined events, typically the provider’s insolvency or a persistent failure to maintain the software. Escrow only works if the deposit is kept up to date and the release conditions can be verified. Our guide to software escrow in the Netherlands sets out what a workable arrangement looks like.
Who owns your data?
You do, and the agreement should say so explicitly. Deal with data separately from intellectual property.
The agreement should state the format in which your data will be returned, the provider’s duty to assist a successor provider, and its duty to delete remaining copies afterwards. If the provider wants to use your data to improve its own services or to train models, that requires explicit, separately negotiated permission, not a line in an appendix.
What must the processor agreement contain?
Where the provider processes personal data on your instructions, the GDPR requires a written processor agreement with prescribed content. Without that content, both parties are exposed.
Article 28(3) of the General Data Protection Regulation (GDPR, in Dutch AVG) sets out what the agreement must contain. It must describe the subject matter and duration of the processing, its nature and purpose, the types of personal data and the categories of data subjects. It must also impose a set of obligations on the processor:
- processing only on documented instructions;
- ensuring the confidentiality of personnel;
- taking appropriate technical and organisational security measures;
- engaging sub-processors only with authorisation and on equivalent terms;
- assisting the controller with data subject requests and breach notification;
- deleting or returning the data at the end of the service.
An agreement missing these elements is not compliant. Our guide to the data processing agreement in the Netherlands covers the required content.
Get the roles right first. A provider that determines its own purposes, for instance by using the data for its own analytics, is a controller for that processing rather than a processor. The agreement must reflect the reality, not the label the parties prefer.
How specific should the security clause be?
Specific enough that you can check it. Name the measures and give yourself a way to verify them.
Relevant measures include encryption of data at rest and in transit, role-based access with multi-factor authentication, logging and log retention, and timescales for patch and vulnerability management. Add backup frequency and restore testing, separation between clients in a shared environment, and physical security where the provider runs its own facilities. An audit right, or a duty to supply an independent assurance report and penetration test results, turns these promises into something you can verify.
What should the breach notification clause say?
It should require the provider to tell you within a short, fixed period. Otherwise you cannot meet your own 72-hour deadline.
Under article 33 GDPR, a controller must notify the supervisory authority within 72 hours of becoming aware of a personal data breach, unless the breach is unlikely to present a risk. In the Netherlands that authority is the Dutch Data Protection Authority (Autoriteit Persoonsgegevens). Where the risk is high, the controller must also inform the individuals concerned (article 34 GDPR). The processor must notify the controller without undue delay. Since you cannot meet your own deadline if you hear late, the agreement should require notification within a short fixed period and name the contact point. It should also oblige the provider to cooperate with the investigation and to supply logs and evidence. Sub-processors and international transfers need the same treatment, with the transfer mechanism identified wherever data leave the European Economic Area.
Which cybersecurity and sector rules affect the contract?
Data protection is no longer the only regulatory layer. The Dutch Cybersecurity Act, the EU rules on digital operational resilience and the AI Act can all reach the provider directly.
What does the Dutch Cybersecurity Act require?
Since 15 August 2026, organisations within its scope must register, manage their cyber risks and report significant incidents quickly. Managed service providers fall within the scope in their own right.
The Dutch Cybersecurity Act (Cyberbeveiligingswet) implements the second EU network and information security directive (NIS2) and has been in force since 15 August 2026. Organisations within its scope must register with the National Cyber Security Centre (NCSC), take appropriate risk management measures and report significant incidents. The reporting timeline follows NIS2: an early warning within 24 hours, an incident notification within 72 hours and a final report within one month. Managed service providers and managed security service providers are covered in their own right. Clients in scope must be able to show that their supply chain is managed. In contractual terms, the provider must support your own reporting deadlines, which are far shorter than a typical incident clause allows. Our guide on the Dutch Cybersecurity Act and what it requires sets out who is covered.
What if you are in the financial sector?
Then the EU Digital Operational Resilience Act (DORA) prescribes the contract content. A standard IT services agreement will not meet it.
DORA has applied since 17 January 2025. Article 30 prescribes the contractual provisions for arrangements with ICT service providers, including service descriptions, locations of processing, access, inspection and audit rights, exit strategies and termination rights. A provider serving financial clients should expect to be asked for those terms.
What if AI is part of the service?
The EU AI Act allocates obligations by role in the value chain. The contract should say who carries which obligation.
A provider integrating a general-purpose AI model into your system may be a provider or a deployer under the AI Act, depending on the arrangement. The obligations are being phased in, and the prohibitions on certain AI practices have applied since 2 February 2025. Our guides on prohibited AI practices and on using AI in a Dutch business set out the position. Whatever the regime, the contract should allocate responsibility for compliance, require cooperation with regulators, and say who bears the cost of changes required by new legislation. Otherwise that cost is argued about later.
How far can the provider limit its liability?
Between businesses, caps and exclusions are in principle valid. A provider cannot rely on them, however, where that would be unacceptable by the standards of reasonableness and fairness, for example in case of intent or conscious recklessness.
Limitation of liability is where the commercial and the legal meet. Provider terms typically cap liability at the fees paid over a short period and exclude consequential loss, loss of profit and loss of data. They also set short periods within which a claim must be notified. Clients commonly negotiate the cap upwards, often to the fees over twelve months. They also carve out the categories they cannot afford to leave capped: breach of confidentiality, infringement of third-party intellectual property, and liability arising from a data protection breach.
Dutch law sets outer limits on these clauses. Under article 6:248(2) BW, a party cannot rely on a contract term where that would be unacceptable by the standards of reasonableness and fairness. The courts consistently refuse to let an exclusion clause shield a party against its own intent or conscious recklessness (opzet of bewuste roekeloosheid), and generally that of its senior management. The seriousness of the breach, the nature of the damage, the insurance position and the relative bargaining strength all play a role. A cap that bears a visible relationship to the contract value and the risk involved is far more likely to be upheld than a blanket exclusion.
What must you do before you can claim?
In most cases you must first put the provider in default in writing. You must also complain within the period the contract or the law requires.
The first step is the notice of default (ingebrekestelling). Where performance is still possible, you must generally give written notice with a reasonable period to perform before you can claim damages or rescind (articles 6:82 and 6:83 BW). That is not needed if a fixed deadline has passed or performance has become impossible. An angry email is not a notice of default. The second step is the complaint period. Under article 6:89 BW, you must complain within a reasonable time after discovering a defect, and provider terms usually shorten that period. A client that discovers a problem, works around it for months and only then complains may find its claim barred.
What does the force majeure clause cover?
Read it for what it includes on the provider’s side. Failures of subcontractors and hosting partners are often listed, which shifts the provider’s own supply chain risk to you.
Failures of subcontractors, hosting partners and telecoms suppliers are frequently defined as force majeure. That transfers the risk of the provider’s own supply chain to you. This point is negotiable. In a managed services contract it is often the most important one, because you are paying the provider precisely to manage that chain.
What should the contract say about people?
It should cover key personnel, subcontracting, the status of freelancers and non-solicitation. IT services are delivered by people, and each of these points can cause trouble later.
Key personnel clauses name the individuals you are relying on and restrict their replacement without your consent. They are common in development and implementation work and rare in managed services. In managed services, at least require equivalent qualifications and a proper handover whenever someone is replaced.
Subcontracting is the norm rather than the exception. The agreement should state whether it is permitted, whether your consent is needed, and that the provider remains fully liable for anyone it engages. Where the subcontractor also processes personal data, the GDPR rules on sub-processors apply as well, with their own consent and notification requirements.
Are the freelancers really self-employed?
That question arises when individuals work at your premises, under your direction, for a long period. If they work like employees, there is a real risk of reclassification.
The Dutch Tax Administration (Belastingdienst) resumed full enforcement on the classification of working relationships on 1 January 2025. A construction in which nominal freelancers work like employees now carries a real risk of reclassification, with payroll tax consequences for the party they work for. Contracts for services should therefore avoid wording that gives you the authority to direct individuals as an employer would. Both sides should look at how the work is actually done, not at the label on the invoice.
What about non-solicitation and taking a service back in-house?
A limited non-solicitation clause is standard. Taking a service back in-house, or moving it with the team, can trigger the Dutch rules on transfer of an undertaking.
A clause preventing each party from hiring the other’s staff for a set period after the contract ends is standard and generally enforceable between businesses, provided it is limited in time and scope. Where you take a service back in-house, or move it to another provider together with the team that performed it, the rules on transfer of an undertaking (overgang van onderneming, articles 7:662 and following BW) can apply. The employees then transfer on their existing terms and conditions. That outcome often surprises the parties, so analyse it before the transition is agreed, not after.
How do term, termination and exit work?
Check the initial term, the automatic renewal and the notice period, and agree a detailed exit clause. The exit clause decides what leaving really costs.
Managed service agreements commonly run for an initial term of one to three years, with automatic renewal unless notice is given. Automatic renewal combined with a long notice period is how clients end up staying with providers they would rather leave. Check the notice period, the date from which it runs and the form the notice must take. Put the date in your calendar on the day you sign.
Which ways out are there?
There are three: termination for convenience, termination for cause and rescission for breach under Dutch law. Each has its own conditions.
- Termination for convenience lets either party, or often only the client, end the contract on notice without giving a reason. Providers frequently leave it out; it is worth insisting on.
- Termination for cause allows immediate termination for a defined material breach that is not remedied within a set period. The triggers should include repeated service level failures, not only catastrophic events.
- Rescission for breach (ontbinding) under article 6:265 BW remains available alongside the contractual routes unless the contract excludes it, subject to the notice of default described above.
What should the exit clause contain?
It should oblige the provider to keep the service running for a period, return your data and cooperate with the successor. Exit clauses are nearly always drafted too thinly.
A workable exit clause obliges the provider, for a set period after termination and at agreed rates, to:
- continue the service;
- return your data in a documented and usable format;
- provide documentation and configuration details;
- cooperate with the successor provider;
- transfer or assign third-party licences where possible;
- delete remaining copies of your data and confirm this in writing.
Without those obligations you can be free to leave on paper and unable to leave in practice.
What happens if the provider goes bankrupt?
A trustee (curator) takes over and is not obliged to continue performing. Your remedy is then a claim in the bankruptcy estate, which is usually worth little.
That is why escrow arrangements, up-to-date exit documentation and independent backups of your own data matter more than any clause in the contract.
Which mistakes cost the most?
A short list accounts for most of the disputes we see. Almost all of them are visible before signing.
- A scope described in categories instead of tasks, which produces invoices for work you believed was included.
- Service credits as the exclusive remedy, which quietly removes the right to claim damages for an outage.
- No termination right for persistent underperformance, leaving you with credits and nothing else.
- Intellectual property assumed to transfer with payment, which turns out to be untrue when you want to switch provider or sell the business.
- A processor agreement copied from a template that does not match the actual processing.
- Subcontractors and hosting partners treated as force majeure.
- Automatic renewal with a notice period nobody put in the calendar.
- No exit clause, so all the leverage sits with the outgoing provider at the worst possible moment.
Read the contract for the day the relationship ends badly, not the day it starts well; that is the only scenario in which these clauses are read at all. For a wider view of how these contracts fit within Dutch technology law, see our guides on the cloud contract in the Netherlands, on the hidden risks of SaaS contracts and on what an IT lawyer does. More background is in our Dutch IT law guides, and related contract types are covered in our guides to the franchise agreement and the participation agreement.
In summary
- An IT services agreement is usually a contract for services (article 7:400 BW and following); make it an obligation of result where you are buying a defined outcome by a fixed date.
- Define scope in tasks, agree an acceptance procedure and a change procedure, and state the order of precedence between the documents.
- Check whether service credits are the exclusive remedy and whether persistent failure gives you a right to terminate.
- Copyright in bespoke software only passes to you by a written agreement and a deed (article 2(3) Auteurswet); payment alone is not enough.
- Agree a GDPR-compliant processor agreement, clauses reflecting the Cybersecurity Act where relevant, and a detailed exit clause.
Frequently asked questions
What is the difference between an IT services agreement and an SLA?
The IT services agreement governs the relationship: scope, fees, intellectual property, confidentiality, liability, term and termination. The service level agreement is the part, usually an annex, that sets the measurable performance standards and the consequences of missing them. The agreement defines the relationship; the SLA defines the performance. Where the two conflict, the order of precedence clause decides which prevails. That is why this clause should be written deliberately rather than copied from a template.
How long should an IT services agreement run?
For managed services, an initial term of one to three years is common, matched to the investment the provider makes in onboarding. For a development project, the term follows the project. The length matters less than the exit. A five-year contract with a genuine termination for convenience and a full exit clause is safer than a one-year contract that renews automatically, has a six-month notice period and no duty to hand anything over.
Who owns software developed for us by a provider?
Under Dutch law the provider does, unless the rights are assigned to you in writing and transferred by deed. No rule transfers ownership to whoever paid for the work. The rule that vests copyright in an employer (article 7 Auteurswet) applies to employees, not to external providers or freelancers. Make sure the agreement contains an express assignment of the rights in the bespoke deliverables, signed by both parties, and a licence for any background material of the provider embedded in them. Check the chain as well: if the provider used subcontractors, it can only assign what it validly acquired from them.
Can we terminate an IT contract early?
That depends on the contract and on how the assignment is classified. Under article 7:408 BW, the client may terminate a contract for services at any time, subject to paying reasonable remuneration for work done. Between businesses, that right can be restricted by contract, and often is. Where the provider is in breach, the route is a written notice of default with a reasonable period to perform, followed by rescission if the breach continues. Where the contract contains a termination for convenience clause, use it and observe the notice period exactly.
What should we check before signing?
Check nine points: the order of precedence clause, the scope exclusions, the SLA exclusions and measurement method, the exclusive remedy wording, the liability cap and its carve-outs, the intellectual property clause, the processor agreement, the renewal and notice provisions, and the exit obligations. If those points are right, the rest of the document rarely decides a dispute. We advise both clients and providers in the Netherlands on the full range of technology contracts, from the IT services agreement and its statements of work to SLAs, development contracts, software licences, escrow, cloud and SaaS terms, and the disputes that follow when a project fails.
Unsure where you stand? Tell us about your situation. We will let you know your options within one working day.
How Law & More can help you with this is explained on our IT lawyer page.
