Use this in the first hour of a suspected incident, and again each time a new fact arrives. You get one file in a new folder, ./incident-severity-triage/: a running incident log, one per incident, that opens with when the company found out, the proposed severity with its reason, who to call and which reporting deadlines may apply, then adds each new fact and decision with its time (<incident-id>-triage.md). This skill drafts for a human to review and sign; this skill never marks a control effective. The incident lead decides the severity; the agent proposes it fast, with reasons.

Inputs to gather

Speed matters more than completeness here. Read the incident response plan and its severity scale if one exists, and the alert, ticket or message that started this. Ask the reader, in one message, only what decides severity: what was seen and when, which systems and data, whether customers or production are affected, whether it is still happening, and whether personal data may be involved. Accept "unknown" and move on.

Step 1: record the clock first

Write the time of first detection and the time the company became aware that an incident probably occurred, in UTC, with who noticed and how. Several notification deadlines run from awareness, not from the end of the investigation. Awareness starts when someone in the company has a reasonable degree of certainty that an incident occurred, which can be the on-call engineer, not the security team's later confirmation. If the reader is unsure, record both candidate times and the reason; the reporting step decides which applies.

Step 2: classify on business impact

Use the company's scale. If there is none, use this one and mark it provisional in the record:

SEV1: confirmed theft or exposure of customer or personal data at scale, ransomware or destructive activity, an attacker active with administrator access, or the core service down for most customers.
SEV2: confirmed compromise contained to limited scope, exposure of one customer's data, a stolen credential with access to sensitive systems, or a partial outage of a core service.
SEV3: suspicious activity not yet confirmed, malware blocked on one device, a phishing click without credential entry, a minor outage with a workaround.
SEV4: an event with no impact, tracked for trends.