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’s 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:
- It’s clearly cyber/IT-related.
The problem is described as a network outage, cyber incident, ransomware, system issue, IT security incident, etc. - 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
- 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.
How we describe a DD-CIT case
For each incident that qualifies, we care about three things:
- How the incident first surfaced (“disclosure pattern”)
- Who first called it “cyber” (attack, ransomware, incident, breach, hack, etc.)
- How officials talked about service impact
You can think of these as three tags we attach to each case.
1. Disclosure pattern
This is the story arc: who spoke first and how the framing changed over time.
Disclosure pattern lookup
| Code | Name | What it means (short) |
|---|---|---|
| OC-I | Official Cyber – Immediate | Official is first to speak, calls it cyber from the start, and acknowledges disruption. |
| OC-D | Official Cyber – Delayed | Official is first to speak, starts as a “technical issue,” later admits it is cyber, disruption described. |
| AC-OC | Attacker Claim → Official Cyber | Attacker/leak site reveals it first; official later confirms a cyber incident. |
| AC-TI | Attacker Claim + Technical Issue | Official talks about a technical issue plus disruption; attacker claims ransomware; official never clearly says cyber. |
| 3P-HP | Third-Party High Probability | Third parties surface ransom note/cyber language; disruption is clear; official stays vague or silent. |
| AC-Only | Attacker Claim Only | Only a ransomware claim; no documented disruption or meaningful official statement. |
We use these patterns:
- AC-OC – Attacker Claim → Official Cyber
A ransomware group or leak site is the first to name the victim. At some point later, the entity confirms a cyber incident (often framed as a data/security incident, sometimes with disruption). - AC-TI – Attacker Claim + Technical Issue
The public story is “technical issue” or “network outage,” but a ransomware group also claims the victim. Officials never clearly call it a cyberattack, even though disruption is real and visible. - 3P-HP – Third-Party High Probability
Students, staff, unions, or local media surface ransom notes or internal emails and call it ransomware/cyber. Services are clearly disrupted. The entity stays vague (“system issue”) or silent on the cyber side. - AC-Only – Attacker Claim Only
A leak site lists the victim, but:These are not DD-CIT cases; we track them separately if needed.- no reliable documentation of service disruption, and
- no meaningful official statement.
OC-D – Official Cyber, Delayed
The entity speaks first, but uses neutral language like “technical issue” or “network outage.” Only later do they admit it’s a cyber incident. Disruption is described.
Day 1: “We’re having IT issues affecting services.”
Day 7: “We have determined this was a cyberattack.”
OC-I – Official Cyber, Immediate
The first public statement comes from the entity and already calls it a cyber or security incident. Disruption is mentioned.
“We are experiencing a cyberattack that is affecting our systems…”
2. Who first called it “cyber”
This is about who used cyber language first, regardless of who acknowledged a problem first.
“Who first called it cyber” lookup
| Code | Who first used cyber language |
|---|---|
| O | Official (entity or regulator) |
| A | Attacker (ransomware group / leak site) |
| 3 | Third party (students, staff, unions, contractors, media) |
| N | No one yet (only “incident/outage/technical issue” so far) |
We care about four possibilities:
- Official – the entity or a regulator is first to say “cyber incident,” “ransomware,” “data breach,” “hack,” etc.
- Attacker – the ransomware group / leak site is first to use cyber language.
- Third party – students, staff, unions, contractors, or local media are first to call it ransomware/cyber.
- No one yet – the story is still only “incident,” “outage,” or “technical issue,” with no explicit cyber language from anyone.
DD-CIT uses this to talk about transparency and who controls the narrative.
3. How officials describe service impact
Here we’re only looking at what officials say about operations, not what attackers claim.
Service impact framing lookup
| Code | Label | What officials are saying about impact |
|---|---|---|
| S | Service disruption | Officials clearly say services/systems were disrupted (offline, unavailable, manual workarounds, restoration, etc.). |
| B | Breach-only | Officials only talk about data/privacy (unauthorized access, data security incident) with no clear disruption language. |
| U | Unclear | Messaging is too generic or thin to tell if services were impacted. |
We use three buckets:
- Service disruption (S)
Officials clearly say that services or systems were affected:- “We took systems offline,”
- “Some services were unavailable,”
- “We used manual processes,”
- “We have restored normal operations.”
- Breach-only (B)
Officials only talk about data and privacy:and never state that systems or services were disrupted.- “Unauthorized access to data,”
- “Data security incident,”
- “Personal information may have been compromised,”
- Unclear (U)
The message is too thin or generic to tell whether operations were affected.
Why we use “S” instead of “D” here:
The taxonomy name (DD-CIT) and the pattern OC-D already use “D” for “documented disruption” and “delayed.” To avoid confusion, we use S for service disruption in this field.
DD-CIT itself only includes incidents where this field is “S” (service disruption).
Breach-only and unclear cases can still be tracked in your broader dataset, but they aren’t counted as “documented disruption” events.
The DD-CIT disruption codes
In practice, once you’ve applied the three ideas above, every documented-disruption case lands in one of eight codes.
We write them as:
Disclosure pattern – Who first called it cyber
(Service disruption is implied.)
DD-CIT code lookup
| Code | What it captures (short) |
|---|---|
| OC-I-O | Official speaks first, calls it cyber immediately, and openly acknowledges service disruption. |
| OC-D-O | Official starts with technical/network issue affecting services, then later admits it is a cyber incident. |
| OC-D-A | Official starts with technical issue; attacker calls it cyber first; official later confirms cyber with disruption. |
| OC-D-3 | Official starts with technical issue; third party calls it ransomware/cyber first; official later confirms cyber with disruption. |
| AC-OC-A | Attacker or leak site reveals the incident first and frames it as cyber; the official later confirms cyber + disruption. |
| AC-TI-A | Official talks about a technical issue/outage and disruption; an attacker claims ransomware; the official never clearly calls it cyber. |
| AC-TI-3 | Official talks about a technical issue/outage and disruption; third parties show ransom notes or cyber language; the official never clearly calls it cyber. |
| 3P-HP-3 | Third parties are first to disclose the incident and call it cyber/ransomware; disruption is clear; officials never use clear cyber wording. |
The eight DD-CIT codes in prose:
- OC-I-O
- Official announces the incident.
- Official immediately calls it cyber.
- Official describes service disruption.
- OC-D-O
- Official first calls it a technical or network issue affecting services.
- The same official is the first to later admit it’s a cyber incident.
- Service disruption is described.
- OC-D-A
- Official first calls it a technical or network issue affecting services.
- A ransomware group is the first to publicly frame it as cyber.
- The entity later confirms a cyber incident.
- Service disruption is described.
- OC-D-3
- Official first calls it a technical or network issue affecting services.
- Third parties (students, staff, media) are first to say “ransomware/cyberattack.”
- The entity later adopts cyber language.
- Service disruption is described.
- AC-OC-A
- A ransomware group or leak site is first to disclose and frame it as cyber.
- The entity later confirms a cyber incident.
- Service disruption is described.
- AC-TI-A
- Official calls it a technical issue/outage and describes service disruption.
- A ransomware group claims responsibility.
- Officials never clearly say “cyberattack” or “ransomware,” but disruption is on the record.
- AC-TI-3
- Official calls it a technical issue/outage and describes service disruption.
- Third parties surface ransom notes or internal emails and call it cyber/ransomware.
- Officials never clearly say “cyberattack,” but disruption is on the record.
- 3P-HP-3
- Third parties are first to disclose the incident and call it cyber/ransomware.
- Service disruption is clearly documented (by those parties and/or generic official “system issue” language).
- Officials never give clear cyber wording.
Everything else lives in supporting categories:
- Breach-only AC-OC cases (no disruption admitted).
- Pure AC-Only claims (no documentation).
- Vague cases where the impact isn’t described enough.
Those remain useful for context, but they’re not “documented disruption” in the DD-CIT sense.
How to label a new case (quick checklist)
When you’re coding an incident:
- Check for clear disruption.
- If you can’t find language that clearly says services or systems were impacted, it’s not DD-CIT.
- If you can, treat it as a candidate DD-CIT case (service disruption).
- Decide the disclosure pattern.
- Did the entity speak first, and call it cyber right away? → OC-I
- Did the entity speak first as a “technical issue,” then later admit cyber? → OC-D
- Did a leak site / attacker reveal it first, and the entity later confirm cyber? → AC-OC
- Is there a mix of “technical issue” plus an attacker claim, with the entity never saying cyber? → AC-TI
- Did third parties surface a ransom note and cyber language while the entity stayed vague? → 3P-HP
- Is it only an attacker claim with no documentation? → AC-Only (not DD-CIT)
- Note who first called it cyber.
- Official, attacker, or third party.
- If the case has service disruption and meets the cyber criteria, assign a DD-CIT code from the list above that matches both:
- the disclosure pattern, and
- who first called it cyber.
That’s it. DD-CIT is just a disciplined way of saying:
“These are not just claims or breaches.
These are the cyber incidents where someone, somewhere, went on the record that services actually broke.”