A cyberattack is more likely to interrupt today’s enterprise than the natural disasters business continuity programs were originally built around.
Enterprises still need to prepare for fires, floods, earthquakes, power failures and other physical events. But they are more likely to experience a cyber incident that disrupts business operations by affecting employee productivity, taking applications or customer-facing services offline, or corrupting or exposing data.
AI adds urgency. Attackers are using AI to accelerate the attack lifecycle, while enterprises are embedding AI into applications, workflows and business processes. Defenders have less time to make informed decisions, and AI-enabled processes create new dependencies across enterprise systems. As agents take actions across those systems, the consequences of a compromised identity, application or agent can extend well beyond the initial point of failure.
The need for resilience came through at Black Hat 2026, a conference historically centered on security threats, vulnerabilities and defenses. Conversations with practitioners reached beyond whether an organization could prevent or detect an attack to the operational consequences of security decisions: which business operations are critical, what dependencies and single points of failure put them at risk, and what conditions are required for those operations to continue or recover. Those decisions have to be made before the organization is under attack, not during it.
Cyber resilience therefore has to start with the business operation itself. Organizations need to know what has to keep running, what can operate in a degraded state, what technology, data and people those operations depend on, and what has to be restored before normal operations can safely resume.
This also extends the architecture developed across this post-Black Hat series. The operating model in the first piece and the governance layer in the second depend on trusted systems, identities, data and context. Cyber resilience addresses the conditions under which those operations can continue when trust or availability is disrupted, and how the organization establishes them again.
Start With the Business Operation
Resilience programs have traditionally focused on backing data up, recovering endpoints and infrastructure, and getting applications back online quickly. Those measures remain important, but individually they don’t necessarily restore the business operation they support.
A customer-facing service may depend on applications, identities, data, endpoints, cloud services, network connectivity and third parties, and those dependencies are often poorly understood until something breaks. Employees may have access to a recovered application but remain unable to work because their devices are unavailable or identity services cannot be trusted, since for many employees the endpoint is the actual means of reaching what they need to do their jobs. An application may be online while the data behind it remains suspect.
Organizations need to define the critical business operation first, including its tolerance for disruption and ability to function in a degraded state. From there, they can map the technology and dependencies that support it, identify where the operation is most exposed, and determine where alternative ways of working are required. That changes the recovery objective: system recovery times become inputs into a larger question of how quickly the business can resume the work that matters, rather than a stand-in for recovery itself.
This is where resilience and security architecture meet. Redundancy, segmentation, immutable copies, alternative access paths and recovery capabilities carry more value when they’re built around the operations they’re meant to protect.
Sometimes the Business Has to Operate While Risk Remains
Cyber resilience also has to account for situations where the business cannot stop operating until a security problem is completely resolved. Critical infrastructure makes this particularly clear. Patching, rebooting or isolating a vulnerable system may interrupt a physical process, affect safety or create consequences greater than the immediate cyber risk. Similar constraints exist in hospitals, manufacturing environments, financial institutions and digital businesses where downtime itself can carry material consequences.
Security teams need to understand those operational constraints before deciding how to respond. Isolation or shutdown may still be required. In other cases, segmentation, restricted access, compensating controls or increased monitoring can reduce exposure while operations continue.
The response has to account for both the cyber risk and the business consequence of remediation. Doing that well requires security and business leaders to establish acceptable operating conditions, escalation paths and decision authority before an incident forces the issue.
Recovery Means More Than Bringing Systems Back Online
Trust is a separate question from availability. Recovered data may be corrupted. Identities or credentials may remain compromised. An attacker may have established persistence elsewhere in the environment. Applications may be functioning while the security controls around them are not.
This is one reason cyber recovery differs from many traditional disaster-recovery scenarios: a server damaged by a flood doesn’t try to remain inside the environment, but a cyber adversary might. Recovery requires a definition of a known-good state and evidence that the organization has reached it. Identity is part of that recovery state, since restoring applications and data without confidence in the identities that can access them leaves part of the environment untrusted.
Sequence matters as well. Applications may depend on identity, data, infrastructure and other services, and recovery plans need to account for those dependencies so that restoring individual components results in a usable business service.
AI Complicates the Definition of a Trusted State
As AI becomes part of business processes, an AI service used for employee productivity may be convenient but nonessential, while an AI system embedded in customer service, software development, fraud detection, logistics or another operational workflow may become part of how the business performs critical work. Organizations need to understand how those processes operate if the model or service becomes unavailable or the data feeding it can no longer be trusted.
Agentic systems introduce a harder recovery problem because they can change the environment before anyone realizes something is wrong. If an agent has created records, modified data, initiated transactions or triggered downstream workflows, restoring the agent itself does not reverse the work it already performed. Recovery may instead require reconstructing the sequence of actions the agent took, determining which systems and processes were affected, and deciding where the business process needs to resume or be rolled back. This is where the governance layer from the second piece in this series does double duty: an agent’s actions can only be reconstructed if its authority and activity were tracked clearly enough in the first place.
That requirement should influence how enterprises design AI-enabled workflows now. Material actions need to be attributable and traceable. Organizations need to understand which changes can be reversed, which processes can shift to an alternative operating procedure and how work continues if an AI component becomes unavailable or untrusted.
Resilience Has to Be Tested at the Business Level
A recovery plan remains an assumption until the organization exercises it. Traditional tests often establish whether backups can be restored, infrastructure can be rebuilt or applications can be brought online, and those exercises provide important evidence, but they don’t necessarily demonstrate whether the business can operate.
A stronger exercise starts with an operational scenario: a critical identity service is compromised, employees lose access to essential applications, a production environment becomes unavailable, a third-party service goes offline, or an agent makes unauthorized changes across several systems. The test then follows the business operation. Can employees perform the work? Can customers access the service? Can the organization operate in a degraded mode? Do teams understand the recovery sequence?
Exercises also need to establish who determines when an environment is trusted enough to reconnect and who has authority to make tradeoffs between security and operational continuity, bringing security, IT, engineering, recovery teams and business owners into the same decision process well before an actual incident does it for them. Testing at this level can expose gaps that infrastructure recovery tests miss, including incorrect assumptions about dependencies, recovery priorities and what the business actually needs to operate.
Cyber Resilience Is a Business Capability
Prevention, detection and containment remain fundamental to cybersecurity, but enterprises also have to prepare for attacks that get through and critical systems that become unavailable or untrusted.
AI raises the pressure on that model. Attackers can move faster, enterprises are becoming more dependent on AI-enabled processes, and agents can make changes across systems that complicate recovery. Resilience now encompasses the state of the business process as well as the technology supporting it.
Those decisions need to be made and tested before an incident, built around the operations the organization actually needs to protect, continue and recover, not the infrastructure underneath them. The real measure of recovery is whether the business can safely get back to work, which is a higher bar than whether the technology comes back online.
This is the third piece in our post-Black Hat series. Next, we’ll examine what these changes mean for the CISO as security becomes more deeply involved in how the enterprise adopts technology, manages operational risk and maintains resilience.
