Data Processing Addendum

This Addendum forms part of the Terms of Service between you ("Controller") and Quathos LLC ("Processor") and applies whenever we process personal data on your behalf through Quathos Auth — in particular the personal data of the end users who sign in to your applications through the pages we host for your tenant. Where it conflicts with the Terms, this Addendum prevails on data protection matters.

1. Roles

You are the controller of the personal data of your tenant’s end users and you decide its purposes and means. We are the processor (operator, under the LGPD) and act only on your documented instructions. Using the product is how you instruct us: creating a tenant, registering an application, enabling a sign-in method, defining a profile field, configuring a webhook and calling the Management API are all instructions. We will tell you if an instruction appears to breach applicable data protection law, and we may pause that instruction until it is resolved. For the data of your own administrators who use the console, we are the controller, as described in the Privacy Policy.

2. Our obligations

• Process personal data only for the purposes of providing the service, and never for our own purposes, for advertising, or to train models.
• Bind everyone with access to a duty of confidentiality, and limit access to those who need it to do their job. Our operators cannot reach data across tenants without a session authenticated with a second factor, and every such access is audited.
• Keep the technical and organisational measures described in Annex II, and not weaken them during the term.
• Assist you with data subject requests — access, correction, deletion, portability — with data protection impact assessments and with consultations with authorities, in each case taking into account the nature of the processing and what we actually have. Most requests you can fulfil yourself from the console or the Management API; for the rest, we answer within 10 business days.
• Forward to you, without answering it ourselves, any data subject request we receive that concerns your tenant.
• Notify you without undue delay of any personal data breach affecting your tenant: an initial notice within 24 hours of becoming aware, and a detailed one — what we know, what we are doing about it and what we suggest you do — within 72 hours, so that you can meet your own deadlines towards authorities and data subjects. We keep updating you as we learn more.

3. Subprocessors

You give general authorisation for the subprocessors listed on our Subprocessors page, which is incorporated here by reference. We impose on each of them, by written contract, obligations no weaker than these, and we remain fully responsible to you for what they do. We announce a new or replacement subprocessor at least 30 days before it starts processing; if you reasonably object on data protection grounds within that window, you may terminate the affected part of the service and receive a pro-rata refund of the unused prepaid cycle. Parties you connect yourself — your applications, your webhooks, external identity providers you federate with — are not our subprocessors.

4. International transfers

Your tenant’s data is stored at rest with Hetzner Online GmbH in Germany (Falkenstein and Nuremberg). Where processing nonetheless involves a transfer out of the EEA, the UK or Brazil to a country without an adequacy decision — because we are established in the United States, or because a subprocessor is — the parties adopt the European Commission’s Standard Contractual Clauses (Module Two, controller to processor), with the UK International Data Transfer Addendum where the UK GDPR applies, and the corresponding instruments recognised by the ANPD for Brazilian data. Those clauses are incorporated here by reference, with this Addendum and its annexes supplying the information their appendices require.

5. United States privacy laws

For personal information subject to California law, we act as a "service provider" and equivalent roles under other state laws. We do not sell or share it, we do not retain, use or disclose it outside the direct business relationship or for any purpose other than performing the service, and we do not combine it with personal information from other sources except as those laws permit. We certify that we understand and will comply with these restrictions.

6. Audits

On request, we provide the information reasonably necessary to demonstrate compliance with this Addendum, including the Security page and any third-party assessment we obtain. Where that is not enough for your regulator or your own obligations, you may audit us — or appoint an independent auditor who is not our competitor — once per year, on 30 days’ notice, during business hours, without disrupting the service and without accessing other tenants’ data. Your own audit trail and authentication logs are available to you at any time and answer most of what an audit asks.

7. Return and deletion

During the term you can read and export your tenant’s data through the console and the Management API. When the agreement ends, we return your tenant’s data on request, in a machine-readable format, for 30 days; after that window we delete it, except what law requires us to keep and what remains in backups until they rotate out, within a further 30 days. Password hashes and second-factor secrets are returned only in the hashed or encrypted form we hold them in — they are never readable, to us or to anyone. We do not restore a backup to recover data you asked us to delete.

Annex I — Details of processing

Annex II — Technical and organisational measures

• Tenant isolation enforced by row-level security in the database, enabled and forced on every identity table, with the application connecting through a role that cannot bypass it. The tenant is derived from the hostname that received the request — never from a parameter, header or token supplied by the client — and a transaction without a tenant in context sees no rows at all.
• One signing key pair per tenant (RSA-2048, RS256), with the private key encrypted at rest under a key held outside the database, published through a per-tenant JWKS, rotated automatically every 90 days and retired 48 hours after its successor takes over.
• Passwords hashed with argon2id, with constant-time behaviour on unknown accounts so that a sign-in attempt does not reveal whether an email exists. Second-factor secrets encrypted at rest with purpose-separated keys; recovery codes and every token we issue — session, refresh, authorisation code, device code, client secret — stored only as hashes.
• Refresh tokens rotated on every use, in families: presenting an already-rotated token revokes the entire family and records the reuse. Authorisation codes are single-use and expire in 60 seconds; PKCE is mandatory.
• Append-only audit trail and authentication logs, protected by a database trigger that rejects updates and deletions and by revoking those privileges from the application role — two independent layers. Payloads never contain secrets, passwords or tokens.
• Multi-factor authentication mandatory for our own operators: cross-tenant access is only possible from a session authenticated with a second factor, by an explicitly enrolled operator, and every such action is audited.
• Session cookies marked HttpOnly and never exposed to page scripts; the browser never calls the API directly; state-changing requests protected by a double-submit CSRF token; a Content Security Policy that allows no external script; rate limits on sign-in, registration and second-factor verification.
• Encryption of data in transit; encrypted database backups kept outside the application host, retained for 30 days, with the field-encryption key stored apart from them and restores rehearsed; separation of environments, with mock providers technically blocked from running in production.
• Role-based access within each tenant and organisation, controlled by you; write operations covered by transactions and idempotency keys.