DSAR + Right-to-Erasure

IdentityMesh ships two admin endpoints that customers’ Privacy / DPO teams use to satisfy Data Subject Access Request (DSAR) and right-to-erasure obligations under GDPR / CCPA / similar regimes.

The unit of identity is the anchor — the customer-chosen stable identifier that links a real person across all of IdentityMesh’s schema (typically UPN, employee number, or email). DSAR returns everything stored against an anchor; erasure removes the PII-bearing rows, sets an erasure marker, and writes a cryptographically-chained audit row recording the act.

Key principles

1. Audit history is preserved on erasure. Audit rows are the evidence that erasure happened — destroying them would defeat the compliance story. Before/after counts of the deleted PII rows are stamped into the audit row’s BeforeJson.
2. The MeshObject row survives with an ErasedAtUtc timestamp so subsequent DSARs surface the act-of-erasure (anchor exists, was erased on date X) rather than returning “no such subject”.
3. Erasure is idempotent. Calling erase twice against the same anchor returns zero counts on the second call and surfaces the original ErasedAtUtc so the historical truth is preserved.
4. Upstream systems are not touched. IdentityMesh erase deletes only its own copy of the data; the customer’s DSAR program independently runs against each connected source system. This is the customer-vs-product split for subject-rights work.

Endpoints

POST /api/admin/dsar/{anchor} — subject access

Returns the full set of mesh objects, attributes, connector-space rows, and audit history for the subject keyed by anchor.

curl -X POST https://identitymesh.example.com/api/admin/dsar/alice@example.com \
     -H "Authorization: Bearer $TOKEN"

Response shape:

{
  "anchor": "alice@example.com",
  "erasedAtUtc": null,
  "meshObjects": [...],
  "attributes": [...],
  "connectorSpaceObjects": [...],
  "auditHistory": [...]
}

When the subject was previously erased, erasedAtUtc carries the erasure timestamp and attributes is empty (the attribute rows were hard-deleted; the audit history that accompanies the erasure event remains).

Permission: dsar.read. Recommended to grant only to a Privacy role separate from day-to-day operator roles.

DELETE /api/admin/erase/{anchor} — right to erasure

Erases the subject’s data:

1. Hard-deletes rows from IM_MeshObjectAttributes for the subject.
2. Hard-deletes rows from IM_ConnectorSpaceObjects for the subject.
3. Sets IM_MeshObjects.ErasedAtUtc = SYSUTCDATETIME() for each mesh object owned by the anchor.
4. Writes an ErasureRequest row to IM_AdminAudit with the pre-erasure counts in BeforeJson and the timestamp + counts in AfterJson. That row is hash-chained per audit-chain.md, so the act-of-erasure is itself non-repudiable.

curl -X DELETE https://identitymesh.example.com/api/admin/erase/alice@example.com \
     -H "Authorization: Bearer $TOKEN"

Response:

{
  "anchor": "alice@example.com",
  "objectCount": 1,
  "attributeRowCount": 12,
  "connectorSpaceCount": 3,
  "erasedAtUtc": "2026-04-26T14:33:21Z"
}

Permission: dsar.erase. The admin-audit middleware auto-records every call (including denied ones) so the audit trail covers “who tried” as well as “who succeeded”. The middleware was extended to recognise the .erase policy suffix alongside the existing .write / .execute suffixes.

Operator workflow

The recommended operational pattern for handling a subject request:

1. Receive the request from your Privacy team via your existing request-tracking system.
2. Verify identity out-of-band (the IdentityMesh API itself doesn’t authenticate the data subject — that’s your Privacy process’s job).
3. Run DSAR against IdentityMesh + every connected source system independently. Compile the responses into the package delivered to the subject.
4. For erasure: run the IdentityMesh erase, then trigger erasure in each connected source system per its native procedure (Entra user delete, AD object disable+expire, Okta deprovision, etc.).
5. Document the erasure in your privacy-request-tracking system, including the IdentityMesh IM_AdminAudit row identifier so an external auditor can correlate the request to the non-repudiable proof of action.

Permissions

The two new permissions slot in alongside the existing 21:

Don’t grant either to the default operator role. The Privacy team needs distinct entitlements precisely so that day-to-day administrative reach doesn’t carry data-subject-deletion authority.

Compliance mapping

Audit rows for the subject are preserved per the retention policy in audit-retention.md — typically 7 years for compliance evidence, overridable per customer policy. The retained audit rows do not contain PII (they reference the anchor + timestamps + actors, not the deleted attribute values).

Related

• audit-chain.md — the hash chain that makes the erasure marker non-repudiable.
• audit-retention.md — how long erasure audit rows survive.
• siem-integration.md — forward the ErasureRequest audit rows to your SIEM for an additional layer of independent retention.
• secrets-and-dpapi.md — secret store context (separate from subject data).