Immutability: What It Does and Does Not Do #

What Immutability Delivers #

storage, ideally hardware , guarantees:

  • Data cannot be deleted after it is written
  • Data cannot be altered
  • Not even root or admin accounts can do this (hardware )
  • Data persists over long retention periods (10 to 30 years and more)

This is technically strong and covers the integrity requirement found across EU and national rules: Art. 5(1)(f) (integrity and confidentiality), MiFID II record-keeping, and national bookkeeping standards such as the German , which explicitly demands immutability of accounting records.

What Immutability Does NOT Deliver #

does not guarantee:

  • Findability: ​“I have 10 million files. How do I find the invoice from March 2021?”
  • Reproducibility: ​“Can I open the file? With which program? Will the format still be readable in 10 years?”
  • Correctness: ​“The data is immutable, but is it correct? Did someone archive corrupted data, immutably?”
  • Completeness: ​“Are all business transactions in the archive, or did some never arrive?”
  • Process documentation: ​“How was the data captured? Who had access? How was quality checked?”

An auditor cannot work with raw blocks. They need structure, metadata, and documented processes.

The Six Requirements: Where Immutability Fits In #

Audit-proof archiving requires that records are:

  1. Complete: every business transaction captured; implemented through capture controls and duplicate checks. does not cover this.
  2. Correct: the data matches reality; implemented through validation and plausibility checks. does not cover this.
  3. Timely: captured and archived promptly; implemented through timestamps and automated archiving. does not cover this.
  4. Orderly: archived according to a defined, documented procedure; implemented through process documentation. covers this only partially.
  5. Immutable: unalterable after capture. This is the one requirement storage covers, fully.
  6. Available: findable and reproducible throughout the retention period; implemented through indexing, a DMS, and recovery tests. does not cover this.

(requirement 5) is technically the hardest to retrofit, which is why it gets the attention. But an archive that meets requirement 5 and fails the other five is not audit-proof.

The Auditor Perspective: What Actually Gets Checked #

In an audit, four checks are typical:

1. Findability: the auditor requests all invoices from a given month. An audit-proof archive answers with an indexed report in minutes. A bare store answers with millions of unstructured files.

2. Integrity: the auditor asks for proof that records are unchanged since archiving. Hardware answers this directly: write-protected since the recorded timestamp, verifiable.

3. Process: the auditor asks for the process documentation: capture, workflow controls, authorizations, error handling, retention periods, access control, responsibilities. Storage hardware alone has no answer here.

4. Data quality: the auditor asks how correctness is verified. The answer must describe validation before archiving and periodic restore tests, not just storage properties.

A company that can only answer question 2 has immutability. A company that can answer all four has audit-proof archiving.

How Audit-Proof Archiving Uses Immutability #

Audit-proof archiving does not replace ; it builds on it. The architecture has two parts:

The DMS layer (structure and findability):

  • Capture (scanners, interfaces, manual entry)
  • Metadata (date, customer number, amount, processor)
  • Workflow (approval, validation)
  • Indexing for fast retrieval

The archive layer (integrity and retention):

  • Hardware storage (for example Silent Cubes: immutability enforced by the system, redundant storage with erasure coding, designed for very long retention)
  • Retention management per record type
  • Long-term readability (archive formats such as PDF/A)
  • Process documentation covering the whole chain

The DMS delivers structure and findability. delivers immutability. Together they deliver audit-proof archiving.

Common Mistakes #

Mistake 1: ​“ equals audit-proof archiving.” No. is a necessary component, not the whole.

Mistake 2: ​“ equals compliance.” No. Compliance must be demonstrable end to end. is one property.

Mistake 3: ​“We do not need a DMS if we have .” Wrong. Without indexing and process documentation, the archive fails the findability and orderliness requirements.

Mistake 4: ​“Our cloud has object lock, so we are audit-proof.” Not automatically. Object lock is software , the weaker integrity guarantee, and the other five requirements remain untouched.

Frequently Asked Questions #

Can we achieve audit-proof archiving with software ? Possibly, but with weaker guarantees. Software can be bypassed by privileged accounts in many configurations, so the burden of proof shifts to your organizational controls (separation of duties, audit logs). Hardware removes that dependency.

Is compliance the same as audit-proof archiving? No. protects data subjects (lawful basis, purpose limitation, right to erasure). Audit-proof archiving protects evidential integrity. The two interact (retention vs. erasure) but are distinct obligations.

Further Resources #

→ Guide (/en/blog/revisionssicherheit-leitfaden/) → What Is ? (/en/blog/was-ist-revisionssicherheit/) → Storage Fundamentals (/en/blog/worm-speicher-grundlagen/) → DMS and : How They Work Together (/en/blog/dms-worm-zusammenspiel/) → Silent Cubes: Hardware Archive Storage (/en/produkte/silent-cubes/)

Disclaimer

This article was written by our editorial team and edited using AI. It provides a general overview and does not constitute legal advice – we recommend seeking professional advice for your specific situation.