Investigating a Cybersecurity Breach

1. Method, not just the beat

Reporting a specific breach or hack is a distinct investigative task from covering cybercrime as a beat. The beat is about sources, trends, and context; a breach investigation is about a single, contested factual claim — that an organisation has been compromised and that data has been exposed — and about establishing whether that claim is true, at what scale, and with what consequences, before anything is published.

Breach stories carry an unusual combination of pressures: a strong incentive to publish fast, unreliable and self-interested claims from attackers, sensitive personal data in the mix, and real legal exposure around how you obtain and handle material. Getting the method right protects the people affected, protects you, and protects the accuracy of the story.

This guide is about verification, harm-minimisation, and legal care. It is not legal advice, and it deliberately avoids any guidance on accessing systems or data. Any significant breach story should involve senior editorial oversight and, where data of uncertain provenance is involved, a media lawyer.

2. Verifying a breach claim before publishing

The central discipline is to treat a breach claim as unproven until you have corroborated it. Verification usually rests on three independent moves.

1. Check a sample against known-good data

The most reliable signal is confirming that a sample of the claimed data matches real, verifiable information you already hold or can independently obtain, without republishing it. If supposedly breached records line up with confirmed facts, the claim gains weight; if they do not, be sceptical.

2. Contact the affected organisation

Put the claim to the organisation and give it a fair chance to confirm, deny, correct, or comment before publication. Its response, or refusal to respond, is part of the story, and approaching it is both fair practice and a verification step in its own right.

3. Use corroboration signals carefully

Services such as Have I Been Pwned can indicate whether email addresses appear in known breach corpora. Treat this as one corroborating signal, not as proof that a specific, newly claimed incident occurred, and never as a substitute for confirming the claim directly.

3. Handling leaked data and the Computer Misuse Act 1990

The single most important legal line is that you must never access a computer system, account, or network without authorisation. The Computer Misuse Act 1990 criminalises unauthorised access to computer material, and journalistic motive is not a defence to gaining access yourself.

Do not log into, probe, or test any system, account, or database to check whether a breach is real; that is exactly what the Computer Misuse Act 1990 is designed to prohibit.
Analysing a dataset a source has already provided is different from actively accessing a system, but handling stolen data still carries legal and ethical risk that should be assessed before you receive it.
Take legal advice before accepting or examining material of uncertain provenance, and document who provided it, when, and on what understanding.
The public interest in reporting a breach does not authorise obtaining the underlying data unlawfully yourself, and a court will distinguish sharply between receiving material and going to get it.
Store any received material securely and limit access to it, both to protect sources and to reduce the risk of onward harm.

4. Minimising harm to the people in the data

A leak exposes real people. The fact that data is already circulating does not make republishing it harmless or lawful, and thoughtless reproduction can compound the damage the breach has already done.

Report the existence, scale, and significance of a breach without republishing individuals' personal records.
Where a specific detail is genuinely necessary to the public interest, redact or aggregate wherever possible rather than reproducing raw data.
Consider the safety implications for named individuals, especially where a leak includes location, financial, health, or otherwise sensitive information.
Remember that the Data Protection Act 2018 journalism exemption can support legitimate reporting, but it is not a blanket licence to publish everything a leak contains.
Take particular care with data relating to children, victims of crime, or other vulnerable people, where the harm of exposure is greatest.

5. Working with the organisation and the ICO framework

The affected organisation is both a subject and a source. Approaching it fairly, and understanding its legal obligations, opens up lines of inquiry that strengthen the story.

Under the UK GDPR and the Data Protection Act 2018, an organisation that suffers a qualifying personal data breach must notify the Information Commissioner's Office without undue delay and, where feasible, within 72 hours of becoming aware of it, and in some cases must also inform the affected individuals. That duty sits with the organisation, not with you, but it gives you a precise set of questions: when did it become aware, did it notify the ICO and those affected, and did it act within the expected window?

A delay or failure in notification, or a gap between what an organisation told the public and what it told the regulator, can be a legitimate and important part of the story in its own right. Confirmed regulatory action or a published ICO statement is a safe, on-the-record fact to report.

6. Attributing an attack cautiously

Attribution is where breach reporting most often goes wrong. Naming a group, nation, or individual as responsible without solid evidence is both an accuracy failure and a defamation risk.

Distinguish between what is confirmed (an organisation has acknowledged an incident), what is claimed (a group says it was responsible), and what is proven (independent evidence of who did it).
Treat any claim of responsibility as an assertion to be verified, not a fact, particularly where it comes from the attacker.
Where attribution cannot be established, report what is actually known rather than filling the gap with a named culprit.
Be wary of technical attribution shared by a single vendor or source without corroboration; genuine attribution is difficult and contested.
Remember that stating who carried out a criminal act, without proof, exposes both you and your publisher to legal claims.

7. Ransomware leak-site claims and corroboration

Ransomware groups routinely publish claims and samples on their own leak sites to pressure victims into paying. These claims are self-serving and cannot be taken at face value: a listing may exaggerate the volume of data, misidentify the victim, recycle old material, or be entirely false.

Treat a leak-site claim as a starting point for inquiry, never as a confirmed fact. Corroborate it the same way you would any breach claim: check a sample against known-good data where possible, seek confirmation from the named organisation, and be transparent with readers about the source and the level of confidence. Reporting that a group “claims” to have breached an organisation is very different from reporting that the breach has occurred.

Publishing an unverified leak-site claim can hand a criminal group exactly the leverage it wants, so weigh whether repeating the claim at all is justified before you have corroboration.

8. Coordinating disclosure timing responsibly

When you publish can matter as much as what you publish. If a vulnerability is still live, immediate publication of specifics could expose more people to harm before the organisation can respond.

1Give the affected organisation reasonable notice and a genuine opportunity to secure systems and notify those at risk, balanced against the public interest in timely reporting.
2Avoid publishing operational detail that would help others exploit an unpatched vulnerability while it remains live.
3Coordinate, where appropriate, with the organisation and relevant authorities on the timing of disclosure, without ceding editorial control of the story.
4Weigh the harm of delay (people left unaware their data is exposed) against the harm of premature publication (wider exploitation), and record the reasoning.
5Be transparent with readers about what has and has not been fixed at the point of publication.

9. Pre-publication checklist

I have corroborated the breach claim, ideally by checking a sample against known-good data, not relied on the claim alone.
I have put the claim to the affected organisation and fairly reflected its response or lack of one.
I have not accessed any system or account myself, and I have taken advice on handling any received data.
I am not republishing individuals' personal records, and any necessary detail is redacted or aggregated.
I have separated what is confirmed, what is merely claimed, and what is proven about attribution.
I have treated any ransomware leak-site claim as unverified until corroborated.
I have considered disclosure timing and whether publishing specifics could cause further harm.
Senior editorial, and a lawyer where data provenance is uncertain, have reviewed the piece.

10. Common mistakes

Publishing a breach claim on the strength of an attacker's say-so without independent corroboration.
Logging into or probing a system to check whether a breach is real, risking a Computer Misuse Act 1990 offence.
Republishing leaked personal records when the story only needed the fact and scale of the breach.
Naming a responsible group or nation as fact when attribution is unconfirmed.
Repeating a ransomware leak-site listing verbatim and lending it credibility it has not earned.
Rushing to publish live-vulnerability detail before the organisation has had any chance to protect those affected.

11. Jargon glossary

Data breach

A security incident in which personal or confidential data is exposed, lost, or accessed without authorisation.

Known-good data

Verified information you already hold or can independently obtain, used to test a leaked sample.

Computer Misuse Act 1990

The UK statute criminalising unauthorised access to computer material and related offences.

UK GDPR / DPA 2018

The UK data-protection framework, including breach-notification duties on organisations.

ICO

The Information Commissioner's Office, the UK regulator that receives breach notifications.

Attribution

Identifying who was responsible for a cyber attack, which is difficult and often contested.

Leak site

A site, often run by a ransomware group, used to publish claims and samples to pressure victims.

Responsible disclosure

Coordinating the timing of publication to reduce harm while a vulnerability is addressed.

Tools for breach investigations

Use our Investigation Risk Register to log your verification steps, data-handling decisions, and disclosure-timing reasoning on a breach story.

Investigation Risk Register Cybercrime Reporting (Depth)

Frequently asked questions

How do I verify a breach claim before publishing?

Start from the assumption that a claimed breach is unproven. The strongest signal is checking a sample of the leaked data against known-good information you already hold or can independently obtain — for example confirming that supposedly breached account details match real, verifiable records without republishing them. Contact the affected organisation and give it a fair opportunity to confirm, deny, or comment. Corroboration services such as Have I Been Pwned can indicate whether an email address appears in known breach corpora, but treat that as one signal among several, not proof of a specific new incident. If you cannot verify, report only what you can establish and say clearly what remains unconfirmed.

Can I access a leaked dataset or a system myself?

You must never access a computer system, account, or network without authorisation. Doing so risks committing an offence under the Computer Misuse Act 1990, which criminalises unauthorised access to computer material regardless of journalistic motive. Analysing a dataset that a source has provided is different from actively breaking into a system, but even handling stolen data can carry legal and ethical risk, and the safest course is to take legal advice before you receive or examine material of uncertain provenance. The public-interest justification for reporting a breach does not extend to obtaining the underlying data unlawfully yourself.

How should I handle personal data contained in a leak?

Minimise harm. The fact that data has been leaked does not make it fair game to republish, and reproducing individuals' personal information can compound the harm caused by the breach and raise data-protection issues of your own. Report the existence, scale, and significance of a breach without publishing the personal records of the people affected. Where a specific detail is genuinely necessary to the public interest, redact or aggregate wherever possible and take advice on the data-protection position. The journalism exemption in the Data Protection Act 2018 can apply to legitimate reporting, but it is not a blanket licence to publish whatever a leak contains.

What does the ICO 72-hour rule actually require?

Under the UK GDPR and the Data Protection Act 2018, an organisation that suffers a personal data breach must, where the breach meets the relevant threshold, notify the Information Commissioner's Office without undue delay and, where feasible, within 72 hours of becoming aware of it. That duty falls on the organisation, not on the journalist. For reporting purposes it gives you a useful line of inquiry: when did the organisation become aware, did it notify the ICO and affected individuals, and did it do so within the expected window? A failure or delay in notification can itself be a legitimate and newsworthy part of the story.

How cautiously should I attribute an attack to a named group?

Very cautiously. Attribution in cyber incidents is genuinely difficult, and naming a specific group, nation, or individual without solid evidence is both a factual and a legal risk. Claims made on a ransomware gang's leak site, or by an anonymous actor, are self-serving and frequently exaggerated or false, so they require independent corroboration before you repeat them. Where you cannot confirm attribution, describe what is actually known — that an organisation has confirmed an incident, that a group has claimed responsibility, or that a dataset has appeared online — rather than stating who was responsible as fact. Attribution asserted without proof is a defamation and accuracy hazard.

Primary sources

Computer Misuse Act 1990— legislation.gov.uk
Data Protection Act 2018— legislation.gov.uk
Personal data breaches: notification guidance— Information Commissioner's Office
Have I Been Pwned— Have I Been Pwned
National Cyber Security Centre— NCSC