# GDPR & SOC 2 Compliance for LLM Logging: A Guide

> Navigate GDPR and SOC 2 requirements for LLM pipeline logging. Learn to separate audit trails from sensitive payloads for compliance and data privacy.

Published: 2026-09-21

Canonical: https://sygnet.ai/blog/gdpr-soc2-compliance-llm-logging

---

## Key takeaways

- The GDPR does not prohibit logging an LLM pipeline: it prohibits keeping the **payload** (prompt plus raw output) for as long as the audit trail. Separate the two layers and the conflict disappears.
- SOC 2 sets no fixed retention period; the framework does not mandate a specific duration, but six months is often treated as a minimum and many auditors prefer twelve months. It is auditors and your contractual commitments that set the bar, not the AICPA (American Institute of Certified Public Accountants).
- On the French side, the CNIL (Commission Nationale de l'Informatique et des Libertés, the French data protection authority) expects a minimum retention of 6 months, and the ANSSI (Agence Nationale de la Sécurité des Systèmes d'Information, the French cybersecurity agency) expects 12 months for security logs: a 6-to-13-month window satisfies both regimes.
- A right to erasure request is handled through crypto-shredding of the payload and irreversible anonymization of identifiers in the audit trail, not by deleting log lines.

## Why does logging an LLM pipeline create a GDPR / SOC 2 conflict?

Because both regimes target the same object with opposite clocks: SOC 2 wants intact evidence across the entire observation window, while the GDPR wants erasure as soon as the purpose has expired. The SOC 2 auditor demands the full observation window plus a buffer, the security lead wants twelve months to be able to reconstruct an incident, and the European tenant wants logs deleted as soon as they are no longer necessary.

The trap specific to extraction pipelines: the prompt **contains** the document. For a payslip, an ID document or a bank statement, the prompt embeds the French social security number (NIR), IBAN, address, date of birth. A standard request log therefore becomes an uncontrolled copy of your sensitive data, sitting outside your primary storage system, often replicated into a third-party SIEM (Security Information and Event Management system).

And the log itself is a form of processing. Logs contain personal data (login, IP address, timestamp) and must therefore appear in the record of processing activities and be disclosed to users. The legal basis is generally legitimate interest under Article 6(1)(f), or legal obligation where a sector-specific rule requires it.

> An extraction pipeline's prompt is not technical metadata: it is the document itself, copied straight into your observability stack.

## What exactly should you log?

Log the **shape**, not the content. An auditable extraction pipeline needs: request ID, document hash, model and prompt template version, output schema version, per-field confidence scores, latency, token cost, any human decision, and the identity of the caller. None of these values require the prompt text.

This is exactly what SOC 2 criteria test for. CC7.1 and CC6.1 require that security-relevant events be logged in enough detail to support an investigation, with minimum coverage including authentication, privileged access, data access, configuration changes and API calls, and logs that are tamper-resistant and stored separately from the systems that generate them. None of this requires retaining the request body.

For cases where you do want content (debugging an extraction regression, disputing a field), keep only the fragment that justifies the extracted value, along with its position on the page. This is the principle behind [field-level provenance](https://sygnet.ai/glossary/field-level-provenance): a bounding-box-and-page anchor is enough to replay a decision without storing plaintext PII (personally identifiable information) in the log.

## Two layers, two retention periods: how do you calibrate them?

Separate a PII-free "audit" layer, kept long, from a "payload" layer with PII, kept short and encrypted under a disposable key. The audit layer can live for 13 to 15 months without any GDPR difficulty as long as it is genuinely de-personalized; the payload layer lives for 7 to 30 days.

SOC 2 specifies no exact duration, but auditors expect logs to cover the entire observation window plus a reasonable buffer: for a twelve-month Type II report, at least fifteen months of audit data. On the CNIL side, the benchmarks are more granular: 6 months for standard access logs, 1 year for security logs, 1 year for access to health data, up to 3 years for fraud detection, beyond which logs must be deleted or anonymized.

| Layer | Content | Target duration | Legal basis / rationale |
|---|---|---|---|
| Audit trail (hash, versions, scores, actor) | no document PII | 13-15 months, WORM (Write Once, Read Many) | Art. 32 GDPR + SOC 2 Type II window (12 months + 3-month buffer) |
| Encrypted prompt/output payload | PII in plaintext once decrypted | 7-30 days | Legitimate interest: debugging, quality (Art. 6(1)(f)) |
| Evaluation sample (golden set) | PII, minimized or synthetic | duration of the project | consent / anonymization |
| Deletion log (DSR, Data Subject Request) | request ID + timestamp | 3 years | proof of execution under Art. 17 |

A two-tier archiving approach is recommended: an indexed, queryable hot store for 30 to 90 days, then an encrypted cold archive for the remainder of the retention period, with restoration available on justified request. This applies to extraction logs as well.

## How do you honor a right-to-erasure request without breaking the audit trail?

Through crypto-shredding of the payload and irreversible anonymization of identifiers in the audit trail. The log line survives, the person is no longer in it.

An audit log often needs to survive for security and accountability reasons, even though it names the person to be erased: removing or irreversibly hashing the identifiers keeps the log useful while taking it out of GDPR scope, whereas pseudonymization, where a key still allows re-identification, is not sufficient. Concretely: an encryption key per subject (or per case file), stored in a KMS (Key Management System). Erasure means destroying the key. The encrypted blob that remains in your WORM bucket is no longer usable personal data, and your hash chain remains verifiable.

Second reflex: refuse cleanly when a rule requires it. Article 17(3)(b) allows data to be retained that would otherwise be erasable when a legal obligation requires the processing, and Article 17(3)(e) allows retention necessary for the establishment, exercise or defense of legal claims. Watch the limit here: "keeping it for future audits" does not hold up legally; you need a precise legal provision requiring the retention of specific data for a specific period. A SOC 2 report is contractual, not legal. You cannot use your auditor's requirements as grounds to refuse a data subject.

If you do refuse, cite the exact Article 17(3) exception in your response, remind the individual of their right to lodge a complaint with the supervisory authority, and respond within one month (with a reasoned notice before the deadline if you extend it).

> A SOC 2 report is a contractual commitment, not a legal obligation: it is never sufficient grounds to refuse an erasure request.

## What do model providers do with your prompts?

By default, they keep them. Abuse-detection logs can contain prompts and responses, and are generated by default for any API usage, then retained for up to 30 days unless longer retention is required by law. Eligible customers can have their content excluded via Zero Data Retention or Modified Abuse Monitoring, subject to prior approval and additional requirements.

This is not an absolute guarantee. At Anthropic, flagged sessions can be retained for up to two years, even under ZDR (Zero Data Retention). On Azure, ZDR and modified abuse monitoring require approval and are reserved for customers under an Enterprise Agreement or Microsoft Customer Agreement: these are not self-service settings.

Practical consequence: your record of processing activities must list this sub-processor-side retention, your DPA (Data Processing Agreement) must reflect it, and your impact assessment must explain why you accept it. If you cannot accept it (healthcare, KYC, know-your-customer checks), the right lever is upstream: [redact PII](https://sygnet.ai/glossary/pii-redaction) before the call, or send only the relevant page area. The broader trade-off is covered in our [build versus buy comparison for IDP](https://sygnet.ai/build-vs-buy-idp) (Intelligent Document Processing).

## Which technical controls make all of this auditable?

Five mechanisms, all verifiable by an auditor in half a day. One: integrity. The CNIL recommends timestamping and signing logs at the moment of creation and storing them in a segregated manner, and hash chaining provides an integrity guarantee that simple base permissions cannot. Two: Object Lock / WORM on the archive bucket, along with the configuration snapshots an auditor will ask for. Three: break-glass access. Set up an exceptional access procedure with traceability and validation, and log access to the logs themselves.

Four: prove deletion, don't just promise it. Log retention actions themselves, both archiving and deletion, and track deadlines to verify that deletions actually occur on schedule. Five: backups. Document the retention window of your backups and make sure the restoration procedure re-applies any pending deletions. This is the most common gap: the DSR gets executed in the database, then a restore brings the data back to life.

Sygnet applies this split in production on documents such as [payslips](https://sygnet.ai/documents/payslip) and [bank statements](https://sygnet.ai/documents/bank-statement); the details of the controls and retention periods are published on its [security and compliance](https://sygnet.ai/security) page.

## FAQ

### Can we keep LLM prompts for 12 months to satisfy a SOC 2 audit?

Not plaintext prompts containing PII. SOC 2 sets no fixed duration, and auditors test the audit trail, not the business content. Keep a PII-free audit trail (hash, versions, scores, actor, signed timestamp) for 13 to 15 months, and limit the payload to 7-30 days under a destructible key. No auditor will ask you for the text of a prompt from a request made back in March.

### Is hashing a prompt enough to fall outside the scope of the GDPR?

No, if it remains reversible or re-identifiable. Pseudonymization, where a key still allows re-identification, does not count as erasure. A document hash (SHA-256 of the file) is acceptable as an integrity identifier, but hashing a low-entropy field, an IBAN or a date of birth, can be reversed by brute force in a matter of seconds. Salt it with a key that gets destroyed upon erasure, or delete the field.

### How should you respond to an erasure request concerning data extracted from an invoice?

Distinguish the accounting record from the log. The invoice is subject to a legal retention obligation: Article 17(3)(b) allows data to be retained where a legal obligation requires the processing. Prompts, intermediate outputs and evaluation samples, however, carry no such obligation and must be deleted. Keep only the narrow slice covered by the exemption, delete or anonymize the rest, and document which exemption covers what.

### Do employees need to be informed about pipeline logging?

Yes, as soon as the logs track the activity of validation operators. Articles 12 and 13 require informing users of the existence of the system, its purposes, the data recorded and the retention period, typically through the IT charter, and require informing and consulting the CSE (Comité Social et Économique, the French employee representative body) whenever the system constitutes a means of monitoring employee activity. A line in the IT charter and a documented CSE briefing are generally sufficient.