Data Breach Notification Decision Prompt

This prompt is designed for security operations and compliance engineering teams who need a consistent, fast, and structured first-pass assessment of whether a security incident triggers mandatory breach notification obligations. The primary job-to-be-done is reducing the time between incident detection and a legally-informed decision while ensuring no notification deadline is missed. The ideal user is an incident responder or compliance analyst who has a structured incident summary and a curated set of jurisdictional regulations, and who needs a standardized output that a qualified attorney can review efficiently. This prompt is not a replacement for legal counsel; it is a force-multiplier that ensures the human reviewer receives a pre-analyzed package with risk-of-harm analysis, affected data categories, and jurisdiction-specific deadlines already extracted.

Use this prompt when you have a confirmed security incident involving personal data and you need to determine notification obligations across one or more jurisdictions. The prompt requires two structured inputs: a detailed incident summary including data categories, affected individuals, and known harm indicators, and a set of relevant regulatory texts with their notification thresholds and deadlines. Do not use this prompt for incidents still under active investigation with incomplete facts, for non-personal data breaches, or for jurisdictions where the applicable law has not been provided as input context. The prompt is also unsuitable for making final filing decisions—every output must be reviewed and signed off by a qualified human before any regulatory submission.

The output is a structured notification assessment that includes a per-jurisdiction determination, a risk-of-harm analysis, affected data categories mapped to regulatory definitions, and a deadline calendar. To wire this into an incident response pipeline, you should validate the output schema before presenting it to a reviewer, log every assessment with the input context and model version, and implement a hard block that prevents any automated filing. The most common failure mode is the model hallucinating a regulation or deadline that was not in the provided context; always cross-reference the output against the source regulatory text you supplied. The next step after using this prompt is to route the assessment to a designated human reviewer through a queue that tracks jurisdiction-specific deadlines and escalates approaching due dates.

This prompt template is designed to be pasted directly into your AI orchestration layer, such as a LangChain node, a custom API handler, or a low-code automation tool. It accepts structured incident data and the full text of applicable regulatory clauses as input. The model's job is to produce a deterministic, evidence-grounded assessment of whether notification is legally required, for which jurisdictions, and within what timeframe. The template uses square-bracket placeholders that your application must resolve before sending the request to the model. Never send unresolved placeholders to the model; your harness should validate that all required fields are populated and reject the request if they are not.

textCopy
You are a regulatory compliance analyst evaluating a security incident for breach notification obligations. Your analysis must be grounded solely in the provided incident data and regulatory text. Do not rely on external knowledge of laws, which may be outdated or incomplete.

## INCIDENT DATA
[INCIDENT_DETAILS]

## APPLICABLE REGULATORY TEXT
[REGULATORY_CLAUSES]

## OUTPUT SCHEMA
Respond with a single JSON object conforming to this structure:
{
  "notification_required": boolean,
  "confidence": "HIGH" | "MEDIUM" | "LOW",
  "jurisdictional_assessments": [
    {
      "jurisdiction": string,
      "regulation": string,
      "notification_required": boolean,
      "deadline": string | null,
      "rationale": string,
      "cited_clause": string
    }
  ],
  "risk_of_harm_analysis": {
    "data_categories_affected": string[],
    "risk_level": "HIGH" | "MEDIUM" | "LOW",
    "rationale": string
  },
  "recommended_actions": string[],
  "uncertainty_flags": string[]
}

## CONSTRAINTS
- If the incident data is insufficient to make a determination, set "notification_required" to false, "confidence" to "LOW", and list the missing information in "uncertainty_flags".
- Every "cited_clause" must be a direct quote or a precise section reference from the provided regulatory text. If no clause supports a claim, state "No applicable clause found."
- Do not invent deadlines. If the regulatory text does not specify a deadline, set "deadline" to null.
- If any data category suggests a high risk of harm (e.g., financial account credentials, government IDs, health records), the overall "risk_level" must be "HIGH" unless strong mitigating evidence is present in the incident data.
- Flag any ambiguity in the incident data or regulatory text in "uncertainty_flags".

To adapt this template, replace [INCIDENT_DETAILS] with a structured summary of the security event, including the type of breach, affected data categories, number of records, and any known exfiltration or access details. Replace [REGULATORY_CLAUSES] with the exact text of the relevant statutes or regulations, such as GDPR Articles 33-34, CCPA Section 1798.82, or your internal policy. The output schema is intentionally strict to allow your application to parse the response and route it to a human review queue when confidence is LOW or uncertainty_flags is non-empty. Before deploying, test this prompt against a golden dataset of known incidents with expected notification outcomes to calibrate your eval thresholds.

The Data Breach Notification Decision Prompt is a high-stakes compliance gate that should never execute in isolation. It must be embedded in an application harness that enforces evidence grounding, validates output structure, and routes borderline assessments to a human reviewer. The prompt itself is a reasoning engine; the harness is what makes it auditable, repeatable, and safe to deploy in a security operations workflow. Without the harness, you risk hallucinated regulatory deadlines, misclassified severity, or a false sense of compliance that creates legal exposure.

Wire the prompt into a structured pipeline with five stages. Stage 1: Context Assembly. Collect the incident report, affected data categories, known jurisdictions, and relevant regulatory excerpts (GDPR Articles 33-34, CCPA 1798.82, state breach laws, contractual notification clauses). Package these into the [INCIDENT_DETAILS], [DATA_CATEGORIES], [JURISDICTIONS], and [REGULATORY_EXCERPTS] placeholders. Do not rely on the model's parametric knowledge of notification deadlines—always supply the current regulatory text as grounding context. Stage 2: Prompt Execution. Call the model with temperature=0 and response_format set to the JSON schema defined in the prompt template. Use a model with strong instruction-following and low hallucination rates on structured legal reasoning tasks. Stage 3: Output Validation. Validate the response against the expected schema. Check that every cited deadline maps to a jurisdiction present in the input, that the notification_required boolean is consistent with the risk_of_harm_level, and that no hallucinated regulation names appear in the regulatory_basis field. Reject and retry any response that fails schema validation or contains citations not present in the provided excerpts. Stage 4: Risk-Based Routing. If risk_of_harm_level is high or notification_required is true, route the assessment to a human reviewer with the full incident context and model reasoning attached. If the model returns needs_human_review: true for any reason, escalate immediately. Only low-risk, no-notification-required assessments with high-confidence reasoning should proceed automatically. Stage 5: Audit Logging. Write the full prompt, response, validation results, routing decision, and reviewer action to an immutable audit log. This log is your evidence of a defensible decision process if a regulator or affected party later questions the notification timeline.

Common harness failures to avoid: (1) Skipping the regulatory excerpt injection and trusting the model to know deadlines—this produces plausible but wrong dates, especially for amended regulations. (2) Treating the model's output as the final decision without human review for high-risk cases—the prompt is a decision support tool, not a delegated authority. (3) Failing to validate that cited jurisdictions match the input—the model may invent multi-jurisdictional obligations where none exist. (4) Not logging the full decision trail—without audit evidence, you cannot demonstrate reasonable diligence. Build the harness to fail closed: if validation fails after two retries, if the model returns malformed JSON, or if the assessment contradicts known facts in the incident report, escalate to a human and log the escalation reason.