Contents5 sections
When you use a cloud fuel app, you are the controller for your drivers' data, and the app provider is your processor. That sounds formal, but it has practical consequences: without a clean contract between you and the provider, the data processing is unlawful under the GDPR — even if the provider does everything right.
This contract is called a data processing agreement, or DPA for short. Here we summarise what it must contain and how to recognise a poor DPA.
What a DPA is and why every cloud app needs one
As soon as a service provider processes data for you and on your behalf, you need a DPA. This applies to:
- Cloud fuel apps that manage your driver data.
- Accounting tools that process personal data.
- Email providers that store your business correspondence.
- Hosting services that keep your customer database.
The DPA governs: What may the processor do with the data? What may they not do? Who is liable for what? How is data deleted? Who audits?
Without this contract, a central requirement of the GDPR is missing. In the event of damage, you are then exposed not only on the technical merits but also formally — which becomes relevant when it comes to fines. Where the DPA sits within the bigger catalogue of obligations is covered in the GDPR in the fleet guide.
Mandatory content: what it must contain
The GDPR prescribes what a DPA must govern. In essence, these are the points:
- Subject matter and purpose of the processing — what exactly does the provider do with the data?
- Types of data — which categories are processed (master data, fuelling transactions, receipts, etc.)?
- Data subjects — drivers, and where applicable dispatchers and end customers.
- Duration of the processing — typically the contract term plus retention periods.
- Obligations and rights of the controller — that is, your side.
- Technical and organisational measures (TOMs) — encryption, access rights, backup, contingency plan, etc.
- Sub-processors — who else is involved besides the provider itself (hosters, payment service providers, support tools)?
- Deletion concept — what happens to the data at the end of the contract?
- Cooperation and notification obligations — for example in the event of data breaches or data subjects' access requests.
- Audit and inspection rights — how can you verify that the provider complies with everything?
A good DPA addresses each of these points concretely, not in platitudes. "Provider takes appropriate measures" is not a technical or organisational measure — it is an empty shell.
Sub-processors: the underestimated topic
Practically every cloud provider uses sub-processors — typically hosters (AWS, Azure, Hetzner), mail dispatch, support tools, payment service providers. A clean DPA lists these sub-processors by name and describes what they do.
More than that: you as the controller must be informed of changes in advance and have a right to object when a new sub-processor is added. Otherwise your data could migrate unnoticed to a provider you want nothing to do with.
Common shortcomings in DPAs
From practice, we repeatedly see the same weaknesses:
- "Sub-processors can be changed at any time without further notice.": This undermines your control and tends to be ineffective.
- "Audit rights are billed on a time-and-materials basis.": Fair enough, the provider cannot tolerate an on-site inspection every day. But shifting the costs entirely onto you is unfair.
- TOMs as generic boilerplate: "state of the art", without describing what that means in concrete terms. Expect an annex covering encryption, access control, logging, backup frequency.
- Deletion concept missing or vague. Key question: what happens to your data 30 days after the end of the contract?
- Third-country transfers are concealed or permitted across the board. If the hoster is based in the USA, Standard Contractual Clauses (SCCs) or another mechanism must be documented.
- Liability limitation shifted onto the provider: some providers try to exclude their liability across the board. In the case of data protection breaches, this is generally not permissible.
If you are presented with a DPA that contains one or more of these points, raise it with the provider. Reputable providers change the wording, or at least give a plausible explanation of why the clause is worded that way.
The DPA in practice: this is what should be in it
A usable DPA from a fuel app provider lists at least these points — check the document against this list before signing:
- Concrete TOMs (encryption in transit and at rest, role-based access, logging, backup).
- Current sub-processors (hoster, and where applicable mail service), with location and function.
- Procedure for sub-processor changes with advance notice.
- Deletion concept at the end of the contract, ideally with a prior data export.
- Notification channels for data breaches, access requests and authority enquiries.
For DKV InstantFuel, you receive the current DPA document as part of concluding the contract. If you have any questions about it, you can reach us via the contact details on the data protection page.
Three questions you should ask every provider
Before you sign:
- "Can you send me the DPA for review before we conclude the contract?" Anyone who refuses often has something to hide in the fine print.
- "Where is the data stored and which sub-processors are involved?" A reputable answer takes no more than 24 hours.
- "What happens to our data if we cancel?" Ideally there are export options and a clear deletion deadline (e.g. 30 or 90 days after the end of the contract).
If all three questions are answered confidently, the GDPR hurdle has essentially been cleared. Even so, the final sanity check before signing should be handled by a legal eye — especially if you are dealing with sensitive data or larger fleets.
Further reading:
Note: This article is not a substitute for legal advice. For specific questions, speak to your data protection officer or a specialist lawyer for IT law.