Resilience Is a Business Issue
The recent Boston Scientific cyberattack is a reminder that cyber resilience is not only about protecting IT systems. It is about maintaining critical business operations when parts of the environment are compromised, degraded, or unavailable.
While the root cause and full impact of the incident remain under investigation, the reported disruption to business applications and customer order processing highlights a broader issue for all large, distributed organizations: a cyber incident becomes a business crisis when teams cannot see what is happening quickly enough, cannot contain the disruption effectively, or cannot keep essential services running during investigation and recovery.
For healthcare, medtech, manufacturing, logistics, and other highly connected industries, this distinction matters. These organizations do not operate around a single system, a single site, or a single security control. They depend on interconnected applications, suppliers, plants, cloud services, identity systems, network services, and operational processes. When one part of that environment is disrupted, the impact can move quickly from IT to operations, customer service, supply chain execution, and reputation.
Visibility Must Come First
That is why resilience must begin with visibility. Security and infrastructure teams need to know what normal activity looks like across the environment, so unusual behavior can be detected early. This visibility cannot rely on one tool or one telemetry source. Endpoint, network, identity, application, cloud, and infrastructure data all provide different pieces of the picture. The earlier teams can identify abnormal activity, the faster they can assess which systems and processes may be affected.
Visibility alone is not enough. It must translate into rapid containment. Once suspicious activity is identified, organizations need the ability to isolate affected systems, restrict malicious communication, and prevent a localized compromise from spreading across regions, business units, or operational environments.
This is where many resilience plans are tested. Containment must be fast enough to limit the attacker but controlled enough not to create additional business disruption.
Plan for Partial Failure
Organizations also need to plan for partial failure. In a real incident, the goal is rarely to keep every system running perfectly. A more realistic objective is to preserve the services that are most critical to safety, customer commitments, and business continuity.
That requires clear prioritization before an incident occurs. Teams should know which applications support core operations, which dependencies those applications have, which fallback procedures exist, and which recovery sequence matters most.
Core network services deserve particular attention in this model. DNS, DHCP, and IP address management are often treated as background infrastructure, but they are essential to how users, devices, and applications communicate.
DNS in particular can support both visibility and response. DNS traffic can provide insight into communication patterns across applications, devices, and infrastructure, helping teams identify unusual activity and add context during an investigation. It can also support containment when combined with appropriate filtering and policy controls.
Resilience Requires Layers
The larger lesson, however, is not that any single technology solves resilience. It does not. Resilience comes from layered preparation: early detection, strong containment, segmented architecture, resilient infrastructure, tested recovery plans, and practiced coordination between security, network, infrastructure, application, and business teams.
Organizations should use incidents like this to ask practical questions. Can we identify abnormal activity early across our global environment? Do we know which systems support our most critical business processes? Can we isolate affected systems without taking down entire operations? Are our core network services resilient enough to operate during a crisis? Have we tested recovery procedures under realistic pressure, or only documented them?
The answers to these questions determine whether an incident remains manageable or becomes prolonged business disruption.
The Real Goal Is Continuity
Prevention is still important, but prevention alone is not a resilience strategy. Modern organizations must assume some controls will fail, some systems will become unavailable, and some decisions will need to be made with incomplete information.
Organizations that recover best are usually not those that expected every attack to be blocked. They are the ones that are prepared to detect quickly, contain decisively, operate through disruption, and recover in a controlled way.
Cyber resilience is ultimately a business discipline, not only a security function. It connects infrastructure design, operational readiness, incident response, and executive decision making. The goal is not simply to restore systems after an attack. The goal is to protect the organization’s ability to keep serving customers, patients, partners, and employees when it matters most.
