Mythos Hardening Control · MRIS 2.0 · Applies to ISO/IEC 27001, TISAX® and IT-Grundschutz

MHC-08 Immutable backups and recovery validation

Ensures backups remain restorable even with compromised admin rights, and that recovery actually works in an emergency instead of existing only on paper.

At a glance

Operational benefit: ensures that after ransomware or data manipulation a clean, unaltered copy exists and that recovery demonstrably works.
Policy affected: backup and recovery policy (part of contingency and continuity management).
Dependencies: no precondition; separate access paths presuppose orderly entitlement management.
Effort drivers: depends on data volume, recovery objectives and the existing backup infrastructure. The actual effort depends on the organization's resources.
Primary metric: success rate of the regular recovery tests from immutable backups.
Standards touched (no claim of fulfilment): ISO/IEC 27002 A.8.13/A.8.14; C5:2026 OPS-06 to OPS-09; DORA Art. 12; NIS2 IR No. 4.1; NIST SP 800-34, SP 1800-11/-25.

Control statement

The organization maintains at least one immutable or network-separated backup copy and verifies regularly, through documented recovery tests, that the data can be restored from it without error. The backup infrastructure is administered through separate administration access. Advanced hardening (Managed level): a dedicated administration and identity plane for the backup infrastructure, together with automated integrity and recovery checks.

Purpose and threat relevance

Modern, AI-supported attacks encrypt or corrupt data and deliberately seek out the backups as well, in order to prevent recovery. An attacker with far-reaching access can encrypt or delete backups reachable online; an immutable or network-separated copy remains unaffected. The protective objective is to be able to fall back at any time on a clean, unaltered data basis after an incident — and to be certain that the recovery actually succeeds.

Effect across frameworks

These are the controls and requirements the MHC acts on. The classification shows how much each control loses its effect under AI-enabled attacks.

Effect across frameworks
Number	Title	Classification / Level
ISO/IEC 27001:2022, Annex A 5 controls
A.5.29	Information security during disruption	partially degraded
A.5.30	ICT readiness for business continuity	robust
A.5.33	Protection of records	partially degraded
A.8.13	Information backup	robust
A.8.14	Redundancy of information processing facilities	robust
TISAX® ISA 2027 1 controls
5.2.8	IT service continuity planning	partially degraded
IT-Grundschutz, MRIS.bd 3 requirements
MRIS.bd.1.A3	Maintaining Immutable Backups with Regular Restore Tests	Basic
MRIS.bd.2.2.A1	Separating the Administration of the Backup System	Basic
MRIS.bd.2.2.A2	Technically Enforcing Immutability	Basic

All 93 controls in the analysis matrix · All 45 controls in the findings matrix · All 23 requirements of the module family

Maturity path

Initial: backups in place; recovery tests annually.
Defined: 3-2-1-1-0 principle implemented, at least one immutable or network-separated copy; separate backup administration access (dedicated admin accounts with phishing-resistant MFA and separate entitlement assignment); documented recovery tests quarterly.
Managed: a dedicated administration and identity plane for the backup infrastructure; automated integrity checking; orchestrated, automated recovery validation; regular adversarial deletion tests; continuous monitoring of immutability.

Measurement and audit evidence

Metric: success rate of the quarterly recovery tests from immutable backups (target: 100%).
Evidence: records of the recovery tests, evidence of immutability (retention and lock settings), separate entitlement assignment for the backup infrastructure, integrity checking reports.
Evidence logic (following ISO/IEC 27001, Clause 9): documented? — policy and test records; responsible? — IT or backup owner; frequency? — quarterly tests, continuous integrity checking; tolerance? — no business-critical data holding without an immutable or separated copy and without a passed recovery test.

Typical mistakes

Backups exist, but they are reachable through the same access as the production systems — an attacker encrypts both.
Backups are created but recovery is never fully tested; when it matters, parts are missing or the process takes too long.
"Immutable" is only configured but not verified; too short a lock period leaves the copy exposed.
The backup does not cover all the data needed (for example configurations or keys), so that a full recovery fails.

Delimitation and residual risk

Delimitation: concerns backup and recovery; continuous availability through redundancy is dealt with by A.8.14, and restart planning by A.5.29/A.5.30.
Residual risk: a network-separated copy is by its nature less current; a very slow or rarely tested recovery can still lead to downtime when it matters.
Effectiveness limit: immutability protects the copy, not the recovery. The retention lock must lie outside the attacker's control plane — its own entitlements, a separate identity, no deletion or shortening right for compromised admin accounts; what is decisive is the regularly tested recovery against a defined RTO, not the mere existence of immutable copies.
ISO/IEC 27002:2022: A.8.13 Information backup; A.8.14 Redundancy of information processing facilities; A.5.29 Information security during disruption; A.5.30 ICT readiness for business continuity; A.5.33 Protection of records.
Framework: C5:2026 OPS-06 to OPS-09; DORA Art. 12; NIS2 IR No. 4.1; NIST SP 800-34 Rev. 1; NIST SP 1800-11 and 1800-25 (data integrity / ransomware recovery, NCCoE); industry practice 3-2-1-1-0.

Implementation in detail

Organizational and technical implementation, implementation examples and the prioritization within the overall programme are described in the Implementation Guide.

Implementation Guide (PDF)Back to the MHC catalog