Security and data handling
Security and data handling
Sync runs on service credentials your admins control. We keep keyed fingerprints of your issue content, not the content, and no contributor token is ever stored.
What we tell customers
What we promise
We don't store your issue content
We store keyed fingerprints used to detect changes. Snapshots, change detection and conflicts hold a fingerprint of each value, never the value itself.
Detailed logs are off unless you turn them on
When on, they're encrypted per tenant, kept for the retention period you choose, and every view is audited.
We never store your contributors' platform tokens
Contributors sign in to Revizto or ACC only to prove what they can see. The token is used during that request and then discarded.
On enterprise plans, you hold the encryption key yourself
Your data keys are wrapped with a key in your own cloud account, so every unwrap appears in your audit trail. Revoke the grant and your data can no longer be read, including in backups.
How it is built
Three layers over a strong baseline
Store less, encrypt what remains per tenant, and let enterprise customers hold the key.
Baseline: SOC 2 Type II, TLS, AES-256
Sync runs on Convex, which is SOC 2 Type II, encrypts all stored data with AES-256 and all traffic in transit with TLS. That covers stolen disks, not our own code, operators or exports. The layers below cover those.
Layer 1: store less
Snapshots, change detection and conflicts store HMAC-SHA256 fingerprints keyed per tenant. A keyed fingerprint rather than a plain hash, so low-cardinality fields like status can't be guessed. The contributor picker and manual conflicts fetch live values, with no display cache, and sync logs are metadata only by default.
Layer 2: per-tenant envelope encryption
What remains, opt-in log payloads, mapping-gap labels and service credential secrets, is encrypted with AES-GCM under a per-tenant data key that a KMS wraps, with the key version stored beside each ciphertext. Crypto runs only in server actions, so the database layer sees ciphertext and fingerprints. Viewing a payload requires an admin, decrypts on demand and writes an audit entry.
Layer 3: customer-managed keys (BYOK)
On enterprise plans you grant Overlink access to a KMS key in your own cloud account and your data keys are wrapped with it. New writes use the newest key version; old rows are re-encrypted in the background or age out through retention.
Org deletion: 30-day grace, then crypto-shred
When an owner requests deletion, all chains pause immediately and the owner can cancel for 30 days. At 30 days the org's keys are destroyed, so everything encrypted for it becomes unreadable, and then the org's rows are deleted. Nothing on your platforms is touched: twins, comments and attachments stay where they are.
What we do not do
Four things Sync never does
Each is an invariant of the sync engine, enforced in code and checked by tests.
We never delete
Sync never deletes an issue, comment or attachment on any platform. The connector contract has no delete operation, and deleting your org touches nothing on your platforms.
We never edit comments
Comments are add-only. We never edit or delete a comment, and edits or deletions made on a platform are not propagated.
We never create on the origin side
Only the origin side of a chain creates issues. Twins appear on the target only, and an issue created on the target is never mirrored back.
We never sync with a contributor's identity
Only the service credentials your admins add read or write synced data. Contributor identities prove visibility and nothing else.
Ready when you are
Sign up with WorkOS to create your org, or see how pricing works.