Imagine stepping away from your business. You, the CISO, your company’s leader of cyber defense, are not there. Nor are you in contact with your team. No laptop. No phone. No check-ins. You’re gone. Now imagine that at that very moment, there’s a system failure or a cyberattack. What now?
Cue the horrified face emoji. Such thoughts trigger immediate discomfort for anyone in charge of a department. After all, you’re in charge, and they need you. The question is, should they need you?
Even if you are not the CISO, a similar question still stands: What would happen if your CISO wasn’t around during a cyberattack? The prospect of a CISO’s absence during a time of crisis is one of the best ways to gauge your true Mean Time to Recovery (MTTR) readiness. It goes beyond numbers on a dashboard and allows you to assess and ultimately confirm your team’s ability to help your organization recover. An MTTR is more than just a calculation of hours; it’s also about knowing you have the right people in place, and this might mean not including yourself in that calculation.
Got feedback? Join the conversation on LinkedIn.
Huge thanks to our sponsor, Palo Alto Networks
It’s not you. It’s them.
It is easy and quite natural for an IT leader like a CISO to feel they are personally responsible for fixing a crisis. But there is a significant difference between being responsible for fixing a crisis and actually fixing that crisis. In this regard, leaders can learn much from military history.
Adam Arellano, field CTO, Traceable, is a veteran who brings battlefield experience directly to this issue of being the only one in charge during a crisis. Whereas security leaders often get this wrong, “military leaders tend to get it right, because there’s an expectation that in any given situation, there’s a possibility that you as a leader will be removed from the situation through injury or otherwise. Therefore, one of the best measures of the success of a development program that involves incident response is whether or not that incident response can run well without the leader involved,” said Arellano.
Naturally this runs against the can-do-must-do instinct of many in leadership positions, especially those who have risen through the ranks and who is a “subject matter expert” to their core.
The ideal metric of an MTTR plan, Adam added, would be, “how well does the team respond without the CISO’s input? The answer should be ‘much better!’ Every single time, they should be responding more effectively without the CISO’s involvement by default. That should be the rule.” Adam offered a compelling and unforgettable lesson in this approach in a post entitled “The Parable of the Colonel’s Boots.”
It’s about time
Sivan Tehila, CEO and founder, Onyxia Cyber, quotes her company’s recent report, Key Metrics to Defend Against Threats: The CISO Perspective, in which it was discovered that “the average target SLA for MTTR is 9 hours,” with only 8% of respondents being able to offer an SLA of 2-3 hours. “In more than a quarter of cases, CISOs reported a target SLA of more than 10 hours to respond to an incident,” the report said.
Her company’s report parallels Adam’s philosophy: “Governing your program and knowing where you stand is the first step; ensuring operational effectiveness and accountability must come next. You want to know that you can not only have a clear and transparent picture of how your program performs, but also how to operationalize program improvements,” she said.
And what baseline are you testing from, exactly?
Tabletop exercises and real hands-on drills are vital to the MTTR experience, but how do you define the scope of these exercises? Jim Bowie, CISO, Tampa General Hospital, suggests that “you should test recovering completely from nothing regularly.” He adds, “the number of supporting technologies and contingencies that you think you have but don’t, will surprise you.”
He continued, “if your team can’t respond to an incident without you, then you don’t have an adequate cyber operations plan. The plan should never rely on one person, if it does, you have a problem with training, process, and trust.” Bowie stressed the importance of having several field commanders equipped with the knowledge and trust to make major rapid decisions. Note the importance Bowie places on “trust” in these deputy positions. He concluded, “In a true massive cyber event, minutes are millions. The CISO can help, but they should not be the reason for a successful mitigation or recovery. When it’s go time it should operate without them, otherwise you do not have any form of resilience.”
Speed isn’t just about reaction. It’s about recovery.
As many of our readers will know, at CISOSeries.com we recently gathered insights from 30 CISOs and IT experts who shared 22 key takeaways for improving MTTR in cloud environments. Their comments highlight just how nuanced the recovery challenge really is. MTTR isn’t only about tools or automation, it’s also about clarity, communication, ownership, and culture.
The big questions, then, become:
- Can your team identify and isolate an issue without you?
- Do they know how to escalate, who owns what, and what not to touch?
- Is your cloud architecture working with your recovery plans, or is it complicating them?
Speed, in this context, isn’t just about detection and alerting. It’s about resilience and resolution regardless who is in charge. It’s about how quickly your systems, teams, and business bounce back to normal. And how independently they can do it.
Recovery speed is a culture, not just a KPI. If your people are confident, your processes are tested, and your tools are tuned, then stepping away shouldn’t feel risky. It should feel like validation. If you can’t – or won’t – accede to doing a “48-hour absence test” right now, ask yourself why. Then use that question and the answers you come up with to drive your next improvement plan. True speed in MTTR isn’t just about running fast. It’s about knowing that you don’t have to run at all.