SaaS contract data ownership: who owns your data under Dutch law?

Under Dutch and EU law nobody owns data as such, so the data clause in your SaaS contract, and not the law, decides who may use, copy, export and delete the information you put into a cloud platform. Article 3:2 of the Dutch Civil Code (Burgerlijk Wetboek, BW) defines a zaak (thing) as a tangible object capable of human control, and a data set is not tangible. What a customer actually holds is a bundle of contractual rights, reinforced in places by copyright, database right, trade secret protection and the GDPR. Vague wording therefore does not leave the question open: it settles it in the provider's favour.

Why SaaS contract data ownership is a contractual question, not a property question

Dutch property law works with goederen: tangible things and property rights (Article 3:1 BW). Data falls into neither category. You cannot deliver it, pledge it or revindicate it the way you can a server or a machine. That is not a gap the courts have quietly filled; it is a deliberate feature of a system in which information circulates freely unless a specific rule restricts it. The practical consequence is blunt. If your agreement says nothing useful about your data, you have no fallback position to retreat to.

Four bodies of law do give data a measure of protection, and it is worth knowing which of them your information actually falls under. Original text, images, drawings and software that you upload or create on the platform attract copyright under the Auteurswet, which is yours by operation of law and does not transfer to a provider merely because it is hosted on their servers. A structured collection can attract the sui generis database right of the Databankenwet where you made a substantial investment in obtaining, verifying or presenting its contents, although settled European case law holds that investment in creating the underlying data does not count towards that threshold. Confidential business information with commercial value, protected by reasonable steps to keep it secret, falls under the Wet bescherming bedrijfsgeheimen, the Dutch implementation of the EU Trade Secrets Directive. And personal data is governed by the GDPR, which grants rights to the individuals concerned rather than to your company.

Everything outside those four categories, which in most SaaS deployments is the bulk of it, is pure contract. Transaction logs, telemetry, configuration settings, usage patterns, sensor readings and the analytics built on top of them are protected only to the extent that your agreement protects them. That is the single most important thing to understand before you read a clause.

What goes wrong when the clause is vague

Ambiguity in a data clause is rarely accidental, and it produces a recognisable set of problems. The first is lock-in: an agreement that offers no export format, no timetable and no price cap makes leaving a project rather than a decision. The second is scope creep in the provider's licence, where a right granted for the purpose of delivering the service quietly extends to product development and commercial exploitation. The third is a compliance gap, because the GDPR obliges a controller to know where personal data is processed and by whom, and a contract that does not answer those questions makes the accountability principle impossible to satisfy. The fourth is deletion on the provider's terms rather than yours, with the archive wiped before you have finished migrating.

None of these are exotic. They are the standard position of most off-the-shelf terms of service, and they are the reason a cloud agreement deserves the same scrutiny as a lease or a distribution contract. Our overview of what to check in a cloud contract in the Netherlands sets out the wider commercial framework in which the data clause sits.

What the data clause should say

A workable data clause does three things: it names what counts as customer data, it states that all rights in that data remain with the customer, and it defines the provider's licence by purpose rather than by breadth. The purpose limitation is the part that carries the weight. A provider genuinely needs to host, process, transmit and display your data to run the service, and no sensible customer objects to that. What a customer should object to is a licence that survives termination, extends to sub-licensing, or covers use for any purpose the provider considers useful.

Compare two formulations that look similar on a first reading. A licence to use, reproduce, modify and distribute Customer Data, granted perpetually and irrevocably, entitles the provider to build products on your information and to keep doing so after you have left. A licence to access and process Customer Data solely for the purpose of providing the Services under this Agreement, ending when the agreement ends, does not. The difference is a handful of words and it determines whether your operational data is your asset or their raw material.

Two further points are routinely overlooked. Define customer data to include material your staff generate inside the platform, not merely what you upload, because tickets, comments, workflow configurations and annotations are often the most valuable content on the system. And address derived and aggregated data explicitly, since a clause covering only Customer Data leaves everything the provider computes from it outside your protection.

Standard terms and the limits of Dutch contract law

Most SaaS agreements are concluded on the provider's general terms and conditions, which brings Articles 6:231 to 6:247 BW into play. Two rules matter here. Under Article 6:234 BW the provider must make the terms available before or at the moment the contract is concluded, and for contracts concluded electronically they must be supplied in a form the customer can store and reproduce; a link that later changes is not enough. Under Article 6:233(a) BW a term is voidable if, weighing all the circumstances, it is unreasonably onerous towards the other party.

That second route is narrower than businesses expect. Article 6:235 BW bars a counterparty from relying on Articles 6:233 and 6:234 if it is a legal entity within the meaning of Article 2:360 BW that has published its most recent annual accounts, or if it had fifty or more employees at the time the contract was concluded. Larger Dutch companies therefore cannot argue their way out of a harsh data clause after the event. Nor can a party that habitually uses the same or nearly the same standard terms itself. For most established businesses, the negotiation before signature is the only real opportunity.

Where standard terms give no relief, Article 6:248(2) BW remains: a rule flowing from the contract does not apply where, in the given circumstances, applying it would be unacceptable by standards of reasonableness and fairness. Dutch courts apply that test restrictively in commercial relationships, and they are noticeably more willing to use it where the provider caused the damage through intent or conscious recklessness. It is a safety valve, not a negotiating strategy.

Foreign law and forum clauses

Many SaaS agreements select the law and courts of the provider's home jurisdiction. Under the Rome I Regulation a business-to-business choice of law is generally valid, and under the Brussels I bis Regulation so is a choice of forum within the EU. What that choice does not do is switch off the GDPR, which applies to processing in the context of an establishment in the Union and to the offering of services to people in the Union, or the switching rules of the Data Act, which bind providers offering data processing services to customers in the Union regardless of where the provider is established. A clause promising compliance with the provider's domestic privacy law instead of the GDPR is a defect, not a detail.

Getting your data back: what the EU Data Act now requires

Since 12 September 2025 the Data Act (Regulation (EU) 2023/2854) has applied, and its chapter on switching between data processing services covers SaaS as well as infrastructure and platform services. It converts a number of points that used to be pure negotiation into statutory minimum entitlements, and it does so irrespective of what the provider's standard terms say. This is the most significant change in cloud contracting in years, and many agreements signed before that date have not been updated to reflect it.

The core obligations run as follows. A provider must remove contractual, technical, commercial and organisational obstacles that prevent a customer from terminating the contract and moving to another provider or to its own on-premises infrastructure. The maximum notice period a provider may impose before the switching process starts is two months. The mandatory transitional period during which the provider must continue to support the move is thirty calendar days, extendable where the switch is technically unfeasible within that window, up to a maximum of seven months. After the transitional period ends, the customer must have a minimum data retrieval period of at least thirty days before exportable data and digital assets are erased. The provider must offer open interfaces and export in a structured, commonly used, machine-readable format.

Charges are being phased out on a fixed timetable. During the transition running to 12 January 2027 a provider may recover only the costs it actually incurs in relation to the switch, which already outlaws the egress fees used as an exit penalty. From 12 January 2027 switching charges disappear altogether: a provider may not charge for the operations necessary to facilitate the switch, nor for data transit out of its environment.

Three practical consequences follow. Contracts concluded on older terms should be re-read against these rules, because a clause that conflicts with them does not save the provider. A promise of a ninety-day export window is no longer generous; it is close to the statutory floor once the notice and transitional periods are added together. And the requirement to export in a usable format has real teeth, because a dump in a proprietary schema that no competing platform can ingest does not discharge the obligation. Where the service you rely on is highly customised, put the format, the schema documentation and the migration support commitments in the contract anyway. Statutory minima are a floor, not a migration plan.

Deletion, backups and the processor agreement

Where the platform holds personal data, the provider is almost always a processor and you are the controller, and Article 28 GDPR requires a written agreement covering the subject matter, duration, nature and purpose of the processing, the categories of data and data subjects, and the controller's instructions. Article 28(3)(g) is the clause that matters at the end of the relationship: on termination the processor must, at the controller's choice, delete or return all personal data and delete existing copies, unless Union or Member State law requires storage. If your agreement lets the provider choose, it does not meet the standard. Our explanation of the roles of controller and processor under the GDPR sets out how to establish which role each party is actually in, and our guide to the data processing agreement covers the drafting in detail.

Backups are where deletion promises usually fail. A commitment that data will be removed from active systems says nothing about archives, snapshots and disaster recovery copies, and an auditor from the Autoriteit Persoonsgegevens will ask about all three. Supervisory practice accepts that backups are not surgically edited: the accepted approach is that data marked for erasure is put beyond use, is not restored into live systems, and disappears when the backup is overwritten on its ordinary rotation. What the contract must therefore specify is the rotation period, the guarantee that flagged data will not be reintroduced, and a written confirmation of deletion once the cycle completes. Ask for the certificate of deletion in the contract, not at the moment you need it.

Security obligations deserve the same treatment. Article 32 GDPR requires appropriate technical and organisational measures from controller and processor alike, and the contract should tie those to a certification the provider actually holds and agrees to maintain, such as ISO/IEC 27001 or a current SOC 2 Type II report, with an audit or inspection right attached. Since the Cyberbeveiligingswet, the Dutch implementation of the NIS2 Directive, entered into force on 15 August 2026, organisations within its scope must register with the NCSC and report significant incidents within twenty-four hours of becoming aware of them, followed by a fuller notification within seventy-two hours. Those deadlines are unmeetable unless your provider is contractually bound to alert you fast enough for you to meet them, so the notification window in the contract should be measured in hours.

AI training and derived data

Derived data is the information a provider computes from yours: benchmarks, predictions, propensity scores, efficiency reports and the model weights trained on the underlying set. Because there is no property right in data, there is no default answer to who may use it, and the same reasoning that leaves your raw data to the contract leaves the derived layer there too. A clause that carefully protects Customer Data while saying nothing about outputs and analytics protects the ingredients and gives away the dish.

The wording to watch is the service improvement clause, typically a right to use anonymised or aggregated customer data to improve and develop the provider's services and models. Two things are wrong with accepting it unexamined. First, anonymisation is a high bar under the GDPR: data is only anonymous where re-identification is not reasonably likely by any means, taking account of the other data available to the provider. Pseudonymised records, and aggregates fine-grained enough to isolate an individual customer, remain personal data and remain subject to the processor restrictions you negotiated elsewhere in the same document. Second, anonymisation says nothing about commercial confidentiality. Your pricing structure, margin data, client mix and internal processes can be perfectly anonymous in a data protection sense and still be the competitive intelligence you least want feeding a product sold to your competitors.

Trade secret protection under the Wet bescherming bedrijfsgeheimen only helps if you have taken reasonable steps to keep the information secret, and consenting in the terms of service to its use for model training is close to the opposite of a reasonable step. Regulation of artificial intelligence does not fill the gap either: the EU AI Act governs how AI systems may be developed, placed on the market and used, and imposes transparency duties, but it does not allocate rights in training data or in model output. That allocation is contractual, which means the protective clause has to be drafted rather than assumed.

A usable formulation states that the customer retains all rights in raw, derived and aggregated data; that the provider may use the data only to deliver the contracted service; that any use for product development, benchmarking, model training or publication requires prior written consent on a case-by-case basis; and that consent, once given, does not extend to sub-licensing or resale. If a provider will not accept a carve-out for model training, that is useful information about its business model, and it is better learned before signature than after a new product launch.

Liability caps under Dutch law

The limitation of liability clause decides what your data protections are actually worth. Providers typically cap liability at the fees paid over the preceding six or twelve months, which in a mid-sized subscription is a fraction of the loss caused by a serious breach. Dutch law does not prohibit such caps; exoneration clauses are valid in principle, and courts respect the allocation of risk that commercial parties negotiate.

They are not unlimited, though. Under Article 6:248(2) BW reliance on an exoneration clause is set aside where it would be unacceptable by standards of reasonableness and fairness, and the Supreme Court's case law treats damage caused by the debtor's intent or conscious recklessness, or that of persons entrusted with the management of its business, as the paradigm case. Where the clause sits in general terms, a party not excluded by Article 6:235 BW may also attack it under Article 6:233(a) BW. Both routes are argued after the loss has occurred, at some cost, and with no guarantee. Negotiating the cap is cheaper.

Two carve-outs are worth insisting on. Breach of confidentiality and of security obligations should sit outside the general cap or under a materially higher one, since that is precisely the risk you are buying protection against. And the intellectual property indemnity should be uncapped, because a third-party infringement claim arising from the provider's own software is a risk you cannot inspect or control. Note also that a contractual cap binds only the parties to the contract. It does not limit a data subject's claim for damage under Article 82 GDPR, and it does not limit the administrative fines the Autoriteit Persoonsgegevens may impose, which for the most serious infringements reach up to four per cent of worldwide annual turnover. Those exposures land on the controller regardless of what the processor agreed to pay.

Continuity if the provider fails

Insolvency is the scenario that most contracts handle worst. If a Dutch provider is declared bankrupt, Article 37 of the Faillissementswet allows the counterparty to set the trustee a reasonable written deadline to confirm whether the agreement will be performed; if the trustee does not confirm, he loses the right to demand performance from you, but that does not conjure up a running service. In practice the platform can be switched off while the estate is wound up, and your data sits on infrastructure the trustee is trying to sell.

A source code escrow alone does not solve this for SaaS, because holding the code is useless without the environment, the configuration and the data. What works is a continuity arrangement that covers all three: regular deposit of source code and build instructions, a current copy of your data in a documented format held outside the provider's estate, and a release trigger that includes insolvency and prolonged service failure rather than insolvency alone. Our articles on escrow arrangements and on software escrow in the Netherlands explain how these are structured and what a release actually delivers.

What to check before you sign

Due diligence on a SaaS provider is largely a matter of asking questions that a well-run supplier can answer in writing. Which certifications does the provider hold, when were they last audited, and will it commit to maintaining them for the term? Where is the data stored and processed, which sub-processors are involved, and how is a change of sub-processor notified and objected to? What is its incident history, and how did it communicate during the last one? Reluctance to answer any of these in writing is itself the answer.

It is worth deciding internally, before you open negotiations, which terms you will not concede. Agreeing that position between the business, IT and legal in advance prevents it being traded away under deadline pressure at the end of a procurement. A workable minimum is that all rights in raw and derived data remain with you; that the provider's licence is limited to delivering the service and expires with the agreement; that export is available in a documented, machine-readable format at no more than the cost the Data Act permits; that deletion covers backups and is confirmed in writing; that incident notification is measured in hours; and that confidentiality, security and IP indemnity sit outside the general liability cap. Present that as a condition of doing business rather than as a list of amendments to the provider's paper, and the conversation goes differently.

Bring legal review in once that internal position exists and the technical due diligence is complete. At that point counsel is working on wording rather than on discovering what the business actually needs, which is faster and considerably cheaper. And keep the option of walking away genuinely open. A provider that will not accept responsibility for its own negligence, or whose revenue depends on rights in your data, is not offering a partnership that can be fixed with drafting.

Contract wording compared

The pattern is consistent: the weak version describes an outcome, the protective version commits to a mechanism. A clause that cannot be tested against a format, a period or a named standard cannot be enforced when it matters.

Data location, sub-processors and audit rights during the term

Rights in data are worth little if you cannot establish where the data actually is. Article 28(2) GDPR requires the processor to obtain the controller's authorisation before engaging another processor, and where that authorisation is general, to inform the controller of intended additions or replacements so the controller can object. In practice most SaaS providers work with a published sub-processor list and a general authorisation, which is acceptable provided the contract fixes the notice period, gives you a real objection right, and states what happens if you object: a workable clause allows termination without penalty and with a full export.

Location matters for the same reason. If personal data leaves the European Economic Area, Chapter V GDPR requires a transfer mechanism, whether an adequacy decision, the European Commission's standard contractual clauses or binding corporate rules, together with an assessment of whether the law of the destination country undermines those safeguards in practice. Adequacy decisions are reviewed periodically and have been challenged before the European courts more than once, so a contract that relies on a single adequacy decision and provides for nothing else is fragile. Require the provider to implement an alternative mechanism at its own cost if the one in use falls away, and to disclose the countries from which support staff can access the environment, which is frequently a broader list than the countries in which data is stored.

Finally, insist on a workable verification right. Article 28(3)(h) GDPR obliges the processor to make available the information needed to demonstrate compliance and to allow for and contribute to audits, including inspections, conducted by the controller or an auditor it mandates. Providers commonly narrow this to an annual certification report, which is reasonable for a shared platform but only if the report is current, covers the services you use, and comes with a right to ask follow-up questions and to inspect where a report reveals a material gap or an incident has occurred. Write those triggers into the clause. An audit right that can only be exercised in the abstract is never exercised at all.

Frequently asked questions about SaaS contract data ownership

Which clause matters most?

The clause defining the provider's licence to your data, because that is what turns an ownership statement into something enforceable. A sentence saying the customer retains ownership is worth little if the next paragraph grants a perpetual, irrevocable, worldwide licence to use the same data for any purpose. Read the two together and look for a purpose limitation, an end date tied to termination, and an explicit reference to derived and aggregated data.

Can I get my data back if my provider becomes insolvent?

Only if you arranged it in advance. In a Dutch bankruptcy the trustee is not obliged to keep the service running, and under Article 37 Faillissementswet the practical outcome of a failure to confirm performance is that the agreement is not performed. A contractual export right against a company in liquidation is a claim, not a remedy. The reliable protection is a continuity arrangement that keeps a current, documented copy of your data and the means to run it outside the provider's estate, with a release trigger that covers insolvency and sustained service failure.

Does GDPR compliance protect my company's data rights?

No, and the assumption is a common source of exposure. The GDPR protects individuals in respect of their personal data and confers rights on those individuals, not on your company as a customer. A provider can process personal data impeccably and still hold a contractual licence to exploit your commercial data, your transaction history and the analytics built on them. Personal data compliance and commercial data rights are separate questions and need separate clauses.

Does the Data Act override what my contract says?

For switching, largely yes. Chapter VI of the Data Act applies to providers offering data processing services to customers in the Union and sets minimum entitlements on notice periods, transitional periods, export formats and charges that a contract cannot undercut. It does not, however, decide who may use your data during the term, who owns derived data, or what happens on a security incident. Those remain matters for the agreement.

How Law & More can help

The IT lawyers at Law & More review and negotiate SaaS and cloud agreements for Dutch and international businesses, covering rights in data, processor agreements, switching and exit provisions, security commitments and liability. We also advise on continuity arrangements and on disputes with providers when an exit goes wrong. Our IT law guides set out the wider framework. Tell us about your situation. We will let you know your options within one working day.