Security, written for the person doing the review

What data we hold, and why

Running an email platform means holding two categories of data. The first is your account data — your users, your billing details, your settings. The second, and the one that matters for a vendor review, is your contact data: the people on your lists, their attributes, and the events you send us about what they did.

We process contact data as a processor acting on your instructions. You remain the controller. That distinction determines who is responsible for having a lawful basis to email those people, and the answer is you — which is why the consent guidance in our alternatives pages is written as carefully as it is.

Certifications, and what we do not hold

Bluey Email is Google CASA verified and certified. CASA — Cloud Application Security Assessment — is the framework Google requires of applications requesting sensitive scopes, and it covers authentication, data handling, dependency management and secure development practice against the OWASP Application Security Verification Standard.

We do not hold a SOC 2 attestation, and we would rather tell you that here than let you discover it three weeks into a procurement cycle. If SOC 2 is a hard requirement in your vendor policy, we are not the right choice today and you should say so early. What we can provide is a DPA, standard contractual clauses where transfers require them, and a completed security questionnaire.

Encryption

Data is encrypted in transit using TLS on every connection — the web application, the API, the SMTP relay and outbound delivery where the receiving server supports it. Data at rest is encrypted at the storage layer.

Outbound mail uses opportunistic TLS: we encrypt delivery wherever the receiving mail server offers it, which today is the overwhelming majority. Where a receiving server does not support TLS, the alternative to sending in the clear is not sending at all, and that is a decision we surface rather than make silently.

Access control

Access to production systems is limited to the engineers who need it, authenticated with multi-factor authentication, and logged. Support staff can act on an account only with a record of having done so.

On your side, accounts support multiple seats with role-based permissions, so a contractor building a campaign does not need the credentials that can export your entire list. Higher plans add SSO and an audit log.

Sub-processors

We use third parties for infrastructure, payments and delivery. The current list is published below and we will tell you before it changes materially, so you have time to object if your own DPA requires it.

Data residency

Where your data is stored matters for GDPR transfers, for India's DPDP Act and for anyone with a public-sector customer. EU data residency is available on request rather than by default — if you need it, raise it before you sign rather than after, because moving an account between regions is not a switch we can flip retrospectively.

Incident response

If we become aware of a breach affecting your data, we will notify you without undue delay with what we know at the time, and update you as the picture develops rather than waiting until it is complete. GDPR sets a 72-hour notification obligation on you as controller, which means our disclosure to you has to leave you time to meet it.

Your responsibilities

A security page that only describes the vendor is half a page. The parts that are yours:

• –Authenticate your sending domain with SPF, DKIM and DMARC. An unauthenticated domain is spoofable, and no platform can fix that from its side.
• –Use role-based seats rather than sharing one login, and remove people when they leave.
• –Keep API keys out of client-side code and out of your repository, and rotate them when someone with access departs.
• –Have a lawful basis for the contacts you upload. We provide the mechanics; the consent record is yours.
• –Verify webhook signatures so you are not acting on forged payloads.