Ernst & Young LLP is notifying clients that an unauthorized third party breached a third-party IT service management platform used by EY staff supporting client tax services, and downloaded documents from it.

The timeline, as disclosed:

  • 28 March – 12 April 2026: unauthorized access to the third-party ITSM platform; multiple documents downloaded.
  • 23 April 2026: EY detects anomalous activity on its networks and launches an investigation.
  • 15 July 2026: EY files breach notifications with the California Attorney General’s office.

The exposed data includes names, addresses, Social Security numbers, credit and debit card numbers, and other information. Support tickets submitted through the platform may include documents containing client tax information. EY secured its systems, notified federal law enforcement, states that the unauthorized access has been removed, and is offering affected clients 24 months of identity monitoring and restoration services through Experian. EY says it is not aware of any misuse or further exposure of the stolen files. Plaintiffs’ firms announced class action investigations within days of the disclosure.

Three things about this incident deserve close attention, and none of them is the intrusion itself.

The real data classification of a ticketing system is set by users, not architects

A support ticket platform is procured as an operational tool. Its data classification, in most organisations, is assigned on that basis: internal, moderate sensitivity, IT-owned.

That classification is almost always wrong, and the mechanism by which it becomes wrong is entirely predictable. A tax professional encounters a problem with a client deliverable. They open a ticket. To make the problem reproducible, they attach the file. The file is a client tax return. The ticket now contains a Social Security number, an address, and possibly a payment instrument.

Nothing in this sequence involves negligence in any conventional sense. The professional is doing their job efficiently. The IT support model requires users to provide enough context to reproduce issues. The system is functioning as designed.

The result is that the actual sensitivity of a ticketing platform is determined by the highest-sensitivity artefact any user has ever attached to it, accumulated over the retention period. In a Big Four tax practice, that ceiling is very high, and the retention period is typically measured in years.

The same dynamic appeared this month in the ServiceNow CVE-2026-6875 exploitation, where the platform’s blast radius extends far beyond what its nominal classification suggests. It is a category of risk, not a one-off.

The controls that address it:

  • Attachment scanning with DLP at ingest, blocking or quarantining files containing SSN, TIN, or PAN patterns before they are stored in the ticket.
  • Aggressive attachment retention, decoupled from ticket retention. Ticket metadata may need to persist for years. The attached tax return does not.
  • A structured secure-upload path for cases genuinely requiring sensitive artefacts, with encryption, access logging, and a short expiry — and a support process that routes users to it rather than relying on them to remember it exists.
  • Classification set by observed content, not intended use. Sample the platform. Whatever you find is your classification.

Eighty-four days from detection to notification

EY detected anomalous activity on 23 April and filed with the California Attorney General on 15 July. That is 84 days.

Whether that interval is defensible depends on a distinction that matters enormously and is frequently elided: the difference between discovering an intrusion and determining whose data was in the files that were taken.

Detecting anomalous network activity on 23 April tells you something happened. It does not tell you which of several thousand support tickets were downloaded, which of those contained attachments, which attachments contained personal information, whose personal information it was, or which state’s notification statute applies to each individual. In a professional services firm, that determination requires reconstructing the contents of downloaded documents and mapping them to identifiable persons across a client base — a document review exercise, not a forensic one.

State statutes accommodate this to varying degrees:

  • California Civil Code § 1798.82 requires notification “in the most expedient time possible and without unreasonable delay,” with allowance for the legitimate needs of law enforcement and for measures necessary to determine the scope of the breach and restore integrity. There is no fixed day count for most entities.
  • Several states impose hard deadlines — 30 days in Colorado and Florida, 45 days in a number of others, 60 days in another group — generally running from discovery or determination that a breach occurred, and the choice of trigger word carries real weight.
  • Multistate exposure means the shortest applicable clock governs the programme, not the average.

An 84-day interval will be examined in litigation. The defensibility of it rests entirely on contemporaneous documentation: when the scope determination began, what it consisted of, what the volume of documents was, and what specifically prevented earlier identification of affected individuals. Firms that can produce that record generally prevail on the timeliness question. Firms that cannot are left arguing from the conclusion.

The operational lesson: start the identification workstream on day one, in parallel with containment, and document its progress weekly. The single most common cause of an indefensible notification gap is that scope determination did not begin until containment was declared complete.

Tax data carries obligations most breach playbooks omit

Client tax information is not simply a category of personal data. In the United States it is subject to a specific confidentiality regime that most generic incident response plans do not reference.

IRC § 7216 makes it a criminal offence for a tax return preparer to knowingly or recklessly disclose or use tax return information other than as permitted. It governs disclosure by the preparer, so an external intrusion is not itself a § 7216 violation — but the statute’s existence establishes the standard of care applied to this data category, and it constrains how a firm may share the information during its own investigation, including with forensic vendors, without appropriate consents or an applicable exception.

IRC § 6713 imposes civil penalties for the same conduct.

The FTC Safeguards Rule (16 CFR Part 314) applies to tax preparers as financial institutions. This is the point most frequently missed. The Rule requires a written information security programme, a qualified individual accountable for it, written risk assessments, access controls, encryption of customer information in transit and at rest, oversight of service providers including contractual security requirements and periodic assessment, an incident response plan, and — since the 2023 amendment — notification to the FTC within 30 days of discovery of a security event involving the unencrypted information of 500 or more consumers.

That 30-day FTC notification obligation runs from discovery of the event, not from completion of the scope determination. It is a different trigger and a much shorter clock than the state statutes, and it is the obligation most likely to be missed by a firm whose playbook is built around state notification law.

IRS Publication 4557 and Publication 5708 set out the Service’s expectations for tax professionals’ data security plans, and the IRS asks tax professionals to report data theft to their local Stakeholder Liaison so that the Service can institute account protections for affected taxpayers — a step that protects clients from fraudulent return filing and has no analogue in general breach response.

Any firm handling tax data should confirm that its incident response plan names these obligations explicitly. Most do not.

The third-party dimension

The compromised platform was a third-party IT service management system. EY’s own network detection caught the anomalous activity, which is to its credit, but the data was taken from a vendor environment.

This is the same structural pattern as the Lidl processor breach and the Pinnacle Financial exposure through its accounting firm — both disclosed within the same fortnight. The organisation’s own perimeter held. The data left through a supplier.

For professional services firms specifically, there is an aggravating factor: the data is not yours. A retailer breached through a vendor exposes its own customers. An audit and tax firm breached through a vendor exposes its clients’ clients — individuals who have no relationship with the firm, did not choose its vendors, and in many cases did not know the firm held their information.

That changes the analysis in three ways. Contractually, client engagement letters routinely contain confidentiality provisions, subcontractor consent requirements, and security standards that a downstream vendor breach may violate independently of any statute. Reputationally, the harmed parties are the clients whose trust is the firm’s entire product. Practically, notification must be coordinated with clients who have their own regulatory obligations and their own communications preferences — which is itself a source of delay that should be planned for rather than discovered.

The vendor governance actions that follow:

  • Maintain a register of which third-party platforms may receive client-confidential material, and enforce it technically rather than by policy statement.
  • Require contractual breach notification from vendors in hours, not “without undue delay.”
  • Ensure vendor contracts permit disclosure of the vendor’s identity in your breach notifications. Firms are sometimes contractually constrained from naming the provider, which reads externally as evasion.
  • Reconcile vendor security commitments against client engagement letter commitments. Where the vendor’s floor is lower than what you promised the client, you have an unfunded obligation.

Conclusion

EY’s response after detection appears methodical: containment, law enforcement notification, external assistance, 24 months of monitoring. The exposure was created earlier, by three decisions that were never experienced as security decisions.

Client tax documents were permitted to accumulate as attachments in an IT support platform. That platform was operated by a third party. And the scope-determination work that governs notification timing had to begin from scratch after the intrusion was found.

Each of those is correctable in advance, at modest cost, by any firm that handles regulated client data. None of them is correctable in April, after the files have already left.

This article is provided for informational purposes only and does not constitute legal advice.