Compliance Industry

GDPR at 8: What to Ask Your Billing Provider About Customer Data

Dr Paul Barrass 12 min read
Reseller reviewing a printed checklist titled GDPR at 8 next to a laptop showing a billing platform login screen with a 2FA prompt and a sample itemised invoice

GDPR at 8: What to Ask Your Billing Provider About Customer Data

GDPR started applying on 25 May 2018. Eight years on, plenty of UK telecoms resellers have a billing provider they signed up with before the rules really bedded in, before the Information Commissioner’s enforcement teeth fully grew, and before the Data (Use and Access) Act 2025 lifted PECR penalties onto the same upper scale as UK GDPR.

The anniversary is a sensible point to ask a question most resellers do not get round to: do you actually know how your billing provider handles your customers’ personal data? The questions in this post are the ones we would put to any provider, ours included. They are vendor-neutral by design. Pull what is useful, run it past whoever you bill through, and see how the answers land.

Key Takeaways

Key terms in this article

What is GDPR Article 28?

GDPR Article 28 covers the relationship between a controller (you, the reseller) and a processor (your billing provider). It lists what must be in the written contract between you, including security obligations, sub-processor rules, and what happens to your data when the contract ends.

What is PECR?

PECR (Privacy and Electronic Communications Regulations) is the UK rule that sits alongside GDPR for electronic communications. It covers marketing consent, cookie rules, breach notification for telecoms providers, and the specific rules on what can appear on an itemised phone bill.

What is a data processing agreement?

A data processing agreement (DPA) is the written contract required by Article 28 between a controller and a processor. It sets out what data is being processed, on what instructions, with what security, and for how long. Without one in place, you are not GDPR-compliant.

What is a sub-processor?

A sub-processor is a third party your billing provider passes your data to in order to deliver the service, such as a payment gateway, an email-sending service, or a hosting provider. Article 28 makes the main processor responsible for the sub-processors they bring in.

What is OWASP ASVS?

OWASP ASVS (Application Security Verification Standard) is an open standard from the Open Web Application Security Project that lists the security controls a web application should meet. It gives you a public yardstick to ask a vendor about, rather than relying on marketing claims.

Why Look at This Again Now?

For the first few years after 2018, most GDPR conversations focused on cookie banners and consent forms. The harder, less visible part was processor relationships and operational security, and that is where the enforcement money has moved. The ICO’s 2025 fines were around eight times the 2024 total, driven almost entirely by security and breach decisions (URM Consulting analysis of 2025 ICO enforcement, 2026); the underlying cases are listed in the ICO’s enforcement register.

The other quiet change is the Data (Use and Access) Act 2025. PECR penalty levels have been lifted to match UK GDPR’s, so the ICO can issue PECR fines of up to £17.5m or 4% of global turnover, where the previous ceiling was around £500,000 (ICO guidance on DUAA commencement, 2026). For a reseller, the practical consequence is that your billing provider sits in the middle of the data flow that would trigger any of this.

For the broader regulatory landscape (Ofcom, VAT, end-of-contract notifications, accessibility), our longer UK telecoms billing compliance guide covers the lot. This post stays narrowly on data protection.

Article 28: Have You Got the Paperwork?

The first question is the easiest to answer and the most often skipped. GDPR Article 28 requires a written agreement between you and your billing provider. It must cover, at minimum:

  • The subject matter and duration of the processing
  • The nature and purpose of the processing
  • The types of personal data and categories of data subjects
  • Your obligations and rights as the controller
  • The security measures the processor will apply
  • The rules for engaging sub-processors
  • The arrangements for assisting you with data subject requests and breach notifications
  • What happens to the data at the end of the contract

If your billing provider has not given you a document that ticks those boxes, ask for one before you ask anything else. The Information Commissioner’s guidance on contracts and liabilities is a useful sense-check while you read it.

Two follow-up questions worth asking once you have the paperwork:

  • Who are the named sub-processors, and how will you be told if that list changes?
  • What happens to your data on day one after the contract ends: returned to you, deleted, or held for a defined period?

Account-Level Security: Questions to Ask

If a billing provider’s security pitch starts and ends with “our data centre is ISO 27001”, press for more. Most breaches do not start in the data centre. They start at a login screen. Phishing is the most common attack type identified by UK businesses, hitting 38% of all businesses in the last year (Gov.uk Cyber Security Breaches Survey, 2026).

Sensible questions to ask:

  • Can two-factor authentication be enforced for every user on our account, not just admins?
  • What happens if a user loses their second-factor device, and how is the recovery process protected from social engineering?
  • Are user roles fine-grained enough that a support agent does not need full billing-run rights?
  • Is there a tamper-evident audit log of logins, customer record changes, and exports, and is access to it restricted to a dedicated data-protection role rather than handed out to every API key?
  • How is session length controlled, and are stale sessions invalidated when a user changes role or leaves?

A provider that has good answers to those will have good answers to most other security questions too. A provider that needs a week to come back to you on basic 2FA support is telling you something.

Customer-Facing Security: Where Bills and Statements Live

The other half of the picture is what happens to data when it leaves the platform on its way to a customer. PDF invoices, statements, and reminders are all personal data, and they get sent over a channel you do not control.

Things to check:

  • Can the end customer decide whether their PDF attachments arrive password-protected, and can that choice be set per email address rather than only per account?
  • When a recipient asks for a password to be turned on (or off), can the change be made without resending old invoices and without an engineering ticket?
  • Where the customer self-serves through a portal, is the portal protected by a real account login (and ideally 2FA), or by a guessable URL?
  • Where is the data physically hosted, and is it inside the UK or covered by a recognised international transfer mechanism?
  • What is the provider’s process for handling a customer data subject access request, and how fast can they actually turn one around?

From our experience: the question that catches the most providers out is the recipient-controlled password one. Plenty of platforms will tell you a password option exists somewhere. Far fewer let the end customer decide, on their own email address, whether the attachment is locked.

PECR: Two Things Generic SaaS Providers Miss

PECR is where telecoms-specific obligations bite, and it is the area where a generic billing tool repurposed for telecoms tends to fall short. Two questions are worth asking.

Marketing comms

If your billing platform also drives any kind of marketing email or SMS to your end customers (price-change notifications, upsell prompts, retention nudges), the consent and suppression rules are PECR’s territory:

  • How are consent records stored against each contact, with timestamp and source?
  • When a customer opts out, how quickly is the suppression list applied across every channel?
  • What audit trail can you produce if the ICO asks how a marketing message ended up in a particular inbox?

Call data on itemised bills

This is the one a SaaS-first provider almost never has a good answer for. PECR Regulation 9 gives subscribers the right to receive non-itemised bills (the ICO’s itemised bills guidance is the practical interpretation). The related convention on suppressing free-to-caller destinations from the itemised page comes from Ofcom’s General Condition C3 on clear, accurate billing rather than from PECR itself, but in practice the two are checked together. Questions to ask:

  • Can a subscriber be switched to a summary-only bill, on request, without a special engineering job?
  • Are free-to-caller destinations (helplines, support lines, freephone) suppressed automatically from the itemised page, in line with Ofcom GC C3, rather than left to per-bill manual redaction?
  • What is the retention period for call detail records, and is it documented in the data processing agreement?
  • Can the provider produce a customer’s call data, on request, in a usable format inside the GDPR one-month window?

If the provider goes quiet on Regulation 9, that is your answer. A telecoms billing platform that does not know what Regulation 9 is should not be billing telecoms.

Independent Assurance: Ask for Evidence, Not Logos

Vendor websites are full of logos and standards names. The useful question is what sits behind them. A few prompts that get to the truth quickly:

  • Is the platform aligned with OWASP ASVS, and at what level? “Aligned with” and “certified to” are different things; ask which is being claimed and ask to see how it is being checked.
  • What is the patch cadence for the application and its dependencies, and how quickly are security patches rolled out once a CVE is published?
  • Where compliance claims are made (ISO, SOC, anything else with a logo), what is the scope statement, and does it actually cover the billing platform you would be using?

You are not looking for perfection. You are looking for a provider who can answer specifically and quickly, rather than one who has to “come back to you”.

How SAFE Answers These

We are not going to pretend this post is not partly a self-portrait. The short version on our side:

  • Written processor agreement with named sub-processors and a defined post-contract data handling clause
  • 2FA on user accounts, role-based access, and a protected audit log that only data-protection-role users can read
  • Minimal bills by default, with recipient-controlled per-email-address passwords on full itemised PDFs, plus full self-service through the customer portal for customers who prefer to pull rather than receive
  • Per-subscriber itemisation control and automatic suppression of free-to-caller destinations on itemised pages, with a documented CDR retention period, to handle PECR Regulation 9 and the related Ofcom GC C3 billing-clarity expectation properly
  • UK data hosting and alignment with OWASP ASVS

If you would like the longer technical view of how these features work in the platform, our sibling product site has a companion Feature Spotlight on protecting customer personal data. And if you would rather just ask us the same checklist questions yourself, the contact page is the right place.

Frequently Asked Questions

Does a small telecoms reseller really need a data processing agreement with their billing provider?

Yes. GDPR Article 28 does not have a small-business exemption. If your billing provider processes personal data on your behalf (and they do, the moment you upload a customer record), the law requires a written contract that meets specific minimum terms. A short, clear DPA is enough; the absence of one is not.

Is UK data hosting still important if my provider uses a major cloud platform?

It still matters, but for slightly different reasons than in 2018. UK hosting simplifies your record of processing activities and removes the need to track international transfer mechanisms for the core platform. Where sub-processors sit outside the UK (for example, a payment gateway), the transfer mechanism for each one should be set out in the processor agreement.

What is the biggest PECR mistake telecoms resellers make with billing data?

In our experience, the most common one is keeping call detail records “in case we need them” with no documented retention period. PECR expects you to hold traffic data only as long as needed for billing, dispute resolution, or a clearly defined business purpose. Indefinite retention is hard to defend and easy for a regulator to spot.

How quickly do I have to report a personal data breach?

As a telecoms provider, you must notify the ICO within 72 hours of becoming aware of a personal data breach under PECR (ICO breach guidance). Your billing provider’s job is to make sure they tell you fast enough that your 72-hour clock has time left on it when it reaches you. Even where the processor agreement does not pin down an exact number of hours, “without undue delay” is what Article 33 expects, and you should be confident your provider will act in that spirit rather than waiting until the end of a working week.

Want to run this checklist against your current setup? Get in touch and we will help you walk through the questions, whether you stay with your current provider or look at moving to ours.

← Back to all posts

Need help with your telecoms billing?

We have been helping UK resellers since 2005. Talk to us about how we can help your business.

Get in Touch