Privacy & data-subject requests

Under GDPR, you are the controller for your end users’ data and Oclavex is your processor. End users file privacy requests with you; your administrators forward them into Oclavex, which executes them across the platform’s data stores.

There are no end-user privacy endpoints by design — identity verification is yours (you know your customers), so filing is an admin operation.

How a request flows

1. Your support desk verifies the subject’s identity through your own channel.
2. An administrator files the request — portal Compliance → Privacy requests, or POST /api/v1/privacy/admin/data-subject-requests with the subject’s email.
3. The request starts as Approved (your verification is the approval) and executes asynchronously across the platform. Four kinds are supported: access, portability, rectification and erasure.
4. When it finishes it moves to Completed: access and portability requests produce a downloadable export; rectification applies the corrected values; erasure requests additionally emit a User.Erased webhook event so your CRM and downstream systems can react.

A request still in progress at the 30-day deadline does not auto-complete — it moves to EscalatedManual, a manual queue where an operator finishes it by hand, so an overdue request is flagged rather than sitting unnoticed.

An unfounded or unverifiable request can be rejected only before execution starts: POST .../data-subject-requests/{id}/reject with a reason. Filing starts execution at once, so screen the request before filing it. List and inspect requests with GET /api/v1/privacy/admin/data-subject-requests (scopes: privacy.read to view, privacy.write to file and reject).

Automate on the lifecycle

Subscribe to the webhook events DataSubjectRequest.Filed, .Approved, .Rejected, .Completed and User.Erased to keep your ticketing system in sync without polling.

What erasure erases — and keeps

Erasure removes or de-identifies the subject’s personal data. A few records are deliberately retained in de-identified form, on documented legal bases:

• Audit records survive, with the user reference replaced by an irreversible pseudonym — the trail stays intact without identifying anyone.
• License and usage records needed for integrity and fraud prevention are likewise pseudonymized rather than dropped.
• Profile data and outbound messages to the subject are deleted outright.

If the person returns and is erased again, earlier pseudonymized records stay unlinkable.

User.Erased is announced only when every data segment erased successfully. A partially-failed erasure still completes — the request lists the failed categories for follow-up — but the announcement is withheld, so downstream systems never act on an erasure that isn’t fully done.

Processing activities (Art. 30)

The register of processing activities — per data category: the lawful basis, retention period and recipients — is viewable in the portal under Compliance → Processing activities, ready to fold into your own Art. 30 records as the processor’s contribution.