A Recovery Exercise Should Assume the Administrator Cannot Be Trusted

Recovery planning becomes more demanding when the exercise assumes the normal administrator account is compromised, rather than merely unavailable.

The exercise needs a harder starting condition

A recovery test can look successful because the team still has everything it would lose during the incident it claims to rehearse. The normal administrator account works. The backup console is accessible. The network is trusted. Restoring a file under those conditions proves something useful, but narrower than the ability to recover after a serious compromise.

NIST’s Guide for Cybersecurity Event Recovery, published in December 2016, describes recovery planning, playbooks, realistic scenarios, testing and improvement. Its public abstract emphasises identifying and prioritising organisational resources. This article uses that established planning principle to examine a particular scenario: what if the people restoring service cannot initially trust the identity that normally controls it? It is not a report of a new vulnerability or a claim that every organisation faces an identical attack.

List the decisions that require separate authority

Consider a hypothetical company whose administrator controls production systems and the backup management account. Its exercise should ask who can establish an authorised recovery route if that identity is suspected of compromise. Simply asking the administrator to log in elsewhere does not resolve the trust question. It moves the same assumption to a different screen.

The practical task belongs with qualified security and continuity specialists. They should identify which recovery actions require independent authorisation, where the supporting records reside and which credentials can be used safely. The exercise should record unresolved dependencies rather than quietly granting temporary privileges that would not exist during a real incident. A discovered gap is useful evidence; a bypass concealed from the report is not.

Recover to a place with a defined purpose

A restoration environment needs an explicit role. Is it intended to inspect recovered data, verify an application or resume business activity? Those are different stages. Treating them as interchangeable can make it difficult to explain when a restored system became suitable for users to trust.

In a hypothetical rehearsal, a team could restore a representative application into an isolated test environment and document the checks needed before any reconnection. The required checks depend on the incident scenario and architecture; a generic editorial checklist cannot determine that a system is clean. The management question is whether someone is responsible for deciding what evidence is sufficient and for documenting why the decision was made.

The order of restoration is a business choice

Teams may be tempted to restore the easiest application first because it produces visible progress. A better exercise connects restoration order to the activities the organisation must resume. A working dashboard may be less urgent than the identity, communications or reference data on which an essential service depends.

The dependency map should reveal whether the chosen order is possible. If an application requires a service that is still unavailable, the plan must acknowledge the obstacle. Business owners should also state the minimum usable function. A reduced service may be worthwhile if users understand its limits. Reporting a server as restored while the necessary business process remains unusable creates a technically accurate but operationally misleading result.

Measure elapsed time honestly

The clock should include the delays that belong to the scenario: contacting authorised decision-makers, locating records, obtaining replacement equipment and resolving uncertainty about the recovered data. Excluding those stages may be appropriate for a narrowly defined technical benchmark. It is inappropriate when the reported result claims to represent the full return to operation.

Useful exercise records separate the stages and explain what was simulated. For example, a team might have verified the application restore while assuming replacement hardware was already present. That is a valid limited test. It should lead to another question about procurement and readiness, rather than become a confident promise that the entire company can resume work within the measured interval.

Keep the evidence useful after the rehearsal

A recovery report should identify failed assumptions, responsible owners and the next action. Statements such as communication needs improvement leave too much unresolved. A more useful finding names the missing contact route, the information that could not be retrieved or the approval that depended on an unavailable person.

Corrections need a subsequent check. Updating a document does not prove that the revised process works. Rehearsing a specific failed step may be enough; every finding need not trigger a complete exercise. What matters is the connection between discovery and demonstrated improvement. The exercise should become a source of operational evidence, not an annual performance in which everybody knows the expected conclusion beforehand.

A credible recovery promise includes its trust assumptions

The difference from an ordinary backup check is the starting point. Here the question concerns authority and confidence in the restoration process, not simply whether a copy of a file exists. A company should be able to explain who can begin recovery, which identities are trusted and what happens if the usual control route is unavailable or suspect.

No exercise can establish resilience against every future event. It can establish that named people have tested a defined scenario and resolved particular obstacles. That is a more credible promise than an impressive recovery time detached from its conditions. A useful rehearsal makes the assumptions visible enough to challenge before a real disruption makes them expensive.

Gabriel Nicolaev — CyGuru

Sources & further reading

NIST SP 800-184: Guide for Cybersecurity Event Recovery, December 2016 ↗

Editorial photograph for illustration.

FOLLOW THE CONNECTION

Another angle on this subject

Continue through related ideas, decisions and consequences.

Technology & AI

Passkeys Need an Exit Plan as Well as an Enrolment Screen

A passkey rollout should explain device loss, provider changes and account recovery with the same clarity as its first successful sign-in.

Human Behaviour

When Staying Becomes More Expensive Than Leaving

Past effort can make a failing commitment feel impossible to abandon, even when the future offers a better use of resources.

Technology & AI

An Automated Service Should Hand Over the Uncertainty

A design essay on escalation: a human needs the unresolved question, relevant context and authority to act, rather than a forwarded conversation alone.