Your Backup Is Not Your Recovery

RBI's Master Directions on Cyber Resilience now assume intrusions will happen. The procurement memo most banks signed in 2022 was for backups. The 2026 question is restore.

In July 2024, the Reserve Bank of India issued the Master Directions on Cyber Resilience and Digital Payment Security Controls. The directions did not arrive in isolation. They arrived after two years of measurable ransomware impact on Indian financial services, with 65 percent of affected Indian organisations paying the ransom and average payouts reaching $1.35 million.

The structural framing of the Master Directions matters more than the line items.

Backup is not recovery.

RBI's current model accepts that intrusions will occur. The regulatory expectation is no longer "prevent the attack." It is "detect, respond, and recover with a measurable RPO and RTO." For the Indian BFSI CIO whose 2022 procurement decision picked a backup platform on price-per-TB, the 2026 procurement question is different. The procurement question is whether the backup is restorable, under attack, within the regulator's expected window, with the auditor reading the runbook.

Most Indian BFSI buyers have not yet re-procured against that question.

But first, some catch-up on infra this week.

For thirty years the backup discipline rested on three numbers.

Three copies of data. Two different media types. One offsite copy. Most Indian enterprise backup contracts written before 2023 were structured around that rule, with vendor RFPs scored on price-per-TB, replication frequency, and offsite-copy verification cadence.

The rule worked while backup repositories sat at the edge of the threat model rather than at the centre.

That changed in 2023-2024. Modern ransomware operators stopped treating backups as an inconvenience and started treating them as the primary target. The attack pattern is now: gain a foothold in production, wait, locate the backup admin credentials, compromise the backup management plane, delete or corrupt the backup repositories first, then encrypt production. The negotiation phase begins with the victim aware that even a full restore from backups will not return the data.

The 3-2-1 rule does not anticipate this. The rule assumes that an offsite copy is safe because it is offsite. The modern attacker does not need to be physically anywhere; they need to be in the backup management plane.

The 3-2-1-1-0 rule is the modern extension that addresses this gap.

The "+1" adds an immutable or air-gapped copy. Immutable means the backup data cannot be overwritten or deleted within a defined retention window, regardless of the credentials of whoever attempts it. Air-gapped means the copy is logically (or physically) isolated from the backup management plane, requiring an out-of-band operation to access. Tape, cold storage vaults, and immutable cloud backup with object-lock all qualify. The threat model: the attacker has compromised your backup admin credentials; the immutable or air-gapped copy is still safe.

The "+0" adds zero unverified restores. A backup that runs successfully but fails on restore is worse than no backup, because it provides false confidence. Modern backup platforms ship with automated verification (sample restore, integrity check, application-aware validation). Without enabling and monitoring that verification, the operator does not actually know whether the backup is restorable until the night they need it. The night they need it is the wrong night to find out.

The plus-zero is the test.

For the Indian BFSI CIO working backward from the RBI Master Directions:

✔ Document every backup tier and the threat model it defends against. Production-to-replica, replica-to-archival, archival-to-immutable, immutable-to-air-gap.

✔ Map every backup credential and audit who can modify retention policy. The compromised admin is the threat model.

✔ Enable automated restore verification across every protected workload class, not just the easy-to-test virtual machines.

✔ Test the quarterly DR drill against a ransomware scenario that includes backup-management-plane compromise, not just a primary-site failure.

The four bullets above are the floor. The vendor's marketing slide will lead with speed-of-recovery numbers. The auditor will read the documentation behind the bullets.

Three vendors dominate the Indian BFSI backup shortlist in 2026. Each is selling a different architectural commitment.

Immutable by default beats opt-in.

Rubrik is the immutable-by-default option. Every backup written to the platform is immutable from the moment of creation. Rubrik's proprietary Atlas file system stores backup data in an append-only format. Data cannot be modified, encrypted, or deleted by attackers or rogue insiders within the retention window. Combined with Rubrik's Zero Trust architectural commitment around the management plane, the platform is consistently cited as the strongest pure-ransomware-recovery option. Best fit for the Indian BFSI buyer whose threat model leads with "what if the backup admin is the attacker."

Veeam is the software-only, hardware-agnostic flexible enterprise option. The platform runs natively on Linux as of v13, decoupling the buyer from a single hardware vendor. Strong on integration breadth (cloud, hyperscaler-native, on-prem, hybrid). Immutable is available but tends to be configured rather than default. Best fit for the Indian buyer who values vendor-independence on storage and platform layers, and whose operational team can run the immutability discipline without it being a default-on feature.

Cohesity is the instant-mass-restore option. The platform's distinguishing feature is Instant Mass Restore, recovering hundreds of virtual machines instantly through differential and incremental engines that handle scale well. Strong immutable backup and ransomware protection. Best fit for the Indian buyer running a large virtualised estate where the RTO target is measured against hundreds of VMs at once, not single workloads.

The three-vendor read-out:

👉 Rubrik: immutable by default, Zero Trust management plane, strongest pure ransomware recovery.

👉 Veeam: software-only, hardware-agnostic, flexible across cloud and on-prem.

👉 Cohesity: instant mass restore, large virtualised estate, recovery speed at scale.

For most Indian BFSI buyers, the procurement question is rarely "which vendor is best." It is "which vendor's architectural commitment aligns with our threat model and our existing virtualisation, storage, and cloud posture." The wrong RFP scores all three on a single feature matrix and picks the lowest-cost cell. The right RFP defines the threat model first, then evaluates each vendor against that frame.

Indian domestic alternatives sit alongside the three globals. TCS, Wipro, Infosys, and HCL run integrated backup-as-a-service contracts for BFSI clients, often with one of the three vendors above as the underlying technology. eSec Forte and Microland run regional managed-services offerings. CtrlS, Yotta, and Sify run hosted-DR offerings for BFSI buyers looking to consolidate the backup and the DR-site contract under a single Indian-resident vendor. For an Indian buyer wanting operational ownership on the Indian side and detection-platform depth on the global side, the hybrid model is increasingly common in 2026, with the Indian SI as the contract-holder and the global vendor as the underlying platform.

The procurement-side caveat worth naming: the hybrid model works only if the Indian SI has demonstrated operational capability on the global platform across at least one comparable BFSI engagement. The SI marketing slide will claim coverage; the procurement memo needs the reference customer who has actually run a quarterly DR drill on the proposed architecture and can document the result.

For most of the last decade, backup compliance in Indian BFSI was a checklist item handled by the infrastructure team and signed off by the audit committee once a year.

That arrangement is finishing.

The RBI Master Directions on Cyber Resilience and Digital Payment Security Controls, issued July 2024, restructured the operational expectation. The substance reads as five points the Indian BFSI CIO should treat as the procurement frame, not as advisory.

✔ Geographically distributed data centres. The single-DC backup posture is no longer compliant for any meaningful workload tier.

✔ Automatic failover mechanisms. Manual failover dependent on a human decision under stress is no longer the expected operational model.

✔ Quarterly disaster-recovery drills. The annual paper drill has been retired. The drill must be operational, tested, and documented every three months.

✔ RPO and RTO requirements that vary by system criticality. The bank must define the criticality tier of every workload and document the backup posture that aligns with the RPO and RTO for that tier.

✔ AES-256 minimum for sensitive data at rest and in transit. Encryption is no longer optional for any workload that touches customer data.

The five points read as architectural decisions, not configuration changes. Most Indian BFSI buyers signed their last backup contract before any of the five was a formal requirement. The renewal cycle in 2026-2027 is the moment when the procurement memo either reflects the new framing or carries forward the 2022 framing into a regulator-audit failure point.

The ransomware reality compounds the picture. Per the Seqrite India Cyber Threat Report 2026, India recorded 265.52 million malware detections in 2025. Manufacturing absorbed 2,786 cyberattacks per week. Financial-services attacks track closely behind manufacturing in volume and intensity. For an Indian BFSI institution, the RPO/RTO drill is no longer a planning exercise. It is a probability-weighted operational reality.

The reframe for the audit committee:

The 2022 audit question was "do we have backups." The answer was binary, yes or no, and most institutions answered yes.

The 2026 audit question is "can we restore the backups under attack, within the documented RPO and RTO, with an auditor reading the runbook, and the result reported to RBI within six hours of the incident."

The answer to the 2026 question is not binary. It is a tested-and-documented posture across architecture, vendor, operational team, and runbook discipline.

The CERT-In Direction of April 2022 set the six-hour reporting clock for cyber incidents. The twenty categories of reportable incidents include phishing, BEC, and ransomware.

For backup-plane events specifically, the reporting expectation is often misread.

A ransomware attack that compromises only the production environment is one reportable incident. The same attack that compromises the production environment AND the backup management plane is a materially different incident, reportable under CERT-In with the additional context that recovery from backups is itself compromised. The reporting artefact, the chain-of-custody documentation, and the RBI sector-regulator notification all sit on top of the basic 6-hour CERT-In clock.

Three contract clauses worth getting right with the backup vendor before the next renewal:

👉 What is the incident-detection artefact when the management plane is compromised, and can it be exported in a form that satisfies the CERT-In + RBI dual-reporting workflow inside 6 hours?

👉 What is the chain-of-custody documentation for backup data accessed during incident response, especially given DPDP data-residency expectations for sensitive customer data?

👉 What is the vendor's posture if the incident is part of a coordinated campaign affecting multiple Indian BFSI buyers simultaneously, and the vendor's incident-response capacity is shared across customers?

The third clause is the one most Indian buyers do not currently ask. The vendor's incident-response capacity is finite. In a coordinated-campaign scenario, the customers who asked about prioritisation upfront have a documented expectation. The customers who did not ask are answered by whichever account team is most available when the call comes in.

Veeam vs Rubrik vs Cohesity: Cyber Resilience Platform Comparison 2026
TechnologyMatch.
The cleanest side-by-side technical comparison published in 2026. Read for the architectural-commitment framing rather than the feature matrix.

3-2-1-1-0 Backup Rule: Cyber-Resilience Architecture for 2026
Rack2Cloud.
The architecture-side primary source on the modern rule. Read before the next vendor RFP lands on your desk.

BFSI Cybersecurity Readiness: RBI Compliance with CloudSEK
CloudSEK.
The Indian-side primary source on the Master Directions framework. Pair with the GIS Pl RBI compliance trends 2026 piece for the procurement-side read.

Seqrite India Cyber Threat Report 2026
Seqrite.
The 265-million-detections backdrop. Read for the Indian-specific threat-model calibration.

Disaster Recovery as a Service for NBFCs in India
Cloud4C.
The NBFC-specific read on the DRaaS landscape under the RBI Master Directions. Useful for the NBFC CIO whose architecture has a different starting point than the bank's.

Every backup conversation in Indian BFSI for the last decade has been about how often the backup runs.

Daily? Hourly? Continuous? The vendor pitch leads with the cadence. The procurement memo scores the vendor on price-per-TB at the chosen cadence. The audit committee signs off because the backup ran successfully overnight.

That conversation is finishing.

Restore is the only metric.

The backup that ran successfully and cannot be restored is worse than no backup at all, because the false confidence drives the operational team's decisions in the moment when those decisions matter most. The bank whose CIO confidently tells the regulator at hour two of a ransomware incident that "we restore from backup" and discovers at hour eighteen that the restore is failing has spent sixteen hours of optionality on a promise the backup platform was not actually keeping.

The 3-2-1-1-0 rule is the architectural response. Immutability that the compromised admin cannot defeat. Air-gap that the attacker cannot reach. Zero unverified restores so the false-confidence trap closes before the night the restore actually matters.

The Rubrik versus Veeam versus Cohesity decision is the platform-layer response. Architectural commitment, not feature matrix. Threat-model alignment, not lowest-cost cell.

The RBI Master Directions are the compliance-layer response. The regulator has accepted that intrusions will occur, and the bank is expected to operate accordingly.

For the Indian BFSI CIO drafting the 2026-2027 backup-vendor RFP, the procurement question is not "what is the cadence of the backup."

The procurement question is "what is the documented RTO under a ransomware scenario that includes backup-management-plane compromise, and what is the verification cadence that proves the documented RTO is operational."

Once that question has an answer, the architecture decision follows. The vendor follows. The audit-committee narrative follows. The RBI compliance posture follows.

VEMIO™ exists because the operational reality of running this kind of backup-and-recovery discipline across a multi-site Indian BFSI estate needs an observability layer that the backup platform alone does not provide. The platform reports that the backup ran. The CIO needs to see across the backup runs, the restore-verification results, the immutability-tier compliance, the air-gap-tier completeness, the CERT-In incident-response readiness, and the RBI sector-regulator workflow. All in one operator view.

The backup ran last night. The question is whether the restore will run tomorrow morning.

Reply to this email with the one restore scenario you have not yet tested this quarter, and we will feature the most operationally interesting reply (anonymised, with consent) next issue.

Until next time,

Ajay Salvi & the Vinay Enterprises team.