DPA Annexes I, II, and III

A. List of parties

B. Description of transfer

C. Competent supervisory authority

Where the data exporter is established in an EU Member State, the competent supervisory authority is that of the Member State in which the data exporter is established.

Where the data exporter is not established in an EU Member State but falls within the territorial scope of the GDPR by virtue of Article 3(2), and has appointed a representative under Article 27(1), the competent supervisory authority is that of the Member State in which that representative is established.

Where the data exporter is not established in an EU Member State and is not required to appoint a representative under Article 27(2), the competent supervisory authority is that of Ireland.

Where the transfer is subject to the UK GDPR, the competent authority is the Information Commissioner’s Office. Where the transfer is subject to Swiss law, the competent authority is the Federal Data Protection and Information Commissioner.

1. Pseudonymisation

Member records carry an internal identifier derived by one-way hash, used as the join key. While a record is live this identifier does not function as pseudonymisation, because identifying data is held alongside it. Following erasure, all direct identifiers in the member and identity records are overwritten and the retained record is no longer attributable to an individual by TribeROI.

2. Encryption

In transit. All external interfaces are served over HTTPS. HTTP Strict Transport Security is served on all routes. The application connects to the database using a connector that enforces TLS, and the database instance is configured to accept encrypted connections only. Connections to connected platforms are restricted to HTTPS. Internal service-to-service calls require a signed invoker token.

At rest. All persistent stores are encrypted at rest using platform-managed keys provided by the infrastructure sub-processor. Customer-managed encryption keys are not in use.

3. Confidentiality: access control and tenant isolation

Tenant isolation. Customer data is separated by row-level security enforced at the database. Isolation is set per transaction, the application refuses to start under a database role capable of bypassing it, every table holding tenant data is declared and verified as protected, and cross-tenant access is proven absent by automated tests on every change.

Authentication. Access requires a verified identity token. Two independent gates are applied on each session: identity verification, and membership of an access list held in the primary database, which fails closed. A third boundary requires a signed invoker token at the network edge.

Authorization. Roles of administrator, manager, and operator are assigned per user. Tenant resolution fails closed for inactive or suspended accounts. Administrative privilege is asserted against a configured list and fails closed when unset.

Staff access. TribeROI administrative access is held only by named TribeROI staff on a configured list, and is used for support and account operations and to fulfil data subject requests. Through the application it permits: importing data into a Customer’s workspace, and wiping a workspace’s data, at the Customer’s request; and searching a Customer’s members by name or email address, and erasing a member, to fulfil an erasure request. The search returns the matching members’ names, email addresses and erasure status. It does not otherwise permit reading another tenant’s community data through the application. Imports, wipes and erasures are recorded in TribeROI’s administrative audit log with actor, action, target, and timestamp. Searches and erasures are also recorded in the Customer’s data access log, marked as staff access, with the identifiers of the members concerned; the search text is never recorded. Exactly one human principal holds elevated infrastructure permissions; all other access is held by scoped service accounts.

4. Event logging and monitoring

Every administrative write is recorded with actor, action, target, and timestamp. Every data subject rights action is recorded in a separate log. Infrastructure configuration is compared daily against a declared baseline, and relaxation of key security settings raises an alert.

Reads of member personal data. The four interfaces that return member personal data in bulk (the member directory, a member’s profile, member search, and the list of removed members) record each read in the Customer’s data access log, with the user, the interface, and the time. A profile read records the member’s internal identifier; a search records the identifiers of the members matched; a directory or removed-members read records the number of members returned. These records hold identifiers and counts only. They never hold the personal data returned or the text of a search.

5. Protection during storage

Connector credentials are held in a dedicated secrets service, one secret per customer and platform. The database stores only the reference name. Prior versions are destroyed on rotation and all versions are destroyed on disconnection. Credentials are never written to logs or returned by any interface.

Email addresses in log fields are masked at the point of log emission. No other category of personal data is masked automatically.

6. Physical security

All infrastructure is operated by the infrastructure sub-processor identified in Annex III. Physical and environmental security is that sub-processor’s responsibility and is covered by its certifications.

7. Resilience and restoration

The primary database has automated daily backups retained on a rolling 7-day window, and point-in-time recovery from 7 days of transaction logs. That backups and point-in-time recovery are switched on is verified daily against the declared baseline. The control-plane datastore has point-in-time recovery enabled and a daily backup retained for 7 days. A documented restoration procedure is maintained, and point-in-time restoration of the primary database was rehearsed on 26 September 2026.

8. Testing and assessment

Security is assessed on every change: dependency vulnerability scanning in the build pipeline for both application and web components, secret scanning as a required check, and an automated security review that blocks merges on critical or high findings. Tenant isolation and completeness of erasure are each enforced by tests that are verified to fail when the corresponding protection is removed. AI prompts are built from computed figures and from text authorized users type into the Service, with no member names, email addresses or member-written text, and an automated test checks the prompts that describe individual members.

9. System configuration and change management

All changes pass required automated checks before merge. Infrastructure configuration is declared and drift is detected daily.

10. Data minimisation

The Service ingests a defined subset of the fields available at each source and discards the remainder at the client boundary. Message text is stored only where the product requires it: full text from Discord, and excerpts of up to 280 characters from Slack. From all other sources only author-written titles, URLs and tags are kept. Reactions are stored as engagement counts and as a link between reacting individual and author; after erasure the reacting individual is represented only by a pseudonymous identifier.

Requests to the AI sub-processor carry aggregated figures, Customer-supplied text, and, for action drafts, numbered rows that describe members by activity counts and the title of the last event attended. They do not carry member names, email addresses, or member free text.

11. Data quality

Identity resolution across sources records the evidence and confidence of each match, and matches are reversible.

12. Retention limitation

Scheduled processes enforce the retention periods in Annex I B.7 for members marked deleted, prospect records, sign-in identities, survey links, sign-in code records, feature usage records and audit records. Each runs on a rehearsable basis, is idempotent, and logs counts without personal data. Deletion of Community Member Data, authorized user account records and feature usage records on termination, or on the Customer’s request, follows a documented procedure carried out manually.

13. Accountability

A public sub-processor list is maintained. Documented procedures exist for breach notification, account deletion, customer offboarding, and database restoration.

14. Data subject rights

The Service provides, for use by the Customer as controller:

• Access and portability: export of a member’s stored record in a structured, machine-readable format: the profile, linked platform identities, survey responses, event registrations and attendance, employment history, and content the member authored. Notes authored about a member are included; the identity of the authoring staff member is withheld. Other individuals’ messages and identifiers are excluded. Records derived from the member’s activity, such as engagements, relationships with other members, lifecycle history and outcome attribution, are not included.
• Erasure: a two-stage process. The record is first removed from all Customer-facing surfaces, then anonymized. Anonymization clears identifiers across the member record, identity records, free-text fields, identity-match evidence and all AI caches, and clears the message text, excerpts, titles, source URLs and tags of content the member authored. The content record itself is retained with its counts so that previously reported figures do not change.
• Restriction: the first stage of the above, applied without progressing to anonymization. The record is excluded from display and from further use, and is retained unchanged. Statistics already computed are not recalculated.
• Rectification: profile fields are editable in the Service. Name and email are corrected by re-import.

15. Limits of erasure

16. Sub-processor measures

Each sub-processor is bound by data protection terms as recorded in Annex III. TribeROI reviews each sub-processor’s published security measures and certifications.

A. Sub-processors engaged by TribeROI

Sub-processor change notice. TribeROI will give the Customer at least 30 days’ notice before engaging a new sub-processor, during which the Customer may object on reasonable data protection grounds.

Breach notification from sub-processors. Anthropic notifies within 48 hours of becoming aware. Resend notifies without undue delay. Google notifies in accordance with the CDPA. These periods inform the notification commitment TribeROI gives the Customer. Anthropic’s 48 hours is equal to that commitment, not shorter; the others are not expressed as a fixed number of hours.

B. Connected platforms (not TribeROI sub-processors)

The following are sources from which the Service reads data on the Customer’s instruction. TribeROI does not transmit Customer Personal Data to any of them. The canonical list is at https://app.triberoi.com/sub-processors.

The Customer is responsible for ensuring that its use of each platform’s data through the Service is permitted by that platform’s terms.