Data processing agreement: Pilotless GitHub App
This version takes effect on the date of publication: 23 October 2026. A signed copy applies from the date both parties sign it.
This agreement is between:
The customer who installs the Pilotless GitHub App, the controller.
Kadima Technology (Pilotless is a product of Kadima Technology), the processor. Kadima Technology is a sole proprietorship (eenmanszaak) of Jacobus Meulen, Van den Boetzelaarstraat 42, 6081 BT Haelen, Netherlands, KvK 80033105.
We sign it with any installing customer who asks. It applies to personal data that Pilotless processes for the customer through the App. It meets the requirements of Article 28 of the GDPR. Where this agreement and other terms between us conflict on data protection, this agreement wins.
1. What we process and why
Subject matter and purpose. We build a weekly status digest and post it as one issue in each repository the customer selects. We do nothing else with the data.
Data subjects. People who work in the selected repositories.
Categories of personal data:
GitHub handles of people active in the selected repositories
Repository activity metadata: pull requests, issues, commits, their authors, states and timestamps
We read repository activity when we build the digest. We do not store code or the digest text. For this agreement's scope, we store:
the selected repositories and their names
installation status and timestamps
references to the digest issues
roadmap items: the organisation login, a title and summary written by the editor (up to 4,000 characters), an optional owner login, the login of whoever last updated the item, links, and a derived status
for each issue or pull request linked to a roadmap item, a snapshot of its state, last-updated time, merged flag and assignee logins, including items in private repositories the installation can see
daily event counts
We don't store issue or pull request bodies, comments, GitHub titles, labels or milestones.
No special categories of personal data are processed.
Out of scope. The account the App is installed on, its type, and the installer's GitHub login. Kadima Technology is the controller for that data, and our privacy notice covers it.
2. Duration and deletion
This agreement runs for as long as the App is installed. When the customer uninstalls the App, a weekly scheduled purge deletes the stored data 30 days after uninstall. Deleted data can remain in backups for up to 7 days before it is overwritten. Digest issues already posted stay in the customer's repositories, under the customer's control.
3. Our obligations
We will:
Instructions. Process the data only on the customer's documented instructions. Installing and configuring the App, and this agreement, are those instructions. If we believe an instruction breaks data protection law, we will say so.
Confidentiality. Make sure anyone who can access the data is bound to confidentiality.
Security. Take appropriate technical and organisational measures (Annex 1).
Data-subject rights. Help the customer respond to requests from people exercising their GDPR rights, as far as we reasonably can. If a request reaches us directly, we pass it on to the customer.
Other help. Help the customer with security, breach notification, impact assessments and prior consultation (GDPR Articles 32 to 36), as far as our role and the information we have allow.
Breaches. Tell the customer without undue delay, and in any case within 48 hours of becoming aware, of a personal data breach that affects their data. We will include what we know and update it as we learn more.
Deletion or return. At the end of the service, delete the data (section 2). If the customer asks before uninstalling, we return a copy first. Deleted data can remain in backups for up to 7 days before it is overwritten.
Audits. Give the customer the documentation needed to show we comply with this agreement. If that documentation is not enough, we allow an on-site audit by the customer or an auditor it appoints, with reasonable notice. Audits happen at most once a year, at the customer's cost.
4. Sub-processors
The customer authorises these sub-processors:
| Sub-processor | What it does | Location |
|---|---|---|
| Google Cloud | Runs our server (Cloud Run) and database (Firestore) | Cloud Run: europe-west1, Belgium. Firestore: EU (Google Cloud multi-region eur3, Belgium and the Netherlands) |
| Bunny CDN (BunnyWay d.o.o., Ljubljana, Slovenia) | Passes requests and GitHub event data through to our server; keeps no request logs for our site | EU edge locations only |
GitHub is not a sub-processor. It is a platform the customer already uses under its own agreement with GitHub; the App works there only through the permissions the customer grants.
Before we add or replace a sub-processor, we tell the customer at least 30 days in advance at the contact address they gave us. The customer has the right to object, on reasonable data protection grounds, within that period. If we can't resolve the objection, the customer can uninstall the App, which ends this agreement. We hold each sub-processor to data protection obligations at least as strict as these.
5. International transfers
We store the data in the EU. Our server runs in Google Cloud's europe-west1 region (Belgium), and our database location is EU (Google Cloud multi-region eur3, Belgium and the Netherlands). Bunny CDN is run by BunnyWay d.o.o., an EU company, and uses EU-only edge locations, so no transfer outside the EU happens there. Where Google's US entities can access the data, we rely on the Google Cloud Data Processing Addendum, which includes the EU Standard Contractual Clauses, and on Google's certification under the EU-US Data Privacy Framework.
6. Liability
Each party's total liability under this agreement is limited to the greater of:
the fees the customer paid Pilotless in the 12 months before the claim, or
EUR 1,000.
There is no limit for damage caused by intent or gross negligence (opzet of grove schuld), or where the law does not allow a limit.
7. Law and disputes
Dutch law governs this agreement. Disputes go to the Rechtbank Limburg.
8. Contact
Data protection questions and breach notices: jacobus@kadima-tech.com.
Signatures
| Customer (controller) | Kadima Technology (processor) | |
|---|---|---|
| Name | [CUSTOMER NAME] | [SIGNATORY NAME] |
| Organisation / GitHub account | [CUSTOMER ORGANISATION / ACCOUNT] | Kadima Technology |
| Date | [DATE] | [DATE] |
| Signature | [SIGNATURE] | [SIGNATURE] |
Annex 1: Technical and organisational measures
Least-privilege App permissions: write access to issues only; read access to pull requests, contents and metadata.
Data minimisation: we do not store code or digest text.
EU hosting region: our server runs in Google Cloud europe-west1 (Belgium). Database location: EU (Google Cloud multi-region eur3, Belgium and the Netherlands).
Deletion: a weekly scheduled purge deletes stored data 30 days after uninstall.
Access control:
Access to cloud resources is managed with Google Cloud IAM.
Deploys run from GitHub Actions without stored keys, through Workload Identity Federation, as a single deploy service account.
Admin endpoints accept only that identity.
Access to our GitHub organisation is limited to two accounts.
Encryption: data at rest is encrypted with Google-managed encryption (Firestore, container images, Secret Manager). Data in transit uses TLS, including where it passes via the Bunny CDN.
Backups: backups keep copies for 7 days. Deleted data can remain in backups for up to 7 days before it is overwritten.
Logging: Our application does not log requests, email addresses or account details. If the server hits an unexpected error, our hosting provider's error logs may contain technical details such as an IP address and an error trace; these logs are kept for 30 days. Cloud Run request logs (IP address, user agent, referrer, URL) are kept for 30 days. Google Cloud also keeps admin-activity and system audit logs for 400 days, a period Google sets and we can't shorten; these record actions by our own accounts and service accounts on the infrastructure, not site visitors.
Secrets: stored in Google Secret Manager, not in the database or code; access is limited to the runtime service account.