Cyber Resilience Is About Planning, Practice, and Patience, not Urgency

In the first twenty-four hours of a cyber incident, security teams race against the clock to resume normal operations. Executives frequently demand answers to parallel problems that incident response teams can only resolve step by step. They push for immediate details on root cause, scope, and notification requirements, creating a massive gap between boardroom expectations and how investigations actually unfold.

Aurobindo Sundaram has spent nearly a decade managing these exact bottlenecks. As Chief Information Security Officer at RELX, a ~$10 billion global information and analytics company with more than 36,000 employees, Sundaram frequently counsels leaders on navigating the friction of a breach. He views practical frameworks, such as his 20-question resilience checklist, as baseline operational tools rather than silver bullets for an active crisis. "Urgency is seen as a virtue. The real, long-term virtue is accuracy. The best approach is to just relax," he says.

Sundaram sees that friction starts the same way across organizations: with a misunderstanding of how breaches actually occur. Theoretical defense-in-depth architectures gradually erode through normal business operations. Over time, system drift creates a hidden bridge for an attacker, turning minor operational housekeeping into an open door.

• Passwords from the past: Sundaram describes a common pattern where layered controls fail in sequence: a seemingly isolated infection can bypass zero-trust architectures if people fail to catch it. "You have antivirus and phishing detection on a device, but a hacker sent an email or an attachment that your system didn't catch, and someone opened it."

• Ghosts in the machine: The problem compounds when forgotten infrastructure comes into play. Sundaram says that "Although the network is supposed to be secure, sometimes you'll find a test system for a temporary project that was never decommissioned, so IT didn't know about it, and security didn't know about it."

A constant environmental drift wrecks tested recovery time, a favorite boardroom metric for resilience. In theory, these metrics should be reliable, but Sundaram points out that in practice, they rarely align with real-world performance.

• The reality of recovery: Sundaram explains that the investigation is the most crucial point of recovery, and it's often the thing that "gets in the way" of immediate results. But teams can't start system recovery without a full investigation. "The recovery clock starts only when you've done enough of the investigation to realize what you have to do, whether that's recovering your system, going to your backups, or another approach. If you wait for four days before making that decision, you've just increased your recovery time by 80 percent."

In many organizations, the tension between sequential forensic work and the desire for immediate answers frequently creates heavy strain on security and recovery teams. Under the external pressures of an outage, some leaders find themselves bypassing established protocols.

• Panic at the top: Even seasoned security leaders aren't immune to the pressure of having to know "right now," and Sundaram maintains the same message of patience and clarity. "No matter how many incidents someone's been through from the executive or the security side, I still see the same pressure. But if you just step back for a moment, you realize there are tasks you need to do first. It's the compressed time frame expectations from people who should know better, but it's stress taking over at that point."

To keep human nature from driving decisions recklessly, many large organizations establish more formal incident response frameworks that include standard PR language. A common maturity milestone is shifting toward a three-part governance structure: a legal-driven process that governs and protects privilege, a security team that investigates the facts, and business leaders who manage risk and overall resilience capabilities.

• Groundhog Day debates: For leaders like Sundaram, a practical step in this evolution involves pre-writing decisions and templatizing statements during peacetime. "You have an incident, you argue about the wording, and no one learns from it. Six months later, you're arguing over the same wording, but it's different now because there are 12 people involved instead of three. Nothing is standardized."

• Halving the headache: The payoff of peacetime preparation is arithmetic, Sundaram says. "You don't need to spend twenty minutes arguing about A, B, and C because we already have built-in decisions and drafts for A and B. Out of twenty issues, ten of them have already been discussed, and now you've got templates that you can use."

Pre-established templates can help leaders filter out external noise. Sundaram advises using pre-written holding statements to set a firm update cadence, buying the security team room to breathe. In this way, navigating the pain and the urgency of an incident in real time comes down to building muscle memory. Organizations can pre-resolve hard choices long before an actual emergency through clear messaging and practice.

• Friendly fire drills: Sundaram advocates compressed, two-hour tabletop simulations to identify gaps before a real incident hits. "You get a security scare and decide to simulate issues to show gaps. Executives want to say 'what if this happened' and I'll say 'No, this is what happened' and it forces us to see how to strengthen our posture. Those couple-hour simulations lead to tangible next steps for the team."

The lesson Sundaram shares is that with the right preparation, learning, and forethought, security teams and boards alike can take measured, relaxed, and effective steps during crises. In this way, it's much easier to avoid downward pressure that creates panic and poor responses. "Instead of reacting to a ransom demand with twenty people having twenty opinions, you've done the simulations," says Sundaram. "You've gone through the anxiety in peaceful times, developed your ransomware policy, and built PR responses. You're starting with your policy rather than arguing about it in a high-stress environment."