ChirpCloud data processing agreement
Version: 2026-11
1. Parties and scope
1.1 This agreement is between the customer ("Customer", controller) and Trackpac Ltd, trading as ChirpCloud ("ChirpCloud", processor). It forms part of the ChirpCloud subscription terms and is made under Article 28 of the UK GDPR and, where it applies, of the EU GDPR (together "data protection law"). ChirpCloud's representative in the EU under Article 27 of the EU GDPR is Connect IoT Group B.V., Wognumsebuurt 3, 1817 BH Alkmaar, the Netherlands.
1.2 It applies to personal data that ChirpCloud processes on the Customer's behalf in providing the service ("Customer Personal Data"). That is personal data contained in: (a) device payloads (uplinks and queued downlinks) and device metadata; (b) device, gateway, application and profile configuration, including gateway locations; (c) other content the Customer enters into its workspace.
1.3 It does not cover account, billing, support and security-log data. ChirpCloud processes that as controller under its privacy notice.
2. Details of processing (Annex 1)
| Item | Detail |
|---|---|
| Subject matter | Hosting a LoRaWAN network server: receiving, decoding and routing device messages, delivering them to the Customer over MQTT, and storing the Customer's configuration |
| Duration | The subscription, plus retention and deletion under section 7 |
| Nature | Receiving, storing, transmitting, backing up and deleting. ChirpCloud does not analyse payload content for its own purposes |
| Data subjects | Whoever the Customer's devices relate to, as the Customer decides (for example employees, tenants, vehicle drivers, asset users) |
| Categories | Whatever the Customer's devices send: for example location, occupancy, environmental or usage readings; device identifiers; gateway locations |
| Special category data | Not intended. The Customer must not process special category or criminal-offence data without ChirpCloud's prior written agreement |
3. ChirpCloud's obligations
ChirpCloud will:
3.1 process Customer Personal Data only on the Customer's documented instructions. These terms, and the Customer's use and configuration of the service, including any integration the Customer configures to send data to a destination of its choice, are those instructions. ChirpCloud will tell the Customer if it believes an instruction breaks data protection law;
3.2 ensure that staff with access are bound by confidentiality;
3.3 apply the security measures in Annex 2;
3.4 use subprocessors only under section 5;
3.5 help the Customer, taking into account the nature of the processing, to respond to data subjects' requests. Customers can view, change and delete their own devices and data through the ChirpStack interface and API while their workspace is active;
3.6 help the Customer with security, breach notification, impact assessments and prior consultation, as far as reasonably possible given the information available to ChirpCloud, at the Customer's cost beyond reasonable effort;
3.7 notify the Customer without undue delay after becoming aware of a personal data breach affecting Customer Personal Data, at the Customer's account email address, from privacy@chirpcloud.co.uk, and in any case within 48 hours of becoming aware of it. The notice includes what ChirpCloud knows at that point, and ChirpCloud follows up as it learns more. A leaked gateway certificate is a personal data breach only where Customer Personal Data is affected.
3.8 at the end of the service, delete Customer Personal Data under section 7;
3.9 make available information needed to demonstrate compliance with this agreement, and allow audits, normally by written questionnaire at most once a year. An on-site audit is allowed only where a supervisory authority requires it or, after a personal data breach, where the questionnaire is not enough. It needs at least 30 days' notice, takes place during business hours under confidentiality, and is at the Customer's cost.
4. Customer's obligations
4.1 The Customer is responsible for having a lawful basis for the processing and for giving the required information to data subjects.
4.2 Shared gateway coverage. By default the Customer's gateways relay other customers' devices, and other customers then see those gateways' identifiers and locations. ChirpCloud decides this sharing and does it as controller under its privacy notice, not on the Customer's instructions; it is outside the scope of this agreement. The Customer can switch it off for all its gateways in the portal ("Gateways are private (uplink)" and "(downlink)"). The Customer must not set a gateway location that identifies an individual's home without a lawful basis; otherwise it must leave the location unset and disable gateway GPS, or make its gateways private.
4.3 The Customer is responsible for keeping its keys, credentials and gateway certificates secret (see the terms, section 3.4).
4.4 Workspace members. The Customer decides whom it invites to its workspace, and those members act on the Customer's instructions. The Customer is responsible for their access, including removing it when needed and revoking credentials they created (see the terms, section 3.6). Members' account and invitation data is not Customer Personal Data: ChirpCloud processes it as controller under its privacy notice (section 1.3).
5. Subprocessors
5.1 The Customer gives general authorisation for the subprocessors in Annex 3.
5.2 ChirpCloud will give the Customer at least 30 days' notice by email of a new or replacement subprocessor. The Customer may object on reasonable data protection grounds. If the parties cannot resolve the objection, the Customer may cancel and the subscription ends at the end of the paid period.
5.3 Where a subprocessor must be replaced urgently to keep the service running or secure (for example a provider failure or a security incident), ChirpCloud may replace it immediately and will notify the Customer as soon as possible. The Customer then has the same right to object as under section 5.2.
5.4 ChirpCloud will impose data protection terms on each subprocessor that are no less protective than this agreement, and remains liable for its subprocessors.
6. International transfers
6.1 Customer Personal Data is stored and processed in the EU (Germany and Finland), including backups, except where the Customer configures an integration or other destination; the Customer is responsible for that transfer. Data in an EU or EEA country is covered by UK adequacy regulations.
6.2 Where a subprocessor in Annex 3 processes Customer Personal Data outside the UK, the EU or the EEA, the transfer is covered by the safeguards in that subprocessor's data processing terms: the UK Addendum to the EU standard contractual clauses or the UK Extension to the EU-US Data Privacy Framework. Any new transfer will use one of these or the UK International Data Transfer Agreement.
7. Return and deletion
7.1 During the subscription the Customer can export its configuration from the workspace settings page in the portal, and read and delete its data through the ChirpStack interface and API.
7.2 When the service ends, retention and deletion follow the terms, section 8. Deletion is irreversible.
7.3 Backups are overwritten within about 30 days. If a backup is restored, deletions made since are re-applied before the service reopens.
8. Liability
8.1 Each party's liability under or in connection with this agreement is subject to the limits in the terms, section 12.
Annex 2: Security measures
- Each customer is a separate tenant; tenant isolation is checked on every API method and covered by automated tests.
- MQTT credentials are scoped to one application's topics. Passwords are stored only as salted hashes and shown to the Customer once.
- TLS protects the portal, the API, MQTT and Basic Station. Semtech UDP is not encrypted, but LoRaWAN payloads are encrypted with device keys.
- The administrative interfaces are not exposed publicly. Secrets are kept out of source code in a managed secrets store.
- Logs exclude secrets, tokens and payloads.
- Continuous database backups go to a separate provider, and restores have been rehearsed.
- Two-factor authentication or a passkey is required to start a paid plan, optional otherwise; rate limiting on sign-in.
Annex 3: Subprocessors
| Subprocessor | Purpose | Customer Personal Data it receives | Location |
|---|---|---|---|
| Hetzner Online GmbH | Infrastructure: servers, storage, load balancer | All (hosting) | Germany and Finland |
| Wasabi Technologies LLC | Database backup storage | All database-held data (configuration, keys, queued payloads) | Germany |