What RC.RP-01 requires when recovery starts
RC.RP-01 asks that the recovery portion of the incident response plan is carried out once incident response initiates it, and that everyone with a recovery role knows the plans and the authorizations each part requires. It is a Subcategory of the Incident Recovery Plan Execution (RC.RP) Category in the RECOVER Function of the NIST Cybersecurity Framework (CSF) 2.0, published as NIST CSWP 29 on February 26, 2024. The Subcategory continues CSF 1.1 RC.RP-1 at the same identifier, so organizations that already mapped that item can carry the mapping forward. The risk it addresses is familiar: restoration teams start rebuilding systems before containment is settled, pull backups that were never checked, or take actions that the change board or legal team never approved. In each case the recovery effort can destroy evidence, reintroduce the attacker, or create an outage nobody planned for.
The hard part is usually the handoff. Incident response and recovery are often run by different people with different tools and different authority, and the plan may say only that recovery begins "when appropriate." Plans that have never been rehearsed tend to fail at the first decision point: who declares that containment is complete, who approves the first restore, and which runbook applies. Ask the organization to name the individual who can start recovery, the criteria that person uses, and the approvals each recovery step needs, then confirm that those names appear in the current plan and in the on-call directory. A tabletop exercise that walks through the response-to-recovery transition will expose gaps that a document review will miss.
NIST's Small Business Quick-Start Guide (SP 1300, February 2024) cites RC.RP-01 when it suggests that organizations identify who inside and outside the business holds recovery responsibilities, which is a practical starting point for any size of organization. Two NIST Implementation Examples describe the work: starting recovery procedures during or after incident response, and making sure everyone with recovery responsibilities understands the plans and authorizations. Assessors will normally look for a dated plan, a documented trigger, role assignments, and records from a past exercise or real event showing the handoff worked. Confirm the current assessment expectations with the framework owner or your assessor, since NIST does not certify or endorse implementations.
Which systems, teams and suppliers RC.RP-01 covers
RC.RP-01 is only as good as the scope behind it. The decisions below determine which systems have recovery procedures, who must know their role, and which platforms sit in the recovery path. Work through them before writing or testing any recovery steps, and record the answers in the recovery plan itself.
Systems with documented recovery procedures
Start with the systems the recovery plan must cover, not the whole estate. For each, record the recovery owner, the restore method, the dependencies it needs to start, and the order it returns in. Systems without a written procedure are where recovery stalls during an incident, so list them as gaps. Ask whether business-critical applications inherit a procedure from their hosting platform or need their own, and confirm that each procedure names the authorization required before it runs.
Internal recovery roles and authorities
Name who decides to start recovery, who executes each step, and who approves a restore into production. IT operations, application owners and security staff often each assume another team holds the final sign-off. Write the authorization for each recovery action, such as isolating a restore environment or returning a service to production, and confirm that the people named have the access rights to carry it out during an incident when normal change approvals may be unavailable.
Communications and business decision makers
Recovery steps often wait on decisions from outside IT, including which service returns first, whether customers are told of a partial restore, and when regulators or contract counterparties are informed. Identify the communications lead, the business owners who accept risk on a degraded service, and the legal or privacy contact. Confirm that each person knows when they are asked to act and that their contact details are kept outside systems that may be down during the incident.
Managed service providers and outsourced operators
If a managed service provider runs backups, patching or monitoring, its staff hold recovery responsibilities even though they are not your employees. Document which recovery actions the provider performs, which ones require your approval, and how quickly it must respond. Check that its contract and runbooks match the recovery plan, and that it knows who in your organization can authorize a restore. Contract terms that limit its role to backups alone leave restoration tasks unassigned.
Cloud and hosting providers
Cloud platforms and hosting providers control the infrastructure you restore onto, and some recovery actions depend on their support processes, quotas or regional availability. Record which of your recovery steps rely on provider tooling, which need provider tickets, and what the provider's own shared responsibility boundaries leave to you. Confirm the escalation path and that your restore account credentials are stored where they remain reachable if your primary identity system is compromised.
Backup and restore platforms in the recovery path
Every backup platform in the recovery path needs a named owner, documented restore procedures and a tested route to the data it holds. Bareos, for example, schedules and supervises backup, restore and verify jobs and keeps a SQL catalog of backed-up files, so its catalog and director become recovery dependencies. restic can confirm that stored pack files are unmodified with its read-data checks. Record which platform holds each system's backups and whether that platform is itself recoverable.
How an assessor tests RC.RP-01
This table walks through the typical assessor test steps for RC.RP-01, the evidence each step asks for, and the findings that most often come up. Read it as a preparation checklist: each row is something the organization should be able to show before an assessor arrives. The main takeaway is that an assessor looks for a plan that names recovery roles and authorizations, and for proof that people used them.
| Test step | What the assessor does | Evidence requested | Common finding |
|---|---|---|---|
| Review the recovery plan | Reads the recovery portion of the incident response plan and checks that it says when recovery starts and who starts it. | Current plan version, approval record, and the trigger that moves work from incident response into recovery. | The plan covers containment and eradication in detail but has no defined handoff into recovery. |
| Check named recovery roles | Confirms the plan names recovery roles, their responsibilities, and any internal or external parties involved. | Role assignments, on-call or escalation lists, and contact details for recovery leads and supporting vendors. | The plan names job titles only, and no current person holds the role. |
| Check authorizations | Looks for the approvals each recovery action needs, such as restoring production, rebuilding systems, or reconnecting to networks. | Written authorization matrix, delegation records, and emergency approval procedures. | Authorizations are assumed or agreed verbally and never written down. |
| Interview recovery role holders | Asks role holders what they would do, who they would call, and what they are allowed to approve. | Interview notes and, where practical, a walk-through of the steps each person would take. | Staff describe different approval paths, or do not know the plan exists. |
| Sample a past or exercised incident | Selects a real incident or tabletop exercise and traces whether recovery began when the plan says it should. | Incident tickets with timestamps, the recovery start decision, and the approvals recorded for each recovery action. | Recovery work starts informally in a chat channel with no decision or approval record. |
| Confirm awareness | Checks that people with recovery responsibilities received the plan and understood their part. | Distribution or acknowledgment records, training attendance, and exercise participation logs. | The plan was updated after the last exercise, and the updated version was never shared. |
| Review plan maintenance | Checks that roles and authorizations are updated when staff, systems, or vendors change. | Change log for the plan, review dates, and records of corrections made after exercises. | Role lists still show people who left the organization. |
How to implement RC.RP-01 step by step
This sequence moves an organization from incident response into recovery in a controlled way, so every person with a recovery role knows what the plan asks of them and under whose authority they act.
Define the handoff trigger from response to recovery
Incident response leads write down the condition that moves work from containment and eradication into recovery, and who has authority to declare it. Typically this is the incident commander or an equivalent role named in the response plan. The trigger should reference observable criteria, such as containment confirmed for affected systems or an agreed decision by the incident commander, rather than a verbal instruction in a channel. The output is a signed or approved trigger statement stored with the incident record, which tells everyone when RC.RP-01 begins. Confirm that your own response plan already names this decision point, because the Subcategory expects recovery to start because incident response initiates it.
Map recovery roles and their authorizations
Working from the recovery portion of the incident response plan, list each recovery activity and the role responsible for it, including staff, system owners, external providers and any legal or communications contacts. For each role, record the approvals it needs before acting, such as authority to restore production systems, to bring back a backup, or to reconnect a network segment. Include people inside and outside the business, because NIST's Small Business Quick-Start Guide (SP 1300) asks organizations to understand who has recovery responsibilities across both groups. The output is a recovery role matrix that names each role, its activities, and the approvals each activity requires.
Confirm authorizations with accountable leaders
Take the role matrix to the executives who own the systems and business processes it covers, and get explicit confirmation that each named authority is correct and current. Pay particular attention to decisions that accept business risk, such as restoring a system before a full root cause is known, or running on reduced capacity. Resolve gaps, such as activities with no named approver, before the plan is used in an incident. The output is a sign-off record listing who approved which authorizations and when, kept with the recovery plan version it applies to.
Brief role holders and record acknowledgment
Hold a briefing for everyone in a recovery role, walking through the trigger, their responsibilities, the approvals they need, and the escalation path if an approval cannot be reached. Share the current plan version and the contact list, and ask each person to acknowledge receipt in writing or through the ticketing or case system your team uses. Track any role holder who has left the organization or changed duties, and fill that gap before the next exercise. The output is an acknowledgment register showing that each named recovery role has been briefed on the current plan.
Rehearse the response-to-recovery handoff
Run a tabletop or technical exercise in which the incident response team declares the trigger and recovery roles pick up their activities. Test whether the right people are reachable, whether approvals can be obtained within the escalation path, and whether recovery actions start from the correct incident state. Capture gaps as findings with owners, and feed them back into the trigger definition, role matrix or contact list. The output is an exercise report with dated findings and corrective actions, which also supports the improvement expectations in the CSF Improvement Category (ID.IM).
Start recovery and log each recovery action
When a real incident reaches the trigger, the incident commander records the declaration in the case record and recovery roles begin the activities they were assigned. Each action is logged with the role that performed it, the approval relied on, the time it started and any dependency on other actions. This log is what allows later reviewers to show that recovery followed the plan rather than improvised steps. The output is a time-stamped recovery action log linked to the incident case, which can be updated as priorities change under the related Subcategory RC.RP-02.
Record outputs and review the handoff
After the trigger is declared and recovery is under way, review whether each role acted within its authorization and whether any approval was bypassed or delayed. Record deviations, the reasons for them, and any changes to the plan that should follow. Keep the review with the incident file so it can feed later decisions on declaring recovery complete under RC.RP-06. The output is a handoff review note attached to the incident record, with each deviation logged against a plan update or corrective action.
Evidence that satisfies RC.RP-01
RC.RP-01 is tested by whether the recovery part of the incident response plan was actually started and carried out by people who knew their roles. The cards below cover the records an assessor will ask to see, and each one needs an owner and a review cycle so it still matches the plan on the day of the audit.
Recovery section of the IR plan
The written recovery procedures, kept as a versioned document with a change log showing who approved each revision and when. Check that the section names the trigger that moves the organization from incident response into recovery, because RC.RP-01 depends on that hand-off being defined. Confirm the version in use matches the version the staff were briefed on, and record a review date after every exercise or real incident.
Role and authorization matrix
A table that lists each recovery task, the role responsible for it, the alternate, and the approval each task requires before it runs, such as restoring production data or reconnecting a segment to the network. Assessors use this to confirm that everyone with a recovery responsibility knows which authorizations apply. Review it whenever staff change roles, and check that named individuals still hold their access.
Acknowledgment and briefing records
Signed or system-logged confirmations that people with recovery roles received the current plan, understood their part and the authorizations attached to it. Keep the date of each briefing alongside the plan version it covered. Gaps usually appear for contractors, on-call staff and managers who joined after the last briefing, so reconcile the list against the current roster at least once a year and after any reorganization.
Response-to-recovery handoff record
A dated record that shows when incident response declared recovery could begin, who made the call, and what open items moved across. It should list the affected systems, the state of containment and the evidence preserved so far. Without this record, an assessor cannot connect recovery actions to the point where the plan was initiated, so store it in the case management system alongside the incident timeline.
Incident and exercise timelines
Time-stamped logs of recovery activity from a real incident or a tabletop or technical exercise, showing when each recovery procedure started and which role executed it. Consolidated timelines from a case management tool make it easier to show the sequence without rebuilding it from chat logs. Keep the exercise after-action notes with the timeline, and check that each step matches a procedure in the current plan.
Approvals for recovery actions
Records of who authorized each significant recovery action, such as a restore from backup, a return to service or a change to firewall rules made during recovery. Each approval should reference the matrix entry that gave the approver authority. Record approvals in the ticketing or case system rather than in email, and set a retention period that matches your audit cycle and any contractual or regulatory retention duty you have.
What meeting RC.RP-01 costs in money and effort
This table breaks down the cost components of running and evidencing RC.RP-01, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. No prices or durations are stated because none were supplied, so use the drivers to frame a written quote. The main takeaway is that most of the ongoing cost comes from keeping recovery roles briefed and evidence current, not from the software itself.
| Cost component | One-time or recurring | Who is paid and what drives it |
|---|---|---|
| Writing recovery procedures | One-time, then recurring upkeep | Internal staff or an implementation partner. Drivers: number of systems in scope, how many recovery paths exist, and how well existing incident response plans are documented. |
| Recovery role briefings | Recurring | Internal time for the people named in recovery roles. Drivers: staff turnover, number of roles with authorizations, and how often plans change. |
| Tooling licenses | Recurring where commercial | Vendor licensing for backup, case management or GRC products. Self-hosted open-source options such as Bareos, restic and DFIR-IRIS remove license fees but still need hosting and admin time. |
| Infrastructure to host tooling | Recurring | Cloud or data center capacity in the organization's own environment. Drivers: backup volume, retention periods and whether a separate recovery environment is kept. |
| Evidence upkeep | Recurring | Internal staff or a partner collecting restore logs, verification output, case records and sign-off records. Drivers: audit frequency and how much evidence is captured automatically. |
| External exercise or review | Recurring or per engagement | Fees paid to an outside tester or facilitator for recovery exercises. Drivers: scope of the exercise and whether it is run in-house or independently. Ask for the written scope before agreeing a fee. |
| Auditor sampling and assessment | Recurring per assessment cycle | Independent auditor or assessor fees, which NIST does not set. Drivers: how many recovery events and restore records the auditor samples. Ask the auditor how they select samples. |
Which open-source tools support recovery evidence
Bareos is an open-source backup system licensed under AGPL-3.0-only. Its Director schedules and supervises backup, restore, verify and archive jobs, and it keeps a SQL catalog of the files it has backed up. For RC.RP-01, that catalog matters because it lets a recovery team select files from the current backup or from a backup taken before a given date and time, which supports the plan's requirement that recovery actions follow documented procedures. Job logs and catalog records can show that restore jobs ran, what they targeted and when. Recovery roles can be tested in advance by running restore drills against a non-production target.
- Job history: Director logs and catalog entries record when restore and verify jobs ran and what they targeted.
- Point-in-time selection: Restores can be drawn from the current backup or from one before a chosen date and time, which helps match the recovery point to the incident timeline.
- Verify jobs: Scheduled verify jobs compare stored data with the catalog, giving a recurring signal before a real restore is needed.
- Restore drills: Test restores to isolated hosts produce dated evidence that people in recovery roles know the procedure.
Confirm with your own team which Bareos version and storage configuration you will run, and whether your retention and catalog backup settings meet your recovery plan.
restic is a backup program licensed under BSD-2-Clause. Its check command verifies the structural consistency of snapshots, trees and pack files. With the --read-data or --read-data-subset options, it reads pack files back and confirms that the stored backup data has not been modified. This supports the recovery plan's expectation that restoration assets are trustworthy before anyone restores from them, which is closely tied to RC.RP-03. restic does not decide whether a backup is clean of attacker activity; that judgment still depends on indicators of compromise checked by people or other tools.
- Structural checks: A standard check confirms snapshots, trees and pack files are consistent.
- Data reads: --read-data reads all pack files back, while --read-data-subset checks a defined portion, which lets teams balance coverage against time.
- Repeatable output: Command output can be captured with timestamps and kept with the recovery record.
- Scope limits: The check confirms storage integrity, not the absence of malware or compromise in the source data.
Before relying on the output, confirm the repository location, the frequency of checks and who reviews the results, and record those decisions in the recovery plan.
DFIR-IRIS is an open-source case management platform licensed under LGPL-3.0-or-later. It keeps each case as one record that holds assets, indicators of compromise, tasks and evidence, with a full audit trail. It triages alerts from SIEM, EDR and REST sources into cases, builds a consolidated investigation timeline and logs evidence with SHA-256 verification and chain of custody. For RC.RP-01, this is where the organization can show who started recovery, which tasks were assigned to whom, and the authorization or decision recorded for each step. The platform records what was entered and by whom; it does not decide whether the authorization was appropriate.
- Case record: One case holds the assets, indicators, tasks and evidence for the incident, so recovery steps sit next to the investigation.
- Audit trail: Entries show actions taken in the case, which supports questions about who acted and when.
- Task assignment: Recovery tasks recorded against named owners show that people in recovery roles were identified.
- Timeline and reports: The consolidated timeline and generated reports can be attached to the after-action record.
Confirm that your case templates include a field for the authorization behind each recovery action, and that your staff know how that field is completed.
No single tool proves that RC.RP-01 is met. An assessor will look for a documented recovery plan, evidence that it was started when incident response initiated it, and proof that people with recovery responsibilities knew the plan and the authorizations each part required. The tools generate records that support those points, such as job logs, integrity check output and case trails. Written role assignments, training or briefing records, approval records and the decision to start recovery usually come from outside the tools, so they must be kept deliberately.
- Plan and roles: The tools cannot show that the recovery plan exists or that roles were communicated; those documents and briefings must be retained separately.
- Authorization: Approvals may be recorded in a case, but the policy that defines who may approve must be documented by the organization.
- Assessor sampling: Assessors usually sample specific incidents or exercises, so evidence should be retrievable for a named event.
- Independent review: Only an independent auditor or assessor can conclude that the control is met.
Ask your assessor which evidence formats and sampling approach they expect before you configure the tools, so the records you keep match the questions they will ask.
Where RC.RP-01 programs usually fall short
RC.RP-01 is met only when people in recovery roles know the plan and hold written authority to act. The gaps below are the ones that most often separate a documented plan from one that works during an incident, and each card ends with a check you can run this quarter.
Recovery roles stop at IT
Recovery plans often name IT operations and the security team but leave out finance, legal, communications, facilities and business unit owners who decide which services return first. During an incident these people are the ones who accept downtime, approve workarounds and sign off on restored processes. Check that every recovery role in the plan names a person or a role holder outside IT, and that each of those people has read the section that assigns them work.
Authorizations assumed, not written
Plans frequently say that a team will restore a system without stating who may approve the restore, who may take a system offline, or who may spend on emergency capacity. Staff then wait for a decision or act without one, which creates disputes after the event. Check that each recovery action in the plan lists the approver, the limit of that approval and the fallback approver when the first is unavailable.
Plans never exercised
A recovery plan that has never been run is an untested assumption about people, tooling and timing. Gaps tend to surface only when staff try to find credentials, reach an off-site copy or follow steps written for a previous architecture. Check that the plan has been walked through in a tabletop or technical restore exercise within the last review cycle, and that exercise findings were logged and assigned owners.
Response-to-recovery handoff undocumented
RC.RP-01 begins when incident response initiates recovery, yet many programs never define that trigger. Responders keep working on containment while recovery staff start restoring systems that are still under investigation, or nobody starts at all. Check that the plan names the criteria and the person who formally starts recovery, and records the time of handoff in the incident case so that the start of recovery can be shown later.
Third parties missing from the plan
Cloud providers, managed service providers, software vendors and data center operators often hold the only copies of configurations, backups or restore tooling. When the plan omits them, recovery stalls while staff look up support contacts or contract terms. Check that every external party with a recovery duty appears in the plan with its contact path, its contractual recovery commitments and the evidence it must return, and that these terms match the supplier agreements on file.
Recovery knowledge held by few people
When only one or two engineers know how to rebuild a platform or unlock backup encryption keys, RC.RP-01 depends on whether those people are reachable during the incident. Key-person dependence also undermines the requirement that everyone with recovery responsibilities understands the plan. Check that runbooks for critical platforms are stored where the recovery team can reach them without the affected systems, and that at least one trained backup person exists for each.
Common questions about RC.RP-01 cost, effort and scope
Does NIST certify compliance with RC.RP-01?
No. NIST does not certify, endorse or offer a conformity assessment program for CSF 2.0 implementations, and it states it has no plans to create one. No one can issue a NIST certificate for RC.RP-01. Evidence that the recovery portion of your incident response plan is carried out comes from your own records, and an independent assessor or auditor may test those records against a scope you agree in advance. Any provider that claims a NIST certification for this subcategory is making a claim the framework does not support. Ask for the assessor's methodology and the scope document in writing, and confirm whether your customers or regulators accept an independent report, a self-assessment or another form of evidence. The organization owns the outcome and the statement of alignment.
What drives the effort of executing a recovery plan?
The effort depends on how many systems and recovery roles the plan covers, how mature the current incident response plan is, and how many authorizations must be written down. Costs fall into four groups: internal staff time for mapping roles and authorizations, exercises that rehearse the recovery portion, tooling for backups and case records, and any outside help. Most of the work is one-time setup, such as writing role assignments and authorization matrices. The recurring work is updating the plan after changes, rehearsing it, and keeping contact lists current. A large estate with several sites and many third parties needs more coordination than a single environment. Ask any quote to separate setup work, recurring operations and tooling, and to state the assumptions it makes about system count and environment.
Can our team run RC.RP-01 without an outside partner?
Yes, if the team has the authority, time and skills to run the work internally. The subcategory asks that the recovery portion of the incident response plan runs once incident response starts it, and that everyone with recovery responsibilities knows the plans and the authorizations each part requires. Those are governance and operational tasks an internal team can own. An outside partner is most useful for preparing systems, testing restores, building self-hosted evidence pipelines and documenting results for assessors. Before you start, confirm that your staff have run a recovery exercise from start to finish recently. A plan nobody has rehearsed tends to reveal its gaps only during a live incident. Decide in advance which parts you keep in-house and which you scope to a partner.
What does RC.RP-01 need from our staff?
Staff need clear recovery roles, named deputies and enough time to read and rehearse the plan. The Implementation Examples for RC.RP-01 describe starting recovery procedures during or after response, and making everyone with recovery responsibilities aware of the plans and the authorizations each part requires. In practice, you must identify who inside and outside the business holds recovery responsibilities, a point NIST's Small Business Quick-Start Guide also raises. Engineers need access to backup catalogs and restore procedures. Business owners need to know who can approve a restore, a rebuild or the return of a service. Managers should plan to release people for drills. Keep role cards and contact lists current, and record who was briefed and when, because those records are evidence.
How long does it take to put RC.RP-01 in place?
This page has no researched figure for how long RC.RP-01 takes, and the framework does not set a duration. Timing depends on the size of the environment, the state of the existing incident response plan, how many recovery roles need briefing, and whether backups and restores have been tested before. Ask any provider for a schedule built from a written scope, with milestones for role mapping, authorization matrices, restore testing and a recovery exercise. Ask which milestones depend on your staff's availability or on third parties. DeployOpen's engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, so any timeline should follow from that written scope. Request the assumptions behind each milestone so you can check them against your own calendar.
What does an auditor need from us for RC.RP-01?
An auditor or assessor needs evidence that the recovery portion of your plan is carried out and that the people involved know their roles. Because NIST runs no conformity assessment, the form of testing depends on who you engage and the criteria you agree. Typical evidence includes the recovery portion of the incident response plan with version history, role and authorization records, briefing and training records, and incident case records showing when recovery started and who initiated it. Exercise results also help. Confirm with the assessor in advance which samples, time periods and formats they accept. Only the independent assessor issues a report or opinion. Your organization keeps ownership of the controls and of every statement it makes about them.
Which parts of RC.RP-01 can an implementation partner take on?
A partner can prepare systems and evidence, but your organization keeps ownership of the control and of the decision to declare recovery under its own process. Work that suits an implementation partner includes setting up self-hosted backup and case-management platforms, configuring verification jobs, drafting role and authorization documents for your review, running restore tests and organizing evidence for the assessor. Work to keep in-house includes approving who holds recovery authority, accepting residual risk and deciding when recovery begins. Ask any partner to state in writing which deliverables it will produce, which evidence it will hand over and which decisions stay with your staff. DeployOpen does not issue audit reports or certifications. Independent auditors and certification bodies do.
Which open-source tools produce recovery evidence for RC.RP-01?
Several open-source tools can produce evidence for parts of this subcategory, but none satisfies RC.RP-01 alone. Bareos schedules and supervises backup, restore, verify and archive jobs and keeps a SQL catalog of backed-up files, which gives you restore records. The restic check command verifies the structural consistency of snapshots, trees and pack files, and with --read-data or --read-data-subset it reads pack files back to confirm the stored data is unmodified. DFIR-IRIS keeps each case as one record of assets, tasks and evidence with a full audit trail, which can show when recovery was initiated and by whom. Confirm each feature against the documentation for your version, for example in the restic documentation, and treat the outputs as inputs to an evidence file that still needs human sign-off.
How DeployOpen prepares recovery evidence
DeployOpen plans, implements and documents the self-hosted recovery tooling that supports RC.RP-01, and prepares the evidence an assessor will ask for, under a written, fixed scope agreed before work starts. In practice that can mean configuring Bareos to schedule backup, restore and verify jobs, setting up restic repositories with scheduled restic check runs that include read-data verification, and building DFIR-IRIS case workflows so that recovery tasks, owners and authorizations are recorded in one place. The organization still owns the recovery plan, the role assignments and the decision to start recovery. DeployOpen's part is to make those decisions traceable in systems the client controls, inside the client's own cloud accounts, data centers or air-gapped networks.
DeployOpen does not issue audit reports, attestations or certifications, and neither does any implementation partner. Only an independent auditor or assessor can test RC.RP-01 and report on it. NIST also does not certify CSF alignment, endorse products or services, or plan a conformity assessment program for the CSF, so no document from DeployOpen or from NIST should be presented as proof that the framework has been met. Before engaging anyone, confirm with your customer, regulator or auditor which evidence they will accept and whether they expect a named assessor. Ask any partner to state in writing which artifacts they will produce and which parts remain your staff's responsibility.
Beyond the initial implementation, two optional services can support the program. Recovery exercises let the people named in your recovery roles practice starting the recovery procedures and confirm they know which authorizations apply to each step, producing dated records that show awareness in practice. Retainers cover ongoing support, upgrades and continuous testing of the recovery tooling, and are priced separately from the fixed-scope implementation. Either option should be defined in the written scope with its deliverables, frequency and responsibilities stated, so that the evidence it generates can be reviewed by your independent assessor without interpretation.
