Skip to content
Watchdog
Sign inSurvey a repo — free

Legal — GDPR Art. 28

Data Processing Agreement

We do not write our own data-processing terms. Watchdog uses the Danish Data Protection Agency's standard contractual clauses, adopted under Article 28(8) GDPR after an opinion from the European Data Protection Board, and last amended 4 March 2024. The clauses are unmodified.

What is specific to us lives in the annexes below: what we process for you, who else is involved, and how it is secured and deleted. For a countersigned copy, write to us.

Annexes — each heading is a permanent link, so a clause can be cited.

A. Information about the processing

A.1 Purpose

We measure your codebases against a public, reproducible standard (the Codebase Assurance Index) and return the result as reports, metrics and trends. Personal data is processed only because (a) the service needs an account, and (b) source code and git history unavoidably identify the people who wrote them.

We do not process the data for our own purposes, and we do not train models on your code.

A.2 Nature of the processing

Temporary cloning of the connected repository, static analysis and analysis assisted by a language model we host on our own hardware, generation and storage of reports and metrics, and disposal of the working copy.

The processing is read-only: we never write to your repository, open no pull requests, and change nothing in your source system.

A.3 Types of personal data

  • Account data — provider identity: login, display name, email address.
  • Repository data — source code, and git metadata: commit authors' names and email addresses, timestamps and change history.
  • Derived data — reports, metrics and findings, which may quote short code excerpts and reflect git authorship (for example ownership and bus-factor analysis).

We do not knowingly process data covered by Article 9 or 10. Source code may incidentally contain personal data that you have put there; what the repository holds is yours to decide.

A.4 Categories of data subjects

  • Your users of the service (account holders).
  • Anyone appearing as an author in the connected repository's git history — including former employees and outside contributors.

A.5 Duration

Processing runs for as long as the repository is connected, and ends on account closure after the reversible period described in C.4.

B. Sub-processors

B.1 Approved sub-processors

  • Stripe Payments Europe, Limited (Ireland) — payment processing. Activates only when billing is taken into use. Card data never reaches our servers.

That is the whole list. The identity provider, the analysis engine, the language model, the database and report storage are all self-hosted on hardware we own in Denmark. No analytics SaaS, no error-tracking SaaS, no CDN, no cloud AI.

If you do not use billing, we have no sub-processors at all.

Your code host is your own relationship

GitHub, GitLab and any other code-hosting service you connect are not our sub-processors.

You have your own agreement with that service and you put your source there independently of this one. Connecting a repository grants us read access to material you have already placed with your own supplier. We disclose no personal data to the service, create nothing there, and never write to your repository.

Your relationship with the code host — its data-processing terms, its sub-processors and any transfers it makes — is governed by the agreement you hold with it, and sits outside this one. The same applies to any code host we support in future.

B.2 Notice before a new sub-processor

We update this page and email account owners before a new sub-processor begins processing, so you have time to object. The notice period is set in the signed agreement.

C. Instruction for processing

C.1 Subject matter and instruction

We may only: read the connected repository's default branch and your account identity at the chosen provider; clone the source into volatile memory and analyse it there; generate and store reports, metrics and findings derived from that analysis; and dispose of the working copy under C.4.

Connecting a repository, choosing a cadence and requesting a survey constitute your documented instruction.

C.2 Security of processing

The security level reflects that the processing covers a company's entire source code. It is not Article 9 data, but it is business-critical material where a breach would be serious for you. We therefore maintain a high level of security, and at minimum the following measures.

  1. Source code is cloned only into RAM. Both the source root and the engine's scratch space are tmpfs mounts, persisted in fstab so a restarted host never falls back to disk.
  2. The working copy is deleted when the scan finishes — completed, failed or cancelled alike — and a recurring sweep removes anything a crashed run left behind, once those remains are older than any scan that could still be using them.
  3. Storage is encrypted at rest. Database storage is encrypted at rest: production database volumes are encrypted using LUKS2 with AES-256 (XTS mode) full-disk encryption. Report artefacts (SARIF, SBOM, PDF and the other report bundles) are stored on a dedicated LUKS2-encrypted volume — AES-256-XTS, argon2id — on its own disk, unlocked at boot from a key file, with the break-glass key held off the machine.
  4. All processing and storage runs on hardware we own and operate in Denmark. There is no cloud provider in the data path.
  5. The language model is self-hosted. No code is sent to OpenAI, Anthropic, Google or any other AI provider, and we do not train on your code.
  6. Access is read-only. We never write to your repository.
  7. Report access mirrors your own access control at the provider and is re-synchronised daily; access lost there is access lost here.
  8. Analysis runs in a hardened container with no or controlled network access.
  9. Clones from untrusted URLs run with side-band protocols disabled and redirects not followed.
  10. These measures are asserted on every deploy. A host whose mounts, configuration, cleanup timer or encrypted volume has drifted from the above fails the release rather than serving customers from a state this section does not describe.

C.3 Assistance to the controller

We assist with data-subject requests. Account data you can delete yourself (C.4). For data originating in git history, we can delete what is held here, but not the source — that lives in your own repository, which we can read and never write.

We notify you without undue delay of a personal-data breach, under clause 9 of the standard clauses.

C.4 Retention and deletion

  • Source code, connected repository — held only in volatile memory (RAM), never written to persistent storage, and deleted when the scan that needed it finishes — completed, failed or cancelled alike. Anything a crashed run leaves behind is removed by a recurring sweep, which waits until those remains are older than any scan that could still be using them; nothing survives a restart of the host.
  • Source code, uploaded archive — held the same way, in RAM only, and likewise gone on restart. It is not deleted at the end of the scan, because unlike a repository it cannot be fetched again — you would have to upload it a second time. It is removed after seven days without use.
  • Per-scan working data — deleted when the scan finishes.
  • Reports and metrics — retained while the repository is connected.
  • Account data — you can close the account yourself. There is a 14-day reversible period; after it the data is deleted.
  • How deletion runs — an ordered cascade: identity at the identity provider, billing invitations, then anonymisation of the account record. It is fail-closed: if a step fails, the account is not marked deleted and the pass is retried.
  • Invoices — retained where bookkeeping law requires.

C.5 Location of processing

All processing and storage takes place on our own hardware in Denmark. No cloud provider is involved in compute, storage, identity or delivery.

C.6 Transfers to third countries

We transfer no personal data to third countries. Processing and storage are on our own hardware in Denmark, and the only sub-processor is established in the EU.

Payment. Our counterparty is Stripe Payments Europe, Limited, established in Ireland. Where Stripe subsequently transfers data to its US group company, it does so under Stripe's own data-processing agreement, which applies the European Commission's standard contractual clauses (Implementing Decision (EU) 2021/914, modules 1 and 2) together with EU-US Data Privacy Framework self-certification.

Your code host. If it sits in a third country, that is a transfer in your own agreement, not in this one. See B.1.

D. Other terms

No separate terms beyond the standard clauses and annexes A–C.