GDPR Compliance

What your instance provides for the General Data Protection Regulation (GDPR): giving a person a copy of their data, erasing it, recording their acceptance of your terms, and protecting it in storage.

Data Privacy & Control

GDPR sets rules for collecting, using and erasing personal data. These are the parts of Zonitix you use to follow them:

Terms Acceptance (GDPR Article 7)

Zonitix records each person’s acceptance of your terms and privacy policy, and asks for it at sign-in:

If something here is not working as you expect, start with When something goes wrong.

How A Data Request And An Erasure Run

The steps on screen are in the guide Handle a personal-data request. This section gives the endpoints behind them and what each one returns.

GDPR Articles 15 (access) and 17 (erasure) are served by concrete endpoints on your instance, reachable through the gateway under /api/v1/user-management. All are audited. None of them runs on a schedule — employee erasure is an operator action, not a background purge (see the invariants at the end). Candidate records are the exception: a separate recruitment-side retention sweep can purge non-hired candidates automatically once a retention period is set.

Right Of Access — Self-Service Export

GET /users/me/export is gated only by having a valid session — there is no :id parameter to point at someone else. The handler reads req.user.id from the trusted x-user context the gateway injects, so it can only ever return the caller’s own record. The response embeds the consent record: acceptedTerms / acceptedTermsAt travel inside profile.attributes. Every call writes a PEOPLE_DATA_EXPORTED audit entry (kind: "dsar_self").

Scope to check as an inspector: the controller assembles the response from an explicit field allowlist, so it carries no password hash, no MFA secret and no recovery codes — those columns are never selected into the payload. recentAuditLogs is filtered to rows whose userEmail equals the caller’s, newest first, capped at 200. A missing profile row returns 404.

crossServiceData is what the other services on your instance hold about the person: e-signature records, devices they own, onboarding / offboarding task data, compliance assignments, the candidate record they were hired from, finance directory and budget-comment entries, and SaaS-usage observations. It is gathered best-effort: a store that could not be reached is named in notes rather than silently left out, so check that list is empty before you treat an export as complete.

Right Of Access — Admin Export For Someone Who Cannot Sign In

A terminated or offboarded employee cannot authenticate to run the self-service export. GET /users/:id/export (manage_users) is the admin-on-behalf path: it loads the subject by id whatever their status, returns the same structure including crossServiceData, and reports the subject’s permissions, not the admin’s. It writes PEOPLE_DATA_EXPORTED at warning level with kind: "dsar_admin" and the acting admin, so it is never confused with a self-service export in an access review.

Right Of Access — Candidate Export

Candidates have no login. Recruitment staff produce a full per-subject export from GET /candidates/:id/data-export (manage_recruitment): profile, contact details, interviews, offer terms, the message thread and the signed offer document, as one audited JSON file.

Right To Erasure — Delete, Or Anonymize

Erasure of an employee account is DELETE /users/:id, gated by the manage_users permission. The account must already be offboarded: an account whose status is still active is refused with 409, because offboarding is what revokes access and deprovisions connected accounts. There are then two successful outcomes. Where nothing else references the row, it is genuinely deleted (the User model is not a soft-delete model, so this is a real SQL DELETE) and the call returns 204 No Content with a USER_DELETED audit entry. Where history that must be kept still references the account (audit records, tasks, approvals), the row cannot be deleted, so it is anonymized instead: name, email, phone, employee id, photo, position, department and attributes are overwritten or cleared, roles and groups are removed, sign-in is disabled, and the status becomes deleted. That returns 200 with { "anonymized": true, "crossServiceErasure": ... } and a USER_ANONYMIZED audit entry. The erasure’s own audit entry records a keyed pseudonym for the subject, not their email.

Export All Company Data

Separate from per-person exports, an administrator can take a copy of everything on the instance from Security Settings → Data export. It is available on every plan. The export is built in the background as a ZIP, held encrypted on your instance, and expires after 24 hours. To download it you mint a link that works once, for 15 minutes, and only for the administrator who minted it.

This is gated on the administrator role itself rather than a permission, so it cannot be delegated by granting a permission to another role. Starting an export, minting a link and every download are written to the audit log.

Encryption & Storage Security

Zonitix implements technical safeguards under GDPR Article 32. To be precise about scope: the transparent field-level AES-256-GCM encryption below covers authentication secrets and integration credentials, plus the highest-sensitivity recruitment fields specifically — an offer’s salary and a candidate’s phone number — which are encrypted at rest in dedicated cipher columns. Candidate and employee records are not column-encrypted wholesale (a candidate’s email, for instance, stays in clear so account matching still works); those rely on access control and single-tenant isolation:

Technical Consent Tracking Flow

When a user logs in, the authentication controller checks for the presence of a consent signature and stores the verification. The check runs in the identity service during login, not at the gateway. Accepting writes acceptedTerms, acceptedTermsAt and acceptedTermsVersion to the user’s profile attributes and raises a TERMS_ACCEPTED audit entry; no user-facing endpoint edits these fields. Without a session, no downstream endpoint is reachable: