On 8 May 2026, the Irish Data Protection Commission announced its final decision following an inquiry into a series of personal data breaches at Permanent TSB. The regulator fined the bank a total of €277,500 and issued a reprimand.
This was not a purely technical hacking case in the usual sense. According to the DPC, malicious actors who already held certain customer information called Permanent TSB’s Open24 Contact Centre, impersonated account holders, gained access to accounts, changed account details, and obtained additional account information.
For compliance, security, and customer-service leaders, that is the important point. A phone channel can become a high-risk attack surface if identity checks and account-change controls are too easy to defeat.
What the Irish DPC said happened
The DPC says the breaches were first reported in May 2022 and involved three incidents. In each incident, malicious actors contacted the Open24 Contact Centre while posing as genuine customers.
In the regulator’s 8 May 2026 press release, it says appropriate security protocols were not followed in all three incidents. As a result, the attackers were able to:
- change details associated with the affected accounts
- obtain additional account information
- expose account holders to an increased risk of further fraud
The DPC also says affected customers had to close their accounts and that some suffered financial loss. Those facts frame this as more than an isolated authentication error. The regulator is describing a failure in operational controls around a live customer-service channel handling personal data and account changes.
Why Permanent TSB was fined
The DPC found that Permanent TSB infringed three GDPR provisions.
Article 5(1)(f) and Article 32(1): security and integrity failures
First, the DPC found that Permanent TSB infringed Article 5(1)(f) GDPR, the principle requiring personal data to be processed with appropriate security, including protection against unauthorised access. Second, it found an infringement of Article 32(1) GDPR, which requires controllers to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk.
The combined fine for those two findings was €250,000. The DPC’s wording is useful here. It did not describe this only as staff error or only as fraud. It tied the outcome back to the organisation’s technical and organisational measures within the Open24 Contact Centre. That is exactly how regulators often look at phone-based impersonation cases: not as an unfortunate one-off, but as a control-design problem.
Article 33(1): late breach notification
The DPC also found that Permanent TSB infringed Article 33(1) GDPR by failing to notify the regulator without undue delay and within 72 hours of becoming aware of the breaches. For that, it imposed a separate €27,500 fine.
This is a useful reminder that GDPR enforcement can stack. An organisation may face scrutiny both for the security failure itself and for how it handled breach escalation once warning signs appeared. That same reporting lesson shows up in our analysis of Canal+ breach reporting.
For many teams, the operational lesson is simple: if fraud, account compromise, or unauthorised disclosure is being investigated, privacy and incident-response leads should be involved early. Waiting too long to decide whether an event is reportable can become its own regulatory problem.
What this means for compliance, security, and customer-service teams
This case should be read well beyond the banking sector. Any organisation that verifies identity by phone, changes customer account details through a contact centre, or allows service agents to disclose account information verbally should pay attention.
Phone authentication is a security control, not just a CX process
Many organisations still treat call-centre verification as a customer-service script rather than a formal security control. That is a mistake. If an attacker can collect enough background information to sound credible on a call, weak or inconsistent challenge questions may offer very little protection. That wider control theme also appears in the ICO’s recent South Staffordshire fine, where familiar operational weaknesses sat behind a major breach.
Where the risk is meaningful, organisations should review whether they rely too heavily on static data points that can be guessed, bought, phished, or reused from previous breaches.
Change-of-details requests need extra friction
Changing contact details, payment details, or linked-account information should usually trigger stronger controls than routine account queries. Examples may include step-up verification, out-of-band confirmation, temporary holds, or manual review where risk indicators are present.
The exact control set will vary by business model, but the principle is consistent: high-impact account changes should not move through the easiest channel with the weakest checks.
Fraud signals must trigger breach escalation quickly
The Article 33 point matters because many organisations separate fraud operations, cyber security, and privacy compliance too rigidly. If those teams are not joined up, a possible personal data breach can sit in the wrong queue while the 72-hour window keeps moving.
The safer approach is to define clear escalation triggers. If impersonation, unauthorised account access, suspicious detail changes, or unauthorised disclosure are suspected, someone should be responsible for assessing possible breach-reporting obligations immediately.
Practical checklist for organisations
If your business handles customer data by phone, this case is a good prompt for a targeted control review:
- Map every phone-based identity and account-change process.
- Identify which steps rely on static customer information as proof of identity.
- Review whether agents can override or skip verification steps.
- Add stronger controls for high-risk requests such as detail changes or disclosure of sensitive account information.
- Test fraud and impersonation scenarios through mystery-shop or red-team style exercises.
- Confirm when fraud cases must be escalated to privacy or legal for Article 33 assessment.
- Record who decides whether the 72-hour breach-notification threshold is met and how that decision is documented.
For UK organisations, the same broad lesson applies under UK GDPR even though this case comes from Ireland. Weak access controls and slow breach escalation remain classic enforcement triggers.
Final takeaway
The Permanent TSB decision is a practical example of how data protection failures can emerge from ordinary operational processes, not just from malware or large-scale cyber attacks.
On the facts published by the DPC on 8 May 2026, the bank was penalised both for inadequate security controls in its contact-centre process and for failing to notify the regulator within the required timeframe. That combination should focus attention on two areas many organisations still underestimate: phone-based authentication and fast breach escalation.
The full DPC decision has not yet been published. When it appears, this article should be updated with any additional detail on the regulator’s reasoning, mitigating factors, and the specific shortcomings identified in Permanent TSB’s controls.
