Confidentiality Breach Escalation Decision Prompt

This prompt is designed for security operations teams building automated triage systems for potential confidentiality breaches. It takes a structured incident report and produces a severity assessment, identifies affected data categories, and recommends an escalation path with urgency justification. The primary job-to-be-done is to create consistent, auditable breach assessment decisions that can feed into SOAR platforms, ticketing systems, or on-call paging workflows. The ideal user is a security engineer or SOC analyst integrating this prompt into an automated pipeline where incident reports arrive from detection systems, data loss prevention tools, or user-reported events and require rapid, standardized classification before human review.

Use this prompt when you need to enforce a repeatable decision framework across a high volume of potential breach events. It is appropriate for environments where incident reports contain structured fields such as data categories involved, affected user counts, regulatory tags, and exposure vectors. The prompt works best when paired with a defined output schema that downstream systems can parse, such as a JSON object containing severity, affected_data_categories, escalation_path, and urgency_justification. You should not use this prompt for automated notification decisions without legal review of the output, nor for generating external communications to affected parties. It is a decision-support tool, not a replacement for breach counsel or regulatory filing determinations.

This prompt does not replace human judgment for confirmed high-severity breaches. Any escalation recommendation above medium severity must be paired with human review before action is taken. Common failure modes include over-escalation fatigue, where the model classifies borderline incidents as high severity to avoid missing a breach, and under-escalation of subtle exfiltration patterns, such as low-volume data access over extended periods. To mitigate these risks, implement eval checks that measure precision and recall against a golden dataset of labeled incidents, and monitor the ratio of escalated-to-confirmed breaches over time. If your incident volume exceeds what your human review team can handle, invest in tuning the prompt's severity thresholds rather than removing the human-in-the-loop requirement.

This section provides the core prompt template for the Confidentiality Breach Escalation Decision Prompt. It is designed to be copied directly into your AI orchestration layer as a system prompt or a templated user message. The prompt instructs the model to act as a security triage analyst, systematically evaluating an incident report against your organization's data classification and incident response policies. It forces structured reasoning about severity, affected data categories, and the appropriate escalation path, rather than generating a generic risk summary.

textCopy
You are a Security Operations Triage Analyst AI. Your task is to assess a potential confidentiality breach incident report and provide a structured escalation recommendation. You must strictly adhere to the provided [DATA_CLASSIFICATION_POLICY] and [INCIDENT_RESPONSE_POLICY].

First, analyze the [INCIDENT_REPORT] against the following criteria:
1.  **Breach Indicators:** Identify specific phrases, metadata, or patterns in the report that indicate a potential confidentiality breach (e.g., unauthorized access, data exfiltration, accidental disclosure, privilege escalation).
2.  **Affected Data Categories:** Map the potentially compromised data to the categories defined in [DATA_CLASSIFICATION_POLICY] (e.g., Public, Internal, Confidential, Restricted).
3.  **Severity Assessment:** Determine the incident severity (Low, Medium, High, Critical) based on the data categories affected, the volume of data, and the nature of the exposure, as defined in [INCIDENT_RESPONSE_POLICY].
4.  **Urgency Justification:** Provide a concise, evidence-based justification for the assigned severity, quoting the relevant parts of the incident report and the policies.

Based on your analysis, generate a JSON output conforming to the [OUTPUT_SCHEMA] below. If the incident report does not contain enough information to make a determination, set the `escalation_path` to "HUMAN_REVIEW" and set the `confidence_score` to a value below 0.6, explaining what information is missing in the `rationale` field.

[OUTPUT_SCHEMA]={
  "incident_id": "string",
  "severity": "Low | Medium | High | Critical",
  "affected_data_categories": ["string"],
  "escalation_path": "NO_ACTION | SECURITY_TEAM | LEGAL_TEAM | EXECUTIVE_TEAM | HUMAN_REVIEW",
  "rationale": "string (evidence-based justification)",
  "confidence_score": "number (0.0 to 1.0)"
}

[CONSTRAINTS]=1. Do not invent or assume details not present in the [INCIDENT_REPORT]. 2. If the report describes a breach of "Restricted" data, the severity must be "Critical" and the escalation path must include "EXECUTIVE_TEAM". 3. Your entire response must be the single JSON object, with no other text before or after it.

To adapt this template, replace the square-bracket placeholders with your actual data and policies. The [DATA_CLASSIFICATION_POLICY] and [INCIDENT_RESPONSE_POLICY] placeholders should be replaced with the full text of your internal policy documents, not just their names. The [INCIDENT_REPORT] placeholder is where you inject the user's report or an alert payload. The [OUTPUT_SCHEMA] is provided inline as a JSON schema for the model to follow, and the [CONSTRAINTS] section encodes hard business rules that prevent common failure modes like under-escalation of critical events. For high-stakes deployments, always route outputs with a confidence_score below 0.8 or an escalation_path of "HUMAN_REVIEW" to a human analyst for final disposition.

This prompt is designed to operate as a decision node inside a larger Security Information and Event Management (SIEM) or Data Loss Prevention (DLP) workflow, not as a standalone chatbot. The model receives a structured alert payload—including breach indicators, affected data categories, user context, and environmental signals—and returns a structured escalation decision. The application layer is responsible for gathering that payload, invoking the model, validating the output, and executing the escalation path. Do not expose this prompt directly to end users or allow free-form chat interaction; the prompt's authority depends on a controlled input schema and a machine-readable output contract.

Integration pattern: The recommended architecture is a classifier-routed triage pipeline. A lightweight pre-filter (regex, signature-based DLP, or anomaly score threshold) identifies candidate events and assembles the [BREACH_INDICATORS], [AFFECTED_DATA_CATEGORIES], [USER_CONTEXT], and [ENVIRONMENTAL_SIGNALS] blocks. These are injected into the prompt template and sent to a fast, instruction-tuned model (e.g., Claude 3.5 Haiku, GPT-4o-mini, or a fine-tuned Llama variant) for initial assessment. The model returns a JSON object with severity, escalation_path, urgency_justification, and confidence. The application layer then applies a decision matrix: low-severity, high-confidence events are logged and aggregated for review; medium-severity or low-confidence events are queued for human analyst review; high-severity events trigger immediate paging and ticket creation. This tiered approach prevents both over-escalation fatigue and under-escalation of subtle exfiltration patterns.

Validation and retry logic: Before acting on the model's output, validate the JSON structure against a strict schema. Check that severity is one of the allowed enum values (low, medium, high, critical), that escalation_path contains a valid team identifier from your routing table, and that confidence is a float between 0.0 and 1.0. If validation fails, retry once with the same payload and an explicit error message appended to the prompt (e.g., 'Your previous output failed schema validation. Return ONLY valid JSON matching the specified schema.'). If the retry also fails, escalate the raw event to a human analyst with a schema_failure flag. Log every validation failure and retry for prompt performance monitoring.

Human review integration: For events classified as medium severity or with confidence below a configurable threshold (start at 0.85 and tune based on your team's false-positive tolerance), route the full event payload and model output to a review queue. The human analyst should see the original indicators, the model's assessment, and a one-click option to confirm, override, or downgrade the escalation. Capture the analyst's decision as ground truth for future eval dataset construction. This feedback loop is essential for measuring and improving the prompt's accuracy over time.

Audit and observability requirements: Every invocation of this prompt must produce an immutable audit record containing: the full prompt payload (with PII redacted if necessary), the raw model output, the validation result, the final escalation decision (including any human override), and timestamps for each stage. Store these records in a tamper-evident log for compliance review and incident postmortems. Use structured logging with trace IDs that connect the prompt invocation to the originating SIEM alert. This audit trail is not optional—confidentiality breach decisions are high-stakes, and regulators will expect evidence of consistent, defensible decision-making.

What to avoid: Do not use this prompt with models that have high hallucination rates on structured outputs without additional validation layers. Do not skip the confidence threshold check—a model that sounds certain is not necessarily correct. Do not allow the model to directly trigger destructive actions (e.g., account disablement, data quarantine) without human approval for any severity level below critical. And do not treat this prompt as static; regularly update the [BREACH_INDICATORS] taxonomy and [ESCALATION_PATHS] mapping as your threat landscape and organizational structure evolve. Run regression tests against a golden dataset of known breach and non-breach events before deploying any prompt changes.