Escalation Evidence Packaging Prompt for Security Analysts

This prompt is designed for security automation engineers and SOC platform builders who need to convert raw detection outputs into structured, analyst-ready investigation packages. The core job-to-be-done is the handoff: taking machine-generated alerts, log excerpts, risk score breakdowns, and related context, then producing a formatted evidence package that follows a standard investigation SOP. Use it when an automated detection system or risk scoring pipeline has flagged an event that requires human investigation, and the goal is to eliminate the manual assembly work that analysts typically perform before they can begin actual analysis. The ideal user is a developer or engineer wiring together a detection pipeline, a SOAR platform, or a case management system, not the analyst performing the investigation itself.

The prompt requires specific, structured inputs to function reliably. You must provide the raw alert payload, relevant log excerpts with timestamps, a risk score breakdown showing contributing factors and their weights, any related alerts or correlated events, and the target investigation SOP sections that define what a complete package must contain. Without these inputs, the prompt will produce a generic summary rather than a complete evidence package. The output is designed to be ingested by a case management system, ticketing platform, or SOC queue, so the prompt includes formatting instructions that match the target system's schema. This is not a prompt for performing the investigation itself, generating new hypotheses, or making escalation decisions. It is a packaging prompt that ensures the handoff from machine to human is complete, consistent, and immediately actionable.

Do not use this prompt when the detection system's output is already structured and complete enough for direct analyst consumption, or when the investigation workflow does not follow a defined SOP that can be encoded as completeness checks. It is also inappropriate for real-time blocking decisions where latency constraints prevent the assembly of a full evidence package. In those cases, a lightweight escalation decision prompt with threshold comparison is more suitable. For investigations that require cross-system correlation or root cause hypothesis generation, use dedicated anomaly correlation or hypothesis generation prompts before packaging the results with this prompt. Always validate the output against the target system's schema before ingestion, and implement a human review step if the packaging prompt itself introduces uncertainty about evidence completeness or accuracy.

This prompt template is designed to be pasted directly into your system instructions or orchestration layer. It takes raw outputs from your detection pipeline—such as log excerpts, risk scores, and related alert IDs—and assembles them into a standardized evidence package. The goal is to eliminate the manual copy-paste work analysts perform when preparing an investigation handoff, ensuring every package is consistent with your investigation SOPs.

codeCopy
You are an escalation evidence packaging assistant for a security operations team. Your task is to compile a structured evidence package from the provided detection data. The package must be complete enough for a human analyst to begin an investigation without re-querying source systems.

## Input Data
- **Triggering Alert:** [ALERT_DETAILS]
- **Risk Score Breakdown:** [RISK_SCORE_JSON]
- **Relevant Log Excerpts:** [LOG_EXCERPTS]
- **Related Alert IDs:** [RELATED_ALERT_IDS]
- **Asset Context:** [ASSET_INFORMATION]
- **User/Entity Context:** [ENTITY_CONTEXT]

## Required Output Schema
Produce a JSON object conforming to this exact structure:
{
  "package_id": "string",
  "generated_at": "ISO8601 timestamp",
  "executive_summary": "A 2-3 sentence plain-language summary of what happened and why it's suspicious.",
  "risk_details": {
    "composite_score": "number (0-100)",
    "score_trend": "string (escalating | stable | de-escalating)",
    "top_risk_drivers": ["string (list of the top 3 factors contributing to the score)"],
    "threshold_comparison": "string (e.g., 'Score of 85 exceeds critical threshold of 80')"
  },
  "evidence_inventory": [
    {
      "source": "string (e.g., 'Firewall Log', 'EDR Alert')",
      "timestamp": "ISO8601",
      "summary": "string (a 1-sentence description of the evidence)",
      "raw_excerpt": "string (the exact log line or alert text)",
      "relevance": "string (explain how this evidence supports or contradicts the alert)"
    }
  ],
  "related_alerts": [
    {
      "alert_id": "string",
      "relationship": "string (e.g., 'Same source IP', 'Same user within 10 minutes')"
    }
  ],
  "initial_triage_notes": {
    "likely_scenario": "string (the most probable attack or failure scenario)",
    "alternative_scenarios": ["string"],
    "immediate_recommended_actions": ["string (a list of 2-4 concrete next steps for the analyst)"],
    "missing_evidence": ["string (list any expected data sources that are absent or empty)"]
  },
  "sop_compliance_check": {
    "required_fields_present": "boolean",
    "missing_required_fields": ["string"],
    "overall_completeness": "string (complete | partial | insufficient)"
  }
}

## Constraints
- Do not fabricate evidence. If a field is empty or data is missing, note it explicitly in `missing_evidence` and set `required_fields_present` to false.
- The `executive_summary` must be understandable by a non-specialist manager.
- All timestamps must be in ISO8601 format.
- If the risk score is below the defined threshold of [CRITICAL_THRESHOLD], add a note to the `initial_triage_notes` explaining why this alert was escalated despite being below threshold.
- The `sop_compliance_check` must reference the investigation SOP requirements defined in [SOP_REQUIREMENTS_DOC].

To adapt this template, replace the square-bracket placeholders with data from your detection pipeline before sending it to the model. The [SOP_REQUIREMENTS_DOC] placeholder is critical—it should contain the specific fields your investigation team requires for a complete handoff. If your SIEM or SOAR platform enforces a different output schema, modify the JSON structure accordingly, but preserve the sop_compliance_check block as a final validation gate. For high-severity alerts, consider adding a [HUMAN_REVIEW_REQUIRED] boolean flag that forces a manual review of the generated package before it reaches the analyst queue.

Integrating the evidence packaging prompt into a production SOAR or SIEM pipeline requires treating it as a deterministic component with well-defined inputs, outputs, and failure modes. The prompt should be invoked only after an escalation decision has already been made—it packages evidence, it does not decide whether to escalate. The calling system must supply all required context: the triggering alert, correlated events, asset context, risk score breakdown, and the target investigation system's schema. Missing inputs should cause the workflow to halt and request data, not to invoke the prompt with incomplete context.

The implementation harness should validate the model's output against the expected schema before the evidence package enters any downstream system. Use a strict JSON Schema validator that checks for required fields (incident_id, evidence_items, risk_score_breakdown, related_alerts, triage_notes, completeness_checks), correct data types, and non-empty arrays where evidence is expected. If validation fails, implement a single retry with the validation error message appended to the prompt as a correction instruction. If the retry also fails, escalate the packaging failure itself to a human analyst with the raw model output and validation errors attached—never silently drop a failed evidence package.

Log every invocation with the prompt version, model used, input context hash, output validation status, and reviewer identity if the package was modified. For high-severity incidents, route the generated package to a human review queue before it reaches the investigation system. The reviewer should confirm that evidence items are correctly attributed, risk score components are explained, and no critical context was omitted. After review, store the final package immutably in the case management system and feed any reviewer corrections back as few-shot examples for future prompt iterations. Avoid using this prompt for real-time blocking decisions—it is designed for post-escalation handoff packaging, not for inline transaction gating.