Escalation Routing Prompt Based on Risk Category

Security orchestration platforms and SOAR tools generate alerts that must reach the correct team with the right priority and context. This prompt takes a risk event, its computed category, and your routing policy, then produces a deterministic routing decision with team assignment, SLA tier, and a packaged context payload. Use it when you need consistent, policy-driven escalation routing that replaces brittle rule engines with an auditable, explainable decision layer. This prompt belongs between your detection systems and your paging or ticketing integration. It does not compute the risk score itself; pair it with a risk scoring prompt upstream.

The ideal user is a security automation engineer or platform operator who already has a risk score and category from an upstream detection system but needs to map that signal to a specific team, SLA, and notification payload. You must provide the prompt with a routing policy that defines which categories map to which teams, what severity thresholds trigger which SLA tiers, and what context fields each team requires. Without a well-defined routing policy, the prompt will produce inconsistent or incomplete routing decisions. This prompt is not a replacement for a full incident management platform; it is the decision layer that sits between detection and notification.

Do not use this prompt when the risk event lacks a computed category or when the routing policy is undefined or in flux. It is also not suitable for scenarios where the routing decision depends on real-time factors like current on-call schedules or team capacity, unless those factors are explicitly included in the input context. For high-severity events where regulatory or contractual obligations require human review of the routing decision itself, pair this prompt with a human-in-the-loop approval step before the notification is sent. The prompt produces a decision, but the execution of that decision—sending pages, creating tickets, logging audit trails—belongs in your application layer.

This prompt template is designed to be pasted directly into your orchestration layer. It takes a structured security event, a risk score, and your organization's routing policy, and produces a deterministic routing decision. The template uses square-bracket placeholders that your application must replace with live data before calling the model. Do not deploy this prompt with placeholders unresolved; doing so will produce unreliable routing and may leak template structure into production decisions.

textCopy
You are an escalation routing engine for a security operations platform. Your task is to determine which team should receive an escalation based on the risk category, severity, and organizational routing policy.

## INPUT
- Event Summary: [EVENT_SUMMARY]
- Risk Score: [RISK_SCORE]
- Risk Category: [RISK_CATEGORY]
- Affected Assets: [AFFECTED_ASSETS]
- Detection Source: [DETECTION_SOURCE]
- Current Time: [CURRENT_TIME]

## ROUTING POLICY
[ROUTING_POLICY]

## OUTPUT SCHEMA
Return a valid JSON object with exactly these fields:
{
  "routing_decision": {
    "target_team": "string (must match a team defined in ROUTING_POLICY)",
    "escalation_reason": "string (specific justification referencing risk category and policy rule)",
    "sla_tier": "string (P1 | P2 | P3 | P4 as defined in ROUTING_POLICY)",
    "required_context_package": ["list of evidence types the target team needs"],
    "fallback_team": "string or null (team to route to if primary is unavailable)",
    "routing_policy_rule_applied": "string (exact rule reference from ROUTING_POLICY)"
  },
  "confidence": {
    "category_match_confidence": "high | medium | low",
    "routing_ambiguity_detected": true or false,
    "ambiguity_notes": "string or null (explain if multiple teams could apply)"
  }
}

## CONSTRAINTS
- The target_team MUST be a valid team name from the ROUTING_POLICY.
- If the risk category maps to multiple teams, select the most specific match and flag routing_ambiguity_detected as true.
- If no team clearly matches, set target_team to the default escalation team defined in ROUTING_POLICY and set confidence to low.
- SLA tier must be derived from the risk score and the thresholds in ROUTING_POLICY, not assumed.
- Required context package must include at minimum: event summary, risk score breakdown, affected assets, and detection source.
- Do not invent team names, SLA definitions, or policy rules. Use only what is provided in ROUTING_POLICY.

## EXAMPLES
[EXAMPLES]

Return only the JSON object. No additional text.

To adapt this template, replace each placeholder with live data from your detection pipeline. [EVENT_SUMMARY] should contain a concise description of the security event. [RISK_SCORE] must include the numeric score and any sub-component breakdowns. [ROUTING_POLICY] is critical: it must define your team structure, SLA thresholds, and category-to-team mappings in structured text. The [EXAMPLES] placeholder should contain 2-3 few-shot demonstrations of correct routing decisions, including edge cases where categories overlap. After replacing placeholders, validate that the output JSON parses correctly and that the target_team field matches a real team in your system before the routing decision is executed. For high-severity events (P1/P2), always require human verification of the routing decision before dispatch.

Integrating this prompt into a production security orchestration platform requires treating it as a deterministic routing function with a natural-language reasoning layer, not as an open-ended chatbot. The prompt should be called after a risk score has been computed and a threshold breach has been confirmed. The application layer must supply the structured [INPUT] payload—including the risk category, severity, affected assets, and detection source—and the [ROUTING_TABLE] that maps categories to on-call teams, SLA tiers, and escalation paths. The model's job is to produce a single JSON routing decision that matches the schema exactly, not to invent new categories or override the routing table.

Validation and retry logic is critical because a malformed routing decision can delay incident response. Implement a JSON schema validator that checks: (1) the team field matches an entry in the [ROUTING_TABLE], (2) the sla_tier is one of the allowed enum values, (3) the context_package contains all required fields from the [OUTPUT_SCHEMA], and (4) the reasoning field is non-empty and references the risk category. If validation fails, retry the prompt once with the validation error message appended to the [CONSTRAINTS] block—for example, "Your previous output failed validation: team 'netsec' not found in routing table. Use only teams from the provided table." If the second attempt also fails, escalate to a human dispatcher with the raw model output and validation errors logged. Do not retry more than twice; at that point, the routing decision is too unreliable for automated handling.

Model choice and tool use should favor models with strong instruction-following and structured output capabilities. GPT-4o and Claude 3.5 Sonnet are appropriate defaults. Enable structured output mode (JSON mode or function calling with a strict schema) rather than relying on prompt-level format instructions alone. If your platform supports tool-use, define a route_escalation function with the output schema as its parameters; this gives you free validation on argument types. Logging and audit must capture the full prompt, the model's raw response, the validated routing decision, any retry attempts, and the final dispatch action. This audit trail is essential for post-incident review and for demonstrating that routing decisions followed defined escalation policies. Store logs in a tamper-evident system and retain them according to your incident response retention policy.

When not to use this prompt alone: If the routing table changes frequently, maintain it in application configuration and inject it into [ROUTING_TABLE] at call time rather than hardcoding it in the prompt. If the risk category is ambiguous or the input lacks a clear category mapping, do not ask the model to guess—instead, route to a default triage queue and flag for human review. This prompt is designed for known categories with defined escalation paths; novel or ambiguous threats should follow a separate "unclassified threat" escalation path that you define in your routing table. Finally, test this prompt against a golden dataset of known incidents with expected routing outcomes before deployment, and re-test whenever the routing table or escalation policies change.