RC.RP-02 Recovery actions prioritized: requirements and evidence

How NIST CSF 2.0 RC.RP-02 sets the order of recovery work

RC.RP-02 asks whether recovery actions are chosen, scoped, ordered and carried out against criteria the organization set in advance, not against whoever is loudest during the incident. If you are a compliance lead or CISO, the question an assessor will put to you is simple: can you show which systems came back first, why, and who decided? Subcategory RC.RP-02 sits in the Incident Recovery Plan Execution (RC.RP) Category of the RECOVER Function in CSF 2.0. It absorbs part or all of CSF 1.1 RC.RP-1, so teams that already had a recovery plan line item will recognize the intent, but the 2.0 wording places more weight on adjusting actions as conditions change.

The risk is concrete. Without ordering rules, teams restore the system with the most pressure behind it rather than the one the business needs most, bring back an application before the identity service or data store it depends on, or send a small number of skilled engineers into low-value work while a payment or patient-facing service stays down. Recovery also drifts: an action that made sense on day one may no longer match the assets still affected or the people still available. The hard part is that these decisions happen under stress, with partial information, and often before the business impact records have been reviewed for the current incident.

Start by confirming three artifacts with your incident response and recovery owners: the criteria in the plan for selecting recovery actions, the business impact or criticality ranking those criteria draw on, and a record of who holds authority to change the sequence. Then ask for evidence of a past exercise or real event in which the sequence was revised and the reason was written down. NIST's Small Business Quick-Start Guide (SP 1300) cites this outcome when it suggests prioritizing recovery by business needs, available resources and the assets affected, which is a useful checklist even if you are not a small business. Use the NIST CSF 2.0 publication to confirm the outcome wording in Appendix A before you build evidence against it.

Which systems, teams and decisions fall under RC.RP-02 prioritization

RC.RP-02 only works if the recovery plan defines what it covers before anyone picks an action. The cards below cover the scoping decisions that change the work: which services are in the plan, who holds recovery roles, how outside providers are included, and how constraints on people and capacity are recorded.

Business services in the recovery plan

Start with the list of business services the plan must restore, not the list of servers. Each service should name its supporting applications, data stores, network paths and identity dependencies. RC.RP-02 asks you to prioritize recovery actions by the plan's criteria, so the criteria need a service-level anchor. Check that every in-scope service has a documented owner and that out-of-scope services are listed explicitly so no one assumes coverage.

Teams holding recovery roles

Record which teams and named individuals can select, approve and perform recovery actions, including their deputies for off-hours incidents. Recovery work often spans infrastructure, application owners, security, legal and communications, and a gap in any of them stalls prioritization. Confirm that each role has written authority to take the actions it is assigned and that those authorities match the plan's escalation path.

Third-party recovery dependencies

Hosting providers, managed service providers and SaaS vendors often control the systems you must recover first. Record each provider's recovery responsibilities, contact paths and the restoration commitments written into your contracts. Ask whether the provider's own recovery sequence can run in parallel with yours. Where a provider cannot be reached during an incident, the plan should say which internal action proceeds anyway.

Assets and backups in scope

Identify which backup sets, restore points and recovery copies apply to each in-scope service, and which system owns each one. Backup tooling such as Bareos keeps a catalog of backed-up files and can restore from a chosen date and time, which helps you decide what to bring back first. Confirm that the plan states which restore sources are trusted and which need verification before use.

Resource constraints and their record

Document the limits that shape prioritization: staff availability, recovery hardware capacity, bandwidth, licenses and budget authority. Record who may approve overtime, emergency purchases or vendor engagement. A constraint that is not written down tends to surface mid-incident as a reason to delay a higher-priority action, so review these records on the same cycle as the plan itself.

Decision log for changed priorities

Recovery priorities change as new facts arrive, for example when a system proves compromised or a dependency fails. Keep a timestamped log of each reprioritization, the criteria applied and the person who approved it. This record supports RC.RP-02's requirement to adjust actions as needs and resources are reassessed, and it gives later reviewers evidence for the after-action report.

How an assessor tests recovery action prioritization

This table walks through the four steps an assessor usually takes for RC.RP-02, the evidence each step asks for, and the findings that most often stop an organization from passing. Read it as a checklist to run against your own recovery plan before an assessment begins, since the same questions apply whether the review is internal, customer-driven or formal.

Assessment step	What the assessor checks	Evidence requested	Common finding
Review prioritization criteria	Whether the incident response plan states how recovery actions are ranked, such as business need, resources and affected assets	Approved incident response plan with version, approval record and the section defining prioritization criteria	Criteria exist only in an unapproved draft or in a team member's notes
Sample a past or exercised incident	Whether the recovery actions taken can be traced back to the stated criteria	Incident record, recovery task list, timestamps and the ordering decisions for a selected incident or tabletop exercise	Recovery order cannot be reconstructed because decisions were made verbally and never written down
Confirm resource availability was considered	Whether staffing, tooling, backup capacity and vendor access were weighed when actions were scheduled	Resource assessment or shift roster at the time of decision, plus notes on constraints such as backup restore capacity	Plan lists priorities but records no check of available people or systems before work started
Confirm actions were revised when needs changed	Whether planned actions were adjusted after the situation or resources changed, and the change was recorded	Change log, revised action list, and the reassessment meeting notes or chat record showing the reason for the change	Recovery plan was never updated after the scope of impact grew or a key system turned out to be unavailable
Check rationale for individual actions	Whether each selected or deferred action has a documented reason tied to a criterion	Decision log entries stating why an action was prioritized, deferred or dropped	Actions appear in the ticket system with no recorded rationale, so the assessor cannot test the link to criteria
Verify the role of the assessor	Whether the review relies on evidence the organization produced, with the independent assessor forming the conclusion	Evidence package indexed to RC.RP-02 and the sample selected by the assessor	Organization presents a self-written summary instead of underlying records, which weakens the test

Implementing RC.RP-02 step by step

This sequence turns RC.RP-02 from a policy statement into a working method: agreed criteria decide which recovery actions run first, the resources behind them are known, and the people allowed to change the order are named before an incident starts. Each step closes with an artifact that an assessor can read.

Define prioritization criteria from business impact
Start with the incident response plan's recovery criteria and the business impact records the organization already holds, then agree the factors that rank recovery actions, such as customer-facing impact, regulatory obligations, safety effects and dependencies between systems. Business and technology owners sign off together. The output is a short, dated criteria document that the incident response plan references. You know this step is done when each criterion can be applied to a named service without further interpretation.
Map asset dependencies to the criteria
Using the asset inventory and data flow maps, record which systems, identity services, networks and data stores each business service depends on. Dependencies decide the order: a database restore cannot finish before the directory service it authenticates against. The output is a dependency map that shows, for each service, the assets it needs and the assets it feeds. Confirm the map with the owners of the platforms, because an out-of-date map produces a wrong recovery order.
Assign candidate recovery actions to priority tiers
Take the recovery actions in the plan, such as restoring identity services, rebuilding a host, rotating credentials or re-enabling a integration, and place each one against the criteria and the dependency map. NIST's Small Business Quick-Start Guide (SP 1300, February 2024) suggests this same approach: prioritize recovery actions by business needs, available resources and the assets affected. Treat that guidance as NIST's suggestion to be adapted, not as a requirement. The output is a ranked action list where every action names its criteria, its prerequisites and its owner.
Record available recovery resources and limits
List the people, backup copies, restore hosts, bandwidth, vendor support contracts and out-of-hours cover that recovery can draw on, and note what each resource can do at the same time. Include backup tooling where it is used, for example a Bareos catalog or restic repositories, and record which restore points are known to exist and how far back they reach. The output is a resource register that the decision maker can read in minutes. Confirm capacity figures with the teams that run the resources, not from the plan document alone.
Agree who may change the recovery order
Name the role that can reorder, pause or add recovery actions during an incident, the conditions that trigger a review, and the people who must be told when the order changes. Record the escalation path to executive leadership for decisions with legal or customer impact. Write the authority into the incident response plan so responders do not need to find it during an event. The output is a decision authority table with named roles and alternates. You know it is done when a tabletop participant can say who changed a priority and why.
Run an exercise and record the decisions
Run a tabletop or technical exercise in which the team applies the criteria to a realistic scenario and reorders actions as new facts arrive, such as a restore point that proves unusable. Record each prioritization decision, the resources consulted and the authority used, and log where the criteria or dependency map failed. The output is an exercise report with timestamps, decisions and corrective actions tracked to owners. Keep the report as evidence for the assessor. Retain the findings for the continuous improvement work described under ID.IM.

Evidence that shows recovery actions were prioritized

An assessor testing RC.RP-02 looks for a clear chain from approved prioritization criteria to the recovery actions taken during an incident. The cards below cover the artifacts that form that chain and how to keep each one current between assessments.

Approved prioritization criteria

The written criteria the incident response plan uses to rank recovery actions, such as business impact, dependency order, data sensitivity and available staff. Assessors check that the criteria exist, were approved by an accountable owner, and match what the plan says. Keep them in version control with a named approver and a review date, so the version an auditor reads is the version responders used.

Recovery action log with rationale

A timestamped record of each recovery action, the asset or service it targeted, the criterion that ranked it, and who approved it. Gaps usually appear where responders acted verbally and the log was completed later. Check that entries are written during the incident, that times are synchronized across tools, and that skipped actions also carry a reason.

Resource availability records

Evidence of the people, backup capacity, recovery environments and vendor support available when priorities were set. This shows that the order of work reflected real constraints rather than an idealized plan. Ask for staffing rosters on call, capacity figures from the backup platform and the status of any third-party support contract at the time of the incident.

Change records for shifted priorities

When new facts moved a system up or down the queue, the change should appear in a change record that names the trigger, the new order and the approver. RC.RP-02 expects planned actions to be adjusted as needs and resources are reassessed, so these records prove the adjustment was deliberate. Confirm that emergency changes are reviewed after the event, not left undocumented.

Exercise and after-action notes

Notes from tabletop exercises, recovery tests and post-incident reviews that record how priorities were chosen and where the criteria worked or failed. Assessors use them to confirm the process improves over time, which connects to the improvement expectations of ID.IM. Track each finding to an owner and a closure date, and confirm that the updated criteria were approved.

Standing review cadence

A recurring schedule that re-reads the prioritization criteria, checks them against current asset inventories and business impact records, and records the outcome. Without it, criteria drift away from the systems the organization runs. Ask who owns the review, how often it occurs, and where the signed minutes or approval record is stored, then confirm the most recent cycle is dated and complete.

How the criteria, resources and reassessment fit together

RC.RP-02 asks for a decision path that runs in a fixed order. The criteria in the incident response plan come first: they define what counts as urgent, which business functions matter most and how the affected assets are classified. Those criteria select which recovery actions are candidates. Available resources come second. Staff with the right skills, backup capacity, recovery environments and vendor support limit how much can run at once and in what sequence. A recovery action that meets the criteria but cannot be staffed or staged is deferred, and the deferral should be recorded with its reason. Ask your team to show where the criteria are written down, who applies them during an incident and where the resulting decision is logged.

Reassessment is what keeps the path honest. Incident conditions change: new systems turn out to be affected, a restore path fails, or a dependency that was assumed healthy is not. The Implementation Examples for RC.RP-02 describe changing planned actions after needs and resources are reassessed, so the recovery lead should have a defined trigger and a cadence for that review, plus a way to record each change of order or scope. Confirm that the people empowered to reprioritize are named in the plan and that they can act without waiting for a full committee cycle.

The requirement is therefore about a documented, followed and adjustable process, not a fixed ranking of systems. An assessor will look for evidence that the criteria existed before the incident, that the choices made during it trace back to them, and that changes were captured. A ranked list written in advance that nobody consults during the event does not satisfy the outcome. Plan the process with the tabletop exercises and post-incident reviews that feed ID.IM, and keep the decision records alongside the recovery logs so the sequence can be reconstructed later.

What meeting RC.RP-02 costs in money and effort

This table breaks down the cost components of meeting RC.RP-02 by who is paid, whether each cost is one-time or recurring, and what drives it up or down. Use it to structure a request for quote, since NIST publishes no price data and every figure must come from your own written scope.

Cost component	Who is paid or who bears it	One-time or recurring	Main cost drivers
Criteria and prioritization rules	Internal staff, sometimes an outside consultant for facilitation	One-time, then reviewed on a set cycle	Number of business services in scope, number of recovery teams, depth of business impact records
Recovery plan approval and sign-off	Executives, legal, business owners and the incident response lead	Recurring with each plan revision	Number of approvers, how often the plan changes, whether resource decisions need board visibility
Tooling and platform licenses	Software vendors for commercial tools; no license fee for most open-source components	Open-source: no license spend; hosting and support recurring	Self-hosted infrastructure, backup storage capacity, support contracts if you buy them
Implementation and integration of backup and restore tooling	Internal platform engineers or an implementation partner under a fixed-scope agreement	One-time build, recurring upkeep	Number of backup targets, restore paths tested, integration with ticketing and asset inventory
Exercise and tabletop time	Internal recovery teams, facilitators, sometimes external exercise designers	Recurring at the frequency you set	Exercise frequency, number of recovery teams involved, whether live restores are included
Evidence upkeep	Internal compliance or security staff who record decisions, reprioritizations and reassessments	Recurring, usually per incident and per exercise	Volume of incidents, number of decisions logged, retention rules for records
External review or readiness assessment	Independent assessor or consultant, chosen by you	Usually one-time per cycle	Scope of review, number of systems sampled, whether the review is independent of the implementer
Auditor sampling	Independent auditor, paid by your organization	Recurring at each audit cycle	Number of recovery events sampled, quality and completeness of prioritization records, audit scope

Who owns RC.RP-02, who can help and where the auditor stops

Your organization owns RC.RP-02 in full. Someone accountable must decide which recovery actions run first, what each one touches, and when the sequence changes. The subcategory expects selection to follow the criteria in your incident response plan and the resources you actually have, so those criteria and resource records must exist in writing before an incident begins. Security, IT operations and business owners share this work, and an accountable executive should approve priorities that trade one service against another.

Written criteria. Document how recovery actions are ranked, such as business impact, data sensitivity and dependency order, and state where those criteria live.
Current resource records. Keep staffing, on-call rotations and backup capacity up to date so prioritization reflects what the team can perform.
Decision log. Record each action selected, deferred or changed, with the reason and time, because this log is the main evidence for the adjustment step.
Reassessment triggers. Name the events that reopen priorities, such as new indicators of compromise or a failed restore.

Confirm that a named role can change the recovery sequence during an incident without waiting for a committee.

RC.RP-02 questions buyers ask before hiring help

How much effort does RC.RP-02 take to meet?

The effort depends on how much recovery planning already exists and how many systems the plan covers. RC.RP-02 asks that recovery actions be selected, scoped, prioritized and performed against the criteria in the incident response plan, so the first question is whether those criteria are written down. If they are, the work is mostly building a prioritization method, testing it against realistic incident scenarios and recording decisions. If they are not, the work starts earlier, with business impact records and asset inventories that the prioritization depends on. Ask any partner to split the effort into planning, technical preparation and evidence collection, and to state which parts recur after each exercise or real incident.

Can we meet RC.RP-02 with our own team?

Yes, in many organizations the core decisions can be owned in-house, because the organization is always responsible for its own controls. The harder part is usually the preparation: keeping the plan current, confirming that backup and restore tooling works, and proving that the team can execute the plan under pressure. NIST's Implementation Examples for RC.RP-02 point to using the incident response plan's criteria and available resources, which means someone must own those criteria and reassess them when resources change. Teams that already run incident response exercises often need less outside help. Teams with little recovery experience may find an implementation partner useful for building the method and the evidence trail, while keeping decision rights internal.

What skills and access does the team need for this work?

The team needs people who understand business processes, technical dependencies and the backup and restore platform. A recovery prioritization decision needs input from business owners who can say which service matters most, from infrastructure staff who know what depends on what, and from whoever is authorized to approve recovery steps. Technical staff also need hands-on access to the backup platform, for example to run restores in a test environment. If the platform is self-hosted open-source software such as Bareos or restic, confirm that staff have operating experience with its scheduling, catalog and verification features before relying on them during an incident. Document who holds each role so that the prioritization is not blocked by one person being unavailable.

How long does RC.RP-02 take to implement?

A timeline is only meaningful once the scope is agreed in writing, because the number of systems, business services and existing documents drives the duration. Most engagements with DeployOpen are fixed-scope, so the scope, deliverables and timeline are set out in writing before work starts. Ask for a schedule that separates the prioritization method, the technical verification work and the exercise that tests both, since the exercise often reveals gaps that extend earlier phases. Be cautious about any timeline offered without a defined list of systems, recovery criteria and evidence outputs.

Is there a certificate for NIST CSF 2.0 compliance?

No. NIST does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans to develop a conformity assessment program. The CSF is a voluntary framework, so any claim of CSF certification should be treated with skepticism. What a customer or regulator may ask for is evidence of alignment, such as documented recovery criteria, exercise records and restore test results for RC.RP-02. Independent auditors or assessors may review that evidence under another standard or contract, but they do not issue a CSF certificate. DeployOpen prepares systems, controls and evidence for assessments and does not issue audit reports or certifications.

What should we ask for in a fixed-scope quote?

Ask the partner to state the scope in terms of named systems, business services, recovery criteria and the incident response plan sections in use. The quote should list each deliverable, such as a written prioritization method, configuration changes to the backup platform, verification procedures and an exercise report, along with who performs each task. Ask which items are one-time and which recur, such as periodic restore tests or plan reviews, and what triggers a change order if the scope grows. Confirm which evidence the partner will hand over, and state clearly that the organization, not the partner, owns the controls and any independent assessment. DeployOpen does not publish a price list, so a quote follows from the written scope.

How DeployOpen prepares RC.RP-02 recovery evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the recovery actions behind RC.RP-02 can be selected, scoped and prioritized against your plan criteria. We prepare the systems and records an assessor will ask to see, while your organization owns the controls and an independent auditor issues any report.

How we scope

We agree a written scope that names the platforms, recovery actions and plan criteria covered for RC.RP-02.
We confirm which recovery prioritization rules your incident response plan already defines and which ones need to be written.
We list the resources, assets and business systems the recovery priority decisions will depend on, agreed before work starts.

How we build

We configure backup and restore tooling, such as Bareos, to support prioritized restore sequences you have defined.
We set up restic repositories and integrity checks so recovery sources can be confirmed before any action is chosen.
We build recovery worksheets that record each selected action, its scope, its priority and any change made after reassessment.

How we hand over

We document the recovery decision process, roles and escalation points so your team can repeat it without us.
We test the prioritization steps in a tabletop or exercise and record what changed as a result.
We deliver the configuration, runbooks and evidence files to your team, and confirm with your assessor which artifacts they expect.

How we support

Engagements are fixed-scope, so the deliverables and timelines for RC.RP-02 are agreed in writing before work begins.
Ongoing support, upgrades and continuous testing are available as a retainer if your recovery priorities change.
Confirm with us how the written scope handles reassessment of recovery needs and resources after each exercise or real event.

RC.RP-02 Recovery actions prioritized