Cyber Resilience Board Briefing Series 1: Recovery vs Recovery to a Trusted State
The Issue
In most organisations, “recovery” is treated as a technical milestone: systems are restored, applications come back online, users regain access and the business resumes operations.
Everyone congratulates each other, this has been a success. The reality is this is frequently where the real risk begins.
Why This Matters at Board Level
Boards are ultimately accountable not just for whether an organisation recovers, but what state it recovers into. In a significant proportion of the destructive cyber incidents I’ve deal with:
Initial access is not fully understood at the point of recovery
Attack surface that the adversary exploited has not been discovered and remediated
Identity systems may still be compromised
Persistence mechanisms remain embedded in the environment
Decisions are made under time pressure with incomplete evidence
The result is a dangerous scenario: The organisation resumes operations on an environment that cannot be trusted. Just to be clear, this is not a technical oversight, it is a governance failure: specifically, a failure to define and enforce the conditions under which recovery is deemed acceptable.
Recovery vs Trusted State: The Distinction
Recovery (a technical outcome)
Systems restored from backup
Services operational
Users able to access applications
Recovery to a Trusted State (a governance outcome)
Identity systems validated and re-established with confidence
Privileged access reviewed, reset, and controlled
Persistence mechanisms identified and eradicated
Attack pathways and vulnerabilities understood and addressed
Recovery decisions supported by sufficient evidence
Control gaps addressed
The difference is subtle in reporting, but material in risk exposure. Recovery is about rebuilding data, trusted state recovery is about rebuilding trust.
Where Organisations Commonly Fail
Across the hundreds of real-world incidents I’ve been involved in, the same patterns emerge:
Premature Restoration of Identity: Identity systems (e.g. Active Directory) are brought back online quickly to restore business functionality, without sufficient assurance that they are clean. This often leads to rapid reinfection or continued attacker access.
Assumption of Backup Integrity: Backups are treated as inherently safe or restored after cursory scans that declare the first snapshot without a malware or Indicator of Compromise match is “clean”. In reality, they may contain:
Undetected persistence
Compromised configurations
Latent attacker access paths
Lack of Defined Recovery Conditions: Many organisations have recovery plans, but few have explicit criteria for what constitutes a “safe” recovery. This leads to:
Inconsistent decision-making
Over-reliance on individual judgement under pressure
Misalignment between IT, Security, and business leadership
Pressure-Driven Decision Making: Operational and commercial pressure drives rapid restoration. Without predefined governance, the default decision becomes: “Get back online as quickly as possible”, even when doing so increases long-term risk.
The Board’s Role
This is not an issue that can be delegated entirely to technical teams. Boards should ensure that:
Recovery Criteria Are Defined in Advance
What conditions must be met before systems are restored?
What level of assurance is required for identity, access, and control planes?
Decision Rights Are Explicit
Who has authority to approve recovery under uncertainty?
How are trade-offs between speed and assurance made?
Recovery is Aligned to Risk Appetite
What level of residual risk is acceptable to resume operations?
How is this evidenced and documented?
Testing Reflects Reality
Are recovery exercises testing technical restoration only or decision-making under degraded trust?
Do simulations include compromised identity and incomplete information?
A Practical Analogy
Restoring systems after a cyberattack without validating trust is like reopening a building after a fire:
The structure may be intact
The lights may be on
People can walk back in
However, if the wiring is still damaged and the fire source hasn’t been fully identified, you haven’t solved the problem, you’ve just made it operational again under hidden risk.
Key Takeaways for the Board
Recovery is not the objective. Trusted recovery is.
The most significant risks often emerge after systems come back online
Governance, not technology, determines whether recovery is safe
Clear decision frameworks reduce risk under pressure
Identity is typically the critical dependency in establishing trust
What to Ask Your Executive Team
How do we define a “trusted state” in our recovery process?
What assurance do we require before restoring identity systems?
How do we validate that backups are safe to use?
Who makes the decision to resume operations under uncertainty?
Have we tested recovery scenarios where identity and control planes are compromised?
Closing Thought
In many of the most damaging incidents, the organisation did recover, the problem was the state that they recovered into.
Next Briefing
Identity as the Critical Path: Why Most Recoveries Fail Before They Begin
