Data processing addendum

Last updated 2026-08-21 · Effective 2026-05-29

This Data Processing Addendum ("DPA") is part of the Terms of Service between BACKTHREAD OÜ ("Backthread", "us", "we") and the customer using the Backthread service ("Customer", "you"). It applies whenever we process personal data on your behalf under Article 28 GDPR — primarily, the source code we momentarily clone from your repositories and the personal data that may be inside it.

The structure follows Article 28(3) GDPR. If you are an individual user of the closed beta acting in a personal capacity (not on behalf of an organisation), Article 28 may not apply to you — in that case, our Privacy Policy is the primary document.

1. Definitions

Terms in this DPA that are not defined below have the meaning given to them by GDPR. "Applicable Data Protection Law" means the GDPR (Regulation (EU) 2016/679) and the Estonian Personal Data Protection Act (Isikuandmete kaitse seadus, 2018), plus any other data-protection law applying to a processing activity. "Customer Personal Data" means personal data inside the source code or repository content you connect to Backthread, and any personal data you upload to your Backthread account. "Sub-processor" means a third party we engage to process Customer Personal Data on our behalf.

2. Roles + subject-matter

You are the controller of Customer Personal Data. We are your processor.

The subject-matter of our processing is: generating a derived architecture diagram + per-module changelog from the repositories you connect; recording the decisions behind your coding-agent sessions; and writing and grading the lesson questions your teammates answer about those decisions.

The duration of processing is the term of your use of Backthread + the retention period in §11 below.

The nature and purpose of processing is to enable Backthread to derive, store, and display to you the architecture diagram + changelog described in the Terms of Service, to record the decisions behind your coding-agent sessions, and to write and grade the lesson questions your teammates answer about them.

The types of personal data processed are: any personal data you embed in your source code, commit messages, PR titles + bodies, or repository content; the redacted capture transcripts behind your decision log; the free-text answers your teammates type into lessons, together with the grader's verdict and note on each; plus the personal data described in the Privacy Policy §2.2–2.4, §2.8 and §2.9.

The categories of data subjects are: your developers, contributors, and any individuals named or identified in your repository content.

3. Customer instructions

We process Customer Personal Data only on your documented instructions, including with regard to transfers to a third country. The Terms of Service, this DPA, and the Privacy Policy constitute your documented instructions. We will inform you (and stop processing on the affected basis) if we believe an instruction infringes Applicable Data Protection Law.

4. Confidentiality + personnel

Our personnel with access to Customer Personal Data are bound by confidentiality. Access is granted on a need-to-know basis. The founder is the only person with admin access during the closed beta.

5. Security (Art 32)

We implement appropriate technical and organisational measures to secure Customer Personal Data. The current state is described in detail on Security and summarised here:

• Ephemeral processing. Each ingest runs in a fresh, isolated sandbox (Cloudflare Containers — Firecracker microVM). We clone with --depth 1, parse statically, write only derived data to our database, then destroy the sandbox. The clone, the installation token, and any in-memory representation of your code die with the sandbox.
• No source-code persistence. Customer Personal Data inside your source code is not retained outside the lifetime of a single sandbox.
• TLS in transit. All network paths use TLS terminated at Cloudflare.
• Encryption at rest by cloud providers. Supabase and Cloudflare encrypt at rest.
• Least-privilege GitHub access. The GitHub App takes contents, metadata, and pull_requests as read-only, scoped only to the repositories you select. No write, no admin, no secrets.
• Per-account isolation. Postgres row-level security scopes derived data by account_id.
• Safety budgets. Per-file size cap, total-bytes cap (zip-bomb guard), file-count cap, symlink-escape rejection, CPU + memory + wall-time caps.
• No code execution. No npm install, no require(), no eval of repository code.
• Secret hygiene. Worker secrets via the wrangler-secrets store. Service-role keys never enter any client bundle. Error messages are scrubbed of credentials before persistence.
• Auth-token life span. GitHub installation tokens are minted per-job and die with the sandbox.

6. Sub-processors (Art 28(2) + 28(4))

You give us general authorisation to engage sub-processors. The current sub-processors are:

We will publish notice of any new or replacement sub-processor on the Privacy Policy page at least 30 days before they begin processing Customer Personal Data. If you reasonably object to a new sub-processor on data-protection grounds within those 30 days, you may terminate your use of Backthread by email to hello@backthread.dev as your exclusive remedy, and we'll cooperate with a clean offboarding.

We impose on each sub-processor written terms that are no less protective than this DPA.

On analytics. Our websites load Cloudflare's cookieless page-view script (Privacy Policy §2.7). It measures visits to our own pages, which we process as controller, not on your behalf — so it is not a sub-processing activity under this DPA, and Cloudflare's row above is unchanged by it. We note it here only so that this table and the Security page cannot be read as disagreeing. One detail worth stating plainly: on app pages the path the script reports contains the repository slug being viewed. Cloudflare already receives that path as the host of every request to us, so the script discloses nothing to anyone who did not already have it.

7. International transfers

Where we transfer Customer Personal Data outside the EEA, we rely on the European Commission's Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914) incorporated into the relevant sub-processor's DPA — except for Google, whose processor terms apply a Data Transfer Solution (the EU–US Data Privacy Framework) where one is available and fall back to the Clauses only where it is not. §6 names the mechanism per sub-processor. The supplementary measures in §5 above — chiefly the no-persistence-of-source-code posture — apply to all such transfers.

One transfer is not covered by that sentence, and we would rather name it than let the sentence read as absolute. We push internal operational alerts to Telegram, a recipient rather than a sub-processor, described in full in the Privacy Policy §5. Those alerts can carry Customer Personal Data — a repository name, a GitHub login, an account identifier. Telegram is outside the EEA, has no DPA with us and therefore no SCCs. We should be straight about the tension in that: §1 above defines a sub-processor as "a third party we engage to process Customer Personal Data on our behalf", with no carve-out for tooling that is not part of delivering the product — and by that definition these alerts would fall in scope. We classify Telegram as a recipient because it is a channel we push notifications into under its own terms, but the classification is doing real work: it is what keeps Telegram out of §6's requirement that every sub-processor be under written terms no less protective than this DPA. Rather than lean on the label, the fix we are actually pursuing is to stop sending Customer Personal Data there at all. Narrowing what we send there is work we have on the list; until it is done, this paragraph is the honest position rather than a blanket assurance.

Where the transfer is subject to the UK or Swiss data-protection regimes, the UK Addendum (ICO) or the Swiss DPA, respectively, applies in addition to the EU SCCs.

A summary Transfer Impact Assessment is available on request to hello@backthread.dev.

8. Data-subject requests (Art 28(3)(e))

You are responsible for handling requests from your data subjects. We will, taking into account the nature of the processing, assist you by appropriate technical and organisational measures, including by:

• providing a self-serve export of derived diagrams on request;
• deleting derived data on your written instruction;
• responding to requests we receive directly from your data subjects by forwarding them to you and not actioning them on your behalf.

If a request relates to data inside your source code (the most likely case), we cannot directly action it: that data exists in your repository, not in our database. We will explain this to the data subject and point them to you.

9. Personal-data breach (Art 33)

We will notify you of a personal-data breach affecting Customer Personal Data without undue delay and in any event within 72 hours of becoming aware of it. Our notice will include, to the extent we know:

• the nature of the breach (categories + approximate numbers of data subjects + records concerned);
• the likely consequences;
• the measures we have taken or propose to take to address it and mitigate its effects;
• a contact point for further information.

Notice to your account-owner email address counts as notice to you.

You remain responsible for notifying the supervisory authority and affected data subjects where Article 33/34 GDPR requires.

10. Audits (Art 28(3)(h))

We make available to you the information necessary to demonstrate compliance with this DPA — including the Security page, this DPA, and the sub-processor DPAs we link from §6. On reasonable prior written request and no more than once per twelve months, we will respond to a written security questionnaire from you.

A physical, on-site audit is disproportionate at the scale of our operation; in lieu of one we will, on request, share the SOC-2 / ISO 27001 reports of our sub-processors (Supabase, Cloudflare, Google, Anthropic, GitHub) to the extent they make those reports available to us.

11. Return + deletion (Art 28(3)(g))

On termination of the Terms of Service:

• Source code: never persisted in the first place — there is nothing to return or delete beyond the in-progress sandbox, which we destroy.
• Derived data: we retain it until you explicitly request deletion, at which point we delete it from our database within 30 days. Backups expire on their normal schedule.

On your explicit request at any time during the term, we will delete derived data within 30 days.

We will keep records to demonstrate that deletion happened.

12. Liability + miscellaneous

The liability cap in the Terms of Service applies to claims arising under this DPA. This DPA is governed by Estonian law; disputes are subject to the jurisdiction clause in the Terms of Service. If a term of this DPA conflicts with a term of the Terms of Service on a data-protection matter, this DPA governs.

BACKTHREAD OÜ · registration number 17524049 · registered office Harju maakond, Tallinn, Lasnamäe linnaosa, Peterburi tee 92g, 13816, Estonia · hello@backthread.dev