After decades of securing high-consequence environments, what has become harder about cybersecurity today, not necessarily because threats are more sophisticated, but because technology and security expectations have multiplied?
Complexity is the enemy now.
When I started in this field, environments were smaller, boundaries were clearer, ownership was easier to understand. Today, an enterprise might run traditional infrastructure, multiple clouds, a stack of SaaS platforms, hundreds or thousands of applications, third parties, remote workers, operational technology, several identity platforms, and years of acquisitions stacked on top of each other.
At the same time, we’ve added an enormous number of security tools. Each one may solve a legitimate problem on its own. Collectively, they create a different problem: understanding how any of it actually fits together.
The expectations placed on a CISO have expanded just as fast. You’re expected to prevent attacks, understand business risk, manage regulatory exposure, protect identities, secure third parties, prepare for ransomware, brief the board, support digital transformation, and when something goes wrong, somehow already know exactly how the company recovers.
That last part is where the industry has underestimated the challenge. Knowing what you own is hard. Knowing how everything depends on everything else is harder. Knowing whether you can actually rebuild it under the pressure of a real attack is harder still.
Where does cybersecurity create the most operational friction for a CISO today: fragmented ownership, legacy systems, identity, third parties, cloud dependencies, tool sprawl, or something else?
All of those play a role, but I’d put fragmented ownership at the center.
Security may be accountable for risk, but security doesn’t own most of the infrastructure required to actually operate or recover the business. Identity belongs to one team, backups to another, cloud to a third, networking somewhere else, applications sit with business units, and critical services often depend on outside vendors.
During normal operations, those boundaries are manageable. During a crisis, they become painfully visible.
A CISO can have excellent security visibility and still lack a reliable answer to some very basic operational questions. What does this application depend on? Where’s its identity infrastructure? Is its backup actually usable? What has to come online before it? Can we rebuild it without reconnecting something compromised?
I’ve started thinking about cyber risk less as a security problem and more as an operational resiliency problem.
Security teams invest heavily in prevention, detection, and response. From your experience with real-world attacks, where does this leave organizations operationally exposed once those defenses are breached?
The industry has spent billions of dollars answering three questions. How do we stop the attacker? How do we detect the attacker? How do we respond to the attacker?
Necessary questions, all three. But there’s a fourth one that’s gotten far less attention: how do we operate again?
Once defenses fail, the conversation changes fast. You’re no longer talking about alerts and controls. You’re trying to figure out whether Active Directory can be trusted, whether backups survived, whether virtualization infrastructure can be recovered, whether the security tooling itself got compromised, which applications are truly critical, and what has to exist before those applications can function.
Organizations discover, usually the hard way, that having backups isn’t the same thing as having recoverability. You can have every server backed up and still not know the right sequence for rebuilding the enterprise. You can restore an application and find that it doesn’t work because DNS, identity, certificates, a database, or some other dependency isn’t there.
That gap, between protected assets and actual restored operations, is one of the biggest exposures I see today.
In cyber incidents, how much of the real damage comes from the attack itself versus the time spent determining what can be restored, in what order, and what dependencies could prevent recovery?
In most of the incidents we work, the attacker creates the crisis. Uncertainty is what extends it. Once an organization hits the recovery phase, every hour counts, and this is often the first time anyone’s trying to answer questions that should’ve been answered years earlier. Which systems are Tier 0? What depends on Active Directory? Which backups are clean? Which recovery infrastructure can be trusted? Which applications have undocumented dependencies? What’s the minimum viable environment needed to operate the company at all?
If you’re answering those for the first time while the company is down, you’re doing architecture discovery in the middle of a disaster.
Recovery is a logistics problem at its core. Thousands of technical components, limited people, dependencies between systems, a sequence that has to be followed. Restore the wrong things in the wrong order, and you can burn enormous amounts of time without meaningfully restoring the business.
Recovery planning can’t be a document sitting on a shelf. Organizations need to understand their dependencies, their sequence, and their actual recoverability before the incident happens, not during it.
The cybersecurity buying cycle now involves security, IT, engineering, procurement, finance, legal, and sometimes the board. Where do their definitions of “value” diverge, and how do you reconcile them?
Everyone’s looking at the same investment through a different lens.
Security wants risk reduction. IT wants something operationally sustainable. Engineers want something that works without adding complexity. Procurement wants commercial discipline. Finance wants measurable value. Legal wants risk transferred or controlled appropriately. The board wants to understand business exposure, full stop.
Problems show up when security tries to talk about value only in security language. The common denominator, I think, is business continuity. Instead of saying “this product identifies 5,000 vulnerabilities,” tell me what those vulnerabilities mean for the company’s ability to operate. Instead of “our backups are successful,” tell me whether we can recover the systems that generate revenue. Instead of “we have an incident response plan,” tell me how long it takes to restore minimum viable operations if identity and infrastructure go down at the same time.
Translate the security conversation into operational and financial consequences, and the stakeholders usually align a lot faster than people expect.
AI, automation, and consolidation dominate cybersecurity vendor messaging today. What should CISOs interrogate to determine whether they create meaningful capability or simply add another layer to the stack?
Ask what problem it actually eliminates.
Not what dashboard it produces. Not how many alerts it generates. Not whether AI shows up somewhere in the architecture diagram.
What manual process goes away? What decision gets faster? What information gets more accurate? What can I retire because of this? What happens differently during a real incident because this thing exists?
AI can be genuinely useful, especially when it helps people analyze relationships and volumes of information faster than they could on their own. Automation removes repetitive work and speeds up response.
Neither one fixes bad data, missing context, or infrastructure nobody understands.
If I bolt on an AI-powered platform and still need five engineers and three other consoles to figure out whether a critical application can recover, I haven’t solved anything. I’ve just built a fancier way to look at the same unsolved problem.
What do you learn from a vendor’s reference customers that you cannot learn from a proof of concept or technical evaluation?
You learn what happens after the sales team leaves the room.
A proof of concept tells you whether the technology works under controlled conditions. A reference customer tells you whether the company behind it works when conditions aren’t controlled at all.
I want to know what happened when something broke. How fast did they respond? Did support actually understand the customer’s environment? Did the product deliver what was promised in the sales process? How rough was implementation? Did the operational teams actually use it, or did it sit unused? Was the vendor still engaged a year later?
References that lived through a genuinely difficult event with the vendor are worth more than any other kind. Cybersecurity products get bought for bad days. I want to know how a vendor behaves on someone’s worst day, not how the software looks in a demo.
Having spent so much time on the recovery side of cybersecurity, how has that experience changed your approach to Fenix24’s own security initiatives? What broader assumptions do you now question based on what happens during major attacks?
It’s made me question almost every sentence that starts with “we think.”
We think our backups are good. We think we know our dependencies. We think our documentation is current. We think that application can be restored in four hours. We think our identity environment can be rebuilt. We think the security tools protecting us will still be there during the incident.
Recovery work teaches you fast that assumptions don’t survive contact with a real attack.
At Fenix24, I think in evidence now, not assumptions. Show me we can recover it. Show me the dependency. Show me the backup. Show me the recovery sequence. Show me what happens if identity goes down. Show me the minimum viable environment.
The other lesson: recovery can’t begin after the attack. The technical work of restoring systems happens afterward, sure, but the knowledge required to recover successfully has to exist long before that.
That’s changed how I think about the whole discipline. Prevention still matters. Detection still matters. Incident response still matters. But we also have to admit something uncomfortable: eventually, some defenses fail.
When that happens, the ability to recover is the last security control standing.
