The Breach You Cannot Assess
Today is the deadline. The ShinyHunters extortion group has given Ernst & Young until 31 July to make contact before it publishes what it claims to have taken. The data in question is not EY's. It belongs to EY's clients: personal and financial information used to prepare tax filings. And it was taken from a platform that, four months after the intrusion began, EY still has not named.
What Happened
EY uses a third-party IT service management platform so that its internal IT personnel can support EY teams performing tax-related work for clients. In practice, that means a ticketing system. Somebody raises a support request, attaches the document they are struggling with, and the document sits in the ticket.
According to EY's own breach notification, an unauthorised party accessed that platform between 28 March and 12 April 2026 and downloaded multiple documents. EY detected unusual activity on 23 April, secured its systems, removed the access and notified federal law enforcement. Affected clients are being offered 24 months of identity monitoring through Experian.
On 27 July, ShinyHunters added Ernst & Young to its data leak site with a final warning: make contact by 31 July or the files are published. The group told BleepingComputer that it obtained EY credentials through a supply-chain attack, and claimed those credentials gave it access to EY's Jira, GitHub and Azure environments. Those claims are unverified, and EY has not confirmed that ShinyHunters was responsible.
Why This One Is Different
Most breach commentary reaches for the same conclusions: patch faster, train staff harder, detect sooner. None of those are the interesting lesson here. EY detected the intrusion, contained it, engaged law enforcement and notified. On the mechanics of response, this was handled competently.
The problem is structural, and it sits one layer further out. EY has not disclosed the name of the compromised support system, the specific categories of information exposed, or how many people were affected. That is a defensible position for a firm managing an active extortion threat and a live law enforcement matter. It is also, for every organisation that engages EY, an impossible position to work with.
You cannot run a risk assessment on a supplier you cannot name.
Consider what a client is actually being asked to do. They know a platform was breached. They do not know which one. So they cannot check whether they use the same platform directly. They cannot ask their other advisers, their outsourced payroll provider or their legal counsel whether that platform sits in their stack too. They cannot query their own vendor register for it. They cannot instruct their security team to hunt for related indicators. Every practical control that a mature third-party risk function would reach for requires a name, and there is no name.
This is the fourth-party problem in its purest form. Most vendor due diligence stops at the direct supplier. The questionnaire asks EY about EY's controls. It rarely asks, with any force, which sub-processors and support platforms will touch the data, and it almost never establishes a contractual right to be told when one of them is compromised.
The Pattern: One Group, One Route In
EY is not an outlier. It is the latest entry in a campaign that has run through 2026 with remarkable consistency of method. ShinyHunters has claimed 3.1 TB from the National Association of Insurance Commissioners via a PeopleSoft compromise, up to nine million records from Medtronic, roughly 2.2 million from Kodak, and access to Abbott through a corporate single sign-on account obtained by voice phishing. Earlier in the year, the group's Salesforce-adjacent activity cascaded across hundreds of downstream customer environments through stolen OAuth tokens from third-party applications.
Read those together and the strategy is obvious. The group is not testing enterprise perimeters. It is targeting the platforms that sit between enterprises and their suppliers, because a single compromise there yields data from dozens or hundreds of organisations at once. Help desks, ticketing systems, integration tokens and identity connectors are the highest-yield targets in the modern enterprise, and they are almost universally governed as commodity IT.
Commercial Exposure for UK Organisations
Regulatory. If your data is in that dataset, the UK GDPR obligations are yours, not EY's. The seventy-two hour clock under Article 33 runs from the point at which you become aware of a personal data breach, and the regulator's position is that awareness arrives when you have a reasonable degree of certainty that a breach has occurred, not when the forensic report lands. An organisation that receives a notification from its adviser and then waits three weeks for clarity has a difficult conversation ahead of it. Firms with EU operations face parallel duties under NIS2 and, in financial services, DORA's third-party register requirements.
Financial. Tax filings are not generic personal data. They contain income, asset positions, corporate structure, beneficial ownership and the commercially sensitive judgements that sit behind them. In the hands of a competitor they are intelligence. In the hands of a fraudster they are the raw material for highly credible impersonation of the one adviser your finance team never questions.
Contractual. Enterprise engagement letters now routinely carry security warranties and breach notification clauses. Most of them run one layer deep. When the breach originates two layers out, at a platform your supplier chose and never disclosed to you, the question of who owes what to whom becomes genuinely difficult, and the answer is usually settled by whoever drafted the flow-down provisions more carefully.
Governance. Directors are expected to demonstrate oversight of material risk. A board that cannot answer the question "which third parties hold our most sensitive data, and on whose infrastructure" is not exercising oversight. It is relying on the reputation of the brand on the invoice, which is precisely the assumption this incident tests.
What To Do Now
Start by mapping the exposure properly. List every engagement in which an external adviser holds your tax, legal, payroll, HR or transaction data. Name the data, not just the firm. Most organisations discover at this point that the register they maintain for procurement purposes bears little resemblance to where sensitive information actually resides.
Then ask the fourth-party question, in writing, to every adviser on that list. Which sub-processors and support platforms handle our engagement data? Was any of it in scope of a recent incident? What is your notification commitment to us if a sub-processor is compromised? The responses will vary in quality, and that variance is itself useful information.
Start the notification clock on the correct trigger. If you are notified by an adviser, the question is not whether you have completed your investigation. It is whether you have a reasonable degree of certainty that personal data for which you are the controller has been affected. Document the reasoning and the timestamp either way, because that document is the one the regulator will read first.
Finally, rewrite the clause. Notification duties must flow down to sub-processors with a defined window, and your contracts should establish a right to be told the identity of a compromised platform under confidentiality. That single provision would have converted this incident, for EY's clients, from an unassessable exposure into a manageable one.
Three Questions for Leadership
First: which of our advisers hold our most sensitive data, and on whose platform does it actually sit? Second: if a supplier told us they had been breached but declined to name the system involved, what would we actually do, and who has the authority to decide? Third: who in this organisation owns fourth-party risk, by name, and when did they last report to the board?
The Strategic Takeaway
The uncomfortable truth in this incident is that EY's clients did not choose the platform, were not told about it, cannot assess it, and are nonetheless carrying the regulatory and commercial consequences of its compromise. Their disclosure timetable is now being set by a criminal countdown clock rather than by their own governance.
Third-party risk management was designed for a world in which you could draw a boundary around your suppliers and assess what was inside it. That world is gone. Data now moves through layers of platforms that no individual party has fully mapped, and the attackers have understood this considerably faster than the assurance industry has. The organisations that respond well to the next incident of this type will be the ones that already know, today, whose infrastructure their information is sitting on.
Do you know whose platform your data is actually on?
A focused engagement on third-party and fourth-party risk: supplier data mapping, contractual notification architecture, and board-level reporting that stands up to regulatory scrutiny.
Discuss More →