{"policy":"# Converight Data Handling Policy\n\n**Last updated:** 25 July 2026 · **Applies to:** Converight v1.0.0-beta.1\n**Data processor:** Thinkdata Labs LLP, trading as Converight\n**Companion document:** `subprocessors.md`\n\nThe one-page answer to \"what exactly do you do with our data?\" (PRD §5.1, §11).\nEvery claim here corresponds to something enforced in code or in configuration,\nnot to an intention. Where a control is not yet in place, this document says so.\n\n---\n\n## 1. What we collect, and from where\n\nConveright reads from your Intercom workspace under a **read-only OAuth grant**.\nThe permission set is fixed and least-privilege: read conversations, users and\ncompanies, tags, articles, admins, and teams. Converight never requests a\npermission that can write to, modify, or delete anything in Intercom.\n\n**Backed up in v1:** conversations (including full message transcripts),\ncontacts, companies, tags, articles, admins, teams.\n\n**Not backed up in v1:** attachments — images and files shared inside\nconversations. This is a deliberate v1 scope decision (PRD §5.2). A conversation\nwhose transcript references an attachment is archived in full; the binary itself\nis not. Attachment backup is a v1.1 fast-follow.\n\n**Transcript completeness.** Intercom returns a bounded number of conversation\nparts inline. Where a conversation exceeds that bound, the archived record is\nflagged `truncated` with a note stating how many parts were captured out of how\nmany exist, and the flag is shown in the UI and included in every export. An\nincomplete transcript that looks complete would be worse than no transcript.\n\n## 2. Where it is stored\n\n| Store | Contents | Encryption |\n| --- | --- | --- |\n| S3 archive bucket | Archived record payloads, and nothing else | Per-record AES-256-GCM data key; server-side encryption (SSE-KMS with a per-customer key alias where configured) |\n| S3 exports bucket | Export bundles you generate | Server-side encryption; deleted after 7 days |\n| PostgreSQL | Metadata, wrapped keys, job state, audit log, search index | Encrypted at rest by the provider; OAuth tokens additionally encrypted at the application layer |\n| Redis | Job queue state — job IDs and workspace IDs only | In transit via TLS |\n\n**PostgreSQL holds no archived record content.** The single, deliberate\nexception is a minimal search index, without which the browse UI could only show\nopaque IDs:\n\n- `index_title` — the contact's display name, or the conversation's primary author\n- `index_subtitle` — the contact's email, or the conversation's Intercom title\n  (which for email conversations is the subject line)\n- `index_tags`, `index_state`, and the source created/updated timestamps\n\nMessage bodies, conversation parts, and note content are **never** written to\nPostgreSQL, and are therefore not searchable. Search matches names, subjects,\ntags and dates only. This is a property the automated test suite asserts.\n\n## 3. Immutability\n\nEvery archived object is written to S3 with **Object Lock** enabled, in\nGovernance mode by default, with a retain-until date derived from the workspace's\nretention policy. Within that window the object cannot be modified or deleted by\nany principal — including Converight's own administrative accounts and including\na compromised one.\n\nRecords are **versioned, never overwritten**. When a record changes in Intercom,\nthe next sync writes a new version; the previous version remains readable. This\nis what makes an edit or a deletion inside Intercom recoverable here.\n\nGovernance mode rather than Compliance mode is a deliberate choice (PRD §18.3):\nCompliance mode admits no override by anyone, which would leave no path to honour\nan erasure request. Compliance mode is available on request for customers whose\nregulator requires it, with the erasure trade-off made explicit first.\n\n## 4. Encryption and key management\n\nThree key levels:\n\n```\nROOT_KEK  (environment / KMS, never written to any database)\n  └── workspace KEK   one per connected workspace, stored wrapped\n        └── record DEK   one per archived record version, stored wrapped\n```\n\nEach record's ciphertext is bound to its own identity (workspace, type, ID,\nversion) as authenticated data, so an object cannot be substituted for another\nand still decrypt. Every record carries a SHA-256 checksum of its plaintext,\nverified on every read; a mismatch is surfaced as an error, never returned.\n\nOAuth access tokens are encrypted by the application before they are stored,\nunder the workspace's own key. Database-level encryption is a second layer, not\nthe only one.\n\n## 5. Deletion and the right to erasure\n\nObject Lock forbids deleting an archived object. GDPR Article 17 requires the\ndata to become unrecoverable. Both are satisfied by **crypto-shredding**: the\nrecord's data key is destroyed, the ciphertext is left in place, and the record\nbecomes permanently unreadable — by you, by us, and by anyone who later obtains\nthe object.\n\nErasure is triggered by:\n\n- an explicit erasure request for a contact, a conversation, or a whole workspace;\n- retention-policy expiry;\n- workspace disconnection or subscription cancellation, after the documented\n  retention window (30 days by default).\n\n**Legal Hold outranks all of these.** A record under an active hold is excluded\nfrom every deletion path, and an erasure request that encounters held records\ncompletes as *blocked*, reporting exactly how many records were preserved and\nwhy, rather than silently partially erasing. A hold placed on a contact also\ncovers every conversation that contact appears in.\n\nEvery erasure — requested, completed, or blocked — is written to the audit log.\n\n## 6. Audit logging\n\nRecorded: every backup run (start, complete, fail); every human view, search,\nexport, and download of archived data; every Legal Hold placed or released with\nactor, timestamp, target and reason; every retention change; every erasure; every\nsign-in, invitation and role change; and every billing event.\n\nThe log is **append-only at the database level** — the tables reject `UPDATE` and\n`DELETE` outright — and each entry is **hash-chained** to its predecessor. The\ndashboard exposes a verification endpoint that re-walks the chain, so tampering\nis detectable even by someone with direct table access. Owners can export the\nfull log as CSV.\n\n## 7. Access control\n\nSign-in is by one-time email link. Converight stores no passwords, so there is no\npassword to reset, leak, or stuff. Two roles: **Owner** (full control including\nconnections, holds, retention, erasure and billing) and **Viewer** (read the\narchive and the audit log). Granular role-based access control is v1.1.\n\n## 8. Availability and recovery\n\nBackups run daily by default. A failed run, or a workspace with no successful\nbackup within 30 hours, raises an internal alert **before** it becomes visible to\nyou. An interrupted job resumes from its last checkpoint rather than restarting.\nThe platform's own metadata database is backed up by the managed provider.\n\n## 9. What Converight is not\n\n- **Not a SOC 2 report.** Converight has not yet completed a SOC 2 examination;\n  that engagement begins once the customer base justifies its cost (PRD §5.3).\n  This document and the sub-processor list are what stand in its place today, and\n  we say so plainly rather than implying otherwise.\n- **Not an audit or certification service.** The free SOC 2 readiness gap\n  analysis is a self-assessment. Only a licensed, AICPA-accredited CPA firm can\n  perform a SOC 2 examination and issue a SOC 2 report.\n- **Not a migration tool.** Converight is an archive. It does not move you off\n  Intercom.\n\n## 10. Who we are, and how to reach us\n\nConveright is a product of **Thinkdata Labs LLP**. In the language of GDPR, you\nare the controller of the data in your Intercom workspace and Thinkdata Labs LLP\nis the processor acting on your instructions; the parties in `subprocessors.md`\nare sub-processors.\n\nSecurity questions, sub-processor notifications, data-subject requests, and\nincident reports: `security@converight.com`.\n\n> **TODO before publication.** Add the LLP's registered address, registration\n> number, and jurisdiction. This document is what a customer's legal team reads\n> before signing a DPA, and a trading name with no registered entity behind it\n> is not something they can contract with.\n"}