TCS had a perfect security score. Then M&S and JLR were breached.

We collected 201 public signals from employee reviews and social media describing organizational strain at TCS in the year before both breaches.

Case 1: TCS and the 2025 UK Cyber Breaches

This is the first post in a series where we investigate major breaches from the last 3 years through alternative data: social media, employee reviews, workforce signals. We’re looking at what was publicly visible before each breach, what it meant, and what it might mean for how we assess cyber risk.

The series covers TCS and the 2025 UK breaches (this post), CDK Global, Change Healthcare, and Clorox. In the final post, we’ll discuss the patterns we found across all four cases. We’re building this in public. We welcome corrections, pushback, questions, and we’re using feedback on each post to shape the next one.

Back to the roots

Tata Consultancy Services (TCS) runs IT infrastructure for some of the largest organizations in the UK. It’s a $30B company deeply embedded in the systems its clients depend on. When a third-party provider sits that deep in your stack, its operational health isn’t just its own problem.

In 2025, we saw this in action. Marks & Spencer (M&S) was breached in April; Jaguar Land Rover (JLR) followed months later. M&S estimated its profit impact at £300 million; the Cyber Monitoring Centre put JLR’s cost to the UK economy at £1.9 billion.

The breach mechanics have been well documented. We wanted to look at something different: what was visible before them.

If TCS was a weak link, you’d expect the existing risk ratings to reflect it. TCS maintained an A grade (90+) on SecurityScorecard throughout all of 2025. Its Social Engineering¹ score was 100 out of 100 for the entire period. That score measures exposure: how targetable an organization’s people are through social networks and public data breaches.

Source: SecurityScorecard (max availability we could check is the last 12 months)

But what happened at M&S and JLR wasn’t a targeting problem. Someone called the helpdesk, and the person on the other end reset the password. The failure was operational, and as far as we can tell, nothing in these ratings or any widely used rating framework is designed to capture that. The gap is that the thing that broke isn’t in scope for what anyone measures.

So we went looking for public signals that might reflect that side. Over a few months, we collected 201 signals from six public platforms. This post walks through what we found, the pattern we see, and the open questions we have.

TCS Connection

We want to be precise about what has been established before we get into our data. The strength of the TCS link varies between the two cases.

M&S (February & April 2025): TCS operated M&S’s IT helpdesk under a ~£1B contract since 2018.

• Attackers accessed M&S’s network as early as February 2025, exfiltrating the Active Directory database containing all domain password hashes.

• In April, attackers called the helpdesk, impersonated an M&S employee, and got staff to reset a password.

JLR (March & August 2025): JLR is part of the Tata Group through Tata Motors, and TCS managed IT and manufacturing systems at JLR.

• In March, the HELLCAT ransomware group breached JLR’s Jira environment using contractor credentials that had been compromised since 2021 and never rotated. That breach exposed employee names, roles, and internal systems architecture.

• Five months later, Scattered Lapsus$ Hunters used that information to social-engineer JLR helpdesk staff into resetting passwords.

Unlike M&S, we found no definitive public evidence that the helpdesk agents were TCS employees. The organizational entanglement is deep, but we can’t draw the same straight line as with M&S.

What we collected

Our dataset spans January 2024 to September 2025. We want to be transparent about what that timeline means because it’s not a clean before-and-after:

1. Pre-breach before April 2025.

2. Gray zone from April to July 2025. The M&S breach is public; JLR hasn’t happened yet. Signals here could be colored by coverage, but the substance is identical to what employees were saying a year earlier. We include this data but flag the ambiguity.

3. Post-breach for both after August 2025.

We organized our data around four categories of pre-breach signal. These categories emerged from the data:

1. Organizational Instability: mass attrition, skills mismatch, restructuring, leadership churn, workforce disruption.

2. Tech & Security Dysfunction: outdated technology, blocked development tools, and complaints from security-specific roles about tooling, staffing, and ignored recommendations.

3. Financial Distress: salary cuts, withheld variable pay, cost-driven deferrals.

4. Compliance Stress: fines, lawsuits, regulatory findings.

AmbitionBox is the largest source (48%) because TCS’s workforce is mostly India-based, and that’s where Indian IT employees leave reviews. Reddit (15%) gives us the client and practitioner side. The rest comes from Twitter/X, Glassdoor, and other platforms. Employee review platforms skew negative by design, so we’re looking for specific, recurring signals that point to operational issues over absolute sentiment.

What we found

The full dataset (201 signals, sources, dates, and our categorization) is available here.

A talent crisis that reached security roles

TCS’s standard fresher salary under its most common hiring track was ₹3.36 lakh/year (~£2,900). In June 2024, the company disclosed it was struggling to fill 80,000 open positions, with its global operations head citing a skills mismatch. A Twitter thread from July 2024 described the dynamic:

They really have a mid-level employee crisis. They have plenty of freshers and plenty of management guys with no technical expertise, but are struggling with the mid level technical guys who do the most work. Anyone who upskills will leave the company for better opportunities elsewhere.

The numbers behind this are in TCS’s own filings. With attrition running at 12-21% across 2022-2025 on a workforce of ~600,000, TCS was losing 70,000-130,000 employees per year. The response was to keep hiring freshers at scale. By January 2025, headcount had shrunk by over 5,000, with senior retirements accelerating and replacement hiring skewing toward the bottom. In May 2025, a 20+ year TCS veteran wrote on Indeed:

Talent leaving organization and freshers/sub-optimal talent is replacing them. Seems TCS is OK with this.

Multiple employees described TCS’s Resource Management Group operating on a skills-agnostic model. One wrote in May 2024:

If Team A requires one person, assign any free resource to that team, does not matter what skill set he/she has.

Clients were seeing the downstream effects. In September 2024, someone on r/sysadmin whose organization had moved its helpdesk to TCS wrote:

We spent 100+ hours of training to onboard them, then when we handed over the ticket queue was somewhere between triple/quadruple its normal average and stayed that way for at least 6 months. Their 1st line is just a call centre (non-technical).

In late December 2024, this reached cybersecurity directly. A TCS employee posted on AmbitionBox:

I am from auditing background and my profile is being pitched to clients as Cyber security analyst (which is something I have never done in my life). So far I have not been given access to MS Office or even MS Teams to communicate or reach out to anyone.

We can’t say that hiring model caused the breach. But a system that places unqualified staff into security-adjacent roles, at scale, creates the conditions for exploits.

Security employees were describing dysfunction months before the breach

Between April and October 2024, eight employees in TCS’s security-related departments posted reviews on AmbitionBox from eight different cities across India. All described some combination of poor management, low compensation, or operational dysfunction.

The most operationally specific came from a SOC Analyst 2 in New Delhi:

Low salary. Management issues. Slow incident response.

In January 2025, a Team Manager in TCS’s IT Security department in Bhubaneswar flagged “Organization restructuring” and “Lack of contextual help”, suggesting that whatever strain existed was being compounded by internal reorganization.

Nine reviews from eight cities is a small sample. We can’t say whether this level of strain is unique to TCS or common across large IT outsourcers (see Limitations). But the point we want to make is narrower: you can isolate the security team’s voice from public review data and see what the people closest to detection and response are saying.

These are people with direct operational knowledge, speaking independently, on different platforms, describing the exact kind of dysfunction that the breaches later could have exploited.

The view from outside TCS matched. In June 2025, a red team operator posted on r/cybersecurity:

I run Red Teams and often deal with TCS and others (Big 4 included) and it’s a sh*t show. SOC’s sleeping on SIEM alerts, basic security practices being ignored, outright lies during audits.

A pattern of underinvestment

Outdated technology was the most common complaint in our dataset. It’s also a widespread grievance at large IT outsourcers, so on its own it doesn’t tell us much. However, when we look at it alongside the other signals, it becomes part of a broader pattern. These aren’t security findings, but they describe an organization cutting corners at a systemic level.

The talent economics describe underinvestment in people: ₹3.36L fresher salaries, sub-2% hikes, an unwillingness to pay market rates for mid-level talent.

The tech complaints describe underinvestment in tooling: legacy frameworks, blocked access to modern development platforms, old software versions. One employee in July 2025 wrote:

Google Colab, Github, Huggingface, ChatGPT, Grok, AI platforms are blocked here. We can’t install open source development software, leave the paid one.

Other employees also described underinvestment in their own internal systems:

Lastly, as an IT company they have horrible internal tech.

Variable pay was being cut. Multiple employees across 2024 described partial or withheld variable payouts, and the complaints continued into 2025. A May 2025 Indeed reviewer at TCS listed primary concerns as:

Regular cut of variable pay (since many quarters) [...] High expectations on margins with no intention to invest in innovation

The pattern extended to regulatory and legal exposure. In July 2024, a US court imposed a $194.2 million penalty on TCS for misappropriation of trade secrets. In February 2025, Bloomberg reported that former staffers alleged TCS had been gaming the US visa system: using L-1 visas reserved for managers to circumvent H-1B rules, with one ex-employee claiming he was ordered to falsify internal org charts.

This is where we’re making an assumption, and we want to name it explicitly. The signals in this post describe an organization that pays entry-level salaries, loses experienced staff, places people into roles regardless of skill match, and blocks access to modern tools. Our hypothesis is that those conditions don’t stop at the boundary of the security function. If the helpdesk is staffed the same way the rest of TCS is staffed — high volume, low experience, minimal investment in retention or training — then the people who are the last line of defense against social engineering are the same people most likely to be set up to fail.

Breach-specific accounts

The signals above describe organizational conditions. The accounts below describe the breaches themselves. We can’t verify any of them. We include them because of how specifically they map to the pre-breach patterns, not as standalone evidence.

In June 2025, someone describing themselves as an M&S employee published a post (later deleted; retrieved via the Wayback Machine):

In 3 of 4 calls, the service desk reset passwords and re-enrolled MFA with zero resistance. The caller simply gave a name – no validation, no callback, no check. On the 4th call, the attacker requested access to a privileged group. The TCS agent asked for an employee ID. The ID given didn’t even match our company’s format; and yet, the access was granted anyway. [...] This is a textbook case of supply chain failure. The attackers didn’t need to hack anything. TCS handed them the keys.

The post goes on to describe TCS stalling on providing additional call logs, eventually claiming the recordings were “either lost or deleted,” and notes that TCS was responsible for both access management and security monitoring, yet “completely missed the post-breach attacker activity.”

We can’t verify this account, but the specifics line up with what employees were describing months earlier. A SOC analyst wrote “slow incident response” in July 2024; this post says the SOC “completely missed the post-breach attacker activity.” An employee described being placed into a cybersecurity role with no experience in December 2024; this post describes helpdesk agents granting access without basic verification.

In reply to that post, someone else, writing with apparent insider knowledge of the impacted organization’s risk process, added:

This organisation received red team reports that highlighted these specific threats, as exploited, and it was brushed under the carpet and the risk ‘accepted’. I personally fought for weeks for it to be heard, and management up to the very top ignored it.

If both accounts are authentic, they describe two sides of the same failure: TCS’s operational weakness at the helpdesk, and the client organization’s decision to accept the risk despite internal warnings. The pre-breach signals we collected describe the conditions that made both possible.

By early 2025, TCS was showing public signs of strain across every dimension we measured: workforce, technology, security operations, financial investment, and regulatory compliance. None of these signals alone would be a finding. Together, they describe an organization where the breach didn’t require bad luck. It required normal operations.

Limitations

We looked at TCS because we already knew. We looked at TCS because we knew it was connected to the breaches. The real test is whether these signals would have differentiated TCS from Infosys, Wipro, or HCL before a breach. But even if these signals turn out to be industry-wide rather than TCS-specific, that’s not a reason to dismiss them. For us, it reframes the question: from “is this vendor uniquely distressed?” to “is the entire outsourced IT layer under more strain than anyone is measuring?”

This is correlation, not causation. We found signals of organizational distress before the breaches. We are not claiming that those signals caused or contributed to the breaches.

The timeline isn’t clean. We’ve addressed this throughout the post, but to restate: our strongest data is pre-April 2025. The gray zone (April–July) describes the same conditions as the preceding year, but we can’t fully rule out contamination from breach coverage.

Open questions

Is there a structural blind spot in how we assess cyber risk? We came into this industry from the outside, and the gap between what was publicly visible and what risk frameworks measure was the first thing we noticed. Kevin Beaumont, who ran the SOC at Co-op before it was outsourced to TCS, has argued that the incentive structure itself is the problem: organizations are rewarded for cutting costs through outsourcing, and insurance covers the downside when it goes wrong. Even if that explains why the gap exists, the signals we collected were public. If organizational strain at a critical vendor is visible a year before a breach, does that change the calculus — for insurers, for regulators, for the organizations themselves? Or does the system absorb that information too?

If the risks were known and documented, what failed? Two post-breach accounts describe risks that were known and formally documented. If that’s a common pattern, then the failure point isn’t that no one saw the risk. It’s the decision to hire the vendor despite known risks. Who owns that risk? Who should?

Signal versus noise. Employee dissatisfaction at a 600,000-person company is not inherently a finding. The question we haven’t answered is what separates background noise from a meaningful signal. Is it specificity (a SOC analyst naming slow incident response versus a generic “bad management”)? Is it clustering? Is it the combination of internal and external voices saying the same thing?

What’s next

We’ve shown our data and our reasoning. If you’re closer to this world than we are, we’re curious what you see that we don’t.

The series is in progress. The next post isn’t locked. CDK Global is the obvious follow-up. The alternative is a control group for TCS. Tell us in the comments which is more useful to you.

1. The SecurityScorecard Social Engineering Module is used to determine the potential susceptibility of an organization to a targeted social engineering attack. The Social Engineering module ingests data from social networks and public data breaches and blends proprietary analysis methods. The Social Engineering Score is an informational indicator calculated based on the number of indicators that appear in SecurityScorecard collection sensors. Source: https://securityscorecard.com/blog/securityscorecard-10-risk-factors-explained/