TrueNAS for Tax Advisors: GoBD-Compliant Data Retention

Tax advisory firms are, in a data protection sense, one of the most conservative industries: client files fall under professional secrecy (§ 203 of the German Criminal Code), accounting data falls under the German GoBD rules and GDPR, and in case of damage the firm is personally liable. A storage architecture that is “good enough” in the mid-market is often too little here.

We are frequently asked at DATAZONE whether TrueNAS alone is “GoBD compliant”. Short answer: no — because GoBD compliance is not a storage feature, it is a combination of process, software, and storage. Longer answer: TrueNAS provides several technical building blocks that, together with proper accounting software and a documented process, deliver what a tax audit expects.

Note for international readers: GoBD (“Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern…”) is the German regulatory framework for electronic bookkeeping. The principles described here translate cleanly to comparable regimes (SOX, HMRC’s Making Tax Digital, FINMA-RS 2018/3 in Switzerland, etc.) — terminology differs, structure is similar.

What GoBD Requires — Very Briefly

The German “Principles for the Proper Maintenance and Retention of Books, Records, and Documents in Electronic Form” are the Federal Ministry of Finance circular that regulates electronic bookkeeping. Four core requirements matter for the storage architecture:

1. Immutability — once posted, accounting records may not be changed without the change being logged
2. Completeness — nothing may be lost
3. Traceability / verifiability — an audit must be able to read and review the data
4. Retention period of 10 years for posting documents, annual statements, inventories, and comparable records

From this we derive concrete storage-side needs: WORM characteristic (write once, read many) or immutability of stored records, integrity-assured retention over ten years, recoverability in case of tax-authority access.

Important: GoBD compliance is never a property of the storage system alone. It is a property of the overall system of accounting software (DATEV, Lexware, Sage etc.), archival solution (DATEV-DMS, ELO, d.velop documents etc.), and storage. An auditor tests whether posting data is immutable after being finalised — not how many snapshots ZFS holds.

What TrueNAS Contributes Technically

1. ZFS Snapshots — Read-Only by Default

ZFS snapshots are not writable after creation. A snapshot of a dataset from 31 Dec 2026 represents the state at that moment. Even an admin with full rights cannot modify the snapshot — they can only delete it. If deletion is administratively restricted (e.g., via dedicated snapshot admin, audit logging, and four-eyes principle), the snapshot remains in the shape it was created in.

Concretely for an accounting dataset:

tank/datev
  ├── @auto-daily-2026-12-31 (read-only, 10-year hold)
  ├── @auto-daily-2026-12-30
  └── ...

With a snapshot hold on the year-end snapshot, deletion is blocked even by admin commands while the hold persists.

2. ZFS Integrity (Checksums + Scrub)

Each data block in ZFS has a SHA-256 or Fletcher checksum. On every read, ZFS verifies that the block still matches the checksum. On mirror or RAIDZ pools, ZFS automatically repairs detected bit rot from redundancy.

A periodic scrub (TrueNAS default: monthly or biweekly) reads the entire pool and verifies every block. This ensures no “silent” data loss accumulates over ten years of storage, only to surface on access.

For tax-advisor datasets we recommend weekly scrubs and monthly reports to IT staff.

3. Replication to a Second System

A second copy on a second TrueNAS system is mandatory. TrueNAS offers native ZFS replication via zfs send/recv, which:

• runs incrementally (after initial sync, only block deltas)
• transmits encrypted (over SSH)
• preserves the read-only nature of snapshots at the destination

Classic setup: primary system in the firm’s server room, secondary system in a colleague’s data centre or at a co-location provider. Replication runs daily, snapshot retention at the destination is noticeably longer than at the source.

4. Access Audits

TrueNAS writes access events to the audit log — who logged in, which datasets were changed, which API calls were executed. For GoBD purposes this is relevant because manipulations to the snapshot inventory (deletion, hold removal) are logged. In an audit you can prove no whitewashing of history took place.

Audit logs should themselves be sent to an external log server (Syslog, Wazuh, Graylog) — otherwise an admin could erase their own tracks.

5. SMB With ACL Separation

In a tax firm, client files are typically shared via SMB. TrueNAS fully supports Windows ACLs — meaning: concrete access rights can be set per client file for defined staff. Not GoBD-specific, but professional-secrecy-relevant (§ 203 of the German Criminal Code).

What TrueNAS Does Not Cover

So it is clear what a complementary solution must provide:

Requirement	TrueNAS alone?	What is additionally needed
Accounting record finalisation	No	DATEV / Lexware / Sage — record finalisation in the accounting system
Document archive with retention lifecycle	No	DMS like DATEV-DMS, ELO, d.velop documents
Procedural documentation (mandatory!)	No	Written documentation, regularly updated
Z3 data-access interface for auditors	No	Accounting / DMS export — TrueNAS only delivers the file
Firm’s authorisation concept	Partially	Organisational doc + technical ACLs on TrueNAS

Storage is the retention layer beneath the GoBD stack. What sits above it — accounting and archival — determines whether “GoBD compliant” is ticked.

Architecture Proposal for a Mid-Sized Practice

For a practice with 5–25 staff, its own server room, and connectivity to a backup data centre, we propose the following architecture:

Primary system: TrueNAS Mini X+ or R series

• Two pools: tank-clients (client files, SMB share) and tank-accounting (DATEV database, iSCSI to the DATEV server)
• Snapshot plan on tank-accounting: 4-hourly (3 days), daily (30 days), weekly (12 weeks), monthly (12 months), yearly (11 years, with hold)
• Snapshot plan on tank-clients: daily (90 days), monthly (60 months), yearly (11 years, with hold)
• Weekly scrub with mail report

Replication: TrueNAS Mini X+ at second site

• Over VPN / WireGuard to backup site
• Replication every 4 hours, read-only snapshots at destination
• Different admin credentials from the primary system (important: a compromised firm admin must not be able to destroy the replica)

Document archive: ELO / DATEV-DMS / d.velop documents

• Documents land in the DMS directly from the scan workflow
• DMS writes encrypted WORM containers onto TrueNAS
• TrueNAS stores only DMS packages — the retention lifecycle is managed in the DMS

Backup: Proxmox Backup Server + tape or object-lock cloud

• Daily image backups of the DATEV VM
• Weekly backup verify
• Monthly tape ejection for bank-vault storage (classic “air-gap” variant) or replication into a cloud tier with object lock

This architecture separates three life phases of the data:

1. Active processing — live pool on TrueNAS, high IO performance
2. Inactive retention — snapshots with hold, long-term read-only inventory
3. Backup / recovery — image backups via PBS, additionally external

Procedural Documentation: The Forgotten Mandatory Document

The procedural documentation has been explicitly required since GoBD 2014. It describes how bookkeeping runs organisationally and technically — with enough detail that a knowledgeable third party can reproduce the bookkeeping. Content includes:

• General description of accounting software and hardware used
• User documentation with permissions, access concept
• Technical doc of server and storage architecture — TrueNAS appears here
• Operational doc — backups, recovery, contingency plan
• Data security doc — encryption, MFA, snapshots, archival

In tax audits, the procedural documentation is regularly inspected first, long before actual posting data is examined. Proper procedural doc is therefore not optional decoration — it is the filter through which the audit passes.

GDPR Aspects: Data Processing and Encryption

Client data is almost always personal data in the GDPR sense. This yields requirements that TrueNAS partly fulfils directly:

• Encryption at rest — TrueNAS supports dataset encryption (AES-256-GCM), keys can be HSM-held
• Encryption in transit — SMB 3.1.1 encrypts automatically, iSCSI over IPsec or dedicated VLANs
• Access logging — see above
• Deletion concept on client end — via dataset structure (“one dataset per client”) cleanly enforced organisationally

For outsourcing to cloud (e.g., backup to AWS S3 or Hetzner Object Storage), a data processing agreement with the cloud provider is required. For tax-advisor firms we recommend EU-based providers — legally clean (Schrems-II compliant) and with applicable standard contractual clauses.

What Tax Advisors Typically Buy at DATAZONE

From concrete firm projects of the last two years, the most common setups:

Firm size	Primary TrueNAS	Replication	Backup
1–10 staff	Mini X+ (8–16 TB)	Mini X+ at second site	PBS + tape (LTO-8)
10–25 staff	R20 (24–48 TB)	R20 at second site	PBS + tape + object-lock cloud
25–50 staff	H10 or R40	R40 in backup DC	PBS cluster + tape + cloud
>50 staff	Individual consulting	Individual consulting	Individual consulting

We do model selection live in the TrueNAS Configurator — per firm with bay layout, RAID topology, and capacity calculation.

Related DATAZONE Articles

• TrueNAS Configurator: configure storage live
• TrueNAS data security against ransomware
• Snapshots and replication explained
• Backup Test Day

Conclusion

TrueNAS alone does not make a tax firm GoBD compliant — that’s as nonsensical as saying a DATEV server alone makes it GoBD compliant. But TrueNAS delivers the storage layer that technically underpins GoBD requirements realistically: immutability via read-only snapshots, integrity via ZFS checksums, recoverability via replication, retention security via snapshot holds.

What additionally has to be in place — accounting with finalisation, DMS with WORM characteristic, procedural documentation, GDPR data-processing agreements — belongs in any proper tax-firm IT project. When these four pieces come together, a firm is well prepared for a tax audit — and for an insurance enquiry after a security incident as well.

Sources

• Federal Ministry of Finance: GoBD circular of 11 March 2024
• Federal Chamber of Tax Advisors: notes on procedural documentation
• DATEV: GoBD-compliant document management
• TrueNAS snapshot hold documentation