Protecting Customer Personal Data: GDPR-Ready Security in SAFE

GDPR started applying on 25 May 2018, which makes today its eighth birthday. Eight years in, the rule that still catches UK telecoms resellers out is the quiet one: Article 32, “security of processing”. It does not give you a checklist. It tells you to put security measures in place that match the risk, and it leaves you to prove you have done so.

That is where the product underneath your billing has to pull its weight. This post walks through the features in the SAFE Billing Platform that exist specifically to help you meet Article 32, plus the bits of PECR that are easy to miss when your business sits on call data every day.

Key Takeaways

• The ICO issued around £21.7m in fines across 15 actions in 2025, an eightfold rise on the £2.7m total for 2024 (URM Consulting analysis of 2025 ICO enforcement, 2026), and the ICO’s enforcement register lists each case in detail
• 46% of UK small businesses experienced a cyber breach or attack in the previous 12 months in the 2025/2026 survey, and phishing remains the most common attack type, hitting 38% of all businesses (Gov.uk Cyber Security Breaches Survey, 2026)
• Under the Data (Use and Access) Act 2025, the ICO now has powers to issue PECR fines up to £17.5m or 4% of global turnover, the same upper scale as UK GDPR (ICO guidance on DUAA commencement, 2026)
• SAFE ships with 2FA on user accounts, customer-controlled bill detail with optional per-recipient passwords, role-based access with protected audit logs, and PECR-aware itemisation that suppresses free-to-caller numbers

Key terms in this article

What does GDPR Article 32 mean?

GDPR Article 32 (“security of processing”) is the rule that you must put in place security measures appropriate to the risk of the personal data you handle. For a telecoms reseller, that covers things like 2FA on staff accounts, encryption of customer files, and access controls on call records.

What is PECR?

PECR (Privacy and Electronic Communications Regulations) is the UK rule that sits next to GDPR for electronic communications. It covers marketing consent, cookies, breach reporting for telecoms providers, and the rules on what you can put on an itemised bill.

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 covers authentication, session management, access control, and cryptography, and gives developers something specific to verify against.

What does two-factor authentication do?

Two-factor authentication (2FA), sometimes called multi-factor authentication, asks for a second proof of identity on top of the password. A stolen password on its own no longer gets an attacker in, because they also need the code from your phone or authenticator app.

What is a password-protected customer email?

A password-protected customer email is one where the invoice or statement attachment is encrypted with a password, so only the recipient can open it. In SAFE, the password is set per email address rather than per customer, so two recipients on the same account each have their own key.

Why Article 32 Is the One That Bites

Most of GDPR is about lawful basis, fairness, and giving people rights over their data. Article 32 is the operational bit. It says you must put security measures in place that are appropriate to the risk, and it expects you to think about things like pseudonymisation, encryption, confidentiality, integrity, availability, and resilience.

That sounds abstract until the ICO turns up. Their 2025 enforcement run shifted sharply toward security and data breach fines, which made up the bulk of the £21.7m total (URM Consulting analysis of 2025 ICO enforcement, 2026); the underlying cases are listed in the ICO’s own enforcement register. Most of those fines were not about being malicious. They were about having too little security underneath services that handle personal data.

For UK telecoms resellers, the data is exactly the kind regulators care about: who called whom, when, for how long, what they paid, and where they live. The SAFE features below exist so you have credible answers when an auditor asks how you protect it.

Two-Factor Authentication on SAFE Accounts

Account takeover is one of the most common ways a small business loses customer data. Phishing is the most common attack type identified by UK businesses, hitting 38% of them in the last year (Gov.uk Cyber Security Breaches Survey, 2026). A staff member clicks a convincing email, types their password into a fake login page, and the attacker walks straight in.

Two-factor authentication closes that door. Even if someone hands over their password, the attacker still needs the second factor: a one-time code from an authenticator app on the user’s phone. SAFE supports 2FA on user logins using the standard time-based code format that any modern authenticator app handles, so there is no extra app to install for your team.

A few practical points worth knowing:

• 2FA can be required for every user in your account, not just admins
• Each user enrols their own device, so a lost phone does not lock out the rest of the team
• Admins can reset a user’s second factor without seeing the user’s password
• The login record shows which users have 2FA enabled and when they last used it

From our experience: the biggest reason resellers delay turning 2FA on for everyone is the fear of locking out a senior person at the wrong moment. The cleanest path is to enrol the admin team first, give them a week to settle in, then roll out to the rest. The fix-up calls are short and rare.

Minimal Bills by Default, With Per-Recipient Passwords

When you email an invoice or a statement, you are sending personal data over a channel you do not control. The recipient might forward it. The address might be wrong by a character. The mailbox might be shared. Article 32’s “confidentiality” language is exactly aimed at this, and PECR’s right to a non-itemised bill is the telecoms-flavoured version of the same idea.

SAFE sends a minimal invoice by default. The first bill carries the charge totals without itemisation, so the personal data on the page is reduced to the minimum that lets the customer pay. From there, the customer chooses what they want to receive in future: a summary bill, a full itemised bill, or an itemised bill with a password on the attachment. The choice sits with the recipient, which is the right place for it.

Where consent is given out of band (a signed form, a phone call you have logged, a written instruction), an operator can mark the account as GDPR and PECR consented in SAFE so the next bill goes out in the agreed format without having to chase the customer through the system.

How the password layer works in day-to-day use:

• Passwords are set per email address rather than per customer, which is more convenient for multi-account customers with different branch contacts, and more secure because each recipient has their own key
• If an email lands in the wrong inbox, the attachment stays sealed
• You can rotate a recipient’s password without resending old invoices
• Customers who self-serve through the customer portal can pull bills with their own portal login instead, no PDF password needed

The combination of minimal-by-default plus per-recipient passwords keeps the volume of personal data flowing through email lower than it was, and gives the customer real control over what their bill looks like.

Role-Based Access and Audit Logs

GDPR’s accountability principle wants you to know who saw what. If a customer complains that their account details have been altered, or your records show charges no one can explain, you need to be able to answer the “who and when” question without guessing.

SAFE uses role-based access so each user only sees the parts of the platform they need. A support agent does not need full billing-run rights. A finance contact does not need to edit tariffs. Limiting what each role can touch limits how much damage any single compromised account can do.

Sitting underneath that is an audit log. Logins, customer record changes, tariff edits, and exports are recorded with the user and timestamp. The log itself is protected: only users with the data protection role can read it, and it is not available through the API. That keeps the record honest even if a working user account is later compromised, because the attacker cannot quietly export or alter the trail.

The combination matters more than either piece on its own. Roles stop most accidents happening; the log tells you the truth about the ones that do.

PECR and Itemised Bills: The Telecoms-Specific Bit

This is the piece most generic GDPR posts skip. PECR contains specific rules on itemised billing that only apply to telecoms providers, and they sit next to GDPR rather than inside it.

The relevant rule is Regulation 9 of PECR. It gives subscribers the right to receive bills that are not itemised, and the ICO’s itemised bills guidance is the practical interpretation most resellers work from. The ICO also points out that the conventions on suppressing free-to-caller destinations (helplines, support lines, freephone) sit under Ofcom’s General Condition C3 on accurate, clear billing rather than under PECR itself, but they tend to be discussed in the same breath because the practical effect is the same: the bill payer sees less than they otherwise would about who was called.

In practice, that pulls a few questions onto your desk as a reseller:

• Can a customer ask for a non-itemised bill, and can you produce one without a special engineering job?
• Are free-to-caller destinations suppressed automatically on the itemised page, so they do not need ad-hoc redaction every billing run?
• How long do you hold the call detail records that sit behind those bills, and is that retention period documented?

SAFE answers each of these out of the box. Itemisation is a per-customer setting, so a subscriber can be moved to a summary-only bill at any point without rewriting your billing run. Free-to-caller numbers (helplines, support lines and similar) are suppressed automatically from the itemised page, in line with the Ofcom GC C3 expectation on clear, accurate billing. And CDR retention is set on the account, so you are not keeping years of personal call data on the off chance you might need it. If you need help configuring any of these for one of your customers, the contact page is the right starting point.

PECR also covers marketing comms (consent records, suppression lists, the rules on unsolicited calls and emails), and the Information Commissioner’s PECR guidance is worth a read alongside your own policies. The Data (Use and Access) Act 2025 lifted PECR penalties onto the same upper scale as UK GDPR, so the ICO can now issue PECR fines of up to £17.5m or 4% of global turnover (ICO guidance on DUAA commencement, 2026). The headline number is much larger than the old £500,000 ceiling, and the regulator’s stated appetite for serious enforcement has moved with it.

OWASP ASVS Alignment

OWASP ASVS is the open standard for verifying that a web application is doing the right things in the right places. It covers authentication, session management, access control, cryptography, and dozens of other categories. The full standard lives at the OWASP ASVS project page if you want to read it cover to cover.

SAFE is built and tested against ASVS. That gives us, and you, a specific list of controls to point at when someone asks “how do you know your platform is secure?” It is not a certification, and we are not going to claim one we do not hold. What it does mean is that the security controls in the platform are verifiable against an external, public standard, rather than against marketing copy.

Two caveats worth keeping in mind:

• Aligning with ASVS is about the platform’s controls, not a substitute for your own security practices
• Some controls (strong passwords, 2FA, careful permission management) live on the customer side; alignment helps but cannot replace those choices

For the broader compliance picture (Ofcom, VAT, accessibility, end-of-contract notifications), our sibling site has a longer UK telecoms billing compliance guide that puts data protection alongside the other regulators you have to satisfy.

What About a Breach?

Prevention does most of the work, but you still need a plan for the day something goes wrong. As a telecoms provider you must notify the ICO within 72 hours of a personal data breach under PECR (ICO breach guidance), and a usable recent copy of your data makes that conversation a great deal shorter. We cover the mechanics in our daily disaster recovery guide, so the detail is not repeated here.

Getting Started

If you are an existing SAFE customer and any of the above is not switched on, it should be: 2FA, password-protected emails, role-based access, and audit logging are all available on your account today. The fastest way to get them configured properly across your team is to drop us a line.

Browse the SAFE feature set or contact our team and we will walk you through the data-protection settings for your account.