This chapter covers incident categories and severity classifications, a core topic in the Incident Response domain (Objective 3.1) of the CS0-003 exam. Understanding how to classify incidents by type and severity is critical for prioritizing response efforts, allocating resources, and ensuring compliance. Approximately 10-15% of exam questions touch on incident categorization, severity levels, and escalation procedures. This chapter provides the precise definitions, frameworks, and decision criteria you need to answer those questions correctly.
Jump to a section
Think of a hospital emergency department's triage system. When patients arrive, a triage nurse assesses each patient's condition and assigns a severity category: immediate (life-threatening), urgent (serious but stable), delayed (minor injury), or expectant (likely fatal regardless of care). This categorization determines the order and resources allocated for treatment. Similarly, in incident response, a Security Operations Center (SOC) uses a severity classification scheme to prioritize incidents. The triage nurse uses a standardized set of criteria—vital signs, mechanism of injury, symptoms—to assign the category, just as a SOC analyst uses predefined impact and urgency criteria to assign a severity level. The hospital's disaster plan may have different triage thresholds for a mass casualty event, analogous to an organization's incident response plan adjusting severity definitions during a major security incident. The triage tag (color-coded) is like the incident ticket's severity field, guiding all subsequent actions. Mis-triage—over-triage (calling a minor injury immediate) or under-triage (missing a life-threatening condition)—leads to resource waste or patient death, just as incorrect incident severity leads to wasted effort or missed critical response windows.
What Are Incident Categories and Severity?
Incident categories are high-level groupings of security incidents based on the nature of the threat or the type of attack. Common categories include malware, phishing, denial of service (DoS), unauthorized access, data exfiltration, and insider threats. Severity, in contrast, measures the potential or actual impact of an incident on the organization, typically using a scale (e.g., critical, high, medium, low). Together, categories and severity form the basis for triage, prioritization, and escalation.
Why They Exist
Without standardized categories and severity, every alert would be treated equally, leading to analyst burnout and missed critical incidents. Categories enable SOC teams to route incidents to the right specialists (e.g., malware incidents to reverse engineers, phishing to threat intelligence). Severity ensures that high-impact incidents are addressed before low-impact ones. Regulatory frameworks like PCI DSS and HIPAA require documented incident classification processes.
How Incident Categories Are Defined
Organizations define categories based on the type of threat or attack vector. The CS0-003 exam expects familiarity with common categories:
Malware: Viruses, worms, Trojans, ransomware, spyware.
Phishing: Spear phishing, whaling, smishing, vishing.
Denial of Service (DoS) / Distributed Denial of Service (DDoS): Network or application-layer attacks aiming to disrupt services.
Unauthorized Access: Intrusion attempts, privilege escalation, brute force attacks.
Data Exfiltration: Unauthorized transfer of data outside the organization.
Insider Threat: Malicious or accidental actions by employees or contractors.
Physical Security: Theft, unauthorized physical access, sabotage.
Policy Violation: Violations of acceptable use policies, data handling policies.
Each category may have subcategories. For example, malware can be further classified by type (ransomware, banking trojan, keylogger).
How Severity Is Determined
Severity is typically calculated using two factors: impact and urgency. Impact measures the potential damage (e.g., data loss, system downtime, financial loss, reputational harm). Urgency measures how quickly the incident needs to be resolved to prevent escalation. A common formula:
Severity = Impact × Urgency
Organizations often use a 4-level scale:
Critical (4): Incident causing severe impact, such as a ransomware outbreak encrypting critical servers, active data exfiltration of sensitive data, or compromise of domain controllers. Requires immediate response, often 24/7.
High (3): Incident with significant impact but limited scope, such as a phishing campaign that compromised several user accounts, or a DoS attack affecting a non-critical service. Response within hours.
Medium (2): Incident with moderate impact, such as a single workstation infected with malware, or a policy violation by a low-privilege user. Response within 24 hours.
Low (1): Incidents with minimal impact, such as a false positive alert, or a single failed login attempt. Response within days or via normal queue.
Step-by-Step Severity Classification Process
Detection: The incident is detected via an alert from a SIEM, EDR, IDS/IPS, or user report.
Initial Triage: The SOC analyst reviews the alert to determine if it is a true positive. If false positive, it is closed. If true positive, they proceed.
Category Assignment: The analyst assigns the incident to one or more categories based on the nature of the attack. For example, an email with a malicious attachment is both 'phishing' and 'malware'.
Impact Assessment: The analyst determines the scope of affected systems, data sensitivity, and business impact. They may use predefined criteria such as:
- Number of affected users or systems - Criticality of affected systems (e.g., domain controller, database server, web server) - Type of data involved (PII, PHI, financial data, intellectual property) - Regulatory implications 5. Urgency Assessment: The analyst evaluates the speed of propagation, whether the attack is ongoing, and the potential for escalation. For example, a worm spreading across the network has high urgency; a dormant backdoor has lower urgency. 6. Severity Calculation: Using a matrix or automated tool, the analyst combines impact and urgency to assign a severity level. Many SIEMs have built-in severity scoring. 7. Escalation: Based on severity, the incident is escalated to the appropriate response team. Critical incidents may require immediate notification of the CISO, legal team, and executive management.
Key Components: Incident Response Plan and SLAs
The incident response plan should define:
Categories and severity definitions
Response times (SLA) per severity level
Escalation paths and notification lists
Roles and responsibilities per severity
Example SLAs:
Critical: Response within 15 minutes, 24/7, containment within 1 hour.
High: Response within 1 hour (business hours), containment within 4 hours.
Medium: Response within 4 hours, containment within 24 hours.
Low: Response within 24 hours, containment within 72 hours.
Common Frameworks and Standards
NIST SP 800-61 Rev. 2: Provides guidance on incident handling, including classification. It suggests categories but does not mandate specific ones.
FIRST CVSS: The Common Vulnerability Scoring System is sometimes adapted for incident severity, though it is designed for vulnerability severity.
ISO/IEC 27035: Information security incident management standard.
MITRE ATT&CK: While primarily a knowledge base of adversary tactics and techniques, it can be used to categorize incidents by technique ID.
How Categories and Severity Interact with Other IR Processes
Triage: Initial triage uses categories to route to the right analyst.
Containment: Severity determines containment strategy—critical incidents may require immediate network isolation, while low severity may be contained with a patch.
Eradication and Recovery: High severity incidents may require a full rebuild, while low severity may be cleaned.
Post-Incident Activity: Lessons learned often include reviews of categorization accuracy and severity scoring.
Trap Patterns on the Exam
Confusing severity with priority: Severity is determined by impact and urgency; priority is a combination of severity and other factors like resource availability. On the exam, they are often used interchangeably, but technically severity is objective, priority is subjective.
Assuming one category per incident: An incident can belong to multiple categories (e.g., a phishing email delivering ransomware). The exam may ask which categories apply.
Misidentifying severity based on category alone: Not all malware is critical. A single low-impact malware on a test system may be medium or low severity, while a ransomware outbreak is critical. Always consider context.
Ignoring regulatory impact: Incidents involving PII or PHI automatically increase severity due to legal and reporting requirements.
Verification Commands and Tools
While categories and severity are conceptual, SOC analysts use tools to document them: - SIEM: Splunk, ELK, QRadar allow custom severity fields and alert rules based on categories. - Ticketing Systems: ServiceNow, Jira Service Management have fields for category and severity. - SOAR: Platforms like Palo Alto Cortex XSOAR automate severity assignment based on playbooks.
Example of a SIEM query to categorize incidents by severity:
index=security sourcetype=alerts severity=critical
| stats count by categorySummary of Key Values
Typical severity levels: Critical (4), High (3), Medium (2), Low (1)
Common categories: Malware, Phishing, DoS/DDoS, Unauthorized Access, Data Exfiltration, Insider Threat, Physical Security, Policy Violation
Response times vary but typical SLAs for critical: 15-30 minutes initial response
This understanding is essential for the CS0-003 exam and for real-world incident response.
Initial Detection and Alerting
The incident is first detected through automated tools (SIEM, EDR, IDS/IPS) or manual reports from users. The detection system generates an alert with initial metadata such as source IP, destination IP, timestamp, and a preliminary category based on signature or anomaly. For example, an EDR may detect a process spawning cmd.exe from an Office application and categorize it as 'malware'. The alert is assigned an initial severity based on default rules, but this is often overridden during triage. The analyst must verify the alert is a true positive before proceeding.
Triage and Verification
The SOC analyst reviews the alert to confirm it is a genuine security incident. They examine raw logs, packet captures, or endpoint data to rule out false positives. For example, a failed login alert may be due to a user forgetting a password, not a brute force attack. The analyst also checks the context: is the affected system a critical server or a test VM? During triage, the analyst may re-categorize the incident if the initial category was incorrect. This step is crucial because mis-categorization leads to improper routing and delayed response.
Category Assignment
Once verified, the analyst assigns the incident to one or more categories from the organization's predefined list. Categories should align with the type of threat: malware, phishing, DoS, unauthorized access, data exfiltration, insider threat, physical security, or policy violation. For complex incidents, multiple categories may apply. For example, a spear-phishing email that installs ransomware would be categorized as both 'phishing' and 'malware'. The category determines which response playbook to use and which team to notify (e.g., phishing team, malware reverse engineers).
Impact and Urgency Assessment
The analyst evaluates the potential and actual impact of the incident. Impact criteria include: number of affected systems, criticality of systems (e.g., domain controller, financial database), type of data involved (PII, PHI, proprietary), and business disruption. Urgency is assessed by the speed of propagation, whether the attack is ongoing, and the likelihood of escalation. For example, a worm spreading rapidly has high urgency; a static backdoor has low urgency. The analyst may use a scoring matrix where each factor contributes points. Typical thresholds: if any system is critical and data is sensitive, impact is at least high.
Severity Assignment and Escalation
Based on the impact and urgency assessment, the analyst assigns a severity level: Critical, High, Medium, or Low. Many organizations use a formula: Severity = Impact × Urgency. For example, high impact + high urgency = critical. The severity determines the response SLA and escalation path. Critical incidents trigger immediate notification of the incident response team, CISO, legal, and possibly executive management. The incident ticket is updated with the severity, and automated playbooks may initiate containment actions (e.g., blocking an IP, isolating a host).
In a large financial institution, the SOC handles thousands of alerts daily. They use a custom severity matrix: Impact is scored 1-5 based on asset criticality (5 for core banking systems, 1 for employee workstations) and data sensitivity (5 for PII/PCI, 1 for public data). Urgency is scored 1-5 based on attack stage (5 for active lateral movement, 1 for a single failed login). Severity = Impact × Urgency, with thresholds: 1-5 Low, 6-10 Medium, 11-15 High, 16-25 Critical. This ensures that a compromised domain controller (impact 5) with active data exfiltration (urgency 5) is critical (25), while a malware alert on a test server (impact 1) with no propagation (urgency 1) is low (1).
Another scenario: a healthcare provider uses categories mandated by HIPAA: 'Unauthorized Access/Disclosure' for any PHI breach, 'Malware' for ransomware, 'Physical Theft' for stolen devices. Severity is based on number of patients affected: <100 = Low, 100-500 = Medium, >500 = High, and any breach requiring notification to OCR (Office for Civil Rights) is automatically Critical. They have SLAs: Critical incidents must be reported to the Privacy Officer within 1 hour, and containment must begin within 30 minutes.
A common misconfiguration is setting severity thresholds too low, causing alert fatigue. For example, a company set 'any alert from a domain controller' to Critical, but the domain controller generated many benign alerts (e.g., account lockouts). The SOC was overwhelmed, leading to missed real critical incidents. The fix was to adjust the severity calculation to include context like 'number of failed logins > 100 in 5 minutes' before assigning Critical.
Performance considerations: Automated severity assignment must be tuned to avoid false positives. A SIEM rule that flags any PowerShell execution as 'malware' and severity 'High' would flood the SOC. Instead, use behavioral thresholds: PowerShell spawning from Office with network connection = High, standalone PowerShell = Low. Also, consider the volume: during a DDoS attack, thousands of alerts may be generated. The severity assignment should de-duplicate and aggregate to avoid ticket overload.
The CS0-003 exam tests incident categories and severity under Objective 3.1: 'Given a scenario, classify incidents based on category and severity.' You must be able to identify the correct category for a described incident and assign the appropriate severity level based on given impact and urgency factors.
Common wrong answers: 1. Confusing 'phishing' with 'malware': A phishing email that contains a link to a credential harvesting page is still 'phishing', not 'malware', because no malicious code is executed on the endpoint. The exam may describe a user clicking a link and entering credentials; the category is phishing (or credential harvesting), not malware. 2. Assigning severity based solely on category: For example, assuming all ransomware incidents are Critical. But if the ransomware only encrypts a non-critical test server with no backups, the severity may be Medium. The exam expects you to consider impact and urgency, not just the attack type. 3. Missing multiple categories: A scenario where an insider steals data via USB and then exfiltrates it via email. The categories are 'insider threat' and 'data exfiltration'. The exam may ask 'which categories apply?' and include only one as a distractor. 4. Ignoring regulatory requirements: An incident involving PII should automatically increase severity due to legal reporting obligations. The exam may present a scenario where the same attack on a system without PII is Medium, but with PII it becomes High or Critical.
Specific numbers: The exam does not require memorizing exact SLA times, but you should know typical relative values: critical incidents get immediate response, high within hours, medium within 24 hours, low within days. Also, the 4-level scale (Critical, High, Medium, Low) is standard.
Edge cases: Incidents that are not easily categorized, such as a 'misconfiguration' that exposes data. The category might be 'policy violation' or 'unauthorized access' depending on intent. The exam may test that a misconfiguration is not an 'attack' but a 'vulnerability' — categories are for incidents that have occurred.
How to eliminate wrong answers: For category questions, ask: 'What is the primary attack vector?' If it's social engineering, it's phishing; if it's code execution, it's malware; if it's network flooding, it's DoS. For severity, ask: 'What is the worst possible outcome?' and 'How fast is it spreading?' If the answer says 'Low severity' but the scenario includes data exfiltration of customer data, it's likely wrong because impact is high.
Incident categories group incidents by attack type: Malware, Phishing, DoS, Unauthorized Access, Data Exfiltration, Insider Threat, Physical Security, Policy Violation.
Severity is calculated from impact and urgency, typically on a 4-level scale: Critical, High, Medium, Low.
An incident can belong to multiple categories; the exam expects you to select all that apply.
Severity is not determined by category alone; context (affected systems, data, spread) is critical.
Regulatory requirements (PII, PHI) automatically increase severity due to legal obligations.
Common wrong answer: confusing severity with priority; severity is objective, priority is subjective.
Common exam trap: assigning Critical to all ransomware; always evaluate impact and urgency first.
SLAs are tied to severity: Critical immediate, High within hours, Medium within 24 hours, Low within days.
Incident categories and severity are documented in the incident response plan and used for escalation.
Re-assess severity as the incident evolves; initial severity may change.
These come up on the exam all the time. Here's how to tell them apart.
NIST SP 800-61 Incident Categories
Defines categories: Denial of Service, Malicious Code, Unauthorized Access, Inappropriate Usage, Multiple Component
Focuses on attack vector and impact on systems
Used as a general framework, not prescriptive
Includes 'Multiple Component' for complex incidents
Less granular; subcategories are optional
CompTIA CS0-003 Common Categories
Common categories: Malware, Phishing, DoS/DDoS, Unauthorized Access, Data Exfiltration, Insider Threat, Physical Security, Policy Violation
More granular, especially for social engineering and insider threats
Reflects modern attack landscape (e.g., ransomware, BEC)
Does not include 'Multiple Component' but allows multiple categories per incident
Aligns with SOC workflows and tooling (SIEM categories)
Mistake
Incident severity is the same as priority.
Correct
Severity is based on impact and urgency (objective), while priority includes resource availability and business context (subjective). However, many organizations use them interchangeably. On the exam, treat severity as the technical impact/urgency score, and priority as the order in which incidents are handled.
Mistake
All malware incidents are Critical severity.
Correct
Severity depends on the affected system and data. A malware infection on a single user's workstation with no sensitive data and isolated from critical systems is often Low or Medium. Only malware that spreads rapidly or affects critical infrastructure is Critical.
Mistake
An incident can only belong to one category.
Correct
Incidents often span multiple categories. For example, a phishing email that installs ransomware is both 'phishing' and 'malware'. The exam expects you to recognize when multiple categories apply.
Mistake
Category is determined by the attack technique, not the target.
Correct
While technique matters, the target also influences category. For instance, an attack against physical security (e.g., tailgating) is 'physical security' regardless of whether the attacker uses social engineering. The exam may test that the same technique (e.g., using a USB drop) can be categorized as 'malware' if it contains malicious code or 'physical security' if it's a physical breach.
Mistake
Severity is static and does not change.
Correct
Severity can change as the incident evolves. A Low severity alert about a single failed login can become Critical if further investigation reveals a brute force attack targeting the CEO's account. The exam may test that severity should be reassessed during the incident lifecycle.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The CS0-003 exam expects you to know common categories: Malware, Phishing, Denial of Service (DoS/DDoS), Unauthorized Access, Data Exfiltration, Insider Threat, Physical Security, and Policy Violation. These are not official CompTIA categories but are widely used in SOC environments. The exam may also include subcategories like ransomware under malware. Memorize these eight categories and be able to match a scenario to the correct one(s).
Severity is an objective measure of the impact and urgency of an incident, often based on a predefined matrix. Priority is a subjective ranking that considers severity plus other factors like available resources, business context, and dependencies. For example, a Critical severity incident might be given lower priority if the affected system is a test environment with no business impact. However, many organizations use the terms interchangeably. On the exam, treat severity as the technical impact/urgency score.
Yes. For example, a phishing email that delivers ransomware is both 'phishing' (the delivery method) and 'malware' (the payload). The exam may present a scenario and ask 'Which categories apply?' — you must select all that apply. Do not assume a single category unless the scenario clearly indicates only one attack vector.
The most common scale is a 4-level system: Critical (4), High (3), Medium (2), Low (1). Some organizations use a 5-level scale (adding Informational) but the exam focuses on 4. Critical incidents require immediate action, High within hours, Medium within 24 hours, Low within days. Know these relative response times for the exam.
If an incident involves personally identifiable information (PII), protected health information (PHI), or payment card data (PCI), the severity is automatically elevated due to legal reporting obligations. For example, a data breach involving 500+ patients' PHI under HIPAA is typically Critical, whereas the same breach without PHI might be High. The exam may test that regulatory impact is a factor in severity assignment.
Category describes the type of attack (e.g., malware, phishing), while severity measures the potential damage and urgency. A phishing campaign could be Low severity if it targets only a few users with no sensitive data, or Critical if it targets executives with access to financial systems. The exam expects you to assign severity based on impact and urgency, not just the category.
Yes. Severity can change as more information becomes available. For example, a single failed login (Low) may escalate to a brute force attack (High) if hundreds of attempts are detected. The incident response plan should include periodic reassessment. The exam may test that severity is not static.
You've just covered Incident Categories and Severity — now see how well it sticks with free CS0-003 practice questions. Full explanations included, no account needed.
Done with this chapter?