breach-autopsy

Breach Autopsy: Telus Digital's 1 Petabyte Problem

Hacker claims 1 petabyte stolen from Telus Digital. If true, that's 1000 terabytes. Here's what that scale of theft means for evidence and liability.

Breach Autopsy: Telus Digital's 1 Petabyte Problem

Telus Digital confirmed a breach. A threat actor claims they stole 1 petabyte of data.

1 petabyte = 1000 terabytes.

If you've never scoped an incident at that scale, here's what changes when the theft is measured in petabytes, not gigabytes.

The Timeline

March 2026: Threat actor surfaces claiming Telus Digital breach with 1 PB of stolen data.

Telus Digital confirms "a cybersecurity incident" affecting their systems. They're investigating the scope.

That's the public story. The autopsy starts with what 1 petabyte actually means.

What 1 Petabyte Looks Like

For reference:

1 petabyte = 1 million gigabytes
The entire Library of Congress (text) = ~10 terabytes
1 petabyte = 100 Libraries of Congress worth of text

Telus Digital provides customer service operations, digital transformation, and IT support for Fortune 500 companies. They handle customer data at scale.

1 petabyte of structured data (customer records, call logs, support tickets) could represent millions of individuals across dozens of enterprise clients.

If the theft claim is accurate, this isn't a breach. It's a mass exfiltration spanning months.

The Technical Autopsy

How do you move 1 petabyte?

You don't exfiltrate 1 PB in a weekend smash-and-grab. Even on a 10 Gbps connection (which most enterprise egress isn't), 1 PB takes 9+ days of sustained transfer at maximum throughput.

That means either:

Long dwell time (attacker had access for weeks/months)
Multiple exfiltration points (parallel transfers from different systems)
Compression/deduplication (actual exfil was smaller, inflated claim)
Insider access (physical media theft or privileged account abuse)

Option 1 is most likely. Multi-month dwell times are common in third-party provider breaches where monitoring is focused on customer-facing systems, not internal ops.

The Legal Autopsy

Third-party liability just got expensive.

Telus Digital is a service provider. They process data on behalf of their clients. Those clients have contractual data protection obligations.

When a processor gets breached at this scale, the legal dominos start falling:

Notification obligations trigger for every affected client
Regulatory reporting starts (GDPR 72-hour clock, CIRCIA if applicable)
Contract breach claims from clients who trusted Telus with their data
Class action exposure if consumer PII is involved

The evidence timeline matters here. When did Telus first detect the breach? When did they notify clients? How long was the attacker inside before detection?

GDPR and most US breach notification laws measure compliance from "becoming aware" of the breach. If Telus knew about suspicious activity but didn't classify it as a breach until the hacker went public, that's an evidence problem.

What Becomes Exhibit A

In the litigation that follows a breach this size, plaintiffs will focus on three artifacts:

Detection logs. When did monitoring first flag anomalous exfiltration? What alerts were dismissed?
The data inventory. Did Telus know what data they held and where? Can they prove which 1 PB was stolen vs. which PB is safe?
Vendor contracts. What security requirements did clients impose on Telus? Did Telus meet them?

If Telus can't definitively say which client data was compromised, every client has to assume worst-case. That makes damage calculations easy for plaintiffs and expensive for defendants.

The Evidence Trail You're Not Building

Most companies don't monitor egress at petabyte scale because they don't expect petabyte-scale theft.

But third-party processors handle aggregated client data. Their risk profile isn't "one client got breached." It's "every client's data is in one place."

That concentration risk requires concentration-grade monitoring:

Data Loss Prevention (DLP) with volume baselines. Flag when 10 GB/day suddenly becomes 100 GB/day
Egress traffic analysis. Not just IDS signatures, but volume and destination tracking
Privileged access monitoring. Who has admin access to bulk data stores? What are they accessing?

If you're a service provider and you can't answer "how much data left our network last month," you can't defend "we detected the breach promptly."

What to Do This Week

If you're a client of a third-party processor:

Review your vendor contracts. Do they commit to egress monitoring and anomaly detection? Can they prove it?
Ask for evidence of their data inventory practices. If they get breached, can they tell you which of your data was affected in 72 hours or less?
Map your notification obligations assuming your vendor gets fully compromised. Who do you notify? When? What's the legal clock?

If you're a service provider:

Baseline your normal data egress. You can't detect abnormal if you don't know normal.
Segment client data. If one client's data gets breached, you need to prove the blast radius stops there.
Test your breach notification playbook at scale. Notifying 50 clients in 72 hours is a logistics problem, not just a legal one.

1 petabyte is rare. But third-party breaches at scale are not. Make sure your monitoring and evidence capabilities match your risk exposure.