The room is quiet in the way only a tired incident bridge can be. Systems are technically back online, the containment work is done, and yet the executives still look uneasy. Someone asks the question that hangs over every major cyber event: “So when do we get back to normal?” Your team looks at each other, knowing what you cannot quite say aloud—that “normal” is gone, and pretending otherwise might be the most dangerous move left on the table.
In today’s environments, “normal” is a moving target built on fragile assumptions: fixed trust boundaries, stable vendors, predictable integrations, a network you mostly recognize. A serious incident blows holes in all of that at once. You rotate credentials, reissue devices, change routes, add new monitoring, lock down third parties, and sometimes rebuild entire segments. Even if every dashboard turns green, you are not back where you started. You are in a different, uncharted configuration that happens to be mostly working. This Wednesday “Headline” feature in Bare Metal Cyber Magazine is about treating that reality as the baseline instead of a temporary inconvenience.
For security and technology leaders, the next few years will be defined less by whether incidents happen and more by how recovery is framed, governed, and measured. Disaster Recovery (DR) language still points people toward rewind thinking: restore from backup, re-enable services, declare victory. But resilient organizations act differently. They define acceptable new steady states, design deliberate degraded modes, and make peace with the fact that “full normal” is often neither achievable nor wise. The question is no longer “How fast can we get back to how things were?” but “Which safe, sustainable state should we move into now, and what stays changed for good?”
The Myth of Normal
“Normal operations” sounds objective on a status slide, but in a modern environment it is mostly a story leaders tell themselves. Before an incident, that story might assume stable cloud regions, a small set of core SaaS providers, and a reasonably clean identity directory. In reality, “normal” is an ever-shifting mix of feature flags, emergency exceptions, shadow integrations, temporary firewall rules that never got removed, and once-off vendor access that quietly became permanent. When a serious incident hits, it does not knock you off a fixed baseline; it exposes that you never really had one.
The language of “back to normal” is powerful because it promises psychological relief. Boards want it, regulators hint at it, and internal stakeholders cling to it because it feels like closure. But if you design your recovery around that promise, you bake in a set of bad assumptions. You assume the same suppliers will be acceptable, even if one just failed badly. You assume your previous authentication patterns were fine, even though you just saw how easily they were abused. You assume your old monitoring gaps can remain, because they were “good enough” before. The more tightly you cling to that imagined baseline, the more you drag yesterday’s weaknesses into tomorrow’s environment.
This also distorts trade-offs in the heat of response. When leaders fixate on “normal,” they frame every control change as temporary friction to be undone later, rather than part of a deliberate step-change. Extra approvals on admin actions, stricter third-party connectivity rules, reduced feature sets, or more aggressive alerting are treated as nuisances to be peeled back quickly. Teams start promising reversions they should never promise, just to make stakeholders feel better. What should be a chance to reset risk posture becomes a race to repaint the old scenery and pretend the stage is unchanged.
Over time, this myth shows up in documents as well as dialogue. Disaster Recovery (DR) plans describe “normal operations” as if it were a clearly defined, static target, instead of a family of acceptable states. Service-level objectives are written as binary—either we are meeting them or we are “not yet back.” When your whole system of plans, metrics, and expectations is tied to a single, hazy normal, you leave yourself with only two stories after an incident: success or failure. Real resilience needs more than two stories.
Recovery as Reconfiguration, Not Rewind
Once you drop the idea of rewinding, recovery starts to look like what it really is: a large-scale reconfiguration of how the organization works. After a material incident, you swap out identity providers or change trust levels between them, you alter how VPN and remote access are granted, you disable certain integrations, you add new telemetry and enforcement points. Even if you keep the same tools, you often change their scope, policies, and automation. Architecturally, you are not restoring a snapshot; you are building a new version of the environment under pressure, with scars from what just happened.
Treating recovery as reconfiguration forces leaders to ask a different set of questions. Instead of “When will everything be back?” the questions become “What should the new trust boundaries look like?” and “Which dependencies are we comfortable carrying forward?” For example, if a third-party integration was central to the breach path, the conversation should not be about how fast you can reconnect it under the old model. It should be about whether that integration ever comes back without a mediated pattern, a different identity strategy, or a change in data scope. The idea of a “clean slate” shifts from nostalgic fantasy to explicit design work.
This mindset also changes how you use your artifacts. Service maps, dependency graphs, and data flow diagrams stop being static documentation and become the blueprint for your new state. Teams can mark which edges are being removed, which are being tightened, and which must be replaced with safer patterns. Recovery plans that once read like linear runbooks can instead point to a small set of intentional configurations—call them operating states—that you are willing to inhabit after a crisis. In that world, the job is not to sprint back to a single idealized normal, but to move decisively into a better-defined, safer configuration and accept that “after” will never look exactly like “before.”
Degraded Modes and Deliberate Sacrifice
Every organization already operates in degraded modes; most just do it accidentally and chaotically. A regional outage, a failed deployment, or a broken integration forces on-the-fly workarounds and whispered “do not touch that system” warnings. In a serious incident, those same patterns appear, but at higher stakes and under more scrutiny. The difference between resilient and brittle organizations is not whether they degrade, but whether the degradation is planned, communicated, and aligned to risk and business priorities. Degraded mode is not failure; it is an intentional choice about which parts of the business you are willing to dim in order to protect what matters most.
Planned degraded modes start with explicit sacrifice decisions. You might decide that certain high-risk features stay offline longer because they punch through multiple trust boundaries, even if they generate revenue. You might predefine that some regions or customer segments are served via slower, manual processes while you keep core transactional systems in a hardened state. You may choose to suspend new account creation, restrict administrative functions to a much smaller group, or turn off non-essential analytics that depend on lateral access. None of these moves are popular, but they are far easier to execute when they have been discussed and documented in calm time.
This is where politics and incentives surface. Business leaders will often push to restore the noisy, visible features fastest, even when those features are precisely where your risk is highest. Security and operations teams may instinctively want to keep everything locked down indefinitely. A mature recovery strategy acknowledges this tension and bakes it into governance. Before the next incident, you can define which services are “protected at all costs,” which can be sacrificed temporarily, and who has the authority to make those calls. In the heat of an event, that prior alignment turns panicked negotiation into execution against a known set of trade-offs, with security and resilience as first-class outcomes rather than afterthoughts.
From DR Playbooks to Resilience Portfolios
Traditional Disaster Recovery (DR) playbooks were built for simpler worlds: a data center fails, a primary database dies, a site goes dark. The script is linear—declare, fail over, validate, declare success. In today’s environments, incidents are rarely that clean. You might have partial data corruption, identity compromise, supply chain issues, and regulatory scrutiny all at once. In that context, a single, linear playbook is an inadequate tool. What you need instead is a resilience portfolio: a small set of clearly defined operating states, each with known constraints, controls, and decision rights. Recovery becomes the act of moving between these states, not blindly following a checklist until someone says “we’re done.”
Think of named operating states such as “isolated core,” “limited outbound,” or “regulator-supervised operations.” Each state describes which services are available, how identities are treated, what connectivity is allowed, and what additional monitoring or approvals are in place. You might have a state where external integrations are severed but core internal workflows continue, one where customer-facing features are sharply reduced, and another where certain segments operate under special scrutiny because of ongoing investigations. The important shift is that these states are pre-designed and understood, rather than improvised on the fly for each incident.
A resilience portfolio also clarifies who decides when to move between states. Instead of an ad hoc debate about whether “we’re back to normal,” you have explicit triggers and authorities. For example, leaving an “isolated core” state might require independent validation that compromised identities have been rotated, that key suppliers have implemented agreed changes, and that specific classes of telemetry are in place and reviewed. Funding and accountability can be tied to maintaining the readiness of these states: keeping documentation accurate, testing transitions during exercises, and ensuring teams know what each state entails. Leaders who adopt this model stop judging recovery purely on speed and start measuring how reliably the organization can inhabit, and move between, safe configurations under stress.
Where Leaders Go From Here
At its heart, this topic is about abandoning the comforting fantasy of “back to normal” and treating recovery as a series of deliberate choices about where your organization will live next. The war room question is not whether you can restore what you had, but whether you should. Once you accept that every serious incident leaves you in a different environment, the goal stops being cosmetic restoration and becomes designing, funding, and governing a set of safer, more honest steady states. That shift is uncomfortable, but it is the only one that matches the complexity you already operate in.
Closing the loop on that incident bridge scene, the most important statement a leader can make is not “we’re back to normal” but “we are now operating in this defined state, and here is what has changed for good.” When leaders think in terms of named operating states, planned degraded modes, and resilience portfolios, they give their teams clearer direction and more realistic constraints. Security moves from arguing for “one more control” to shaping which states are acceptable; business leaders move from demanding speed at all costs to negotiating visible trade-offs; boards and regulators get a more transparent view of how risk is actually being managed after the headlines fade.
If you internalize this frame, recovery conversations in your organization will change. You will tolerate less magical thinking about rewinds, demand clearer articulation of what “up” really means for each service, and be more willing to leave certain paths closed if they no longer meet the bar. The practical next step is not rewriting every playbook overnight, but asking a small number of pointed questions: Which operating states do we recognize today, even informally? Who gets to decide when we move between them? And where are we still promising a “normal” that no longer exists? Those questions, asked early and often, do more for real-world resilience than any number of green check marks on a post-incident slide.
