Data Residency and Email Signatures: Where Does Your Data Actually Go?

By David, 2026-08-07

Ask a signature vendor "where does our data live?" and you'll get a data-center map and a compliance-badge wall. Ask the better question - "what of ours passes through or rests in systems you operate?" - and the conversation gets specific fast. Because for a product category this small, signature platforms move a surprising amount of sensitive data, and the three architectures in the market move very different things.

This article is the tracing exercise: what actually leaves your tenant under each model, so your data-residency review runs on mechanics instead of marketing.

The three flows worth tracing

A signature platform can touch three of your data flows. Any given product touches one, two, or - in the common case - all three:

1. Your outbound mail. In-transit stamping architectures route messages through the vendor's cloud, where the signature is applied before delivery. While that hop exists, the message - body, recipients, attachments - is being processed on infrastructure you don't operate. Vendors handle this responsibly and document it well, but no amount of responsible handling changes the residency fact: your mail content transits a third party's environment, and your data-flow diagram must now say so.

2. Your directory data. To render "Jane Smith, Director of Finance, +44 20…," the platform needs Jane's attributes. Most SaaS platforms sync them - a copy of names, titles, phone numbers, and org structure now rests in the vendor's database, on the vendor's retention schedule, in the vendor's chosen region. Directory data is personal data; under GDPR and most residency regimes, that sync makes the vendor a processor of your employee PII, with everything that implies for your records of processing.

3. Your signature content itself. Templates, brand assets, and the assignment logic connecting people to signatures - typically hosted in the vendor's multi-tenant environment. The least sensitive of the three, but it still describes your org structure, and it still sits outside your boundary.

"Pick your region" is not the same as "it's yours"

The standard SaaS answer to residency concerns is region selection: run our service in the Azure region of your choice. That's genuinely useful - it answers the jurisdiction question, and for many organizations it's enough.

But be precise about what it doesn't answer. Region-selectable processing is still the vendor's processing: their subscription, their operators, their retention, their multi-tenant blast radius. If your requirement is "employee data stays within the EU," region choice can satisfy it. If your requirement is "employee data stays within our tenant" - increasingly the bar in government, healthcare, and finance - then where the vendor hosts is beside the point, because the vendor hosting anything is the finding. We walk through this distinction vendor-by-vendor in the Atlas Ink vs Crossware comparison, where region-selectable sovereignty is the headline pitch.

What the alternative looks like

Now run the same trace against a customer-owned, push-based architecture - the model Atlas Ink is built on:

• Mail: never routed through Atlas. There's no connector and, by default, no transport rule; Atlas writes each user's own Outlook compose signature via the Exchange admin API, so a message leaves Exchange Online exactly as Microsoft sends it. Flow 1 doesn't exist. (Optional server-side stamping, which an admin turns on explicitly and which isn't available in GCC or GCC High, adds one mail-flow rule in your own Exchange Online. The signature is appended inside Microsoft's pipeline, so mail still never transits Atlas, and Flow 1 still doesn't exist.)
• Directory: read in place, read-only, via Microsoft Graph - from a service running inside your own Azure subscription. Tokens hydrate at push time. There is no synced copy of your people in a vendor database, because there is no vendor database. Flow 2 doesn't exist.
• Signature content: templates and assignments live in a per-tenant PostgreSQL database in your subscription, encrypted with keys in your Key Vault. Flow 3 stays home too.

What does leave the tenant? An aggregate count of distinct active users per month, reported to Atlas for metered billing (always $1 per active user, per month), plus, if you add clickable banners, the banner links and their click counts. No signature content leaves - which turns the residency section of your vendor assessment from a diagram into a sentence.

The same logic applies to the audit trail. When the platform runs in your subscription, its logs are your logs: who changed which template, what was pushed where, all inside the boundary your SIEM already watches.

The questions that sort every vendor quickly

Five questions, answerable from any vendor's architecture documentation, that separate the three models in minutes:

1. Does outbound mail transit your infrastructure? If yes: which regions, what's logged, and how long does message content persist anywhere?
2. Do you store a copy of our directory attributes? If yes: which fields, what retention, and is deletion on offboarding automatic or on request?
3. Where do templates and assignment data live, and are they encrypted with keys we control?
4. What is the complete list of data that leaves our tenant in normal operation? (The right answer is short. Ours is one item long.)
5. Where do your service's audit logs live, and can we ingest them without an export pipeline?

If a vendor's answers require a meeting rather than a page, that's an answer too.

Residency reviews exist because "trust us" isn't a control. The cleanest way to pass one is to have almost nothing to review - and that's a property you choose at architecture-selection time, not one you bolt on afterwards. If "no signature content leaves, only billing and banner-click counts" is the shape your review needs, that's the product.