A cyberattack affecting EY has exposed sensitive personal and financial information belonging to clients of some of the world’s best-known financial firms, including Goldman Sachs’ wealth management business, hedge fund Man Group and real estate developer Tishman Speyer.
The incident is notable because the attackers did not need to compromise Goldman Sachs, Man Group or Tishman Speyer directly.
They reached the information through EY.
And according to EY’s breach notifications, the information was sitting inside a third-party technology platform used to support EY’s tax work.
That chain is the more important privacy story.
Modern organizations can spend enormous amounts securing their own environments while sensitive information continues moving through accountants, law firms, cloud systems, ticketing platforms, consultants, SaaS providers and other vendors. Every additional recipient becomes another place where the data can potentially be exposed.
The EY incident is a particularly clear illustration of why privacy programs can no longer treat vendor management as a contracting exercise performed once during procurement.
The data follows the vendor.
So does the risk.
What happened at EY?
According to breach notifications filed with regulators, EY uses a third-party information technology service-management platform to support personnel performing tax-related work for clients.
Those support tickets could contain documents holding client tax information.
EY said it confirmed anomalous activity in the platform on April 23, 2026. Its investigation subsequently determined that an unauthorized third party accessed the environment between March 28 and April 12 and downloaded documents associated with a number of EY clients. EY brought in an independent cybersecurity firm, notified federal law enforcement and said the unauthorized access had been stopped.
The Financial Times reported that the incident stemmed from a vulnerability involving Checkmarx software and ultimately affected individuals associated with Goldman Sachs, Man Group, Tishman Speyer and other EY clients. The cybercriminal group ShinyHunters claimed responsibility for the attack.
Importantly, Goldman Sachs and Man Group both said their own systems were not compromised. Tishman Speyer’s notification similarly states that its internal systems were not affected.
That distinction does not make the privacy consequence disappear.
The information was still exposed.
What information was involved?
The specific data varied by affected individual and client, but reporting and regulatory notifications indicate that compromised information included combinations of:
- names;
- addresses;
- email addresses;
- tax identification information;
- financial information related to investment holdings.
The Financial Times reported that tax identifiers and financial information were among the compromised data. EY’s notice concerning Tishman Speyer investors states that bank-account numbers, income and net worth were not included in that particular affected dataset.
EY also began offering affected Man Group individuals 24 months of Experian identity-monitoring services.
For criminals, this is potentially much more useful than a compromised email address by itself.
A dataset combining identity information with investment relationships and tax identifiers can support identity theft, highly convincing phishing campaigns, tax fraud attempts and targeted social engineering.
The sensitivity comes from the combination.
The clients were breached without being breached
This is the part companies should study.
Goldman Sachs can accurately say its systems were not affected.
Man Group can accurately say its systems were not compromised.
Tishman Speyer can accurately say the same.
And yet information relating to their clients or investors was exposed.
Modern data processing increasingly looks like this:
Individual
↓
Financial institution
↓
Professional services firm
↓
IT platform
↓
Underlying software and infrastructureSecurity teams often focus primarily on the second box.
Privacy teams need to understand the entire chain.
From the individual’s perspective, it matters little whether an attacker stole a tax identifier directly from the financial institution or obtained exactly the same identifier from a service provider several layers downstream.
The data has still left the protected environment.
Professional services firms are enormous data aggregators
Accounting firms, law firms and consultants create a peculiar cybersecurity problem because organizations deliberately send them highly sensitive information.
An accounting firm may receive:
tax records
investment information
employee information
corporate financial records
identification numbers
transaction histories
ownership informationA law firm may possess litigation records, medical information, internal investigations and privileged communications.
A payroll processor can hold salary and banking information.
An insurer can receive detailed operational and security information from insured companies.
These organizations may not resemble consumer data brokers, but from an attacker’s perspective they can function as extraordinarily valuable data repositories.
Compromising one service provider can potentially provide access to information originating from many unrelated companies.
That changes the attack economics.
Instead of attacking 100 companies independently, an attacker looks for the intermediary trusted by all 100.
The ticketing-system problem deserves attention
Another important aspect of the EY incident is where the information reportedly resided.
It was not necessarily sitting inside the primary tax-processing application.
It could be attached to IT support tickets.
EY’s notification states that support tickets submitted through the affected platform may include documents containing client tax information.
This is a common enterprise privacy blind spot.
Sensitive information has a tendency to escape the system where everyone knows it exists.
An employee encounters a technical problem.
They open a support ticket.
They attach:
a screenshot
a spreadsheet
a tax document
a customer record
a database exportThe organization now has another copy of the information.
That copy may have:
- different retention rules;
- different administrators;
- different security controls;
- different subprocessors;
- broader internal access;
- a completely different deletion schedule.
The official data map may say:
Tax data is stored in System A.
Operational reality may be:
System A
+
email
+
Slack
+
ticketing platform
+
shared drive
+
temporary export
+
vendor support environmentThat gap between documented processing and actual processing is where many privacy failures start.
Data minimization should apply to support systems too
The obvious question arising from the EY incident is whether complete client documents needed to be present within the support environment.
That does not mean EY necessarily violated a legal requirement; the available public information does not establish that.
But it raises the right governance question:
How much production data should ever enter an IT support system?
Organizations should consider controls such as automatic redaction, tokenization, synthetic test data, restricted attachments and automated detection of sensitive information.
For example, if an employee attempts to upload a document containing:
Social Security number
taxpayer identification number
bank account number
passport numberthe system could:
detect
↓
warn
↓
block
↓
require justification
↓
apply restricted accessThat is data minimization implemented technically rather than written into a policy.
Vendor due diligence cannot stop at SOC 2
Organizations frequently perform vendor diligence by collecting documents.
The security team requests:
SOC 2 report
ISO 27001 certificate
penetration test
security questionnaire
data processing agreementThose documents matter.
But they do not answer the most important operational questions.
A meaningful vendor assessment should determine:
What information are we actually sending this vendor?
Then:
Where does the vendor put it?
Then:
Which of the vendor’s own providers can access it?
And finally:
How long does every participant keep it?
A company might approve EY after an extensive security review while never realizing that a particular client document could later appear inside a third-party support ticket.
That is why data-flow diligence needs to sit alongside vendor diligence.
Fourth-party risk is now ordinary risk
Companies often describe their immediate suppliers as third parties and those suppliers’ suppliers as fourth parties.
The terminology becomes less useful as cloud architecture becomes more complex.
What matters is the processing chain.
A controller may use Vendor A.
Vendor A relies on Platform B.
Platform B incorporates Technology C.
Data may also be backed up into Infrastructure D.
The consumer usually has no visibility into any of this.
Yet every layer can affect the security of the consumer’s information.
Privacy teams should therefore ask vendors to identify material subprocessors and understand which of them can actually receive customer information.
This is particularly important when the information involves:
financial records
government identifiers
health information
biometrics
credentials
children's data
precise locationIncident response also becomes a data-discovery problem
EY confirmed anomalous activity on April 23.
For Tishman Speyer-related information, EY notified Tishman Speyer on August 6 that investor data might have been affected and completed the identification process later that month. EY described the review as time-intensive because of the nature of the affected dataset.
That timeline illustrates another recurring breach problem.
Stopping an attacker and determining whose data was stolen are different tasks.
After containment, investigators may be left with thousands or millions of files.
Then begins a privacy exercise:
What files were accessed?
↓
What information was inside them?
↓
Whose information was it?
↓
Which jurisdictions apply?
↓
Which clients own the relationship?
↓
Who needs notification?Organizations with strong data inventories can perform that work much faster.
Organizations with poor data governance may spend months reconstructing what they stored.
Privacy inventories should include copies, not just systems
Traditional data mapping asks:
Which system contains personal data?
A stronger approach asks:
Everywhere can this information propagate?
For sensitive financial information, that might include:
production application
backup
analytics environment
email
ticketing system
collaboration tools
document repositories
external accountants
legal counsel
cloud providers
subprocessorsThis produces a much more realistic attack surface.
It also helps organizations impose different controls depending on sensitivity.
Not every system should be allowed to ingest every category of information.
Contracts still matter
Technical controls should come first, but contractual provisions matter once data leaves the organization.
Agreements with service providers should address issues such as:
- permitted processing purposes;
- security requirements;
- subprocessor disclosure;
- breach-notification timing;
- cooperation during forensic investigations;
- retention limits;
- deletion obligations;
- audit rights;
- restrictions on secondary use.
One particularly important issue is whether the vendor must notify the customer about an incident immediately after discovering a security event or only once it concludes that customer information was actually affected.
Those may be separated by weeks or months.
Companies should know what their contracts require before an incident occurs.
One breach can create three different risks
Incidents like this create overlapping problems.
The first is cybersecurity:
How did the attacker gain access?
The second is privacy:
What personal information was disclosed?
The third is governance:
Why was that information present in that system and who was responsible for protecting it?
Organizations sometimes spend all of their energy on the first question.
The second and third often determine regulatory and litigation exposure.
A technically sophisticated attacker exploiting a software vulnerability is a cybersecurity problem.
A complete tax document sitting unnecessarily inside a broadly accessible support environment is a data-governance problem.
Those require different remedies.
The lesson from EY is not “don’t use vendors”
No major company can operate without third parties.
Goldman Sachs is not going to perform every professional service internally because outside providers create cybersecurity risk.
The practical lesson is narrower:
Outsourcing a business function does not outsource the consequences of the data flow.
Organizations need to know:
what leaves
why it leaves
who receives it
where it goes next
how long it stays there
how it is protectedAnd they need a way to verify those answers.
The EY breach is especially useful because the primary clients’ own systems apparently remained intact.
That removes one of the usual distractions.
The privacy problem was downstream.
Sensitive information moved through a trusted professional-services relationship into another technology environment and was ultimately exposed there.
That is how modern breaches increasingly work.
A privacy program that protects only the organization’s own network is therefore protecting only part of the data.
The modern perimeter follows the information.