Severity classification is the decision that shapes every other decision
Most incident response plans are contact lists with a cover page. They say who to call and where the backups are, and they skip the decision that determines whether any of it happens: how bad is this. Without a shared severity scale, that judgement gets made fresh, under stress, by whoever happens to be on deck, and it swings between two expensive failure modes.
The first failure mode is panic. A quarantined piece of adware on one workstation becomes a 2am phone tree, a day of lost work for six people, and a standing reluctance to raise the next alarm. The second is complacency, and it costs far more. A compromised mailbox gets logged as an ordinary IT ticket, worked in business hours, and closed with a password reset, while the attacker keeps the inbox rules and the payment redirect they set up on day one. Both failures share a root cause: nobody agreed in advance what a serious incident looks like, so nobody can recognise one.
A severity matrix fixes this by making classification a lookup rather than a debate. The person who finds the incident matches what they can see against a table, gets a level, and the level carries the response: who gets woken, what happens first, and which external clocks may have started. Classification takes minutes, and every decision after it starts from an agreed footing.
The matrix
The matrix below is a working starting point for a mid-sized Australian business. It is deliberately small. Four levels is enough to separate the incidents that justify waking the owner from the incidents that justify a ticket, and scales with six or more levels collapse in practice because nobody can remember the difference between a three and a four under pressure.
Two reading notes. Classify on what you can see now plus the plausible worst case, because early information is always incomplete and under-classification is the more dangerous error. And treat the external column as a prompt to start the clock or the assessment, because whether each obligation actually applies depends on your regulatory footprint, which a later section unpacks.
| Level | Looks like | First actions | Inform internally | External triggers |
|---|---|---|---|---|
| SEV1 Critical | Ransomware running, confirmed data theft, or admin control lost | Isolate networks, keep machines on, move comms out of band | Owner or CEO, board, legal counsel, full response team | Insurer now; OAIC assessment; ReportCyber; bank if money moved |
| SEV2 High | One compromised mailbox or privileged account; contained server malware | Revoke sessions, disable sign-in, export logs, scope the spread | IT lead plus a named executive | Insurer early; OAIC assessment if personal information is involved |
| SEV3 Moderate | Quarantined workstation malware; phished password with no confirmed use | Capture evidence, reimage, reset credentials, check for reuse | IT manager; summary to management | Usually none; ReportCyber is worthwhile for attempted crime |
| SEV4 Low | Reported phishing, blocked scans, lost encrypted device remotely wiped | Log it, block the sender, tune the control that caught it | Security or IT records it | None |
A starting severity matrix for an Australian business. Tune the examples, names and thresholds to your own systems.
What the levels look like in practice
SEV1 means the business itself is under threat. Ransomware actively encrypting a wholesale distributor's file server. Confirmed exfiltration of a medical clinic's patient records. An attacker holding global administrator on the Microsoft 365 tenant. A conveyancing firm discovering that account details were altered in its outgoing settlement correspondence. The common thread is confirmed, active harm to money, data or control, and the correct response is everything at once: full plan invocation, executive engagement, external help moving within the hour.
SEV2 is a real compromise with a contained blast radius, for the moment. One staff mailbox confirmed compromised in a business email compromise attempt. Malware on a server that the endpoint agent has contained but nobody has explained. A privileged credential known to be phished, with no confirmed use yet. These deserve urgency without the full alarm, and the weight of the work sits on scoping, because SEV2 is where the true level gets discovered. Many SEV1 incidents spend their first day misclassified as SEV2.
SEV3 covers incidents the controls handled where verification remains: a workstation infection quarantined by the endpoint agent, a phished password reset before any use, a contractor account signed in from an odd location with an innocent explanation not yet confirmed. SEV4 is the background noise a healthy program generates: reported phishing, blocked scanning, a lost phone confirmed encrypted and wiped. SEV4 exists so that noise has somewhere to go other than the escalation path, and so the pattern across a quarter of noise stays visible in one register.
The first hour changes with the level
Our field note on the first hour of an incident sets out the discipline in full: isolate machines from the network without powering them off, preserve volatile evidence, start a contemporaneous log, and make the first calls in the right order. That discipline applies in full at SEV1 and SEV2. The level does not change what good first-hour practice is; it changes how much of the machinery you invoke and who is in the room.
At SEV1 the first hour is the whole playbook at once: containment, the internal authority call, the insurer, out-of-band communications, and the pre-agreed decision about whether revenue systems come offline. At SEV2 the first hour is narrower and mostly forensic. Revoke the compromised identity's sessions and refresh tokens, disable sign-in rather than deleting anything, export the sign-in and audit logs before retention ages them out, and scope: inbox rules, newly registered MFA methods, OAuth grants, and anywhere else the account reached, before any password reset announces that you know.
At SEV3 the first hour is evidence capture followed by cleanup: snapshot or image if the machine warrants it, reimage rather than disinfect, reset the affected credential and check where else it was used. At SEV4 the first hour is a register entry. Resist the urge to give minor incidents a miniature crisis response. Each false full-scale alarm makes the next real one easier to dismiss.
The notification clocks run whether you watch them or not
External notification is where classification stops being an internal convenience and becomes a legal matter. The obligations run on their own clocks, several of them short, and most start from the moment you become aware or form a belief, whether or not the response is going well.
Which rows apply depends on what your organisation is. The Notifiable Data Breaches scheme under the Privacy Act 1988 covers most businesses with annual turnover above three million dollars, plus health service providers and some other categories regardless of size. The SOCI Act rows apply only to responsible entities for critical infrastructure assets. CPS 234 applies to APRA-regulated entities such as banks, insurers and superannuation trustees. A card data compromise carries contractual duties to your acquiring bank under PCI DSS. ReportCyber, the Australian Government's cybercrime reporting portal, routes reports to the ACSC and the relevant police force. If you cannot say today which of these regimes cover you, that mapping is worth an afternoon well before an incident makes it urgent.
| Trigger | Notify | Clock |
|---|---|---|
| Suspected eligible data breach of personal information | OAIC and affected individuals | Assess within 30 days; notify as soon as practicable |
| Ransomware or cyber extortion payment made, turnover $3 million or more (or a critical infrastructure asset) | Australian Signals Directorate via ReportCyber | 72 hours after the payment is made |
| Critical infrastructure asset, significant impact (SOCI Act) | ACSC | 12 hours |
| Critical infrastructure asset, other relevant impact (SOCI Act) | ACSC | 72 hours |
| APRA-regulated entity, material information security incident (CPS 234) | APRA | 72 hours |
| Fraudulent payment or diverted invoice | Your bank, then ReportCyber | Immediately; recall chances fade fast |
| Any incident that may trigger your cyber policy | Insurer hotline | Per policy, often before engaging responders |
Notification clocks that commonly apply to Australian businesses. Confirm which regimes cover your organisation.
Preserve the evidence before you fix anything
Evidence preservation at every level rests on the same three habits. Keep compromised machines running and isolated at the network rather than powered off, because memory holds encryption keys, live connections and malware that exists nowhere on disk. Export logs early, because retention windows are short: Entra ID sign-in logs last seven days on the free tier and thirty days with a P1 or P2 licence unless you already ship them elsewhere, and firewall and VPN appliances often hold days. And keep a contemporaneous incident log, in UTC, outside the compromised environment, recording who did what, when, and what they observed.
The incident log earns its keep twice. During the response it is the shared record that stops two responders undoing each other's containment. Afterwards it is the raw material for the insurer's questions, for the assessment the Notifiable Data Breaches scheme may require, and for any later dispute about who knew what and when. A photographed ransom note and a dated log entry outlast anyone's memory of a bad week.
Escalation and downgrade are decisions, and they get logged
A severity level is a working hypothesis. The matrix needs explicit rules for moving between levels and a named owner for the call, because reclassification made casually is how incidents drift into the complacency failure while everyone assumes someone else agreed. The rules that hold up are simple:
- Escalate on confirmed spread: a second compromised account or machine moves the incident up a level
- Escalate on confirmed access to personal information, payment systems or a privileged credential
- Escalate when scoping stalls: if you cannot say what the attacker reached, act as though the answer is worse
- Downgrade only on positive evidence that the feared access did not happen, never on absence of findings
- Record every change of level with the reason and the person who made the call
When to call for outside help
At SEV1, external incident response help should be moving within the first hour, engaged through your insurer's panel where the policy requires it, and through legal counsel where privilege over the findings may matter. At SEV2, the honest trigger is capability. If nobody in-house can read the sign-in logs, enumerate the inbox rules and OAuth grants, and say with confidence how far the attacker reached, then scoping is the thing to buy, because every other decision depends on it. Help at SEV2 is cheap compared with discovering in week three that a mailbox compromise was a foothold.
The matrix on this page is the generic shape. The version that works is tuned to your business: your actual crown-jewel systems named at SEV1, your actual regulatory rows in the notification table, your actual on-call reality in the internal column, and thresholds rehearsed until classification is boring. Building that version, rehearsing it, and standing behind it during a live incident is the work Black Shard does in incident readiness and vCISO engagements. What a public note can give you is the test: pick three plausible incidents tonight, ask two colleagues to classify them independently against your current plan, and see whether the answers match. If they do not, you have found a matrix-shaped gap while it is still cheap. This note is general information rather than legal advice; take counsel on your organisation's specific obligations.
