Security at Solves, in plain English.
Your support inbox holds some of the most sensitive things customers ever write to you. Here is how Solves protects it, stated honestly: customer content is encrypted at rest with XChaCha20-Poly1305 under per-organisation keys, access is limited to authorised people scoped to the right organisation and brands, and logs record what happened without storing message bodies, email addresses or secrets.
No compliance badges, no buzzwords. We describe what is built and say plainly what is still coming.
The short answer
What we protect, and how
Solves is built so the sensitive part of support, the words customers write and the details they share, is encrypted before it touches the database and is only ever shown to people you have authorised. We keep the security story short and checkable rather than dressing it up.
Encryption at rest
All customer support content is encrypted before it is stored. That covers message bodies, subjects, contact names, email addresses and company names, saved replies, tags, raw inbound payloads and contact-form submissions. The encryption is XChaCha20-Poly1305, an authenticated cipher, so stored values are both kept secret and protected against tampering.
Each organisation has its own data encryption key, and every organisation's content is encrypted under that key alone. Each stored value is also bound to its organisation, table and field, so a ciphertext cannot be quietly moved between tenants, columns or rows. If any of that binding does not match on read, decryption fails closed rather than returning the wrong content.
Fields you need to search on, such as a contact email used to find prior tickets, are matched through a separate keyed search index rather than by storing the text in the clear. Look-ups compare a hash, never the plaintext, so search works without leaving readable copies behind.
Authorised access only
Access to support content is restricted to the people in your organisation that you have authorised, and it is scoped further by brand and by ticket visibility. Team permissions use simple role presets together with per-brand access, so you decide who can reply, who can add private notes only, and who can administer a brand. Every database query is scoped to the organisation, and brand and ticket access is enforced consistently, so no one sees beyond the boundary you set for them.
Metadata-only logs
We record what happened, when, and how long it took, so problems are visible before a customer reports them. We do not log the things that would make those records sensitive: message bodies, subjects, email addresses, secrets and raw payloads never reach a log. Structured events pass through a sanitiser that strips forbidden fields and redacts anything that looks like personal data or a secret, and it fails closed if dirty data reaches a log writer.
How it is built
Four practical safeguards
The controls that matter most for an email-first support desk, described in concrete terms.
Encryption at rest
XChaCha20-Poly1305 with a per-organisation key, applied to every piece of customer content before it is stored, and bound to its organisation, table and field so values cannot move between tenants. Decryption fails closed on any mismatch.
Access and logging
Authorised access only, scoped by organisation and brand through role presets and ticket-visibility settings, paired with metadata-only logging that never captures bodies, addresses or secrets.
Email safety
Mailbox setup is verified before live sending is allowed, replies are locked to the ticket's brand and mailbox so nothing goes out under the wrong identity, and a stale-reply check stops a teammate answering on top of an out-of-date view.
Audit history
Significant ticket and account actions are recorded as metadata, who did what and when, so changes are traceable. The audit trail keeps the same metadata-only discipline as the logs and stores no message content.
Saying it straight
What we do not claim
It is easy for a security page to over-promise. We would rather be useful than impressive, so here is what Solves does not say about itself, and why.
Not zero-knowledge
Solves is not zero-knowledge. Customer content is encrypted at rest under per-organisation keys, but the service can decrypt it to show you tickets, run searches and send replies. A genuine zero-knowledge design would mean even we could never read your content, and that is not how Solves works. We would rather state that than imply a guarantee we do not provide.
No blanket compliance claim
We do not claim UK GDPR compliance as a badge, because whether a deployment is compliant depends on how you configure and operate it as much as on the software. We also carry no compliance logos or certification marks we have not earned. Instead we describe the concrete controls in place, encryption at rest, authorised and scoped access, and metadata-only logging, and let you judge them against your own obligations. Solves is designed for UK SMEs, and our accessibility work targets WCAG 2.2 AA.
Retention, export and deletion
Controls for data retention, export and deletion are planned, and parts are already in place. Observability data runs on a metadata-only retention routine today, and tenant isolation means a single organisation's content is cleanly separated. Broader self-service export and deletion for customer support data are on the roadmap rather than finished, so we describe them as coming. As each control ships we will say exactly what it does, here and in the changelog, rather than promise it in advance.
No delivery or omnichannel promises
Solves is email-first. We do not run live chat, phone lines, WhatsApp or social inboxes, and we make no guaranteed-delivery promise for outbound email, because final delivery depends on receiving mail servers we do not control. What we do is verify mailbox setup before live sending and keep sender identity correct per brand, which is the part within our reach.
Found a security issue?
If you believe you have found a vulnerability, please get in touch through our contact page with enough detail to reproduce it, and give us a reasonable chance to investigate and fix it before sharing it more widely. We read every report.
FAQ
Security questions, answered
Is a help desk customer support?
A help desk is the tool customer support runs on, not the support itself. Support is the people answering customers; the help desk is the system that turns incoming email into owned, tracked tickets with owners, states, priorities, notes and SLA timers, so nothing is missed and history is kept. Solves is an email-first help desk: it gives a small support team structure, accountability and a record, while your people do the actual helping.
What makes a secure helpdesk?
A secure helpdesk protects the customer content it holds and limits who can reach it. In practice that means support content is encrypted at rest, access is restricted to authorised people scoped to the right organisation and brands, and logs record what happened without storing message bodies, email addresses or secrets. Solves does all three: customer content is encrypted with XChaCha20-Poly1305 under per-organisation keys, every query is scoped by organisation and brand, and logging is metadata only.
Is customer support content encrypted in Solves?
Yes. Message bodies, subjects, contact names, email addresses and company names, saved replies, tags and raw inbound payloads are encrypted before they reach the database, using XChaCha20-Poly1305 authenticated encryption with a per-organisation key. Each ciphertext is bound to its organisation, table and field, so a value cannot be moved between tenants or columns, and decryption fails closed if anything does not match.
Is Solves zero-knowledge?
No, and we will not say it is. Solves encrypts customer content at rest under per-organisation keys, but the service can decrypt that content to show you tickets and send replies, so it is not zero-knowledge. We would rather state that plainly than imply a guarantee we do not provide.
Does Solves claim UK GDPR compliance?
We do not make a blanket UK GDPR compliance claim, because compliance depends on how you configure and operate the product as well as on the software. What we can say is concrete: customer content is encrypted at rest, access is authorised and scoped, logs are metadata only, and data retention, export and deletion controls are planned, with parts already in place. As those controls land we will describe exactly what each one does.
Can teammates see tickets they should not?
No. Access is governed by role presets, per-brand access and ticket-visibility settings. Every query is scoped to the organisation and to the brands a teammate is allowed to see, and private notes are held separately from replies so light, notes-only collaborators never gain reply access. Contact history a teammate is not permitted to see is never exposed.
Run support on a desk that respects the inbox
Encrypted at rest, authorised access only, metadata-only logs. Start at £29, or ask us a security question first.