Privacy — DSAR, retention & erasure attestations

For enterprise buyers accountable to a DPO, a regulator, or a contractual counterparty, privacy execution lives or dies on provability. It is not enough to have answered a subject access request, run a retention job, or deleted a record. You must be able to show — months later, to a skeptical reviewer with no access to your production systems — that the action was complete, timely, authorized, and bounded by the schedule and consent state that actually governed at the time.

The real cost of unprovable privacy execution

Most privacy programs are strong on policy and weak on proof. Retention schedules exist in a spreadsheet or a records register. Consent is captured in a CMP and mirrored — eventually — into downstream stores. DSARs are handled by a ticketing queue that fans out to system owners who each run a query, paste results into a bundle, and attest by email that they looked. In a demo this looks covered. Under audit it collapses.

Three costs follow. First, DSAR completeness cannot be defended. When a data subject asks what you hold, the answer requires knowing which systems were in scope, which lawful basis applied to each data category, what was withheld or redacted and why, and whether any replica, log, or backup was missed. If the only artifact is the export bundle itself, there is no independent record of the search that produced it. An auditor — or opposing counsel — will reconstruct the search adversarially and find the system you forgot to wire in last quarter.

Second, retention drifts without detection. Application teams implement retention as scheduled deletions or TTLs, each with its own clock, its own interpretation of the triggering event, and its own failure mode when a job stalls. The records register says invoices are kept seven years from booking. The object store still holds three prior system generations where the clock never started. Over-retention becomes the default, and no trail shows which schedule governed which record at which version. You cannot prove minimization if you cannot prove the clock.

Third, erasure is asserted, not attested. A deletion ticket closed in Jira is not evidence that every replica, cache, search index, analytical projection, and versioned backup honored the request — or that the attestation of erasure itself does not re-expose the data it claims to have removed. Legal needs a receipt that says erasure was executed, propagated, and verified, while retaining only a hash commitment of what was erased, not a copy of the sensitive payload.

These failures share a root cause: privacy was implemented as application behavior rather than as a gated, receipted control plane. The fix is to treat DSAR fulfillment, retention expiry, and erasure each as an attestation — a signed, hash-chained, policy-bound record that can be verified offline on your infrastructure.

DSAR as attestation — beyond the export bundle

Buyers often evaluate DSAR tooling by the quality of the export: a well-formatted package, deduplicated, with clear category labeling. The export matters to the data subject. The attestation matters to everyone else who will later judge whether the export was sufficient. Lorca Labs structures DSAR fulfillment so the export and its attestation are produced together, on your infrastructure, without requiring data to leave your custody for a vendor to generate proof.

A complete attestation answers seven questions at the moment of fulfillment. Who was the requester and how was identity verified, with what verification evidence hash? What declared purpose and lawful basis scoped the search, citing the policy pack version that was enforced? Which systems were queried, which returned hits, and which were correctly excluded — with per-system receipts? What categories were disclosed, redacted, or withheld, with a rule-path citation for each redaction? What retention state applied to each disclosed record — was it still within schedule, or was its retention clock already expired? What consent state applied at fulfill time, bound to the ledger entry hash? And what output commitment does the bundle carry so a reviewer can confirm the bundle has not changed since attestation?

This is where purpose binding and consent state change outcomes. A DSAR that pulls from a lakehouse view built from three upstream feeds will over-disclose if any feed contains data whose consent had been withdrawn before fulfillment. Without a Consent Receipt Ledger that emits a hash-bound receipt per consent action, fulfillment has no authoritative consent timestamp to check. Similarly, without a Retention Expiry Clock that carries the schedule version and per-record expiry, fulfillment cannot distinguish between data it must disclose and data it should already have erased.

The Subject Access Export component produces the DSAR attestation as a signed, hash-chained bundle on your infrastructure. Each system connector emits a per-store receipt — hit, miss, or excluded — chained to the authenticated request receipt and the policy gate receipt that authorized the scope. The final bundle hash is sealed and bridged to your evidence store. A reviewer who holds the bundle and its receipt chain can re-hash the export, replay the gate against the cited policy version, and confirm completeness of scope without accessing any production datastore. Try the flow in Studio against synthetic subjects before any production system is in scope.

Retention — the clock you can prove

Retention schedules fail at the binding between schedule text and record lifecycle. Legal writes that marketing profiles are kept 24 months from last active consent. Engineering sets a TTL on the profile document. Neither side can show — per record — that the same schedule version governed the same clock from start to expiry, or that the clock was paused, extended, or superseded by a hold.

The Retention Expiry Clock treats each schedule as a versioned, hash-addressed artifact deployed through your change control on your infrastructure. Enrollment binds a record to a schedule version and records the triggering event hash — booking, consent, contract end — so the start of the clock is itself receipted. Each evaluation emits a receipt: still retained with time-to-expiry, expired and queued for erasure, or held under litigation or regulatory hold with hold receipt citation. Because schedules are versioned, a record enrolled under v3 that is evaluated after v4 promotion still cites v3 until explicitly migrated, and that migration is itself a receipt. This is the property auditors expect and almost never find: continuity of governing version.

For buyers mapping to privacy and data protection obligations, the direct use is minimization evidence. Rather than asserting that retention is enforced, you present the clock receipts for a sampled population: enrollment receipt, periodic evaluation receipts, and expiry receipt with downstream erasure linkage. Verification replays clock evaluation deterministically against the cited schedule hash. Data residency is enforced by topology — clocks, schedules, and receipts never leave your infrastructure — and keys remain under your custody. Explore the schedule versioning and hold mechanics in Studio.

Erasure — attested without re-exposure

Erasure is where proof most often undermines its own purpose. Teams that build an erasure report by copying identifiers and payloads into a ticket or a log create a new store of the data they claim to have erased. Teams that simply delete and move on have no proof that survives the act. And teams that delete from the primary store but not from search indexes, caches, vector embeddings, analytical projections, or retained backups have not erased — they have relocated the risk.

The Erasure Attestation component separates the commitment from the content. At erasure time, the payload is hashed and the hash is retained in the receipt; the payload itself is removed. Propagation receipts are collected per replica and per downstream store — primary, replica, cache, index, projection, backup generation — each signed by the executor service under your key custody and chained to the initiating erasure receipt which itself cites the triggering DSAR, retention expiry, or consent withdrawal receipt. A backup that cannot be mutated immediately emits a deferred-erasure attestation bound to its rotation schedule, so the reviewer sees bounded retention rather than an unqualified claim of instant completeness.

Verification is hash-anchored and offline. A reviewer confirms that each store's erasure receipt commits to the same payload hash, that the hash chain from the expiry or request receipt through each propagation receipt is intact, and that signatures verify against keys under your custody. At no point does verification require the reviewer to handle the erased data itself. The attestation proves that what was erased matches what was committed, and that every committed downstream copy produced a receipt. Walk through the propagation model in Studio.

Consent and purpose — the boundaries that make the other two true

Retention and erasure answer when data may be held and how its removal is proven. Consent and purpose answer whether it should have been used at all — including during DSAR fulfillment itself. Both require receipts that can be cited by hash at decision time, not reconstructed from application logs afterward.

The Consent Receipt Ledger gives each consent action — grant, withdrawal, scope change, expiry — a signed, append-only receipt with purpose binding and ledger position. Any downstream action that discloses or processes personal data cites the ledger entry hash that authorized it at that moment. When consent is withdrawn, subsequent DSAR exports and analytical projections that still reference the earlier entry fail verification, which is the desired outcome: the ledger makes stale reliance detectable. Evaluate the ledger semantics in Studio.

These four components — Subject Access Export, Retention Expiry Clock, Erasure Attestation, and Consent Receipt Ledger — are designed to be evaluated independently and deployed together. Each runs on your infrastructure, each emits the same receipt-and-hash substrate, and each is available as a no-signup experiment at /studio including /studio/subject-access-export, /studio/erasure-attestation, /studio/retention-expiry-clock, and /studio/consent-receipt-ledger against isolated demo data.

Architecture — a gated lifecycle on your infrastructure

No diagram needed; the shape is a single lifecycle loop with four gates that all run on your infrastructure, whether that is a VPC, an on-prem cluster, or an air-gapped enclave. The same receipt chain carries a record from enrollment through expiry and erasure, so a reviewer never has to correlate separate logs.

Enrollment gates on intake. When personal data enters the environment — via application write, ingestion pipeline, or manual import — the intake gate requires a purpose declaration, a lawful-basis citation, a retention schedule binding, and a consent ledger reference if applicable. The intake receipt commits to the payload hash and cites the policy pack version and schedule version that governed enrollment. Data that cannot declare its retention binding is denied at intake rather than admitted with an ambiguous lifecycle.

Retention gates on time. The clock evaluates continuously and emits periodic receipts; expiry is an attested event, not a silent deletion. Expiry receipts cite the enrollment receipt, the schedule version, and the triggering consent state if relevant, and they enqueue a bounded erasure workflow with a deadline commitment.

Fulfillment gates on disclosure. Every DSAR or internal access that would disclose personal data is evaluated by a deterministic gate outside the application process. The gate checks purpose, schedule state, and consent ledger position at fulfill time and emits an allow or deny receipt with rule path before any data is read. Disclosure only proceeds on allow, and the disclosure receipt is chained back to the gate receipt and forward to the bundle commitment.

Erasure gates on propagation. The erasure workflow collects per-store receipts and verifies that each store's commitment matches the original payload hash. Deferred stores — such as immutable backups — produce bounded-retention attestations rather than false claims of immediate erasure. The completed chain — enrollment through erasure — is sealed and bridged to your audit infrastructure through a verifiable bridge that preserves hash commitments and signatures for offline verification without re-exposing payloads.

Sovereign controls are enforced by deployment topology, not by vendor promise. Keys never leave your custody, policy and schedule bundles are promoted through your change control with content hashes, and the entire loop can run without an outbound network path. See the cross-industry framing in /industries/privacy-and-data-protection for how this maps to organizational risk ownership.

Verification without trusting the application

Every attestation in this guide verifies the same way: re-hash, re-evaluate, re-chain. The reviewer holds the receipt bundle and the referenced policy, schedule, and ledger artifacts by content hash. Verification does not require access to the application that produced the data or to any production datastore.

1. Re-hash each payload, bundle, and schedule artifact; compare to the commitment in its receipt.
2. Walk the hash chain from enrollment through retention evaluations to DSAR or erasure; confirm every receipt cites its predecessor.
3. Re-evaluate each gate receipt — intake, disclosure, expiry — against the cited policy or schedule bundle version.
4. Check consent ledger citations: confirm the ledger entry hash cited at disclosure was the tip of the ledger at that timestamp.
5. Verify signatures against keys under your custody; check rotation and revocation.
6. For erasure, confirm every replica and deferred store produced a propagation receipt committing to the same payload hash.

Because commitments are hashes, the verification bundle respects minimization — reviewers confirm integrity without the bundle becoming a secondary store of personal data. And because verification is offline, audit sampling does not require live access to the production environment, which matters when systems are segmented by network or classification.

Where to start

For enterprise buyers, the practical entry point is not a platform migration. It is a bounded attestation pilot on synthetic data. Pick one DSAR category, one retention schedule with known over-retention risk, and one system pair that represents your primary-and-replica topology. Run intake, clock, disclosure, and erasure receipts end to end in Studio — Subject Access Export, Retention Expiry Clock, Erasure Attestation, and Consent Receipt Ledger — until your DPO and platform owner can verify the chain offline. Then replicate the same components on your infrastructure under NDA, with your keys and your schedule and policy change control, before any production data is in scope. The measures of readiness are simple: every in-scope system emits a receipt, every governed record cites its schedule version, and every erasure is attested without retaining the payload.

Buyers evaluating industry context can start from /industries/privacy-and-data-protection and map the same components to the surrounding control environment — including how attestation bundles are handed to existing audit, GRC, and evidence workflows without creating a new privileged data store.