TheDPDPAct.com – Official WhatsApp Channel
Stay updated with the latest DPDP Act news, compliance insights, updates, and resources.
Ask a security leader whether their organization can recover from a cyberattack, and the answer is almost always yes. Ask how they know, and the answer gets considerably softer.
That gap — between confidence and demonstrated capability — is the defining story of enterprise cyber resilience right now. And it's not a small gap. Recent research surveying hundreds of senior security leaders worldwide found that while nine in ten expressed confidence in their recovery capabilities, fewer than one in three ransomware victims actually recovered all their affected data. On average, organizations got back about 72% of what was lost. The rest was simply gone.
Confidence is not the same thing as capability. And in cybersecurity, confusing the two is expensive.
Prevention Metrics Tell You the Wrong Story
Most security programs are measured by what they stop — blocked attacks, quarantined threats, patched vulnerabilities, closed tickets. The work behind those numbers is real and it matters. What it doesn't tell you is whether the organization can function when one of those controls fails.
And controls do fail, more often than most programs acknowledge. Enterprise security software fails to protect devices roughly one day in five — leaving organizations exposed during windows they typically don't account for in their resilience planning. Meanwhile, the average enterprise now runs more than eighty security tools, which creates coordination overhead that can itself become a failure point during an active incident.
The financial reality of downtime has also shifted dramatically. Unplanned outages now cost large enterprises hundreds of thousands of dollars per hour — not as an abstract worst-case estimate, but as a documented median. For smaller organizations the number is lower in absolute terms, but the business impact is often proportionally more severe.
None of this means prevention is the wrong investment. It means prevention alone is an incomplete answer to the question: "What happens when something gets through?"
The Incident Disrupts More Than Most Plans Account For
When a serious cyber incident hits, the breach itself is frequently not the most damaging part. What comes after it is.
Operations halt or degrade across functions that most continuity plans never anticipated being affected. Customer-facing services go dark or behave unpredictably. Revenue stops flowing in ways that compound daily. Leadership faces decisions that need to be made quickly, with incomplete and potentially unreliable information. Legal and regulatory obligations activate immediately — breach notification timelines under frameworks like India's DPDP Act and the EU's GDPR don't pause because the recovery is still in progress. Communications teams manage stakeholder relationships in real time, without pre-prepared materials, under conditions nobody rehearsed for.
Among organizations that experienced a cyber incident in the past year, more than 40% reported direct customer disruption. A similar proportion reported financial loss or measurable revenue impact. More than a third experienced extended downtime of systems they considered critical to operations.
These failures don't happen because security teams didn't work hard enough. They happen because resilience — the capability to absorb disruption and continue functioning — was never built as a cross-functional organizational capability. It was treated as the security team's problem, and handed to them accordingly.
The Alignment Problem Nobody Talks About
Cyber resilience, genuinely practiced, is not something a security team does while the rest of the organization watches. It requires genuine cross-functional ownership — and most organizations haven't built that yet.
Operations needs to have mapped which business functions cannot survive extended downtime and for how long. Finance needs to have modeled what disruption actually costs per day, not in the abstract but against specific revenue streams and contractual obligations. Communications and legal need prepared, rehearsed responses — not templates assembled under pressure at two in the morning. And executive leadership needs to have already made the decisions that an active incident will force in real time, so the crisis doesn't also become a governance failure.
Only about half of organizations maintain documented disaster recovery plans. Fewer than four in ten run crisis simulations more than once a year. The gap between having a plan and having a practiced, tested, cross-functional capability is wide — and it's where most recovery failures actually originate.
As Veeam's CEO put it in the company's 2026 research on this topic: "Confidence in recovery from a ransomware attack is high, but the data tells a different story. Even the most sophisticated organizations are discovering that confidence in recovery and proof of recovery are fundamentally different capabilities."
That distinction — between confidence and proof — is the most useful frame for any organization trying to honestly assess where it stands.
What a Resilience-Led Program Actually Looks Like
The shift from a prevention-focused security program to a resilience-led one isn't about replacing existing controls. It's about adding the layer most programs are missing.
Recovery objectives need to reflect operational reality. Recovery time targets set in isolation by the security team — without input from the functions that would actually be affected — tend to measure what's technically achievable rather than what the business genuinely needs. Aligning these requires operations and security to define the targets together.
Plans need to be tested against realistic conditions. Tabletop exercises are useful. Live recovery rehearsals — actually restoring systems from immutable backups under realistic time pressure, with the people who would execute the process during an incident — are what close the gap between a documented plan and a proven capability. The organizations that know they can recover are the ones that have proved it, not just planned for it.
Backup infrastructure needs genuine isolation. Backup systems that live on the same network as the systems they protect are vulnerable to the same attack. Ransomware operators targeting backup infrastructure specifically is not a sophisticated technique — it's a standard playbook step. Air-gapped or logically isolated recovery targets change that calculus significantly.
The response needs a leadership and communications layer. When operations are disrupted, customers are calling, regulators are watching, and media attention is possible, the security team's technical response is only part of what needs to work. Pre-prepared stakeholder communications, clear escalation paths, and leadership roles that have been assigned and rehearsed are as important to the overall outcome as the containment capability itself.
The Question Worth Asking Before the Incident Forces It
The most useful question an organization can ask about its own resilience isn't whether it has a security program. Almost every organization does. It's whether the business could actually keep operating while an incident is being managed — and whether it would recover the things it genuinely cannot afford to lose.
For most organizations, that question has never been run as a real test. It's been answered with a recovery plan, a backup vendor, and reasonable confidence in a scenario nobody has actually rehearsed. The research is consistent: organizations that integrate security and continuity planning, test recovery under realistic conditions, and build cross-functional ownership of resilience outcomes consistently outperform those that don't — in recovery speed, in data recovery rates, and in the downstream impact on customers and revenue.
Security protects systems. Resilience protects the organization. And the difference between them is only visible when one control fails and the organization finds out, in real time, what it actually built.
At ILLUME Intelligence, this is precisely where our vCISO advisory and incident preparedness engagements are designed to help — working with leadership teams to close the gap between security posture and operational resilience, testing recovery capability before it's needed, and ensuring that the plan on paper is one the organization can actually execute under pressure. Reach out to Illume to start that conversation before an incident makes it urgent.
