Data Breach Notification Decision Prompt

This prompt is designed for incident response teams, privacy officers, and security operations engineers who need to triage potential data breach events and determine whether regulatory notification obligations are triggered. It takes an incident report, maps the event against jurisdictional notification thresholds (GDPR, CCPA, HIPAA, and others), identifies affected data subjects and categories, assesses severity and risk of harm, and produces a structured recommendation with a notification timeline. Use this prompt when you have a concrete incident description and need a consistent, auditable first-pass assessment before human review.

The prompt expects a structured incident report as input, including the nature of the breach, data categories involved, estimated number of affected subjects, jurisdictions in play, and known containment status. It works best when the incident details are factual and specific rather than speculative. The output is a decision-support artifact that includes a severity classification, a regulatory mapping table, a notification obligation assessment per jurisdiction, a recommended timeline, and a confidence score for each determination. This output should be logged as part of your incident response audit trail and reviewed by qualified personnel before any regulatory filing or customer communication.

Do not use this prompt as a replacement for legal counsel or as the sole determinant of notification decisions. It is not suitable for incidents involving ongoing active exploitation where containment actions must precede assessment, nor for incidents where the facts are too sparse to support a reliable regulatory mapping. The prompt does not generate customer-facing notification language or legal filings—it only assesses obligations. Always route the final output through human review, and ensure your implementation captures the full prompt input and output for audit purposes. If the incident involves multiple conflicting jurisdictions, flag the output for prioritized legal review rather than treating the model's recommendation as final.

This prompt template is designed to be pasted directly into your system instructions or chat interface. It forces the model to act as a structured incident triage analyst, not a general advisor. Before execution, replace every square-bracket placeholder with real incident data, regulatory mappings, and your organization's specific notification thresholds. The prompt is structured to produce a machine-readable JSON output alongside a human-readable summary, making it suitable for direct integration into an incident response pipeline.

textCopy
You are an Incident Triage Analyst AI. Your task is to assess a potential data breach event and determine notification obligations based strictly on the provided [INCIDENT_REPORT], [REGULATORY_FRAMEWORK], and [NOTIFICATION_THRESHOLDS].

# INPUT DATA
[INCIDENT_REPORT]

# REGULATORY CONTEXT
Applicable Frameworks: [REGULATORY_FRAMEWORK]
Notification Thresholds: [NOTIFICATION_THRESHOLDS]

# CONSTRAINTS
- Do not speculate beyond the provided incident report. If information is missing, flag it as an unknown.
- Map findings explicitly to specific clauses in the [REGULATORY_FRAMEWORK].
- If the incident involves PII, apply the data minimization principle in your analysis.
- Your output must be a valid JSON object conforming to the [OUTPUT_SCHEMA] below.

# OUTPUT SCHEMA
{
  "incident_id": "string",
  "assessment_summary": "string (a concise, factual summary of the breach)",
  "severity_score": "string (CRITICAL|HIGH|MEDIUM|LOW)",
  "affected_data_subjects": ["list of strings"],
  "data_categories_involved": ["list of strings, e.g., PII, PHI, Credentials, Internal Docs"],
  "regulatory_obligations": [
    {
      "regulation": "string (e.g., GDPR)",
      "relevant_article": "string (e.g., Art. 33)",
      "notification_required": "boolean",
      "deadline_hours": "number or null",
      "rationale": "string (explain why the threshold is met or not met)"
    }
  ],
  "recommended_actions": ["list of strings"],
  "missing_critical_information": ["list of strings"],
  "escalation_recommended": "boolean",
  "confidence_score": "number (0.0 to 1.0)"
}

# FINAL INSTRUCTION
Analyze the [INCIDENT_REPORT] against the [REGULATORY_FRAMEWORK] and [NOTIFICATION_THRESHOLDS]. Output only the JSON object. Do not include any text outside the JSON block.

To adapt this template, start by replacing the regulatory framework placeholder with a concise summary of the specific laws you operate under, such as 'GDPR Art. 33-34, CCPA Section 1798.82'. The notification thresholds should be quantitative or qualitative rules from those laws, like 'risk to rights and freedoms of natural persons' or 'acquisition of unencrypted PII by an unauthorized person'. The incident report should be a structured summary of the known facts, not raw logs. After pasting the prompt, always run it through a JSON validator in your application layer. If the model fails to produce valid JSON, implement a retry loop that feeds the parsing error back into the model as a new user message, asking it to correct the format. For high-severity incidents, this AI assessment must be a decision-support tool, not the final decision-maker; always route CRITICAL severity outputs for immediate human review before any notification is sent.

This prompt is designed to operate as a decision-support tool within a broader incident response platform, not as a standalone chatbot. It should be wired into a workflow that ingests structured incident data, enriches it with regulatory metadata, and presents the model's assessment for human review before any notification action is taken. The prompt expects a pre-assembled [INCIDENT_REPORT] containing known facts, affected data categories, jurisdictions, and timelines. The application layer is responsible for assembling this context from ticketing systems, data catalogs, and asset inventories before calling the model. The model's output is a structured recommendation, not an executed action.

Validation and retry logic must be implemented in the harness, not in the prompt. The model returns a JSON object conforming to [OUTPUT_SCHEMA], which includes fields like breach_severity, affected_subjects, regulatory_thresholds_met, notification_timeline, and recommended_actions. The harness should validate this output against the schema immediately. If validation fails, implement a single retry with the validation error message appended to the prompt as additional context. If the retry also fails, escalate to a human analyst with the raw model output and the validation failure details. Do not loop retries indefinitely—two attempts is the maximum before escalation. For high-severity assessments (e.g., breach_severity: critical), the harness should require explicit human approval before any notification workflow is triggered, regardless of model confidence.

Logging and audit trails are non-negotiable in this workflow. Every model call must be logged with: the full prompt (including the incident report), the raw model output, the validated output, the retry count, the human reviewer's identity, and the final decision. This log serves as evidence for regulatory inquiries and internal post-incident reviews. Use structured logging with a correlation ID that ties the AI assessment back to the originating incident ticket. Model choice matters here: use a model with strong reasoning capabilities and a large context window (e.g., GPT-4o, Claude 3.5 Sonnet) because the prompt includes detailed regulatory mappings and multi-jurisdiction analysis. Avoid small or quantized models that may miss subtle threshold triggers. If your incident data contains PII, ensure the model endpoint is configured for zero data retention and that the harness redacts or tokenizes PII before sending it to the model if your deployment architecture requires it. The next step is to build a golden test set of historical breach scenarios with known outcomes and run this prompt against them before deploying to production.