GDPR Compliance Report Parsing Prompt Template

This prompt is designed for privacy engineering teams that need to convert unstructured GDPR compliance reports—such as Records of Processing Activities (ROPA), Data Protection Impact Assessments (DPIAs), and breach notifications—into machine-readable, structured outputs. The primary job-to-be-done is mapping natural language obligations to specific GDPR articles with verifiable source citations, enabling downstream ingestion into compliance management systems, audit trails, and regulatory review dashboards. The ideal user is a technical privacy engineer or compliance automation developer who understands the GDPR's structure and needs outputs that a system can validate, not just a human can read.

You should use this prompt when your pipeline must distinguish between controller and processor obligations, detect cross-border transfer mechanisms, and validate extracted article references against the actual GDPR text. Generic extraction prompts fail here because they treat 'Article 28' as just another string, missing the legal implication that a missing processor agreement field is a compliance gap. This template explicitly instructs the model to flag missing required fields—such as a absent Data Protection Officer contact in a ROPA—and to produce a structured missing_fields array that your application can route for human review. Concrete implementation requires you to supply the full source document text as [INPUT] and a strict [OUTPUT_SCHEMA] defining the expected JSON structure for obligations, articles, and evidence.

Do not use this prompt for general document Q&A, summarization, or non-GDPR privacy laws like the CCPA or LGPD without significant adaptation of the article reference constraints. It is also not a replacement for legal advice; the output is a structured extraction that requires human verification before being treated as a definitive compliance record. Before wiring this into production, ensure you have a validation layer that checks the output schema, confirms article references exist in the GDPR, and logs any missing_fields for your compliance team's review queue. The next step after reading this section is to copy the prompt template, adapt the [OUTPUT_SCHEMA] to match your system's data model, and run it against a set of known DPIAs to establish baseline accuracy before integrating it into your automated pipeline.

This prompt template is designed to parse a GDPR compliance report—such as a Data Protection Impact Assessment (DPIA), Record of Processing Activities (ROPA), or breach notification—into a strict JSON schema. It instructs the model to map findings to specific GDPR articles, cite evidence by section, and explicitly flag missing required fields. The template uses square-bracket placeholders that you must replace with your specific document text, desired output schema, and operational constraints before use.

textCopy
You are a regulatory compliance extraction engine. Your task is to parse the provided GDPR compliance document into a structured JSON output.

[INPUT]
The full text of the GDPR compliance document to be parsed.

[OUTPUT_SCHEMA]
{
  "document_type": "string (e.g., 'DPIA', 'ROPA', 'Breach Notification')",
  "controller": {
    "name": "string | null",
    "contact_details": "string | null",
    "data_protection_officer": "string | null"
  },
  "obligations": [
    {
      "gdpr_article": "string (e.g., 'Art. 35')",
      "description": "string",
      "status": "string (e.g., 'Compliant', 'Non-Compliant', 'Partial', 'Not Applicable')",
      "evidence_citation": "string (exact section or paragraph reference from the document)",
      "missing_fields": ["string"]
    }
  ],
  "high_risk_flags": ["string"],
  "extraction_confidence": "string (e.g., 'High', 'Medium', 'Low')"
}

[CONSTRAINTS]
1. Map every finding to a specific GDPR article (e.g., 'Art. 5', 'Art. 32'). If an article is implied but not explicitly stated, note this in the 'evidence_citation' field.
2. For the 'controller' object, if any field is not found in the document, set its value to `null` and add the field name to a top-level 'missing_controller_fields' array.
3. If the document type cannot be determined, set 'document_type' to 'Unknown'.
4. Do not invent data. If a status is unclear, use 'Indeterminate' and explain why in the evidence citation.
5. Base all 'evidence_citation' values on verbatim section headers, paragraph numbers, or direct quotes from the document.

[RISK_LEVEL]
HIGH. This workflow handles legally significant compliance data. All outputs must be traceable to source text. A human compliance officer must review all 'Non-Compliant', 'Partial', and 'Indeterminate' findings before any downstream action.

To adapt this template, replace the [INPUT] placeholder with the full text of a single compliance report. The [OUTPUT_SCHEMA] is a starting point; you should extend it to match your organization's specific data model, such as adding fields for processor details, cross-border transfer mechanisms, or retention periods. The [CONSTRAINTS] section is critical for preventing hallucination—always include explicit instructions for null handling and evidence citation. Before deploying, run this prompt against a golden dataset of 20-30 annotated reports and measure exact-match accuracy for article mapping and missing-field detection. Any output where extraction_confidence is 'Low' or where high_risk_flags is non-empty must be routed to a human review queue, not automatically ingested into a system of record.

This prompt is designed to be a single step in a larger document processing pipeline. It expects pre-extracted text from a GDPR-related document (such as a Data Processing Agreement, DPIA, or breach notification) and a strict JSON schema to populate. The application layer is responsible for document ingestion, text extraction, and post-processing validation. Do not send raw PDF bytes to this prompt; use a dedicated document parser to extract clean text first. The prompt's primary job is structured reasoning and citation, not OCR or layout analysis.

The implementation harness should enforce a strict contract around the prompt's input and output. Before calling the model, validate that the [INPUT_TEXT] is not empty and does not exceed the model's context window after combining it with the [OUTPUT_SCHEMA] and [CONSTRAINTS]. After receiving the model's response, run a multi-stage validation pipeline: (1) parse the JSON and check for schema conformity, including required fields like controller and processor; (2) validate that all article_references map to real GDPR articles (e.g., Art. 5, Art. 28, Art. 32) using a hardcoded lookup table; (3) check that every evidence object contains a non-empty citation string. If any validation stage fails, log the failure with the raw output and the specific validator that tripped, then execute a retry. The retry prompt should include the original input, the failed output, and a specific error message from the validator (e.g., 'Missing required field: processor.contact_info'). Limit retries to two attempts before escalating to a human review queue.

For high-risk documents like Data Protection Impact Assessments (DPIAs) or breach notifications, a human-in-the-loop gate is mandatory. After successful schema validation, route any output where a risk_level field is 'high' or where cross_border_transfers is true to a manual review interface. This interface should display the extracted JSON side-by-side with the original source text, highlighting the specific citations. The reviewer can approve, reject, or amend the extraction. Approved records can be written to the compliance database; rejected records should be logged as training examples for future prompt refinement. Use a model with strong structured output capabilities (such as GPT-4o or Claude 3.5 Sonnet) and set a low temperature (0.1-0.2) to maximize deterministic schema adherence. Log every prompt version, input hash, output, validation result, and reviewer action for auditability.