GDPR and data protection

How Obexal's two GDPR roles work, and the built-in tooling for data subject rights, minimization, retention and breach notification.

Obexal ships the tooling that data protection work relies on: export, deletion, minimization by design, an immutable audit trail and configurable retention. This page maps that tooling to the GDPR. It describes features, not legal advice.

Two roles under the GDPR

For the personal data of your tenant's end users, Obexal acts as a processor (article 28): it processes data on your instructions, and you remain the controller who determines purposes and legal bases. This relationship is governed by the Data Processing Agreement.

For its own data (customer accounts, billing, B2B contacts), Obexal is the controller, with the usual legal bases: contract performance for customer accounts, legal obligation for accounting, legitimate interest for securing the platform.

Data subject rights, mapped to features

The export is a single authenticated call:

curl https://accounts.obexal.com/v1/auth/account/export \
  -b "obexal_session=$SESSION"

It returns the user's profile, federated identities (provider and subject, never any provider secret) and MFA factor metadata. No secret is ever included: no password hash, no TOTP secret. Each export is written to the audit log.

Deletion (POST /v1/auth/account/delete) requires re-authentication (the current password, or the exact email address for passwordless accounts) and cascades across credentials, sessions, MFA factors, passkeys, consents and tokens. The audit record is written before the erasure, and the user.deleted webhook carries only the user id, never the email. SCIM deprovisioning is distinct: it deactivates the account (sessions become inoperative at once) without erasing it; see Inbound SCIM.

Data minimization

• The profile schema is limited to what SSO needs: name, display name, job title, department, locale. There is deliberately no date of birth field.
• Social sign-in stores only the link (provider, subject) plus the email. No provider access or refresh token is retained.
• Passkeys store a public key only; recovery codes and every one-time token exist server-side only as hashes.
• Compromised-password checks run against a local list: no email or password material leaves the platform.

Audit log and retention

The audit log is append-only and immutable (a database trigger rejects any update or delete). It records security-relevant events, including exports and deletions. Retention is configurable per deployment (AUDIT_RETENTION, 0 meaning unlimited): a daily purge removes entries older than the window, which limits storage duration without ever editing an entry. See Audit log.

Breach notification

As a processor, Obexal notifies the controller without undue delay after becoming aware of a personal data breach (article 33.2), with the elements the controller needs to notify its supervisory authority within 72 hours where required, and the data subjects when the risk is high. The operational procedure follows contain, preserve evidence, eradicate, restore, post-mortem.

Shared responsibility

This documentation describes the tooling. Overall compliance also depends on how you, as controller, configure and use it: determining legal bases, setting retention durations, answering data subjects (Obexal assists per article 28.3.e but does not respond to your end users directly), and running a DPIA where your context requires one. Sub-processors in the data path (hosting, SMTP relay) are EU-based; any addition is notified with a right to object, and at the end of the contract data is deleted or returned, at your choice. Details in the DPA.