Can You Bring Back the Minimum Viable Bank?

Banks have plenty of worst-case scenario plans: playbooks, backup schedules, escalation paths, and tabletop exercises. But these plans only work when banks can detect an attack in time. In a ransomware attack, attackers may spend weeks inside a network before they’re detected and may compromise backups in the process.

A new IDC analyst brief sponsored by Everpure, “Operational Resilience in Banking: From Disaster Recovery to Minimum Viable Bank,” argues that disaster recovery (DR) planning rests on an assumption a cyberattack can break: that a clean restore point exists. IDC recommends planning around a Minimum Viable Bank (MVB) instead.

For a CISO, that changes two things. The bank decides in advance which services come back first and what “restored” means for each. It also tests recovery to the point where the business is operating again—a longer and more expensive test than most institutions run.

Why banks are spending on recovery

IDC’s “Future Enterprise Resiliency and Spending (FERS) Survey” asked 387 financial services organizations in December 2025 what is driving their 2026 cyber recovery investment. Nearly 70% of respondents named a current solution that is insufficient at limiting losses as their primary or secondary driver.

Compliance and cyber insurance requirements were a top-two driver for 53.3%, and one in four said their primary driver was a loss from a successful cyberattack in the past 12 months. A smaller share (27.7%) named a current solution that is too difficult to use as a top-two driver.

IDC’s summary: “The problem is not awareness; it is architecture.” The spending reflects doubt that existing recovery architecture can handle the events banks now face.

The clean restore point problem

DR programs were built for infrastructure failure, such as a failed array or a data center outage. The institution controls the timeline. It declares a disaster, runs the runbook, and restores from a copy it assumes is clean.

A ransomware or wiper attack takes that control away. The bank usually learns of it after detonation, uncertain when the compromise began. Before restoring, the team has to establish which copy is clean, whether restoring it will reintroduce the threat, and how long after restore the business can safely operate. Answering those questions means knowing the infection boundary: when the attacker got in, what it touched, and whether backup copies were corrupted during the dwell period.

IDC’s conclusion is that “recovery is now a security function with infrastructure execution.” IDC adds that insider sabotage, supply chain compromise, catastrophic infrastructure failure, and extended cloud provider outages produce the same condition with no ransomware involved.

What is a Minimum Viable Bank?

IDC defines the Minimum Viable Bank (MVB) as the minimum set of systems, data flows, and operational processes required to sustain critical banking functions during and immediately after a disruptive event. Critical functions include payments, settlements, core deposit access, and regulatory reporting. For most banks, fraud controls belong on that list too.

Most banks treat a reduced operating state as a failure. IDC treats it as the target: a deliberate operating posture, engineered in advance, that the bank can reach and hold while full recovery continues. Without one, recovery point objective (RPO) and recovery time objective (RTO) commitments float against an undefined endpoint, and scope decisions get made under incident pressure.

Regulators are heading the same way. DORA, enforceable since January 2025, covers ICT disruption well beyond malicious attacks. The UK’s PRA and FCA, Singapore’s MAS, and Australia’s APRA CPS 230 cover any severe but plausible disruption. In the US, IDC points to FFIEC guidance, OCC expectations, and SEC incident disclosure rules.

WRT is usually the longer clock

RPO sets tolerable data loss, and RTO sets how quickly systems return. IDC adds work recovery time (WRT)—the interval between a system being available and the business operating on it. This includes validating data integrity, reconciling transactions, restoring dependencies, clearing exception queues, and getting staff back to work.

IDC finds WRT is frequently the longer interval. A core banking system restored in two hours may need four to six more hours of reconciliation before payment processing can safely resume. Settlement systems need sequenced validation across counterparty records before they can be trusted. In IDC’s words, “The RTO clock stops when the system comes back. The WRT clock stops when the business comes back.”

4 gaps recovery testing misses

Recovery testing can show whether systems can be restored, but it does not necessarily show whether the bank can resume critical operations—or how long that will take. Four gaps often stand in the way:

• Retention has to outlast dwell time.

Immutable backups only help if a clean copy still exists. Retention periods need to account for the possibility that an attacker was present long before detection.

• Dependency outranks business criticality.

The most important application may not be the first thing that needs to come back. Identity, DNS, certificates, and other dependencies can determine the actual recovery sequence.

• Legal and insurance steps add time.

Forensics, regulatory requirements, and cyber insurance provisions can affect when recovery can begin and should be included in the recovery timeline.

• WRT rarely has an owner.

Restoring infrastructure is only part of recovery. Business teams still need to validate data, reconcile transactions, and return operations to a usable state.

Will the plan hold under pressure?

IDC argues that resilience comes down to more than having backups or a documented recovery plan. Banks need to know:

• Can we identify a verified clean restore point?
• Can we restore critical services in the right sequence?
• Can we prove the business can operate again once systems are restored?

Those are questions worth answering before an incident forces the issue.

One part of that challenge is making sure the recovery copy itself can be trusted and protected from the same compromised credentials used in an attack.

Everpure storage systems require two named, authorized contacts working with Everpure Support at the same time to delete a locked snapshot before its retention timer expires. The process occurs outside the institution’s own login system, and every request is logged. This gives banks a documented way to meet a legitimate erasure obligation while reducing the risk created by a single compromised administrator account.

The measure of a recovery plan is whether the bank can bring its Minimum Viable Bank back from clean data within the time customers and regulators will accept.

Read the IDC analyst brief

For a deeper look at the Minimum Viable Bank, RPO, RTO, WRT, and the recovery gaps financial institutions need to address, read the full IDC analyst brief, “.”