Home · Synthesis · cl-backup

Ransomware-resilient backup architecture

CIS Controls v8.1 ISO 27001 NIST CSF 2.0 PCI DSS RBI CSF SEBI CSCRF RBI ITGRCA IRDAI 2026 MeitY CSP NCIIPC NIS2 NIST 800-53 SEBI Cloud SOC 2

Primary statement

Backup of information, software, and systems shall be designed for ransomware resilience: multiple copies including at least one immutable (WORM / Object Lock) and at least one offline or air-gapped copy; encryption at rest; separation of backup administrative credentials from production; automated execution at a frequency proportionate to criticality; restoration testing quarterly for the most-critical systems; integrity verification before any restoration is acted upon. Generic backup ≠ resilient backup; the cluster ceiling is the resilient specification.

Audit-fatigue payoff

Demonstrating SEBI CSCRF PR.20 + RBI CSF RC.1 backup architecture with quarterly restoration testing satisfies every other framework's backup requirement in this cluster (14 frameworks total). A single evidence pack — strategy document, immutability configuration screen-cap, air-gap copy evidence, credential separation matrix, quarterly restoration test report with success/failure outcomes — replaces 14 separate audit workpapers. The depth of evidence is driven by the strictest framework; the other 13 are subset relationships.

Strictness matrix

Scope

Backup coverage shall include information, software, AND systems — i.e., the data layer, the application layer, and the infrastructure layer. Other frameworks address subsets (NIST PR.DS-11: data only; PCI 9.4.1: cardholder data only; SEBI PR.20: critical systems). The ISO 27001 formulation is the broadest scope and the audit-defensible baseline. Ceiling source: iso27001:A.8.13 Rationale: ISO 27001 A.8.13 uniquely scopes backup to "information, software AND systems" rather than data only. Satisfying this scope satisfies the narrower scopes in other frameworks by superset relationship.

Threshold

Backup obligations are criticality-triggered: Critical and Most-Critical systems receive enhanced controls (more frequent backup, more frequent restoration testing, real-time monitoring of backup health, immutable copies mandatory). Lower-criticality systems may operate with baseline backup. The classification methodology drives the trigger thresholds. Ceiling source: rbi_csf:RBI.ID.3 Rationale: RBI CSF ID.3 is the strictest threshold articulator: it requires a documented criticality classification methodology that itself triggers differential backup controls. Other frameworks state "critical systems" as a flat label; RBI requires the classification methodology to be explicit and Board-approved.

Method

Strict method specification: (1) multiple copies of backup data; (2) at least one immutable copy via WORM storage / S3 Object Lock / equivalent; (3) at least one offline or air-gapped copy; (4) separation of backup administrative credentials from production credentials; (5) encryption at rest of backup data; (6) restoration testing quarterly for critical systems with success/failure outcome documented. Six explicit elements; an architecture missing any one is non-compliant. Ceiling source: sebi_cscrf:CSCRF.PR.20 Rationale: SEBI CSCRF PR.20 enumerates six specific architectural elements; other frameworks each contribute one or two of these elements but not the integrated specification. Satisfying SEBI PR.20 satisfies all six architectural questions at once.

Frequency

Backup execution: weekly minimum for in-scope assets; more frequent (daily or continuous) for critical assets. Restoration testing: quarterly for critical systems per RBI CSF / SEBI CSCRF. These are two distinct cadences: how often the backup runs vs how often you verify it can restore. Ceiling source: cis_controls:CIS.11.2 Rationale: CIS Controls 11.2 sets the strictest backup execution frequency (weekly minimum, more for critical). RBI CSF and SEBI CSCRF set the strictest restoration testing frequency (quarterly for Most-Critical). The audit ceiling is the union: weekly backup execution + quarterly restoration testing for critical systems.

Evidence

Required evidence: (1) backup architecture diagram showing all copies and their locations; (2) backup schedule configuration per system class; (3) restoration test records with explicit success/failure outcomes (not just "tested" attestations); (4) immutability configuration evidence — WORM storage, S3 Object Lock, tape vault, or equivalent cited by name; (5) separation evidence showing different network segments and different credentials between backup infrastructure and production. Ceiling source: rbi_csf:RBI.RC.1 Rationale: RBI CSF RC.1 enumerates the most specific evidence list, citing concrete technology examples (WORM, S3 Object Lock, tape vault) rather than generic descriptors. This level of evidence specificity satisfies the evidence expectations of every other framework in the cluster.

Auditor test pattern

Step 1: Inspect the backup architecture diagram against the SEBI PR.20 six-element specification — multiple copies, immutable, air-gap, credential separation, encryption, restoration testing. Step 2: Sample 3 most-critical systems and trace each to: a current backup, an immutable copy, an offline copy, and a recent restoration test record. Step 3: Verify the immutability configuration cannot be tampered with even by privileged backup administrators (true WORM vs configurable retention). Step 4: Confirm the quarterly restoration test cadence has been honoured for the past 4 quarters; verify the test report documents both success and any partial-failure modes. Step 5: For ransomware resilience, attempt to verify the air-gap copy is actually disconnected (not just labelled offline).

Common findings

Common 2024–26 findings: (1) Backup labelled "immutable" but configuration is modifiable by the backup admin role (not true WORM); (2) Air-gap copy actually mounted writable on the same storage system; (3) Restoration tested at file level only, never at full-application-stack level; (4) Backup admin credentials are the same identity as a production admin (no separation); (5) Cross-border backups to a SaaS region without sectoral approval (RBI data localisation failure); (6) Restoration test report says "test successful" without naming what was restored, to what point-in-time, with what data integrity verification.