The board chair looks across the table and asks a question you have heard a hundred times in different words: “So… are we secure?” The slide behind you is full of colors, control domains, and maturity scores, but you know none of it can honestly deliver the simple “yes” everyone wants. In today’s environments, where software supply chains shift weekly and every critical service is entangled with cloud and third-party dependencies, “secure” is no longer a stable state. It is a moving target, and pretending otherwise only makes your job harder when the next incident lands. This Wednesday “Headline” feature from Bare Metal Cyber Magazine is about changing that conversation.
At senior levels, the challenge is not a lack of controls or frameworks. The challenge is the story our metrics tell about reality. Traditional maturity models promise comfort: levels, roadmaps, and color-coded assurances that look tidy in a board pack. But they rarely describe how your organization actually behaves under stress. Boards do not lose sleep over whether you are at level two or level three. They lose sleep over whether core services will survive the next serious hit and how long it will take to recover. Over the next few years, that survivability story is what will separate credible security programs from fragile ones.
This article argues for a different center of gravity: resilience over perfection. Instead of trying to prove that you are “secure enough,” you lead by showing how the business bends without breaking, and how quickly it learns after it does. We will explore what survivability metrics look like in practice, how to mine incidents and exercises for the right signals, and how to teach boards to live with incomplete without giving up on accountability. The goal is not to lower the bar. It is to move it to where the real game is actually played.
The Mirage of “Secure Enough”
Every leader feels the gravitational pull of “secure enough.” It shows up in budget cycles, in board packets, and in hallway conversations where someone asks when security will finally be “done.” The pressure is understandable. Boards are awash in other complex risks and would love a clean finish line: a point where controls are in place, certifications are earned, and cyber risk is neatly boxed. Many security leaders, especially under scrutiny, lean into that narrative and present roadmaps that quietly imply an endpoint. The problem is that modern digital operations simply do not work that way. The more tightly your business is coupled to software, data, and external platforms, the less plausible any notion of “done” becomes.
This mirage is reinforced by the way organizations ask questions. Board members and executives are rarely trying to be naive; they are trying to reduce ambiguity so they can discharge their duties. Regulators and insurers ask binary questions. Internal audit wants clear remediation dates. In response, security teams translate messy, probabilistic reality into clean statements: “This control gap will be closed by Q3,” “We will reach target maturity by year-end,” “We are on track to meet framework X.” Over time, those simplifications harden into expectations. When a serious incident occurs after a set of “green” reports, trust erodes quickly, even if the incident fell outside the neat boundaries of previous assurances.
For leaders, the cost of living inside the “secure enough” mirage is subtle but heavy. It pushes you toward cosmetic wins that look decisive on paper but barely move survivability in practice. It incentivizes under-reporting of residual risk because acknowledging uncertainty sounds like failure. It encourages teams to treat every new control as a step toward completion, rather than an ongoing commitment to operate, monitor, and adapt that control as the environment shifts. The first step toward resilience is refusing to participate in the illusion. You acknowledge, explicitly, that “never done” is not a weakness of the program but a property of the problem space itself. From there, different metrics and conversations become possible.
When Maturity Models Become Theater
Capability and maturity models were designed as navigation tools, not stage props. In theory, they help you understand where controls exist, how consistently they are operated, and where to invest next. In practice, many organizations turn them into performance art. The model becomes a spreadsheet of domains and subdomains, each scored on a one-to-five scale that is, at best, loosely tied to observable behavior. Those scores are then rolled up into heatmaps and radar charts that look authoritative but hide as much as they reveal. Leaders find themselves arguing whether a given domain is “three or four” while having only a vague sense of how that domain behaves under real-world stress.
This drift into theater happens for predictable reasons. Maturity models are attractive because they create the appearance of precision without the discomfort of probabilistic risk discussions. They give everyone something to point at: “We improved our identity and access management domain from level two to level three this year.” Vendors and consultants reinforce the pattern with templated assessments and prebuilt dashboards. Over time, the model becomes an internal currency for budget and status. Yet very few of these debates touch the questions boards care about most: When a serious incident hits, which services are likely to fail first, how quickly can you recover essential functions, and what trade-offs will you be forced to make under pressure?
For security leaders, the danger is not that maturity models are useless but that they become self-referential. You optimize for better scores instead of better survivability. You celebrate a “green” domain even though the one team that actually operates the critical control is understaffed and exhausted. You report overall maturity improvement while the organization quietly adds new dependencies that increase blast radius and recovery complexity. The shift toward resilience is not about burning the models. It is about demoting them. They become supporting evidence, not the main story. The main story moves to how systems and teams perform when controls fail, when signals are noisy, and when time is short. That is where survivability lives, and where your metrics need to follow.
Survivability as the New North Star
If “secure” is never done, survivability becomes the more honest target. Survivability asks a different set of questions: When something goes wrong, how does the organization bend? Which services degrade, and in what order? How quickly can you restore the functions that matter most? This frame does not abandon prevention; it puts prevention in context. Controls still matter, but they are in service of keeping the business within tolerable impact bands rather than chasing an abstract ideal. For boards and executives, this is far easier to reason about because it connects directly to continuity, customers, and mission outcomes.
At an executive level, survivability metrics are surprisingly concrete when you force them to be. Instead of “overall cyber maturity,” you talk about time to degrade a critical service under specific classes of failure, time to recover to minimally acceptable functionality, and the duration of unacceptable data integrity or confidentiality exposure. You look at maximum tolerable outage windows for core processes and compare them to demonstrated recovery performance, not just stated recovery time objectives. You quantify dependency concentration: how many critical services hinge on a single identity provider, a single cloud region, or a small team. These are measures a board can argue about intelligently because they live in the same space as other resilience concerns, like supply chain disruption or physical outages.
Reorienting around survivability also changes how you prioritize work. Initiatives that barely move a maturity score might dramatically shorten recovery time or reduce the blast radius of an inevitable compromise. Investments in better runbooks, cross-functional drills, and simplification of fragile architectures often look modest compared to a marquee technology deployment, yet they move survivability in ways leaders can see and test. When survivability becomes the north star, the question stops being “How do we get to level four?” and becomes “How do we ensure that when—not if—we take a solid hit, our customers, regulators, and partners experience a disruption that is painful but acceptable?” That question drives very different choices.
Measuring What Fails, Not Just What Exists
Most organizations have detailed inventories of what exists: control catalogs, asset lists, third-party registers, recovery plans, and policy libraries. Fewer have a disciplined view of how those elements behave when it actually matters. Measuring survivability means shifting your analytics lens from static presence to dynamic performance under stress. You care less about how many controls you can list and more about how systems, teams, and partners respond when controls are bypassed, misconfigured, or simply overwhelmed. That requires different data and different habits than traditional compliance reporting.
Incident history is the first and most obvious source. Every significant event contains clues about survivability: how quickly the right people were engaged, where detection lagged, which workarounds were improvised, what dependencies surprised you, and how long it took to restore minimally acceptable service. Leaders often treat post-incident reviews as forensic exercises focused on root cause and remediation tasks. A resilience lens asks additional questions: What did this incident reveal about our time to degrade and time to recover? Which controls mattered in practice, and which were largely irrelevant? How well did communication keep pace with technical response? Those answers can be translated into metrics that you track over time, rather than leaving them buried in narrative reports.
Exercises and experiments provide the other half of the signal. Chaos-style tests, tabletop simulations, and business continuity rehearsals let you observe failure and recovery in more controlled conditions. Instead of merely checking whether a plan exists, you measure whether people can execute that plan under uncertainty and time pressure. You see where manual workarounds are fragile, where cross-team handoffs break, and where tooling slows you down. Over time, you build a metrics backbone that includes things like median time to meaningful decision in a simulated incident, number of critical services with tested degraded modes, and frequency of exercises that touch real production-adjacent systems. Leaders who consistently measure what fails, not just what exists, develop a far more accurate sense of where to invest next—and a story they can defend to boards when incidents arrive.
Teaching the Board to Live with Incomplete
If survivability is the new north star, the board has to live with a permanent state of “incomplete” without feeling abandoned or exposed. That is a communication problem as much as a technical one. Many security leaders walk into boardrooms armed with pages of control detail but very little framing for uncertainty. The result is either a false sense of comfort or a cloud of anxiety with no clear shape. Teaching the board to live with incomplete starts by changing the question on the table. Instead of “Are we secure?”, you present a small set of survivability questions the board can return to every quarter: Which critical services are most exposed to disruption today? How quickly can we realistically recover them? What potential losses are we consciously accepting in exchange for speed, innovation, or cost savings?
This requires discipline in how you present metrics. You deliberately avoid one giant “cyber risk score” that pretends to synthesize everything. Instead, you focus on a handful of resilience-oriented measures that sit alongside other enterprise risk indicators. You show trends in demonstrated recovery performance, not just planned recovery time objectives. You highlight dependency concentrations and single points of failure in language that mirrors supply chain or operational risk discussions. You are explicit about the trade-offs: improving this recovery window will require slowing that product rollout; reducing this dependency will increase near-term cost. Boards do not need guarantees. They need to see that these trade-offs are being made consciously, not by accident.
The other part of teaching the board to live with incomplete is narrative. You normalize the idea that cyber work is never finished without sounding defeatist. That means telling stories where survivability improved over time because of deliberate investment and learning, even as the environment remained hostile. It means highlighting incidents where the organization took a hit but stayed within tolerable impact bands because earlier resilience decisions paid off. Over time, this builds a different kind of trust. The board stops expecting you to prevent every bad event and starts judging you on how predictably you steer through them. That is a standard you can meet—and exceed—if your program is built around resilience rather than perfection.
Leading a Culture That Trains for Hits
Resilience on paper is worthless without a culture that expects to be hit and trains accordingly. Many security programs still operate as if incidents are rare deviations rather than routine conditions of modern digital life. That mindset shows up in how teams schedule work, how leaders respond to bad news, and how much time is reserved for drills versus projects. A resilience-focused culture treats security more like safety or reliability in high-risk industries: incidents are inevitable, surprises are valuable data, and practice under stress is part of the job, not an optional extra. Leaders set this tone by what they ask about, what they praise, and how they react when things go wrong in public.
Practically, a culture that trains for hits makes room for regular, cross-functional exercises that include the people who actually run critical services, not just a core incident response team. It favors blameless post-incident reviews where the primary question is “What did our system and process designs make likely?” rather than “Who made the mistake?” It allocates time for teams to simplify architectures, remove hidden dependencies, and refine degraded modes, even when those activities do not show up as flashy initiatives. Metrics are used to reinforce learning, not as weapons: improvements in recovery time, reductions in decision latency, and increased frequency of realistic drills are celebrated as much as passing an audit.
For executives, the key move is to align incentives with this reality. If career success depends on spotless dashboards and never admitting uncertainty, people will hide fragility until it bursts into view during a crisis. If success instead includes honest reporting of weaknesses, proactive participation in exercises, and clear documentation of trade-offs, the organization becomes more transparent about where it can withstand hits and where it cannot. Over time, this habit of training for impact builds confidence that goes beyond any single metric. Teams know they will be tested, boards know the program is tuned for survival under stress, and the entire organization becomes more comfortable with the idea that “never done” is a shared operating assumption, not a failure of leadership.
Where Leaders Go From Here
At its heart, this topic is about trading the illusion of completion for the discipline of survivability. The recurring question in the boardroom—“Are we secure?”—is not going away, but how you answer it can change everything. Instead of offering comfort through maturity scores and green dashboards, you anchor the conversation in how your organization bends under stress, how quickly it recovers, and how predictably it learns. You recast “never done” from a source of shame into an honest description of the terrain, and you show that within that terrain, leaders still have sharp, testable choices to make.
Tying back to that moment at the board table, the measure of a strong program is not whether you can say “yes” with a straight face. It is whether you can describe, with evidence, which services are most exposed, what recovery looks like in practice, and which trade-offs you are deliberately making. When you orient metrics around survivability, you change where energy flows: toward simplifying brittle architectures, rehearsing realistic incidents, and shortening the distance between failure and learning. Maturity models and compliance frameworks do not disappear, but they stop pretending to be the main story. The main story becomes how your business behaves on its worst day.
For security and technology leaders, the shift to resilience over perfection is ultimately a leadership posture. It means inviting your peers and your board into a more grown-up conversation about risk: one that accepts incompleteness, prizes transparency, and rewards training for hits rather than hiding them. A practical next step is simple: ask your team, and your board, one question—“If we took a serious hit in our top two critical services next quarter, what do we actually believe would happen?” The gaps in that answer are your roadmap. And your opportunity.
