Cybersecurity

The Tax Files Left Through the Help Desk

EY says an intruder sat in a third-party ITSM platform for two weeks and took client tax documents. The lesson for owners is the ticket queue, not the tax system.

CybersecurityBy Servola Tech Desk2026-07-205 min read

AI-assisted, edited by humans. | Editor-in-Chief: Leon Soliman | Editorial standards

The Tax Files Left Through the Help Desk

Key takeaways

An unauthorized third party sat inside EY's third-party ITSM platform from 28 March to 12 April 2026 and client letters are dated 13 July, so roughly three months passed between the intrusion ending and clients being told.
EY identified anomalous activity on 23 April 2026, eleven days after the access window closed, which is the earliest date any affected client could have started its own clock.
Treat your ITSM platform as a regulated data store: inventory what is actually held in ticket bodies and attachments before your next audit cycle.
Set an attachment retention limit on tickets, with automatic purge, and default it to weeks rather than the indefinite retention most help desks run today.
Rewrite the vendor clause so notification is owed in hours, and so the scope explicitly names ticket bodies and attachments, not just the vendor's production database.

The attachment nobody thought twice about

The document that leaked was attached by someone doing the job correctly. A tax associate hits a permissions error on a client return, raises a ticket with the internal IT team, and attaches the file so the analyst can reproduce the fault. The ticket is closed that afternoon. The attachment is never mentioned again by anyone.

Ernst & Young has disclosed that an unauthorized third party accessed a third-party IT service management platform used by its internal IT teams to support its tax practice. In EY's own words, support tickets submitted through the platform "may include documents containing client tax information". The data types reported include personal and financial data contained in or used to prepare tax filings.

EY states that the intruder was in the platform between 28 March 2026 and 12 April 2026 and downloaded documents pertaining to a number of EY clients. The firm also says it is "not aware of any misuse or further exposure of your personal information". Both statements are on the record. Only the second one is reassuring.

Two weeks inside, eleven days to notice, three months to tell

The dates carry more weight than the technique here. Access ran from 28 March 2026 to 12 April 2026. EY identified anomalous activity on 23 April 2026. Notification letters to affected clients are dated 13 July 2026, and a filing was made with the California Attorney General on 15 July 2026. Four states were notified.

What EY has not published matters just as much. The vendor behind the platform has not been named. The initial access vector has not been disclosed. No victim count has been given, and it remains unclear how many clients were affected. No ransomware group has claimed responsibility, which removes the usual public source of a stolen-file inventory.

For a client of the firm, that combination is the hard part. You know your documents may have moved. You do not know which ones, you do not know how the intruder got in, and you cannot check the claim independently because you never held the logs. Everything you can say to a regulator is a quote from somebody else.

The help desk is a data store nobody put on the map

The system that leaked was not the tax platform. It was the ticket queue. That distinction is the whole lesson, and it applies to firms far smaller than EY.

Staff attach client documents to support tickets as a matter of routine, because attaching the file is the fastest way to get the fault fixed. Over a few years the help desk quietly accumulates an unclassified, vendor-held, indefinitely retained shadow copy of the most sensitive material the firm holds. Nobody designed it. It is a by-product of everyone being helpful.

It also tends to be invisible on paper. The ITSM platform rarely appears on a data map, rarely shows up in a record of processing activities, and rarely triggers a data protection impact assessment, because nobody classifies the IT help desk as a place where client data lives. The tax platform gets the encryption review, the access certification and the retention policy. The queue that holds copies of the same documents gets a license renewal.

Your 72-hour clock starts when your processor decides it does

A processor's notification delay is subtracted directly from your own compliance window. Under the GDPR, a controller's 72-hour notification duty runs from the moment the controller becomes aware of a personal data breach. If the party holding your data takes almost three months to reach you, your clock starts almost three months after the attacker finished.

Apply that to these dates. Detection on 23 April 2026, client letters dated 13 July 2026. A firm receiving that letter is opening its own supervisory authority conversation in mid-July about downloads that happened in late March, with no telemetry of its own, no named vendor and no scope of exposure to describe.

Regulators are not indifferent to who caused the delay, and a controller that acted promptly on the information it had is in a defensible position. But the practical experience is still poor: you are the one explaining a gap you did not create, using facts you cannot verify, to an authority that will reasonably ask why your contract permitted the delay in the first place.

Three changes worth making before the next audit cycle

Start by finding out what your ticket queue actually holds. Export a year of attachments by file type and sample them. Most firms that run this exercise discover payroll files, identity documents, signed contracts and tax workpapers sitting in closed tickets that were resolved and forgotten years ago.

Then set retention. Attachments on resolved tickets should expire on a defined schedule and purge automatically, and the default should be measured in weeks. Where reproduction of a fault genuinely needs client data, the workflow should point staff at a controlled location rather than the ticket body, and the platform should be able to prove the difference.

Finally, read the vendor contract against this scenario specifically. Confirm that the defined scope of protected data covers ticket bodies and attachments and not only the vendor's core records. Confirm the notification obligation is expressed in hours from vendor awareness. Confirm you are entitled to the forensic detail, including the access vector, that you will need to answer your own regulator.

Frequently asked questions

Has EY said which vendor was breached?

No. EY has not named the third-party ITSM provider, has not disclosed the initial access vector, and has not given a victim count. It remains unclear how many clients were affected.

Is there evidence the stolen tax documents have been used?

EY states that it is not aware of any misuse or further exposure of the personal information involved. No ransomware group has claimed responsibility. EY is offering 24 months of identity monitoring and restoration services through Experian.

Why does this affect a client's own GDPR position?

Because the 72-hour notification duty runs from the controller's awareness. EY detected anomalous activity on 23 April 2026 and client letters are dated 13 July 2026, so an affected controller's clock started months after the access window closed, with no independent facts of its own.

The firms that come out of this well will not be the ones with the best tax platform security. They will be the ones who accepted that a help desk queue is a data store, mapped it, put a purge on it, and wrote a vendor clause that measures notification in hours.

Ernst & YoungITSMThird-party riskGDPRData breach

Progress tells ShareFile users to pull the plug

Progress Software told ShareFile customers to physically shut down on-prem Storage Zone Controllers over a credible threat. No patch, no CVE. What owners should learn.

3 min read

Capital

16,000 Firms Pooled Their Supplier Risk. You Didn't

Risk Ledger raised 24 million pounds in Series B on 15 July 2026 for a network-first supplier-risk platform used by 16,000 organisations. Why NIS2 and DORA make the questionnaire model your problem, and what European owners should change.

4 min read

Law & Regulation

The EA Buyout Now Hinges on Brussels

The largest take-private in history has cleared EA shareholders and US antitrust. The last real gate is the EU - and not classic merger review, but the Foreign Subsidies Regulation, facing its first blockbuster test.