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.
Classify by impact on customers, data and operations, never by how loud the alert is or how hard the technical problem looks. When torn between two levels, pick the higher one and record the reason; downgrading later costs little, a missed deadline or an absent decision maker costs a lot.
Step 3: decide who is called
Propose the call list from the plan's contact tree, by role:
- SEV1: incident lead, technical lead, an executive who can authorise spending and shutting down systems, legal and privacy, communications, within about 15 minutes, day or night.
- SEV2: incident lead, the system owner, privacy if personal data may be involved, within the hour.
- SEV3: the on-call engineer in working hours; incident lead informed.
- SEV4: ticket only.
If the normal channels may be compromised (mailbox takeover, chat account takeover), say so and propose the out-of-band channel from the plan.
Step 4: flag clocks and preserve evidence
Separate from severity, add a line per regime and contract, each marked yes, no or unknown, with the fact that decides it: personal data affected, and whose (for the company's own data GDPR Art. 33 runs from its awareness; as a processor for a customer's data, the duty is to tell that customer without undue delay, Art. 33(2)), a significant incident for an entity in NIS 2 scope (Art. 23, where the early warning is due within 24 hours of awareness, so a yes or unknown cannot wait for the investigation), a major ICT-related incident for a financial entity under DORA (Art. 18 and 19), customer contract notification clauses, and the cyber insurance policy's notice condition. Anything other than "no" goes to the reporting clock step at once.
List the evidence to keep before anyone fixes anything: snapshots or images of affected machines before rebuild, logs that will roll over (check retention, some keep only days), mailbox audit records, cloud audit trails, the original phishing message with headers. Containment that destroys evidence is a decision for the incident lead, recorded with the reason.
Step 5: keep the record running
Append each new fact, decision and who made it, with a UTC time. Re-triage at least every few hours during a SEV1 or SEV2, and whenever scope changes. Record each downgrade with its reason. Write the record for its later readers too: for a personal data breach it feeds the breach documentation a controller keeps (GDPR Art. 33(5)) and the post-incident review. If the provisional scale was used, close the record with a note for the plan owner to create or reconcile the company's severity scale.
What good looks like
- The record opens with the awareness time, the severity with its one-line reason, and the clock flags. A reader joining late understands the state in one minute.
- A strong practitioner asks "is personal data involved" and "is the attacker still in" before anything else; those two answers change the call list and the clocks.
- The common mistake is triaging by technical interest: a clever exploit on a test server becomes SEV1 while a spreadsheet of customer data emailed to the wrong person sits at SEV3.
- The tell that it went wrong: no awareness timestamp, no regulatory line, logs already overwritten, and a severity never revisited after the first hour.
Framework lookups
If ISMS Copilot is connected to your agent (MCP server https://account.ismscopilot.com/v1/account/mcp), ask it the framework question with create_conversation (mode think, answer_format: decision) and keep one conversation for this task. Send only a short question in your own words, show it to the user first, and never include file contents, secrets, personal data or evidence. If it is not connected, check the official text of the framework yourself; this skill does not restate it. Set it up: https://www.ismscopilot.com/mcp?ref=grcskills-incident-severity-triage
Rules
- MUST record detection and awareness times in UTC before anything else.
- MUST give a one-line reason for every severity and every downgrade.
- MUST write outputs only inside
./incident-severity-triage/ and ask before overwriting.
- NEVER contain, delete, rebuild, block or shut down anything; propose it to the incident lead.
- NEVER page, message or notify anyone, inside or outside the company, on the reader's behalf.
- NEVER copy credentials, personal data or customer records into the triage record; describe them by type and count.