# Data Processing Agreement (DPA) — Aleatoria Template, version 1.0. Effective: **10 September 2026**. Language: **English** (the working language for business customers). Czech counterpart on request. > **(k právní revizi / pending legal review)** This template was drafted by the engineering team so that its > technical annexes describe the system truthfully. The contractual wording — in particular §9 (liability), > §10 (audits) and the chosen governing law — must be reviewed by a lawyer before it is signed with a customer. This DPA applies **only** where the Customer is a controller and Aleatoria processes personal data on the Customer's behalf — typically a Pro plan with several seats, or API use inside the Customer's own product. For individual users creating music for themselves, Aleatoria is the controller and the privacy policy () applies instead (see §1 of ). --- ## 1. Parties and subject matter **Controller ("Customer"):** the entity identified in the order or in the account's billing details. **Processor ("Provider"):** **Cloudpeakify s.r.o.**, company ID (IČO) **21041342**, VAT ID **CZ21041342**, registered seat **Jičínská 226/17, Žižkov, 130 00 Prague 3, Czech Republic**, registered in the Commercial Register kept by the Municipal Court in Prague, Section C, Insert 396064, operator of the Aleatoria service. Contact for this DPA: **support@aleatoria.io**. This agreement is concluded under **Article 28(3) of Regulation (EU) 2016/679 (GDPR)** and forms part of the Terms of Service (). Where this DPA and the Terms conflict on data protection, this DPA prevails. | item | content | |---|---| | Subject matter | provision of the Aleatoria AI music studio (generation, storage and delivery of audio) | | Duration | for the term of the Customer's subscription, plus the deletion period of §8 | | Nature and purpose | hosting, generating, storing and making available audio and the associated account data | | Types of personal data | account identifier, e‑mail address, API key, generation inputs (prompts, lyrics — which may contain personal data if the Customer's users enter it), generated audio and derived metrics, operational logs (those the Provider writes carry an anonymised IP and no query string; the hosting platform's own request logs keep the full client IP and request URL — Annex II and §10), billing details | | Categories of data subjects | the Customer's users (seats), and any natural persons whose data the Customer's users place in a prompt or lyrics | | Special categories (Art. 9) | none — the Customer must not submit them | --- ## 2. Instructions The Provider processes personal data only on the Customer's documented instructions. The Customer's use of the service (the API calls it makes, the settings it chooses) constitutes such instructions. Additional instructions must be given in writing and may be subject to a fee if they exceed the service's normal functionality. The Provider informs the Customer without undue delay if, in its opinion, an instruction infringes the GDPR or other Union or Member State data protection law (Art. 28(3), final paragraph). The Provider **does not** use the Customer's personal data or generated content to train any AI model, to build profiles, or for any purpose of its own beyond providing and securing the service. --- ## 3. Confidentiality Every person authorised by the Provider to process the personal data is bound by a duty of confidentiality (contractual or statutory) that survives the end of their engagement. --- ## 4. Security measures (Art. 32) Annex II lists the technical and organisational measures. They include, at minimum: encryption in transit (TLS) and at rest, a database reachable only over a private IP with enforced encrypted connections, least‑privilege service accounts, secrets held in Secret Manager with EU‑only replication, buckets with public access prevention, time‑limited (1 hour) signed download URLs, one job per worker instance, structured logging with anonymised IP addresses **in the logs the Provider itself writes**, and audit logging of administrative access (Cloud Audit Logs: Admin Activity plus the Data Access log types listed in Annex II). The anonymisation covers the Provider's own log records. It does **not** cover the request logs the hosting platform writes for every HTTP request (Cloud Run and the load balancer), which keep the full client IP address and the full request URL for 30 days; the Provider does not produce those records and cannot truncate them. This is stated in Annex II and in §10 rather than left to be discovered. The Provider may change the measures as technology evolves, provided the level of protection is not reduced. --- ## 5. Sub‑processors The Customer gives **general written authorisation** (Art. 28(2)) to the sub‑processors listed at , which is incorporated into this DPA by reference. The Provider will notify the Customer of an intended addition or replacement of a sub‑processor at least **30 days** in advance (by e‑mail to the account's billing address and in the app). The Customer may object on reasonable data protection grounds within that period; if the objection cannot be resolved, either party may terminate the affected part of the subscription with a proportional refund of prepaid fees. Each sub‑processor is bound by data protection obligations no less protective than this DPA. The Provider remains fully liable to the Customer for the performance of its sub‑processors' obligations. --- ## 6. Assistance to the Customer * **Data subject requests (Art. 12–23).** The service itself lets the Customer's users exercise access, portability and erasure (`GET /api/me`, `GET /api/me/export`, `DELETE /api/me`). Where a request reaches the Provider directly, it forwards it to the Customer without undue delay and does not respond on its behalf, unless instructed to. * **Articles 32–36.** The Provider assists the Customer, taking into account the nature of processing and the information available to it, with security of processing, breach notification, data protection impact assessments and prior consultation. §8 of contains the Provider's own DPIA of the fingerprinting feature and may be reused by the Customer. --- ## 7. Personal data breach (Art. 33(2)) The Provider notifies the Customer **without undue delay, and in any event within 48 hours** of becoming aware of a personal data breach affecting the Customer's data, at the account's contact address. The notification contains, so far as known: the nature of the breach, the categories and approximate number of data subjects and records, the likely consequences, and the measures taken or proposed. Notification of the supervisory authority and of data subjects is the Customer's responsibility as controller; the Provider supplies the information needed for it. The Provider's internal breach procedure is §12 of . --- ## 8. Return and deletion (Art. 28(3)(g)) On termination of the subscription the Customer may, within **30 days**, export all data through `GET /api/me/export` (JSON plus audio links). After that period — or immediately on the Customer's written instruction — the Provider deletes the personal data, including from the object storage. Residual copies may persist in encrypted database backups for at most **7 days** (the point‑in‑time recovery window) and in operational logs for at most **30 days**, after which they are deleted automatically. Backups are never used to restore access to deleted data; if a backup is restored after a disaster, deletions are re‑applied. The Provider may retain data where Union or Member State law requires it (e.g. invoices for 10 years under Czech accounting and VAT law); such data is retained only for that purpose. --- ## 9. Audits (Art. 28(3)(h)) The Provider makes available to the Customer the information necessary to demonstrate compliance, namely: (records of processing, retention, DPIA, security measures), this DPA with its annexes, the `terraform output resource_locations` residency map, and the certifications and audit reports of its infrastructure sub‑processor (Google Cloud: ISO/IEC 27001, 27017, 27018, SOC 2/3 — see ). The Customer may carry out an audit or inspection once per 12 months (or after a breach affecting its data), on 30 days' written notice, during business hours, under confidentiality, and in a way that does not disrupt the service. The Customer bears the cost of the audit; the Provider bears the cost of remedying non‑compliance found. --- ## 10. International transfers The Provider processes the Customer's personal data — account data, prompts and lyrics, generated audio, derived metrics, billing records and the Provider's own application logs — **within the European Union**, with the exception of transactional e-mail stated below (Google Cloud regions `europe-west4` and `europe-west1`, EU multi‑region backups, application logs routed to the `aleatoria-eu-logs` bucket in `europe-west4`), enforced by the organisation policy `gcp.resourceLocations = in:eu-locations` (§5 of ). **One qualification, stated rather than glossed over.** Cloud Logging keeps two buckets that Google creates and manages itself and that a customer project cannot relocate: `_Required` (Cloud Audit Logs — Admin Activity, 400 days) and `_Default` (30 days). Both are held in the `global` multi‑region, for which Google gives no guarantee that the data stays inside the EU. `_Required` cannot be switched off at all. `_Default` receives a copy of the operational, request and Data Access records **while the project's `_Default` sink is switched on** — today it is; once that sink is switched off those records stay only in the EU `aleatoria-eu-logs` bucket. Neither bucket ever carries the Customer's generated content. Any transfer arising from them, and any support access from a third country, is covered by the standard contractual clauses in the Google Cloud Data Processing Addendum. **Transactional e-mail (since 22 September 2026).** Sub-processor P3, Resend (Plus Five Five, Inc., USA), receives the recipient's e-mail address and the content of the transactional messages the service sends (address confirmation, sign-in links, order and withdrawal confirmations). Delivery runs through Amazon SES in Ireland; the Resend account and message metadata are held in the USA. This transfer relies on the standard contractual clauses (Module Two) and the EU–US Data Privacy Framework, as listed in . Apart from the Google Cloud qualification above and this one, no transfer to a third country takes place under this DPA, and the Provider will inform the Customer before relying on any new transfer mechanism. --- ## 11. Liability, term and governing law Liability under this DPA follows the limitations agreed in the Terms of Service, save where mandatory law provides otherwise (Art. 82 GDPR is unaffected). This DPA takes effect when the Customer accepts the Terms or signs the order form, and lasts as long as the Provider processes personal data for the Customer. It is governed by the law of the Czech Republic **(k právní revizi)**. --- ## Annex I — Details of processing | item | value | |---|---| | Categories of data subjects | the Customer's users (seats); natural persons named in prompts or lyrics | | Categories of personal data | account id, e‑mail and whether it is verified; **authentication data** — password hash (scrypt), one-time e-mail tokens, session records (session id, sign-in method, timestamps, anonymised IP, user agent, hash of the session secret), the Google identifier (`sub`) when Google sign-in is used, and the API key (stored as an HMAC digest); prompts and lyrics; generated audio and metrics; **operational logs** — the Provider's own records carry an anonymised IP and no query string, while the hosting platform's request logs, which the Provider does not produce and cannot truncate, keep the **full client IP address and full request URL** for 30 days (Annex II, §10); **billing data** — subscription, credit ledger, orders, invoices (amounts, VAT, country, VAT id) and payment-provider event records | | Sensitive data | none permitted | | Frequency | continuous, for the term of the subscription | | Nature of processing | storage, generation of audio, computation of novelty metrics, delivery of files, authentication and session management, abuse protection, delivery of transactional e-mail, subscription and credit accounting, billing | | Purpose | provision of the Aleatoria service | | Retention | as in §6 of and §8 of this DPA | | Sub‑processors | — currently P1 Google Cloud EMEA (hosting, EU), P2 Stripe Payments Europe (payments, live mode since 21 September 2026; partly an independent controller), P3 Resend / Plus Five Five, Inc. (transactional e-mail since 22 September 2026: recipient address and message content; delivery via Amazon SES in Ireland, account and metadata in the USA — SCCs Module Two and the EU-US DPF) and P4 Seznam.cz (support mailbox, Czech Republic). All four process data today. Until version 1.1 of this DPA was published, this row wrongly said that only P1 was processing data and that no e-mail sender was engaged | ## Annex II — Technical and organisational measures (Art. 32) | area | measure | |---|---| | Pseudonymisation and encryption | TLS in transit; AES‑256 at rest (Google‑managed keys); anonymised IP addresses **in the logs the Provider writes** and in session records (last IPv4 octet zeroed, IPv6 truncated to /48, before formatting; the platform's own request logs are not covered — see the Logging and audit row), with the trusted hop taken from the end of `X-Forwarded-For` so a caller cannot write its own value into them; API keys stored only as an HMAC‑SHA256 of the key; **passwords stored as scrypt (N = 2¹⁵, r = 8, p = 3) with a per-password salt**; session secrets and e-mail tokens stored only as SHA-256; the e-mail dimension of the abuse counters stored as a truncated SHA-256 digest, never as the address; the provenance record states **whether** a prompt was given (`prompt_provided`) and never stores the prompt itself | | Confidentiality | least‑privilege service accounts (`aleatoria-api`, `aleatoria-worker`, `aleatoria-build`); buckets with uniform access and public access prevention; secrets in Secret Manager (EU‑only user‑managed replication); API key authentication | | Authentication and session security | `__Host-`prefixed, `HttpOnly`, `SameSite=Lax` session cookie carrying only a session id and a random 256-bit secret; absolute lifetime 30 days, idle 14, secret rotated every 24 h with a 60-second grace, and **re-use of a rotated secret revokes the session** and is logged; CSRF double-submit enforced on every cookie-authenticated unsafe request, with an `Origin` check; per-IP and per-e-mail attempt limits on every sign-in, sign-up, magic-link, password-reset and token-consumption route; a password reset and "sign out everywhere" revoke every session **and the API key**; an account whose address was never verified loses its password and API key the moment somebody proves that address by another factor | | Application response headers | `Content-Security-Policy` (`default-src 'self'`, `frame-ancestors 'none'`, no `object-src`), `X-Content-Type-Options: nosniff`, `X-Frame-Options: DENY`, `Referrer-Policy: same-origin`, `Cross-Origin-Opener-Policy: same-origin`, a restrictive `Permissions-Policy`, and HSTS at the load balancer | | Payment integrity | card data never reaches the Provider (hosted Checkout, PCI scope SAQ-A); the webhook is verified by HMAC over the raw body with a ±300 s tolerance and a live/test-mode guard; every credit movement is an append-only ledger row with an idempotency key, so a redelivered event cannot double a balance; a reconciler re-reads the provider every five minutes and repairs anything a lost webhook missed | | Integrity | infrastructure as code (Terraform) with peer review; atomic file writes; checksums in the provenance record; AI content marking of every export | | Availability and resilience | Cloud SQL daily backups in the EU multi‑region + 7‑day point‑in‑time recovery; stateless services that scale from zero; hard instance caps and a global daily generation cap against resource exhaustion | | Network | dedicated VPC without auto subnets, database on a private IP only, workers closed by IAM (only the api's service account may invoke them; no public invoker), default‑deny ingress firewall, no Cloud NAT | | Testing and evaluation | automated test suite in CI, terraform validate, restore test at least annually **(to be established)** | | Job isolation | one job per worker instance (concurrency 1), non‑root container, writable `/tmp` only | | Logging and audit | structured JSON logs, 30-day retention, routed to the `aleatoria-eu-logs` bucket in `europe-west4`, query strings dropped and client IPs truncated before formatting. Until the project's `_Default` sink is switched off, every entry is written **twice** — once into that EU bucket and once into `_Default` — so the EU bucket is an addition, not yet a replacement (§10). Two log buckets are Google-managed and sit in the `global` multi-region rather than in the EU (§10): Cloud Audit Logs — Admin Activity in `_Required` (400 days, cannot be switched off or moved) and Data Access (`ADMIN_READ`/`DATA_WRITE` for Cloud SQL, Secret Manager and GCS; `DATA_READ` for Cloud SQL and Secret Manager), which reach `_Default` (30 days) over that same sink and therefore, once it is switched off, reach only the EU bucket — at 30 days either way. The request logs the platform itself writes for Cloud Run and the load balancer are outside the Provider's control and keep the full client IP and request URL for the same 30 days |