Incident

slug: incident element_type: TERM mutability: MUTABLE inline: true current_version: 0 status: seed-draft contentURI: null

An incident is an observed event or sequence of events in which a threat has interacted with one or more assets in a way that violates federation security policy, regardless of whether harm was successfully realized. An incident has a timeline (when observed, when started, when contained, when closed), an attribution claim (the threat responsible, with confidence), an impact assessment (what was actually affected), and an evidence chain (the data supporting all of the above). Incidents are immutable once filed; corrections produce new versions, never overwrites.

Status

Seed-draft, no personal attribution. Cyber Security Sub-Leviathan opening set (2026-05-16). The framing borrows from NIST SP 800-61 incident handling vocabulary but does not bind the federation to that framework's full lifecycle — domain authors choose.

Why this matters

The incident is the unit on which response, forensics, and post-mortem operate. Every other operational element (alerts, runbooks, evidence collection) refers back to "the incident." Federation-wide reporting and cross-instance learning require a shared definition.

Reasoning trail

• "Regardless of realized harm." An attempted but contained attack is still an incident — it informs threat models, exercises response, and provides evidence. Defining incident as "harm only" would create a perverse incentive to under-report close calls.
• Immutability is structural. Per principle:typed-findings and the inherited principle:witness-principle (from meta), incident records cannot be quietly edited. Corrections are explicit new versions with the prior version retained. This is the forensic discipline.
• Attribution is a claim with confidence, not a verdict. Premature attribution has caused historical incident-response failures. The schema requires confidence to be carried alongside the claim, never separated.
• Evidence chain is mandatory. A claim without an evidence pointer is a hypothesis, not an incident — handled in forum/cyber-security discussion, not in the registry.

Open questions for domain authors

• What is the minimum evidence to declare an incident? (One indicator of compromise? Two? A successful command execution? A failed login storm?)
• What is the threshold for closing an incident? Containment alone, or eradication + recovery + post-mortem?
• Should attempted-but-blocked events become incidents automatically, or be tagged as "near miss" with a lower lifecycle?
• How are multi-instance incidents (one threat hits assets across Sub-Leviathan boundaries) coordinated? Joint incident? Federated incident?

Related elements

• term:threat — threats cause incidents
• term:vulnerability — incidents typically exploit vulnerabilities
• term:asset — incidents affect assets
• rule:forensics-immutability — operational rule enforcing the immutability requirement
• rule:await-approval-before-mitigation — response actions during an incident gated through approval
• Inherited from meta: term:evidence, term:dialectic — incident discussions follow standard dialectic with evidence tiering

Awaiting domain author

Incident lifecycle (states, transitions, closure criteria) is the largest open design question for this Sub-Leviathan. See /forum/cyber-security.