Squally Data Processing Agreement (Art. 28 GDPR)

Effective date: 29 October 2026

This Data Processing Agreement ("DPA") is concluded between the organization using Squally ("Controller") and Mohamed Abid, Gustav-Schulenburg-Str. 24, 76189 Karlsruhe, Germany ("Processor"). It forms part of the Beta Terms (https://squally.dev/terms) and later of any paid terms and is concluded when the Beta Terms are accepted. A signed PDF copy is available on request from support@squally.dev.

1. Subject matter and duration

1.1 The Processor processes personal data contained in Customer Data on behalf of the Controller to provide Squally.

1.2 The DPA applies for as long as the Processor processes Customer Data for the Controller.

1.3 Account data of users (name, email, login) and billing data are processed by the Processor as a controller in its own right and are covered by the privacy policy, not by this DPA.

2. Nature, purpose, data and data subjects

Purpose: receiving, storing, analysing and displaying test results from the Controller's CI; reports; optional AI analysis started by the Controller.

Types of data (as far as the Controller's tests and CI send them): test names, file paths, step titles, results and durations, error messages and stack traces, console output, page snapshots, screenshots and traces, CI metadata (branch, commit SHA, commit message, commit author name, CI provider, CI run URL, operating system, Playwright version), test configuration (Playwright projects with browser, viewport and artifact settings, timeouts, retries, workers, reporter names; the repository name unless the Controller disables it; the base URL only if the Controller enables it). Commit author email addresses are not sent.

Data subjects: the Controller's employees and contractors (e.g. commit authors), test users and any persons whose data appears in the test content.

The Controller must not send special categories of personal data (Art. 9 GDPR).

3. Instructions

3.1 The Processor processes personal data only on documented instructions from the Controller. The Beta Terms, this DPA and the Controller's use and configuration of Squally (app settings, API calls, enabled integrations) are the Controller's instructions.

3.2 The Processor informs the Controller without delay if it considers an instruction to infringe data protection law. The Processor may suspend carrying out that instruction until the Controller confirms or changes it.

4. Confidentiality

The Processor ensures that persons authorised to process the data are bound to confidentiality. At present, only the Processor personally has access to production systems.

5. Security

The Processor implements the technical and organisational measures in Annex 1 (Art. 32 GDPR). The measures may be adapted to technical progress as long as the level of protection is not reduced.

6. Sub-processors

6.1 The Controller gives general authorisation to engage the sub-processors listed in Annex 2.

6.2 The Processor will inform the Controller by email at least 30 days before adding or replacing a sub-processor. The Controller may object for important data protection reasons within this period. If no solution is found, the Controller may terminate the contract.

6.3 The Processor imposes data protection obligations on each sub-processor that are equivalent to this DPA.

7. Assistance

7.1 The Processor assists the Controller with requests from data subjects. Projects or the whole organization can be deleted in the app; on the Standard and Pro plans, runs and test results can be exported via the read API. Where the app offers no self-service function, the Controller can contact support@squally.dev.

7.2 The Processor assists the Controller in meeting its obligations under Art. 32 to 36 GDPR, taking into account the information available to it.

8. Personal data breaches

The Processor notifies the Controller without undue delay, and where possible within 48 hours, after becoming aware of a personal data breach affecting Customer Data. The notice contains the information required by Art. 33(3) GDPR as far as available.

9. Deletion and return

9.1 Customer Data is deleted automatically after the retention period of the Controller's plan.

9.2 When the organization is deleted, it is locked immediately and all Customer Data is deleted permanently after 30 days unless the owner restores it. On the Standard and Pro plans, the Controller can export runs and test results via the read API before deleting the organization.

9.3 Database backups (point-in-time recovery) expire within 1 day.

9.4 On request, the Processor confirms the deletion in text form.

10. Audits

10.1 The Processor provides the Controller with the information necessary to demonstrate compliance with Art. 28 GDPR.

10.2 Further audits, including inspections, are possible after at least 30 days' notice, during business hours, without disrupting operations and at most once a year, unless there is a specific reason. Each party bears its own costs.

11. Transfers outside the EU

Transfers to third countries take place only with the safeguards listed in Annex 2 (EU-U.S. Data Privacy Framework under Art. 45 GDPR or Standard Contractual Clauses under Art. 46(2)(c) GDPR).

12. Liability and precedence

12.1 Liability is governed by Art. 82 GDPR and the Beta Terms.

12.2 In case of conflict, this DPA takes precedence over the Beta Terms with regard to data protection.

Annex 1 — Technical and organisational measures

Access to systems and data

• Login with password (hashed with scrypt) or Google sign-in; sessions expire after 7 days without use.
• Passwords checked against known leaks (Have I Been Pwned, k-anonymity: only the first 5 characters of a hash leave Squally).
• Bot protection on sign-up and password reset (Cloudflare Turnstile); rate limits per IP on all authentication endpoints; limits on code emails per address.
• Rate limits at the firewall: 300 requests per minute per ingest key, 60 per minute per read key, 1,000 per minute per IP; plus monthly quota and batch size per plan.
• Role model per organization (owner, admin, member); data separated per organization and project.
• One ingest key per project, can be regenerated at any time; read keys per organization, with expiry and revocable.
• Automatic deletion after the retention period and after organization deletion is active in production.
• Production access only by the Processor, with multi-factor authentication on provider accounts.

Transfer

• TLS for all connections; cookies Secure and httpOnly where applicable.

Availability and resilience

• Hosting in Frankfurt (Vercel, Neon); file storage in the EU (Cloudflare R2).
• Point-in-time recovery of the database for 1 day.
• Error monitoring (Sentry).

Data minimisation and deletion

• Retention per plan (at most 90 days for runs and results).
• Screenshots, traces and console output: 7 days for attempts that passed first time, 21 days for failures and retries.
• Organization deletion: locked immediately, deleted after 30 days.

Organisation

• Procedure for handling personal data breaches (section 8).
• Review of sub-processors before engagement.

Annex 2 — Sub-processors

Not sub-processors under this DPA: integrations the Controller activates itself (GitHub App, Slack webhook, Playwright Trace Viewer), and services that do not receive Customer Data (Cloudflare Turnstile, Google sign-in, Have I Been Pwned, Formspree).