Data Breach Notification Event Log Prompt

This prompt is designed for privacy engineers and legal operations teams who need to convert unstructured breach reports into structured, machine-readable notification event logs. The primary job-to-be-done is transforming a factual breach summary—typically a narrative document or email—into a record that can be ingested directly by an incident management system, a regulatory filing pipeline, or a compliance audit trail. The ideal user has a breach report in hand and needs to extract, normalize, and structure key data points such as data categories, affected subjects, discovery timestamps, and applicable regulatory triggers without manually re-keying information into a ticketing system.

Use this prompt when you have a confirmed or suspected breach summary and need a consistent, auditable output. The prompt assumes the input contains factual information; it does not make legal determinations about whether a breach is notifiable, nor does it replace human judgment about notification obligations. It is appropriate for operationalizing the recording of a breach event, not for making the legal decision to notify. Do not use this prompt as a substitute for legal advice, to generate a notification letter to affected parties, or to interpret vague or contradictory source material where a human investigator has not yet established the facts. The output is a structured log entry, not a final regulatory filing.

Before using this prompt, ensure you have a complete, reviewed breach summary. The prompt's value is in its strict schema enforcement, which maps extracted fields to a controlled taxonomy for data categories and regulatory triggers. If your input is a raw, unconfirmed alert from a detection system, route it through an investigation and confirmation workflow first. The next step after generating this log is to feed the structured output into your incident management system and, where required by your organization's policy, queue it for human review before any regulatory submission.

This prompt template is designed for privacy engineers and security operations teams who need to generate structured, machine-parseable data breach notification event logs. It enforces a strict JSON schema, maps affected data categories to a controlled taxonomy, and identifies applicable regulatory triggers (GDPR, CCPA, HIPAA, etc.) based on the data types and affected subjects. The output is intended to feed directly into incident management systems, regulatory filing workflows, and audit trails. Do not use this prompt for generating the actual notification text to data subjects or for providing legal advice on notification obligations; it produces a structured event record, not a legal document.

textCopy
You are a privacy incident logging assistant. Your task is to generate a structured data breach notification event log entry from the provided incident details. You must strictly adhere to the output schema, use only the allowed data category taxonomy, and map the incident facts to the correct regulatory triggers.

## INPUT
[INCIDENT_DESCRIPTION]

## CONSTRAINTS
- Output ONLY a valid JSON object conforming to the provided schema. No markdown fences, no surrounding text.
- All timestamps MUST be in ISO 8601 format (YYYY-MM-DDThh:mm:ssZ).
- The `data_categories` array MUST only contain values from the approved taxonomy listed below.
- The `regulatory_triggers` array MUST only contain values from the approved regulation list.
- If a field's value is unknown or not applicable, use `null` for nullable fields or an empty array `[]` for array fields as specified in the schema. Do not omit required fields.
- The `severity` field must be one of: `critical`, `high`, `medium`, `low`, `info`.
- The `discovery_method` must be one of: `automated_alert`, `manual_review`, `external_report`, `internal_audit`, `third_party_notification`, `unknown`.

## APPROVED DATA CATEGORY TAXONOMY
- `pii` (Personally Identifiable Information)
- `phi` (Protected Health Information)
- `financial` (Financial Account or Payment Data)
- `credentials` (Passwords, Keys, Tokens)
- `biometric` (Biometric Data)
- `communications` (Private Communications Content)
- `geolocation` (Precise Geolocation Data)
- `behavioral` (Behavioral or Profiling Data)
- `corporate_confidential` (Trade Secrets, Internal Strategy)
- `legal_privileged` (Attorney-Client Privileged Material)

## APPROVED REGULATORY TRIGGERS
- `gdpr` (General Data Protection Regulation)
- `ccpa_cpra` (California Consumer Privacy Act / CPRA)
- `hipaa` (Health Insurance Portability and Accountability Act)
- `pci_dss` (Payment Card Industry Data Security Standard)
- `breach_notification_laws` (General US State Breach Notification Laws)
- `ftc_act` (Federal Trade Commission Act Section 5)
- `ny_shield` (New York SHIELD Act)
- `lgpd` (Brazilian General Data Protection Law)
- `pipeda` (Canadian Personal Information Protection and Electronic Documents Act)
- `none` (No specific regulatory trigger identified)

## OUTPUT SCHEMA
{
  "event_id": "string, unique identifier for this event log entry",
  "event_type": "data_breach_notification_event",
  "incident_id": "string, reference to the parent incident",
  "discovery_timestamp": "string, ISO 8601 timestamp of breach discovery",
  "recorded_timestamp": "string, ISO 8601 timestamp of this log creation",
  "severity": "string, enum from severity list",
  "status": "string, one of: new, investigating, notified, remediated, closed",
  "affected_subjects": {
    "count_estimated": "integer or null, estimated number of affected individuals",
    "count_confirmed": "integer or null, confirmed number of affected individuals",
    "subject_types": ["array of strings, e.g., customer, employee, patient, partner, unknown"],
    "jurisdictions": ["array of strings, e.g., US-CA, EU-DE, BR, CA-QC"]
  },
  "data_categories": ["array of strings from approved taxonomy"],
  "breach_cause": "string, one of: malicious_attack, system_glitch, human_error, lost_stolen_device, third_party_breach, unknown",
  "discovery_method": "string, enum from discovery method list",
  "regulatory_triggers": ["array of strings from approved regulation list"],
  "notification_obligations": {
    "regulator_notification_required": "boolean",
    "regulator_deadline": "string or null, ISO 8601 date by which regulator must be notified",
    "subject_notification_required": "boolean",
    "subject_deadline": "string or null, ISO 8601 date by which subjects must be notified",
    "media_notification_required": "boolean"
  },
  "source_system": "string, system that detected or reported the breach",
  "reporter": {
    "name": "string or null",
    "role": "string or null",
    "contact": "string or null"
  },
  "evidence_references": ["array of strings, links or IDs to evidence artifacts"],
  "notes": "string or null, additional context"
}

## INSTRUCTIONS
1. Analyze the incident description to extract all relevant facts.
2. Map affected data types to the approved data category taxonomy.
3. Determine applicable regulatory triggers based on data categories, subject jurisdictions, and subject types.
4. Assess notification obligations based on regulatory triggers and breach scope.
5. Populate the JSON schema completely, using `null` or `[]` where information is unavailable.
6. Output only the valid JSON object.

To adapt this prompt for your environment, replace the [INCIDENT_DESCRIPTION] placeholder with the actual incident narrative. You should also customize the approved taxonomies and regulatory lists to match your organization's specific compliance obligations and data classification policies. For high-risk production use, always pipe the generated JSON through a schema validator before ingestion into your incident management system. Implement a retry loop with a maximum of two additional attempts if validation fails, and log all failures for human review. This prompt is designed for single-turn structured generation; do not use it in a conversational context where the model might drift from the schema.

This prompt is designed to be called from a privacy incident response pipeline, not a free-text chat interface. The application layer should supply the incident narrative and known metadata (discovery timestamp, affected system, initial reporter) as [CONTEXT]. The prompt template expects a [DATA_CATEGORY_TAXONOMY] and a [REGULATORY_REQUIREMENT_MAP] to be injected at call time so the model can classify data types and flag relevant obligations without hallucinating legal references. In production, these taxonomies should be maintained as configuration files or database tables, not hardcoded in the prompt, so they can be updated when regulations change without retesting the entire prompt.

Wire the prompt into a structured output API call with response_format set to json_schema and a schema that enforces the data_categories, affected_subjects, regulatory_triggers, and discovery_timestamp fields. After receiving the model response, run a validation layer that checks: (1) every data_category value exists in the supplied taxonomy, (2) discovery_timestamp is ISO 8601, (3) affected_subject_count is a positive integer, and (4) every regulatory_trigger key maps to a known regulation in the requirement map. If validation fails, retry once with the validation errors appended to [CONSTRAINTS] so the model can self-correct. If the second attempt also fails, route the record to a human review queue rather than silently ingesting a malformed entry. Log every generation attempt—including the raw prompt, model response, validation result, and reviewer decision—as an audit trail for your own compliance evidence.

Model choice matters here. Use a model with strong schema-following behavior and low refusal rates on security-sensitive content. Avoid routing this prompt through general-purpose chat models that may append conversational disclaimers or refuse to classify breach data. If your deployment requires air-gapped or local-only processing, test the prompt against your chosen open-weight model with the same validation harness before relying on it in an incident. Do not bypass human review when the model flags a regulatory trigger you have not previously tested; a false negative on a notification obligation carries legal risk that no prompt eval can fully absorb.