teiss – Cyber Risk Management

It’s tempting to assume that when an organisation suffers a cyber-security breach, its defences must have been seriously flawed. Yet core safeguards are already widespread, with the UK government’s 2025 Cyber Security Breaches Survey finding that 77% of businesses used updated malware protection and 72% had network firewalls. Important as these tools are, however, their presence alone cannot guarantee that security will hold up during an attack.

Part of the problem is that a live incident introduces variables that can cause trusted security measures to perform unexpectedly. For example, security teams must typically deal with attacks using incomplete information and under intense time pressure. Incidents can also expose resilience weaknesses that remain hidden during routine operations, and attackers rely on this uncertainty to exploit gaps that emerge in identity controls and recovery arrangements when those controls and arrangements fail to withstand such conditions.

If we accept the premise that, for almost everyone, being targeted is not a question of if but when, being breached must also be a realistic possibility. It therefore stands to reason that there must be much more emphasis on how well each organisation can re-establish trusted operations.

Identity is a resilience issue 

Take identity breaches, for example. Verizon’s 2026 Data Breach Investigations Report found that credential abuse was involved in 39% of breaches, even where it was not the attacker’s initial route into an organisation.

Among the various issues that arise, orphaned accounts and lingering privileged access can easily persist in an environment. Service accounts may also suffer from a lack of clear ownership, making their access harder to review or revoke. Wherever the problem actually lies, identities can provide an attacker with a route into connected systems during an incident.

During recovery, organisations can inadvertently restore compromised accounts or permissions, potentially giving attackers continued access to the restored environment. Data and applications cannot return to normal use until approved users and systems can authenticate securely.

Instead, the recovery process requires access to a known-good identity environment that can be verified before affected systems are returned to service. Yet this approach is far from ubiquitous, with fewer than 25% of organisations surveyed by IDC having documented and tested their Active Directory and Microsoft Entra ID recovery capabilities.

The role of ResOps 

In reality, an organisation’s ability to recover depends on decisions made across security and recovery functions before an incident occurs. Resilience Operations (ResOps) is the formal representation of this approach and provides a framework for coordinating this work around the shared objective of keeping the business operational during disruptions.

It brings recovery considerations into security planning, so that teams can identify the dependencies between critical business services and the technology needed to support them before they become obstacles to restoration. For example, a customer-facing application may be restored quickly yet remain unusable until its identity service is available. A production system may also depend on a database that needs to be recovered first.

Organisations that understand these dependencies and have processes in place to address them can create a more active approach to resilience, grounded in testing and evidence. Testing should examine how a control might fail and the effect that failure would have on operations. Based on this insight, recovery exercises then need to reflect realistic constraints, including incomplete information and pressure on decision-makers.

Teams should validate that they can restore a clean environment without carrying the original compromise into the recovered systems. A useful measure is the time required to re-establish trusted operations in practice, rather than the recovery time assumed on paper. The results should reveal gaps that need to be addressed before a real incident exposes them.

Putting ResOps into practice 

Sounds great on paper, but how does a ResOps-centric organisation actually perform during a cyber-security incident compared with one that relies on static recovery processes?

Imagine a manufacturer hit by ransomware that takes its production scheduling system offline. A static recovery plan may focus on restoring the core platform, only to discover that it cannot return to service until a dependent database has been recovered and verified.

A ResOps approach identifies that dependency through earlier testing and sets the recovery sequence accordingly. The business can then restore the database first and bring the scheduling system back online in a known-good state, limiting the time production is disrupted.

The difference is not simply that one organisation restores technology faster. A ResOps-led manufacturer has already agreed which services must return first, who can make critical decisions, and what evidence is needed before systems can be trusted. Its findings then feed into recovery plans and future testing, allowing resilience to improve as the environment changes.

Within a ResOps model, exercises such as this provide evidence of whether an organisation can re-establish trusted operations within the time the business can tolerate. Rather than treating recovery as a one-off technical task, it becomes an ongoing operational discipline. Ultimately, resilience is not demonstrated by the existence of a plan, but by the organisation’s ability to restore the services the business depends on securely and within an acceptable timeframe.

Darren Thomson is Field CTO at Commvault 

Main image courtesy of iStockPhoto.com and narvo vexar