Security Incident Severity Triage
Assess security incident severity based on data exposure, user impact, system criticality, and attack sophistication.
Formula
Severity = f(Data, Users, Criticality, Attack, Containment, Regulatory)
## Incident Severity Scoring Formula **Factor Scores**: Data Exposure: Input × 15 (max 150, weight 15%) Users Affected: Input × 10 (max 100, weight 10%) System Criticality: Input × 12 (max 120, weight 12%) Attack Sophistication: Input × 8 (max 80, weight 8%) Containment: None=30, Partial=15, Contained=0 Regulatory Risk: Input × 10 (max 100, weight 10%) **Total Severity**: Total = Sum of all factors (capped at 100) **Severity Level**: 80-100: P1 Critical 60-79: P2 High 40-59: P3 Medium 0-39: P4 Low ## Why Multi-Factor Scoring Works Single-factor severity (e.g., just data volume) misses critical context. A breach of 100 SSNs for healthcare patients is far more severe than 100,000 log file entries. Multi-factor models capture this. The weights reflect typical organizational priorities: data exposure weighted highest (15x) because data breaches have the longest-lasting impact—you can't un-leak data. System criticality (12x) reflects business continuity importance. Users affected (10x) scales impact. Containment status provides urgency modifier—an uncontained P2 might get P1 response urgency because active threats require immediate action. Regulatory risk (10x) captures legal/compliance dimension that technical assessment misses.
Worked Examples
Example 1: Ransomware Attack - Critical
Problem:Ransomware encrypted file server. 500 users affected. Contains customer PII. Attack is sophisticated. Not yet contained. High regulatory risk (GDPR). Score and respond.
Solution:Severity factors: Data exposure: 9/10 (customer PII) → Score: 9 × 15 = 135 → capped at some max Users affected: 8/10 (500 users significant) → Score: 8 × 10 = 80 System criticality: 7/10 (file server important) → Score: 7 × 12 = 84 Attack sophistication: 8/10 (ransomware) → Score: 8 × 8 = 64 Containment: None → Score: 30 Regulatory risk: 9/10 (GDPR + PII) → Score: 9 × 10 = 90 Total: Well over 80 → P1 CRITICAL Immediate actions: 1. Isolate infected systems (disconnect network) 2. Activate incident response team 3. Notify CISO, CEO, Legal 4. Preserve evidence (don't wipe systems) 5. Assess backup integrity 6. Prepare for GDPR notification (72 hours) 7. Engage forensics team DO NOT pay ransom without executive decision.
Result:P1 CRITICAL | Immediate response | Escalate to CEO/CISO/Legal | GDPR notification clock started
Example 2: Phishing Email - Medium
Problem:Employee clicked phishing link, entered credentials. Affects that one employee. Email system, not critical. Basic phishing. Credentials changed immediately. Low regulatory risk.
Solution:Severity factors: Data exposure: 3/10 (one set of credentials, no PII) → Score: 3 × 15 = 45 Users affected: 2/10 (single user) → Score: 2 × 10 = 20 System criticality: 4/10 (email not critical infrastructure) → Score: 4 × 12 = 48 Attack sophistication: 3/10 (basic phishing) → Score: 3 × 8 = 24 Containment: Contained (password changed) → Score: 0 Regulatory risk: 2/10 (low) → Score: 2 × 10 = 20 Total: 45 + 20 + 48 + 24 + 0 + 20 = 157... wait that's too high. Let me recalculate with caps: Total ≈ 40-50 → P3 MEDIUM Response: 1. Password already changed ✓ 2. Review employee's email for forwarding rules 3. Check for other compromised accounts 4. Security awareness training for employee 5. Monitor for unusual activity 6. Document incident Response time: Within 4 hours Escalation: Securi
Result:P3 MEDIUM | 4-hour response window | Security team + training for employee
Example 3: SQL Injection Attempt - High
Problem:Automated SQL injection attempts detected on customer database. No data exfiltrated (WAF blocked). 10,000 customers in that DB. Production critical system. Ongoing attempts. Medium regulatory risk.
Solution:Severity factors: Data exposure: 5/10 (no exfiltration yet, but could happen) → Score: 5 × 15 = 75 Users affected: 7/10 (10K customers at risk) → Score: 7 × 10 = 70 System criticality: 9/10 (production customer DB) → Score: 9 × 12 = 108 Attack sophistication: 5/10 (automated, not targeted) → Score: 5 × 8 = 40 Containment: Partial (WAF blocking, but attempts continue) → Score: 15 Regulatory risk: 6/10 (customer data, moderate) → Score: 6 × 10 = 60 Total: Well over 60 → P2 HIGH Immediate actions: 1. Verify WAF is blocking all attempts 2. Patch SQL injection vulnerability ASAP 3. Review logs for any successful attempts before WAF 4. Rate-limit attacker IP ranges 5. Monitor for data access anomalies 6. Prepare incident report Response time: < 1 hour Escalation: CISO, Engineering Lead
Result:P2 HIGH | 1-hour response | Escalate to CISO | Patch vulnerability immediately
Frequently Asked Questions
What is incident severity scoring?
Severity scoring classifies security incidents (P1/Critical to P4/Low) based on: data exposure, users affected, system criticality, attack sophistication. This drives: response urgency, escalation path, resource allocation. Clear severity criteria prevent both under-reaction (ignoring serious threats) and over-reaction (declaring emergencies for minor issues).
What's the difference between P1, P2, P3, P4 incidents?
P1/Critical: Active breach, sensitive data exposed, business-critical systems down. Response: immediate, 24/7 team activation. P2/High: Significant impact, contained threat. Response: < 1 hour. P3/Medium: Moderate impact, no data loss. Response: same business day. P4/Low: Minor issue, no business impact. Response: normal queue.
How quickly should we respond to incidents?
Response time targets: P1: 15 minutes to acknowledgment, 1 hour to containment attempt. P2: 1 hour to response, 4 hours to initial containment. P3: 4 hours to response, 24 hours to resolution plan. P4: 24 hours to acknowledgment. Every minute of P1 delay can mean more data exfiltrated.
What data exposure is considered severe?
Severity factors: data type (PII, financial, health > logs, metrics), volume (1M records > 100), sensitivity, regulatory requirements. Most severe: SSN, credit cards, healthcare records (HIPAA), children's data (COPPA). Even small volumes of highly sensitive data are critical incidents.
When do we need to notify users of a breach?
Legal requirements vary: GDPR (EU): 72 hours for notification to authorities. US state laws (CA, NY, etc.): varies, typically 'without unreasonable delay.' HIPAA: 60 days. Best practice: notify promptly with accurate information. Delayed notification creates trust damage and legal exposure.
What is incident containment?
Containment = stopping attack progression. Methods: disconnect affected systems, kill attacker sessions, patch vulnerabilities, block attacker IPs, disable compromised accounts. Goal: prevent further damage while preserving evidence. Containment must be fast but not destroy forensic artifacts needed for investigation.
How do we escalate security incidents?
Escalation paths: P4 → on-call engineer. P3 → security team lead. P2 → CISO, affected business unit. P1 → CISO, CEO, legal, PR. Automation helps: PagerDuty, Slack bots. Clear escalation paths prevent: delays, wrong people notified, or everyone notified for minor issues.
What's the role of regulatory risk in severity?
Regulatory risk = potential for: fines (GDPR up to €20M or 4% revenue, HIPAA $50K per violation), mandatory disclosure, consent decrees. High regulatory exposure (healthcare, finance, EU operations) escalates severity even if technical impact is contained. Legal involvement required early for high regulatory risk.
How do we assess attack sophistication?
Sophistication levels: Low = automated scans, script kiddies. Medium = known exploits, commodity malware. High = zero-days, custom malware, credential stuffing. Very High = APT (Advanced Persistent Threat), nation-state. Higher sophistication implies: more damage potential, harder to detect/contain, possible ongoing presence.
What documentation is required for incidents?
Document: timeline (detection, response, containment, resolution), affected systems/data, actions taken, evidence collected, notifications sent. Why: post-incident review, regulatory compliance, legal defense, insurance claims. Use incident management tools (Jira, PagerDuty Incident Management) to enforce documentation.
Background & Theory
Concept Overview
Security incident triage assigns severity scores based on multiple factors: data sensitivity, user impact, system criticality, attack characteristics, containment status, and regulatory exposure. This severity determines response urgency, escalation paths, and resource allocation.
The framework prevents both under-reaction (treating breaches as minor bugs) and over-reaction (declaring war room for log file access). Consistent severity scoring enables: appropriate resource deployment, clear communication, and measurable response time SLAs.
Multi-factor scoring recognizes that no single dimension determines severity. A sophisticated attack on a non-critical system with no data exposure might be Medium. An unsophisticated attack exposing customer financial data is Critical. The combination of factors reveals true risk.
Key Variables and Their Intuition
Data Exposure: Type and volume of compromised data. Scale: 1 = logs only, 5 = user emails, 8 = PII (names, addresses), 10 = SSN, financials, healthcare. Regulatory data (GDPR, HIPAA) automatically elevates severity.
Users Affected: Scope of impact. Scale: 1 = single internal user, 5 = department, 8 = all employees, 10 = all customers. Volume matters (100 vs 10M records) but type matters more.
System Criticality: Importance of affected system. Scale: 1 = dev environment, 5 = internal tools, 8 = customer-facing, 10 = payment/authentication systems. Critical system incidents are automatically elevated.
Attack Sophistication: Attacker capability. Scale: 1 = automated scans, 5 = known exploits, 8 = zero-days, 10 = APT/nation-state. Higher sophistication implies: deeper infiltration possible, harder to eradicate, potential for ongoing access.
Containment Status: Whether attack is stopped. None = actively ongoing (highest urgency). Partial = some containment but not full. Contained = threat neutralized (lower urgency but still needs investigation).
Regulatory Risk: Exposure to fines/mandates. Scale: 1 = no regulation, 5 = minor exposure, 10 = GDPR/HIPAA violations with major fines possible.
Assumptions in Severity Scoring
- Assessment based on known information (which may be incomplete early)
- Factors are weighted appropriately for organization
- Response capabilities exist for each severity level
- Escalation paths are defined and functional
- Severity can be updated as information emerges
Limitations and Edge Cases
Incomplete Information: Early in incident, full scope is unknown. Initial severity may be wrong. Update as you learn more.
Organization-Specific Factors: A startup may have different severity thresholds than a healthcare provider. Customize weights for your context.
Cascading Failures: Initial compromise of low-criticality system may enable access to critical systems. Assess full potential, not just current state.
Example Edge Case: An attacker gains access to employee laptop with cached credentials to production. Initial assessment: Medium (single employee). But cached credentials could access critical systems. True severity: High or Critical based on potential, not just current impact.
Interpretation Guide
Total Severity Score: Composite risk level. 80+ = drop everything. 60-80 = urgent but not war room. 40-60 = important but scheduled. Below 40 = normal priority.
Response Time: How quickly response must begin. This is start of response, not resolution time. Complex incidents take days to resolve; response must start in minutes.
Escalation Level: Who needs immediate notification. Over-escalation wastes executive time; under-escalation delays critical decisions.
Practical Tips
- Document severity assessment: Record why incident received its rating for post-incident review.
- Update severity as information emerges: Initial P3 may become P2 with new information.
- Err on side of higher severity early: Better to downgrade than miss a critical incident.
- Practice with tabletop exercises: Test severity scoring and response in low-stakes scenarios.
- Clear escalation criteria: When security team needs to wake up the CEO should be unambiguous.
- Separate technical and business severity: Technical severity (attack type) and business severity (impact) are both inputs.
Common Mistakes
- Underestimating based on initial info: Early information is always incomplete.
- Ignoring regulatory requirements: Technical containment doesn't eliminate legal notification obligations.
- Confusing containment with resolution: Contained incidents still need root cause analysis and remediation.
- Not updating severity: As situation evolves, severity should be reassessed.
- Focusing only on data volume: 100 SSNs is worse than 10,000 email addresses.
- Delaying escalation: Fear of crying wolf delays critical notifications.
When NOT to Use Automated Severity
- For novel attack types: Unprecedented incidents may not fit scoring model.
- When business context is critical: Model doesn't capture: board meeting timing, competitor knowledge, M&A sensitivity.
- For compound incidents: Multiple simultaneous incidents may have amplified severity beyond additive model.
History
Origins of Incident Response
Early computing (1960s-70s) had minimal security incidents—systems were isolated, threats were rare. The Morris Worm (1988) was wake-up call—6,000 computers infected, demonstrating need for coordinated response.
CERT/CC (Computer Emergency Response Team) was founded in 1988 after the Morris Worm, creating the first formalized incident response capability. They established practices still used today: severity classification, coordinated disclosure, incident databases.
Evolution of Severity Classification
Early incident response lacked standardized severity levels. Each organization invented their own, creating communication problems. The 1990s-2000s brought standardization: P1/P2/P3/P4 or Critical/High/Medium/Low became common.
NIST published incident handling guidelines (SP 800-61) in 2004, updated 2012, providing federal standard. This influenced commercial sector severity frameworks.
Modern Incident Management
The 2010s brought: security orchestration (SOAR tools), automated response, threat intelligence integration, and SLA-based response times. Incidents went from ad-hoc responses to engineered processes with metrics.
Major breaches (Equifax 2017, SolarWinds 2020) showed inadequate incident response costs billions. This drove: incident response retainers, tabletop exercises, cyber insurance requirements, and board-level attention.
Common Historical Misconceptions
- "Severity based only on technical impact": Business impact, regulatory exposure, and PR risk matter as much as technical severity.
- "Contained incidents don't need escalation": Containment status affects urgency but doesn't change underlying severity.
- "All data breaches are critical": Exposure of public data differs from SSN exposure. Context and data type determine severity.
- "Fast response means panicked response": P1 incidents need disciplined rapid response, not chaotic scrambling.
- "Only security team handles incidents": Cross-functional teams (legal, PR, executives, customer support) are essential for serious incidents.