Data Subject Access Request Fulfillment Prompt

This prompt is designed for privacy operations teams who need to automate the discovery, formatting, and exemption review of personal data in response to a Data Subject Access Request (DSAR). It instructs an AI system to locate all personal data related to a data subject across provided source records, structure it for disclosure, and flag any content that requires redaction or exemption under applicable regulations such as GDPR Article 15 or CCPA. The ideal user is a privacy analyst or engineer who has already retrieved candidate records from your data stores—via a search tool, database query, or RAG pipeline—and now needs the model to perform the final assembly and compliance check before human review.

Use this prompt when you have a batch of unstructured or semi-structured records (emails, chat logs, CRM notes, support tickets) that are likely to contain a data subject's personal information and you need a structured, auditable output. The prompt expects you to provide the raw source records as [SOURCE_RECORDS], the data subject's identifying information as [DATA_SUBJECT_IDENTITY], and the applicable regulatory framework as [REGULATORY_FRAMEWORK]. It will return a structured JSON object containing a list of discovered personal data items, their source locations, and any recommended exemptions with legal justifications. This output is designed to be fed into a review queue where a qualified privacy professional can approve, reject, or modify each finding before the final report is released to the data subject.

Do not use this prompt as a substitute for legal advice or as the sole decision-maker on exemption application. It is not designed for real-time, conversational DSAR intake from data subjects themselves—that requires a separate triage and identity verification workflow. Avoid using this prompt on records that have not been pre-filtered for relevance; feeding it an entire production database dump will produce noisy, expensive, and potentially incomplete results. The output must always be reviewed by a qualified privacy professional before release to the data subject. If your use case involves fully automated disclosure without human review, you are operating outside the safe boundary of this playbook and should reconsider your risk posture.

This prompt is designed to be deployed as a system instruction for an AI model that has access to a set of retrieved records for a specific data subject. Its primary job is to process those records against a DSAR, producing a structured disclosure report that identifies all personal data, formats it for the data subject, and applies necessary redactions based on defined exemptions. The prompt enforces a strict workflow: first, inventory all data points; second, map them to the request's categories; third, justify and apply any redactions; and finally, format the output for direct release. This is a high-risk compliance workflow, so the prompt is built to be auditable, requiring explicit reasoning for every piece of data that is withheld.

markdownCopy
# SYSTEM INSTRUCTION
You are a privacy operations assistant responsible for fulfilling Data Subject Access Requests (DSARs). Your task is to process a set of retrieved records for a specific data subject and produce a structured disclosure report. You must follow the rules below without exception.

## CORE RULES
1.  **Exhaustive Inventory:** Identify every instance of personal data related to the data subject in the provided records. Do not summarize or skip any data point.
2.  **Category Mapping:** Map each data point to the specific categories requested in [REQUEST_CATEGORIES]. If a data point does not fit a requested category, include it in an "Other Personal Data Found" section.
3.  **Exemption and Redaction:** For each data point, determine if an exemption under [APPLICABLE_REGULATIONS] applies. If an exemption is triggered (e.g., includes third-party personal data, legal privilege, or confidential trade secrets), you must redact it. You must provide a clear, specific reason for every redaction in the [REDACTION_LOG]. Never redact the data subject's own personal data unless it is inextricably linked to an exempt third party's data.
4.  **Structured Output:** Your final response must be a valid JSON object conforming to the [OUTPUT_SCHEMA] below. Do not include any text outside the JSON object.
5.  **No Assumptions:** If the provided records are insufficient to fulfill a part of the request, explicitly state this in the "Completeness Assessment" field. Do not infer or fabricate data.

## OUTPUT SCHEMA
```json
{
  "report_metadata": {
    "subject_identifier": "string",
    "request_id": "string",
    "generation_timestamp": "string (ISO 8601)",
    "completeness_assessment": "string (A statement on whether all requested data was found and any limitations.)"
  },
  "disclosed_data": [
    {
      "data_category": "string (e.g., 'Contact Details', 'Purchase History')",
      "data_points": [
        {
          "field_name": "string",
          "value": "string (The data value or '[REDACTED]')",
          "source_record_id": "string"
        }
      ]
    }
  ],
  "redaction_log": [
    {
      "data_point_reference": "string (A unique identifier linking to the redacted field)",
      "redaction_reason": "string (Specific legal or policy reason for redaction)",
      "applied_exemption": "string (The specific clause from [APPLICABLE_REGULATIONS])"
    }
  ]
}

CONSTRAINTS

• [REQUEST_CATEGORIES]: {{customer_support_transcripts, account_metadata, purchase_history}}

To adapt this template, replace the placeholders in the CONSTRAINTS section with your specific values. [APPLICABLE_REGULATIONS] should be a concise, machine-readable reference to the legal basis for exemptions (e.g., GDPR Art 15(4), CCPA 1798.105(d)). [REQUEST_CATEGORIES] must be a precise list of the data domains the subject has asked about. The [RISK_LEVEL] tag is a signal to your orchestration layer to enforce additional safeguards like human review. Before deploying, test this prompt with a golden dataset of records that includes known third-party PII and privileged information to validate that the redaction logic triggers correctly and that the JSON schema is strictly adhered to. A common failure mode is the model redacting the data subject's own information when it appears in the same record as a third party; your evals must specifically test for this over-redaction error.

This prompt is a single step in a larger Data Subject Access Request (DSAR) pipeline. It should never be the sole decision-maker for data disclosure. The model's output must be treated as a draft extraction and redaction proposal, not a final legal response. The implementation harness must enforce strict validation, source grounding, and human approval before any data leaves the system. The primary risks are incomplete data discovery (missing a system of record) and improper exemption application (disclosing data that should be redacted or redacting data the subject has a right to see). The harness must catch both failure modes before the response reaches the requestor.

Wire the prompt into a staged pipeline with these components: (1) Data Retrieval Layer: Before the prompt runs, execute deterministic queries across all registered data stores (CRM, support tickets, analytics, auth systems, logs) using the verified subject identifier. Do not rely on the model to decide where to search. The retrieved records become the [CONTEXT] input. (2) Prompt Execution: Run the DSAR prompt with the retrieved context, the jurisdiction's exemption rules, and the required output schema. Use a model with a large context window and strong instruction-following for structured outputs (e.g., GPT-4o, Claude 3.5 Sonnet). Set temperature=0 to minimize variance in redaction decisions. (3) Schema Validation: Parse the JSON output and validate it against a strict schema. Reject any response where subject_id doesn't match the request, where exemptions reference undefined exemption codes, or where data_categories contain records without a source_system trace. If validation fails, retry once with the validation errors injected into the prompt's [CONSTRAINTS] field. If the retry also fails, escalate to a human reviewer with the raw context and both failed attempts. (4) Completeness Check: Compare the data_categories in the model's output against the list of systems queried in step 1. If a queried system returned records but those records don't appear in any category, flag a potential omission. (5) Human Review Queue: Route all outputs with exemptions or redactions to a privacy analyst for approval. The reviewer sees the original records, the model's proposed redactions, and the cited exemption rationale. Only after human sign-off is the final report generated and sent to the data subject.

Log every step for auditability: the subject identifier, the systems queried, the raw model output, validation results, retry attempts, and the human reviewer's decision. This audit trail is essential for demonstrating compliance to regulators. Do not cache or reuse DSAR outputs across requests, even for the same subject, as data changes and consent status may have changed. Implement rate limiting on the DSAR endpoint to prevent abuse, and never expose the raw prompt output to the data subject without the human review gate. If the pipeline is processing a high volume of requests, consider a tiered approach: fully automated fulfillment for simple, no-exemption cases with a clear audit trail, and mandatory human review for any case involving exemptions, redactions, or multi-system data. The prompt itself should be version-controlled alongside the pipeline code, and any change to exemption rules or output schema must trigger a regression test against a golden set of known DSAR scenarios before deployment.