The information security manager is defining severity levels for the incident classification scheme. What should PRIMARILY determine an incident's severity?

Incident severity exists to drive prioritization, escalation and resource allocation, so it should reflect what matters to the organization: the actual or potential impact on critical business operations, the sensitivity and volume of data affected, and legal, regulatory and contractual obligations that may be triggered. Severity levels defined in terms of business impact ensure that the most consequential incidents receive the fastest response and the right level of management attention. The technical sophistication of an attack is useful for analysis and threat intelligence, but a sophisticated attack on a low-value system may matter less than a simple one on a critical system. The number of alerts reflects how the monitoring tools are tuned and how noisy an attack is, not how much harm it causes. Expected analyst effort describes workload, which is relevant to resourcing but does not indicate how important the incident is to the business. Exam caveat: severity is reassessed as an investigation reveals more about scope and impact, so the initial rating is provisional. Operational check: confirm each severity level in the scheme is defined by impact criteria that the business has approved and that each level maps to response times and escalation paths.