How Sigbot protects the data that moves through connected inboxes — from authentication and encryption to how we respond when something goes wrong.
Sigbot is built on established cloud infrastructure rather than self-managed servers, so the Services inherit the physical and network security controls of our providers:
Google Cloud Platform, EU: data in Firestore eur3, processing in europe-west2 (London)
Firebase (Google)
Paddle (merchant of record)
Mail.Read, User.Read, offline_access). If your organisation needs an admin to approve Sigbot, the brief for IT admins says what Sigbot reads and keeps, and how to approve or revoke it for the whole company.We log access to production systems and monitor for anomalous activity. Application logs are kept for 30 days; a separate security log of refused sign-ins and requests, failed mailbox connections, and staff and administrative actions is kept for 400 days, as are admin-activity logs (see section 9); these periods are reviewed in line with our data minimisation obligations.
Sigbot's code redacts email addresses before writing them to application logs. Where one of Sigbot's own log entries refers to an address, whether one of your contacts' or your own, it keeps only the first character and the domain (for example, a…@example.com). The sign-in service (Google Identity Platform) keeps its own log of each sign-in, sign-up and account change, with the full email address used, the IP address, browser details and the outcome, for 30 days; failed attempts are also kept for 400 days in the security log.
We welcome reports of potential security issues in sigbot.app, sigbot.co, our backend and our mobile apps through our Vulnerability Disclosure Policy. No independent penetration test has been carried out yet. We intend to commission one, and will publish its date and a summary here once it has been done.
We maintain a written incident response plan for identifying, containing, and notifying customers of security incidents affecting their data. Under our Data Processing Addendum, we notify affected customers of a personal data breach without undue delay and in any case within 72 hours of becoming aware of it.
A current list of subprocessors that may process Customer Data is maintained in our Data Processing Addendum, and its Annex D sets out our technical and organisational measures. The Subprocessors page sets out the same list in one table — purpose, data, location and transfer mechanism for each — and lets you ask to be emailed each change. We give at least 14 days' notice before adding or replacing a subprocessor.
Sigbot is a growing company and is transparent about where formal certifications currently stand:
Our certification status, our answers to the Cloud Security Alliance security questionnaire (CAIQ) and every security document are collected in the Trust Centre.
Retention is automatic. The periods below are enforced by scheduled deletion and time-to-live policies on our database; nothing on this list needs a request from you.
| Data | Kept for | Then |
|---|---|---|
| Contact records | Until you delete them, then 30 days in Trash, during which you can restore them | Erased. Delete permanently erases at once. |
| Records another member removed from a team folder | 30 days, during which they can be restored | Erased |
| Review-queue entries you rejected | 180 days | Erased |
| Scan coverage hashes (SHA-256 of message ids; no content) | 180 days | Erased |
| Cached signature parses | 90 days | Erased |
| Scan job records | 90 days | Erased |
| Done-for-you build orders that were never paid (a saved brief or an application) | 90 days from when it was last saved or approved; 1 year for a Tell me when Gmail is ready request | Erased. A paid order is kept as a billing record. |
| Throttle counters | 1 day | Erased |
| OAuth sign-in state | 10 minutes | Erased |
| Mailbox tokens | Until you disconnect the mailbox | Google grants are revoked at Google immediately. Microsoft tokens are deleted at once, and the app links to your Microsoft account so you can revoke the grant there. |
| Application logs, and the sign-in service's log of each sign-in, sign-up and account change | 30 days | Erased |
| Security logs: refused and failed sign-ins, sign-ups and requests (with the email address and IP address used), failed mailbox connections, reads of stored secrets, and staff and administrative actions | 400 days | Erased |
| Your public contact card, if you publish one | Shown publicly until you unpublish it; kept in your account until you change it | Deleted with your account |
| Admin-activity logs | 400 days | Erased |
| Everything above, when you delete your account | — | Your subscription is cancelled first, then all of it is erased at once, except the logs, which age out on the schedule above. Copies in backups age out within 14 days. |
Billing records are kept for as long as tax and accounting law require; see Delete your account.
You do not need to contact us for any of the following.
Requests about anything else, or about data held in someone else's account, go to legal@sigbot.co.
Security questions or concerns: security@sigbot.co. We reply within one working day. To report a vulnerability, see our Vulnerability Disclosure Policy.