Data Processing Agreement — ZephyrAB

DRAFT — NOT YET BINDING.

This is a complete, honest draft written from what the platform actually does.

It has not been reviewed by a lawyer, and a DPA is a contract: it should not

be offered to a customer or published as binding until it has been. Everything

below marked [ARNOLD: …] is a fact only the business can supply.

Last updated 2026-08-19.

1. Parties and roles

Processor: [ARNOLD: legal entity name, registered address, company number.]

Referred to below as "ZephyrAB".

Controller: the customer, being the organisation whose users' mail ZephyrAB

processes.

ZephyrAB acts as a processor on the controller's behalf. For its own

business records — billing, support correspondence, the accounts of the people

who administer a tenant — ZephyrAB is an independent controller, and this

agreement does not cover that processing.

2. Subject matter, duration, nature and purpose

Subject matter. The provision of a hosted mail, calendar and contacts

service.

Duration. For as long as the controller's tenant exists, plus the deletion

and backup-retention periods in §8.

Nature and purpose. Receiving, storing, transmitting, indexing and serving

electronic mail and groupware data so that the controller's users can use it.

3. Types of personal data

Mail is unusually broad here, and saying so is more useful than a short list.

The controller decides what its users send, so **ZephyrAB cannot bound the

content categories** and does not attempt to:

Categories of data subjects: the controller's users, and **any person who

sends mail to or receives mail from them** — who has no relationship with

ZephyrAB and cannot be asked for consent. That is inherent to email and is why

§4's minimisation commitments matter.

4. ZephyrAB's obligations

4.1 Instructions

ZephyrAB processes personal data only on the controller's documented

instructions, of which this agreement and the service configuration are the

whole. ZephyrAB will tell the controller if an instruction appears to infringe

data protection law.

4.2 Confidentiality

Everyone with access is bound by confidentiality. [ARNOLD: confirm that

personnel confidentiality undertakings exist in writing.]

4.3 Security (Article 32)

These are measures the platform actually implements, not aspirations:

• Encryption in transit. TLS on every protocol surface, with implicit-TLS

ports offered in preference to STARTTLS. DANE/TLSA and MTA-STS are published

so that a sending server can require authenticated TLS rather than accept a

downgrade.

• Encryption at rest, optional and per-user. A user may upload an OpenPGP

public key, after which their delivered mail is stored encrypted to it. The

server holds no private key and cannot read that mail back — which also

means body search stops working for that mailbox and is refused with a reason

rather than answered emptily.

• Tenant isolation by construction. Every stored object is keyed by tenant;

there is no query path that spans tenants.

• Authentication. Passwords are stored as argon2id verifiers. Administrative

access is scoped by role and bound to a subject (a tenant or a domain), so an

administrator of one tenant cannot reach another's.

• Malware scanning at message acceptance, on both the primary and secondary

paths.

• Durability. Accepted mail is reconciled to a terminal state by an

independent auditor; the platform is designed so that a message is never

accepted and then lost.

• Backups, with restoration verified on a schedule rather than assumed.
• Logging with an address-redaction mode, and a check in the build that

fails if a secret is written to a log.

**Stated limits, because a security section that lists only strengths is not

useful:** message headers are not encrypted at rest even for opted-in users

(that is PGP/MIME, not a shortcut); an independent penetration test has not yet

been carried out — an internal assessment has, finding no critical or high

issues — and an external test is a condition of general availability.

4.4 Subprocessors

The current list is published at docs/legal/subprocessors.md and maintained

there. ZephyrAB will inform the controller before adding or replacing a

subprocessor, giving the controller an opportunity to object.

The material fact, stated here rather than buried: all processing takes

place on infrastructure in the Philippines, which has no European Commission

adequacy decision. A controller subject to the GDPR needs an Article 46

safeguard for that transfer. [ARNOLD: confirm the SCC position before this

document is offered to any EU controller.]

4.5 Assisting the controller

Data subject rights (Articles 15–22). ZephyrAB provides tooling that

produces a complete export of one account and permanently erases one account:

• Access and portability. zephyr-account-export writes messages as .eml,

calendars as .ics, contacts as .vcf and filters as .sieve — standard

formats another system can import, not a dump of our internal storage. The

export carries a manifest with a checksum for every file, and a verification

mode that re-reads the database and reports anything the export is missing.

• Erasure. zephyr-account-delete removes messages, mailboxes, calendars,

contacts, filters, credentials and the address itself. It is ordered so that

a failure part way through leaves a disabled account rather than an address

that still accepts mail for data that is gone.

Both are exercised end to end by an automated test that proves deletion from

three surfaces independent of the tool that performed it.

Two things erasure does not do, and both are deliberate:

1. Backups still contain the data until they age out of retention. Editing

a backup to remove one person would destroy its integrity as a backup. The

data is inaccessible to the service and is deleted when the backup expires.

1. The message-acceptance ledger is retained. It records that the platform

accepted a message and reconciled it to a terminal state. It carries no

account reference and no content — it is the evidence that the service does

not lose mail. ZephyrAB considers this legitimate retention for the

integrity of the service. [ARNOLD: a lawyer should confirm the lawful basis

and the retention period stated to controllers.]

Breach notification. ZephyrAB will notify the controller without undue delay

after becoming aware of a personal data breach, with the information needed for

the controller's own Article 33 notification. [ARNOLD: commit to a number of

hours. "Without undue delay" is what the regulation says; customers will ask

for 24 or 48.]

4.6 Deletion or return

On termination, at the controller's choice, ZephyrAB will return the

controller's personal data (using the export tooling above) or delete it, and

delete existing copies unless law requires storage. Backups follow §8.

4.7 Audit

ZephyrAB will make available the information needed to demonstrate compliance

with Article 28 and allow for audits by the controller or an auditor it

mandates. [ARNOLD: set notice period, frequency, and who bears cost.]

5. The controller's obligations

The controller warrants that it has a lawful basis for the processing it

instructs, that it has provided any notices its users are owed, and that its

instructions comply with data protection law. **The controller decides what its

users may send**; ZephyrAB has no visibility into whether a given message

contains special-category data and no ability to prevent it.

6. International transfers

See §4.4. [ARNOLD: attach the SCC module and the transfer impact assessment

once they exist.]

7. Retention

8. Liability, term, governing law

[ARNOLD: these are commercial and jurisdictional terms and I have deliberately

not drafted them. They should come from a lawyer alongside the main services

agreement.]

Annex — what ZephyrAB will not do

Recorded because a processor's refusals are as much a part of the arrangement

as its capabilities:

• It will not read a user's mail to train a model. AI features are opt-in per

deployment, a model may label a message but never move one, and a

browser-direct mode exists in which prompts never reach ZephyrAB's servers.

• It will not weaken transport security to deliver a message. A message that

cannot be delivered with the authenticated TLS its recipient's policy demands

is deferred, never downgraded.

• It will not silently discard mail. Every accepted message is reconciled, and

a message the platform cannot accept is refused while the sender still has

it.