Data processing agreement
Draft for legal review. Not in force. Last updated: [date of publication]
This agreement ("DPA") is part of the Terms of Service between the customer ("Customer") and [Company] ("Trailcam"). It applies when Trailcam processes personal data on Customer's behalf in providing Trailcam.
1. Roles
Customer is the controller (or a processor for its own customers) of the personal data in its workspaces' content. Trailcam is its processor and processes that data only to provide Trailcam, on Customer's documented instructions: these terms, this DPA, and what Customer's people do in Trailcam. If Trailcam believes an instruction breaks data protection law, it will say so.
2. What's processed
See Annex 1. Customer is responsible for the lawfulness of the data it puts in Trailcam, and for using test data in flows rather than real people's (Terms, section 2).
3. Trailcam's commitments
- Confidentiality: only people who need to, under confidentiality obligations, can access customer data.
- Security: the measures in Annex 2, kept up to date.
- Sub-processors: the ones listed at trailcam.dev/subprocessors are approved. Trailcam gives at least 30 days' notice of a new one (by email to Owners and on that page); Customer may object on reasonable data protection grounds, and if we can't resolve it, end the affected part of the service with a prorated refund. Trailcam binds each sub-processor to terms that protect the data at least as well as this DPA, and is responsible for them.
- People's requests: Trailcam helps Customer answer requests from people about their data (access, correction, deletion), mostly through the product itself (exports, and deleting projects and workspaces).
- Breaches: Trailcam tells Customer without undue delay, and within 72 hours of becoming aware of a breach affecting customer data, with what's known and what's being done, and helps Customer meet its own obligations.
- Assessments: Trailcam gives reasonable help with data protection impact assessments and consultations with regulators.
- Deletion: when Customer deletes a workspace (or its account ends), Trailcam deletes its data at once, its files within a day, and backups age out within [backup retention]. Customer can export its data before then.
- Audits: Trailcam answers reasonable security questionnaires once a year, shares summaries of independent security assessments (such as penetration tests) when it has them, and allows an audit by an independent auditor where the law requires it, at Customer's cost and with reasonable notice.
4. Transfers
Trailcam processes customer data in the United States. Where a transfer from the EU, EEA, UK or Switzerland needs a safeguard, the [EU standard contractual clauses (module two, controller to processor; module three where Customer is a processor) and the UK addendum] apply and are incorporated by reference, with the annexes below as their annexes.
5. Term
This DPA lasts as long as Trailcam processes customer data for Customer. Liability under it is subject to the Terms' limits, except where the law doesn't allow that.
Annex 1: Processing details
- Subject matter and purpose: providing Trailcam: storing customers' builds and flows, running them on simulators and emulators, recording runs and the requests Customer's apps make during them (the network log: where each went, how it answered and how long it took, never what it carried) and the screens they pass through (checked for accessibility, with pictures of those with problems), receiving the email Customer's apps send to a run's own address (the test inbox), sending alerts and reports, and (when on) Trailcam AI.
- Duration: for as long as the workspace exists; recordings, with the email runs received, their network logs and their accessibility reports, for as long as its plan keeps them.
- Nature: storage, running apps on emulated devices, recording their screens, analysis by AI models (when on), transmission to Customer's chosen alert channels.
- People whose data it is: Customer's people who use Trailcam; and anyone whose data Customer puts in its apps' test data, builds or flows (which the Terms ask Customer to avoid).
- Kinds of data: names and email addresses of Customer's people; whatever personal data appears in Customer's builds, flows, test accounts, the screens, logs and screenshots of runs, the addresses its apps' requests go to (with a query's names, not its values), and the email its apps send to runs' addresses.
- Special categories: none intended; Customer shouldn't put them in Trailcam.
Annex 2: Security measures
- Isolation: each run on its own throwaway virtual machine or container, discarded afterwards, with no access to the host, other runs or Trailcam's network; every device host proves this before taking runs.
- Separation: every query on a workspace's data runs within that workspace in the database (row-level security), and every API route is tested to refuse other workspaces' data.
- Encryption: TLS for every connection; alert channels' addresses and keys sealed with AES-256-GCM; the providers' encryption at rest for databases and files.
- Access: Customer's people by role (Owners, Admins, Members, Viewers), recent sign-in required for sensitive changes; Trailcam staff by individual account, with every staff action in a staff audit log.
- Keys: device hosts each have their own key, revocable at once; CI keys per project, revocable by Customer.
- Monitoring: request and error logs, Content Security Policy reports, alerts on failures; a written incident process.
- Development: code review, automated tests (including isolation and security tests), dependency and secret scanning, and an independent penetration test before launch.
- Backups: point-in-time recovery of the database, with restores tested.
Annex 3: Sub-processors
As listed at trailcam.dev/subprocessors.