Data processing agreement

This agreement is the Article 28 contract for customers who are themselves a controller — a company, a charity, a sole trader — whose Pidgeon account holds personal data about other people. It supplements the terms of service and does not replace them.

If you use Pidgeon for your own personal correspondence you do not need this document. The GDPR does not reach purely personal or household activity, and the privacy policy already describes everything we do.

1. How this takes effect

It applies automatically, with no signature, from the moment you use the service for personal data for which you are a controller. If your procurement process needs a countersigned copy on our paper or yours, write to legal@pidgeon.ai and you will get one.

In it, Customer means you, the controller. Processor, we and us mean PCN Labs OÜ, registry code 17037148, Tornimäe tn 5, 10145 Tallinn, Estonia.

GDPR means Regulation (EU) 2016/679, together with the UK GDPR and the UK Data Protection Act 2018 where the processing is subject to them. Controller, processor, personal data, processing, data subject, personal data breach and supervisory authority carry their GDPR meanings.

2. Roles, and what is being processed

Customer is the controller. We are the processor. Where Customer is itself a processor for someone else, we are a subprocessor and this agreement is read accordingly.

The subject matter, duration, nature and purpose of the processing, the categories of personal data and of data subjects are set out in Annex I.

For Customer’s own account data — who signed up, who was invited, what was billed — we are a controller in our own right, and the privacy policy governs that processing rather than this agreement.

3. Our instructions

We process personal data only on Customer’s documented instructions, including on transfers, unless EU or Member State law requires otherwise — in which case we will tell Customer before processing, unless that law forbids it on important grounds of public interest.

Customer’s instructions are: the terms of service, this agreement, the settings Customer configures, and the API calls Customer makes. Using the product is instructing us. Anything beyond that needs to be agreed in writing, and we may charge for it where it is not something the service does already.

We will tell Customer if, in our opinion, an instruction infringes the GDPR. We will not decide the purposes of the processing, and we will not use the personal data for our own purposes — in particular, we will not use the contents of Customer’s mail to train a model, ours or anyone else’s, and we will not sell it or analyse it for advertising.

The one processing we perform without a specific instruction is what running a mail service requires and what §6 of the acceptable use policy describes: spam classification, delivery, indexing for search, and the anti-abuse measures without which the service could not be provided to anyone. Those are part of the service, not a separate purpose.

4. Confidentiality

Everyone we authorise to process personal data is bound by an obligation of confidentiality — by contract of employment or by written undertaking — and access is limited to those who need it to provide, secure or support the service.

5. Security

We implement the technical and organisational measures in Annex II, taking account of the state of the art, the cost of implementation, and the nature, scope, context and purposes of the processing, as required by Article 32.

Those measures may change over time. They will not fall below the standard in Annex II, and Annex II is updated when what we do changes.

6. Subprocessors

Customer gives general authorisation for us to engage subprocessors. The current list, with what each does and where, is published at /legal/subprocessors, which forms Annex III.

We will give at least 30 days’ notice before adding a subprocessor or materially changing what one does, by updating that page and its version date. Customer may subscribe to be told directly by writing to privacy@pidgeon.ai.

Customer may object on reasonable, documented data-protection grounds within those 30 days. We will then work with Customer to find a solution; if none is workable, Customer may terminate the affected part of the service without penalty and be refunded the unused part of anything prepaid.

An emergency replacement — a provider failing, or being removed for a security reason — may happen with shorter notice. We will say so, and say why, as soon as we can.

We impose data protection obligations on each subprocessor that are no less protective than these, and we remain fully liable to Customer for their performance.

7. Helping with data subject requests

Taking into account the nature of the processing, we will assist Customer by appropriate technical and organisational measures, so far as possible, in responding to requests to exercise rights under Chapter III of the GDPR.

In practice, most of it Customer can do without us: the application and the API let Customer read, search, export and delete any message, address or mailbox in the account, and IMAP and SMTP are on every plan so a standard mail client can take a complete copy. Where a request needs something the product does not do, write to privacy@pidgeon.ai.

If a data subject contacts us directly about data we process for Customer, we will not respond substantively — we will tell them to contact Customer, and tell Customer promptly.

8. Helping with Articles 32 to 36

We will assist Customer in meeting its obligations on security of processing, breach notification, data protection impact assessments and prior consultation, taking into account the nature of the processing and the information available to us. The privacy policy, the subprocessor list and Annex II are written so that an impact assessment can mostly be completed from published material.

9. Personal data breach

We will notify Customer without undue delay after becoming aware of a personal data breach affecting personal data we process for Customer, and in any event in time for Customer to meet its own 72-hour obligation under Article 33.

The notification will describe the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, the measures taken or proposed, and a contact point — to the extent we know them, and with further detail as it becomes available. We will not wait for a complete picture before telling Customer something is wrong.

We will not notify a supervisory authority or data subjects on Customer’s behalf unless Customer asks us to or the law requires us to.

10. Deletion and return

Deletion is in Customer’s hands throughout: deleting a message deletes it, and deleting a raw original with it.

On termination of the service, Customer chooses whether we delete or return the personal data we process for Customer. If Customer says nothing, we delete it. Before deleting we give Customer a reasonable period to export — by IMAP, by the API or by the mailbox download — and §12 of the terms sets that period out.

Two honest exceptions. Encrypted backups taken before a deletion retain the data until they rotate, and we will not restore one to recover deleted data. And we keep what EU or Member State law requires us to keep, for as long as it requires — billing records being the usual case — and we keep it protected and process it for nothing else.

11. Audits and information

We will make available to Customer the information necessary to demonstrate compliance with Article 28 and allow for and contribute to audits, including inspections, conducted by Customer or an auditor it mandates.

In the first instance this is satisfied by the published material — this agreement, the privacy policy, the subprocessor list, Annex II, and the security documentation published with the source — and by answering Customer’s written questions.

Where that is genuinely not enough, Customer may audit once in any twelve-month period, on 30 days’ written notice, during business hours, without unreasonably disrupting the service, subject to confidentiality, and at Customer’s cost unless the audit finds a material breach by us. An audit may not extend to another customer’s data or to our subprocessors’ own premises, where we will instead provide what those subprocessors make available to us. A supervisory authority exercising its own powers is not limited by any of this.

12. International transfers

Where we transfer personal data outside the EEA, we do so only on a lawful basis under Chapter V — an adequacy decision, the European Commission’s Standard Contractual Clauses, or another valid mechanism.

Where the Standard Contractual Clauses apply, Module Two (controller to processor) is incorporated into this agreement by reference, or Module Three (processor to processor) where Customer is itself a processor. The optional docking clause applies; the clause 17 governing law and the clause 18 forum are Estonia; the clause 9 option is general written authorisation with the notice period in §6; and Annexes I, II and III of this agreement populate Annexes I, II and III of the Clauses. Where the processing is subject to the UK GDPR, the UK International Data Transfer Addendum applies to those Clauses.

The transfers that exist today are named in §4 of the subprocessor list: the United Kingdom, which has an adequacy decision, and the United States. The mail itself is stored in Ireland.

13. Liability, precedence and term

Each party’s liability under this agreement is subject to the limitations in §16 of the terms of service, to the extent the law allows. Nothing here limits a data subject’s rights or a supervisory authority’s powers.

Order of precedence, if two documents conflict on the processing of personal data: the Standard Contractual Clauses, then this agreement, then the terms of service, then everything else.

This agreement runs for as long as we process personal data for Customer, and the obligations that by their nature should survive it — confidentiality, deletion, transfers — do.

---

Annex I — the processing

A. The parties

Data exporter — Customer, the controller, whose identity and contact details are those held on the Pidgeon account and, where the Standard Contractual Clauses apply, those given in Customer’s signed copy. Activities: sending and receiving email in the course of Customer’s business.

Data importer — PCN Labs OÜ, registry code 17037148, Tornimäe tn 5, 10145 Tallinn, Estonia. Contact: privacy@pidgeon.ai. Activities: providing a hosted email service, the processor.

B. Description of the processing

C. Competent supervisory authority

The Estonian Data Protection Inspectorate (Andmekaitse Inspektsioon), Tatari 39, 10134 Tallinn, Estonia — as the authority of the Member State in which the data importer is established.

---

Annex II — technical and organisational measures

These are the measures in place today. They are described in more detail, with the reasoning, in the security documentation published with the product’s source.

Access control and authorisation. Authorisation is enforced as a database join rather than as a check that could be forgotten: every service function resolves a resource joined to its owner, filtered by the authenticated account, in one query. Row-level security is enforced in the database underneath that. Staff access to production is limited to those who need it, and administrative credentials are separate from application ones.

Authentication. Sign-in is a one-time emailed link — there is no password stored, so there is none to leak, phish or reuse. Mail clients use app passwords, stored hashed, scoped to that use and individually revocable. API keys are stored hashed and displayed once.

Encryption. TLS in transit, including between mail servers where the other side supports it, with MTA-STS published so that a sending server knows to require it. Encryption at rest for the database and for object storage. Mail is not end-to-end encrypted, and §7 of the privacy policy explains why and what follows from it.

Pseudonymisation. Sender addresses, recipient addresses and message fingerprints used by the anti-abuse model are stored as keyed hashes rather than as themselves.

Secrets. Held write-only in the deployment platform, not readable back. Cloud access uses short-lived identity-federated credentials in preference to long-lived keys. A production deployment refuses to start with a development default in a security-relevant setting.

Logging and accountability. An immutable event log of everything consequential — deliveries, response codes, sign-ins, hand-offs, domain verifications — which the database refuses to delete from inside the retention window.

Resilience and availability. Mail is queued and retried rather than dropped in both directions. Webhook deliveries are retried on a schedule with a dead-letter state and replay. Managed, encrypted backups with point-in-time recovery — and a restore from one has not yet been rehearsed, which is recorded as open work rather than left to be assumed from the word “backups”.

Erasure. Deleting a message erases its raw original. Retention windows are enforced by scheduled jobs, by object-store lifecycle rules, and by database constraints that refuse an early or a late deletion, so that the schedule does not depend on the application being correct.

Abuse and integrity. Per-account sending limits, trust tiers, rate limiting, and spam classification, with every verdict recorded.

Third-party minimisation. Error reporting strips cookies, headers, email addresses, tokens and message content before sending. Analytics is server-side only, against an opaque identifier, with geolocation disabled, on EU infrastructure. No session recording and no autocapture is installed anywhere in the product.

Application security. A Content-Security-Policy on every response, mail bodies isolated when rendered, source maps not published, and dependency and static analysis in continuous integration.

Organisational. Written security documentation maintained alongside the code and updated in the same change; changes reviewed before they ship; confidentiality obligations on everyone with access; a documented process for handling a reported vulnerability at security@pidgeon.ai.

---

Annex III — subprocessors

The current list is published at /legal/subprocessors and forms part of this agreement. It names each subprocessor, the entity and country, what it does, where it runs, and which transfers leave the EEA.