For most of my career, security was framed as a wall. Build it high enough, patch it fast enough, watch it closely enough, and the bad thing stays outside. It was a comforting model and it was never quite true, and in 2026 it is not true at all. The organizations that come through an incident intact are no longer the ones with the highest wall. They are the ones that assumed the wall would be breached and built for what happens next.
I run technology for a group that operates in critical industrial sectors across many countries, and that context changes how I think about this. When your clients work in aerospace, defense and energy, a security failure goes well beyond an embarrassing headline and becomes a safety and continuity problem that touches things that matter. So I have moved my own thinking, and my teams, from a posture of protection to a posture of resilience. The difference sounds semantic. In practice it changes almost everything.
Protection asks a different question than resilience
Protection asks how do I keep the attacker out. It is a necessary question and I spend real money answering it. But it has a hidden assumption baked in, which is that keeping them out is achievable if you try hard enough. Every serious person in security has quietly abandoned that assumption. The attacker only has to be right once, the surface keeps expanding, and the tooling on the offensive side is getting cheaper and faster at the same rate as everything else.
Resilience asks a harder and more useful question. When something gets through, and it will, how quickly do we detect it, how much can it reach, how fast do we recover, and does the business keep running while we do. That reframing is liberating, because it stops you pretending you can achieve perfect prevention and starts you engineering for the world as it actually is. You still build the wall. You simply stop betting the company on it holding.
The practical test I use is simple. For any critical system, I ask not only how we stop a breach, but what happens the morning we discover one. If the honest answer is that we would be scrambling, improvising, and hoping, then no amount of preventive spend has actually made us safe. It has only made us feel safe, which is worse.
What building for resilience actually means
Resilience is not a product you buy, and the vendors who imply otherwise are selling the wall again with a new label. It is a set of design choices and rehearsed habits. It means containment by design. When something is compromised, how far can it spread before it hits a boundary. A flat network where one foothold reaches everything is a prevention bet with no fallback. Segmentation, least privilege and hard internal boundaries are what turn a catastrophe into an incident. Most of the difference between a bad week and a bad year is decided here, long before any attacker shows up.
It means recovery you have actually tested. Everyone has backups. Far fewer have restored from them under pressure and measured how long it took and what broke. A backup you have never restored is a hope, not a capability. I would rather find the gap in a drill than in a crisis, so we rehearse the recovery, not just the plan for it.
It means removing single points of failure, including the ones that are commercial rather than technical. A dependency on one provider or one foreign platform that could be cut off is a resilience risk even if it never gets hacked, because the switch does not have to be an attacker. It can be a policy change, a sanction, a supplier decision made in another country. If a single external decision can take out something critical, that is a fragility I have to design around, whatever the contract says.
And it means the human layer is rehearsed, because the first hour of an incident is chaos and chaos is where the damage compounds. Who decides to take a system offline. Who talks to whom. When does this stop being an IT matter and become an executive one. If the answers are being invented in the moment, the incident is already running the organization instead of the other way around.
The seams are where the real risk lives
The failures I worry about most are rarely a single dramatic hack of a well-defended core. They happen at the seams. The system nobody quite owns after a reorganization. The supplier connection that was convenient and never reviewed. The acquired company plugged in quickly under deadline pressure with its security posture unexamined. The integration bridge that was meant to be temporary and is now load-bearing.
None of these are exotic zero-day attacks. They are governance gaps wearing a technical costume, and they are far more common than the cinematic version of a breach. Which is why so much of resilience is unglamorous ownership work. Knowing what we have, who owns each piece, where the boundaries are, and where the quiet dependencies run. An accurate map of your own estate is a security control, even though it never appears in a security product catalog.
This is also where speed and safety stop being opposites. A team that ships fast on a shared platform with guardrails built in is safer than a slow team improvising its own security each time, because the guardrails are consistent and the fast path is also the compliant one. Resilience designed well makes the safe way the easy way, and that is the only version of security that survives contact with people under deadline.
Why I treat this as a leadership responsibility
It would be easy to file all of this under the security team and move on. The security team is essential and I back them fully. But the decisions that determine whether an organization is resilient are mostly not security-team decisions. They are architecture choices, supplier choices, investment trade-offs, and the discipline to rehearse things that have not gone wrong yet. Those are leadership calls, and they compete for attention with a hundred things that feel more urgent because they are already on fire.
This is also why resilience belongs on the board agenda and not only in a technical review. A board does not need the packet-level detail, but it does need to understand the exposure it is carrying and to fund the buy-down deliberately, the same way it treats any other insurable risk to the enterprise. I have found the useful board conversation is not about tools at all. It is about a single question posed in their language. If our most critical system went down tomorrow to a breach, how long until we are running again, what does each hour cost us, and what have we already spent to shorten that number. Framed that way, resilience stops being a technical line item the board tolerates and becomes a risk position the board owns, which is exactly where the accountability should sit.
That is the quiet difficulty. Resilience is spending today against a loss that has not happened, and it is easy to defer because nothing breaks the day you defer it. The job is to fund and enforce it anyway, in the calm periods, so that the capability exists before the morning you need it. I have come to think of that as one of the more honest measures of technology leadership. Not whether you were breached, because eventually something gets through for everyone. Whether, when it did, the organization bent and recovered instead of breaking. You build that answer long before the day you have to give it.
