Back to slim.io

Privacy Rights · GDPR

GDPR Article 15 & 17,
built in.

Data Subject Access Requests handled end-to-end. slim.io compiles subject access records, executes erasure cascades across every connected store, and generates cryptographically signed receipts — all via a single API call.

Article 15

Right of Access

Any data subject can request a full record of what personal data an organization holds about them. slim.io aggregates a SubjectAccessRecord across every connected cloud store, SaaS application, and database and returns it in a single response.

ART. 15

Subject access query

Identify a subject by email, SSN, phone, or a custom customer ID. slim.io runs a subject-hash lookup across all connected data stores and aggregates a complete SubjectAccessRecord. Subject identifiers are HMAC-hashed before storage — the raw identifier never persists.

1
Identifier normalization. The submitted identifier (email, SSN, phone, or custom ID) is normalised and HMAC-hashed into a deterministic subject_hash.
2
Cross-store lookup. slim.io queries the entity resolution index across all connected connectors. Matching findings are grouped by data store and resource type.
3
Record assembly. A SubjectAccessRecord is built with the set of stores the subject appears in, the entity types found, and the scan timestamps. Raw values are not included in the record.
4
Receipt generation. An Ed25519-signed Tier 1 receipt is generated for the access query. The receipt can be presented as proof that the request was processed.
POST /api/v1/dsar/lookup
// Request body
{
  "subject_identifiers": [
    {"type": "email", "value": "alice@example.com"}
  ]
}
// Response
{
  "identifier_count": 1,
  "records": [{
    "subject_hash": "hmac:sha256:a3f2c8...",
    "stores_found": ["s3://acme-data", "postgres://prod-db"],
    "entity_types": ["EMAIL", "SSN", "PHONE"],
    "receipt_id": "rcpt_art15_7f1a...",
    "processed_at": "2026-05-28T14:32:00Z"
  }]
}
Rate limiting: Access requests are rate-limited per tenant. The subject hash is the rate-limit key — repeated requests for the same subject within a window return a 429.

Article 17

Right to Erasure

A data subject can request that their personal data be erased. slim.io initiates an erasure cascade across every store the subject appears in, checks legal holds automatically, and writes an immutable audit entry for every action taken.

ART. 17

Erasure cascade

A single API call triggers a coordinated erasure across all connected data stores. slim.io chooses between graduated anonymization (replace with category label) or full deletion depending on your policy. Legal holds are checked automatically before any erasure fires.

1
Legal hold check. Before any erasure fires, slim.io checks whether an active legal hold covers the subject. If a hold exists, erasure is blocked and the request is queued until the hold is released.
2
Policy evaluation. Your erasure policy determines the action per data store and entity type: anonymize (replace with category label) or delete (hard delete the record or field).
3
Cascade execution. slim.io executes the erasure action on every store in the subject access record. Each store operation is attempted in parallel; partial failures are retried and reported.
4
Immutable ledger entry. An immutable audit entry is written for every store action. The entry records what was done, when, and by which principal. An Ed25519-signed receipt is attached.
POST /api/v1/dsar/erase
// Request body — multi-identifier intake (1–10 subjects per batch).
// `confirmation_token` is minted via POST /api/v1/dsar/confirmation-token
// and is bound to sha256(sorted(subject_hashes)) — order-independent.
{
  "subject_identifiers": [
    {"type": "email", "value": "jane@acme.co"}
  ],
  "confirmation_token": "f1a3...64-char-hex",
  "reason": "GDPR Art. 17 request #2026-0042"
}
// Response — BatchErasureResult; one per-subject `results` entry,
// all linked by a single `batch_id` for the audit trail.
{
  "tenant_id": "tenant-acme",
  "identifier_count": 1,
  "batch_id": "11111111-2222-4333-8444-555555555555",
  "results": [{
    "subject_hash": "hmac:sha256:a3f2c8...",
    "subject_type": "email",
    "receipt_id": "rcpt_art17_9c2d...",
    "ledger": {"ledger_id": "ldg_...", "tombstone_retention_days": 2557}
  }],
  "summary": {
    "findings_erased_total": 3,
    "tokens_revoked_total": 1,
    "systems_touched_union": ["s3://acme-data", "postgres://prod-db"]
  },
  "errors": []
}
Legal holds: Cascade per-subject errors are surfaced verbatim in the response’s errors array; the privacy officer reviews them and routes legal-hold-protected subjects through their internal hold-release workflow before retrying the erasure.

Proof

Verifiable Receipts

Every access query and erasure action generates an Ed25519-signed receipt with a three-tier chain-of-custody proof. Receipts can be verified entirely offline — no network call, no dependency on slim.io infrastructure being reachable.

Tier 1
Action receipt
An Ed25519-signed record of the specific DSAR action: who requested it, which identifier was queried or erased, which stores were affected, and when. Generated immediately at action time.
Tier 2
Batch attestation
A Merkle-tree root over all DSAR receipts produced in a time window. Proves that the individual receipt is part of an unmodified batch and has not been inserted or deleted retroactively.
Tier 3
Transparency log
The batch root is appended to a tamper-evident transparency log. An auditor can prove that a receipt existed in the log at a given time without access to any other receipts in the batch.
Chain of custody
T1
Action receipt — Ed25519 signature over (tenant_id, subject_hash, action, stores, timestamp). Immediately available on the API response.
T2
Batch Merkle root — SHA-256 Merkle tree over all receipts in the hour window. Proves the T1 receipt was included unmodified.
T3
Transparency log entry — Batch root appended to the tamper-evident log. Timestamp-anchored; auditable by any party with the public key.
Offline verification

Download a compliance bundle ZIP containing receipts, Merkle proofs, and the public key. Verify the entire chain without any network access using the open-source CLI.

# Install the verifier
pip install slim-receipts-verify
# Verify a bundle offline
slim-receipts-verify bundle.zip
# Output
✓ T1 Ed25519 signature valid
✓ T2 Merkle inclusion proof valid
✓ T3 transparency log entry verified
✓ All 1 receipt(s) in bundle verified
Open source verifier: The slim-receipts-verify Python package is published on PyPI and independently mirrors slim.io's signing primitives. It imports nothing from the slim.io monorepo. Source at tools/verifier-py/.

Quick reference

All DSAR endpoints

Authentication required. All requests must carry a valid slim.io bearer token with the MANAGE_DSAR permission. Designed for privacy officers and admin integrations, not customer-facing surfaces.

POST /api/v1/dsar/lookup
Look up 1–10 subjects in a single batch. Body: subject_identifiers: [{type, value}, …] where type is one of email / ssn / phone / customer_id. Returns a BatchAccessRecord with per-subject records and a T1 receipt.
POST /api/v1/dsar/erase
Initiate an Article 17 cascade across a multi-identifier batch. Body: subject_identifiers, confirmation_token (minted via POST /api/v1/dsar/confirmation-token), optional reason. Returns a BatchErasureResult with per-subject ledger rows linked by a shared batch_id.
GET /api/v1/dsar/receipts/{receipt_id}
Fetch a full receipt by ID, including T1 signature bytes and Merkle proof path for offline verification.