Converight Data Handling Policy

Last updated: 24 August 2026 · Applies to: Converight v1.1.0 Data processor: Thinkdata Labs LLP, trading as Converight Companion document: Sub-processor list

Every claim in this document corresponds to something enforced in code or in configuration, not to an intention. Where a control is not yet in place, this document says so.

1. What we collect, and from where

Converight reads from your Intercom workspace under a read-only OAuth grant. The permission set is fixed and least-privilege: read conversations, users and companies, tags, articles, admins, and teams. Converight never requests a permission that can write to, modify, or delete anything in Intercom.

Archived: conversations (including full message transcripts), contacts, companies, tags, articles, admins, teams.

Not archived: attachments — images and files shared inside conversations. A conversation whose transcript references an attachment is archived in full; the binary itself is not. Attachment archiving is planned.

Transcript completeness. Intercom returns a bounded number of conversation parts inline. Where a conversation exceeds that bound, the archived record is flagged truncated with a note stating how many parts were captured out of how many exist, and the flag is shown in the UI and included in every export. An incomplete transcript that looks complete would be worse than no transcript.

2. Where it is stored

PostgreSQL holds no archived record content. The single, deliberate exception is a minimal search index, without which the browse UI could only show opaque IDs:

• index_title — the contact's display name, or the conversation's primary author
• index_subtitle — the contact's email, or the conversation's Intercom title (which for email conversations is the subject line)
• index_tags, index_state, and the source created/updated timestamps

Message bodies, conversation parts, and note content are never written to PostgreSQL, and are therefore not searchable. Search matches names, subjects, tags and dates only. This is a property the automated test suite asserts.

3. Immutability

Every archived object is written to S3 with Object Lock enabled, in Governance mode by default, with a retain-until date derived from the workspace's retention policy. Within that window the object cannot be modified or deleted by any principal — including Converight's own administrative accounts and including a compromised one.

Records are versioned, never overwritten. When a record changes in Intercom, the next sync writes a new version; the previous version remains readable. This is what makes an edit or a deletion inside Intercom recoverable here.

Governance mode is the default, and Compliance mode is available on the Enterprise plan for customers whose regulator names it.

Both modes are WORM. On either plan an archived object cannot be altered or deleted for its retention period, by us or by anyone else.

The difference is what the guarantee rests on. Governance mode has a privileged override built into S3, and we deny it across the whole AWS organisation with a Service Control Policy — verified by attempting the deletion as an organisation administrator and being refused. So the object is immutable, but the mechanism that makes it immutable is a policy under our control, and a policy can in principle be changed by whoever controls it.

Compliance mode removes the override itself. There is then nothing for us to change our minds about, which is what a regulator naming non-rewriteable, non-erasable storage is usually asking for.

Erasure works identically under both. An erasure request destroys the record's encryption key; it never deletes the object. So choosing Compliance mode costs nothing in the ability to honour Article 17 — a point worth stating plainly, because the reverse is widely assumed.

What Compliance mode does cost is operational recovery. If the wrong workspace is ever archived, those objects are unreachable for the full retention period by anyone, including AWS. That is the trade-off to weigh, and it is why Governance is the default rather than the ceiling.

4. Encryption and key management

Three key levels:

ROOT_KEK  (environment / KMS, never written to any database)
  └── workspace KEK   one per connected workspace, stored wrapped
        └── record DEK   one per archived record version, stored wrapped

Each record's ciphertext is bound to its own identity (workspace, type, ID, version) as authenticated data, so an object cannot be substituted for another and still decrypt. Every record carries a SHA-256 checksum of its plaintext, verified on every read; a mismatch is surfaced as an error, never returned.

OAuth access tokens are encrypted by the application before they are stored, under the workspace's own key. Database-level encryption is a second layer, not the only one.

5. Deletion and the right to erasure

Object Lock forbids deleting an archived object. GDPR Article 17 requires the data to become unrecoverable. Both are satisfied by crypto-shredding: the record's data key is destroyed, the ciphertext is left in place, and the record becomes permanently unreadable — by you, by us, and by anyone who later obtains the object.

Erasure is triggered by:

• an explicit erasure request for a contact, a conversation, or a whole workspace;
• retention-policy expiry;
• workspace disconnection or subscription cancellation, after the documented retention window (30 days by default).

Legal Hold outranks all of these. A record under an active hold is excluded from every deletion path, and an erasure request that encounters held records completes as blocked, reporting exactly how many records were preserved and why, rather than silently partially erasing. A hold placed on a contact also covers every conversation that contact appears in.

Every erasure — requested, completed, or blocked — is written to the audit log.

6. Audit logging

Recorded: every backup run (start, complete, fail); every human view, search, export, and download of archived data; every Legal Hold placed or released with actor, timestamp, target and reason; every retention change; every erasure; every sign-in, invitation and role change; and every billing event.

The log is append-only at the database level — the tables reject UPDATE and DELETE outright — and each entry is hash-chained to its predecessor. The dashboard exposes a verification endpoint that re-walks the chain, so tampering is detectable even by someone with direct table access. Owners can export the full log as CSV.

7. Access control

Sign-in is by one-time email link. Converight stores no passwords, so there is no password to reset, leak, or stuff. Two roles: Owner (full control including connections, holds, retention, erasure and billing) and Viewer (read the archive and the audit log). More granular role-based access control is planned.

8. Availability and recovery

Backups run daily by default. A failed run, or a workspace with no successful backup within 30 hours, raises an internal alert before it becomes visible to you. An interrupted job resumes from its last checkpoint rather than restarting. The platform's own metadata database is backed up by the managed provider.

9. What Converight is not

• Not a SOC 2 report. Converight has not completed a SOC 2 examination. This document and the sub-processor list are what stand in its place today, and we say so plainly rather than implying otherwise.
• Not an audit or certification service. The free SOC 2 readiness gap analysis is a self-assessment. Only a licensed, AICPA-accredited CPA firm can perform a SOC 2 examination and issue a SOC 2 report.
• Not a migration tool. Converight is an archive. It does not move you off Intercom.

10. Who we are, and how to reach us

Converight is a product of Thinkdata Labs LLP. In the language of GDPR, you are the controller of the data in your Intercom workspace and Thinkdata Labs LLP is the processor acting on your instructions; the parties in the sub-processor list are sub-processors.

Security questions, sub-processor notifications, data-subject requests, and incident reports: security@converight.com.

The contracting entity, for the DPA your legal team will want to put this in:

"Converight" is a trading name, not a counterparty. Contract with the LLP.