If you follow ransomware leak sites or breach disclosure feeds, it might feel like there’s a new “incident” every hour. But you won’t see all of them on DysruptionHub.
That’s not a mistake. It’s a choice.
We can’t cover everything, so what we cover has to matter. For us, that means focusing on real-world disruption to services in the United States and its territories, not every logo on a leak site or vague “data security event” press release.
To make that filter explicit and repeatable, we built DD-CIT: the Documented Disruption Cyber Incident Taxonomy.
This short piece explains what that means in practice.
What qualifies an incident for DysruptionHub?
For our core coverage, an incident generally has to pass four tests:
- It’s clearly cyber/IT-related.
The problem is described as a cyber incident, network outage, ransomware attack, system issue, IT security problem, etc. - There’s a named entity.
A city, county, school district, hospital, utility, agency, company, cooperative, etc.
“A hospital in the Midwest” doesn’t cut it. - There’s documented disruption.
Someone credible says, in public, that something actually broke.
If no one can point to disruption, it might still be a serious breach, but it’s not a DD-CIT disruption case and usually not a DysruptionHub story.- systems taken offline
- portals or apps unavailable
- services delayed, diverted or cancelled
- staff forced onto paper or manual workarounds
- It impacts the United States or its territories.
Our primary scope is U.S. public interest: local governments, schools, courts, hospitals, utilities, regional companies and so on. We sometimes reference international incidents as context, but they’re not the core of our tracker.
Only when an incident passes those gates do we ask: how transparent was the public story?
That’s where DD-CIT comes in.
The two questions DD-CIT answers
Once we know an incident is “in,” DD-CIT focuses on two simple questions:
- Who owns the “cyber” story?
- Did the entity itself call it a cyberattack or security incident?
- Or did that framing come from an attacker, staff, unions, reporters, or researchers?
- Who owns the “disruption” story?
- Did the entity clearly admit that services were affected?
- Or did we only learn about outages and workarounds from outside sources?
We encode the answers as a short code:
[Cyber transparency] – [Disruption transparency]
Example: OC-OD, XC-OC-OD, XC-XD, XC-ND.
You don’t have to memorize the codes to read DysruptionHub. They exist so we can be consistent and honest about how much the public really knows about what broke and who said so.
Chip in once
If this reporting helped you, a one-time tip helps cover hosting, tools and future investigations.
Support us monthly
A small monthly pledge keeps independent coverage and our reader tools online for everyone.
Cyber transparency: OC, XC-OC, XC
On the “cyber” side, we think in three bands:
- OC – Official Cyber
The entity publicly calls it a cyber incident: cyberattack, ransomware, data breach, hack, etc. - XC-OC – External Cyber → Official Cyber
A ransomware group, researcher, staff or media outlet calls it cyber first.
The entity catches up later and starts using cyber language too. - XC – External Cyber only
The entity never uses cyber language.
The only people saying “ransomware” or “cyberattack” are attackers or third parties.
Think of it as a ladder:
OC → most transparent on cause
XC-OC → dragged into admitting it
XC → outsiders tell the cyber story, not the victim
Disruption transparency: OD, XD, ND
On the “disruption” side, we use:
- OD – Official Disruption
The entity clearly says services were affected:- “We took systems offline.”
- “Some services are unavailable or limited.”
- “We are using manual processes.”
- XD – External Disruption only
The entity stays vague (“technical issues,” “network problems”), but credible external sources spell out what actually broke: closed offices, missed deliveries, cancelled appointments, paper workarounds. - ND – No Disruption cues
No one you’d rely on — not the entity, not regulators, not reporters — clearly says that services went down.
DD-CIT is about documented disruption, so we only count OD and XD.
Anything with ND (no disruption on the record) sits outside the taxonomy.
Putting it together: examples
Once you have both sides, you can describe an incident with a compact code.
Here are a few grounded examples from DysruptionHub’s own work:
- OC-OD – Official Cyber, Official Disruption
A city acknowledges a “cyber-attack” and explains that invoices, permits and hiring systems are disrupted, with manual workarounds in place. Officials own both the cyber label and the outage story. - XC-OD – External Cyber only, Official Disruption
A municipality talks about a “citywide network outage” and warns services may be unavailable, but never says “ransomware” or “cyber.” A ransomware group’s leak site and researchers provide the cyber framing. The city is honest about what’s broken, but evasive about why. - XC-XD – External Cyber only, External Disruption only
A broadcaster never posts a statement, but an on-air announcement (relayed by listeners) uses the word “ransomware,” and listeners plus our own checks show streams failing and systems degraded. The company never publishes a durable record of either cyber cause or disruption. Outsiders tell the whole story. - XC-ND – External Cyber only, No Disruption cues (out of scope for DD-CIT)
A ransomware gang lists an organization on a leak site. There’s no local reporting, no official statement, no sign in public records that services changed. That still matters for threat intelligence and victim awareness, but it doesn’t meet our bar for documented disruption, so we don’t treat it as a DD-CIT case.
In practice, XC-ND is the vast majority of ransomware group claims. Projects like ransomware.live do an excellent job cataloging these listings, and DataBreaches.net has long documented cases where we only ever get the attacker’s side of the story. Reporters such as Valery Marchive (Le Mag IT / TechTarget) also provide invaluable coverage of these incidents, especially in Europe and other regions outside our core U.S. focus. We don’t ignore XC-ND cases because they’re unimportant; we exclude them from DD-CIT because this taxonomy requires credible public signals on both sides of the equation: cyber and disruption.
Most of what we cover falls into a small subset of these combinations. Some theoretically valid patterns, like OC-XD (entity calls it cyber but refuses to admit disruption while outsiders document outages), are rare and usually temporary — one later line about “service impact” typically moves them into OC-OD or XC-OC-OD.
Why this matters for coverage
If you’ve ever wondered why DysruptionHub doesn’t write up every leak-site post, every corporate breach notice or every “technical issue,” DD-CIT is the answer.
We’re deliberately biased toward:
- Named entities in the United States and its territories
- Clear, public evidence of disruption
- A transparent record of who told the truth about cause and impact
That means we skip a lot of:
- pure claim-only “victims” with no visible impact
- breach notices that never mention systems or services
- vague “technical issues” that might be cyber but have no documented disruption
We’d rather go deeper on the incidents where people’s lives, services and trust are actually affected — and where transparency (or the lack of it) matters.
If you want the full technical breakdown of DD-CIT, including all the codes and lookup tables, we keep a separate explainer page for that. For day-to-day reading, you just need to know:
When DysruptionHub covers an incident, it’s because someone, somewhere, went on the record that services really broke — and we’re tracking how honestly that story was told.
