GoBD and evidence

What German law actually requires

Business emails are commercial correspondence and, where they relate to a booking, accounting records. Under German law that means:

Retention periods: 6 years for commercial correspondence (§ 257 HGB, § 147 AO) or 8 years for accounting records, 10 years for books and annual financial statements.
GoBD (the German finance ministry’s administrative guidance on proper bookkeeping and record-keeping): records must be complete, correct, timely, orderly, unalterable, traceable, and machine-evaluable, with procedural documentation and a log of any changes. Records must be kept in their original format — an email stays an email, not a printout.
“Unalterable” specifically means: once captured, nobody — including an administrator — can change or delete the content before the retention period ends; deletions after the period ends are themselves logged.
“Timely and complete” means the copy has to be made before a user can change or delete the original. That is why the archive design uses journaling, not a periodic mailbox sync: a sync only sees what is still there when it runs.
GDPR, alongside GoBD: a deletion concept once retention ends, the ability to search by person for a data-subject access request, access restrictions, and a legal hold used only for a documented reason.

How the archive design targets this (once it ships)

Capture: Exchange Online journaling receives a copy of every journaled message before a user can act on it, as the primary path; Graph sync and IMAP sync are supplements, explicitly marked as “captured after the fact” where journaling could not have seen the item first.
Immutability: a running hash chain over every archived item, anchored daily, so any alteration is detectable; on storage that supports it, hardware object-lock (S3 Compliance mode) enforces immutability at the storage layer too. Where the storage target has no object-lock, Osiris says so in the interface rather than implying a guarantee the storage cannot back up.
Retention and legal hold: a policy per tenant (6, 8, 10 years, or unlimited), a legal hold that blocks deletion until explicitly lifted, and a daily deletion run that only removes expired, non-held items and writes what it deleted into the same hash chain.
Evidence: search across message and attachment content, export as EML with a checksummed manifest (readable by any mail client, without Osiris running), and a signed evidence report per tenant covering the retention policy, chain integrity, storage’s object-lock status, and deletion history.
Procedural documentation (Verfahrensdokumentation): generated per tenant from the actual configuration — capture path, storage location, encryption, access rights, retention, deletion procedure, controls — because an archive’s defensibility rests on that document as much as on the data itself.

What Osiris does not claim, and will not claim once archiving ships

Not “GoBD-certified”. There is no such certificate to hold: the GoBD explicitly rules out blanket conformity statements or positive attestations by tax authorities, and responsibility stays with the taxpayer. Osiris will say the archive is built for German GoBD requirements and name the specific measures, not “certified” or “compliant” as an unqualified claim.
Not “revisionssicher” (a marketing term with no legal definition) without immediately explaining what it means in the same sentence: change-detecting (hash chain) and, on object-lock storage, unalterable.
Not a substitute for review by your tax advisor or data protection officer.
No completeness guarantee for IMAP archiving without journaling — it is documented as the best available approximation for providers that do not support journaling, not as equivalent to it.

Where to read more

Backup vs. archive — why these are two different systems, and why neither one deletes anything from your mailbox.
Archiving — the full design and current (in-development) status.