Skip to content

DD-CIT: Documented Disruption Cyber Incident Taxonomy

What DD-CIT is for

DD-CIT is DysruptionHub’s way of tracking cyber/IT incidents that clearly disrupt services, not just data breaches or ransomware claims.

It is intentionally narrow. We only count cases where there is public, on-the-record evidence that something stopped working:

  • systems offline
  • portals or apps unavailable
  • services diverted or delayed
  • staff forced onto paper or manual workarounds

If all you have is a leak-site logo or a vague “data security incident,” it does not go into DD-CIT. It can live elsewhere in your tracking, but it doesn’t count as a documented disruption.

When an incident “counts” for DD-CIT

An incident belongs in DD-CIT if:

  1. It’s clearly cyber/IT-related.
    The problem is described as a network outage, cyber incident, ransomware, system issue, IT security incident, etc.
  2. Service disruption is described clearly in public.
    At least one credible source (the entity, a regulator, reliable local or national media) says something like:
    • systems were taken offline or shut down
    • services were unavailable or limited
    • staff used paper/manual workarounds
    • operations were diverted and then later restored
  3. There is a named entity.
    A city, county, hospital, school district, utility, company, etc. — not just “a hospital in the Midwest.”

If you don’t have documented disruption, it’s not DD-CIT, even if you’re pretty sure systems were affected.

The two axes: how we describe a DD-CIT case

For each incident that qualifies, we care about two core questions:

  1. Who owns the “cyber” story?
  2. Who owns the “disruption” story?

DD-CIT uses a short code that combines both:

[Cyber transparency] – [Disruption transparency]
Example: OC-OD, XC-OC-OD, XC-XD, XC-ND, etc.

DD-CIT proper only tracks incidents where disruption is documented (OD or XD).
Cases with ND (“no disruption cues”) live outside DD-CIT but can still be tracked in the broader dataset.

1. Cyber transparency scale

This axis answers: who publicly framed it as a cyber incident?

Cyber transparency lookup

Code Label What it means (short)
OC Official Cyber The entity publicly calls it a cyber incident (cyberattack, ransomware, data breach, hack, etc.).
XC-OC External Cyber → Official External actors (attacker or third party) call it cyber first; the entity later confirms it as cyber.
XC External Cyber only Only external actors ever call it cyber; the entity never uses explicit cyber language.

You can think of this as a transparency ladder:

  • OC → most transparent on cause (“we were hit by X”).
  • XC-OC → pulled into admitting cyber after someone else forced the issue.
  • XC → the entity never uses cyber language; attackers/third parties tell that part of the story.

2. Disruption transparency scale

This axis answers: who clearly admitted that services broke?

Disruption transparency lookup

Code Label What it means (short)
OD Official Disruption The entity clearly describes disruption (systems offline, services unavailable, manual workarounds, etc.).
XD External Disruption only Disruption is only clearly described by credible external sources (media, regulators, staff/students, etc.).
ND No Disruption cues No credible public source clearly describes disruption.

DD-CIT focuses on OD and XD.
ND is used to classify claim-only or breach-only cases that don’t have documented disruption.

Examples of OD:

  • “We took some systems offline as a precaution.”
  • “We are experiencing an outage affecting online bill pay.”
  • “We are using manual processes while we restore our systems.”

Examples of XD:

  • Entity says little or nothing beyond vague “issues,” but:
    • Local media or regulators describe closures, diversions, downtime, or workarounds.
    • Staff/students/unions describe systems being down in ways you can treat as credible.

Examples of ND:

  • Only an attacker leak site lists the victim.
  • No one (officials or credible third parties) clearly says anything went down.

3. DD-CIT codes: combining cyber + disruption

Once an incident passes the DD-CIT gate (cyber/IT + disruption + named entity), you can assign a combined code.

Remember:

  • First part = cyber transparency (OC, XC-OC, XC)
  • Second part = disruption transparency (OD, XD, ND)

For DD-CIT itself, we only keep cases where the disruption side is OD or XD.

DD-CIT “in-scope” combinations (disruption documented)

These are the main combinations you’ll actually see in DD-CIT:

Code Cyber transparency (who calls it cyber?) Disruption transparency (who admits things broke?) What it captures (short)
OC-OD Official Cyber Official Disruption Entity calls it cyber and clearly admits disruption.
OC-XD Official Cyber External Disruption only Entity calls it cyber, but only external sources clearly describe disruption.
XC-OC-OD External Cyber → Official Cyber Official Disruption External actors call it cyber first; entity later confirms cyber and clearly admits disruption.
XC-OC-XD External Cyber → Official Cyber External Disruption only External actors call it cyber first; entity later confirms cyber but never clearly describes disruption.
XC-OD External Cyber only (entity never says “cyber”) Official Disruption Entity admits disruption as a “technical issue/outage,” but never uses cyber language; external actors do.
XC-XD External Cyber only External Disruption only Only external actors describe both cyber and disruption; entity never clearly admits either.

You can think of these as the core DD-CIT universe:
we know something broke, and we know there’s a cyber/IT angle, but the mix of who speaks about what changes the transparency score.

Examples in the wild

Below are current examples for each DD-CIT pattern. These will evolve over time as we add more coverage.

  • OC-OD – Official Cyber, Official Disruption
  • OC-XD – Official Cyber, External Disruption only
    • No clear public example yet.
      This would look like an entity labeling an event a “cyberattack” while insisting operations were unaffected, even as credible external reporting documents concrete outages or workarounds. If you spot a case that fits, we’d like to hear about it.
  • XC-OC-OD – External Cyber → Official Cyber, Official Disruption
    • Cyber threat at Georgia court records hub disrupts filings
      A ransomware group and external reporting frame the incident as a cyberattack first. The Georgia court records authority later cites a “cybersecurity threat,” takes systems offline and clearly describes statewide filing disruption and paper-based workarounds.
  • XC-OC-XD – External Cyber → Official Cyber, External Disruption only
    • No clear public example yet.
      This would look like external actors first calling it cyber, the entity eventually confirming it as a cyber incident, but only external sources providing convincing detail about disruption. Send us candidates if you see them.
  • XC-OD – External Cyber only, Official Disruption
    • Qilin claims ransomware hit on Santa Paula, California
      The city describes a “citywide network outage” affecting email and internal servers and warns some services may be unavailable, but never uses cyber language. Ransomware framing comes from the Qilin leak site and third-party researchers.
    • Catawba County, North Carolina website disruption
      The county’s website shows a prolonged “temporarily offline for maintenance” message and officials acknowledge the outage, while Qilin later claims “Catawba County Government” on its leak site. The county never publicly calls it cyber.
  • XC-XD – External Cyber only, External Disruption only

4. Out-of-scope combinations (no disruption)

We still see cases where there’s a cyber claim or cyber language but no disruption cues. These are useful context, but they are not DD-CIT cases.

They live in the ND column:

Code What it means (short) Example
OC-ND Entity calls it a cyber/data incident, but never clearly describes disruption; no one else does either. A pure data breach with no services impact on the record.
XC-OC-ND External calls it cyber first; entity later confirms cyber, but no one clearly describes disruption. A confirmed cyber incident framed strictly as a data/privacy event.
XC-ND External Cyber only; no one clearly describes disruption. Ransomware gang lists a victim; there’s no visible or reported impact.

You can still track these in your broader dataset, but they are explicitly outside DD-CIT because there is no credible, documented disruption.

5. How to label a new case (quick checklist)

When you’re coding an incident:

  1. Check if it even belongs in DD-CIT.If no disruption cue at all, it’s ND (e.g., XC-ND) and not a DD-CIT case.
    • Is it clearly cyber/IT-related?
    • Is there a named entity?
    • Can you find at least one credible disruption cue?
  2. Assign cyber transparency (OC / XC-OC / XC).
    • Did the entity publicly call it a cyber incident (cyberattack, ransomware, data breach, hack, etc.)?
      • Yes → at least OC.
    • Did someone external (attacker or third party) call it cyber before the entity did?
      • YesXC-OC (external first, then official cyber).
    • Did the entity never use cyber language at all, and only attackers/third parties did?
      • YesXC (external cyber only).
  3. Assign disruption transparency (OD / XD / ND).
    • Does the entity clearly describe disruption (systems down, services unavailable, manual workarounds, restoration)?
      • YesOD.
    • If not, do credible external sources clearly describe disruption?
      • YesXD.
    • If neither officials nor credible third parties clearly describe disruption:
      • ND → out-of-scope for DD-CIT.
  4. Combine them into a DD-CIT code.
    • If disruption = OD or XD → this is a DD-CIT case.
      • Example: OC-OD, XC-OC-OD, XC-XD.
    • If disruption = ND → not a DD-CIT case.
      • Example: XC-ND (AC-Only).

What DD-CIT is really saying

All of this boils down to a simple idea:

These are not just claims or quiet breaches.
These are the cyber/IT incidents where someone, somewhere, went on the record that services actually broke — and we track who told the truth about cause and impact.

About DD-CIT

DD-CIT (Documented Disruption Cyber Incident Taxonomy) is developed and maintained by DysruptionHub as a newsroom and research framework for classifying cyber/IT incidents with documented service disruption.

You’re welcome to reference or adapt DD-CIT in your own research or reporting. Please credit DysruptionHub and link back to this explainer when you do.

Suggested citation:
DysruptionHub. “DD-CIT: Documented Disruption Cyber Incident Taxonomy.” 2025.

Versioning:
This is DD-CIT v1.0 and it will evolve as new patterns and edge cases emerge. Feedback from researchers, defenders and journalists who use it in the field is welcome.