# Procedural documentation (Verfahrensdokumentation): email archiving

**[Company name]**

> Template from restowbackup.com, version of 22 October 2026. A skeleton with headings and fill-in prompts. It is not a filled-in example, it is not legal or tax advice, and it makes no legal statements about your case.

## Notes on use (delete before use)

- The template is generic. Adapt every section to your actual process: strike what does not apply and add what is missing.
- Describe what is actually in place and practised, not what would be desirable. The documentation has to match the process in use.
- Square brackets are placeholders. Replace every placeholder or delete the line. Lines that begin with "To fill in" are prompts and are removed before use.
- The structure follows the parts the GoBD usually name (general description, user documentation, technical system documentation, operating documentation) and lists the internal control system as a part of its own.
- Have the finished version reviewed by your tax advisor and, where personal data is involved, by your data protection officer.
- You may use and adapt the template freely. It comes without any warranty.
- The GoBD are German rules. Keep the German term Verfahrensdokumentation in the title, because that is what an auditor will look for.

## Document header

| Field | Entry |
| --- | --- |
| Company | [Company name] |
| Process | Email archiving |
| System (name, vendor, version) | [System name, vendor, version number] |
| Version of this documentation | [Version number] |
| Date of this version | [DD.MM.YYYY] |
| Valid from | [DD.MM.YYYY] |
| Prepared by | [Name, role] |
| Reviewed by | [Name, role] |
| Approved by | [Name, role] |
| Next scheduled review | [DD.MM.YYYY] |

## 1. General description

### 1.1 Purpose and scope

To fill in: What is the email archive for in your company, and which legal entities, sites, domains and mailboxes does this documentation cover?

- Purpose of the process: [Description]
- Scope (legal entities, sites, domains): [List]
- Date from which the process exists in this form: [Date]

### 1.2 Legal and internal basis

To fill in: Which rules and internal policies do you base the process on? Agree the list with your tax advisor.

- Rules the process rests on: [List]
- Internal policies and instructions: [List, with reference]

### 1.3 Systems involved

To fill in: Which systems create, receive, store or process email?

| System | Role | Vendor or operator | Version | Location |
| --- | --- | --- | --- | --- |
| [Email system] | [Mailboxes, sending and receiving] | [Vendor] | [Version] | [Location] |
| [Email archive] | [Retention] | [Vendor or in-house] | [Version] | [Location] |
| [Further system] | [Role] | [Vendor] | [Version] | [Location] |

### 1.4 What is archived and what is not

To fill in: By which criterion do you decide which emails belong in the archive? Who decided, when, and where is the decision recorded?

- Archived emails (for example commercial letters, vouchers, emails that matter for taxation): [Description]
- Emails that are not archived (for example pure transport messages, newsletters, advertising, spam, private messages): [Description]
- Handling of attachments and of e-invoices: [Description]
- Handling of sent, deleted and internal emails: [Description]
- Decision taken by [Name, role] on [Date], recorded in [Reference]

### 1.5 Retention classes

To fill in: Which classes exist, and how is an email assigned to a class? Fix the periods together with your tax advisor.

| Class | Examples | Retention period | Start of the period | Basis |
| --- | --- | --- | --- | --- |
| [Class 1] | [Examples] | [Duration] | [Rule] | [Reference] |
| [Class 2] | [Examples] | [Duration] | [Rule] | [Reference] |
| [Class 3] | [Examples] | [Duration] | [Rule] | [Reference] |

- Assignment of emails that touch several classes: [Rule]
- Extension of the period while the record can still matter for a tax assessment: [Rule and responsibility]

### 1.6 Roles and responsibilities

| Role | Name or position | Deputy | Tasks |
| --- | --- | --- | --- |
| Person responsible for the process | [Name, role] | [Name] | [Tasks] |
| Business responsibility (for example accounting) | [Name, role] | [Name] | [Tasks] |
| Technical responsibility (IT) | [Name, role] | [Name] | [Tasks] |
| Data protection | [Name, role] | [Name] | [Tasks] |
| Service provider | [Company, contact] | [Name] | [Tasks, contractual basis] |

## 2. User documentation

To fill in: How do users work with the archive?

### 2.1 Who may do what

| Group | Search and read | Export | Restore or retrieve | Change settings |
| --- | --- | --- | --- | --- |
| [Group 1] | [yes or no] | [yes or no] | [yes or no] | [yes or no] |
| [Group 2] | [yes or no] | [yes or no] | [yes or no] | [yes or no] |

### 2.2 Workflows

- Search for and read an archived email: [Steps]
- Export one or several emails (format, procedure, approval): [Steps]
- Handle a request from a tax audit (who, within what time, in which format): [Steps]
- Handle a data subject request under data protection law: [Steps]

### 2.3 What users cannot and may not do

- Change archived emails or delete them before the period ends: [Description of the technical and organisational barrier]
- Report faults and irregularities to: [Contact, channel]

## 3. Technical system documentation

To fill in: How is the system built, and what does it do technically?

### 3.1 Structure and components

- Overview of the architecture (attach a sketch): [Description or annex]
- Components, vendors and versions: [List]
- Interfaces to other systems: [List]
- Program versions in use and how version changes are recorded: [Description]

### 3.2 Capture path

To fill in: How does an email get into the archive, and from when? Answer for each kind of mailbox (for example Microsoft 365, IMAP, Google Workspace) and for each capture way you use. Strike the ways you do not use.

| Kind of mailbox | Capture way | When the copy is made | Mail from before the set-up | Gaps this way leaves |
| --- | --- | --- | --- | --- |
| [Kind, for example Microsoft 365] | [Way, for example journaling; capture from the mailbox through the mail provider's interface; both] | [In transport / shortly after delivery / afterwards] | [Taken over once and marked as captured later / not taken over] | [Description] |
| [Kind, for example IMAP or Google Workspace] | [Way, for example a copy the mail provider forwards; sync from the mailbox over IMAP; both] | [In transport / shortly after delivery / afterwards] | [Taken over once and marked as captured later / not taken over] | [Description] |
| [Mail files] | [Import from files] | [Once, after the fact] | [Not applicable] | [Description] |

The usual ways, and the gaps to describe for each:

- Journaling in the email system, or a copy that the mail provider forwards to the archive: the copy is made in transport, before a user can change or delete the mail. Describe: what happens when the archive cannot be reached (how long the sender retries, where undeliverable reports go), whether blind-copy (BCC) recipients are visible in the copy, and which mail does not travel through the transport path (for example mail imported into a mailbox from outside).
- Capture from the mailbox shortly after delivery (a sync, a change notification): near-time, and not complete. Describe: that a mail moved or deleted between delivery and capture can be missed, what the mail system keeps for deleted mail (a retention policy or hold) and who confirmed that, which folders are read and which are not (for example drafts), and mail that cannot be fetched (for example above a size limit).
- Import from files: afterwards, with the retention period starting at the import, not at the date of the mail.
- The same mail through more than one way: how the archive recognises it (for example Message-ID and content), which capture is kept as the item and where the other captures are recorded.

Further points:

- Time of capture per way (on delivery, after minutes, after hours, once): [Description]
- Behaviour when a capture way fails (retry, queue, alert, who is told): [Description]
- Logging of receipt and archiving: [Description]
- Who may switch a capture way on or off, and how a change is recorded: [Description]

### 3.3 Data formats and conversion

- Format in which emails and attachments are stored: [Description]
- Is anything converted? If so: how, when, and how is the original kept and linked: [Description]
- Handling of e-invoices and other structured attachments: [Description]
- Indexing and metadata (sender, recipients, date, subject, capture path): [Description]

### 3.4 Storage

- Storage location and storage medium: [Description]
- Operator of the storage: [Name or company]
- Separation from the user's mailbox: [Description]
- Backup of the archive (number of copies, locations, rhythm): [Description]
- Behaviour on a system change, migration or decommissioning: [Description]

### 3.5 Encryption and key management

- What is encrypted (transport, storage, backup): [Description]
- Method and key lengths: [Description]
- Who manages the keys, where they are kept, how they are protected: [Description]
- How records stay readable for the whole retention period (loss of a key, change of people or providers): [Description]

### 3.6 Protection against alteration

To fill in: Which measures make sure that an archived email cannot be altered or deleted unnoticed? For each measure, say what it achieves and what it does not.

| Measure | Kind (technical, software, organisational) | What it achieves | What it does not achieve |
| --- | --- | --- | --- |
| [Measure 1] | [Kind] | [Description] | [Description] |
| [Measure 2] | [Kind] | [Description] | [Description] |

- Logging of changes, access and deletions (what, where, for how long it is kept): [Description]

### 3.7 Search, machine evaluability and export

- Search functions and their limits (fields, attachments, language): [Description]
- Export formats and whether they can be read without the archive system: [Description]
- Machine evaluability and data access for a tax audit (inspection, indirect access, data transfer): [Description]

## 4. Operating documentation

To fill in: How is the system run and maintained?

### 4.1 Access rights

- Authorisation concept (roles, groups, granting, withdrawal): [Description]
- Sign-in and authentication: [Description]
- Administrators: who, and how they are supervised: [Description]
- Regular review of the rights (rhythm, responsible people, evidence): [Description]

### 4.2 Retention and deletion

- Retention periods per class and calculation of the end of the period: [Reference to section 1.5]
- Who triggers a deletion, who approves it: [Name, role]
- Deletion procedure (automatic or manual, rhythm, check before deleting): [Description]
- Deletion log (content, retention, location): [Description]
- Check whether a period must not yet end: [Description]
- Reconciliation with the deletion concept under data protection law: [Reference]

### 4.3 Suspending deletion (legal hold)

- Occasions on which deletion is suspended (for example a legal dispute, an ongoing audit): [List]
- Who may suspend, who may lift, with what reason: [Name, role]
- Documentation of suspension and release: [Description]

### 4.4 Operation, monitoring and faults

- Monitoring (availability, storage space, capture errors): [Description]
- Alerting and response times: [Description]
- Procedure for faults and data loss: [Description]

### 4.5 Changes, updates and system changes

- How updates and configuration changes are planned, tested, approved and documented: [Description]
- Which check follows a system change or a major change: [Description]
- Transfer of data when the system or the provider changes: [Description]

### 4.6 Service providers

- Which tasks lie with service providers: [List]
- Contracts and agreements (for example on commissioned processing): [Reference]
- Access of a tax audit to data held by the provider: [Description]

## 5. Internal control system

To fill in: Which controls make sure the process runs as described, and how is the evidence kept?

| Control | What is checked | Rhythm | Carried out by | Evidence (location and retention) |
| --- | --- | --- | --- | --- |
| Completeness of capture | [for example a sample: find emails from the mailbox in the archive] | [Rhythm] | [Name, role] | [Location] |
| Integrity of the archive | [for example a check of the protection measures from section 3.6] | [Rhythm] | [Name, role] | [Location] |
| Restore and retrieval | [for example a test retrieval and a test of the archive backup] | [Rhythm] | [Name, role] | [Location] |
| Access rights | [Review of the rights from section 4.1] | [Rhythm] | [Name, role] | [Location] |
| Deletion runs | [Sample of the deletion logs] | [Rhythm] | [Name, role] | [Location] |
| Match with the documentation | [Comparison of this documentation with the system in use] | [Rhythm and occasions] | [Name, role] | [Location] |

- Checks triggered by an event (for example after a system change): [Description]
- Handling of deviations found: [Description]

## 6. Data protection

To fill in: Refer to your existing documents instead of repeating them here.

- Record of processing activities: [Reference]
- Deletion concept: [Reference]
- Contracts on commissioned processing: [Reference]
- Rules on private messages and on employee representation, where relevant: [Reference]

## 7. Emergency and recovery

- Scenarios (failure of the archive, loss of the storage, compromised credentials): [List]
- Measures and responsibilities per scenario: [Description]
- Recovery objectives, where set: [Description]

## 8. Change history

To fill in: Every version of this documentation is versioned and recorded with date, change, reason and approval. Earlier versions are kept.

| Version | Date | Change | Reason | Edited by | Approved by |
| --- | --- | --- | --- | --- | --- |
| [1.0] | [DD.MM.YYYY] | [First version] | [Introduction of the process] | [Name] | [Name] |
| [1.1] | [DD.MM.YYYY] | [Change] | [Reason] | [Name] | [Name] |

### Program versions in use over time

| Period | System | Version | Remark |
| --- | --- | --- | --- |
| [from to] | [Email system] | [Version] | [Remark] |
| [from to] | [Email archive] | [Version] | [Remark] |

## Annexes

- Annex A: Sketch of the architecture [File]
- Annex B: List of mailboxes and domains in scope [File]
- Annex C: List of permissions [File]
- Annex D: Check logs and deletion logs [Reference]
- Annex E: Contracts with service providers [Reference]