Converight Sub-processor List
Last updated: 12 September 2026 · Applies to: Converight v1.1.0 Data processor: Thinkdata Labs LLP, trading as Converight
This document lists every third party that processes, stores, or transmits customer data on behalf of Thinkdata Labs LLP, and — separately — the other parties named in our infrastructure, with the reason each one is not a sub-processor.
Under GDPR terms: the customer is the controller of the data in their Intercom workspace, and Thinkdata Labs LLP is the processor.
Not every party named on this page is a sub-processor, and the distinction is contractual rather than presentational. The authorised sub-processors are those listed in Schedule 3 of our Data Processing Addendum, reproduced below. The parties in the second half of this page are listed because you will find them if you look, not because they are authorised to process Customer Personal Data on our behalf.
We will give 30 days' notice before adding or replacing a sub-processor that
processes Customer Personal Data. To be notified, email
security@converight.com.
The contracting entity is:
| Legal entity | Thinkdata Labs LLP |
| Registration number | AAI-9081 |
| Registered office | #176, First Floor, Sector-10, Panchkula, Haryana 134109, India |
| Jurisdiction | India |
| Contact | security@converight.com |
"Converight" is a trading name, not a counterparty. Contract with the LLP.
Because Thinkdata Labs LLP is established in India, which has no EU adequacy decision, transfers of EU or UK personal data rely on the EU Standard Contractual Clauses — Module Two applies where legally available, subject to the Article 3 assessment — and, for UK transfers, the ICO's International Data Transfer Addendum (Version B1.0), both incorporated by our Data Processing Addendum, published 12 September 2026.
The assessment required by Clause 14 of those Clauses is being completed. Whether GDPR Art. 27 requires us to appoint an EU/UK representative remains under legal review, and this document will name one — or record that it is not required — once that is settled.
Authorised sub-processors
Authorised by Schedule 3 of the DPA. Adding to or replacing anything in this section requires 30 days' notice.
Handling archived customer content
| Sub-processor | Purpose | Data processed | Location |
|---|---|---|---|
| Amazon Web Services India Private Limited (S3) | Archive storage. Every archived record is stored encrypted, under Object Lock. Contracted with the Indian AWS entity; the services it supplies run on US infrastructure. | Encrypted record payloads and generated export bundles | Contracting entity in India; data at rest in us-east-1, Northern Virginia |
| Amazon Data Services, Inc. | AWS onward infrastructure sub-processor supporting us-east-1. Converight contracts with AWS India; this is the entity operating the infrastructure those services run on. |
The same encrypted record payloads and export bundles | Northern Virginia, United States |
| Render Services, Inc. | Runs the API, worker and dashboard; hosts the managed PostgreSQL and Redis instances. | Application metadata, and — in plaintext, so the archive can be searched — the identifiers attached to each archived record: end-user names, email addresses, conversation titles, tags, and pseudonymous Intercom contact IDs. Also the email addresses of your own Converight users, the audit log including the email address of whoever performed each action, wrapped key material and job state. Archived conversation content is not here; it is encrypted in S3. | US (Virginia) |
On the Render row. Calling that store "metadata" would understate what is in it. No archived record content is held there — that part is true — but the archive is searchable, and search needs names and email addresses in a form a database can index. They are therefore held in plaintext, and this page says so rather than leaving a reader to assume otherwise.
The answer to "is any personal data stored outside your encrypted archive?" is yes, and the paragraph above sets out exactly what and where.
Erasure reaches this store: crypto-shredding nulls the name, email, title and tag columns as well as destroying the record's key, and removes the link joining that conversation to an Intercom contact ID once no readable version of it remains. An erased conversation leaves nothing recording that a particular person took part in it.
Not handling archived customer content
| Sub-processor | Purpose | Data processed |
|---|---|---|
| Amazon Web Services India Private Limited, providing Amazon SES | Sends sign-in links and team invitations. Transactional mail only — we operate no lists and send no marketing. | Email addresses of your own Converight users, and one-time sign-in links. No customer archive data. |
| Render Services, Inc. onward sub-processors | Infrastructure supporting Render's own services, as identified in Render's current sub-processor list at render.com/security — verified 14 September 2026. | As Render's list describes; no archived record content beyond what Render itself holds. |
Other parties, and why each is not an authorised sub-processor
These parties appear in Converight's infrastructure or contracts but are not authorised sub-processors under Schedule 3. They are listed here with the reason each falls outside it.
| Party | Classification | Why |
|---|---|---|
| Intercom Inc. | Customer-appointed source platform. Not a sub-processor. | Intercom is engaged by the customer directly, not by us. We read from the customer's own workspace under a read-only OAuth grant the customer issues. DPA §2.4 states this: Intercom is the customer's separately engaged service provider, and it is not a sub-processor appointed by Converight. Nothing in Intercom's own contract covers Converight, which is why a separate DPA with Thinkdata Labs LLP exists at all. Data stays in the customer's own Intercom region (US / EU / AU). |
| Sentry | Optional sub-processor, not currently activated. | Disabled unless a DSN is configured, and Schedule 3 records that it is not an authorised sub-processor unless enabled after notice under DPA §7. This is enforced by the application: enabling Sentry requires recording the date customers were notified, and it remains disabled until that date is at least 30 days old. If activated it receives stack traces and request metadata; cookies, tokens and key material are redacted before transmission, and archived record content is never sent. |
| Cloudflare, Inc. | DNS provider receiving no Customer Personal Data, for as long as proxying stays disabled. | Authoritative DNS for converight.com. Cloudflare's proxy is not enabled, so no request content passes through it and it sees DNS queries only. |
If the Cloudflare proxy is ever enabled, Cloudflare terminates TLS and therefore sees every request and response in transit, including archived record content on its way to the dashboard. That makes it a sub-processor handling customer content: it would require 30 days' notice under DPA §7 and an amendment to Schedule 3 before being switched on. It is a compliance decision, not just a networking one.
What each party can and cannot see
- Archived conversation content exists in exactly one place: the S3 archive bucket, encrypted with a per-record data key. AWS holds ciphertext; the keys that decrypt it are wrapped and held in Converight's PostgreSQL database. Neither store is sufficient on its own.
- PostgreSQL never stores archived record content. It stores pointers, checksums, wrapped keys, job state, the audit log, and a deliberately minimal search index (record type, display name or subject, tags, dates, state) — see Data handling for the exact fields and why they are there.
- Converight staff cannot alter or delete an archived object. S3 Object Lock applies to every principal, including our own administrative accounts.
Open items
- No cross-region replication of the archive bucket. A single-region AWS outage is an availability event, not a data-loss one, but it is stated here rather than left to be discovered in a questionnaire.
- The GDPR Art. 27 representative question is under legal review, as noted above.