Effective 2026-07-24
Data Processing Agreement
This Data Processing Agreement (this “DPA”) is between Brogan LLC (“Cluestick”, “we”, “us”) and the company or other legal entity that holds a Cluestick account (“Customer”, “you”). It is incorporated into the Terms of Service by Section 17 of those Terms and forms part of them, so it binds every Customer without a signature.
Sections are numbered so they can be cited. Where a section is referred to elsewhere in this DPA, the number is the reference. Terms defined in the Terms of Service — in particular Customer Data, End User, SDK and Service — carry the same meaning here. “Personal data”, “controller”, “processor”, “sub-processor”, “data subject”, “processing” and “personal data breach” carry the meanings given to them in the GDPR, and their equivalents under the UK GDPR, the Swiss Federal Act on Data Protection, and other applicable data protection law.
1. Scope and roles
This DPA applies where Brogan LLC processes personal data contained in Customer Data on the Customer’s behalf in providing the Service. It does not cover the account, billing and website data we hold in our own right, for which we are the controller and which Part A of the Privacy Policy describes.
The Customer is the controller of the personal data in Customer Data, and Brogan LLC is the processor of it. Where the Customer instead acts as a processor for its own controller, this DPA applies to the Customer in that capacity, Brogan LLC is a sub-processor, and the Customer warrants that it has its controller’s authority to give the instructions in Section 2 and to enter into this DPA.
Where this DPA and the Terms conflict on the treatment of personal data, this DPA controls, as Section 17 of the Terms provides. A Customer that requires a countersigned copy of this DPA may request one at logan@brogan.io, and we will sign it and send it back.
2. Processing on documented instructions
We process personal data in Customer Data only on the Customer’s documented instructions, including as to an international transfer, unless a law we are subject to requires otherwise, in which case we tell the Customer of that requirement before processing unless the law forbids us to on important grounds of public interest.
The documented instructions are the Terms, this DPA, and the Customer’s use of the Service: how it configures its applications and integrations, what its members do in the dashboard, and the calls its applications make through the SDK and our APIs. Any other instruction must be agreed in writing.
We do not use Customer Data for our own purposes, we do not disclose it to anyone outside Annex III except as this DPA and the Terms permit, and we do not use it to train machine-learning models.
If we consider that an instruction infringes the GDPR, the UK GDPR or other applicable data protection law, we tell the Customer without undue delay, and we may suspend the processing that instruction calls for until it is withdrawn, amended or confirmed.
3. Confidentiality
Everyone with access to personal data in Customer Data is bound by a written obligation of confidentiality, whether as an employee, a contractor or a professional adviser, and that obligation survives the end of their engagement. Access is limited to those who need it in order to operate, secure and support the Service, and it is withdrawn when it is no longer needed. Section 9 of the Terms applies to Customer Data as the Customer’s Confidential Information.
4. Security
We implement and maintain the technical and organisational measures described in Annex II, taking into account the state of the art, the cost of implementation, the nature, scope, context and purposes of the processing, and the risk to data subjects.
Those measures may change as the Service develops. We will not materially reduce the overall level of protection they provide during the term of the Terms.
5. Sub-processors
The Customer gives a general authorisation for us to engage sub-processors, and authorises the sub-processors listed in Annex III.
Each sub-processor is engaged under a written contract that imposes data protection obligations no less protective than those in this DPA, to the extent they apply to the service it provides. We remain liable to the Customer for the performance of each sub-processor’s obligations as if they were our own.
We give at least thirty (30) days notice, by email to the address registered on the account, before we add or replace a sub-processor. Where a sub-processor has to be replaced sooner in order to protect the security or the continuity of the Service, we give notice as soon as we reasonably can.
The Customer may object to a proposed sub-processor within the notice period on reasonable data-protection grounds, and we will work with the Customer in good faith to resolve the objection. If it cannot be resolved, the Customer may terminate the affected part of the Service, or the Terms, on written notice and without further liability for the terminated part, and Section 8 then governs what happens to Customer Data.
6. Data-subject requests
Taking into account the nature of the processing, we assist the Customer by appropriate technical and organisational measures, so far as is possible, in meeting its obligation to respond to a data subject exercising a right under Chapter III of the GDPR or an equivalent right under other applicable law.
Most of that assistance is self-serve. Three controls sit in the dashboard, each available to an owner or administrator of the workspace:
- export one End User — the context panel beside a conversation downloads a JSON file describing that person: their identifier and whether it is anonymous, their device and application context, their custom traits, their service identifiers, their conversations, every message in both directions with the device snapshot taken at each inbound one, attachment metadata, their registered devices, and their feature-request votes. It leaves out the internal notes staff have written on their conversations, whether that person is currently blocked from sending, push tokens, and attachment file content, which stays retrievable in the conversation itself;
- erase one End User — the same panel erases that person after a confirmation step. Their attachment files are removed from object storage first, and only then is the End User record deleted, which cascades to their conversations, the internal notes on those conversations, their messages, attachments, devices and votes. If any file cannot be removed, nothing is erased and the attempt reports a failure so that it can be retried. Erasure cannot be undone; and
- export the whole workspace — workspace settings downloads the organisation as JSON: team, applications, conversations, knowledge base, feature board and audit log. Neither export includes signing secrets, API key hashes, push tokens or attachment file content.
Anything those controls do not cover is a request to us at logan@brogan.io, and we act on it in time for the Customer to meet its own deadline. There is no self-serve account closure control today, so closing an account and having everything in it deleted is a request at logan@brogan.io rather than a button in the dashboard.
If a data subject contacts us directly about personal data we process for a Customer, we forward the request to that Customer and tell the person that we have done so, rather than responding to it ourselves. We cannot verify who they are, and the instruction to act is the Customer’s to give.
We also assist the Customer, so far as is possible and taking into account the information available to us, with its obligations under Articles 32 to 36 of the GDPR: security of processing, notification of a personal data breach, data protection impact assessments, and prior consultation with a supervisory authority.
7. Personal data breach
We notify the Customer of a personal data breach affecting personal data we process for it without undue delay, and in any event within seventy-two (72) hours of becoming aware of it, by email to the address registered on the account.
The notification describes the nature of the breach, the categories and approximate number of data subjects and of records concerned so far as they are known to us, the likely consequences, and the measures taken or proposed in response. Where we do not hold all of that at the time, we send what we hold and supplement it as it becomes available, without further undue delay.
We take reasonable steps to contain and remediate the breach, and we assist the Customer with any notification it must make to a supervisory authority or to affected data subjects. Notifying the Customer is not an admission of fault or of liability by either party.
8. Return and deletion of Customer Data
After termination the Customer may export Customer Data through the dashboard and the API for thirty (30) days, as Section 13 of the Terms provides. If the account is no longer accessible to the Customer, we produce the export on request at logan@brogan.io during that window.
After that window closes we delete Customer Data from our production systems, including the attachment objects held in object storage. The Customer may ask us in writing during the window to delete it sooner, and we will delete it sooner if asked.
Backups age out on our providers’ ordinary schedules, so a copy can survive in a backup for a period after the data has gone from the live systems. We do not restore a backup in order to retrieve deleted Customer Data, and anything still held in a backup remains subject to this DPA until it ages out.
We keep personal data beyond that point only where the law requires us to, and then only for as long as the law requires and only for that purpose.
9. Audit
We make available to the Customer the information necessary to demonstrate compliance with Article 28 of the GDPR and with this DPA. That information is this DPA, the measures in Annex II, the sub-processor list in Annex III, and our answers to a reasonable security questionnaire, which we complete once in any twelve (12) month period at no charge.
The Customer may carry out an on-site audit of the facilities used to provide the Service no more than once in any twelve (12) month period, at the Customer’s expense, on at least thirty (30) days written notice, during business hours, in a way that does not disrupt the Service, and where a supervisory authority requires the audit as a condition of the Customer’s own compliance. An auditor must not be a competitor of ours and must be bound by confidentiality. Findings are the Confidential Information of both parties.
Nothing in this section limits the audit and inspection rights that the Clauses give the Customer where the Clauses apply.
10. International transfers
Cluestick is operated from the United States, and all processing takes place on infrastructure hosted in the United States. We do not offer regional hosting.
Where the Customer transfers personal data subject to the GDPR to us, the standard contractual clauses approved by Commission Implementing Decision (EU) 2021/914 of 4 June 2021 (the “Clauses”), Module Two (controller to processor), are incorporated into this DPA by reference and apply to that transfer, with the Customer as data exporter and Brogan LLC as data importer.
The Clauses apply as follows: the optional docking clause in Clause 7 applies; the general written authorisation in Clause 9(a), Option 2, applies, with the notice period in Section 5 of this DPA; the optional independent dispute resolution body in Clause 11(a) does not apply; the governing law under Clause 17 is the law of the Member State in which the data exporter is established, or, where the data exporter is not established in a Member State, the law of Ireland; the forum under Clause 18(b) is the courts of that same Member State; Annex I of this DPA is Annex I to the Clauses; Annex II of this DPA is Annex II to the Clauses; and Annex III of this DPA is the list of sub-processors for the purposes of Clause 9.
Where the Customer transfers personal data subject to the UK GDPR, the International Data Transfer Addendum to the EU standard contractual clauses issued by the Information Commissioner applies to that transfer, and it is completed as follows: the parties in Table 1 are the parties described in Annex I; the approved EU clauses in Table 2 are the Clauses as incorporated above, for Module Two; the appendix information in Table 3 is Annexes I, II and III of this DPA; and in Table 4 neither party may end the Addendum when the Approved Addendum changes.
Where the Customer transfers personal data subject to the Swiss Federal Act on Data Protection, the Clauses apply with these amendments: the competent supervisory authority is the Federal Data Protection and Information Commissioner; references to the GDPR are to the Swiss Federal Act on Data Protection so far as the transfer is governed by it; and references to a Member State are read so that a data subject in Switzerland may enforce the third-party beneficiary rights in the place of their habitual residence.
If a transfer mechanism in this section is invalidated or replaced, the parties will apply the replacement approved for the transfer, and this section is then read as referring to it.
11. California Consumer Privacy Act
For the personal information contained in Customer Data, the Customer is the business and Brogan LLC is a service provider under the California Consumer Privacy Act.
We process that personal information solely to provide the Service under the Terms and this DPA, which is the business purpose for which it is disclosed to us. We do not sell it, and we do not share it for cross-context behavioural advertising. We do not retain, use or disclose it for any purpose other than performing the Service, and we do not combine it with personal information we receive from anyone else, except where the Act permits.
We understand these restrictions and will comply with them, and we will tell the Customer if we determine that we can no longer meet them.
12. Annex I — Details of the processing
Data exporter. The Customer, acting as controller, or as processor for its own controller as Section 1 describes. Its identity, its role and its activities relevant to the transfer are those recorded on its Cluestick account, and its contact point is the email address registered there, to which notices under this DPA are sent.
Data importer. Brogan LLC, acting as processor, operating Cluestick, a support platform for iOS applications. Its contact point for this DPA, for data protection questions and for supervisory authority enquiries is logan@brogan.io. We publish no postal address, and email is the contact point for every purpose in this DPA, including the party details the Clauses call for.
Representative. Brogan LLC has not appointed a representative under Article 27 of the GDPR or of the UK GDPR. Enquiries from individuals and from supervisory authorities in the European Union or the United Kingdom should be sent to logan@brogan.io.
Data subjects. The End Users of the Customer’s applications: the people who use those applications and contact the Customer’s support through the Service, whether identified through the Customer’s own backend or holding an anonymous identifier that the Service mints for an install that has not been identified. The Customer’s own personnel are data subjects to the extent they appear in Customer Data, as the author of an outbound message or of an internal note and as the acting member recorded in the workspace audit log. The account records of those personnel are held by Brogan LLC as controller and are outside this DPA.
Categories of personal data.
- end-user identifiers, including the opaque anonymous identifier minted for an install that has not been identified;
- custom traits — up to fifty key and value pairs the Customer chooses to attach to a person. There is no dedicated name or email field in the Service, so a display name or an email address reaches us only if the Customer sends it as a trait or uses it as the identifier;
- service identifiers, such as a RevenueCat customer id, that the Customer supplies so that its own integrations look up the right person;
- device and application context — application version, operating system name and version, device model and locale, held both as that person’s latest state and as a snapshot taken at each inbound message;
- message content in both directions, together with the internal notes the Customer’s staff write on a conversation, which are never shown to the End User;
- attachments — the files an End User or an agent uploads, with their filename, media type and size;
- push notification tokens, the push environment each belongs to, and the SDK version, held so that a reply can be delivered;
- feature-request votes — the items on the Customer’s public feature board that a person voted for; and
- End User IP addresses — the network address a device presents when it calls our public SDK endpoints. It is processed only to rate-limit those endpoints, held for that purpose as a short-lived counter key in the managed Redis described in Annex II for the sixty (60) second rate-limiting window, and it appears in our hosting provider’s request logs. It is not written to the application database and is not attached to a person, a conversation or a message.
Special categories of personal data. No special category data is processed under this DPA. Section 5 of the Terms prohibits the Customer from routing it through the Service, and the Service is not designed or contractually equipped to hold it. No processing is carried out on the basis of Article 9(2) of the GDPR, and none concerns criminal convictions or offences.
Nature and purpose of the processing. Hosting, storing, transmitting and displaying Customer Data so that the Customer can receive, read and answer support messages from its End Users, deliver push notifications about replies, operate a help centre and a public feature board, and export or erase a person’s data on request.
Frequency of the transfer. Continuous, for as long as the Customer’s applications and dashboard are in use.
Duration of the processing. The term of the Terms, continuing for thirty (30) days after termination, which is the export window in Section 8, after which Customer Data is deleted from production systems and ages out of backups as that section describes.
Transfers to sub-processors. The sub-processors in Annex III receive the categories above, for the purposes stated there, and for the same duration.
Competent supervisory authority. For a transfer under the Clauses, the supervisory authority of the Member State in which the data exporter is established, or, where the data exporter is not established in the Union, the supervisory authority of the Member State in which the data subjects whose personal data is transferred are located.
13. Annex II — Technical and organisational measures
Encryption in transit. Traffic to and from the Service, the dashboard, the APIs and the SDK travels over TLS.
Encryption at rest. Our managed database and object storage providers encrypt the data they hold at rest.
Integration credentials. Integration credentials — the RevenueCat, PostHog, Mixpanel, Sentry and APNs keys a Customer connects — are encrypted with AES-256-GCM before they are stored, with a random initialisation vector and an authentication tag for each value, and are decrypted only for the moment they are used. That includes a Customer’s APNs .p8 signing key, encrypted the same way as the enrichment-integration keys above it. The per-application secret used to sign End User identity tokens is held the same way. The encryption key lives in the deployment environment rather than in the database.
API keys. An application’s API key is stored only as a SHA-256 hash, alongside a short indexed prefix used to find it. The key itself is shown once, when it is created, and is scoped to the single application it was minted for. A key can be revoked at any time, revocation is recorded rather than the row deleted, and hash comparison is timing-safe. Minting or rotating a key requires an owner or an administrator whose email address has been verified.
Access control. Access to the dashboard is scoped to a workspace and to a role — owner, administrator or member. The role check runs on the server before any action it governs, so hiding a control in the interface is not the gate. Every read and write is scoped to the caller’s active workspace, so one Customer cannot reach another’s data, and an unrecognised role never passes. The controls that export or erase a person’s data are reserved to owners and administrators.
End User identity. An End User’s identity comes from the signed session the SDK holds and is never taken from the body of a request, so a caller cannot claim to be someone else by editing a payload. Identity tokens are signed with a per-application secret the Customer can rotate.
Audit logging. Administrative actions in a workspace are written to an audit log the workspace can read: application creation and renaming, API key creation, rotation and revocation, identity secret rotation, integration connection and disconnection, End User erasure and blocking, message hiding, attachment removal, suspension and resumption, and workspace export. Each entry records what was done, what it was done to, the acting member’s email address, and when. The write is deliberately best-effort, so that a failure to record never blocks the action it describes, such as revoking a leaked key, and a failed write is reported to our error monitoring rather than swallowed.
Infrastructure. The Service runs on the managed platforms listed in Annex III, in United States regions: managed Postgres, object storage, hosting and compute, a managed Redis used for rate limiting and short-lived operational counters, transactional email, push delivery and billing. Rate limits apply to the public endpoints in order to contain abuse. Backups are the ones those managed providers operate, and Section 8 describes how they age out.
Error monitoring. Our own error monitoring is configured not to attach request bodies, headers or IP addresses, and we never send message content, attachment content or end-user personal data to it. Section 6 of the Privacy Policy describes this in more detail.
Personnel. Access is limited to the people who need it in order to operate, secure and support the Service, and each of them is bound by confidentiality as Section 3 describes.
Assurance. We hold no third-party security certification and no independent audit report. Annex II describes what the Service does today; it is not an attestation by anyone else. Report a suspected vulnerability to logan@brogan.io, as our disclosure policy describes.
14. Annex III — Sub-processors
The Customer authorises the sub-processors below. This is the same list published at /legal/subprocessors, rendered from the same source, so the public list and this Annex cannot drift apart. Section 5 governs how the list changes and how the Customer may object to a change.
Vercel appears once and in two capacities: it hosts and runs the Service, and it provides Vercel Web Analytics, the aggregate page-view counter that runs on every page of our website and dashboard. Sentry is a sub-processor only for error monitoring of our own systems. RevenueCat, PostHog, Mixpanel and a Sentry account a Customer connects as an integration are not sub-processors of ours: those lookups run on credentials the Customer supplies, against the Customer’s own accounts with those vendors, on demand, and nothing they return is stored in Cluestick.
Not every row in the table is engaged for Customer Data under this DPA, because the table is the single published list of every vendor we disclose data to at all. The rows that host, store, transmit or deliver Customer Data — managed Postgres, object storage, hosting and compute, the managed Redis used for rate limiting, and push delivery — are the sub-processors the Customer authorises for the purposes of Clause 9 of the Clauses, and Section 5 governs how that list changes. The billing row, the transactional email row and Vercel in its Web Analytics capacity are engaged only for the account, billing and website data we hold in our own right as controller: Section 1 places that data outside the scope of this DPA, and Part A of the Privacy Policy describes it. Error monitoring sits between the two — it is engaged for our own systems rather than on the Customer’s instructions, and it receives personal data in Customer Data only incidentally, within the limits Annex II states.
| Subprocessor | Purpose | Data | Location |
|---|---|---|---|
| Neon | Managed Postgres — the primary application database | Account data; Conversation and message content; End-user identifiers and device context | United States |
| Cloudflare | R2 object storage — attachment bytes | Attachment files uploaded by end users and agents | United States |
| Vercel | Application hosting, compute and logging, and Vercel Web Analytics — the aggregate page-view counter that runs on every page of our website and dashboard | All data in transit through the service; Request logs; Website page-view events from visitors to our own site | United States |
| Upstash | Redis — rate limiting and short-lived operational counters | IP addresses and API key identifiers | United States |
| Resend | Transactional email — sign-in codes and notifications | Account email addresses; Email message content | United States |
| Apple | APNs — push notification delivery to end-user devices. Apple provides APNs under the Apple Developer Program License Agreement rather than a separate negotiated data processing agreement, so the link on its name is Apple's published privacy documentation rather than a DPA. | Device push tokens; Notification content | United States |
| Stripe | Subscription billing and payment processing | Customer billing contact and payment details | United States |
| Sentry | Application error monitoring for Cluestick's own systems. Sentry acts as a subprocessor only in this capacity — not when a customer connects their own Sentry account, which Cluestick accesses solely as a read-only integration under that customer's agreement with Sentry. | Error traces, which may incidentally include identifiers | United States |
The terms each vendor publishes for the service it provides us are linked from its name in the table above. For most of them that link is the vendor’s own data processing agreement. Push delivery is the exception: it is provided under that vendor’s developer programme licence agreement rather than a separate data processing agreement, and the link on its name is its published privacy documentation, as the table’s purpose column states.