Legal

Data processing addendum

Effective 20 September 2026 Last updated 20 September 2026 KammCS, publisher of Boardhop

Placeholder. This document describes how Boardhop actually works, but its wording has not been reviewed by a lawyer and it is not yet binding. It is published so the app stores, the Marketplace listing and prospective customers have something to read during the beta. The reviewed version replaces it before public launch.

1. Parties and scope

This addendum applies between the organization that subscribes to the Boardhop relay (“Customer”) and KammCS (“Processor”), and forms part of the terms of service. It applies only to personal data processed through the Boardhop relay. It does not apply to organizations that use only the free app, because in that case no personal data reaches us at all.

Where the GDPR, the UK GDPR or a similar law applies to the Customer's use of the relay, this addendum is the Article 28 agreement between the parties.

2. Roles

The Customer is the controller of the event metadata and device registrations described below, and KammCS is the processor. Where KammCS determines its own purposes — billing records, account contacts, security logs — it acts as an independent controller under its privacy policy.

3. Subject matter and duration

Subject matter: the delivery of push notifications about events in the Customer's Azure DevOps organization to the devices of that organization's members.
Duration: for as long as the Customer's subscription or trial is in effect, plus the retention periods in section 11.
Nature and purpose: receiving event metadata from Azure DevOps, determining the audience, and transmitting a pointer to Apple's and Google's push services.

4. Data and data subjects

Data subjects: members of the Customer's Azure DevOps organization who install Boardhop.

Categories of personal data:

  • Azure DevOps user identifier and display name
  • Device push token issued by Apple or Google
  • Notification preferences and quiet hours
  • Identifiers and short titles of the work items, pull requests, runs and approvals a notification points to
  • Dates on which a user was active, for billing
  • Billing contact name and email address

Not processed: comment bodies, work item descriptions, source code, diffs, wiki content, attachments or Azure DevOps credentials. The relay reads webhook payloads in memory to determine the audience and persists nothing from them.

Special categories: none are intentionally processed.

5. Our instructions

KammCS processes personal data only on the Customer's documented instructions, which are: these documents, the configuration the Customer's administrators set in the admin hub, and the app settings each user chooses. KammCS will tell the Customer if it believes an instruction breaks data protection law.

6. Confidentiality

Everyone with access to personal data is bound by confidentiality obligations, and access is limited to those who need it to run and support the service.

7. Security measures

  • TLS for every connection, inbound and outbound.
  • Per-organization shared secrets on webhook intake, verified on every request.
  • Azure DevOps tokens are used to verify organization membership and then discarded; they are never written to storage.
  • Push credentials for Apple and Google exist on the gateway only, with restricted file permissions, and are never copied into an image or a backup.
  • Encrypted storage at rest on the host, with restricted administrative access over key-based SSH only.
  • Data minimisation as the primary control: what is never stored cannot be breached.
  • Logs redact credentials and retain for 30 days.

The current measures are described further on the security page. KammCS may change them, provided the level of protection is not reduced.

8. Subprocessors

The Customer gives general authorisation for the subprocessors listed on the subprocessors page. KammCS imposes equivalent obligations on each and remains liable for their performance. At least 30 days' notice is given before a new subprocessor is added, and the Customer may object on reasonable data protection grounds; if the objection cannot be resolved, the Customer may terminate the affected subscription without penalty.

9. Assistance to you

Taking into account the nature of the processing, KammCS assists the Customer with data subject requests, data protection impact assessments and consultations with supervisory authorities. In practice most requests are satisfied by the Customer's own Azure DevOps administration, because that is where the underlying data lives; for the limited data held by the relay, KammCS responds within 10 business days of a request from the Customer.

10. Personal data breaches

KammCS notifies the Customer's billing and security contacts without undue delay and in any event within 48 hours of becoming aware of a personal data breach affecting the Customer's data, with the nature of the breach, the categories and approximate number of records affected, the likely consequences and the measures taken.

11. Deletion and return

Device registrations and notification preferences are deleted when a user signs out, when the push token is rejected, or after 90 days of inactivity. On termination all of the Customer's device registrations and preferences are deleted within 30 days. The active-user ledger is kept for 24 months as a billing record and the invoices for as long as tax law requires.

12. Audits

KammCS makes available the information needed to demonstrate compliance with this addendum and, on reasonable notice and no more than once a year, allows an audit by the Customer or an independent auditor bound by confidentiality, at the Customer's cost, subject to reasonable arrangements to protect other customers' data.

13. International transfers

The relay runs in the European Union. Where personal data is transferred outside the EEA or the UK — to Apple's or Google's push services, or to Stripe — the transfer is made on the European Commission's Standard Contractual Clauses or another valid mechanism, and the data transferred is limited to what is described in section 4. An organization that requires event metadata to remain entirely inside its own tenancy should use the self-hosted relay.

14. How to put this in place

Email privacy@boardhop.dev with your organization's legal name and address. We will return a countersigned copy. A self-serve signature flow will replace this step before public launch.