Data Processing Agreement

1. Parties and acceptance

This Data Processing Agreement ("DPA") forms part of the agreement between:

• Controller: the business that subscribes to the Amarantic platform (the Tenant, GDPR Art. 4(7));
• Processor: Amarantic (GDPR Art. 4(8)), operated from Copenhagen, Denmark. The registered legal entity, address, and CVR number are pending confirmation by our lawyer and will be inserted before production rollout.

This DPA is accepted by the Tenant Owner at sign-up via click-through (Decision 3, locked 2026-05-06). Acceptance is recorded as an append-only row in our tenant_terms_acceptance ledger with terms_kind = "dpa", the version shown above, the actor's IP, user-agent, and the Supabase authentication identity that clicked accept. A future signed-PDF path is reserved at the schema level (the method and signed_document_ref columns are already in place) and will be enabled by a small follow-up when the first Tenant requests it; no migration is required.

This DPA is governed by the Terms (opens in new tab) of which it forms part. The Privacy Policy (opens in new tab) describes the data flows; the Sub-processors page (opens in new tab) lists the current named providers.

2. Subject matter and duration

Subject matter. Processing of personal data of end-clients of the Tenant for the purposes of appointment booking, calendar and resource management, intake forms, clinical-notes management, payments and invoicing, marketing communications under the Tenant's control, AI-assisted analytics and outreach drafting, and related Service operation.

Duration. The DPA applies for the term of the Tenant's subscription, plus a deletion window of up to 90 days following termination (Section 13).

3. Nature and purpose of processing

We process personal data only to provide the Service to the Tenant and to fulfil our obligations under applicable law. The categories of processing include: collection, storage, retrieval, organization, structuring, sending, receiving, analysing, and erasure of personal data; sending and tracking transactional and marketing communications under the Tenant's instructions; rendering AI-assisted suggestions and drafts to the Tenant's staff; and reconciliation of payments through our payment sub-processor.

We act only on the documented instructions of the Tenant, including these Terms (opens in new tab), this DPA, the Privacy Policy (opens in new tab), the Tenant's product configuration (booking flow design, intake-form definitions, marketing settings, AI autonomy toggles, audience selections), the in-product capability metadata, and any instructions that the Tenant gives through the Service or in writing.

4. Categories of personal data

The categories of personal data processed include:

• Identification and contact data — name, email, phone number, language preference.
• Booking and appointment data — service, date/time, staff, location, notes, status.
• Payment data — transaction amount, currency, status, and provider references (we do not store full card numbers; the payment sub-processor controls card data directly).
• Communications data — message content, delivery receipts, click events on trackable booking links (salted SHA-256 hashes of IP and user agent, never raw).
• Special-category data (Art. 9) — allergies, skin conditions, treatment notes — only where the Tenant has configured the surface and the end-client has granted explicit consent under Art. 9(2)(a). Encrypted at rest with AES-256-GCM; the per-mutation change-log is encrypted under the same key posture.
• Consent records — append-only ledger of consent grants and withdrawals.
• AI-derived insights — visit frequency, churn-risk segment, predicted next-visit date.
• Authentication and session data — for end-clients who use the Tenant's client portal: hashed credentials via Supabase Auth, session cookies.

5. Categories of data subjects

• End-clients of the Tenant — people who book appointments, register on the Tenant's portal, or receive communications.
• Tenant staff — owners, managers, and staff users in the Tenant's Account.

6. Processor obligations (Art. 28(3))

We will:

1. Process on documented instructions — process the personal data only on the Tenant's documented instructions, including transfers to third countries, unless required to act otherwise by EU or Member-State law; if so, we will inform the Tenant before processing, unless legally prohibited.
2. Confidentiality — ensure that all our personnel authorized to process the personal data are bound by appropriate confidentiality undertakings.
3. Security (Art. 32) — implement the technical and organizational measures summarized in Section 7.
4. Sub-processors — use sub-processors only under Section 8.
5. Assist with rights requests — assist the Tenant, taking into account the nature of the processing, in fulfilling its obligations to respond to data subject requests (Art. 12–22) through Service features and case-by-case operator support.
6. Assist with security obligations — assist the Tenant in ensuring compliance with Art. 32 (security), Art. 33 (breach notification to authorities), Art. 34 (breach notification to data subjects), and Art. 35–36 (data protection impact assessment and prior consultation), taking into account the nature of processing and the information available to us.
7. Deletion or return — at the Tenant's choice, delete or return all personal data to the Tenant after the end of the provision of services, and delete existing copies unless retention is required by Union or Member-State law (see Section 13).
8. Information for audits — make available to the Tenant all information necessary to demonstrate compliance with Art. 28 and allow for and contribute to audits, including inspections, conducted by the Tenant or another auditor mandated by the Tenant (Section 11).
9. Notify on breach — notify the Tenant without undue delay, and in any case within 24 hours of confirmed awareness of a personal-data breach, with the information required by Art. 33(3) to the extent then known.
10. Notify on infringing instructions — inform the Tenant immediately if, in our opinion, an instruction infringes the GDPR or other data protection provisions.

7. Confidentiality, security, and Art. 32 measures

We apply the following technical and organizational measures (further detailed in our internal Security specification):

• Tenant isolation: PostgreSQL Row-Level Security on every tenant-scoped table, enforced via a managed session-context model (current_tenant_id(), current_user_id(), current_actor_type()). Cross-tenant reads and writes are blocked at the database level, not just at the application layer.
• Encryption at rest for Art. 9 data: AES-256-GCM for health notes, treatment chart fields, visit-note content, and the per-mutation change-log of those rows.
• Encryption in transit: TLS for all client/server and server/sub-processor connections.
• Authentication: Supabase Auth with httpOnly session cookies and password hashing managed by Supabase. Leaked-password protection is plan-gated upstream and will be enabled once the Supabase project is upgraded to Pro.
• Authorization: role-based access control in the application (owner / staff / client / agent / system / mcp / platform-owner / cockpit-admin), capability metadata for risk-classed mutations, approval policy for higher-risk actions.
• Append-only audit ledgers: booking events, agent audit, consent records, platform-terms acceptance, treatment-chart change-log — IMMUTABLE policy class with SELECT + INSERT only, defended at RLS and (for change-logs) by a database trigger that blocks UPDATE/DELETE for every role except the documented erasure path.
• Rate limiting: Upstash Redis-backed sliding windows on public, authenticated, auth, GDPR, agent, and MCP tiers.
• Secrets management: server-only environment variables; no client-side exposure.
• AI safeguards: tenant-scoped prompt context (no cross-tenant prompt mixing), assistant-visible payload minimization at a canonical projection boundary, Art. 9 egress gated by named consent surfaces, AI autonomy default-OFF doctrine.
• Backups and recovery: managed by our infrastructure sub-processors (Supabase) with the integrity guarantees they document.

Pseudonymized data is treated as personal data unless an explicit, reviewed design says otherwise.

8. Sub-processors

The Tenant gives general written authorization for our use of sub-processors. The current named list, including each provider's role, jurisdiction, and transfer mechanism, is published at Sub-processors (opens in new tab). The page also describes the function-not-vendor disclosure pattern, the conditional Standard Contractual Clauses clause that auto-applies whenever any listed sub-processor is outside the EEA, and the explicit non-listing of Google Gemini (which is a test-only opt-in, never used for production Tenant data).

We will give the Tenant 30 days' written notice before adding a new sub-processor or replacing an existing one. The Tenant may object on reasonable grounds within the 30-day notice period. If we cannot accommodate the objection within a reasonable time, the Tenant may terminate the affected portion of the Service with a pro-rata refund for any prepaid period that has not yet been provided.

Re-acknowledgement of the Sub-processors page (opens in new tab) is automatic when an addition is published (material: true). Removals (material: false) surface as a passive notice.

We remain liable to the Tenant for the performance of each sub-processor's data-protection obligations.

9. International transfers

Where personal data is transferred to a sub-processor or other recipient outside the European Economic Area, the transfer is governed by Module-2 Standard Contractual Clauses (Commission Decision 2021/914) or another Article 46 transfer tool (e.g. the EU-US Data Privacy Framework where the recipient is certified). The SCCs are incorporated into our agreement with each non-EEA sub-processor and apply between the Tenant and the sub-processor by means of this clause.

We maintain Transfer Impact Assessments for each US sub-processor we currently use and review them as appropriate. The current TIA scope and outcome are summarized on internal compliance records and can be made available to the Tenant on request.

We do not represent that "all data stays in the EU" while any non-EEA sub-processor is on the Sub-processors (opens in new tab) list.

10. Assistance with data subject rights

We assist the Tenant in fulfilling its obligations under Art. 12–22 by:

• providing data export (Art. 20) via a tenant-scoped endpoint that returns a machine-readable JSON file containing all data we hold about the data subject, including booking history, notes, consent history, AI-derived insights, and agent decisions;
• running an erasure cascade (Art. 17) on Tenant request that, in one atomic transaction: anonymizes booking financials for the legal-retention window, hard-deletes free-text notes (including encrypted clinical notes and their per-mutation change-logs through the documented immutability-trigger disablement path), inserts withdrawal records into the consent ledger, anonymizes audit metadata, and deletes derived analytics and waitlist entries. The operation returns a summary listing what was erased and what was retained under a legal-retention exception;
• supporting rectification, restriction, and objection through the standard Service surfaces.

Where the Tenant cannot fulfil a request without our help (e.g. cross-table erasure), we will assist in good faith within the Art. 12(3) timeframe.

11. Audit rights

The Tenant may audit our compliance with this DPA at most once per twelve-month period with at least 30 days' written notice, save where mandatory law or a personal-data incident requires shorter notice. Audits will be conducted in a manner that respects the confidentiality of our other Tenants and the security of the Service. Where the Tenant uses a third-party auditor, the auditor must sign a non-disclosure undertaking. We may charge reasonable fees for on-site audits beyond a single annual occurrence, calculated against time and materials.

Documentation made available on request includes: this DPA and the public Layer-1 pages (Terms (opens in new tab), Privacy (opens in new tab), DPA (opens in new tab), Sub-processors (opens in new tab)); the current Sub-processors list (opens in new tab) with transfer mechanisms; summaries of internal compliance specifications (Security, GDPR, Control Plane) and the structural audit posture; the most recent penetration-test summary when one exists.

12. Personal-data breach

We follow the breach-notification cadence summarized in the Privacy Policy (opens in new tab) Section 14:

• Tenant notification within 24 hours of confirmed awareness, with the information required by Art. 33(3) to the extent then known. We update the Tenant as new information becomes available.
• Datatilsynet notification within 72 hours for reportable breaches.
• End-client notification without undue delay under Art. 34 where the breach is likely to result in a high risk to their rights and freedoms.

We maintain an immutable internal breach log retained for 5 years.

13. Deletion or return on termination

At the Tenant's choice, on termination of the subscription we will:

• delete all personal data held on the Tenant's behalf within 90 days of effective termination; or
• return a machine-readable export to the Tenant before deletion.

Records that we are required by law to retain (notably financial records under bogføringsloven, 5-year retention) will be retained for the legal period in anonymized or otherwise minimized form and deleted thereafter. The Privacy Policy (opens in new tab) Section 8 lists the retention timetable in full.

The append-only tenant_terms_acceptance ledger that records the Tenant Owner's acceptance of this DPA is removed via the organization-deletion cascade; it is not subject to per-data-subject Art. 17 erasure because the data subject is the controller, not an end-client.

14. Liability and indemnification

Each party's liability under this DPA is governed by Art. 82 GDPR and the cap and exclusions in the Terms (opens in new tab) Section 12. Nothing in this DPA limits a party's liability under Art. 82 where such limitation would be invalid under mandatory law.

15. Changes to this DPA

We may update this DPA. Updates are versioned with version and effectiveAt, and flagged as material: true or material: false. Material updates require re-acknowledgement at the next privileged action; non-material updates surface as a passive notice. Past versions are preserved in the acceptance ledger.

16. Governing law and venue

This DPA is governed by the laws of Denmark. The exclusive venue for disputes is the competent courts of Copenhagen, Denmark, without prejudice to mandatory consumer-protection venues where applicable.

17. Order of precedence

Within the Amarantic Layer-1 contracts, the order of precedence on a personal-data point is: this DPA, then the Privacy Policy (opens in new tab), then the Terms (opens in new tab). On a commercial or acceptable-use point, the Terms prevail.