Hosting providers assume GDPR is the customer’s problem because the data is on the customer’s server. For your billing system that is exactly wrong, and it is where a subject access request lands.
Ilinca Bostan6 min readHosting providers get GDPR wrong in a specific and consistent way: they assume that because customer data sits on the customer's server, GDPR is the customer's problem. For the data on those servers, largely true. For the data in your billing system, not remotely.
You are a processor for one set of data and a controller for another, and the obligations are different. Here is where the line falls and what it means operationally.
Not legal advice. Controller and processor determinations are fact-specific and depend on what you actually do with the data. Supervisory authorities in different member states interpret aspects differently. Get your position confirmed by a qualified adviser.
You are a processor for the personal data your customers put on the infrastructure you provide — the contents of their databases, their end-users' records, their mailboxes. You process it on their instructions, you do not decide what it is for, and your obligations flow from the contract with them.
You are a controller for the data you hold about your own customers — their names, addresses, contact details, billing history, payment references, support tickets, login records, and the IP addresses assigned to their services. You decided to collect it, you decided what for, and the obligations are yours directly.
Almost everything in your billing platform is controller data. That is the part providers overlook, and it is the part a subject access request will land on.
A lawful basis for each purpose. Contract performance covers most billing activity. It does not automatically cover marketing to your customers, retaining data after they leave, or analytics — those need their own basis, and consent is not the only one but it is often the honest one.
Retention limits. This is where hosting billing gets genuinely awkward. Tax law in most jurisdictions requires invoices to be kept for years, and GDPR requires personal data not to be kept longer than necessary. The resolution is that the legal-obligation basis supports keeping the invoice, but it does not support keeping everything else about that person indefinitely. A former customer's support tickets, login history and marketing preferences do not inherit the invoice's retention period.
Subject rights. Access, rectification, erasure, portability, objection. The practical test is whether you can actually produce everything you hold about one person, from every system, inside a month.
Records of processing. Article 30 requires a written record of your processing activities. Most small hosting providers do not have one and are supposed to.
Breach notification. 72 hours to the supervisory authority where the breach is likely to result in a risk to individuals. That clock is separate from, and shorter in some respects than, the reporting duties under NIS2 — and an incident can trigger both.
A former customer asks you to delete everything. You cannot delete the invoices — you are legally required to retain them. This is not a conflict, it is a correctly-handled case, and the way to handle it is to say so.
The defensible response has three parts: delete what you can (marketing data, analytics, non-essential records), retain what you must with the legal basis stated (invoices and their supporting records, for the statutory period), and tell the person exactly which is which. What is not defensible is either deleting the accounting records or refusing the request wholesale because part of it cannot be met.
Operationally that means your platform needs to support anonymising or restricting a customer without destroying the financial documents attached to them. If your only options are "keep everything" and "delete the row", you will end up choosing one and being wrong.
Run this inventory once and it will surprise you. Personal data about a single customer is typically spread across the billing database, the ticket system, email logs, payment gateway records, server access logs, DNS and WHOIS records, backups, and any analytics or marketing tool you connected.
Two of those are the hard ones. Backups contain data you have deleted from production, and the accepted position is generally that you do not restore a backup to erase one record — you document that the data will age out with the backup rotation and is not returned to production. That position only works if your rotation actually expires, which is worth verifying rather than assuming.
Payment gateways hold data you never see, under their own controller or processor role. Deleting a customer in your platform does not delete the token or transaction history at the processor, and your privacy notice should not imply it does.
For the customer-data half you need a data processing agreement with each customer, a record of sub-processors (your datacenter, your backup provider, your monitoring vendor), a commitment to assist with their subject requests and breach obligations, and clarity on international transfers if any sub-processor is outside the EEA. Most of this is contractual rather than technical, and the sub-processor list is the part that goes stale.
Your billing platform is a processor of your controller data, and that makes us a sub-processor in your customers' eyes — expect to have to name us. FluxBilling supports self-hosting on the Business tier (€44.95/month plus a €500 one-time fee) where you need the data to sit on infrastructure you control and inside a jurisdiction you choose, which is a real answer to data residency questions rather than a policy statement about them.
On the managed tiers, the practical points are that customer records, invoices, tickets and IP assignments live in one system rather than five, which makes a subject access request a query rather than an archaeology project; that audit trails record administrative access; and that the accounting export lets you extract and retain financial records independently of the platform.
Honest limits: we do not publish an ISO 27001 or SOC 2 certification, and you should not represent us as certified in your own documentation. Ask us directly what we can evidence for a supplier assessment.
See data protection, security, and data sovereignty and self-hosted billing.
Do the inventory before you need it. Pick one real former customer and try to produce everything you hold about them, from every system, as if a request had arrived. The gap between what you thought you held and what you actually hold is the whole of your GDPR exposure, and it takes an afternoon to measure.
A PDF is a picture of an invoice, not an electronic one. Why cross-border hosting businesses get caught by rolling national mandates, and the identifier data to start collecting now.
Sell hosting to a consumer in another member state and the place of supply moves to them. The threshold is lower than most providers think, and the platform requirements are specific.
Data centre and cloud services sit in Annex I, which makes qualifying providers essential entities on the strictest tier. Scope tests, the 24-hour clock, and the parts that touch your billing system.