RC.RP-02: Recovery actions are selected, scoped, prioritized, and performed

The rc.rp-02: recovery actions are selected, scoped, prioritized, and performed requirement is where many recovery programs fail in audits: teams can describe recovery goals, but can’t show how they consistently decide what to do first, what “done” means, and how recovery work gets executed under pressure. RC.RP-02 pushes you past general disaster recovery planning into operational discipline that stands up during a real outage, ransomware event, cloud service disruption, or major data integrity issue.

For a CCO or GRC lead, the fastest path is to treat recovery actions like any other controlled operational process: intake, triage, scoping, approval, execution, and verification, with evidence at each step. This requirement also bridges cyber incident response and broader resilience. Some recovery actions are technical (restore from backups, rebuild servers, rotate secrets); others are business-facing (restore customer communications, re-enable payments, reconcile data, coordinate with a third party).

If you build a repeatable recovery action lifecycle, assign owners, and capture objective evidence from both tests and actual events, you will meet RC.RP-02 expectations and reduce time-to-recover in practice. The implementation guidance below is written for operators who need to stand up something defensible quickly, then mature it over time. ¹

Regulatory text

Text (excerpt): “Recovery actions are selected, scoped, prioritized, and performed.” ²

What the operator must do:
You must run recovery as a controlled set of decisions and actions, not an ad hoc scramble. That means:

• Selected: You have defined recovery action options (by scenario/system/service) and decision criteria for choosing among them.
• Scoped: Each recovery action has boundaries (systems, data sets, users, environments), preconditions, and dependencies.
• Prioritized: You rank actions based on business impact, safety, regulatory impact, and technical dependencies.
• Performed: You execute actions through authorized runbooks and change pathways, then verify outcomes and capture evidence.

A useful mental model: RC.RP-02 expects a “recovery operations pipeline” that can be demonstrated with documentation and records from tests and real recoveries. ¹

Plain-English interpretation

RC.RP-02 means you can answer, with proof:

1. What recovery actions are available to you for your critical services (and common failure scenarios).
2. How you decide which actions to take first when time is limited and information is imperfect.
3. How you define scope so teams don’t restore the wrong thing, miss a dependency, or reintroduce corrupted data.
4. How you execute and validate recovery, including sign-offs and post-recovery learning.

This is not limited to IT. If a third party hosts a core platform, recovery actions must include the coordination steps, escalation paths, and “what you do if they can’t meet your needs.” ¹

Who it applies to (entity and operational context)

Applies to: Any organization operating a cybersecurity program and responsible for recovering services, systems, or data after disruption. ¹

Operational contexts where RC.RP-02 is directly tested:

• Ransomware, destructive malware, and credential compromise recoveries
• Cloud region failure, SaaS outage, identity provider outage
• Data corruption, failed deployments, broken integrations
• Third-party disruptions affecting critical services
• Business continuity events requiring technology restoration sequencing

Control ownership (typical):

• Primary: IT Operations / SRE / Infrastructure, Incident Response, and BC/DR leads
• Accountable: CIO/CISO (execution), business service owners (priority decisions), GRC (governance and evidence)
• Consulted: Legal/Privacy, Risk, Comms, Vendor/Third-Party Management

What you actually need to do (step-by-step)

1) Define your “recovery action catalog” per critical service

Build a structured list of recovery actions aligned to critical services (not just assets). For each critical service, record:

• Recovery action name (e.g., “restore database from immutable backup to clean environment”)
• Triggering scenarios (ransomware, corruption, outage)
• Preconditions (backup availability, clean credentials, golden images)
• Dependencies (identity, network, DNS, third parties, keys/certs)
• Validation steps (data integrity checks, functional smoke tests)
• Required approvals (service owner, security, change authority)
• Owner and on-call team

Keep it short enough to run during a crisis. Store it where responders will find it. ¹

2) Establish scoping rules that prevent “partial restores” and “dirty restores”

Scope must be explicit. For each action, define:

• Systems/infrastructure scope: prod vs non-prod, regions, accounts/subscriptions
• Data scope: time range, tables/objects, customer cohorts, logs
• Identity scope: which accounts must be rotated/disabled, how access is restored
• Containment boundaries: what must stay isolated until validated
• Third-party scope: which providers must be contacted, what evidence you need from them, what alternative actions exist

Create a one-page “scoping checklist” for incident command. Most audit findings come from missing scope definition and weak dependency mapping. ¹

3) Define prioritization logic that a non-technical executive can defend

Write down how you prioritize recovery actions. Use a simple decision matrix that includes:

• Customer impact / revenue impact (qualitative tiers are fine)
• Safety and legal/regulatory exposure (e.g., integrity of records, privacy risk)
• Operational dependencies (must restore identity before apps; must restore network before data replication)
• Time sensitivity (what becomes unrecoverable if delayed)
• Resource constraints (key staff, access, tooling)

Practical tip: prioritize by service restoration sequence, then map technical tasks under each service milestone. This helps you avoid optimizing for a single system while the end-to-end service remains down.

Record the priority decision during incidents (who decided, on what basis). That record is part of “performed” in RC.RP-02 because it shows controlled execution, not improvisation. ¹

4) Convert recovery actions into executable runbooks with completion criteria

For the top critical services, make runbooks that include:

• Exact steps (commands/scripts where appropriate)
• Required access and break-glass steps
• Rollback points and stop conditions
• Evidence to capture during execution (screenshots, logs, ticket references)
• “Definition of done” (service-level checks, monitoring thresholds, reconciliation)

Keep runbooks aligned to your change management path. If emergency change is allowed, define what evidence is required after the fact. ¹

5) Execute recovery actions through controlled workflows

During an event or exercise:

• Open a recovery ticket/war room record and link all actions to it
• Assign each action to an owner with a timestamp and expected completion outcome
• Track status (not started/in progress/blocked/complete/validated)
• Capture blockers and decisions (especially scope changes and priority changes)
• Validate recovery outcomes with predefined checks, not “it looks okay”

This produces the audit trail RC.RP-02 expects: selected, scoped, prioritized, performed, and verified. ¹

6) Perform a post-recovery review and feed a recovery backlog

After action:

• Document what actions were taken, what changed, and what evidence supports successful restoration
• Identify gaps (missing runbooks, missing access, backup failures, third-party contact failures)
• Create remediation items with owners and due dates
• Update the catalog/runbooks and prioritization rules

Treat this as continuous improvement. If you only test annually, your recovery actions drift from reality. ¹

Required evidence and artifacts to retain

Keep evidence that proves both design (you planned) and operation (you did it).

Core artifacts (minimum set):

• Recovery action catalog mapped to critical services (with owners and dependencies)
• Recovery scoping checklist/template and completed examples from exercises/incidents
• Prioritization matrix and documented prioritization decisions for at least one event/exercise
• Runbooks for high-impact recovery actions (version-controlled)
• Exercise reports (tabletop and technical) with outcomes and corrective actions
• Incident records showing recovery actions executed (tickets, change records, war room notes)
• Validation evidence (monitoring snapshots, test results, reconciliation logs)
• Post-recovery review reports and tracked remediation backlog

Operational proof points auditors like:

• “Before/after” timestamps showing execution flow
• Explicit scope statements (what was included/excluded)
• Evidence of dependency sequencing decisions
• Demonstrated coordination steps for third parties (emails, portal tickets, call logs)

Where Daydream fits (earned mention): Daydream can serve as the control system of record that maps RC.RP-02 to owners, procedures, and recurring evidence collection, so you are not rebuilding audit binders from scratch after every event. ²

Common exam/audit questions and hangups

Questions you should be ready to answer with artifacts:

• “Show me how you decide recovery priorities across services during an incident.”
• “Where is recovery scope defined, and how do you prevent restoring corrupted data?”
• “Which recovery actions are pre-approved vs require explicit authorization?”
• “Provide evidence you performed recovery actions during your last incident or exercise.”
• “How do you handle recovery dependencies on third parties?”

Hangups that trigger findings:

• Runbooks exist but aren’t tied to business services or priority decisions.
• Teams can’t show validation steps; recovery “completed” equals “systems booted.”
• Dependency gaps: identity/DNS/network restore sequencing is undocumented.
• Third-party recovery responsibilities are assumed, not documented or tested.

Frequent implementation mistakes and how to avoid them

1. Mistake: treating RC.RP-02 as “we have backups.”
   Avoid it: map recovery actions beyond backups, including identity recovery, key rotation, integrity checks, and customer-impacting business steps. ¹

2. Mistake: no defined scoping method, so scope changes mid-incident are chaotic.
   Avoid it: enforce a scoping template and require an explicit scope statement in the incident record. ¹

3. Mistake: prioritization is implicit and depends on who is loudest.
   Avoid it: publish a prioritization matrix approved by business owners; record who made the call during incidents. ¹

4. Mistake: runbooks exist but are outdated and not exercised.
   Avoid it: require updates after every incident/exercise; track changes in version control and keep a remediation backlog. ¹

5. Mistake: third-party dependencies are missing from recovery actions.
   Avoid it: add explicit “third-party coordination steps” and alternates (workarounds, degraded modes, exit options) for critical services. ¹

Enforcement context and risk implications

NIST CSF is a framework, not a regulator, so this page does not cite direct NIST “penalties.” Your risk comes from downstream obligations and examiner expectations where NIST CSF is adopted as a benchmark or referenced in contracts, customer security requirements, cyber insurance underwriting, and sector guidance. The practical exposure is operational: if you cannot prove that recovery actions were selected, scoped, prioritized, and performed, you may face adverse audit findings, failed customer diligence, and increased impact from real incidents due to slower, less controlled recovery. ¹

A practical 30/60/90-day execution plan

First 30 days (stand up the minimum defensible workflow)

• Assign an RC.RP-02 control owner and define RACI across IR, IT ops, BC/DR, and service owners.
• Identify critical services and pick the highest-impact subset to operationalize first.
• Create a recovery action catalog template and populate it for that subset.
• Publish a scoping checklist and a prioritization matrix draft.
• Decide where evidence will live (GRC repository, ticketing system, version control).

By 60 days (make it executable and testable)

• Convert the highest-priority recovery actions into runbooks with validation steps.
• Integrate recovery actions into incident management workflows (tickets, war room notes, change records).
• Run at least one tabletop focused on prioritization and scoping decisions; produce an after-action report and backlog.

By 90 days (prove operation and close evidence gaps)

• Run a technical recovery exercise for at least one critical service path (restore + validate).
• Collect execution evidence end-to-end and confirm it is retrievable for audit.
• Review third-party dependencies for critical services; add coordination steps and alternates to the catalog.
• Track remediation items to closure; update runbooks and decision matrices based on lessons learned.

Frequently Asked Questions

Do we need to document recovery actions for every system?

Start with critical services and the systems that support them, then expand. Auditors usually accept a risk-based scope if you can show prioritization and a plan to mature coverage. ¹

What’s the difference between “scoped” and “prioritized” in practice?

Scope defines the boundaries of the recovery action (what’s included, excluded, and dependent). Priority defines the order you execute actions across services and tasks based on impact and dependencies. ¹

Can incident response runbooks count as recovery actions?

Yes, if they include restoration steps and validation criteria, not only containment and eradication. Map the runbook steps to specific recovery actions in your catalog so selection and prioritization are explicit. ¹

How do we handle third-party recovery actions we don’t control?

Document coordination actions you do control: escalation paths, required status updates, evidence you request, and internal workaround steps. Tie those actions to service dependencies and prioritization logic. ¹

What evidence is “good enough” if we haven’t had a real incident lately?

Technical recovery exercises plus tabletop exercises can demonstrate operation if they show selection, scoping, prioritization decisions, execution, and validation outputs. Keep the complete record package. ¹

We have DR plans in PDFs. Why isn’t that sufficient for RC.RP-02?

PDFs often describe intentions but don’t show controlled execution or decision records. RC.RP-02 expects repeatable selection, scoping, prioritization, and performed actions with timestamps and validation evidence. ¹

Footnotes

1. NIST CSWP 29

2. NIST CSWP 29; NIST CSF 1.1 to 2.0 Core Transition Changes