Bubbl

Data Processing Agreement

Version 1 · effective 30 Sep 2026 · All versions

Effective date: [EFFECTIVE DATE]

Draft status: this is a starting draft for review by a UK solicitor. Items in square brackets are placeholders or points to confirm. It is not legal advice.

This Data Processing Agreement ("DPA") forms part of the Terms of Service (the "Terms") between [COMPANY LEGAL NAME], a company registered in England and Wales under company number [COMPANY NUMBER], whose registered office is at [REGISTERED ADDRESS] ("Bubbl" or the "Processor"), and the customer that has accepted the Terms (the "Customer" or the "Controller").

It sets out the terms required by Article 28 of the UK GDPR for Bubbl's processing of personal data on the Customer's behalf.

1. Definitions

1.1 "Data Protection Law" means the UK GDPR, the Data Protection Act 2018, the Privacy and Electronic Communications (EC Directive) Regulations 2003 ("PECR") and any other law relating to personal data that applies in the United Kingdom, each as amended or replaced.

1.2 "Customer Personal Data" means personal data about End Users that Bubbl processes on the Customer's behalf in providing the Service, as described in Annex 1.

1.3 "Personal Data Breach" means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Customer Personal Data.

1.4 "Sub-processor" means a third party engaged by Bubbl to process Customer Personal Data.

1.5 "Restricted Transfer" means a transfer of Customer Personal Data to a country outside the UK that is not covered by UK adequacy regulations.

1.6 "controller", "processor", "data subject", "personal data" and "processing" have the meanings given in the UK GDPR. Other capitalised terms have the meanings given in the Terms.

2. Scope and roles

2.1 This DPA applies to Customer Personal Data: personal data about End Users of Customer Apps that is collected through the SDK or the device API, or that the Customer otherwise submits to the Service about End Users.

2.2 For Customer Personal Data, the Customer is the controller and Bubbl is the processor.

2.3 This DPA does not apply to personal data for which Bubbl is the controller, which is described in Bubbl's Privacy Policy, namely:

  • dashboard users (Authorised Users), billing contacts and support conversations; and
  • users of Bubbl's Showcase app. [SOLICITOR REVIEW: Showcase devices are paired into, and visible in, a Customer's Workspace, and are subject to that Workspace's retention settings. See notes.md.]

2.4 Bubbl may process information about the use and performance of the Service (for example request counts, error rates and the number of Billable Devices) to operate, secure and support the Service and to calculate Fees. To the extent such information is personal data, Bubbl processes it as part of providing the Service under the Customer's instructions in clause 3. [SOLICITOR REVIEW: whether Bubbl should instead be described as an independent controller for billing, security and service-improvement purposes.]

3. Processing on documented instructions

3.1 Bubbl will process Customer Personal Data only on the Customer's documented instructions, unless required to do otherwise by UK law, in which case Bubbl will inform the Customer of that legal requirement before processing unless the law prohibits this on important grounds of public interest.

3.2 The Customer's instructions are: the Terms and this DPA; the Customer's configuration and use of the Service, including its campaigns, geofences, segments, delivery rules, retention settings and privacy settings in the dashboard; and any other reasonable written instructions agreed by the parties.

3.3 Bubbl will tell the Customer immediately if, in its opinion, an instruction infringes Data Protection Law. Bubbl is not obliged to carry out legal checks of the Customer's instructions.

4. Customer obligations

4.1 The Customer is responsible for the lawfulness of the processing of Customer Personal Data and for its instructions to Bubbl. In particular, the Customer will:

  • provide End Users with a privacy notice that meets Articles 13 and 14 of the UK GDPR and describes the processing through Bubbl, including the collection of location data (and background location where the Customer App requests "always" permission), device information, push tokens, notification and survey interactions, and any segments and custom events;
  • identify and document a lawful basis for the processing;
  • obtain any consent required by Data Protection Law, including consent under PECR regulation 6 for storing and accessing information on End Users' devices where the SDK's functions are not strictly necessary for a service the End User has requested, and any consent required for marketing communications;
  • request location and notification permission in each Customer App in accordance with the operating system's rules and the app store's policies, with a clear explanation, and, for background location on Android, show the prominent disclosure Google Play requires;
  • where it relies on consent, start the SDK with its consent option (requireConsent) and call setConsent(true) only after the End User has agreed, and allow End Users to withdraw consent (for example through optOut);
  • provide End Users with a way to request erasure of their data, which may use the SDK's deleteMyData function;
  • carry out a data protection impact assessment where required (Bubbl considers that systematic processing of location data will often require one);
  • not send special category data, criminal offence data or data about children under [13] to the Service (including in segments, custom event names or properties, survey questions or answers, or notification content), and not configure geofences or segments intended to reveal such data, unless agreed in writing; and
  • set retention periods in the dashboard (Data and privacy settings) appropriate to its purposes.

4.2 The Customer is responsible for its own accounts with Google (Firebase) and Apple (Apple Push Notification service) and for the credentials it uploads to the Service for them.

5. Confidentiality

5.1 Bubbl will ensure that anyone it authorises to process Customer Personal Data (including employees and contractors) is subject to a duty of confidentiality, whether contractual or statutory.

5.2 Bubbl will limit access to Customer Personal Data to personnel who need it to provide, support or secure the Service. Bubbl administrators may access a Customer's Workspace to provide support or investigate a problem; such access is recorded in an audit log.

6. Security

6.1 Bubbl will implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, as required by Article 32 of the UK GDPR, including the measures in Annex 2.

6.2 Bubbl may update those measures from time to time, provided that the overall level of security is not reduced.

7. Sub-processors

7.1 The Customer gives Bubbl general written authorisation to engage Sub-processors. The Sub-processors in use at the effective date are listed at [SUB-PROCESSOR LIST URL].

7.2 Bubbl will give the Customer at least 30 days' notice before adding or replacing a Sub-processor, by updating the Sub-processor list and emailing the Workspace owner [and any privacy contact set in the dashboard].

7.3 The Customer may object to a new Sub-processor on reasonable data protection grounds by writing to Bubbl within that 30-day period. The parties will discuss the objection in good faith. If Bubbl cannot reasonably accommodate the objection, the Customer may terminate the affected part of the Service by written notice before the change takes effect, and Bubbl will refund any Fees paid in advance for the period after termination.

7.4 Bubbl will impose data protection obligations on each Sub-processor, by written contract, that provide at least the same level of protection as this DPA, and remains liable to the Customer for each Sub-processor's performance of those obligations.

7.5 Where urgent replacement of a Sub-processor is needed for security or continuity of the Service, Bubbl may make the change on shorter notice, and will notify the Customer as soon as possible; the objection right in clause 7.3 still applies.

8. International transfers

8.1 Bubbl hosts the Service with Amazon Web Services in the UK (London, eu-west-2), with disaster-recovery backups in Ireland (eu-west-1). Transfers to the European Economic Area are covered by UK adequacy regulations.

8.2 Bubbl will not make a Restricted Transfer of Customer Personal Data unless it is covered by:

  • UK adequacy regulations, including the UK Extension to the EU-US Data Privacy Framework (the "UK-US data bridge") where the recipient is certified under it; or
  • the International Data Transfer Agreement ("IDTA") or the International Data Transfer Addendum to the EU Standard Contractual Clauses (the "Addendum") issued by the ICO, together with a transfer risk assessment.

8.3 The mechanism for each Sub-processor is shown in the Sub-processor list. [CONFIRM each one.]

8.4 Push notifications are delivered through Google's Firebase Cloud Messaging and Apple's Push Notification service, which operate globally. The Customer acknowledges that notification content and push tokens are transmitted to those services for delivery.

9. Assisting with data subject rights

9.1 Taking into account the nature of the processing, Bubbl will assist the Customer by appropriate technical and organisational measures in responding to requests from End Users to exercise their rights. The Service provides the following:

  • Erasure: the SDK's deleteMyData() function permanently deletes the End User's device record from the Service, together with its location events, survey answers, segment memberships, diagnostic logs and any events still queued for processing, and revokes the device's credentials. This deletion is immediate and is not a soft delete. Aggregate delivery counts are kept, but refer only to a random identifier that no longer leads to the device. The SDK also clears its local data on the device.
  • Withdrawal of consent and objection: the SDK's optOut() (or setConsent(false)) stops the SDK collecting and sending data and tells the Service that consent has been withdrawn. setLocationEnabled(false) stops location processing while leaving other features running. Once the Service receives a withdrawal, it removes the device's push token, sends it no further notifications, and ignores location and event data from it until consent is given again. Withdrawing consent does not itself delete data already collected; deleteMyData() does.
  • Access and portability: the Customer can find a device in the dashboard (Active users) by its install identifier and export Workspace data, including device data, from the dashboard.
  • Retention: the Customer can set how long location events are kept and when inactive devices are deleted. Data past its period is permanently deleted overnight.

9.2 If an End User's request cannot be met through these functions (for example, where the End User no longer has the Customer App installed), the Customer may ask Bubbl for help through [SUPPORT EMAIL], and Bubbl will provide reasonable assistance. [CONFIRM: the dashboard does not currently offer deletion of an individual device; this is handled manually.]

9.3 If Bubbl receives a request directly from an End User, it will not respond other than to direct the End User to the Customer, where Bubbl can identify the Customer, and will promptly forward the request to the Customer.

10. Other assistance

Bubbl will provide reasonable assistance to the Customer, taking into account the nature of the processing and the information available to Bubbl, with the Customer's obligations under Articles 32 to 36 of the UK GDPR (security, breach notification, data protection impact assessments and prior consultation with the ICO). Bubbl may charge reasonable fees for assistance beyond providing information about the Service that is generally available. [CONFIRM.]

11. Personal Data Breaches

11.1 Bubbl will notify the Customer without undue delay, and in any event within [48] hours, after becoming aware of a Personal Data Breach affecting Customer Personal Data. [CONFIRM notification window.]

11.2 The notification will be sent to the Workspace owner [and the privacy contact set in the dashboard] and will include, to the extent known: the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, and the measures taken or proposed to address it. Where information is not available at once, Bubbl will provide it in phases without undue delay.

11.3 Bubbl will take reasonable steps to contain and investigate the breach and to mitigate its effects, and will co-operate with the Customer in meeting its obligations to notify the ICO and data subjects.

11.4 Notification of a breach is not an acknowledgement of fault or liability.

12. Deletion or return at the end of the Service

12.1 Before the Service ends, the Customer can export its Workspace data from the dashboard.

12.2 When the Customer deletes its Workspace, or the Terms otherwise end:

  • the Workspace enters a 14-day grace period, during which SDK calls are refused, campaigns are paused and the deletion can be cancelled;
  • at the end of the grace period the Workspace is closed; and
  • 30 days after closure, Bubbl permanently erases the Workspace and all Customer Personal Data in it from its live systems, including uploaded media and exports.

12.3 Copies in backups are overwritten in the ordinary backup cycle within 35 days and are not restored except for disaster recovery.

12.4 Bubbl may keep Customer Personal Data after this period only where UK law requires it, in which case this DPA continues to apply to it.

12.5 On request, Bubbl will confirm in writing that deletion has taken place.

13. Audit and information

13.1 Bubbl will make available to the Customer the information reasonably necessary to demonstrate compliance with Article 28 of the UK GDPR, including answers to reasonable security questionnaires [and any current third-party certifications or audit reports it holds]. [CONFIRM whether Bubbl holds, or relies on AWS's, certifications such as ISO 27001, SOC 2 or Cyber Essentials.]

13.2 If that information is not sufficient to demonstrate compliance, or where required by the ICO, the Customer (or an independent auditor it appoints who is bound by confidentiality and is not a competitor of Bubbl) may carry out an audit, including an inspection, subject to the following:

  • at least 30 days' written notice, except after a Personal Data Breach or where the ICO requires it;
  • no more than once in any 12-month period, except after a Personal Data Breach or where the ICO requires it;
  • during normal business hours, without unreasonable disruption, and limited to Bubbl's processing of Customer Personal Data;
  • no access to other customers' data or to Bubbl's Sub-processors' facilities (for which Bubbl will provide the Sub-processors' own audit reports where available); and
  • at the Customer's cost, unless the audit reveals a material breach of this DPA by Bubbl.

14. Liability

Each party's liability under or in connection with this DPA is subject to the limitations and exclusions of liability in the Terms. [SOLICITOR REVIEW: whether a separate cap applies to data protection claims.]

15. Duration, precedence and changes

15.1 This DPA applies for as long as Bubbl processes Customer Personal Data.

15.2 If this DPA conflicts with the Terms, this DPA prevails in relation to the processing of Customer Personal Data.

15.3 Bubbl may update this DPA to reflect changes in Data Protection Law, guidance from the ICO, or changes to the Service that do not reduce the protection given to Customer Personal Data, on at least [30] days' notice.

15.4 This DPA is governed by the law of England and Wales, and the courts of England and Wales have exclusive jurisdiction.

Annex 1: Details of processing

Subject matter and duration

Providing the Bubbl location-based engagement Service to the Customer, for the term of the Terms and until deletion under clause 12.

Nature and purpose of processing

Collection, storage, organisation, retrieval, use, transmission and deletion of Customer Personal Data in order to:

  • register installations of Customer Apps and authenticate them;
  • supply each device with the geofences near it that it is targeted by;
  • receive geofence entry and exit events and decide, on the server, whether to show a notification, applying the Customer's campaign, targeting, frequency, cooldown and quiet-hours rules;
  • send scheduled and triggered push notifications through Firebase Cloud Messaging (Android) and Apple Push Notification service (iOS);
  • record notification and survey interactions and custom events, and produce reports, footfall and heatmap views for the Customer;
  • apply the Customer's retention settings and End Users' erasure requests;
  • provide diagnostics and support; and
  • count devices for billing.

Categories of data subjects

End Users of the Customer's Customer Apps in which the SDK is installed. [Where the Customer uses the Service for its own staff or test devices, those individuals too.]

Categories of personal data

Category Data
Identifiers Install identifier generated by the SDK; Bubbl device identifier; per-install credential (key id, and a secret stored encrypted); push token (FCM registration token or APNs device token) and its type and APNs environment
Device and app information Platform, operating system version, device model, manufacturer, app identifier, app version, SDK version, locale or language, country, time zone, integration mode, first and last seen times
Permission and consent state Notification permission; location permission (always, when in use, denied or not determined); whether precise location is allowed; the time consent was given (where the Customer App uses the SDK's consent option)
Location data For each geofence entry or exit: the geofence, the event, the time, and the device's latitude, longitude and reported accuracy. Location update events (latitude, longitude, accuracy) where sent. The device's approximate position when it requests nearby geofences (used to answer the request)
Interaction data Notification received, displayed, opened, dismissed, call-to-action clicked, survey started, media viewed or completed, with the related campaign, notification and geofence; app opened events
Survey responses Answers to the Customer's survey questions, including free text of up to 2,000 characters
Segments and custom events Segment tags the Customer App assigns to the device; custom event names and up to 50 properties per event, as defined by the Customer
Technical data IP address, used transiently for rate limiting and security and in infrastructure logs (infrastructure logs are kept for 30 days); request metadata processed by application monitoring (see the Sub-processor list)

The Service does not require, and the SDK does not collect, End Users' names, email addresses, phone numbers or advertising identifiers. However, the Customer controls segment names, custom events and survey questions and could use them to send other data. See clause 4.1.

Special category data

None intended. The Customer must not send special category data (clause 4.1). Location data is not special category data, but may reveal it (for example visits to a place of worship or a clinic), and the Customer must take this into account in its geofence and campaign design and its impact assessment.

Retention

As set by the Customer in the dashboard (Data and privacy):

  • location events: kept for 30, 90 or 180 days, 13 months (the default) or 2 years; when deleted, location coordinates are also removed from other events of the same age;
  • inactive devices: deleted after 3, 6, 12 (the default) or 24 months without activity;
  • raw device payloads received by the Service are deleted 30 days after they are processed;
  • reports keep aggregated totals, which contain no personal data, after the underlying events are deleted;
  • an End User's erasure request (deleteMyData) deletes their device data at once; and
  • everything is deleted at the end of the Service under clause 12.

Annex 2: Technical and organisational security measures

Items marked [CONFIRM] describe production infrastructure that is not yet verifiable from the code.

Hosting and infrastructure

  • Hosted on Amazon Web Services in the UK (London, eu-west-2); disaster-recovery backups in Ireland (eu-west-1). [CONFIRM]
  • Database (PostgreSQL), cache and queues (Redis) and file storage (Amazon S3) are not publicly accessible. [CONFIRM network configuration]
  • Encryption at rest for the database, backups and storage. [CONFIRM]
  • The storage bucket blocks public access control lists; media is served through a bucket policy or content delivery network.
  • Regular backups, with restore testing. [CONFIRM frequency and testing]

Encryption and credentials

  • All traffic uses HTTPS (TLS). The SDK refuses plain HTTP except to local development hosts.
  • Application-level encryption of sensitive values: device credential secrets, the Customer's Firebase service-account credentials and APNs keys, and two-factor authentication secrets and recovery codes.
  • Dashboard sessions are encrypted and their cookies are sent only over HTTPS.
  • Passwords are stored as one-way hashes.

Device authentication

  • Each app installation receives its own credential. Every request is signed with HMAC-SHA256 over the method, path, query, timestamp and body, and requests more than 300 seconds out of time are rejected.
  • On the device, the credential is kept in the Android Keystore or iOS Keychain (not included in backups, and on iOS only available after first unlock).
  • Credentials can be revoked, and are revoked on erasure.
  • Rate limits apply per installation and per IP address, with stricter limits on failed authentication and pairing attempts.

Access control

  • Each Customer's data is logically separated, with every query scoped to the Customer's Workspace.
  • Role-based permissions within each Workspace.
  • Customers can require two-factor authentication for their Workspace, allow passkeys, restrict invitations to approved email domains and sign out idle users.
  • Two-factor authentication is required for Bubbl administrators.
  • Administrator actions, including access to a Customer's Workspace, are recorded in an audit log with the administrator's identity, IP address and user agent.
  • Sign-in alerts by email when an account is signed in.

Data minimisation and deletion

  • The SDK does not collect names, contact details or advertising identifiers.
  • The SDK's consent option prevents any network, location or notification activity until consent is given.
  • Configurable retention with automatic, permanent deletion.
  • Immediate, permanent erasure of a device on the End User's request.
  • Workspace exports expire after 7 days.

Monitoring and resilience

  • Application monitoring and error tracking (Laravel Nightwatch), with request payloads not captured, and authorisation headers, cookies and password fields redacted. Most device API requests are not recorded (1% sample).
  • Centralised application logs. [CONFIRM retention]
  • Scheduled tasks run on one server at a time and failures are retried and logged.

Organisation

  • Staff and contractors with access to Customer Personal Data are bound by confidentiality. [CONFIRM]
  • Access is limited to those who need it, and removed when no longer needed. [CONFIRM]
  • Security incident response procedure. [CONFIRM a written procedure exists]
  • [CONFIRM any certifications, for example Cyber Essentials.]

Annex 3: Sub-processors

The current list of Sub-processors, with the data they process, their location and the transfer safeguard relied on, is published at [SUB-PROCESSOR LIST URL].