CS0-003 Incident Response and Management Practice Question
An organization's incident response team is classifying an incident based on severity and priority. Which TWO factors should the team consider when determining the priority of an incident? (Select TWO.)
⚠ Common exam trap
CS0-004 often tests the confusion between severity (technical) and priority (business) — candidates pick volume or threat-actor factors when the question asks for business-impact and asset-criticality drivers.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The potential business impact of the incident.
Option B is correct because incident priority is driven primarily by the potential business impact — how severely the incident could disrupt operations, revenue, reputation, or regulatory obligations — which determines how urgently the response must be escalated. Option C is correct because the criticality of the affected systems or data (for example, a domain controller, PII database, or payment processing system) directly shapes priority, since a compromise of high-value assets warrants faster and more aggressive response than one on a low-value endpoint. Together, business impact and asset criticality are the standard inputs for priority scoring in frameworks such as NIST SP 800-61, which separates severity (technical impact) from priority (business-driven urgency). Option A is not a priority factor per se; the number of users reporting an issue may indicate scope but does not by itself establish business urgency. Option D is not a defining factor, since time of day may affect staffing but not the inherent priority of the incident. Option E is also not a priority determinant; the type of threat actor is relevant to threat intelligence and attribution, not to how urgently the business must respond.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The number of users reporting the issue.
Why it's wrong here
The number of users reporting the issue is a symptom of scope, not a determinant of priority. User reports can be sparse or duplicated, and a single incident affecting a highly privileged account can be far more urgent than a large number of low-impact user complaints. Priority classification should derive from the incident's potential impact, asset criticality, and urgency, not from the volume of helpdesk tickets.
- ✓
The potential business impact of the incident.
Why this is correct
The potential business impact of an incident drives its priority because the goal of incident management is to minimize harm to the organization. Impact includes financial loss, operational disruption, regulatory fines, reputational damage, and customer trust. A high-impact incident, such as a ransomware attack on a core revenue system, necessitates immediate escalation regardless of other factors.
- ✓
The criticality of the affected systems or data.
Why this is correct
System and data criticality determines how severely an incident affects the organization if confidentiality, integrity, or availability is compromised. Assets supporting core business processes, sensitive customer data, or regulated information have a higher criticality rating, and incidents involving them are automatically prioritized above those affecting nonessential systems. This asset-based measure provides an objective foundation for triage decisions.
- ✗
The time of day the incident occurred.
Why it's wrong here
The time of day an incident occurs has no bearing on its priority classification because the clock does not change the underlying impact or criticality. Whether ransomware strikes at 3 a.m. or 3 p.m., the damage to the organization's operations and data is the same. Time of day may influence response staffing or service-level agreements, but it is not a classification criterion for priority.
- ✗
The type of threat actor involved.
Why it's wrong here
The type of threat actor involved is useful for threat intelligence and response strategy, but it does not directly define the priority of an incident. An unsophisticated attacker can still cause severe business damage through stolen credentials, while a nation-state reconnaissance scan on a low-value system may warrant routine handling. Priority is predicated on the potential harm to the organization, not the adversary's sophistication.
Go deeper
Related to this question
Learn chapter
Dark Web Monitoring and Threat Feeds
Key term
Threat actor
A threat actor is any person or group that intentionally causes harm to digital systems, networks, or data.
Key term
Asset
In IT and cybersecurity, an asset is anything valuable that an organization owns or controls, including data, hardware, software, people, and intellectual property.
About these practice questions
One of 701 original CS0-004 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CompTIA exam blueprint
This CS0-004 practice question is part of Courseiva's free CompTIA certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CS0-004 exam.