Security should not own them alone. The right decision often needs security, product, legal, compliance, and trust and safety input because the risk may be regulatory, reputational, or customer-facing rather than purely technical. Shared ownership keeps severity aligned to actual operational harm and accountability.
Why This Matters for Security Teams
ai safety severity is not just a technical label. In regulated environments, it can determine whether an issue becomes a disclosure event, a product hold, a policy exception, or a customer escalation. That means the decision has to reflect legal exposure, safety impact, privacy risk, and operational context, not only model behaviour. Guidance from the NIST Cybersecurity Framework 2.0 reinforces the need to align governance, risk, and response activities rather than treating them as separate silos.
The common mistake is letting security severity categories stand in for broader safety governance. That works for a vulnerability ticket, but it breaks down when the AI system can generate harmful output, influence decisions, or interact with customers under regulatory scrutiny. Product teams understand intended use, legal teams understand obligations, compliance teams understand reportability, and trust and safety teams understand user harm patterns. Security still matters, but it should not define the entire impact model alone. In practice, many security teams encounter the real severity of an AI issue only after a customer complaint, regulator question, or incident review has already forced a wider escalation.
How It Works in Practice
Effective severity ownership starts with a documented decision model. Best practice is to define who assesses technical risk, who judges business and regulatory impact, and who has authority to approve the final severity. That usually means security leads the intake and evidence gathering, while product, legal, compliance, and trust and safety participate in triage for anything that could affect protected groups, consumer outcomes, or regulated workflows. The decision should be recorded with the rationale, not just the label.
A practical workflow often includes:
- Initial classification by security or AI operations based on exploitability, exposure, and system criticality.
- Impact review by product and trust and safety to assess user harm, misuse potential, and edge-case behaviour.
- Legal and compliance review where the issue may trigger reporting duties, contractual obligations, or policy breaches.
- Final severity approval by a designated owner group, with escalation rules for disagreement.
For control mapping, this kind of governance fits naturally with NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where accountability, incident handling, and risk assessment need to be formalised. It also aligns with the operational logic of regulated AI programmes: severity should drive a response path, not just a ticket priority. The strongest implementations use a severity rubric that separates technical severity from harm severity, then require sign-off when those two differ. These controls tend to break down when AI ownership is fragmented across regions or product lines because no single group can consistently interpret the same harm in the same way.
Common Variations and Edge Cases
Tighter governance often increases review time, requiring organisations to balance fast remediation against the need for accountable, defensible decisions. That tradeoff becomes sharper in regulated environments where a low-latency fix may still need legal or compliance approval before release. Current guidance suggests there is no universal standard for this yet, so organisations should expect to tailor severity models to their industry, customer base, and regulatory obligations.
Edge cases usually appear when the issue is not a classic security flaw. A model hallucination may be a product quality concern in one context and a consumer protection issue in another. A prompt injection vulnerability may look technical, but if it can expose personal data or alter an automated decision, the severity can rise quickly. Cross-border deployments add another layer because one jurisdiction may treat the same behaviour as a reportable incident while another does not.
This is also where shared ownership is most important. Security can quantify exposure, but it may not be best positioned to decide whether an AI output creates unfair treatment, misleading advice, or a reportable safety event. For teams building repeatable processes, the right goal is not perfect consensus on every ticket. It is a documented escalation path that keeps severity decisions consistent, reviewable, and defensible when auditors or regulators ask why an issue was classified the way it was.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack surface, NIST CSF 2.0, NIST AI RMF and NIST AI 600-1 set the technical controls, and EU AI Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 | Severity ownership is a governance and risk decision, not just a technical one. |
| NIST AI RMF | GOVERN | AI RMF governance requires accountable decision-making for AI risk treatment. |
| NIST AI 600-1 | GenAI profiles stress operational controls for harmful output and misuse handling. | |
| OWASP Agentic AI Top 10 | Agentic systems can create harm through autonomous actions and tool use. | |
| EU AI Act | Regulated AI requires documented accountability for safety and compliance decisions. |
Assign cross-functional risk ownership and document how AI safety severity is approved.
