Passing a security audit with self-hosted email

A security questionnaire lands with a field that reads "list all subprocessors that process customer data, their function, and their region." You start typing, and three lines in you realize your email setup alone accounts for four vendors, each with its own subprocessor page you have never read. Every email SaaS is another row you have to justify.

Email is the part of the stack teams forget to threat-model until an auditor forces the question. A transactional sender holds every recipient address and the body of every receipt, reset, and notification you send. A marketing platform holds your entire subscriber list with names, tags, and engagement history. An inbox or webmail provider holds years of received mail and attachments. Each one is a third party processing your customers' personal data, which makes each one a subprocessor an auditor expects you to name, contract with, assess, and keep watching.

This guide does the unglamorous version of audit prep for email properly: what an auditor actually asks about your email vendors, how to build the artifacts (subprocessor register, DPA inventory, control mapping) they want to see, and what the controls look like when you do them by hand. Then, at the end, it shows where owning the stack collapses most of this work, because the shortest path through an email subprocessor audit is having fewer subprocessors to audit.

How does self-hosting email help you pass a SOC 2 or security audit?

Self-hosting email helps by shrinking the subprocessor surface the audit has to cover. It does not make you compliant on its own, but it removes several third parties (your transactional sender, your marketing tool, your inbox host) from the boundary an auditor draws around your customer data, replacing them with one infrastructure provider you already contract with. Fewer subprocessors means fewer vendor assessments, fewer DPAs, fewer external SOC 2 reports to collect, and a shorter list to disclose to your own customers.

The key word is surface. An audit is not graded on how few tools you use; it is graded on whether you can demonstrate control over every place customer data lives. The trouble with a typical email stack is that customer data lives in three or four vendor systems you do not run, each with its own nested chain of subprocessors. You cannot directly control those systems, so you control them by proxy: you collect the vendor's SOC 2 report, sign their DPA, read their subprocessor page, and trust that what they wrote is what they do. That works, but every vendor multiplies the paperwork and the standing review burden.

Self-hosting changes the shape. When the sender, the list, and the inbox all run inside infrastructure you control, the data is in your account, the access controls are your access controls, and the only external processor is the cloud provider underneath. You trade "trust four vendors and document the trust" for "run the system and control it directly." Both can pass an audit. The second is a smaller surface to reason about and a shorter list to keep current.

What does an auditor actually ask about your email vendors?

An auditor asks where customer data flows, who else can touch it, and whether you have a contract and a control for each of those parties. For email specifically, that resolves into a predictable set of questions, and the painful ones are almost always about the vendors rather than your own code.

The recurring questions, in the order they tend to land:

• Inventory. "List every third party that processes customer or personal data, its function, and its data location." Your email vendors each generate a row here.
• Subprocessors. "For each vendor, list its subprocessors." This is the nested one. Your marketing tool may use a separate analytics provider, a CDN for hosted images, and its own transactional sender, each of which is a place your subscriber data flows.
• Contracts. "Provide the DPA and, where applicable, the SOC 2 or ISO 27001 report for each processor." One per vendor.
• Access control. "Who at your company can access this data, and how is that access granted and revoked?" For a shared inbox or a marketing tool, this is your seat list and your role configuration.
• Data lifecycle. "How long is data retained, and how do deletion requests propagate to every system?" Email systems are notorious for orphaned copies: a suppressed address lingering in send logs, an unsubscribed contact still in a backup.
• Breach handling. "If a subprocessor is breached, how are you notified and how do you respond?" Every vendor you add is a breach you can inherit and must have a plan for.

None of these questions is unreasonable. The reason an email stack makes them painful is multiplication. Three or four vendors means three or four DPAs, three or four subprocessor pages to read and re-read, three or four SOC 2 reports to chase at renewal, and three or four breach-notification paths to wire into your incident response. The audit does not get harder per vendor; it gets longer.

How do you build a subprocessor register for email by hand?

Build a single register that lists, for every system touching customer data, the processor, its function, its region, its own subprocessors, the contract on file, and the data it holds. This is the artifact the inventory and subprocessor questions are really asking for, and most teams do not have it until an audit forces the build. Here is the honest, complete version of that work for the email portion.

Step 1: Enumerate every system that touches an email address or message. Not just the obvious senders. Include the signup form provider that captures addresses, any CRM the list syncs to, analytics tools that receive email-keyed events, the transactional sender, the marketing platform, and the inbox where replies land. If a customer's address or message flows through it, it is in scope.

Step 2: Pull each vendor's own subprocessor list. Reputable processors publish one, often at vendor.com/subprocessors or /legal/subprocessors. Record every entry and its region. This is where short registers fall apart: your primary vendor is one row, but its three subprocessors are three more places data flows that you are contractually obligated to disclose.

Step 3: Record the contract on file for each. A signed DPA at minimum, plus the most recent SOC 2 Type II or ISO 27001 report where the vendor provides one. Note the report date; an expired report is a finding.

Step 4: Record region and retention. Where the data is processed and how long it is kept. Note any cross-region transfer, because that pulls in transfer-mechanism questions covered in keeping subscriber data in your own region.

A minimal register row for the email portion, in plain terms:

System:          Marketing / newsletter platform
Function:        Stores subscriber list, sends campaigns
Personal data:   Subscriber email, name, tags, engagement, consent timestamp
Processor:       Acme Mail Inc. (US)
Subprocessors:   Acme CDN (US), Acme Analytics (US), SES (us-east)
Contract:        DPA signed 2025-03; SOC 2 Type II on file (report 2025-09)
Region:          us-east
Retention:       Indefinite until manual list deletion          <-- review

Now multiply that row by every email vendor in the stack. A team running a transactional sender, a marketing tool, and a hosted inbox produces three of these primary rows and, once the subprocessor columns are expanded, eight to twelve total entries an auditor can ask about individually. Each subprocessor page is also a living document the vendor updates without notifying you in any way you will reliably catch, so the register is never finished: it has to be re-pulled at every audit and ideally on a schedule between them.

What controls does the audit expect over the email system itself?

Beyond the subprocessor paperwork, an auditor expects demonstrable controls over how the email system is accessed, changed, monitored, and recovered. These apply whether the system is a SaaS tool or self-hosted; the difference is whether you are evidencing your own controls or relying on a vendor's report for theirs.

The control areas that matter for an email system:

• Access control. A documented list of who can read the inbox, who can send on behalf of the company, and who can edit the subscriber list, with a process for granting and revoking. Role-based access is the expected shape; modeling it is covered in adding role-based access to a shared team inbox.
• Change management. How code or configuration reaching the live sending and inbox system is reviewed and deployed. For self-hosted, this is your pull-request and deploy pipeline; auditors like to see that production changes are reviewed, not pushed ad hoc.
• Logging and monitoring. A record of who accessed what and when, and alerting on anomalies. For a sender, this includes the send log; for an inbox, access logs.
• Encryption. Data encrypted in transit (TLS for sending and for the admin UI) and at rest (the database and object storage).
• Data lifecycle. Retention periods and a deletion runbook that propagates an erasure request to every place a copy lives.
• Backup and recovery. Regular backups and a tested restore path, so a failure does not mean data loss. The mechanics for a Cloudflare stack are in backing up and restoring a Cloudflare email stack.

With a SaaS stack, you satisfy most of these by collecting the vendor's SOC 2 report and pointing the auditor at it: the vendor evidences encryption, their logging, their change management. That is legitimate, and it is also the trade you are making. You inherit their controls and their report cycle, and you are one renewal lapse or one critical subprocessor change away from a gap you did not create. With self-hosting, you evidence these controls directly, against a system that runs on your own account, with its data, logs, and configuration under your control. More work to author, but no third party's report to depend on and no surprise when their boundary shifts.

Where does owning the email stack shrink the audit surface?

Owning the stack collapses the email subprocessor list from three vendors-plus-their-subprocessors down to one: your infrastructure provider. There is no separate transactional sender to assess, no marketing SaaS holding your list, and no third-party inbox host to contract with, because all three functions run inside infrastructure you control. The inventory row that used to be four vendors becomes "our own deployment, on our cloud account," and the only external processor left is the cloud provider you already had to account for.

This is where a stack like Tinbox fits. Tinbox is a tenant-deployed email system that runs on your own Cloudflare account: a transactional sender, a newsletter and marketing tool, and a human webmail inbox, all on D1 (SQLite), R2, Queues, and Workers that you deploy. The subscriber list, the send logs, and the received mail live in one D1 database in your account instead of being scattered across three vendor systems. You install it with one command:

npx tinbox init yourdomain.com

✔ Provisioned D1 database (tinbox-yourdomain-db)
✔ Provisioned R2 bucket (tinbox-yourdomain-mail)
✔ Wrote wrangler.jsonc (assets + queue consumer + cron + email handler)

Next: add the printed DNS records (MX, SPF, DKIM, DMARC), then `npx tinbox deploy`.

For the audit, the effect is concrete. The three email rows in your subprocessor register (sender, marketing, inbox) become one: "Tinbox, self-hosted on our Cloudflare account." Cloudflare is your infrastructure provider and the single subprocessor entry, with its own published SOC 2 and ISO certifications and its own subprocessor controls you cite once rather than chasing across four vendor pages. A deletion request becomes a query you run against your own D1 store instead of three support tickets hoping the deletion actually propagates. Access control is your own role configuration, change management is your own deploy pipeline, and the system handling the mail runs on infrastructure you own rather than a black box you infer from a report. The broader case for owning your infrastructure is in building an email stack you own and control.

Two honest caveats, because overstating compliance is exactly the kind of thing an audit catches. First, self-hosting does not make you compliant by itself. SOC 2, ISO 27001, and GDPR are about controls and lawful basis, not about which tool you run. You still owe access control, change management, logging, encryption, retention, breach notification, and a deletion runbook for the self-hosted system, and you still need a DPA with your cloud provider. Self-hosting removes processors from the chain and gives you direct control to evidence; it does not remove your obligations, and anyone telling you otherwise is selling you a finding. Second, a Tinbox deploy is scoped to one brand and one domain today. You run multiple tenants by doing separate deploys, one per domain, on the same Cloudflare account; multi-domain-per-instance and a control-plane SSO are designed but not yet built. For an audit of a single product on a single domain, that is fine; if you operate many brands, plan for one deploy per domain rather than one global instance, and reflect that accurately in your inventory.

The deeper point is that the audit surface and the data-ownership question are the same question. The teams that pass cleanly are not the ones with zero vendors; they are the ones who can name every place customer data lives and show a control for each. Shrinking that list to "our account, our cloud provider" is the most direct way to make the list nameable. For the full model of what owning the stack buys you, the Tinbox overview lays it out end to end.

Deploy this yourself: npx tinbox init yourdomain.com. The subprocessor register and the control-mapping checklist above are the two artifacts to build first, and the docs cover the access-control and backup settings that back them.