Telus and the 700 TB theft: what the ShinyHunters attack changes for companies
The ShinyHunters group claims 700 TB stolen from Telus in March 2026. Understand what the incident means for organizations that depend on telecom and identity providers.

In March 2026, Telus, one of Canada’s largest telecommunications operators with more than 17 million subscribers, confirmed a security incident of significant proportions. The group ShinyHunters, already responsible for attacks on Ticketmaster, Santander and Snowflake in 2024, claims to have exfiltrated at least 700 terabytes of data, including personally identifiable information (PII), call records, background check results and, most seriously, source code from internal systems. This is not a leak of reused passwords. It is the operational map of a critical infrastructure.
For those who work in risk management in Brazil, geographic distance offers no real comfort.
What ShinyHunters stole, and why it matters
ShinyHunters is not a group of script kiddies. Since 2020, the collective, partially identified by the FBI and Europol, has operated with discipline and clear commercial objectives: exfiltrate data in volume, publish it on forums such as BreachForums and monetize what remains through private negotiations.
In Telus’s case, the combination of data is particularly dangerous:
- PII and communications data: name, address, call history. Enough for highly targeted social engineering.
- Background checks: information companies collect about employees and partners. In the wrong hands, an asset for corporate extortion or competitive espionage.
- Source code: perhaps the most persistently damaging element. With it, adversaries can map specific vulnerabilities in the operator’s infrastructure for years, even after the incident is closed.
Telus has not yet publicly confirmed the exact volume or all types of compromised data, which by itself is a warning sign about crisis communication maturity. But ShinyHunters’ claim, combined with partial sample posts on forums, gives enough credibility to the scope described.
The vector nobody wants to admit, the supplier chain
The most important question is not "how Telus was breached", but "what is your level of dependence on suppliers that share Telus’s risk profile".
Telecom operators and digital identity providers, companies that manage authentication, background checks and corporate communications data, are high-value targets precisely because they aggregate sensitive data from hundreds or thousands of corporate customers into a single point. When one of these suppliers falls, exposure propagates in cascade across their customer base.
In Brazil, this risk is amplified by a market for outsourced identity and communications infrastructure that has grown significantly over the past three years, driven by Open Finance, digital KYC and employee verification platforms. Many mid-market companies today rely on two or three suppliers to manage data that, under the LGPD, remain their responsibility, regardless of where they are stored.
The illusion of shared responsibility
The argument "but the supplier handles that" does not withstand a notification from the ANPD. Article 42 of the LGPD is clear, the controller is liable for damages resulting from data processing, including those carried out by operators. This means that if your background-check provider or your corporate communications operator suffers an incident like Telus’s, you are the one responsible toward the data subject.
What to do in practice, three nonnegotiable measures
The Telus incident is not a reason to panic. It is a concrete argument to prioritize initiatives many companies have had in backlog for months.
1. Classify your suppliers by systemic risk profile
It is not enough to have a list of critical suppliers. You must specifically categorize those that aggregate sensitive data from multiple customers , operators, identity providers, background-check platforms, managed SIEMs. For these, the level of due diligence should be equivalent to that applied to an internal partner. This includes requiring evidence of annual penetration tests, SOC 2 Type II reports and incident response plans with notification SLAs.
2. Implement logging and access alerts for third-party data
If a supplier has access to your data, or you access theirs, audit logs are being generated. The question is whether anyone is watching them. Correlate unusual access events (off-normal volume, atypical hours, unexpected geolocation) with alerts in your SIEM. ShinyHunters’ behavior in past attacks involves gradual exfiltration over weeks, detectable with adequate telemetry.
3. Update your incident response playbook to include suppliers
Most of the playbooks I audit assume the scenario "our system was compromised". Few cover "our supplier was compromised and we are waiting for their formal notification while the data is already circulating on BreachForums". That scenario needs a specific protocol: who contacts the supplier, what the tolerated response time is, when the company notifies affected data subjects independently.
The recurring pattern
What the Telus case confirms, once again, is that telecommunications and identity infrastructure is a recurring, high-priority target for organized groups. ShinyHunters has demonstrated, consistently over three years, that it knows where the highest-value data are and how to extract them before security teams respond.
For Brazilian companies, the message is direct, your supplier’s risk is your risk. Treat it as such, with proportional controls, contracts and monitoring; it has ceased to be best practice and become a regulatory requirement and a reputational imperative.
700 terabytes is a large enough number that no one can pretend they did not see it.


