Threshold Violation Severity Ranking Prompt

This prompt is designed for SOC managers and security automation engineers who need to prioritize multiple simultaneous threshold breaches. When a monitoring system fires a dozen alerts at once, human analysts need a ranked list that explains which violation to investigate first, why it matters, and what the blast radius looks like. This prompt takes a batch of violation records and produces a severity-ranked output with consistent justification, blast radius assessment, and recommended response ordering. Use it inside a SOAR playbook, an alert aggregation pipeline, or a shift handoff workflow where triage speed and consistency directly affect mean time to respond.

The ideal input is a structured list of violation records, each containing at least a unique identifier, a violation type, a triggered threshold value, the observed value, and the affected asset or user. The prompt works best when the input also includes asset criticality scores, business context, and any related active incidents. Do not use this prompt for single-alert triage—simpler classification prompts handle that case with lower latency and cost. Do not use it when the violations span entirely disconnected business units with no shared prioritization framework; the ranking will be arbitrary without a common risk taxonomy. The prompt assumes that all violations in the batch are true positives requiring human review; it does not perform alert suppression or deduplication.

Before deploying this prompt into a production triage pipeline, validate its output against historical incident outcomes. Run a regression test suite with known severity rankings from past major incidents to confirm the model consistently places high-impact violations at the top. Monitor for ranking inversion—cases where a lower-severity violation is ranked above a higher-severity one—and implement a human feedback loop to correct systematic errors. The prompt's value is in reducing the cognitive load of manual triage, but it must earn trust through consistent, explainable decisions that align with your organization's actual risk priorities.

This prompt template is designed to be invoked when your monitoring systems detect multiple threshold breaches within a short time window and a human SOC manager needs a prioritized action list. The template forces the model to apply consistent severity criteria across different violation types—such as authentication spikes, data exfiltration alerts, and configuration drift—rather than treating each alert in isolation. Replace every square-bracket placeholder with live data from your alerting platform, asset inventory, and runbook policies before each invocation.

codeCopy
You are a security operations severity ranking assistant. Your task is to analyze a set of simultaneous threshold violations and produce a ranked list ordered by urgency, with clear justification for each ranking decision.

## INPUT DATA
- Current Violations: [VIOLATIONS_LIST]
  (Each violation must include: alert_id, alert_type, source_system, triggered_threshold, observed_value, timestamp, affected_assets, and any initial risk score.)
- Asset Criticality Map: [ASSET_CRITICALITY_MAP]
  (Mapping of asset identifiers to criticality tiers: CRITICAL, HIGH, MEDIUM, LOW, with business impact descriptions.)
- Environmental Context: [ENVIRONMENTAL_CONTEXT]
  (Current operational state: maintenance windows, known incidents, recent changes, threat intelligence feeds, and staffing levels.)
- Severity Criteria Policy: [SEVERITY_CRITERIA_POLICY]
  (Definitions for SEV1 through SEV5, including response time expectations, blast radius thresholds, and data sensitivity weightings.)

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "ranking_timestamp": "ISO 8601 timestamp",
  "total_violations_evaluated": <integer>,
  "ranked_violations": [
    {
      "rank": <integer starting at 1>,
      "alert_id": "string",
      "severity_assigned": "SEV1|SEV2|SEV3|SEV4|SEV5",
      "severity_justification": {
        "primary_driver": "string explaining the dominant factor",
        "blast_radius_assessment": "string describing affected users, systems, or data scope",
        "asset_criticality_contribution": "string explaining how asset tier influenced the score",
        "temporal_urgency": "string describing time-sensitivity and escalation deadlines"
      },
      "recommended_response_order": "string with concrete first action and SLA target",
      "related_violations": ["alert_id"] or [],
      "confidence": "HIGH|MEDIUM|LOW",
      "confidence_rationale": "string explaining any uncertainty in the ranking"
    }
  ],
  "consistency_notes": "string describing any cross-violation calibration decisions made"
}

## CONSTRAINTS
- Apply the severity criteria policy consistently across all violation types. If two violations have similar blast radius and asset criticality, the one with higher temporal urgency must rank higher.
- If a violation affects a CRITICAL asset, it cannot be ranked below SEV2 unless you provide explicit override justification.
- Group related violations (same root cause, same attacker infrastructure) and note the relationship in `related_violations`. Do not rank related violations far apart without explanation.
- If confidence in any ranking is LOW, flag it explicitly and recommend human review before action.
- Do not invent asset criticality or environmental context. If data is missing, note it in `confidence_rationale` and assume worst-case for ranking purposes.
- The `consistency_notes` field must explain how you resolved any conflicts between the severity criteria policy and operational reality.

## EXAMPLES
Example input (abbreviated):
Violations: [{"alert_id": "A1", "alert_type": "data_exfiltration", "triggered_threshold": ">100MB outbound", "observed_value": "450MB", "affected_assets": ["db-primary-1"], "initial_risk_score": 92}, {"alert_id": "A2", "alert_type": "auth_spike", "triggered_threshold": ">50 failed logins/min", "observed_value": "320 failed/min", "affected_assets": ["vpn-gateway-2"], "initial_risk_score": 78}]
Asset Criticality: {"db-primary-1": "CRITICAL - customer PII store", "vpn-gateway-2": "HIGH - remote access gateway"}

Example output:
{
  "ranked_violations": [
    {
      "rank": 1,
      "alert_id": "A1",
      "severity_assigned": "SEV1",
      "severity_justification": {
        "primary_driver": "Active data exfiltration from CRITICAL asset containing customer PII",
        "blast_radius_assessment": "Potentially all customer records in primary database; regulatory notification required if confirmed",
        "asset_criticality_contribution": "CRITICAL asset with PII mandates immediate response per policy",
        "temporal_urgency": "Exfiltration is ongoing; every minute increases data loss"
      },
      "recommended_response_order": "Isolate db-primary-1 from network immediately; escalate to IR lead within 5 minutes",
      "related_violations": [],
      "confidence": "HIGH",
      "confidence_rationale": "Clear exfiltration pattern with unambiguous threshold breach"
    },
    {
      "rank": 2,
      "alert_id": "A2",
      "severity_assigned": "SEV2",
      "severity_justification": {
        "primary_driver": "Credential attack against VPN gateway with high failure rate",
        "blast_radius_assessment": "VPN gateway compromise could enable lateral movement to internal systems",
        "asset_criticality_contribution": "HIGH criticality as access vector, but no confirmed breach yet",
        "temporal_urgency": "Attack is active but rate-limited; window to block source IPs before success"
      },
      "recommended_response_order": "Block attacking IP ranges on VPN gateway; investigate for any successful logins within 30 minutes",
      "related_violations": [],
      "confidence": "MEDIUM",
      "confidence_rationale": "Auth spike could be misconfigured service account; needs investigation to confirm attack vs. operational issue"
    }
  ],
  "consistency_notes": "A1 ranked above A2 because confirmed data exfiltration from CRITICAL asset outweighs potential access vector compromise. Both are active threats but blast radius and certainty differ significantly."
}

## RISK LEVEL
HIGH. Incorrect ranking can delay response to active security incidents. If you cannot determine ranking with HIGH confidence for any SEV1 or SEV2 violation, flag for immediate human review rather than guessing.

Adapt this template by adjusting the severity criteria policy to match your organization's incident response framework. If your SOC uses a different severity scale (P1-P4, Critical-High-Medium-Low), update the enum values and policy definitions accordingly. The related_violations field is critical for reducing alert fatigue—ensure your alerting platform can pass correlation hints (such as shared source IPs or common attack signatures) into the [VIOLATIONS_LIST] input so the model can group related breaches. For production deployments, validate the output JSON against the schema before presenting rankings to a human analyst; a malformed ranking list is worse than no ranking at all.

Before deploying this prompt into an automated escalation pipeline, run it against a golden dataset of historical multi-alert incidents where you know the correct ranking. Measure whether the model's severity assignments match your senior analysts' decisions at least 90% of the time, and investigate every mismatch for policy ambiguity or missing context. Never allow this prompt's output to trigger automated containment actions without human approval—the ranking is a decision-support artifact, not an execution command.

This prompt is designed to sit at the end of a detection pipeline, consuming a batch of threshold violations that have already been triggered. It should not be used as a real-time, per-event classifier; its strength is in comparative ranking when multiple concurrent breaches compete for responder attention. The ideal integration point is a scheduled job or a webhook that fires when a violation queue exceeds a defined count (e.g., more than 5 unranked violations) or at a fixed interval during high-severity incidents. The input payload must be a structured list of violation objects, each containing a unique ID, a violation type, the breached threshold value, the actual observed value, the affected asset or service, and a timestamp. Without this minimum schema, the model cannot produce a reliable blast radius assessment or a consistent severity justification.

Wire the prompt into a SOAR playbook or a custom automation step that first aggregates violations from the source system (SIEM, monitoring tool, fraud detector) and normalizes them into the required JSON input format. Before calling the LLM, validate that each violation record has the required fields and that timestamps are in a sortable format. The LLM call should be wrapped in a retry block with a maximum of 2 attempts, catching malformed JSON responses. On the first failure, append a repair instruction to the retry prompt: 'The previous output was not valid JSON. Return ONLY the corrected JSON array.' If the second attempt also fails, log the raw response, flag the batch for manual review, and alert the on-call channel. For model choice, a model with strong JSON mode and reasoning capabilities (e.g., GPT-4o, Claude 3.5 Sonnet) is preferred. Avoid smaller, faster models here; the cost of an inconsistent severity ranking—where a low-impact violation is prioritized over a critical one—is far higher than the latency or token cost of a capable model.

Post-processing is critical. Parse the ranked output and validate that every input violation ID appears exactly once in the ranked list. Check that the severity field is one of the allowed enum values (e.g., CRITICAL, HIGH, MEDIUM, LOW) and that the blast_radius field is populated. If the model introduces a new violation ID or omits an input, do not publish the ranking. Instead, log the mismatch and fall back to a deterministic ranking based on a predefined static severity map for known violation types. For auditability, store the full prompt, the model response, and the final validated ranking in a case management or incident log. When the ranking is used to auto-assign incidents or trigger paging, always include a human-readable summary of the top 3 violations and their justifications in the notification payload. Never auto-execute a response action based solely on the model's ranking without a human-in-the-loop confirmation step for the top-ranked item, especially if the action is irreversible (e.g., isolating a production host, blocking a payment rail).