01data processing agreement
Draft. Not yet reviewed by counsel.
draft dated 2026-09-03 · not effective
The parties have defined roles.
This data processing agreement is between the customer identified in the applicable service agreement, as controller, and the Reproloop service provider identified in that agreement, as processor. It forms part of that service agreement once executed.
The subject matter is the hosted service.
Reproloop processes personal data on the customer's behalf to provide Reproloop Cloud, including investigation, verification, release, delivery, administration, security, audit, support, and billing.
Processing follows the service term.
Processing continues for the term of the service agreement and for the limited period afterward needed to return or delete personal data, unless applicable law requires longer retention.
The nature and purpose are limited.
Reproloop receives support tickets and customer-authorised context, investigates them against connected docs, code, logs, account state, and history, reproduces technical failures, creates and verifies proposed resolutions, applies the customer's release policy, and delivers or escalates the result. Reproloop also processes the minimum account, security, audit, usage, and billing data needed to operate the service.
Data categories are defined.
- Customer content. Support tickets, messages, attachments, docs, repository content, changelogs, logs, account facts, history, evidence, patches, reproduction output, transcripts, and proposed actions.
- Identity and contact data. Names, business email addresses, organisation membership, roles, invitations, and identity-provider identifiers.
- Technical and security data. Request identifiers, credential metadata, timestamps, session metadata, authentication assertions, audit events, usage records, and billing references.
Data subjects are defined.
Data subjects can include the customer's personnel, administrators, contractors, end users, and people who submit or appear in support requests. Special-category data is not required for the service and should not be intentionally submitted unless the parties agree appropriate safeguards in writing.
Subprocessor purposes are listed.
- OpenAI. Model processing.
- Anthropic. Model processing.
- Box by ASCII. Isolated execution in the EU.
- GitHub. Repository and ticket connectivity.
- Stripe. Billing and invoices.
- Cloudflare. Network delivery and protection.
- Robotomail. Transactional email delivery.
The customer gives general written authorisation for these subprocessors under the service agreement. Reproloop remains responsible for their processing under equivalent data-protection obligations and will give notice before adding or replacing a subprocessor. The current status of each relationship appears on the security and trust page.
Security measures follow the published record.
Reproloop applies the following implemented measures:
- Forced, tenant-keyed PostgreSQL row-level security and least-privilege runtime roles.
- Per-request human membership checks, stored machine roles and scopes, distinct credential classes, keyed secret MACs, constant-time comparison, and revocation checks on each verification.
- Browser-bound rotating sessions, plus CSRF and origin checks.
- Application-level AES-256-GCM sealing for recoverable auth, connector, and browser secrets.
- Disposable Docker containers or Box VMs, execution egress controls, hardened containers, guarded result collection, and cleanup checks.
- Append-only tenant audit records and global and workspace kill switches.
The published record does not yet prove EU deployment, public TLS, storage encryption, encrypted backups, KMS-backed key custody, console MFA enforcement, retention automation, organisation and cross-store deletion, or an incident contact. Current and planned controls are separated on the security and trust page.
Deletion ends the processing.
At the customer's choice, Reproloop will return or delete personal data after the services end and delete remaining copies, unless applicable law requires retention. Credential, run-token, and session revocation takes effect on the next call. Runtime cleanup removes per-run Docker, Box, and browser resources. Docker and Box cleanup check their absence.
An organisation-deletion service, scheduled retention, customer-facing deletion requests, backup expiry, cross-store deletion for bundles and evidence, and physical media erasure proof must be operational before this draft becomes effective.