Data processing addendum

This addendum forms part of the terms of service between you (the controller) and Md Shaiyad and Hardil Singh, trading as Posthaste (the processor). It applies whenever we process personal data on your behalf. Where it conflicts with the terms of service, this addendum takes precedence for that processing.

1. Scope of the processing

You decide what goes into a message. Please do not put special category data — health, biometric, political or similar — into transactional email that does not need it; email is not a confidential channel end to end, however well we handle our part.

2. Our obligations

• We process personal data only on your documented instructions. Using the API is an instruction; so is a written request to us.
• If we believe an instruction breaches data protection law, we will tell you.
• Everyone with access is bound by confidentiality obligations.
• We do not use your recipients’ data for our own purposes, and we do not use message content to train anything.

3. Security

We implement appropriate technical and organisational measures, including tenant isolation enforced by database row-level security, encryption at rest of message bodies and of DKIM signing keys, hashing of API secrets, and an append-only, hash-linked delivery record. These are described in detail on the security page, which forms part of this addendum by reference — including the limits of each, which are stated there rather than left to be discovered.

Two of those measures are commitments to your data subjects as much as to you, so they are set out here as terms rather than only as a description:

• Message bodies are encrypted at rest with AES-256-GCM under a key held outside the database. The subject line, sender and recipient addresses and headers are not encrypted, because they are the keys the delivery record is indexed by.
• Staff access to a stored message body is audited and notified. An operator must give a written reason, the reason and their identity are recorded in the same database transaction as the read, and the account owner is emailed the reason verbatim. This cannot be disabled, by us or by you. Mail received at an inbound address belonging to you is stricter still: our operator panel withholds the body outright and has no route that reveals it.

On transit, the honest statement rather than the flattering one: the API is HTTPS only, and outbound mail uses opportunistic TLS — we negotiate STARTTLS with a receiving server whenever it offers it, which is the overwhelming majority of mail, and we deliver in the clear where a receiver offers none, because the alternative is not delivering. What happened on each attempt is recorded in the message’s record. Email is not a confidential channel end to end and no provider can make it one.

4. Sub-processors

You give general authorisation for us to engage sub-processors. The current list, with what each processes and where, is at posthastemail.dev/legal/subprocessors.

We will give at least 30 days’ notice by email before adding or replacing one. If you reasonably object on data protection grounds, tell us within that period and we will work to find an alternative; if we cannot, you may terminate the affected service and receive a refund of prepaid fees for the unused period.

Each sub-processor is bound by terms no less protective than these, and we remain liable for their performance.

5. International transfers

Our processing takes place in the European Union. Where a sub-processor transfers data outside the UK or EEA, that transfer relies on an adequacy decision or on standard contractual clauses, as noted per provider on the sub-processors page.

Separately from any sub-processor: the service is operated from India, so administration, support and the audited access described in section 3 take place there. India has no adequacy decision. Where you are established in the UK or the EEA, that is a restricted transfer, and we will enter into the standard contractual clauses with you on request — email [email protected] and we will sign them. Nothing here obliges you to ask before relying on the rest of this addendum.

6. Assisting you

We will help you, so far as is reasonable and taking account of the nature of the processing, with:

• responding to requests from data subjects — the API exposes the delivery records and suppression entries relating to any address;
• data protection impact assessments and prior consultations; and
• demonstrating compliance with your own obligations.

If a data subject contacts us directly about data we hold on your behalf, we will not respond substantively; we will pass it to you promptly.

7. Personal data breaches

We will notify you without undue delay, and in any event within 48 hours, of becoming aware of a personal data breach affecting your data. The notification will describe what we know, what we are doing, and what we recommend you do — and we will keep sending updates as it develops rather than waiting until we have a complete picture.

8. Deletion and return

Personal data processed on your behalf expires on its own without you asking. Message bodies are deleted 30 days after sending on every plan, including the signed copy of the message as sent; that window is fixed and cannot be extended by agreement. Delivery records follow your plan — 30, 90, 365 or 730 days — and outlive the bodies deliberately, because the record of what happened is what a dispute six months later turns on. Moving to a smaller plan honours the previous, longer window for a further 30 days rather than truncating history the moment a payment changes.

On termination you may export your delivery records through the API for 30 days. After that we delete the personal data processed on your behalf, except where we are required to retain it by law and except for the two cases below.

You do not have to ask us. Deletion is self-service — the account owner requests it from the settings page and confirms with their password and, where two-factor is enabled, a code. It is then scheduled 30 days out and can be cancelled at any point in that window; when it runs, the data is erased in a single step and the owner is emailed to confirm. Writing to [email protected] works too, and lands on the same path.

Two exceptions, both deliberate:

• Suppression entries are retained. Deleting them would mean sending again to addresses that bounced or complained, which harms the very people the record exists to protect. An entry holds the address itself alongside a keyed hash of it — the address is there because the API returns it to you, and a list that could not tell you which address was suppressed would not be usable.
• The operator audit log is permanent. If a member of our staff read one of your message bodies, the record of that — who, when, which message, and the reason they gave — has no deletion path in the database at all. It is what makes section 3 more than a sentence, and the price is that the record of a read outlives the message that was read.

Backups are the other honest caveat. The database is dumped nightly and dumps are kept for fourteen days, so anything deleted is gone from the live system at once and gone from the backups as those roll off.

9. Audit

We will make available the information reasonably needed to demonstrate compliance with this addendum, and will contribute to audits carried out by you or an auditor you appoint, on reasonable notice, no more than once a year unless a supervisory authority requires otherwise or there has been a breach.

We hold no certification — not SOC 2, not ISO 27001 — and no third party has audited us, so there is no report we can offer you in place of the audit right above. That right is therefore a real one rather than a formality we expect to buy our way out of, and nothing on this site will suggest a certification we do not have.

10. Signing this

Accepting the terms of service accepts this addendum, and no signature is needed. If your procurement process requires a countersigned copy, email [email protected] and we will sign one.