Anomaly Investigation Handoff Prompt Template

This prompt is designed for security operations teams that need to transfer active anomaly investigations between shifts, tiers, or specialized teams. It takes raw investigation notes, alert payloads, and analyst commentary and produces a structured handoff document that an incoming analyst can read and act on without restarting the investigation. Use this prompt when you have a partially completed investigation and need to preserve state, findings, open questions, and evidence inventory in a consistent format.

The ideal user is a Tier 1 or Tier 2 SOC analyst who has spent time investigating an anomaly but must hand off the case before reaching a conclusion. The prompt assumes you already have investigation data collected—alert IDs, log excerpts, tool outputs, timeline notes, and hypotheses considered. It does not perform detection, triage, or root cause analysis. It synthesizes what is known and identifies what is missing. Required inputs include the raw investigation notes, any alert payloads or case IDs, a list of tools or data sources already queried, and the current disposition of the investigation.

Do not use this prompt when the investigation is complete and ready for closure—use a case summary prompt instead. Do not use it when no investigation work has been performed; the prompt requires partial findings to synthesize. Do not rely on this prompt to make escalation decisions or compute risk scores; it documents investigation state, not risk thresholds. In regulated environments, ensure the handoff document is reviewed by a senior analyst before the incoming analyst acts on its contents, particularly when the investigation involves potential data exfiltration, insider threat, or compliance-reportable events.

After generating the handoff, validate that all required sections are populated, evidence references are traceable to source systems, and open questions are specific enough to guide next steps. Wire the output into your case management system or SOAR platform so the incoming analyst receives the handoff in their queue with full context. If the prompt produces a handoff with critical gaps flagged, treat that as a signal to pause the handoff and collect missing evidence before transfer.

This prompt template produces a structured handoff document for security operations shift changes and cross-team escalations. It captures investigation state, findings, open questions, next steps, and an evidence inventory with completeness checks. Replace every square-bracket placeholder with real data before execution. The template assumes you have investigation notes, alert context, and evidence references available as input.

textCopy
You are a senior security analyst preparing a structured investigation handoff for an incoming analyst. Your goal is to ensure the receiving analyst can continue the investigation without restarting or losing context.

## INPUT
Investigation notes and evidence:
[INVESTIGATION_NOTES]

Alert or case context:
[ALERT_CONTEXT]

Evidence references (log excerpts, tool outputs, screenshots, timelines):
[EVIDENCE_INVENTORY]

## OUTPUT_SCHEMA
Produce a JSON object with the following fields. Do not include any text outside the JSON.

{
  "handoff_id": "string, unique identifier for this handoff",
  "timestamp": "ISO 8601 timestamp of handoff creation",
  "incident_summary": "string, 2-4 sentence executive summary of what is known",
  "investigation_state": {
    "phase": "string, one of: initial_triage | evidence_collection | hypothesis_testing | containment | remediation | post_incident",
    "confidence_level": "string, one of: low | medium | high",
    "hours_invested": "number, total analyst hours spent so far"
  },
  "findings": [
    {
      "finding_id": "string",
      "description": "string, what was found",
      "confidence": "string, one of: confirmed | likely | possible | ruled_out",
      "evidence_refs": ["array of evidence IDs from evidence inventory"],
      "timestamp": "ISO 8601 when finding was established"
    }
  ],
  "open_questions": [
    {
      "question_id": "string",
      "question": "string, the unanswered question",
      "priority": "string, one of: critical | high | medium | low",
      "blocked_by": "string or null, what is preventing an answer",
      "suggested_approach": "string, how the incoming analyst might resolve this"
    }
  ],
  "next_steps": [
    {
      "step_id": "string",
      "action": "string, concrete next action",
      "priority": "string, one of: critical | high | medium | low",
      "depends_on": ["array of step_ids or question_ids that must be resolved first"],
      "estimated_effort_minutes": "number"
    }
  ],
  "evidence_inventory": [
    {
      "evidence_id": "string",
      "type": "string, one of: log | screenshot | tool_output | timeline | interview | alert | external_report",
      "source": "string, system or person that produced this evidence",
      "description": "string, what this evidence contains",
      "access_instructions": "string, how the incoming analyst can retrieve or view this evidence",
      "chain_of_custody": "string or null, if evidence integrity matters"
    }
  ],
  "contacts": [
    {
      "role": "string, e.g., escalation_point | system_owner | legal | comms",
      "name": "string",
      "contact_method": "string",
      "availability": "string, e.g., on_call | business_hours | notified"
    }
  ],
  "completeness_checks": {
    "all_findings_have_evidence": "boolean",
    "all_critical_questions_addressed": "boolean",
    "evidence_inventory_complete": "boolean",
    "timeline_gaps_identified": "boolean",
    "missing_context_notes": "string or null, anything the incoming analyst should know is missing"
  },
  "handoff_notes": "string, freeform notes from the outgoing analyst to the incoming analyst"
}

## CONSTRAINTS
- If any finding is marked "confirmed," at least one evidence reference must be provided.
- If investigation_state.confidence_level is "low," the handoff_notes field must explain why and what would increase confidence.
- Do not fabricate findings. If the input does not support a field, use null or an empty array as appropriate.
- Prioritize open_questions and next_steps by urgency: critical items must appear first.
- For each open_question marked "critical," provide a suggested_approach.

## RISK_LEVEL
[HIGH_RISK: This handoff may inform incident response decisions. The incoming analyst must verify all findings before acting. If confidence is low, escalate to a senior analyst before containment actions.]

Adaptation guidance: Replace [INVESTIGATION_NOTES] with the outgoing analyst's raw notes, [ALERT_CONTEXT] with the triggering alert or case ticket, and [EVIDENCE_INVENTORY] with a list of evidence items and their access paths. If your organization uses a different investigation phase model, update the phase enum values. For regulated environments, add a regulatory_classification field to the output schema and require a legal_review_required boolean. If the handoff feeds into a case management system, map the JSON fields to your system's API contract. For high-risk incidents, route the completed handoff through a human review step before the incoming analyst accepts it.

This prompt is designed to be the final step in an analyst's workflow, not a standalone chatbot. It should be triggered by an explicit 'handoff' or 'shift change' action within a Security Orchestration, Automation, and Response (SOAR) platform or a custom investigation case management system. The application layer is responsible for gathering the structured and unstructured data required by the prompt's placeholders, such as [CASE_TIMELINE], [EVIDENCE_INVENTORY], and [OPEN_QUESTIONS]. The model's job is to synthesize this pre-fetched context into a coherent, standardized document; it should not be used to query live systems or make investigative decisions.

To wire this into an application, build a function that assembles the prompt's input variables from the current investigation state. For example, [EVIDENCE_INVENTORY] should be a pre-formatted list of log snippets, alert payloads, and file hashes with their source systems. After the model generates the handoff document, a post-processing validation step is critical. Implement a schema check to ensure the output contains all required sections: 'Investigation State', 'Findings So Far', 'Open Questions', 'Next Steps', and 'Evidence Inventory'. If the model's output fails this structural validation, use a repair prompt or a retry loop with a stricter [OUTPUT_SCHEMA] constraint. Log every generated handoff with a unique investigation ID, the prompt version, and the raw model output for auditability.

Model choice involves a trade-off between speed and reasoning depth. A fast model like GPT-4o or Claude 3.5 Sonnet is suitable for straightforward handoffs, but for complex, multi-stage investigations with nuanced findings, a reasoning model like o1 or Claude 3.5 Opus may produce more coherent 'Next Steps' and better identify contradictions in the 'Open Questions' section. Crucially, this prompt must not be connected to any tool that can modify tickets, close cases, or send notifications. The output is a draft for human review. The incoming analyst should confirm the summary's accuracy and completeness before the handoff is finalized in the system of record. The primary failure mode is the model hallucinating a resolution or omitting a critical open question, which is why the human-in-the-loop review step is a hard requirement, not an option.