A SOC analyst reviews a ransomware incident. The SIEM shows only four alerts, but the affected file server stores regulated employee records, supports payroll processing, and two additional servers show encryption indicators. The severity matrix weighs data sensitivity, business downtime, and scope. What severity assignment is most appropriate?

A severity matrix in incident response converts observable impact into a consistent escalation decision. Data sensitivity asks whether protected or regulated information is involved; business downtime asks whether a revenue, workforce, or customer-facing process is impaired; scope asks whether the issue is confined to one asset or is spreading. In this case, regulated employee records, payroll disruption, and indicators on multiple servers combine to justify a high severity, even though alert volume is low. An assignment based on alert volume is wrong because noisy telemetry can come from low-value assets or benign misconfigurations, while sparse alerts can accompany sophisticated compromise. An assignment that downgrades the incident because only one file server is encrypted or exfiltration is unconfirmed is also wrong; the matrix already includes scope and sensitivity, and confirmed lateral indicators plus regulated data outweigh the absence of proven exfiltration. An assignment that lowers severity because backups or endpoint isolation exist is wrong as well, because preventive or recovery controls reduce consequence but do not erase the current business impact or data exposure. Exam caveat: severity labels vary by organization, so always apply the documented matrix thresholds and escalation rules. Operational check: record the affected asset’s business owner, data classification, downtime window, and confirmed lateral movement before submitting the incident score.