Select, scope, prioritize, and perform recovery actions
Not all systems can be restored at once, and attempting to do so without a clear priority order wastes resources and can delay recovery of the most critical services. Recovery actions must be deliberately selected based on business impact, scoped to avoid re-introducing the threat, and sequenced so that critical functions come back online first. Without this discipline, teams risk spending hours restoring low-priority systems while customer-facing services remain down. This control ensures recovery effort is directed where it matters most.
Implementation steps
- 1
Review system criticality rankings and determine recovery priority order
Use your existing business impact analysis or system criticality inventory to rank affected systems. Identify which services have the lowest RTO and the highest downstream dependencies. Document the agreed-upon recovery sequence before any restoration work begins.
confluenceservicenowarcher - 2
Scope each recovery action to a specific system or service
For each item in the recovery sequence, define the exact scope: which environment, which components, which data sets. Scoping prevents partial or overlapping restores that can corrupt data or leave gaps. Document scope boundaries in the incident ticket before executing each step.
jiraservicenowconfluence - 3
Execute recovery actions in priority order and log each completed step
Begin restoration work on the highest-priority systems first, following the runbook steps. Log each action with a timestamp, the operator who performed it, and the outcome. If a step fails or deviates from the runbook, escalate immediately rather than improvising.
jiraservicenowslackpagerduty
Evidence required
Recovery prioritization record
Documentation showing how systems were ranked and the agreed-upon recovery sequence.
- · Business impact analysis excerpt with RTO targets per system
- · Recovery sequence decision log in the incident ticket
- · Spreadsheet or Confluence page listing systems in priority order
Scoped recovery task log
A record showing that each recovery action was scoped to a specific system or component before execution.
- · Jira subtasks with scope defined per system
- · Change records in ServiceNow specifying environment and components
- · Runbook steps annotated with scope boundaries
Recovery action execution log
A timestamped log of all recovery actions performed, including who performed them and the result of each step.
- · Incident ticket activity feed with timestamped updates
- · Operations log or runbook with steps checked off and dated
- · Chat log from the recovery channel showing step-by-step progress
Related controls
Re-establish critical mission functions and cybersecurity services
Incident Recovery Plan Execution
Execute the recovery plan once the incident response process initiates recovery
Incident Recovery Plan Execution
The integrity of restored assets is verified, the asset is deemed secure, and normal operating status is confirmed
Incident Recovery Plan Execution
Verify the integrity of backups and restoration assets before use
Incident Recovery Plan Execution