An analyst finds a workstation infected with a commodity infostealer. EDR shows the host held customer PII, but no malware family known to be highly destructive is present. The business owner says this data supports regulated customer onboarding. What should primarily drive incident severity classification?
Select an answer to reveal the explanation.
Short Explanation
Think of severity like triage in an ER: the wound matters more than the tool that cut you. You classify this incident by the customer PII and regulated onboarding exposure, not the commodity infostealer's scary name. The malware family may shape containment, but data impact drives severity.
Full Explanation
In incident response, severity is assigned by the potential harm to the business, so a commodity infostealer that touches regulated customer onboarding data can be high severity even when the malware family is not particularly destructive. The mechanism is data-centric impact: identify the asset, the data category, regulatory obligations, and business function, then set severity based on confidentiality, integrity, availability, and legal exposure. The malware family's destructive capability is a technical indicator that can raise risk, but it does not replace the business impact of PII exposure. The number of endpoints reporting the same hash helps establish blast radius and containment scope, yet a wide hash match without sensitive data impact should not outrank regulated PII exposure. An approved antivirus exception is a control-hygiene or false-positive clue, not a determinant of incident severity; it may explain why detection lagged, but it does not define the harm. Exam caveat: choose the factor that maps to business and data impact, not malware classification or telemetry volume. Operational check: document the affected data classification, regulatory requirement, and business owner before assigning the incident severity tier.