Incident Severity & Priority
What is it?
Severity measures how bad the incident is (assets affected, data at risk, business impact). Priority measures what gets attention first. They usually align — but a lower-severity incident on a time-critical system can outrank a higher-severity one on an idle system.
Why it matters
Severity drives who gets woken up and what gets reported upward; getting it wrong in either direction has real cost.
Where you see it
The severity field on every incident ticket, and the escalation matrix that maps severities to who must be told, how fast.
What normal looks like
Severity assigned from defined criteria — asset criticality, data classification, spread — and revised when evidence changes it, with the revision recorded.
What suspicious looks like
Every incident rated 'medium' by habit, or a severity that never changed even as scope tripled.
How analysts investigate
By tying severity to named facts — which asset, which data, how far spread — so anyone reading the ticket can re-derive the rating from evidence.
Common beginner mistakes
- Rating severity by how dramatic the alert LOOKS rather than what the affected asset actually holds — a noisy alert on a kiosk is not a quiet one on the payment database.
Two incidents open at Marasi within an hour: ransomware notes on an idle test server, and quiet unauthorized queries against the shipment-tracking database that customers use all day. Which is more severe — and which comes first?
Quick check
In the Marasi example, why can the database incident outrank the ransomware incident in priority?
A quick self-check — it doesn't affect your XP or progress.
Sign in to save your progress on the server.