← TribeROI beta

DPA Annexes I, II, and III

These annexes complete Annexes I, II, and III of the EU Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914), Module Two (controller to processor) and, where the Customer acts as a processor for a third party, Module Three (processor to sub-processor). They are also referenced by the body of the TribeROI Data Processing Agreement and reused in the TribeROI privacy notice.

Version
1.0

Annex I

A. List of parties

Data exporter (Customer)

Name, address, contact person, and role: as set out in the Agreement.

Role: Controller in respect of Community Member Data. Where the Customer processes Community Member Data on behalf of a third party, the Customer is a Processor and TribeROI is a Sub-processor.

Data importer (TribeROI)

Name: TribeROI Inc
Address: 971 US Highway 202N, Suite N, Branchburg, NJ 08876, United States
Contact: privacy@triberoi.com

Activities relevant to the transfer: provision of the TribeROI community measurement and analytics application at beta.triberoi.com.

Role: Processor.

B. Description of transfer

B.1 Categories of data subjects

  1. Members of the Customer’s community. Individuals who participate in the Customer’s events, forums, repositories, or publications. These individuals have no direct relationship with TribeROI and do not contract with TribeROI.
  2. The Customer’s authorized users. Individuals the Customer permits to access the Service in an administrator, manager, or operator capacity.

B.2 Categories of personal data

CategoryFields
Identity and contact dataFull name; email address; platform username or handle; display name; real name as published on a source platform; platform account identifier.
Profile dataLocation; biography; photograph URL; labels or tags applied by the Customer.
Event participation dataRegistration status; registration timestamp; attendance and check-in timestamps; derived non-attendance.
Survey dataNumeric ratings, net promoter scores, and benefit scores; free-text survey responses.
Public content metadataTitles and URLs of posts, discussion topics, issues, releases, and articles authored by the individual on connected platforms; engagement counts. Content bodies are read for the sole purpose of extracting mentions and are then discarded. They are not stored.
Interaction dataDirected records of interactions between individuals (replies, mentions, quotations, reactions), stored as a graph of relationships.
Derived dataLifecycle state history; identity-resolution confidence scores and match records; per-author content metrics.
Customer-authored data about membersFree-text notes authored by the Customer’s authorized users concerning a member. Such records concern two data subjects: the member described and the author.
Authorized user dataAccount identifier; email address; role; display name; feature usage records.

B.3 Sensitive data

None. The Agreement prohibits the Customer from submitting special categories of personal data within the meaning of Article 9 GDPR.

The Customer’s attention is drawn to the following, which informs that prohibition rather than qualifying it. No field in the Service is designed to hold special category data and no field is technically prevented from holding it. Free-text fields, tags, discussion topic titles ingested from connected platforms, and the interaction graph could carry such data if the Customer’s community generates it. The Customer therefore warrants that it will not submit special category data to the Service and will not connect a source whose ordinary content would constitute such data.

B.4 Frequency of the transfer

Continuous for connected platform sources, which are synchronized on a scheduled basis. Periodic and Customer-initiated for file imports. One-off for survey responses submitted by members.

B.5 Nature and subject matter of the processing

Collection, storage, organization, structuring, aggregation, and statistical analysis of community participation data for the purpose of producing community health measurements.

The processing includes:

  • Ingestion from Customer-connected platforms using credentials the Customer supplies, and from files the Customer uploads.
  • Pseudonymous identity resolution, which links records describing the same individual across multiple sources.
  • Deterministic computation of factor, pulse, and aggregate scores.
  • Generation of narrative summaries of aggregated results using an AI sub-processor. Member names, email addresses, and member free text are not transmitted for this purpose. Members are referenced by positional index only, which is enforced by an automated test.
  • Erasure and export operations performed on the Customer’s instruction.

B.6 Purpose of the transfer and further processing

To provide the Service to the Customer in accordance with the Agreement. TribeROI does not process Community Member Data for its own purposes, and does not use it to train machine learning models.

No sub-processor trains models on data received from TribeROI. The AI sub-processor is contractually prohibited from doing so under its Commercial Terms of Service. Data sent to that sub-processor is retained by it for 30 days and may be accessed by it for safety and security purposes. Feedback submission, which would transmit complete requests and responses for model improvement, is disabled at the organization level.

B.7 Retention period

CategoryPeriod
Community Member Data, during the termRetained for the duration of the Agreement
Community Member Data, on terminationDeleted within 30 days of termination
Members marked deleted by the CustomerAnonymized 30 days after marking
Authorized user and prospect records24 months from last contact
Audit records generally24 months
Records of erasure actionsRetained for the duration necessary to demonstrate compliance. These contain no direct identifiers; the subject is recorded as a keyed hash or as a post-erasure pseudonymous identifier
Application logs30 days
Database backups7 days (rolling)

B.8 Sub-processor retention

Each sub-processor’s retention period is set out in Annex III.

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.

Annex II — Technical and organisational measures

Measures are described as implemented. The limits of each measure are stated alongside its coverage.

1. Pseudonymisation

Member records carry a derived identifier used as the internal 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 permits write operations across tenants for support and provisioning. It does not permit reading another tenant’s community data through the application. 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.

Limit, stated explicitly. Read operations are not logged. In the event of an incident, TribeROI can enumerate affected tenants and records that were modified. It cannot enumerate records that were only read. This limit is reflected in the breach notification provisions of the Agreement.

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.

Personal data is masked at the point of log emission.

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

Automated daily database backups are retained on a rolling 7-day window, with 7 days of transaction logs. Backup configuration is verified daily against the declared baseline. A documented restoration procedure is maintained.

Limits, stated explicitly. The primary database is zonal and has no read replica. Point-in-time recovery is not enabled.

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, absence of personal data in AI prompts, and completeness of erasure are each enforced by tests that are verified to fail when the corresponding protection is removed.

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. Content bodies from connected platforms are read for mention extraction and are not stored. Reaction data is stored as counts without reactor identity where the source permits.

Requests to the AI sub-processor carry aggregated figures and Customer-supplied text. 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. Each runs on a rehearsable basis, is idempotent, and logs counts without personal data.

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 complete record in a structured, machine-readable format. Notes authored about a member are included; the identity of the authoring staff member is withheld.
  • 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.
  • 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

Erasure does not reach:

  1. Records of erasure actions themselves, retained to demonstrate compliance and containing no direct identifiers.
  2. Aggregate statistics previously computed, which contain no identifying data.
  3. Database backups, for a maximum of 7 days.
  4. Application logs, for a maximum of 30 days, in which personal data is masked at emission.
  5. Any data the Customer has exported to its own systems.

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.

Annex III — Sub-processors

Canonical list: https://beta.triberoi.com/sub-processors

A. Sub-processors engaged by TribeROI

Sub-processorEntityProcessingLocationTermsRetention on termination
Google CloudGoogle LLCInfrastructure: database, control-plane datastore, secrets management, compute, loggingus-central1 (United States)Cloud Data Processing Addendum, accepted 2026-07-29. European Data Protection Law certification made the same date, applying the Standard Contractual ClausesPer the CDPA
Firebase AuthenticationGoogle LLCIdentity and authentication for the Customer’s authorized usersGoogle-managed infrastructure, primarily United StatesCovered by the Cloud Data Processing Addendum accepted 2026-07-29Per the CDPA
AnthropicAnthropic, PBC (contracting entity for customers outside the EEA, Switzerland, and the UK)Generation of narrative summaries from aggregated data. Receives no member names, email addresses, or member free textUnited StatesCommercial Terms of Service effective 2025-06-17, which prohibit training on customer content and incorporate the Data Processing Addendum effective 2025-02-24. Standard Contractual Clauses Modules Two and Three incorporated; UK Addendum and Swiss Addendum included; governing law Ireland for the ClausesRetention of inputs and outputs set to 30 days at organization level. Deletion of all customer data within 30 days of termination
ResendPlus Five Five, Inc., 2261 Market Street #5039, San Francisco, CA 94114Transactional email to the Customer’s authorized users and prospects. Does not receive Community Member DataUnited StatesData Processing Addendum executed 2026-01-14. Standard Contractual Clauses Modules One, Two, and Three incorporated; governing law Ireland. EU-US Data Privacy Framework and UK Extension certification heldDeletion within 90 days of account termination

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, and are shorter than, the notification commitment TribeROI gives the Customer.

B. Connected platforms (not TribeROI sub-processors)

The following platforms are sources from which the Service reads data on the Customer’s instruction, using credentials the Customer supplies from its own account. The Customer holds the contractual relationship with each. TribeROI does not transmit Community Member Data to them.

PlatformData readNote
LumaEvent guest records: identifier, approval status, email, name, registration and check-in timestampsGuests without an email address are skipped
DiscourseUser records including email address, discussion topic titles and URLs, engagement eventsThe Service requests email addresses through the administrative interface. The Customer must have a lawful basis for this disclosure
GitHubAccount login, identifier, name, publicly published email; issue and release titles and URLsLimited to repositories the Customer explicitly lists
DEV.toAccount identifier, username, name; article and comment metadataThe source exposes no email address

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