Key Takeaways
- Between 28 March and 12 April 2026, an attacker downloaded client documents from a third-party IT help desk platform used by EY staff. Support tickets there may have included attached client tax files.
- EY detected it 11 days after the last access. Regulators were notified about twelve weeks after detection, a class action followed within days, and client letters landed in late September.
- Tax data is harder to recover from than most breaches. A tax identifier stays with a person for life, and the IRS took about 20 months on average to resolve an identity-theft case in 2025. EY’s monitoring offer lasts 24 months.
- Goldman Sachs asked EY for “objective evidence and third-party checks” that remediation worked. A supplier’s assurance is no longer enough; clients want proof.
- Vetting the vendor wouldn’t have changed much. If an attacker gets in by any route, they find the same readable tax returns. What mattered was what had piled up inside the tool, and whether it was readable.
- The real failure happened upstream, when regulated data left the system built to protect it. The fix is to know your data, eliminate what isn’t needed, control access in production, and automate compliance, so you can prove it when asked.
It probably started the way these things usually do. A tax file wouldn’t open. A client upload kept failing. Someone raised a ticket with IT and, to save a round of back-and-forth, attached the actual document. The problem got fixed. The ticket got closed. The attachment stayed.
Nobody would call a help desk a data store. But that’s roughly where this year’s EY incident landed. EY’s breach notice to the California Attorney General says support tickets on the affected platform “may include documents containing client tax information.”
This is the story of what happened next, what it’s costing, and what it says about every large organisation that handles other people’s data.
How the EY Breach Unfolded
Between 28 March and 12 April 2026, an unauthorised party had access to a third-party IT service management platform used by EY staff supporting client tax work, and downloaded documents relating to a number of EY clients. EY spotted the anomalous activity on 23 April, eleven days after the last known access.
Then the clock slowed down. Notices went to regulators in California, Texas, Massachusetts and Vermont in mid-July, according to The Economic Times, roughly twelve weeks after detection. Within days, a proposed class action was filed in federal court in New York. By late September, letters were reaching affected clients, including customers of Goldman Sachs’ wealth management business and the hedge fund Man Group, as Bloomberg reported. The Financial Times also named real estate firm Tishman Speyer among EY’s affected clients.
What Makes a Tax Data Breach Harder to Recover From
A password can be reset. A card can be cancelled and reissued in a week. A tax identifier stays with a person for life.
According to SecurityWeek’s reporting on the notices, the exposed information may include names, addresses, Social Security numbers, account numbers, credit and debit card numbers, and other details used to prepare tax filings. That is close to a complete kit for tax-related identity fraud: filing a false return, claiming someone else’s refund, or opening accounts in their name.
Fixing that isn’t quick. In 2025 the IRS was taking an average of about 20 months to resolve an identity-theft case, delays the National Taxpayer Advocate has called “unconscionable.” EY has offered affected people 24 months of identity monitoring through Experian. The monitoring has an end date. The exposure doesn’t.
And these weren’t random people. The clients named in coverage include some of the most sophisticated financial institutions in the world, and the people behind them are wealthy individuals whose tax files show exactly what they own and where. For a fraudster, that’s not just identity data. It’s a target list, and the raw material for very convincing phishing.
The class action complaint estimates the number of affected US individuals in the tens or hundreds of thousands. That’s the plaintiffs’ estimate, not a confirmed figure, but it gives a sense of the scale being argued.
The Damage That Doesn’t Fit in a Notice Letter
Goldman Sachs said its own systems weren’t affected and that client assets “remain safe.” But according to City AM, its technology risk team went further: it asked EY for “objective evidence and third-party checks” that the remediation had actually worked.
That request is the most important detail in the whole story. One of the most demanding buyers of professional services in the world is saying that a supplier’s assurance is no longer enough. It wants proof.
It isn’t only Goldman. The Economic Times reported that clients across the Big Four are now pushing for tighter controls, and quoted Gartner analyst Apeksha Kaushik:
“The practical priority is to create a consistent, measurable security baseline across all member firms and critical providers.”
Then there’s the lawsuit. The complaint argues that EY is “a sophisticated organization with the resources to deploy robust cybersecurity protocols” and “knew, or should have known” that stronger measures were needed. Whatever the outcome, litigation changes the question. What was sitting in that system, and in what form? stops being a security question and becomes a matter of evidence.
And this has happened before. In 2023, the MOVEit file-transfer attacks hit EY too, and led to alerts for 30,210 Bank of America clients. Different software, same shape: sensitive client data sitting in a tool that was built for something else.
Why Vetting the Vendor Alone Wouldn’t Have Changed Much
Most of the commentary has landed on third-party risk, and the instinct is understandable. Verizon’s 2025 Data Breach Investigations Report found third-party involvement in breaches had doubled, to 30%.
But run the counterfactual. Give the platform provider a perfect questionnaire score, a clean SOC 2 report and a fresh pen test. If an attacker still gets in, by any route, they find the same tickets with the same readable tax returns attached.
Vendor assessment tells you whether a supplier’s system can be trusted. It tells you almost nothing about what of yours has piled up inside it, or whether it’s readable. That second question decided how bad this was.
Darktrace’s Nathaniel Jones put the detection side of it well: “document theft often looks like normal business activity.” His point was that organisations “have spent years securing access to applications,” and the harder problem now is the data inside them.
The Real Failure Happened Upstream
The control that matters most didn’t fail at the supplier. It failed earlier, at the moment regulated data left the system built to protect it and settled somewhere nobody counts as a data store.
That happens constantly, through completely ordinary work. A ticket attachment. A one-off export saved to a shared drive. A production clone handed to developers. A full file sent to a supplier when a masked one would have done. A download that never leaves someone’s laptop. Nobody makes a bad decision. The data just accumulates.
How to Close the Gap: Mage Data’s Data Privacy Framework
We use the same four-part framework with every customer, whatever regulation they’re working to. It applies whether or not you ever buy a tool, and it runs in this order.
1. Know your data, across your entire landscape
Find every asset and every place sensitive data sits, then classify and catalog it. Your inventory says tax records live in the tax system. Start with what it leaves out: ticketing exports, shared drives, file servers, project folders, non-production databases and endpoints. Look inside the files. A PDF called scan_001 can hold a full tax return.
2. Eliminate unnecessary data, across your entire landscape
Non-production databases, test copies and files sent for troubleshooting shouldn’t hold real values. Neither should users or servers that don’t need them. Set retention rules for each data type and system, and purge on schedule. Data you’ve deleted can’t leak.
3. Control access in production
Some systems need real data. That doesn’t mean everyone who can query them should see it. Decide per user and per context whether to block, redact, mask or monitor, so a support engineer gets what they need to fix the problem and nothing more.
4. Automate privacy compliance in production
Retention, purge and compliance controls should run continuously, not as a yearly project. That’s also how you answer the Goldman question: with records that show where sensitive data sits, what was masked or removed, and when.
Discover all Assets 
Discover Sensitive Data 
Classify & Catalog .svg){kind=icon}
Consumers (human & AI) 
Non-Production Databases 
Non-Privileged User Access 
Non-Privileged Servers 
Data Retention & Purge 
Block 
Redact 
Mask 
Monitor 
Consent Management 
DSR Fulfilment 
Automated Posture Management 
Automated Retention & Purge 
Continuous Compliance Controls Mage Data: Data protection that truly follows the data
We should be clear about the limit first. No tool you run can protect data once it’s inside a system you don’t control. Mage Data couldn’t have reached into a supplier’s help desk. What it can do is change what gets there, and in what form, before it arrives. That’s what we mean by data protection that truly follows the data.
Now replay the story as a typical production support ticket. Something breaks in a live system. To show the problem, someone attaches a file containing real customer data. An engineer pulls the application logs and attaches those too. Both end up on a third-party ticketing platform, outside your control.
With Mage Data, neither carries real customer data.
Before a file goes onto a ticket, it can be masked in a few clicks. Context-preserving masking keeps the format and layout intact, so the problem can still be reproduced, but the tax ID and account numbers are replaced with realistic, fake values. Where the original values may be needed later, reversible tokenization lets authorised users restore them.
Logs are protected automatically, at the point your application writes them. Mage Data’s log data protection replaces only the sensitive fields with reversible tokens, so the logs stay readable and production support can still use them to troubleshoot. Whatever reaches your SIEM or log platform, and whatever someone later downloads from there and attaches to a ticket, is already protected. Only authorised people can reverse the tokens.
The result is that your customers’ sensitive data doesn’t leave your environment for a vendor’s ticketing platform. Discovery finds the folders and laptops where these files tend to pile up, old exports are purged on schedule, and when a customer like Goldman asks for evidence, you send a report.
The attacker might still get in. What they find is different.
Mage Data
Here’s how each part of the framework maps to what Mage Data does:
| Framework step | What Mage Data does | What changes in the ticket story |
|---|---|---|
| Know your data | Asset discovery and sensitive data discovery across databases, file servers and endpoints, using patterns, dictionaries, data matching, NLP for free text and AI models for PDFs and scans. Results are classified and catalogued centrally, and can be written as file tags that your DLP tools enforce on | The folders and laptops where tax returns pile up before they reach a ticket get found and flagged, with counts |
| Eliminate unnecessary data | Static data masking, masking in transit, a Secure File Gateway that masks files as they land, subsetting for test data, and data retention and purge | The copy that goes to support, test or a supplier carries XXX-XX-6789. The 2024 export nobody needs is gone |
| Control access | Dynamic data masking by role, user, location and time, a database firewall to block, and activity monitoring | A support engineer looking at the live record sees a masked tax ID and email |
| Automate privacy compliance | Automated retention and purge, continuous compliance controls, and a central record of what was found and how it’s protected | When a client asks for proof, you send a report the same week |
None of this means rebuilding how your teams work. Masking and delivery fit the processes you already have, whether that’s a nightly clone, a file drop or a self-service request.
What This Means for Your Team
If you run security, privacy or compliance at a bank, an insurer, a hospital group or a professional services firm, some of this will feel familiar. Client questionnaires get longer every year. Auditors want evidence, not policies. And somewhere at the back of your mind is a list of places you suspect hold real customer data that shouldn’t: the test environment someone refreshed from production last quarter, the shared drive a project team never cleaned up, the ticketing tool nobody thinks of as a data store.
None of that means your team is careless. It’s what happens when a lot of people do their jobs quickly with the tools they have. What’s changed after EY is that clients have started asking about it directly. Goldman asked its supplier for proof. Your clients and your regulators can ask you the same thing, and “we have a policy for that” won’t be enough of an answer.
The useful first step is an honest picture of where you stand. Which systems hold sensitive data you didn’t plan for? What’s readable that shouldn’t be? And if someone asked tomorrow, what could you actually prove?
Talk to a Mage Data specialist
Tell us how your environment is set up and what your clients and regulators are asking for. We’ll give you a straight view of where your data security stands, where the gaps are likely to be, and what we’d tackle first. It’s a conversation, not a sales demo.
Sources Referenced
- Ernst & Young LLP, breach notification filed with the California Attorney General, July 2026 — oag.ca.gov
- BleepingComputer, Ernst & Young discloses data breach after support system hack, July 2026 — bleepingcomputer.com
- SecurityWeek, Ernst & Young Data Breach Affects Personal, Financial Information, July 2026 — securityweek.com
- CFO Dive, EY faces proposed class action over data breach, July 2026 — cfodive.com
- Journal of Accountancy, Identity theft victims waited 20 months for IRS case resolution, September 2026 — journalofaccountancy.com
- City AM, Goldman-linked EY breach highlights new era of undetectable data theft, October 2026 — cityam.com
- Bloomberg via Claims Journal, coverage of Goldman Sachs data exposed in the EY hack, October 2026 — claimsjournal.com
- IBM, Cost of a Data Breach Report 2025, US average cost of $10.22 million, via CyberScoop — cyberscoop.com
- Verizon, 2025 Data Breach Investigations Report — verizon.com
- teiss, Ernst & Young says MOVEit Transfer hack impacted over 30,000 Bank of America customers, 2023 — teiss.co.uk
- The Economic Times via CA Alley, EY data breach puts spotlight on data security at Big Four as clients demand tighter controls, October 2026 — caalley.com
- Silicon UK, Goldman Sachs Client Data Affected By EY Hack, citing the Financial Times, October 2026 — silicon.co.uk