the tax files were in the tickets

The detail that stays with me in the EY reporting is where the documents were. Client tax files were attached to support tickets. A process meant to help people do their work had created another place to keep their clients' data.

According to the reported notices, an unauthorized party accessed EY's third-party IT service-management platform between 28 March and 12 April 2026 and downloaded documents. EY noticed unusual activity on 23 April. Some of the material attached to tickets included names, addresses, tax identifiers and financial details. Later reporting connected affected people to Goldman Sachs and Man Group, both of which said their own systems were untouched.

That last point is quite plausible alongside a serious exposure. Client information can leave through a copy held elsewhere. Once somebody attaches a tax file to a support ticket, the support platform's permissions and retention settings become relevant to that file too. So do the accounts allowed to search tickets, export records, administer the platform or restore its backups.

I can understand how the file gets there. Someone needs help, the ticket has an attachment field, and uploading the document is a quick way to show the problem. Understanding that choice doesn't make it a good default. The person resolving the ticket may need an error message or transaction ID; the full document can contain far more information than the support problem requires.

That is where I'd begin a review of the workflow. Establish whether a redacted excerpt would have been enough. Where the original really is needed, consider a controlled link back to it. Every full-file attachment creates another copy to protect and eventually delete, and potentially another set of users and integrations that can reach it. The extra work isn't obvious to the person clicking “attach.”

following the attachments

A ticketing system is usually organized around records such as subject, description, assignee and status. Attach a tax document and it may now hold information about people who have never used the platform. The file might be copied into a vendor object store, indexed, exported or retained after the ticket closes. Those are possibilities to investigate, not a description of EY's architecture. The public reporting doesn't provide enough detail to make that claim.

Working out who could access the files means including service accounts and integrations as well as human users. Some identities may be restricted to one client. Others may search or export across clients. Accounts that can change audit or retention settings deserve attention because they may also be able to affect the evidence you need for the investigation.

A successful login is only the start of that reconstruction. The useful timeline connects the credential to a ticket, attachment or export, through a particular API, at a particular time. Identity-provider events, ticket reads, attachment downloads, export jobs, API-token activity and object-store logs all contribute different parts of it.

I'd expect actor, client, ticket and attachment IDs to connect those records, with request IDs and UTC timestamps to help reconcile them. Source IP and user agent add context. If the identifiers don't line up, the application may show normal ticket browsing while the storage layer records downloads under another identity. You then have to establish the relationship before you can say much about what was accessed.

Signed object URLs are one example of the difficulty. The application can record who requested a link, while storage records a later fetch with a different identifier. A missing download event in the application log isn't strong evidence that the file stayed put until you understand that alternate path and the logs that cover it.

Build a manifest of attachments the compromised identity could reach during the reported window, including versions and deleted files still held under retention. Compare that with downloads you can actually observe. Keep the distinction between reachable and observed clearly documented. Logging gaps shouldn't be quietly converted into certainty about what wasn't downloaded.

changing what support is allowed to keep

Ordinary support tickets shouldn't become the default storage location for tax documents. A separate evidence workflow could ask for the client's classification, the reason the file is required and an expiry before accepting the upload. Where an attachment is unavoidable, file-type and size limits, malware scanning, sensitive-data checks, client isolation and retention controls each address part of the problem. Exceptions need an owner and an expiry too; an indefinite exception tends to become the routine workflow.

The permissions need checking again when the file is fetched. Access to a ticket title doesn't necessarily authorize a download of the tax records behind it. Each download endpoint should verify the caller against the attachment's client and classification. A signed URL should follow that decision, stay short-lived and permit only the required object and operation. It shouldn't provide a broader route around the check.

Bulk export warrants its own permission and alerting. Opening one attachment to work on a ticket is different from downloading hundreds across clients. Look at volume relative to that account's normal work, the number of distinct clients, file types and unusual times or locations. A fixed threshold of 100 downloads can be evaded at 99 and can still be noisy for an account that performs legitimate exports. The surrounding activity is needed to interpret the count.

None of this establishes how the attacker initially got in. Reporting mentions an earlier attribution to a software vulnerability, without identifying a CVE, affected version or detailed exploit method. I wouldn't invent a sequence to fill that gap. The reported data flow is enough to justify examining how much sensitive material a secondary operational system held and who could retrieve it.

Patching the entry point, if a vulnerable component was involved, would leave those workflow questions open. So would disabling one compromised account. The copies could still be available to another stolen credential or an integration with excessive access.

For a follow-up, I'd want the ticket inventory tied to a decision about each kind of attachment: why support needed it, who could access it, and when it should have been removed. Then I'd want to see the upload and download rules that enforce those decisions. A retention policy in a document isn't much help if closing a ticket leaves its tax files available indefinitely.

mock draft and technical analysis. incident facts are drawn from the october reporting ↗ and the man group notice ↗. the proposed controls are my analysis; i was not involved in the incident.