A few weeks back I watched a vendor tech log into our ticketing system to troubleshoot a project ticket. It was routine. They needed access to the ticket history to see what had been tried, so I gave them a temporary login. Standard stuff.
What I did not do, and what I realised only after reading the EY breach notification this week, was ask what their support tool looked like on the inside. Because the ticketing platform they were logging into might have been the one that just got breached.
"The breached system was not EY's core ledger. It was the ticketing tool vendors use to support clients, and the class-action lawyers were on the case within 24 hours."
On 20 July 2026, CFO.com reported that EY had notified clients of a data breach involving a third-party IT support ticket platform called Trial Balance. The following day, Accounting Times confirmed EY had begun contacting affected clients. By 21 July, International Accounting Bulletin reported that Edelson Lechtzin was already reviewing potential class-action exposure.
This is not a story about EY's internal security failing. It is a story about the tool your vendors use to support you, and the one question nobody in the procurement chain is asking.
The attack surface you cannot see
Here is the shape of the problem. Your organisation uses a ticketing platform. It might be ServiceNow, Jira Service Management, Zendesk, or a specialist tool like Trial Balance. Your internal team works in it. So do your vendors, your MSP, your external auditors, and the contract IT staff who rotate through every six months.
Each of those vendors has their own ticketing platform where they log the work they do for you. When something goes wrong with one of their tickets, the natural thing is to give them direct access to your platform so they can see the full context. You create a vendor login, set a permission scope, and move on.
But here is the part that makes this EY story different. The breach did not happen inside EY's network. It happened inside the third-party support ticket platform that EY and many of its clients use to manage their day-to-day support work. That platform sits between EY and its clients. It holds tax engagement notes, client identifiers, contact details, and the kind of procedural information that tells an attacker exactly how to impersonate someone in a support call.
If you have ever emailed your accountant a signed authority form through a support portal, that portal is the surface I am talking about.
The Trial Balance incident
According to reports published on 20-21 July 2026, the compromised platform is Trial Balance, a tool used by accounting and professional services firms to manage client support tickets. EY notified clients that their data had been exposed through this third-party platform, rather than through EY's own systems.
The key details as reported:
| Detail | Source |
|---|---|
| Breach notification sent to EY clients | CFO.com, 20 Jul 2026 |
| Ey tells clients data exposed via third-party ticket platform | Accounting Times, 21 Jul 2026 |
| Edelson Lechtzin reviewing class-action claims | International Accounting Bulletin, 20 Jul 2026 |
| Breached system was IT support ticket platform, not core systems | Multiple sources, 20-21 Jul 2026 |
The class-action angle tells you something important. When a firm like Edelson Lechtzin starts reviewing claims within 24 hours of a notification, it means the legal theory is clear: the data held in a support ticket platform was sensitive enough that its exposure creates real harm. This is not a "low-risk" notification.
Why this is the breach pattern of 2026
The EY incident is the latest in a pattern that has been building all year. Supply-chain breaches that target the integration layer between organisations, rather than the organisations themselves. The Oracle EBS vulnerability that hit Estee Lauder on 21 July. The IT ticket platform that hit EY on 20 July. These are not random. They share a structure:
- A critical integration tool sits between vendor and client.
- That tool holds client data by design (ticket history, engagement notes, contact details).
- The tool is managed by a third party, not by either the vendor or the client.
- Security assessments focus on the vendor's systems but skip the integration tool.
If you are an IT-pro at an organisation that works with external vendors, auditors, MSPs, or contract teams, you have this blind spot in your stack right now. I have it in mine.
The one-page checklist I would run this week
Here is the audit I am running on my own setup this week, and the one I would recommend for any SMB or enterprise team that uses a shared ticketing platform with vendors.
Step 1: Map every vendor-facing platform
List every tool where an external party has a login. Ticketing platforms top the list, but also include document sharing portals, client communication tools, and project management systems. If a vendor can see client names, contact details, or ticket content, it goes on the list.
Step 2: Ask which platforms the vendors themselves use
This is the step almost everyone skips. Your vendor has a login to your ServiceNow instance. But your vendor also uses their own support ticket platform to manage their work across multiple clients. If that platform gets breached, your data sitting inside it is exposed, even if your own instance is perfectly hardened.
The EY breach happened on the vendor-facing side. Your question to every vendor should be: "What platform do you use to manage client support tickets, and can I see your vendor security assessment for that platform?"
Step 3: Classify the data in your support tickets
Not every ticket contains sensitive data. Password reset requests usually do not. But tax engagement letters, signed authority forms, onboarding documentation with identity verification, and tickets that include "please call this client at [number] to verify" absolutely do.
Run a quick scan of the last 20 tickets in your most active vendor-partnered queue. If any of them contain client PII, financial details, or authentication-related information, you have data living inside a third-party platform that you did not assess.
Step 4: Limit what vendors can see by default
Most ticketing platforms let you create restricted access roles for external users. The default vendor login often has more visibility than it needs. Reduce it to the minimum set of fields and queues that the vendor actually needs to do their work.
If a vendor needs to see a ticket title and status but not the attached signed form, configure the role to hide attachments. If they need to update a ticket but not view the client contact history, scope it to the ticket level only.
Step 5: Add a third-party platform question to your vendor assessment
If you have a vendor security questionnaire (and you should), add one question: "Do you use a third-party IT support ticket platform to manage client work, and if so, what is their security certification and breach notification process?"
The answer to that question would have caught the EY exposure before it became a notification.
The cost of not asking
The class-action exposure for a breach like this is not hypothetical. Edelson Lechtzin specialises in data breach class actions. Their involvement within 24 hours means the legal framework for claiming damages is already established.
For an SMB, the cost is different but equally real. A breach notification to your clients that starts with "our vendor's vendor had an incident" is hard to explain, harder to justify in a competitive tender, and almost impossible to contain once the media picks up the vendor name.
What I am changing
I am adding a question to every vendor onboarding I manage from here. "What is your internal support ticket platform, and can I review their security posture?" I am also reviewing the existing vendor list and reaching out to the ones whose platforms I know hold client data.
It is not a big change. It is one question. But it is the question that would have surfaced the EY breach path before it became a notification.
Further Reading
- CFO.com - EY reports data breach on IT support ticket platform: Trial Balance (20 Jul 2026)
- Accounting Times - EY tells clients of third-party data breach (21 Jul 2026)
- International Accounting Bulletin - Edelson Lechtzin reviews potential claims over EY tax data breach (20 Jul 2026)
- Help Net Security - Estee Lauder discloses data breach tied to Oracle EBS vulnerability (21 Jul 2026)
- SecureInSeconds - Your AI agent runs as you, and your vendors have agents too
- SecureInSeconds - How the Frontier Airlines breach shows the supply chain problem
- SecureInSeconds - The former employer data retention blind spot
- SecureInSeconds - Medical records stolen, Australia edition
If you manage vendor relationships or IT security for your team, forward this to whoever runs your procurement process. The question they need to add to the next vendor assessment takes five seconds to ask and saves a notification cycle.
Mathew Clark / Founder, SecureInSeconds / Currently: auditing which vendors can see client data through my own ticketing platform
