The Goal Is Not
Perfect Prevention

Your board can be shown how much of the estate is patched, where multifactor authentication is enforced and whether the latest backup completed. Each measure deserves attention. Yet the report may leave a consequential question unanswered: if a critical service has to be restricted tomorrow, what can your organisation still deliver safely, and for how long?

When Prepared Does Not Mean Ready raises the gap between preparation and usable readiness. The next task is to define what readiness must achieve once an incident interrupts normal operations. A response plan and a recovery target need to connect to a service the organisation can actually sustain.

Prevention remains essential. Reducing the likelihood of compromise and addressing known weaknesses are continuing responsibilities. Planning for a compromise does not excuse a preventable failure. It gives your organisation a second responsibility: to limit the consequences and retain usable choices if the first line of defence is bypassed.

Operational survivability begins with a specific service, rather than a promise that the whole organisation will keep running. Which function matters most if normal systems are unavailable? What information does it need, who can perform it and what level of reduced service would remain acceptable?

Consider an illustrative healthcare setting. A hospital has a downtime procedure for an essential clinical service. Staff know where to find it, and the main application has a recovery plan. The remaining question is whether the clinical team can obtain sufficiently current information and communicate safely if access to a shared identity service has to be restricted.

The application may still be running while staff cannot use it. A fallback may exist but depend on the same login, network storage or communications service that is now unavailable. Even an independent alternative needs enough trained people and a way to handle the work it creates.

The clinical owner must judge whether that alternative supports safe care and where its limits lie. Security and infrastructure teams need to establish whether the required information and access can remain available without relying on the route being restricted. The executive team needs to understand the resulting service limits before treating the fallback as an operating option.

Keeping a service available in a reduced form can preserve an important function while the investigation continues. It also changes what people can reasonably rely on. In the hospital example, the fallback may support a defined clinical activity but provide less information or create additional checking work. That limitation needs to be understood by the people using it.

An agreed operating limit should describe what the service can support, what would require further restriction and when its use must be reviewed. A temporary process that works for one shift may become unsafe or unmanageable as the backlog grows. The organisation needs someone responsible for observing those conditions and escalating a change.

Sometimes the safe option is to suspend the service. Operational survivability includes recognising that limit and protecting people from an unsafe continuation. It also includes planning what happens to the work or demand that can no longer be handled locally. Decisions about acceptable degradation belong with the relevant service owners and executives, informed by security findings.

The CISO can help the executive team connect a credible compromise scenario to the service consequence. Operations then needs to demonstrate what can continue within the proposed restrictions. That joint work gives the board a more useful account than either security coverage or a continuity plan considered alone.

NIST CSF 2.0 places governance alongside the other cybersecurity functions and describes resilience mechanisms for adverse situations. Those outcomes support asking how the organisation’s arrangements work together. A framework mapping still needs evidence from your own environment.

Select an essential service and test a relevant dependency loss in a controlled setting. Establish whether the intended restriction takes effect and whether the alternative process remains usable. Where the test exposes a limit, record it, assign the necessary work and check the change before relying on the option.

The result need not be a perfect exercise. An unresolved dependence is useful information if it changes a decision about investment or service expectations. Report what was demonstrated, the conditions of the test and what remains unproven. A successful restoration of an application alone cannot establish that the people, information and supporting services required for delivery are ready.

Effective containment can reduce the harm that an active threat is able to cause. Its contribution to continuity depends on the activity interrupted and the services affected by the restriction. Your organisation needs to understand that scope before relying on it as part of an operating design.

Our platform’s Ransomware Containment capability monitors supported SMB and NFS file activity without endpoint agents and can isolate the responsible user or session when illegitimate active encryption is detected.

Additional Server Intrusion Protection (SIP) and Virtual Server Protection (VSP) features run on that platform. SIP extends protection to compromised server access, while VSP addresses attacks directed at supported hypervisor environments.

"The Foundation Failed While the Building Still Stood" follows the dependency beneath the fallback. Several services may have separate owners and applications while relying on the same infrastructure. The next article asks what remains controllable when that common foundation also supports the tools needed to investigate and recover.