An IT services agreement is the contract under which a provider delivers technology services to a client: managed IT, development, hosting, support or a combination. Under Dutch law it is normally a contract for services (overeenkomst van opdracht) governed by Book 7 of the Civil Code, and sometimes a contract for work (aanneming van werk) where a defined result is to be delivered. That classification is not academic. It decides whether the provider owes best efforts or a result, whether the client may terminate at will, and what happens when a deadline is missed.
What kind of contract this is under Dutch law
Dutch law distinguishes two obligations that English-language IT contracts routinely 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 the outcome is not delivered, the provider is in breach whatever effort it made.
Providers draft for the first, clients assume the second. The word deliver, used loosely, does not settle the question, and Dutch courts decide it by interpretation, looking at the wording, the negotiations, the expertise of the parties and the commercial purpose. If the client is buying a working system by a fixed date, the contract must say that the delivery of that system by that date is an obligation of result and that acceptance is measured against defined criteria. If the parties genuinely mean best efforts, the contract should say that too, and set out how effort will be measured.
Classification also drives termination. Under the rules on contracts for services, the client may in principle terminate at any time, with the provider entitled to reasonable remuneration for the work done. That right cannot be excluded where the client is a private individual, but between businesses it can be, and provider terms routinely do 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. Reading the termination clause against those defaults tells you 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. In practice there is a framework agreement setting out the legal terms, one or more statements of work or service descriptions setting out what is actually being delivered, a service level agreement setting out the performance standards, a data processing agreement where personal data are involved, and the provider’s general terms and conditions sitting underneath all of it. The order of precedence between these documents needs to be stated expressly, because they contradict one another more often than not, and the clause that resolves the contradiction may be worth more than any individual term.
Scope, acceptance and change control
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, at what hours, what is patched and how often, how many endpoints and users are covered, 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 honest providers welcome them. 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 are the usual candidates. Where they are excluded, the contract should also say at what rate they will be charged if they occur.
Acceptance deserves its own regime whenever anything is built rather than merely operated. Say who tests, against which criteria, within what period, what counts as a defect and in which severity class, how many correction rounds the provider gets, what happens if the client does not test within the period, and what the consequence of definitive rejection is. Deemed acceptance clauses, under which the deliverable is accepted automatically if the client does not respond in time, are standard in provider terms and are enforceable; the answer is not to fight them in principle but to make the period realistic and to start it only when the provider has actually delivered something testable.
Change control is the third element of the same problem. Every substantial IT engagement changes during its life. Without a procedure, changes are agreed by email between people who cannot bind their organisations, and the dispute at the end is about what was agreed in March. A short procedure naming who may request a change, who must approve it, how it is priced, and that no change takes effect until signed by both parties, prevents most of that.
Service levels and what a service credit is worth
If the scope says what is done, the service level agreement says how well. A usable SLA states the metric, the measurement method, the measurement window, the exclusions and the consequence of failure. Each of those is a place where a headline number can be quietly emptied of meaning.
Take availability. A guarantee of 99.9 per cent sounds impressive and permits roughly forty-three minutes of downtime in a thirty-day month; 99 per cent permits more than seven hours. But the figure only means something once you know what is measured, since availability of the platform is not the same as availability of the client’s application; what is excluded, since planned maintenance windows, third-party network failures and force majeure are normally carved out; and who measures it, since 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, and a fifteen-minute response target is worth little without a resolution target beside it. Both depend on the severity classification, so the definitions of critical, high, medium and low incidents should be written in terms of business impact rather than technical symptoms, and the client should have a route to escalate a mis-classification.
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, because they are capped at a fraction of a fee that is itself small relative to the loss caused by a serious outage. Two things therefore matter. First, whether the credits are the exclusive remedy: a clause providing that service credits are the sole and exclusive remedy for a failure to meet service levels removes the right to claim damages, and that is the single most important sentence in many SLAs. Second, whether persistent failure gives a right to terminate, typically after a defined number of breaches in a rolling period. A client with no termination right and only credits has no real leverage at all.
Fees, payment and the provider’s standard terms
Set out the pricing model precisely: fixed fee, per user, per device, per ticket, time and materials, or a combination, and what is included in each. State the indexation mechanism, naming the index and the review date, 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 and European rules on late payment in commercial transactions apply here as they do to any other business contract. Where no period is agreed, payment falls due within thirty days; between businesses a longer period may be agreed within statutory limits; and once payment is late, statutory commercial interest runs by operation of law together with a fixed sum for collection costs. Providers frequently add a right to suspend the service on non-payment. That right is lawful in principle but it is a blunt instrument in an IT context, where suspension can take the client’s business offline, and it should be qualified by a notice period and by an exception for undisputed and disputed amounts.
Nearly every Dutch IT provider declares its general terms and conditions applicable, and in this sector many use the standard industry terms published by the trade association. They are professionally drafted and heavily provider-oriented: best-efforts obligations, short complaint periods, liability capped at a portion of the contract sum, and broad exclusions of consequential loss. They are negotiable more often than clients assume, particularly on the liability cap and the SLA remedies.
Two Dutch rules on standard terms are worth knowing. The user of general terms must give the other party a reasonable opportunity to take note of them before or when the contract is concluded, in practice by supplying them; if it does not, the individual clauses can be annulled. And where both parties refer to their own terms, Dutch law follows the first shot: the terms referred to first apply unless the other party expressly rejects them, which is the opposite of the position in several other systems. Our guides on general terms and conditions explained and on the five most common mistakes in international commercial contracts set out how that works in practice.
Intellectual property and source code
Paying for software does not make you its owner. Under Dutch copyright law the person who creates the work is the author and holds the copyright, and there is no doctrine that transfers ownership to whoever commissioned or paid for the work. Two exceptions exist. Where the work is made by an employee in the performance of duties that include creating such work, the employer is deemed to be the author. And 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. Neither exception covers the ordinary case of a client engaging an external provider or a freelance developer.
The consequence is that an assignment must be agreed expressly, and Dutch law requires a deed for the transfer of copyright: a written instrument signed 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. The same applies to the transfer of rights in a database and to a licence exclusive in nature.
A practical agreement therefore separates three categories. Background material is what the provider brings with it, its frameworks, libraries, tools and standard modules; the provider keeps ownership and the client receives a licence, and the scope, duration, territory and transferability of that licence should be defined. Foreground material is what is created specifically for the client; ownership normally transfers on full payment. Third-party and open source components carry their own licences, and the provider should warrant which components are used and on what terms, because a copyleft licence embedded in bespoke software can impose obligations the client never intended. Our guide to the open source software licence in the Netherlands explains those obligations.
Where the client depends on software it does not own, source code escrow is the standard answer: the source code and build documentation are deposited with an escrow agent and released to the client on defined events, typically the provider’s insolvency or a persistent failure to maintain. Escrow only works if the deposit is kept current and if the release conditions are drafted to be verifiable, and our guide to software escrow in the Netherlands sets out what a workable arrangement looks like.
Finally, deal with data separately from intellectual property. The client’s data are the client’s, and the agreement should say so, along with the format in which they will be returned, the obligation to assist a successor provider, and the obligation to delete remaining copies afterwards. Where the provider wants to use client data to improve its own services or to train models, that requires an explicit and separately negotiated permission, not a line in an appendix.
Personal data: the processor agreement
Where the provider processes personal data on the client’s instructions, the General Data Protection Regulation requires a written processor agreement, and it prescribes what that agreement must contain: the subject matter and duration of the processing, its nature and purpose, the types of personal data and categories of data subjects, and a defined set of obligations on the processor. Those obligations include 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 with breach notification, and deleting or returning the data at the end of the service. An agreement missing these elements is not compliant, and both parties are exposed. 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, and the agreement must reflect the reality rather than the label the parties prefer.
Security should be specific. Encryption of data at rest and in transit, role-based access with multi-factor authentication, logging and log retention, patch and vulnerability management timescales, backup frequency and restore testing, segregation between clients in a shared environment, and physical security where the provider operates its own facilities. An audit right, or an obligation to supply an independent assurance report and the results of penetration testing, converts these promises into something the client can verify.
Breach notification is the clause most likely to be tested. Under the Regulation a controller must notify the supervisory authority, in the Netherlands the Dutch Data Protection Authority, within seventy-two hours of becoming aware of a personal data breach where it is likely to present a risk, and must inform affected individuals where the risk is high. The processor must notify the controller without undue delay. Since the client cannot meet its own deadline if it hears late, the agreement should require notification within a short fixed period, name the contact point, and 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 where data leave the European Economic Area.
Cybersecurity and sector regulation
Data protection is no longer the only regulatory layer sitting on top of an IT services agreement, and several regimes now reach the provider directly rather than only through the client.
The Dutch Cybersecurity Act, which implements the second European network and information security directive, has been in force since 15 August 2026. Organisations within its scope must register with the National Cyber Security Centre, take appropriate risk management measures, and report significant incidents, with an initial report within twenty-four hours and a fuller report within seventy-two hours. Managed service providers and managed security service providers fall within the scope of the regime in their own right, and clients in scope must be able to show that their supply chain is managed. In contractual terms that means an obligation on the provider to support the client’s own reporting deadlines, which are far shorter than a typical incident clause allows for. Our guide on the Dutch Cybersecurity Act and what it requires sets out who is caught.
For clients in the financial sector, the European regulation on digital operational resilience has applied since 17 January 2025, and it prescribes contractual content for arrangements with information and communication technology providers, including provisions on service descriptions, locations of processing, access, inspection and audit rights, exit strategies and termination rights. A standard IT services agreement will not satisfy it, and a provider serving financial clients should expect to be asked for those terms.
Where artificial intelligence forms part of the service, the European artificial intelligence regulation allocates obligations by role along the value chain, and a provider integrating a general purpose model into a client’s system may be a provider or a deployer depending on the arrangement. The obligations are being phased in, and the prohibitions on certain practices already apply. 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, because that cost is otherwise argued about later.
Liability, force majeure and the limits Dutch law imposes
Limitation of liability is where the commercial and the legal converge. Provider terms typically cap liability at the fees paid over a short period, exclude consequential loss and loss of profit, exclude loss of data, and impose short periods within which a claim must be notified. Clients negotiate the cap upwards, commonly to the fees over twelve months, and 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 places outer limits on these clauses. Exclusions and caps between businesses are in principle valid, but a party cannot rely on one where reliance would be unacceptable by the standards of reasonableness and fairness, and the courts consistently refuse to allow an exclusion to shield a party against its own intent or conscious recklessness, 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 feed into that assessment. A cap that bears a visible relationship to the value of the contract and to the risk being run is far more likely to be upheld than a blanket exclusion.
Two mechanics decide whether a claim can be brought at all. The first is default: where performance is still possible, the client must generally give written notice of default allowing a reasonable period for performance before it can claim damages or rescind, unless a fixed deadline has passed or performance has become impossible. Sending an angry email is not a notice of default. The second is the complaint period: provider terms usually require defects to be notified within a short period after discovery, and a client that discovers a problem, works around it for months and then complains may find the claim barred.
Force majeure clauses in IT contracts should be read for what they include on the provider’s side. Failures of subcontractors, hosting partners and telecommunications suppliers are frequently defined as force majeure, which transfers to the client the risk of the provider’s own supply chain. That is a negotiable point, and in a managed services contract it is often the most important one, because the provider is being paid precisely to manage that chain.
People: subcontracting, freelancers and staff
IT services are delivered by people, and the contract should say something about them. Key personnel clauses name the individuals the client is relying on and restrict their replacement without consent; they are common in development and implementation work and rare in managed services, where the client should at least require equivalent qualifications and a handover on any change.
Subcontracting is the norm rather than the exception, and the agreement should state whether it is permitted, whether the client’s consent is needed, and that the provider remains fully liable for the acts of anyone it engages. Where the subcontractor also processes personal data, the sub-processor rules under the data protection regime apply on top, with their own consent and notification requirements.
Where individuals work at the client’s premises, under the client’s direction and for a sustained period, a further question arises: whether the relationship between the client and those individuals is really self-employment at all. The Dutch Tax Administration resumed full enforcement on the classification of working relationships from 1 January 2025, so a construction under 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 language that gives the client the authority to direct individuals in the way an employer would, and both sides should look at how the work is actually performed rather than at the label on the invoice.
Two further points arise at the boundaries of the relationship. A non-solicitation clause preventing each party from hiring the other’s staff for a defined period after the contract ends is standard and generally enforceable between businesses, provided it is limited in time and scope. And where a client takes a service back in-house, or moves it to another provider together with the team that performed it, the Dutch rules on the transfer of an undertaking can apply, so that the employees transfer with their existing terms and conditions. That outcome frequently surprises the parties and it should be analysed before the transition is agreed, not after.
Term, termination and exit
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 the mechanism by which clients stay with providers they would rather leave, so check the notice period, the date from which it runs, and the form the notice must take. Diarise it on the day you sign.
Distinguish three exits. Termination for convenience allows either party, or often only the client, to end the contract on notice without giving a reason; providers frequently omit it and it is worth insisting on. Termination for cause allows immediate termination on a defined material breach that is not cured within a defined period; the list of triggers should include repeated service level failures rather than only catastrophic events. And rescission for breach under general Dutch law remains available alongside the contractual routes unless the contract excludes it, subject to the notice of default described above.
Exit management is what determines the real cost of leaving, and it is nearly always drafted too thinly. A workable exit clause obliges the provider, for a defined period after termination and at defined rates, to continue the service, to return the client’s data in a documented and usable format, to provide documentation and configuration details, to cooperate with the successor provider, to transfer or assign third-party licences where possible, and to delete remaining copies of client data and confirm it in writing. Without those obligations a client can be technically free to leave and practically unable to.
Insolvency deserves a line of its own. If the provider is declared bankrupt, a trustee takes control and is not obliged to continue performing; the client’s remedy is a claim in the estate, which is usually worth little. This is the reason escrow arrangements, exit documentation kept current, and independent backups of the client’s own data matter more than any clause in the contract.
The mistakes that cost the most
A short list accounts for most of the disputes we see. A scope described in categories instead of tasks, which produces invoices for work the client believed was included. Service credits declared to be the exclusive remedy, which quietly removes the right to claim damages for an outage. No termination right for persistent underperformance, leaving the client with credits and nothing else. Intellectual property assumed to transfer with payment, discovered to be untrue when the client wants to move to another provider or to sell the business. A processor agreement copied from a template that does not match what is actually being processed. Subcontractors and hosting partners treated as force majeure. Automatic renewal with a notice period nobody diarised. And no exit clause, so the leverage sits entirely with the outgoing provider at the worst possible moment.
Read the contract for the day the relationship ends badly rather than the day it starts well; that is the only scenario in which any of these clauses will be read at all. For a wider view of how these contracts sit 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.
Frequently asked questions
What is the difference between an IT services agreement and an SLA?
The IT services agreement is the contract governing 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 partnership; the SLA defines the performance. Where the two conflict, the order of precedence clause decides which wins, which is why that clause should be written deliberately rather than inherited 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. 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 with a six-month notice period and no obligation 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. There is no rule that transfers ownership to whoever paid for the work; the rule that vests copyright in an employer 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 covering any of the provider’s own background material that is 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?
It depends on the contract and on how the assignment is classified. The statutory rules on contracts for services allow the client to terminate at any time, subject to paying reasonable remuneration for work done, but between businesses that right can be and often is restricted by the contract. Where the provider is in breach, the route is a written notice of default granting a reasonable period to perform, followed by rescission if the breach persists. Where the contract contains a termination for convenience clause, use it and observe the notice period exactly.
What should we do before signing?
Read 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 nine points are right, the rest of the document rarely decides a dispute.
Getting the contract right
Law & More advises clients and providers in the Netherlands on the full stack of technology contracts: the IT services agreement and its statements of work, service level agreements, development and implementation contracts, software licences and escrow, cloud and SaaS terms, data processing agreements, and the disputes that follow when a project fails or a service degrades. If you are about to sign, are renegotiating at renewal, or are in a dispute with a provider or a client, our lawyers will review the documents and set out the options. Please contact us to discuss your situation, or read our Dutch IT law guides. Related contract types are covered in our guides to the franchise agreement and the participation agreement.
