Threshold Breach Escalation Prompt with Context

This prompt is designed for incident response and security operations workflows where an automated monitoring system has detected a threshold breach and a human analyst needs a complete, structured escalation payload to begin an investigation. The job-to-be-done is bridging the gap between a raw detection signal and a human-actionable ticket. The ideal user is a detection engineer or SOAR (Security Orchestration, Automation and Response) developer who has a reliable stream of breach events but needs to package the triggering event, risk score trajectory, affected assets, and recommended response actions into a single, coherent document. The required context includes the raw event data, a history of the risk score leading up to the breach, and an asset inventory mapping affected entities to business criticality.

Use this prompt when your detection pipeline can surface a breach but cannot assemble the narrative and context a human needs to act quickly. It is the correct tool when the primary failure mode is analyst cognitive load—spending the first 15 minutes of an investigation manually correlating logs, asset databases, and threat intelligence. Do not use this prompt for real-time automated blocking decisions, as it is designed for human review and does not have the latency or determinism guarantees required for inline enforcement. Do not use it for generating end-user notifications, which require a different tone, privacy filter, and channel. Do not use it when the underlying risk score computation itself is the primary task; this prompt consumes a score, it does not validate the scoring model's calibration. This prompt belongs after a detection rule fires and before a human picks up the ticket, serving as the formatting and context-assembly layer between detection and investigation.

Before implementing, confirm that your upstream detection system provides the minimum required fields: a unique event identifier, a timestamp, a risk score value with the threshold that was breached, and a list of affected asset identifiers. If any of these are missing, the prompt will produce an incomplete escalation payload that slows the analyst rather than accelerating them. The output should be treated as a draft for human review, not a final incident report. Always log the raw prompt input and generated output for post-incident review and prompt evaluation. If the escalation involves regulated data or PII, ensure the prompt runs in an environment where data handling meets your compliance requirements, and consider redacting sensitive fields before they enter the model context.

This template is designed to be injected into your incident response pipeline the moment a monitoring system detects a threshold breach. Its job is to synthesize raw detection data into a single, structured escalation payload that a human responder can act on immediately. The prompt forces the model to package the triggering event, the risk score's trajectory, the affected assets, and a set of recommended response actions into a consistent format. Replace each [PLACEHOLDER] with live data from your detection and asset management systems before sending the request to the model.

textCopy
You are an escalation assistant for a security operations center. Your task is to produce a structured escalation payload when a risk threshold is breached.

## Input Data
- Triggering Event: [EVENT_DETAILS]
- Current Risk Score: [CURRENT_SCORE]
- Risk Score Threshold: [THRESHOLD_VALUE]
- Risk Score Trajectory (last 5 data points): [SCORE_TRAJECTORY]
- Affected Assets (IDs, names, criticality): [AFFECTED_ASSETS]
- Anomaly Context: [ANOMALY_CONTEXT]
- Detection Rule That Triggered: [DETECTION_RULE]

## Output Schema
Produce a JSON object with the following structure:
{
  "escalation_id": "string",
  "severity": "critical|high|medium|low",
  "title": "string (concise summary of the breach)",
  "triggering_event": {
    "timestamp": "ISO 8601",
    "rule_name": "string",
    "description": "string"
  },
  "risk_assessment": {
    "current_score": "number",
    "threshold": "number",
    "breach_magnitude": "number (current_score - threshold)",
    "trajectory": "escalating|stable|declining",
    "trajectory_confidence": "high|medium|low"
  },
  "affected_assets": [
    {
      "asset_id": "string",
      "asset_name": "string",
      "criticality": "critical|high|medium|low",
      "impact_description": "string (how this asset is affected)"
    }
  ],
  "recommended_actions": [
    {
      "priority": 1,
      "action": "string (clear, executable step)",
      "owner": "string (suggested team or role)",
      "sla_minutes": "number"
    }
  ],
  "context_completeness": {
    "status": "complete|incomplete",
    "missing_fields": ["string (list any critical missing context)"]
  },
  "urgency_accuracy": {
    "assessment": "string (justification for the severity level chosen)",
    "overrides_applied": "boolean"
  }
}

## Constraints
- Do not fabricate asset details. Use only the provided [AFFECTED_ASSETS].
- If the risk score trajectory is flat or declining, set trajectory_confidence to "high" only if the data supports it.
- If critical context is missing, set context_completeness.status to "incomplete" and list the missing fields. Do not guess.
- Recommended actions must be specific and executable. Avoid vague advice like "investigate further."
- If the breach magnitude is extreme (>2x the threshold), severity must be "critical" unless an override justification is provided in urgency_accuracy.assessment.

To adapt this template for your environment, start by mapping your internal detection fields to the placeholders. The [SCORE_TRAJECTORY] should be a serialized list of recent scores so the model can determine if the situation is escalating or stabilizing. The [AFFECTED_ASSETS] placeholder expects a pre-formatted list from your CMDB or asset inventory—do not pass raw, unstructured data here. After generating the payload, validate the JSON against the schema and check that context_completeness.status is accurate; a common failure mode is the model claiming completeness when critical fields like asset criticality are missing. Finally, route the output to your escalation queue, using the severity and recommended_actions[0].sla_minutes fields to set paging rules.

This prompt is designed to be the final reasoning step in an automated escalation pipeline, not a standalone chatbot. It should be invoked by an application service after a monitoring system detects a threshold breach. The application is responsible for assembling the required context—the triggering event, risk score trajectory, affected assets, and relevant runbook references—before injecting them into the prompt's placeholders. The model's output is a structured escalation payload, which the application must then parse, validate, and route to the appropriate on-call channel or ticketing system.

The implementation harness requires strict output validation before any notification is sent. The application must verify that the generated JSON payload contains all required fields (escalation_id, severity, summary, affected_assets, recommended_actions) and that the severity field matches one of the predefined enum values (e.g., SEV1, SEV2, SEV3). If validation fails, the harness should retry the prompt once with a repair instruction appended to the context, such as 'The previous output failed schema validation for missing field [FIELD_NAME]. Please regenerate the full payload.' If the retry also fails, the system must fall back to a human-crafted alert with the raw context and a flag indicating an AI generation failure, preventing silent drops in the escalation pipeline.

For high-risk environments, this prompt must be deployed with a human-in-the-loop review step for all SEV1 escalations. The application should route the validated payload to a review queue rather than directly paging responders. A human reviewer confirms the severity, adjusts the recommended actions if needed, and approves the final notification. The system must log the original model output, the reviewer's modifications, and the approval timestamp for auditability. For SEV2 and SEV3 events, you can configure automatic routing to Slack channels or ticketing systems, but include a feedback mechanism (e.g., 'Was this escalation correct?') to capture human judgment for future model evaluation and fine-tuning.

Model choice matters here. Use a model with strong instruction-following and structured output capabilities, such as GPT-4o or Claude 3.5 Sonnet, and set temperature=0 to maximize determinism. Avoid small or open-weight models unless you have extensively tested their ability to adhere to the output schema and severity definitions under varied incident scenarios. The prompt should be version-controlled alongside the application code, and any changes to the prompt template must pass a regression test suite containing examples of past threshold breaches with known correct escalation payloads before deployment.