Security Event Risk Scoring Prompt Template

This prompt is designed for SOC analysts and detection engineers who need to convert raw security event data into a structured, explainable risk score for triage prioritization. Use it when you have event telemetry, log data, or alert payloads that require consistent severity assessment before routing to investigation queues. The prompt produces a composite score that combines threat intelligence mapping, asset context, and confidence indicators so that downstream automation or human reviewers can act on a standardized output.

Do not use this prompt for real-time blocking decisions where latency below 500ms is required; it is built for triage and review workflows, not inline prevention. The prompt assumes you have already extracted and normalized the event fields before calling the model. You should also avoid using it when the event lacks critical fields such as source IP, target asset, or event type, as the model will be forced to guess rather than reason from evidence. For high-severity events that may require immediate containment, pair this prompt with a separate escalation playbook that triggers paging or automated isolation before the scoring step completes.

Before integrating this prompt into a production pipeline, validate that your event normalization layer consistently populates the required input fields. Run the prompt against a golden dataset of 50–100 historical events with known outcomes to measure score calibration and inter-rater reliability across analysts. If the prompt produces inconsistent severity labels for similar events, revisit your asset criticality mappings or add few-shot examples that anchor the scoring behavior. Once calibrated, wire the output into your SIEM or SOAR queue with a human review gate for any event scoring above your defined escalation threshold.

This prompt template is designed for SOC analysts and detection engineers who need to triage security events consistently. It enforces a structured JSON output, requires evidence grounding for every score component, and instructs the model to flag low-confidence assessments rather than guessing. The template uses square-bracket placeholders that you must replace with real data before each call. The output includes a severity score, MITRE ATT&CK technique mapping, asset criticality weighting, and explicit confidence indicators for each field.

textCopy
SYSTEM: You are a security event risk scoring assistant. Your task is to analyze a security event and produce a structured risk assessment. You must ground every score in the provided evidence. If evidence is insufficient for any field, set the confidence to 'low' and explain what is missing. Do not invent details. Do not guess.

USER:
Analyze the following security event and return a JSON object conforming to the [OUTPUT_SCHEMA] below.

## EVENT DETAILS
[EVENT_DETAILS]

## ASSET CONTEXT
[ASSET_CONTEXT]

## ENVIRONMENTAL CONTEXT
[ENVIRONMENTAL_CONTEXT]

## OUTPUT SCHEMA
{
  "event_id": "string",
  "severity": {
    "score": "number (0.0 to 10.0)",
    "label": "'critical' | 'high' | 'medium' | 'low' | 'informational'",
    "confidence": "'high' | 'medium' | 'low'"
  },
  "mitre_attack": [
    {
      "technique_id": "string (e.g., T1059.001)",
      "technique_name": "string",
      "relevance": "'direct' | 'indirect' | 'potential'",
      "evidence": "string (quote or reference from event details)",
      "confidence": "'high' | 'medium' | 'low'"
    }
  ],
  "asset_criticality": {
    "level": "'critical' | 'high' | 'medium' | 'low'",
    "weighting_factor": "number (0.0 to 1.0)",
    "justification": "string",
    "confidence": "'high' | 'medium' | 'low'"
  },
  "risk_factors": [
    {
      "factor": "string",
      "impact": "'increases_risk' | 'decreases_risk' | 'neutral'",
      "evidence": "string",
      "confidence": "'high' | 'medium' | 'low'"
    }
  ],
  "recommended_action": {
    "action": "'escalate' | 'investigate' | 'monitor' | 'close'",
    "urgency": "'immediate' | 'within_1_hour' | 'within_24_hours' | 'none'",
    "rationale": "string"
  },
  "low_confidence_fields": ["string (list field names where confidence is 'low')"],
  "overall_confidence": "'high' | 'medium' | 'low'"
}

## CONSTRAINTS
- Every field in the output must be populated.
- For any field where evidence is insufficient, set confidence to 'low' and explain what is missing in the justification or evidence field.
- Do not assign a severity score above 7.0 unless you can cite specific evidence of active exploitation or confirmed compromise.
- If the event is a known false-positive pattern, set severity to 'informational' and explain the pattern match.
- Map to MITRE ATT&CK techniques only when you can cite supporting evidence from the event details.
- The asset_criticality.weighting_factor must be justified by the provided asset context.
- If overall_confidence is 'low', recommended_action.action must be 'escalate' or 'investigate'.

To adapt this template, replace the three input placeholders with real data on each call. [EVENT_DETAILS] should contain the raw alert, log entry, or event description. [ASSET_CONTEXT] should include information about the affected system such as its business function, data classification, and exposure. [ENVIRONMENTAL_CONTEXT] should provide broader situational awareness such as active campaigns, recent incidents, or known vulnerabilities. The output schema is designed to be parsed by downstream automation. If your SIEM or SOAR expects a different field structure, adjust the schema but preserve the confidence indicators and evidence grounding requirements. For high-severity events, route the output to a human reviewer before taking automated action. Test the prompt against a golden dataset of known events with expected severity labels to measure inter-rater reliability before deploying to production.

The prompt template is a single component in a larger security triage pipeline. In production, the harness must enforce output schema compliance, handle model failures gracefully, and route high-severity or low-confidence results to a human review queue. Treat the prompt as an unreliable function that can return malformed JSON, hallucinate MITRE ATT&CK technique IDs, or produce inconsistent severity scores across similar events. The harness is responsible for catching these failures before a score reaches an analyst or an automated response playbook.

Wire the prompt into an application function that accepts a structured security event payload and returns a validated risk score object. Before calling the model, assemble the prompt with the event's raw log data, asset criticality from your CMDB, and the current MITRE ATT&CK reference context. After receiving the model response, run a strict JSON schema validator that checks required fields (severity_score, confidence, mitre_techniques, reasoning), enforces enum values for severity levels, and verifies that MITRE technique IDs match the expected T#### pattern. If validation fails, retry once with the validation error message appended to the prompt as a correction hint. If the retry also fails, log the failure and route the event to a manual triage queue with the raw event data and partial model output attached.

For high-risk security workflows, implement a human review gate based on two conditions: severity score above your defined threshold (e.g., severity_score >= 7) or model confidence below your minimum (e.g., confidence < 0.7). When either condition triggers, do not automatically create an incident or trigger a SOAR playbook. Instead, package the scored event into a review queue item with the full prompt response, the raw log evidence, and a pre-formatted summary for the SOC analyst. Log every scoring decision—including model, prompt version, input hash, output, validation result, and review routing decision—to your security data lake for auditability and drift monitoring. Run periodic eval batches using golden datasets of known incidents and benign events to measure score calibration, inter-run consistency, and alert fatigue rate before deploying prompt or model changes.