Back
EN | ES

Data Processing Agreement

Last reviewed: Version: 2026-07-21.1

Effective from: the date the Customer accepts the Terms of Service, which incorporate this DPA by reference (see Terms §6), or, where the Customer's procurement process requires it, the date of a separately countersigned copy.

This Data Processing Agreement ("DPA") forms part of the Master Subscription Agreement or other written or electronic agreement between Zendrhax LLC, operator of Zendrhax ("Processor", "we", "us") and the Customer ("Controller", "you") that governs the Customer's use of the Service.

This DPA reflects the parties' agreement on the processing of personal data carried out by the Processor on the Controller's behalf in connection with the Service. It is intended to document the parties' arrangements under Article 28 of Regulation (EU) 2016/679 ("GDPR") and the UK GDPR. Where the Customer or its end users are located outside the European Economic Area, the DPA still applies as a contractual baseline — local law may add requirements that supersede the GDPR clauses below.

This template is intended to support the parties' Article 28 arrangements; it is not a certification that every use of the Service complies with Data Protection Laws. Each party should obtain legal advice about its own processing, lawful bases, notices, retention, and jurisdiction-specific obligations before relying on this DPA.

A countersigned counterpart of this DPA is available on request at legal@zendrhax.com. Where the Controller's procurement process requires bilateral signature, the version executed there prevails over this online version.

1. Definitions

Capitalised terms not defined below have the meaning given to them in the GDPR.

  • "Customer Personal Data" — personal data processed by the Processor on behalf of the Controller in connection with the Service, as more fully described in Annex A.
  • "Data Protection Laws" — the GDPR, the UK GDPR, and any other applicable laws relating to the protection of personal data.
  • "Sub-processor" — any third party engaged by the Processor to process Customer Personal Data on the Controller's behalf.
  • "Security Incident" — any breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Customer Personal Data.
  • "Standard Contractual Clauses" (SCCs) — the European Commission's standard contractual clauses for the transfer of personal data to third countries (Commission Implementing Decision (EU) 2021/914).

2. Roles and scope

2.1 The parties acknowledge that for the purposes of Data Protection Laws and in respect of Customer Personal Data, the Customer is the Controller and Zendrhax LLC is the Processor.

2.2 This DPA applies for as long as the Processor processes Customer Personal Data on the Controller's behalf.

2.3 The subject-matter, duration, nature, purpose, categories of data, and categories of data subjects of the processing are described in Annex A.

3. Processor's obligations (Article 28(3))

The Processor shall:

(a) process Customer Personal Data only on documented instructions from the Controller, including with regard to transfers to a third country, unless required to do so by Union or Member State law to which the Processor is subject. The Controller's instructions are those given through the Service (configuration, API requests, deletion requests, support tickets) and any written instructions expressly identified as such. If the Processor cannot comply with an instruction it will notify the Controller without undue delay;

(b) ensure that persons authorised to process Customer Personal Data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality;

(c) implement the technical and organisational measures set out in Annex B and review them at least annually;

(d) respect the conditions set out in clauses 4 and 5 below for engaging sub-processors;

(e) assist the Controller, taking into account the nature of the processing and the information available, in fulfilling the Controller's obligations to respond to requests from data subjects exercising their rights under Chapter III of the GDPR. The Service provides self-service endpoints — GET /me/data-export (Article 15) and POST /me/data-deletion-request (Article 17) — which the Controller may direct its account-holding end users to. Account-free Reputation reviewers can use a private, 15-minute management grant for POST /review/manage/data-export and POST /review/manage/anonymize. For requests that cannot be fulfilled through those controls, the Processor will respond to a written request from the Controller within thirty (30) days;

(f) assist the Controller in ensuring compliance with the obligations pursuant to Articles 32 to 36 of the GDPR taking into account the nature of processing and the information available;

(g) at the choice of the Controller, delete or return all Customer Personal Data to the Controller after the end of the provision of services relating to processing, and delete existing copies unless Union or Member State law requires storage. Routine deletion happens within thirty (30) days of termination; backups roll out of retention according to the schedule in Annex B;

(h) make available to the Controller all information necessary to demonstrate compliance with the obligations laid down in Article 28 and allow for and contribute to audits, including inspections, conducted by the Controller or another auditor mandated by the Controller, subject to clause 7 below.

The Processor shall immediately inform the Controller if, in its opinion, an instruction from the Controller infringes Data Protection Laws.

4. Sub-processors (Article 28(2), 28(4))

4.1 The Controller grants the Processor general written authorisation to engage Sub-processors. A current list of Sub-processors (name, location, processing activity) is maintained at /legal/sub-processors and updated when changes occur.

4.2 The Processor shall notify the Controller of any intended changes concerning the addition or replacement of Sub-processors at least fourteen (14) days before the change takes effect, thereby giving the Controller the opportunity to object. Notifications are sent to the email address registered on the Controller's account.

4.3 Where the Controller objects in writing within the notice period and the parties cannot agree on a resolution, the Controller may terminate the affected portion of the Service on written notice and receive a pro-rated refund of any prepaid fees.

4.4 The Processor shall impose on each Sub-processor, by way of a written contract, data protection obligations no less protective than those set out in this DPA.

5. International transfers (Chapter V)

5.1 The Processor shall not transfer Customer Personal Data outside the European Economic Area, the United Kingdom, or another country deemed adequate by the European Commission unless an appropriate safeguard under Chapter V GDPR is in place.

5.2 This online DPA is the parties' Article 28 processing baseline. It does not, by itself, execute the European Commission SCCs. Where the SCCs are required for a restricted transfer, the parties must separately execute the applicable module and options, complete and sign the required annexes, and document a transfer impact assessment before that transfer begins. The Controller must not submit data for that restricted transfer until the safeguard is effective. Contact legal@zendrhax.com to arrange the transfer documents.

5.3 If an existing transfer safeguard is invalidated, the parties will suspend the affected transfer where required and use reasonable efforts to put an alternative lawful mechanism in place without undue delay.

6. Security and personal-data breaches (Article 32, 33)

6.1 The Processor shall implement and maintain the technical and organisational measures set out in Annex B, designed to ensure a level of security appropriate to the risk.

6.2 The Processor shall notify the Controller of a Security Incident affecting Customer Personal Data without undue delay and in any event within seventy-two (72) hours of becoming aware of it. The notification shall include, to the extent known: the nature of the incident, the categories and approximate number of data subjects and records concerned, the likely consequences, and the measures taken or proposed.

6.3 The Processor shall reasonably cooperate with the Controller's investigation and notification obligations under Articles 33 and 34 of the GDPR. The Processor will not notify data subjects directly on the Controller's behalf unless legally compelled or expressly instructed to do so by the Controller.

7. Audits (Article 28(3)(h))

7.1 The Processor shall make information reasonably available to the Controller on written request to demonstrate compliance with Article 28, including a summary of the Processor's technical and organisational measures. Third-party or provider audit reports are provided only when they exist and the Processor is authorised to share them. Nothing in this DPA states that Zendrhax LLC holds a SOC 2 or ISO 27001 certification.

7.2 Where the above is insufficient to demonstrate compliance, the Controller may, no more than once per twelve (12) month period and on at least thirty (30) days' prior written notice, audit the Processor's compliance with this DPA, subject to:

  • audits being conducted during business hours and in a manner that does not interfere with the Processor's operations;
  • the auditor being bound by appropriate confidentiality obligations;
  • the Controller bearing its own and the Processor's reasonable costs for the audit, unless the audit reveals material non-compliance, in which case the Processor bears its own reasonable costs.

7.3 Nothing in this clause requires the Processor to give access to other customers' data, to its source code, or to information that would compromise the security of the Service.

8. Term and termination

8.1 This DPA takes effect on the Effective Date and remains in force for as long as the Processor processes Customer Personal Data on the Controller's behalf.

8.2 The Processor's obligations regarding confidentiality, security, and the return or deletion of Customer Personal Data survive termination.

9. Liability and governing law

9.1 Each party's liability under or in connection with this DPA is subject to the limitations and exclusions of liability set out in the Master Subscription Agreement.

9.2 This DPA is governed by the law specified in the Master Subscription Agreement. If none is specified, this DPA is governed by the laws of the State of Florida, United States, and the parties submit to courts of competent jurisdiction in the State of Florida, United States.

Annex A — Details of processing

Categories of data subjects:

  • The Controller's authorised end users (employees, contractors, collaborators) who hold accounts on the Service.
  • The Controller's customers, clients, and other third parties whose personal data the Controller chooses to upload or otherwise process through the Service (for example, billing contacts on invoices managed via the Invoices module).
  • Customers invited through the Reputation module to submit a review, whether or not they hold an account on the Service.

Categories of personal data:

  • Identification & contact data: name, email address, phone number, postal address, locale preferences.
  • Account data: hashed passwords, two-factor secrets, session identifiers, IP address, user-agent string, login history.
  • Business data uploaded by the Controller: invoices, clients, payment status, line-item descriptions, free-text fields.
  • Reputation data: review-recipient name and email, service reference, numeric rating, optional comment, locale, moderation status, publication choice, and publication-consent history.
  • Audit data: records of actions taken by the Controller's users inside their workspace (who created what, when, from which IP).

The Controller is solely responsible for the lawful basis on which any of the above is uploaded and for not uploading special-category data (Article 9 GDPR) unless it has separately agreed with the Processor in writing.

Frequency: continuous, for the duration of the Customer's subscription to the Service.

Nature and purpose of processing:

  • Hosting, storing, and serving the Customer's workspace data.
  • Authenticating and authorising the Customer's users.
  • Generating invoices and other Customer-driven artefacts.
  • Sending transactional email on the Customer's behalf.
  • Delivering review invitations and collecting, moderating, and, only with the reviewer's active permission, publishing testimonials.
  • Maintaining audit logs for the Customer's compliance use.

Duration: for as long as the Customer maintains an active subscription, plus the retention windows defined in Annex B.

Annex B — Technical and organisational measures (Article 32)

The Processor implements the following measures. The list reflects the state of the Service at the Effective Date; specific controls evolve as the Service evolves, but the level of protection will not materially decrease.

B.1 Pseudonymisation and encryption

  • TLS 1.2+ for all data in transit.
  • Encryption at rest for managed database storage and for object storage where personal data is held.
  • Passwords stored using Argon2id; webhook signing secrets stored encrypted; 2FA secrets stored encrypted in the user record.

B.2 Confidentiality, integrity, availability, resilience

  • Role-based access control (capabilities + roles) inside each workspace; tenant isolation enforced on every data read/write path.
  • Multi-tenant database schema; cross-tenant access requires a platform-admin session and is audit-logged.
  • Encrypted daily full-recovery archives retained up to thirty (30) days. The newest archive is verified weekly by restoring its databases into isolated in-memory targets; a full isolated recovery rehearsal is performed quarterly (see docs/operations.md).
  • The platform exposes health and metrics endpoints and runs a same-host scheduled watchdog. Production operations require a separate off-host monitor so a host-wide outage remains observable; see the incident-management runbook in docs/operations.md.
  • Reputation management and submission links are sensitive capabilities. New mail places the raw token in a URL fragment that is not transmitted on GET; a neutral page requires an explicit CSRF-protected POST, rotates the anonymous session id, and issues a 15-minute grant before redirecting to a clean URL. Only SHA-256 token hashes are persisted. Legacy token-in-path GET pages are neutral. Every /review response uses no-store, no-referrer, and noindex controls, and sensitive application logs omit browser, account/workspace identity and redact legacy token paths. The operator must apply equivalent redaction or omission to edge, proxy, CDN, load-balancer, and web-server access logs.

B.3 Restoration of availability and access

  • The platform exposes a self-service GET /me/data-export endpoint (Article 15) returning a stable-shape JSON archive of all data keyed to the requesting user. Rate-limited to one request per user per 24 hours. The Reputation slice includes only reviews linked to that user as the reviewer (reviewer_user_id), not customer review requests the user merely created as an employee.
  • An account-free Reputation reviewer can export the request, review, and publication-consent history for one review through POST /review/manage/data-export with a live management grant and CSRF. The successful-export claim is atomic and limited to one per review per 24 hours; GET is rejected without consuming quota. Neither plaintext capability tokens nor stored hashes are included. Only byte count and a SHA-256 digest are retained while the review exists.
  • A scheduled cron job verifies the most recent backup is restorable against a sandbox database; failure alerts fire to operations.

B.4 Erasure and deletion (Article 17)

  • The platform exposes POST /me/data-deletion-request. A successful request opens a pending row with a 14-day grace window during which the user can cancel. After the window, the daily gdpr.finalise_data_deletions cron job anonymises the user record in place: PII columns are scrubbed (name, email, password, 2FA secret), anonymised_at is stamped, and authentication artefacts (sessions, login history, API keys, password resets, OTP codes, workspace memberships) are hard-deleted.
  • Before an account-erasure request is marked finalised, the platform runs the erasure hook for every installed module, including inactive modules. Reputation hard-deletes reviews directly linked to the account and clears remaining creator/consent-actor references. All modules are attempted. A hook error, missing catalog module, discovery failure, or unavailable catalog state keeps the request pending for an idempotent retry.
  • An account-free Reputation reviewer may request immediate, irreversible erasure through POST /review/manage/anonymize. A live 15-minute grant, CSRF, and explicit confirmation are required. One module transaction hard-deletes the request, review, identity/content/source data, consent history, capabilities, privacy receipts, and recovery/export limits. No individual rating or event timestamp survives, and the review cannot be recovered or republished.
  • Individual erasure contributes only response_count and rating_sum to a tenant-level aggregate. It has no individual key, but may be mathematically inferable for a very small cohort and is not treated as categorically anonymous. An automatic request also contributes a keyed HMAC source fingerprint retained solely to suppress replay. This minimized, purpose-bound pseudonymous ledger and the aggregate are deleted on tenant purge. HMAC key rotation requires a planned ledger migration.
  • Unanswered Reputation invitations are hard-deleted 90 days after expiry. An answered invitation remains a throttled, recovery-only mailbox anchor while its review exists; it cannot display or change review data.
  • Private or archived reviews are hard-deleted after 24 calendar months without review, consent, or moderation activity. A non-archived public review remains while publication permission is active; withdrawal removes it from public display immediately and starts the private retention path from latest activity.
  • Permanent tenant deletion executes module purges before deleting the core tenant row. A module/catalog/discovery failure stops core deletion so the operation can be retried. Reputation tenant purge removes live review data, settings, receipts/limits, aggregate sum/count, and HMAC suppressions.
  • Audit-log foreign keys are intentionally retained as tombstones so the workspace's compliance record stays intact while the personal data behind them is gone.
  • Tenant owners must transfer ownership of every workspace they own before the deletion countdown can start.

B.5 Regular testing

  • Architecture-guard suite gates every PR against regressions in the Domain/Application/Infrastructure boundary, raw SQL in services, and controller method-length budgets.
  • Unit and integration test suites run on every PR; merges to main require green CI.

B.6 Personnel

  • Access to production data is limited to personnel with a documented operational need. All such personnel are bound by written confidentiality obligations.

B.7 Sub-processors

The current list of Sub-processors and their location is published at /legal/sub-processors. The list includes the Processor's infrastructure provider, transactional email provider, error-tracking provider, and payment processor.