Technical and Organisational Measures

Last updated: 14 September 2026 · Applies to: Converight v1.1.0 Data processor: Thinkdata Labs LLP, trading as Converight

Written to drop into Annex II of the Standard Contractual Clauses and into a Data Processing Addendum's security schedule, and to answer a security questionnaire without a call.

Every measure below is implemented, not planned. Where one is verified by an automated test, the test is named — a control nobody checks is a control that has already drifted. Measures we do not have are in the last section rather than omitted.

1. Encryption

At rest. Every archived record is encrypted with its own AES-256-GCM data key. That key is wrapped by a per-workspace key-encrypting key, which is itself wrapped by a root key held only in the application environment — never in the database. Three layers, so compromising the database yields ciphertext and wrapped keys that open nothing.

Additional authenticated data binds each ciphertext to its workspace, record type, external ID and version. A ciphertext moved to another row, workspace or version number fails to decrypt rather than decrypting into the wrong context.

In transit. TLS to the application, to Intercom, to S3, and to the managed database.

Credentials at rest. Each customer's Intercom OAuth token is encrypted by the application before storage, so database-level encryption is a second layer rather than the only one.

Key rotation. The root key can be rotated without re-encrypting a single archived record — only the per-workspace keys are rewrapped. Rotation is all-or-nothing, safe to re-run, skips already-rotated workspaces, supports a dry run, and is recorded in the audit log. Verified by devops-hardening.test.ts, including that it aborts entirely rather than leaving the vault half-readable.

2. Tenant isolation

Each workspace holds its own key-encrypting key. One workspace's key cannot unwrap another's record key — proved by handing the test the other tenant's row directly and confirming decryption fails.

Every query is scoped by workspace, every object is namespaced under its own storage prefix, and two workspaces cannot collide on the same external ID. Route guards resolve a workspace only within the caller's account, so an identifier from another tenant returns 404 — not 403, which would confirm the record exists, and not a decryption error, which would mean the guard was missing and cryptography was the only thing separating them.

Verified by tenant-isolation.test.ts across concurrent workspaces.

3. Access control and least privilege

Against Intercom. Exactly five read-only OAuth scopes — conversations, users and companies, tags, articles, admins. No write, update, delete or messaging permission is requested, so the application has no capability to modify anything in a customer's workspace. Verified by intercom-scopes.test.ts, which fails the build if a write scope is declared or if any endpoint called is not covered by a declared scope.

Against storage. The application's IAM policy denies destructive S3 operations. An organisation-level Service Control Policy denies s3:BypassGovernanceRetention to every principal in the account including its root user, and including an administrator who rewrites the IAM policy.

Human access. Sign-in is by one-time link; there is no password to store, reset or leak. Sessions are httpOnly, sameSite=lax and secure in production. Two roles — owner and viewer — with write operations restricted to owners. Account creation is approval-gated: an unknown address receives no account and no link.

4. Integrity and immutability

Write-once storage. Every archived object is written under S3 Object Lock and cannot be modified or deleted before its retention date, by any account including ours. Governance mode by default, with the bypass permission denied organisation-wide; compliance mode available, which removes the override entirely. Enforcement is checked at startup — production refuses to boot if the archive backend does not really enforce write-once.

Tamper-evident logging. Every backup run and every human action — view, search, export, download — is written to a hash-chained audit log. Each entry chains to its predecessor, so altering history breaks the chain detectably. The database itself rejects UPDATE and DELETE on that table by trigger; it is append-only at the storage layer, not by convention. The chain is verifiable and exportable by the customer. Verified by audit-log.test.ts and audit-timezone.test.ts, which pin the hash inputs against a non-UTC session and sub-millisecond timing.

Checksums. Each record carries a SHA-256 checksum; exports carry a manifest, so a recipient can verify a file independently of us.

Version history. Every snapshot is retained. An edited or deleted conversation leaves its earlier version readable.

5. Availability and resilience

Point-in-time recovery on the managed database (7 days), plus a nightly logical dump written to our own separate AWS account, expiring at 90 days by lifecycle policy — so losing the hosting account cannot take the backups with it.

Archive content is not in that dump; it is already in object storage under Object Lock. The dump carries the metadata and wrapped key material that make it readable.

Restore testing. A sampled decryption runs on demand and confirms the root key, the metadata database and the object store still agree, and that crypto-shredded records are correctly unreadable. Most recent run, against production on 14 September 2026: all 29 readable archived records recovered — every record not crypto-shredded, rather than a sample — with the root key, the metadata database and the object store in agreement.

Failure detection. A missed or failed backup raises a critical alert; the customer is told after two consecutive failures, and immediately if their Intercom token was revoked. Worker liveness is monitored from outside the worker, because a scheduler that detects its own missed runs goes quiet precisely when it dies. Verified by worker-liveness.test.ts and backup-failure-notice.test.ts.

6. Completeness

After every backup, archived record counts are reconciled against Intercom's own per resource type. Sustained drift raises a critical alert. Records Intercom returned incomplete are counted and surfaced rather than left to be discovered.

Immutability proves a record was not altered; it says nothing about a record that never arrived. This is the measure that addresses the second. Verified by capture-coverage.test.ts.

7. Restriction of processing

A record restricted under GDPR Art. 18 is removed from search, refused on retrieval, excluded from exports, and protected from every deletion path — while the encrypted object itself is untouched. Enforced at each of those points rather than by a flag the read paths consult voluntarily.

The Art. 18(1) ground, the target, the actor, both timestamps and a stated reason for placing and for lifting are recorded in the audit log. Verified by processing-restriction.test.ts.

8. Erasure

Erasure destroys the record's data key and nulls the searchable identifier columns, leaving ciphertext that is permanently unreadable under storage that cannot be deleted.

It survives a restore. A backup predating an erasure still holds the key it destroyed, so every erasure is written to an append-only ledger under Object Lock, outside the database — and the application re-applies anything a restore brought back, at startup.

Deletion after disconnection requires a human acknowledgement. A workspace disconnected because Intercom rejected its token is never purged on that basis alone. Verified by crypto-shred.test.ts, erasure-ledger.test.ts and purge-consent.test.ts.

Certification. A customer can obtain a certificate of erasure assembled from the same predicates the deletion paths use, so the document and the behaviour cannot drift. It names what was not erased and why — Legal Hold, an active restriction, an unresolved critical alert, or a disconnection nobody has acknowledged. A certificate claiming completion while a hold quietly preserved records would have the customer tell a regulator something untrue on our authority. Verified by erasure-certificate.test.ts.

9. Data minimisation

Only seven resource types are read, under read-only scopes. Job queue payloads carry identifiers only — no names, addresses or content. Error tracking redacts cookies, tokens and key material, and never receives archived content; it is disabled unless explicitly configured. Sign-in and session tables are deliberately excluded from backups: restoring them would resurrect credentials that should have died with the incident.

10. Testing and change control

As of 14 September 2026, forty automated test suites, run on every push, covering the controls above rather than only the happy path — production boot requirements, token revocation, rate limiting, tenant isolation, key rotation, webhook signature verification, and the deletion paths.

Every build runs typecheck, the full suite, and a build reproducing the deployment's own install, because a green build with development dependencies present says nothing about whether the release will compile.

Infrastructure is declared as code, so a rebuild does not come back missing the backups.

11. Incident response

Documented in our incident response runbook — held internally, because it carries on-call contact details and operational steps, and sent to customers on request to security@converight.com. It includes the point most often got wrong: the 72 hours everyone quotes is the controller's deadline to their supervisory authority. Ours as processor is Art. 33(2) — without undue delay — which is stricter, and a processor that waits 72 hours has probably destroyed the customer's own window.

Separately, Intercom's Platform Guidelines require us to notify Intercom within 72 hours of a personal data breach involving data obtained through their API.

12. Sub-processors

Listed publicly at Sub-processors, with 30 days' notice before adding or replacing any that processes Customer Personal Data.

What we do not have

Stated here rather than omitted, because a reviewer who finds an undisclosed gap stops trusting the disclosed ones.

No SOC 2 or ISO 27001 certification. The controls above are real and tested; they are not third-party attested.
The transfer impact assessment is outstanding. A Data Processing Addendum was published 12 September 2026, incorporating the EU Standard Contractual Clauses (Module Two) and the UK International Data Transfer Addendum — but Clause 14 of those Clauses requires a documented assessment of the destination country's law, and ours is not yet complete.
Attachments are not archived. Transcripts referencing a file are; the binary is not.
Not zero-knowledge. The application decrypts records to serve them, so our staff have the technical capability to read customer content. The control is the audit log, not an inability — and any vendor claiming otherwise while serving you a readable transcript is describing something that cannot be true.
No formal penetration test. Not yet commissioned.
The restore drill is manual. The script exists and is run on demand; nothing runs it on a schedule.

Our Data Processing Map — the store-by-store account of where personal data sits and which transfer legs it crosses — is available on request to security@converight.com.