Data Processing Agreement

Last updated: [date]

This Data Processing Agreement ("DPA") forms part of the Terms of Service between [Company Legal Name], [Company Address], [Country of Incorporation] ("Processor", "we") and the customer organisation that accepted them ("Controller", "you"). It applies where we process personal data on your behalf under Article 28 GDPR. Annex IV applies additionally to customers subject to Turkish Law No. 6698 (KVKK).

Where this DPA and the Terms conflict on data protection, this DPA wins.

1. Subject matter and duration

We process personal data only to provide the mobile test automation Service described in the Terms: running your app builds on devices, storing the artifacts those runs produce, and giving your organisation access to them. Processing lasts for as long as your account exists, plus the retention windows in Annex I.

2. Nature and purpose

Installing and executing your app build on a device; capturing screenshots, video, logs and accessibility hierarchies from the run; storing and serving those artifacts; storing run and test metadata; authenticating and authorising your members; delivering notifications you configure; and, where you have set your own model provider key, forwarding a bounded failure bundle toward that key on your instruction.

3. Categories of data subjects and personal data

Data subjects

• Your members and administrators (the people who sign in to the panel).
• Any person whose personal data appears in your test data, test accounts, or on screen during a run — for example your own end users, if you test against non-synthetic data.

Personal data

• Account data: name, email, role, authentication and two-factor material, SSO/SCIM identity.
• Customer Content: app builds, test flows and their fixtures, screenshots, video, accessibility hierarchy dumps, logs, run and test metadata, issues, and whatever personal data those happen to contain.
• Operational data: audit events (who did what), device-minute usage, and technical logs including IP addresses.

We do not require special-category data. If you put it into test data, you remain responsible for having a lawful basis and for telling us in advance where a heightened measure is needed.

4. Your instructions

4.1 We process personal data only on your documented instructions. This DPA, the Terms, and your use of the Service's own configuration (retention windows, masking rules, model data policy, region, connected integrations) are those instructions.

4.2 We tell you if, in our view, an instruction breaches the GDPR or other EU or Member State data protection law.

4.3 If a law requires us to process beyond your instructions, we tell you before doing so unless that law forbids it.

5. Confidentiality

Everyone we authorise to process your personal data is bound by confidentiality — by contract of employment or by a written agreement — and access is limited to those who need it to run or support the Service.

6. Security

We implement the technical and organisational measures in Annex II, and keep them appropriate to the risk. We may change a measure as long as the level of security does not drop.

7. Sub-processors

7.1 You give general authorisation for us to use sub-processors. The current list is Annex III, kept up to date at subprocessors.md.

7.2 We will give at least 30 days' notice before a new sub-processor starts processing your data, by updating that page and notifying the address you gave for notices.

7.3 You may object on reasonable data protection grounds within that notice period. We will work with you on an alternative; if there is none, you may terminate the affected part of the Service without penalty for the unused prepaid term.

7.4 We impose data protection obligations on each sub-processor that are no less protective than this DPA, and remain fully liable to you for their performance.

7.5 A model provider you connect with your own key, and any channel you configure (Slack, PagerDuty, Jira, GitLab, and your own agent endpoint), is your processor, not our sub-processor. We route to it because you instructed us to.

8. Assistance to you

We assist you, at your cost where the effort is more than trivial:

• Data subject requests — by the export and deletion functions in Organization › Data, and otherwise by reasonable help. If a data subject contacts us directly about your data, we forward the request to you and do not answer it ourselves.
• Personal data breach — we notify you without undue delay and in any case within 48 hours of becoming aware of a breach affecting your personal data, with what we know: nature, categories and approximate numbers affected, likely consequences, and the measures taken. We keep you updated as we learn more, and support your Art. 33/34 notifications.
• DPIA and prior consultation — reasonable assistance under Art. 35 and 36, given the nature of the processing and what we know.

9. Deletion and return

9.1 You can export your organisation's data at any time (Organization › Data → export): one JSON document containing the organisation, settings, projects, tests, suites, runs, issues, the most recent audit events, and an index of artifacts with time-limited download links.

9.2 On termination, or on request, you can delete your data with the deletion request in the same place. It is owner-only, requires you to type the organisation slug to confirm, runs after a 7-day grace period during which you can cancel, and then deletes every project of the organisation and all data cascading from it, including stored objects. The organisation record, its membership and the audit trail survive — the audit event recording the deletion is the evidence that it happened.

9.3 Data not covered by 9.2 ages out under the Annex I retention windows. Backups are not a way around a deletion request: a restored backup is used only for disaster recovery, never to reconstitute deleted data.

10. Audits

10.1 We make available the information needed to show compliance with Art. 28 — this DPA, our published policy set, and the evidence described in it.

10.2 You may audit no more than once a year (and after a breach affecting your data) on 30 days' written notice, during business hours, without disrupting operations, and subject to confidentiality. In the first instance we may satisfy an audit with our documentation, our policy set, and any third-party report we hold.

10.3 Where we hold a third-party report (for example a SOC 2 report or a penetration test report), we make it available under NDA. We do not hold one today; see [docs/compliance/](../compliance/README.md) for the current state of that programme. We will not claim otherwise.

11. International transfers

11.1 Your data is hosted in the EU (Annex I). Where personal data is transferred out of the EU/EEA — because you or one of your users is outside it, because you enable a sub-processor outside it, or because our support access happens from outside it — the transfer is made under the European Commission's Standard Contractual Clauses (Decision 2021/914), incorporated into this DPA by reference, with the module appropriate to the parties' roles (normally Module Two, controller to processor; Module Three where we transfer to a sub-processor).

11.2 For the purposes of those Clauses: the docking clause applies; Annex I, II and III of this DPA populate the corresponding annexes; the supervisory authority is [Supervisory Authority]; and the governing law and forum are those in Clause 17 and 18 as specified in [Governing Law and Courts].

11.3 We carry out a transfer impact assessment where one is needed and apply supplementary measures — encryption in transit, encryption of secret material at rest, and minimisation of what leaves the EU.

12. Liability

Each party's liability under this DPA is subject to the limitations and exclusions in the Terms, except where the GDPR or other mandatory law does not allow it.

13. Term

This DPA takes effect when you accept the Terms and ends when we have deleted or returned all personal data under section 9.

Annex I — Processing details

Annex II — Technical and organisational measures

These are the measures actually implemented. Where a measure is planned but not yet in place, it is marked as such rather than claimed.

Access control and authentication

• Sign-in through Better Auth with email and password, GitHub, or the organisation's own OIDC single sign-on. An organisation can enforce SSO for its verified email domains, with break-glass local accounts so it cannot lock itself out.
• TOTP two-factor authentication with backup codes for local accounts.
• Four organisation roles (owner, admin, member, viewer) enforced per route, plus a bounded session lifetime configured per organisation (default 7 days).
• SCIM provisioning and deprovisioning from the customer's identity provider, and an IP allowlist for the API and MCP surfaces.
• Machine access is by scoped project tokens (author, run, analyze, upload, runner), each pinned to one project of one organisation, revocable and expiring. Actions that hand out capabilities — issuing tokens, storing keys, changing secret patterns — are session-only, so a leaked machine token cannot escalate.

Tenant isolation

• Every route resolves the row it touches to its project and organisation and compares it against the actor, so a token or session never reads across organisations.
• One job per device at a time; cloud device slots are reset between jobs.
• A runner writes only to the job it has leased.

Encryption

• TLS for all traffic to the control plane, the panel and the API.
• Customer secrets — model provider keys and other bring-your-own credentials — are encrypted at rest with AES-256-GCM under a key derived from the deployment secret, and are never returned in clear (only the last four characters are shown).
• Artifact download links are HMAC-SHA256 signed with a 10-minute default lifetime, verified in constant time, and served cache-control: private, no-store.
• Runner binaries are signed with Ed25519 and verified by the runner against a public key compiled into it, so an unsigned or altered update never replaces a running binary.

Data minimisation and masking

• Project tokens, runner secrets, Bearer header values and sk-… style provider keys are always masked out of logs and hierarchy dumps, along with every organisation-wide masking rule and per-project secret pattern, before the artifact leaves the server. The rules themselves are treated as secrets and are never returned.
• The model data policy (hierarchy, screenshots, logs) bounds what may ever be sent toward a customer's own model key. Screenshots and logs are off by default; with no key set, nothing leaves toward an external model provider at all.
• Known limitation, disclosed rather than hidden: masking today runs on the artifact download path. Failure bundles and public report artifacts read storage directly; extending masking to them is tracked in docs/security.md.

Logging and tamper evidence

• Every admin, agent and system action is written as an audit event: actor type and id, action, target and payload.
• Audit events form a per-organisation hash chain: each row carries the SHA-256 of the previous row's hash concatenated with a canonical JSON of the event's fields, and the insert holds a per-organisation advisory lock so concurrent writes cannot fork the chain. Altering or removing a row breaks the chain and is detectable.
• Audit events are exportable as CSV and can be streamed live to the customer's own SIEM.

Availability and resilience

• Daily database snapshots with continuous write-ahead logging, retained 30 days, with restore drills — see docs/compliance/business-continuity.md.
• A retention job runs on a schedule and writes a record of every deletion pass, including rows deleted and bytes freed, so retention is itself auditable.

Change management

• Code review, and CI gates for lint, typecheck, unit tests, per-tool contract tests and the runner build, before anything reaches production. Migrations and release signing are part of the same pipeline. See docs/compliance/change-management.md.

Incident response

• Documented severities, on-call, a public status page and postmortems — see docs/compliance/incident-response.md — feeding the 48-hour breach notification in section 8.

Not yet in place (stated so no one relies on it): no completed SOC 2 audit, no third-party penetration test report, and no application-level rate limiting independent of the edge.

Annex III — Sub-processors

The authoritative, dated list is subprocessors.md. At the date of this DPA:

Model providers used with the customer's own key are not our sub-processors — see section 7.5.

Annex IV — KVKK annex (Turkish customers)

This Annex applies where the Controller is subject to Turkish Personal Data Protection Law No. 6698 ("KVKK"). It supplements, and does not replace, the rest of this DPA.

1. Roles. For personal data processed in the Service, the Controller is the veri sorumlusu (data controller) and [Company Legal Name] is the veri işleyen (data processor) under KVKK Art. 3. We process personal data only on the Controller's instructions, and we are jointly responsible with the Controller for taking the security measures required by KVKK Art. 12 within our own sphere.

2. Security. The measures in Annex II are the measures we apply for the purposes of KVKK Art. 12(1), read together with the Board's published guidance on technical and organisational measures.

3. Cross-border transfer. The Service is hosted in the EU, so personal data of Turkish data subjects is transferred abroad within the meaning of KVKK Art. 9. The Controller and the Processor will put the Board's standard contract (standart sözleşme) in place for that transfer and the Controller will notify it to the Kişisel Verileri Koruma Kurumu within the statutory period following signature. The completed standard contract, and any other basis the parties agree (an explicit consent, an undertaking, or an adequacy decision if one is later issued), is at: [Cross-border transfer basis — to be completed by the Controller's counsel]. Until that instrument is in place, the Controller is responsible for confirming it has a lawful basis for the transfer.

4. Breach notification. Where a breach affects personal data of Turkish data subjects, we notify the Controller within the 48-hour window in section 8, so that the Controller can meet its own obligation to notify the Board as soon as possible — in practice within 72 hours of becoming aware, per the Board's decision on the subject — and to notify affected data subjects.

5. Data subject applications. Applications under KVKK Art. 11 are made to the Controller as veri sorumlusu. Where such an application reaches us, we forward it to the Controller and assist under section 8 rather than answering it ourselves.

6. VERBİS. Registration with VERBİS, where the Controller's registration duty applies, is the Controller's own obligation. We provide the processing information in Annex I so the Controller can complete its entry.

7. Interpretation. Where KVKK and the GDPR both apply, the stricter requirement governs. Terms not defined here have the meaning given in KVKK.