Data processing agreement

This agreement under Article 28 GDPR is between the organisation using Kauri (the “Controller”) and Karussell Labs OÜ, Tartu mnt 67/1-13b, 10115 Tallinn, Estonia, Registry code 17536456 (the “Processor”). It is accepted when an organisation is created and forms part of the terms of service.

1. Subject matter, duration, nature and purpose

The Processor operates the Kauri platform for the Controller for as long as the Controller’s organisation exists. The processing consists of storing and displaying findings uploaded by the Controller’s runner, requests and records the Controller creates, files the Controller attaches, and member accounts, for the purpose of change and release management of the Controller’s software.

2. Types of data and categories of data subjects

Data: findings about the Controller’s systems (names of migrations, functions, grants, policies, buckets, cron jobs, environment keys by name, deployed commits); commit messages and pull-request titles; text the Controller’s members type; files they attach; member email addresses and roles. Data subjects: the Controller’s members, and any person named in commit messages or attachments. The Processor never receives environment values, connection strings, keys, tokens, database rows or file contents: the runner refuses to send them.

3. Instructions

The Processor processes personal data only on the Controller’s documented instructions, which are the terms, this agreement and the settings the Controller chooses in the platform, unless Union or Member State law requires otherwise, in which case the Processor informs the Controller before processing unless that law prohibits it.

4. Confidentiality

Persons authorised by the Processor to process the data are bound by confidentiality.

5. Security

The Processor implements the technical and organisational measures in Annex 2, including row-level tenancy on every table from the first migration, encrypted transport, hosting in the European Union, a public description of what the platform holds and does not hold, and deletion on request that leaves nothing behind.

6. Sub-processors

The Controller authorises the sub-processors in Annex 1. The Processor informs the Controller of any intended addition or replacement at least 30 days in advance by email to the organisation’s owners; the Controller may object within that period, in which case either party may terminate. The Processor imposes on each sub-processor the same data protection obligations by contract and remains liable for their performance.

7. Assistance

The Processor assists the Controller with data subject requests (Articles 12–22) and with the obligations in Articles 32–36, taking into account the nature of the processing and the information available to it. Owners can export the organisation’s data and delete it from the settings page without the Processor’s involvement.

8. Personal data breach

The Processor notifies the Controller without undue delay after becoming aware of a personal data breach affecting the Controller’s data, and in any case within 48 hours, so that the Controller can meet its own 72-hour obligation, and provides the information in Article 33(3) as it becomes available.

9. Deletion and return

When the organisation is deleted, the Processor deletes all its personal data immediately and completely, including uploaded files, unless Union or Member State law requires storage. The Controller may export the data first from the settings page.

10. Audit

The Processor makes available the information necessary to demonstrate compliance with Article 28 and allows for and contributes to audits, including inspections, conducted by the Controller or an auditor mandated by the Controller, on reasonable notice and at most once a year unless a breach or a supervisory authority requires otherwise. The source of the runner and the platform’s access rules are available to the Controller for review.

11. Law

Estonian law; the courts of Harju County, Tallinn; the English text is binding.

Annex 1 — Sub-processors

Not sub-processors: Cloudflare, which serves DNS for karusselllabs.com and does not proxy or receive platform traffic; GitHub, which the Controller already uses and which the platform reads only through an installation the Controller grants and can revoke.

Annex 2 — Technical and organisational measures

• Every table carries the organisation it belongs to and every access rule checks membership; this is enforced in the database, not in the application.
• The platform holds no customer credential; the runner refuses to upload anything shaped like one, and the build fails if that check is bypassed.
• Transport encryption everywhere; the application listens only on loopback behind a TLS proxy; firewalls at the host and on the server allow SSH, HTTP and HTTPS only.
• The model runs on the platform’s own server, reachable only from that server; no third-party model vendor receives data unless the Controller configures one.
• Uploaded files are stored in a private bucket under the organisation and request, served through links that expire within an hour, and removed with the request and the organisation.
• Deletion of an organisation cascades through every record and file it owns and runs immediately; an organisation must always keep an owner so that deletion remains possible.
• Server access logs are kept up to 30 days; drift reports older than two years are deleted by a scheduled job.
• Changes to the platform and the runner are version-controlled, reviewed in CI against a portability gate, a boundary gate and a secret scan, and deployed from the main branch only.