Leadership
During an incident it’s one of the first questions people ask, what did the attacker do? Did they steal any data? How did they do it?
All of which are typically rather difficult to answer in the first, probably week of an incident (incidents vary, sometimes it’s very obvious, other times you can’t be 100% sure on some details!)
But recently I’ve been talking lots about the way organisations communicate during incidents to their customers and the public etc. I’ve been explaining that the day 0 comms of ‘no data was stolen’ followed by a ‘lots of data was stolen’ in say day zero plus five… well it doesn’t help with my my trust in the victim organisation. Which to me, seems like an odd strategy for organisations to take. They have options:
- Say nothing.
- Say they have had an incident and are investigating.
- Deny any loss has occurred (and often then countering the deny with an acceptance later)
- Say data loss has occurred/is likely.
And clearly variations of the above! Now….. there are a range of competing factors here ranging from:
- Brand & Reputation Management
- Legal requirements to report to data regulators and affected parties
- Trying to stop panic
- Legal implications
- Law Enforcement investigations
- Potential Negotiations with the criminals
and likely more! This is not a binary game! There are lots of factors, variables and pressures.
Now clearly doing planning for this before you have an incident is incredibly sensible, and whilst you can’t war-game every possible scenario you could at least focus on likely and high impact events and work out a plan from a worst case scenario perspective (a bit like we say as an industry, assume breach!)
So to help with this I’ve used GROK to generate a list of incident types alongside a likelihood of data loss:
Common Cyber Incidents and Data Theft Likelihood
| Cyber Incident Type | Description | Data Theft Likelihood |
|---|---|---|
| Ransomware (Encryption) | Malware encrypts victim’s data, demanding ransom for decryption. | High (Attackers often exfiltrate data before encryption for additional leverage). |
| Extortion-Only (Data Breach) | Attackers steal data and threaten to leak it unless ransom is paid. | Practically Guaranteed (Data theft is the core of the attack). |
| Phishing | Fraudulent emails or messages trick users into revealing sensitive information. | Moderate to High (Credentials or personal data often stolen if successful). |
| Business Email Compromise (BEC) | Attackers impersonate executives or vendors to trick employees into transferring funds or data. | Moderate (Data theft may occur to facilitate fraud, but financial loss is primary goal). |
| Malware (Non-Ransomware) | Malicious software (e.g., spyware, keyloggers) infiltrates systems. | High (Often designed to steal data like credentials or intellectual property). |
| Distributed Denial of Service (DDoS) | Overwhelms systems with traffic to disrupt services. | Low (Focus is on disruption, not data theft, though some attacks may pair with data breaches). |
| SQL Injection | Attackers exploit database vulnerabilities to extract data. | High (Directly targets sensitive data in databases). |
| Credential Stuffing | Attackers use stolen credentials to gain unauthorized access to accounts. | Moderate (Access may lead to data theft, depending on account contents). |
| Insider Threat | Employees or contractors misuse access to steal or leak data. | High (Intentional insider attacks often target sensitive data). |
| Supply Chain Attack | Attackers compromise a third-party vendor to access target systems or data. | Moderate to High (Depends on attacker’s goal, but data theft is common). |
| Zero-Day Exploit | Attackers exploit unpatched software vulnerabilities. | Variable (Data theft depends on the system compromised and attacker’s intent). |
| Social Engineering | Manipulating individuals to disclose confidential information or perform actions. | Moderate to High (Often used to gain access to data or systems). |
| Cryptojacking (Crypto Mining) | Attackers use victim’s computing resources to mine cryptocurrency without consent. | Low (Focus is on resource exploitation, but some attacks may involve data theft for access or persistence). |
| Misconfigured Cloud Storage (Open Buckets) | Unsecured cloud storage (e.g., AWS S3 buckets) left publicly accessible, exposing data. | High (Data is openly accessible, making theft or exposure highly likely). |
| Open Directories | Unprotected web server directories expose sensitive files to public access. | High (Files are publicly accessible, enabling easy data theft). |
| Physical Device Loss/Theft | Laptops, USB drives, or other devices containing sensitive data are lost or stolen. | Moderate to High (Depends on encryption and attacker’s ability to access data). |
| Web Skimming | Malicious code on websites captures user data, such as payment details, during transactions. | High (Directly targets sensitive user data like credit card information). |
If anything you probably want to focus on the idea of an incident where you have lost data. You also probably want to work out a high level comms plan example for macro incident types to cover the first two weeks (as an example).
This at least should be provoking responses to questions such as:
If you suffered a major encryption even, what would you do? how would you communicate!
Now to also help in this space, I had GROK analyse a number of incidents and the comms approaches:
Data Breach Communication Pattern Analysis
Introduction
A recurring pattern exists in data breach communications where organizations initially report on “day 0” (the day the breach is publicly disclosed or detected) that no data has been accessed by cybercriminals, only to revise their statements—often within a week—to confirm data access. This analysis examines this pattern using 2025 cyber incidents from Transport for London (TfL), Royal Mail, Marks & Spencer (M&S), Co-op, and Harrods, alongside broader trends from 2024–2025 breaches. It explores why this pattern occurs, its implications, and recommendations for improvement.
Evidence from 2025 Incidents
The following table summarizes the communication timelines for the 2025 incidents to assess the pattern.
| Organization | Day 0 Statement | Confirmation of Data Access | Time Gap | Fits Pattern? |
|---|---|---|---|---|
| TfL | Sep 2, 2024: “No evidence any customer data has been compromised.” | Sep 12, 2024: Names, contact details, bank details (~5,000 customers) accessed. | 11 days | Yes |
| Royal Mail | Apr 1, 2025: No data compromise specified; no operational impact. | Apr 2, 2025: 144GB data leaked (names, addresses, company info). | 1 day | Partial |
| M&S | Apr 20, 2025: Disruptions to payments, click-and-collect; no data claim. | Apr 24–25, 2025: Data exfiltrated via ransomware. | 4–5 days | Partial |
| Co-op | Apr 30, 2025: “No initial evidence of customer data compromise.” | May 2, 2025: Member data (names, DOBs, contacts) accessed. | 2 days | Yes |
| Harrods | May 1, 2025: “No evidence of data breaches.” | May 8, 2025: No data breach confirmed. | 7+ days | No |
Summary: TfL (11 days) and Co-op (2 days) strongly fit the pattern, M&S (4–5 days) partially fits due to vague initial statements, Royal Mail’s 1-day gap is accelerated by external leaks, and Harrods is an outlier with no data breach confirmed.
Broader Evidence (2024–2025)
Other breaches reinforce the pattern:
- Bank Sepah (Mar 2025): Denied breach; days later, acknowledged 42 million records accessed.
- Oracle Health (Mar 2025): Denied breach; weeks later, confirmed patient data theft.
- NTT Communications (Feb 2025): Feb 5, no data claim; Feb 15, 17,891 customer companies’ data accessed.
- VeriSource (Apr 2025): Initial 112,000 affected; weeks later, 4 million confirmed.
The 2025 Verizon DBIR notes ransomware and credential-based attacks delay data exfiltration detection, contributing to this pattern.
Why Does This Pattern Occur?
- Investigative Delays: Complex attacks (e.g., Scattered Spider’s MFA fatigue in M&S) require time for forensic analysis. Verizon DBIR: Credential-based breaches take 249–323 days to identify.
- Cautious Communication: Organizations avoid premature data theft claims to limit panic or liability. FTC advises against misleading statements, creating a dilemma.
- External Pressure: Hacker leaks (e.g., GHNA for Royal Mail, DragonForce for Co-op) force quicker revisions. 2025 DBIR: Rise in ransomware extortion attacks.
- Regulatory Constraints: GDPR’s 72-hour notification rule pressures quick but incomplete statements.
- Third-Party Complexity: Supply chain attacks (e.g., Spectos for Royal Mail) delay investigations. Gartner: 45% of organizations face such attacks by 2025.
Critical Examination
Criticisms
- Lack of Transparency: Repeated reversals (e.g., TfL, Co-op) erode trust, as noted in a May 3, 2025, X post.
- Regulatory Pressure: GDPR pushes quick disclosures, leading to inaccuracies.
- Victim Impact: Delayed confirmations delay protections, increasing identity theft risks.
Defenses
- Investigative Necessity: Breaches require time to diagnose. FTC recommends forensic teams.
- Avoiding Misinformation: Premature data theft claims could mislead stakeholders.
- Evolving Threats: 2025 DBIR notes ransomware and credential attacks are harder to detect.
Counterpoint: Harrods’ containment shows the pattern isn’t universal, but most attacks (e.g., DragonForce) are too complex for instant clarity.
Implications
- Eroded Trust: 75% of consumers avoid untrusted companies.
- Increased Costs: IBM: 2024 breach cost $4.88M, with $1.58M for detection/escalation. TfL spent £30M.
- Regulatory Scrutiny: GDPR, NYAG may penalize misleading communications.
Recommendations
For Organizations
- Transparent Statements: Avoid definitive “no data accessed” claims; use “investigating, will update” (FTC, X post).
- Accelerate Forensics: Use AI/automation (61% adoption, 74-day savings per IBM).
- Communication Plans: Model TfL’s dedicated page (tfl.gov.uk).
- Third-Party Security: Vet vendors (82% share sensitive data).
- Regular Drills: Conduct breach simulations (Secureframe).
For Consumers
- Monitor accounts/credit reports post-breach.
- Demand transparency, per X post.
- Use fraud alerts/credit freezes (e.g., Freddie Mac advice).
Conclusion
The pattern of claiming “no data accessed” on day 0, then confirming access ~1 week later, is evident in TfL, Co-op, partially M&S, and other 2024–2025 breaches (e.g., Bank Sepah, Oracle). Driven by investigative delays, cautious communications, hacker leaks, regulations, and third-party complexity, it erodes trust and raises costs. Harrods’ exception highlights containment’s value, but sophisticated attacks dominate. Transparency, faster forensics, and robust defenses are critical, while consumers should stay vigilant.
It’s interesting isn’t it, this dataset is small, I might expand this if can find time, I’d love to see data on customer sentiment as the comms journey goes as well.
Moving forwards
As always you will likely want to engage a range of stakeholders, you may find different roles have very different perspectives on this.
For me the key thing is thinking and planning for a bad day, making sure you have at least the bones of some plans in place that you can then build upon, with table tops but also simulations and training exercises, and then if you combine all of this with a kick ass cyber security capability with continual learning and improvement you hopefully will never have to use it, but you will have, just incase an idea of how your incident might go and how you might want to communicate.
