Overview
This document explains exactly what UnfussyCRM (the service operator) can and cannot access from your data, how that data is protected, and what technical and operational controls are in place. We aim to be direct about the limits of our privacy model so you can make an informed decision.
What we can see
The following data is stored in plaintext and is accessible to the service operator:
| Data | Notes |
|---|---|
| Your login email address | Used for account authentication and notifications |
| Organisation and workspace name | Visible in admin dashboard |
| CRM contact records | Names, email addresses, company, pipeline stage, tags, last-touch date |
| Email subjects | Stored unencrypted for fast list rendering |
| Email snippets | First ~200 characters of each email body, stored unencrypted for inbox list performance |
| Email participant addresses | From / To / CC / BCC addresses for every synced message |
| Message metadata | Timestamps (sent, received), direction (inbound/outbound), read status, thread groupings |
| Attachment metadata | Filename, file size, MIME type — not the attachment content |
| Parsed contact signatures | Structured fields extracted from email signatures (name, title, phone) |
| Activity and touchpoint counts | How many emails exchanged, meeting notes, stage changes |
| Storage and usage metrics | Per-workspace email count, contact count, storage volume |
| Billing and subscription status | Stripe plan and status |
What we cannot easily see
The following data is encrypted before being written to the database. It is not readable from a database dump or direct database access without additional server-side access:
| Data | Encryption |
|---|---|
| Email body text | XChaCha20-Poly1305, per-user key |
| Email body HTML | XChaCha20-Poly1305, per-user key |
| Email headers | XChaCha20-Poly1305, per-user key (stored for threading and compliance replay) |
| OAuth access and refresh tokens | XChaCha20-Poly1305, server key |
| IMAP / SMTP credentials | XChaCha20-Poly1305, server key |
Important caveat: This is encryption-at-rest, not zero-knowledge encryption. The key management model is described in the next section. A determined operator with server access could technically decrypt this data.
How encryption works
Key hierarchy
UnfussyCRM uses a two-tier key model:
- Key Encryption Key (KEK) — A single 32-byte random key held only as an environment variable on the API and mail-sync servers. It is never written to the database. It is used to wrap per-user keys and to encrypt OAuth credentials directly.
- Per-user Data Encryption Key (DEK) — A unique 32-byte random key generated the first time you connect an email account. Your DEK is stored in the database only in its wrapped (encrypted) form, protected by the KEK. The plaintext DEK exists only in server memory during active request handling.
Encryption algorithm
All content encryption uses XChaCha20-Poly1305 (via libsodium). Each encrypted value includes a random nonce, so no two ciphertexts are alike even for identical inputs.
What this protects against
| Threat | Protected? |
|---|---|
| Database breach (attacker gets a database dump) | Yes — email bodies, headers, and credentials are ciphertext without the KEK |
| Compromised backup | Yes — same as above |
| Insider threat (rogue employee with DB access only) | Yes — they cannot read email bodies without the KEK |
| Insider threat (full server access, including env vars) | No — the KEK is accessible to someone with server-level access |
| Subpoena for database contents | Partial — metadata and subjects would be disclosed; encrypted bodies would require also disclosing the KEK |
Body storage policy
We apply a hybrid storage model to minimise unnecessary data retention:
- Gmail and Microsoft — emails from or to a known CRM contact: Body text is encrypted and stored in the database for immediate access.
- Gmail and Microsoft — emails from unknown senders (non-contacts): Only the subject and 200-character snippet are stored. The full body is never proactively stored. It is fetched on-demand from Gmail or Microsoft Graph only when you explicitly open the message, then encrypted and stored at that point.
- IMAP accounts: Body text for all messages is encrypted and stored, regardless of whether the sender is a CRM contact. This is a limitation of the IMAP protocol — there is no equivalent on-demand fetch mechanism once the live connection closes.
- HTML email bodies: HTML is never stored for Gmail or IMAP — only plain text. For Microsoft, the HTML body is stored encrypted when no plain-text version is available.
- Attachment content: Never stored. Attachment binaries remain at the mail provider.
What we do with your data
- We do not sell your data to any third party.
- AI features (reply drafting, contact enrichment) use Anthropic's API. Only the specific text submitted for a request is sent; we do not batch-send your entire email history. Anthropic's data handling is governed by their API terms.
- Your email credentials (OAuth tokens) are used solely to sync your mail. They are not used for any other purpose and are not shared.
- Operational staff do not routinely access customer email content. The admin dashboard exposes usage metrics (counts, storage volumes) only — not message content.
Data hosting and infrastructure
Database, API, and mail-sync services run on infrastructure you control when self-hosted, or on dedicated cloud instances for managed deployments. Database backups are encrypted at rest. All API traffic is TLS 1.2+ in transit. The database is not publicly accessible; it is reachable only from within the private network.
Data retention and deletion
- Email data: Configurable per workspace. Older raw messages can be purged on demand via the admin dashboard. Retention policy defaults to 365 days.
- Account deletion: Removing your email account connection deletes OAuth credentials immediately. Synced message rows are soft-deleted; a hard purge can be triggered by a workspace admin.
- Workspace deletion: A full workspace delete removes all associated contacts, messages, touchpoints, and users from the database.
Your controls
As a workspace administrator you can:
- Purge email records older than a configurable number of days
- Purge touchpoints while retaining the CRM contact record
- Disconnect email accounts (revokes stored credentials)
- Export contact and activity data via the API
- Delete the workspace entirely, removing all data
Summary
| Question | Answer |
|---|---|
| Can you read my email bodies? | Technically yes, if someone has both DB access and server env access. From DB alone: no. |
| Are my email credentials safe if the DB is leaked? | Yes — credentials are encrypted and unreadable without the server key. |
| Do you use my emails to train AI? | No. AI requests are per-action and use Anthropic's API under their data terms. |
| Is this zero-knowledge? | No. The encryption key is server-side. This is strong encryption-at-rest, not end-to-end. |
| Who controls my data retention? | You do — configurable per workspace, with on-demand purge. |
If you have questions about a specific data handling scenario, please contact us directly.