Data Breach in the UK: Lessons from LGPD
138 pensioners saw each other's data on a British portal. The error was basic — and any Brazilian company could repeat it.
by Cleverson Gouvêa

Data breach is no longer a distant multinational problem: in March 2026, the UK public service pension portal exposed personal information of retirees due to a flaw that any basic audit would have caught. The Capita case made headlines in the UK — and is a direct warning for any Brazilian company that collects customer data under the LGPD. In this guide, I break down what happened, why it happened, and what you should do differently.
TL;DR
- On 30/03/2026, the Civil Service Pension Scheme (CSPS) portal, operated by Capita, allowed 138 members to see other people's pension statements for about 35 minutes.
- The cause was broken access control: each user should only see their own data, and the system slipped.
- The same portal had already gone live without DNSSEC, a basic protection for a financial website.
- This was not the first time: Capita was fined £14 million by the UK regulator (ICO) for a 2023 data breach that affected 6.6 million people.
- For companies in Brazil, the risk scenario is identical under the LGPD — and the errors are avoidable.
What happened in the Capita data breach
On 30 March 2026, for approximately 35 minutes, the Civil Service Pension Scheme portal — the pension scheme for about 1.7 million UK public servants — presented a serious defect. When generating the Annual Benefit Statements (ABS), the system mixed up records: 138 members either saw someone else's statement or had their own statement seen by others. Name and address were among the exposed data.
The scheme's administration is the responsibility of Capita, a British outsourcing giant that took over the contract on 1 December 2025 — a seven-year deal valued at £239 million, inherited from the previous operator, MyCSP. As soon as the flaw was identified, the statement generation function was suspended, and all affected individuals were contacted on 3 April. On 16 April 2026, the UK government itself referred the case to the Information Commissioner's Office (ICO), the country's data protection regulator.
It may seem like a small number — 138 people. But in data protection, scale does not define severity. What defines it is the nature of the data (financial, personal) and the principle failure: a system that mixes records between users broke the most basic rule of any application dealing with individual accounts.
The technical flaw: broken access control
The heart of the problem is a concept every developer should have tattooed: access control. The idea is simple — each authenticated user can only access resources that belong to them. When this control fails, what the industry calls broken access control arises, now the number one item on the OWASP web application risk ranking.
In Capita's case, the portal delivered user A's document to user B. In practical terms, it's like an ATM showing the balance of the customer in line to the next customer. There was no sophisticated invasion, no ransomware, no movie hacker: it was the application doing the wrong thing by itself when generating the statements.
The aggravating factor: the portal went live without basic security
Here lies the part that most bothers those who work with the web. Even before this episode, experts had already pointed out that the portal went live in December 2025 without DNSSEC — a DNS security extension that makes domain hijacking and redirecting users to fake websites more difficult. The protection was only activated after a public warning.
A quote from a security expert cited by the British press sums it up: "this is the absolute basics for managing a website. It's a serious failure for a financial website." When the bread and butter of web security is neglected, a data breach ceases to be bad luck and becomes a matter of time. It's the same lesson we saw when GitHub was used to distribute a malicious VS Code extension: the entry point is almost always an avoidable oversight.
Not the first time: the £14 million fine
The 2026 episode is not an isolated case. It happens with Capita still bearing the scar of a much larger data breach from 2023, the bill for which only arrived in October 2025. It's worth comparing the two events side by side:
| Aspect | 2023 Incident | 2026 Incident |
|---|---|---|
| Type | Ransomware attack | Access control failure |
| Origin | Malicious file downloaded by employee | Defect in statement generation |
| People affected | 6.6 million | 138 |
| Exposed data | Pensions, HR, sensitive data | Name and address |
| Response time | Device isolated only after 58 hours | Function suspended immediately |
| Consequence | £14 million fine from ICO | Case referred to ICO |
In the 2023 invasion, a malicious file was downloaded on an employee's device on 22 March. Despite a high-priority alert being triggered within 10 minutes, the company only isolated the machine 58 hours later — a window sufficient for the attacker to extract nearly 1 terabyte of data between 29 and 30 March. The ICO concluded that the security operations centre was understaffed and that systems with millions of records did not undergo recurring penetration tests.
The result was a fine of £14 million (the sum considered £8 million for Capita plc and £6 million for Capita Pension Solutions), announced by the ICO in October 2025. The initial calculation reached £58 million before reductions. The regulator's message was explicit: data security is not a firefighting task; it is continuous maintenance.
Why this matters for Brazilian companies
"It's a UK case, not relevant to me." It is, and very much so. The regulatory logic that punishes Capita is the same that governs the processing of personal data in Brazil. Replace "ICO" with "ANPD" and "UK GDPR" with "LGPD" and the entire story could take place here.
The General Data Protection Law (Law 13.709/2018) requires any company that processes personal data to adopt technical and administrative measures to protect it. The National Data Protection Authority (ANPD) can apply warnings, require blocking or deletion of data, and impose fines of up to 2% of revenue, capped at R$50 million per infraction. And the trigger is not only external attacks: the obligation to notify incidents applies both to sophisticated ransomware and to the bug that showed one customer's data to another.
The risk lies in the details, not the spectacular
Capita's 2026 data breach proves a point I repeat to every client: the greatest risk is rarely the Hollywood attack. It's the poorly tested access control, the unvalidated form, the exposed admin panel, the public backup. These are flaws cheap to fix and expensive to ignore. The same silent fragility appeared in the case of NPM packages infected by Shai-Hulud, where blind trust in a dependency opened the back door.
The 6 practical lessons from the case
I've taken six lessons from this episode that we apply at Agathas Web in any system that touches customer data. None are expensive; all are frequently skipped.
- Access control is mandatory testing, not optional. Every endpoint that returns personal data must verify that the logged-in user is the owner of that data. Test this explicitly, with different accounts, before going live.
- Basic security comes before launch, not after. HTTPS, DNSSEC, security headers, and strong authentication are go-live prerequisites, not improvements for "phase 2".
- Incident response time is a life-or-death metric. Capita's 58 hours in 2023 turned into 1 TB leaked. Have a response plan and rehearse it.
- Penetration testing is recurring. A pentest only at launch ages in weeks. Redo it after every relevant change.
- Minimise what you collect. Data you don't store can't leak. Ask if you really need that CPF, that address.
- Notify quickly and transparently. The LGPD requires communication to the ANPD and data subjects within a reasonable time. Hiding an incident worsens the penalty and destroys trust.
Official and secure system vs workaround
There is a thread connecting the Capita case to a decision Brazilian companies make every week: use the official, auditable tool, or the cheaper workaround that "works for now". Capita erred even while operating an official platform — imagine the risk for those running sensitive data on improvised solutions, without support, without security updates, and without anyone responsible when something breaks.
It's exactly the logic we defend when it comes to service integration. Running your company's communication on unofficial APIs or cloned apps is building on sand: no continuity guarantee, no audit trail, and your number (and your customers' data) hostage to a layer that could disappear at any moment. I've detailed this trade-off in the comparison between WhatsApp Business App and Official API and in the guide on what to do when WhatsApp is blocked. The conclusion is always the same: official infrastructure costs a bit more and protects you much more.
Security is not a feature added at the end. It's an architecture decision made at the beginning — the same principle that applies to a pension portal, an educational app, or the security layer of an entire operating system like Android 17.
How to protect your customers' data today
You don't need to be a multinational to do your homework. This is the minimum checklist I recommend to any business that maintains customer records:
- List all points where your application returns personal data and test access control on each one.
- Enable HTTPS everywhere, force redirects, and renew certificates automatically.
- Use strong authentication (preferably with two-factor) for administrative access.
- Keep dependencies and the server updated — most breaches exploit known old versions.
- Make encrypted backups and test actual restoration, not just the scheduling.
- Have a written incident response plan, specifying who does what and within what timeframe.
- Document what you collect and why — it's an LGPD requirement and excellent data hygiene.
If your team doesn't have the bandwidth to handle all this, hiring someone who treats security as part of the project — not as an add-on — is much cheaper than an ANPD fine or the loss of your customers' trust.
Conclusion: doing the basics well is what protects
Capita's data breach was not the work of a criminal genius. It was the sum of neglected details: an access control not thoroughly tested, basic security postponed, a history of slow response. Precisely because it is mundane, it teaches so much — because the same oversights are within reach of any rushed company.
The good news is that the way out is known and accessible: treat customer data with the care you would want for your own. If you want to review how your system handles personal data and close those doors before someone finds them, the Agathas Web team can help make that diagnosis calmly.
Related posts

WhatsApp Cloud API: Complete Guide to the Official Meta API
What is the WhatsApp Cloud API, how it works, what it really costs, and when it's worth it. We demystify Meta's official API without beating around the bush.

WhatsApp Coexistence Mode: What's Allowed in 2026
Can you use WhatsApp Business on your phone and the official API on the same number? Yes — and coexistence mode has changed the game. See the rules and limits.

WhatsApp Business Ban: The 2026 Wave in Brazil
The WhatsApp Business ban wave in 2026 has already paralysed thousands of operations in Brazil. See why and how to shield yours.