Contracts with service providers: what is most often missing

A processor is whoever processes data on your behalf and under your instructions. Having access to the system where the data sits already counts as processing — regardless of whether the vendor reads that data every day or only during an incident.

A typical list in a small organisation: an accounting service or program, mail and document cloud storage, a CRM system, a website hosting provider, a marketing mailing platform, video surveillance maintenance, an IT support company, and an archiving and document destruction service.

If a vendor uses the data for its own purposes and decides itself how to process it, it is an independent controller. This is usually the case with banks, auditors, notaries and lawyers, who act under their own professional duties.

This distinction needs to be settled before signing, because it determines the structure of the agreement and who is responsible for notices and data subject requests. Getting the structure wrong produces a document that regulates nothing.

The agreement must state the subject matter and duration of the processing, its nature and purpose, the types of personal data and the categories of data subjects. Next come the vendor's obligations: to process only on documented instructions, to maintain confidentiality, to apply appropriate security measures, to help you meet your obligations, and to provide information proving compliance.

Sub-processors and what happens to the data once the agreement ends are addressed separately. For the mandatory content, see Article 28(3) GDPR.

The clause missing most often covers the handling of sub-processors. A vendor almost always brings in someone else: an infrastructure provider, a support desk, a monitoring service. The agreement must state whether sub-processors are allowed, how new ones are notified, and how much time you have to object.

The practical benefit is simple: without this clause you do not know who actually sees your data, and you cannot record it in your register. It helps to ask for an up-to-date list of sub-processors and a link to where it is published.

The second point most often left out is what happens to the data when the agreement ends. It must be clear whether the data is returned or deleted, within what timeframe, in what format it is returned, and how deletion is confirmed.

Without this clause, migrating from one system to another turns into a negotiation at the most inconvenient possible time, and the old system keeps holding your data for another year with no basis at all.

The agreement must state that the vendor notifies you of a breach without delay, ideally with a specific deadline in hours and a named contact. You have 72 hours from becoming aware of it, so any delay by the vendor eats directly into your time.

It also helps to agree the minimum content of the notification: what happened, when, which categories of data, how many data subjects, and what measures were taken. Without that, your report to the authority will end up being drafted from a phone call.

You must have the right to receive information proving that the vendor is meeting its obligations. In practice this is rarely an on-site audit — usually it is enough to have the right to receive a description of security measures, or copies of certificates or independent assessment reports.

It matters that the clause is not empty. "The vendor will provide information where possible" is not a right; "within 30 days of the request" is.

If the vendor or its sub-processors access the data from third countries, this must be recorded in the agreement and in the register, together with the transfer basis and any supplementary measures. Technical support from another continent counts as access, even if the servers themselves are in Europe.

The question to the vendor should be phrased precisely: not "where is the data stored" but "who can access it, and from which countries". The answers to these two questions differ more often than you would expect.

It often turns out the terms are already in an annex to the main agreement or in the vendor's general terms. What is left is to check whether they match reality and record that in the list. Deal with the missing agreements in order of risk: start with the systems that hold the most data.

Small vendors sometimes refuse because they do not have such a document. A simple two-page annex with the mandatory content, written in plain language, usually works better than a twenty-page template.

If the vendor still refuses, it becomes a risk decision: either you change vendor, or you write down the decision and the measures you are taking to reduce the risk. What matters most is that the decision is a conscious, recorded one, not something forgotten.

When someone requests a copy of their data or its deletion, you may need the vendor's help, since the data sits in its system. The agreement must state that the vendor will help, and ideally within what timeframe.

Without this clause, the deadline by which you must respond to the person depends on the vendor's goodwill. In practice this is one of the most common causes of delay.

It also helps to check the technical side in advance: whether the system allows exporting one person's data, and whether a record can be deleted without breaking accounting. The answer often changes what you ask for in the agreement.

The sentence "the vendor applies appropriate technical and organisational measures" is a quote from the law, not a commitment. A short annex is worth more: access control, encryption, backup policy, logs, staff confidentiality undertakings, incident handling.

The annex should not turn into a twenty-page document. It is enough to include what can be checked and what can be demanded if something goes wrong.

If the vendor has an independent security assessment or certificate, referencing it in the agreement is a convenient solution — but it is worth checking that the assessment actually covers the specific service you are buying.

With large platforms there is usually no negotiation: the terms are standard and non-negotiable. That does not mean nothing can be done — you can choose the region, switch off unneeded features, limit the amount of data, and narrow access on your own side.

Before signing, it is worth reading what the terms say about sub-processors, transfers and breach notification, and recording that in your register. If the terms are unacceptable, the decision needs to be made now, not after an incident.

It helps to write the decision down: what risk you see, why you are still choosing this service, and what measures you are applying. It takes five minutes and helps a great deal when an inspection later asks the same question.

The list only works if someone is responsible for keeping it up to date. In practice it is most convenient to tie it to procurement: a new service is not ordered until it has been established what data the vendor will see and whether the agreement is in place.

Once a year the whole list is worth reviewing: whether all the services are still in use, whether any systems remain that still hold your data unnecessarily, and whether the sub-processors have changed.

When ending an agreement, the final step is essential: confirmation that the data has been returned or destroyed. Without it, the vendor stays in your register indefinitely, and you remain responsible for data you no longer control.

Before signing, it is worth answering four questions: what data the vendor will see, where it will be stored, who else will have access to it, and what happens once the agreement ends. These answers immediately show whether the draft agreement is sufficient.

The second step is to check whether the data types described match reality. Agreements often list only contact details, even though the system also holds payment, health and video data.

Third, link the agreement to the register on the same day. An agreement that is not in the vendor list effectively does not exist: nobody will find it when it is needed.

In a small organisation with ten vendors, the whole check takes about one day: half a day for the list and document review, half a day to start negotiating the missing agreements.

The longest part is not the legal work but waiting for vendors to respond. So it is worth starting with the emails and only then sitting down with the documents.

The annual review later takes a few hours, if the list is kept up to date alongside procurement. If it is not, after two years the work starts almost from scratch.