Keep what you must. Delete what you should. Prove both.

Archiving and retention under the GDPR

The GDPR does not set retention periods for email. What it sets is a principle — storage limitation, in Article 5(1)(e) — requiring that personal data be kept in an identifiable form no longer than is necessary for the purposes it was collected for. Article 5(2) then makes you responsible for demonstrating that you comply. Those two obligations, taken together, are what make "we keep everything forever, just in case" an untenable position rather than merely an expensive one.

The practical consequence is that a retention schedule has to be built from purposes, not from mailboxes. We work with clients to classify what actually travels through their mail estate and to attach a period, a justification and a disposition action to each class.

The periods above are illustrative. The point is the structure: a class, a stated reason, a period that follows from the reason, and an action at the end. A schedule without the stated reason cannot be defended, and a schedule without the action at the end is a wish.

Journal capture, not mailbox copying

We archive by journaling — capturing messages at the transport layer as they are sent and received, before a user can act on them. The alternative, periodically copying mailbox contents, produces an archive that reflects what users chose to keep rather than what actually happened. For anything with evidential value that distinction is decisive.

Deletion has to be real

Disposition that removes an item from the archive index while leaving it recoverable from backups has not deleted anything. We design retention so that backup expiry is part of the schedule rather than an unexamined exception, and we document the maximum interval between logical disposition and the last copy ageing out — because that interval is what you will be asked about.

Data subject rights against an archive

An archive that cannot be searched by data subject cannot serve an access request. We index for subject-oriented retrieval from the outset, and we distinguish clearly between the parts of an archive that can be erased on request and the parts retained under a legal obligation, where erasure may lawfully be refused. Both answers need to be producible on demand, with a record of which was given and why.

eIDAS-aware messaging

Ordinary email carries almost no evidential weight on its own. Where a business process needs proof that a message was sent, received, and unaltered, the relevant European framework is eIDAS — Regulation (EU) No 910/2014, as amended — and specifically its treatment of electronic registered delivery services, electronic seals and electronic time stamps.

The design work that "eIDAS-aware" actually amounts to:

• Routing that preserves integrity. Transport paths that do not rewrite, re-encode or re-sign messages carrying qualified seals, since any such modification invalidates the signature and with it the presumption it was supposed to support.
• Segregating registered delivery traffic. Correspondence that must travel through a qualified electronic registered delivery service is routed to it deliberately, not left to arrive by ordinary SMTP and be reconstructed afterwards.
• Archive integrity. Archived items are stored with content addressing and a tamper-evident audit trail, so that alteration after ingestion is detectable. Where a stronger guarantee is required, we integrate qualified time stamps from a supervised provider rather than asserting our own.
• Retaining the evidence, not just the message. Delivery receipts, transport logs and authentication results are archived alongside the message. A message without its delivery evidence answers "what was said" but not "what was received", and the second question is usually the one in dispute.

Data residency in the EU

Every service we operate stores customer content within the European Union. Residency is a contractual commitment in our engagement terms, not a configuration default that can drift.

We publish a subprocessor register listing every third party that may process customer content, its role, and the country of processing. Customers are notified in advance of additions, with a defined window to object. The register is available on request during scoping — before you are asked to commit to anything.

Where a customer's own configuration requires an onward transfer outside the EEA — a filtering service, a directory, an integration — we say so explicitly, document the transfer mechanism, and will not implement it silently.

Data processing agreements

For the services described on this site, our customer is the controller and Talvara acts as a processor. We provide a data processing agreement meeting the requirements of Article 28 as standard, executed before any customer content is processed.

• Subject matter, duration, nature and purpose of processing, and the categories of data and data subjects.
• Processing on documented instructions only, with an obligation to notify if an instruction appears to infringe applicable law.
• Confidentiality undertakings from every person authorised to process the data.
• Technical and organisational measures under Article 32, described specifically rather than by reference to a generic list.
• Subprocessor terms with prior notice and a right to object.
• Assistance with data subject rights requests and with Articles 32 to 36, including breach notification.
• Deletion or return of customer content at the end of the engagement, at the customer's election, with written confirmation.
• Audit and information rights — see below.

We accept customer paper. If your legal team has a preferred DPA template, we would rather negotiate against it than insist on ours; in our experience that shortens procurement more than any other single concession.

Audit support

Being audited is a normal part of operating regulated or contractually constrained infrastructure, and the work is much cheaper when the evidence already exists.

We hold no certification we have not earned, and we would rather say so plainly than imply coverage we do not have. Where a customer requires a specific certification from their supply chain, we will tell you honestly whether we hold it, whether it is on our roadmap, and what compensating evidence we can offer in the meantime.

Incident handling

Our engagement terms commit us to notifying the customer without undue delay after becoming aware of a personal data breach affecting their content, with enough information for the customer to meet their own notification obligations within the statutory period. Notification to a supervisory authority is the controller's decision and the controller's action; our job is to make sure they have the facts in time to take it, and support for it afterwards.