What RC.RP-06 asks before an incident can be closed
RC.RP-06 asks the organization to declare the end of incident recovery against criteria it set in advance, and to complete the incident documentation, including an after-action report that covers the incident, the response and recovery actions, and the lessons learned. The point is that someone with authority makes a recorded decision that recovery is over, based on tests the organization agreed before the pressure of the incident began. A recovery that is finishing usually has systems back online and stakeholders eager for normal operations, which is exactly when a premature closure is most likely.
The risks are predictable. An incident closed too early leaves residual exposure undocumented: a backdoor not yet removed, a restored service running with a logging gap, or a workaround that no one ever retired. Without a written close-out, the same weakness can resurface as a repeat incident, and the next responders start from scratch. The work is hard for two reasons. Many teams never defined what "recovered" means, so the decision becomes a debate, and the evidence is scattered across chat threads, ticket comments, email and personal notes. Before the closure meeting, confirm who holds the authority to declare recovery complete, which criteria must be met, and where the timeline and decisions will be recorded.
NIST added RC.RP-06 as a new Subcategory in CSF 2.0, so organizations that adopted CSF 1.1 may not have a matching practice to build on. NIST's Small Business Quick-Start Guide, SP 1300, cites RC.RP-06 when it suggests that small businesses prepare an after-action report, alone or with a vendor or partner, and document the end of the incident. That guidance applies to organizations of any size. A practical first step is to draft a short closure checklist with named criteria, a sign-off role, and a required after-action template, then test it against the next tabletop exercise before a real incident relies on it.
Which incidents, systems and teams RC.RP-06 covers
Declaring the end of recovery is only as credible as its boundaries. The decisions below set which incidents need a formal closure, which systems and third parties count as part of the recovery, who signs the declaration, and when notification duties allow closure to be declared.
Incident classes that need formal closure
Not every event needs a written end-of-recovery declaration. Define classes by impact, such as ransomware, data exposure, loss of a critical service or any event that triggered external notification. Each class should name the closure criteria it must meet. Check that low-impact events still leave a short closure record, so the organization can show it chose not to escalate and why.
Systems in scope for closure
Closure should list every system, data store and service that the recovery touched, including restored backups, rebuilt hosts and temporary access paths. Compare that list with the asset inventory before declaring anything complete. Systems left in a degraded or interim state, or accounts created for the incident and never removed, should block the declaration until they are dispositioned.
Third parties in the recovery
Managed providers, cloud platforms, forensic firms and software vendors often hold pieces of the recovery. Confirm in writing which third-party actions are complete, such as a vendor confirming a patch or a hosting provider releasing a restored environment. Record any open items the provider still owns, because the organization remains accountable for closing them even when a partner performed the work.
Declaration authority and sign-off
Name one role with authority to declare recovery complete, and a deputy for absences. Typical candidates are the incident commander or a senior security or operations leader, but the choice should match the organization's governance. Write the approvers into the recovery plan and record the declaration with a timestamp, the people consulted and the criteria confirmed as met.
Legal and regulatory notification duties
Closure can run ahead of notification obligations that still have deadlines or follow-up reports due. Map each applicable regime, such as GDPR breach notification, DORA incident reporting or NIS2 reporting, to its timing and its final-report requirement. Ask counsel whether the declaration needs to wait for a final report, and document that the notification record is complete before closing the case.
Customer and contractual notice
Customer contracts, service-level commitments and supplier agreements may require written confirmation that service is restored or that an incident is closed. Inventory these obligations before the incident and attach their notice requirements to the closure checklist. Confirm the wording of the closure notice with the account owner, so that the organization does not declare recovery complete while a contractual report is still outstanding.
How an assessor tests the end-of-recovery declaration
This table walks through the test steps an assessor typically follows for RC.RP-06, the evidence each step asks for, and the findings that most often appear. Read it as a checklist for your own pre-assessment review: if you cannot produce the evidence in the right column for a sampled incident, the declaration will be hard to defend. The main takeaway is that criteria must exist before the incident, and the after-action report must be complete.
| Test step | What the assessor checks | Evidence requested | Common finding |
|---|---|---|---|
| Sample closed incidents | Selects a sample of incidents closed in the review period, including a mix of severities and recovery types | Incident register extract, case closure records, dates of recovery start and declared end | Sample drawn only from low-severity cases, leaving major incidents untested |
| Check criteria predate the incident | Confirms the end-of-recovery criteria were defined and approved before the sampled incident occurred | Versioned recovery plan or procedure with approval dates, change history, document metadata | Criteria written or edited after the incident, with no version history to prove otherwise |
| Compare declaration to criteria | Tests whether each stated criterion, such as restored services verified and monitoring in place, was actually met before closure | Checklist or sign-off record showing each criterion with the evidence reference | Declaration recorded with a generic note such as recovery complete and no criterion-level evidence |
| Confirm authorized declarant | Verifies that the person declaring the end of recovery held the role the plan assigns to that decision | Role assignments, RACI or plan roster, approval record or ticket with the approver's identity | Closure made by an analyst who was not named in the plan, or approval recorded only in chat |
| Review the after-action report | Checks that the report covers the incident, the response and recovery actions taken, and the timeline | After-action report, consolidated timeline, links to the response actions and evidence items | Report exists but is a template with unfilled sections or copied text from another incident |
| Verify lessons learned | Looks for lessons that name specific causes and specific follow-up actions, and checks that actions were tracked to closure | Lessons-learned register, improvement tickets with owners and status, follow-up review notes | Lessons listed in general terms with no owner, due date or tracked improvement action |
| Check documentation completeness | Confirms that the incident record, evidence log and related communications are complete before the case was closed | Case audit trail, evidence chain-of-custody entries, communication logs for the incident | Open tasks or unlogged evidence still present in a case marked closed |
| Test consistency across records | Compares dates, decisions and owners across the case, the report and the recovery records | Cross-referenced timestamps from ticketing, backup logs and restore records | Declared end date falls before restored systems were confirmed in normal operation |
Implementing an end-of-recovery process step by step
This sequence turns the end of an incident from an informal judgment into a documented decision. Each step produces a record that an assessor can trace back to the criteria, the restored assets and the lessons the organization committed to act on.
Define closure criteria for each incident class
Before an incident happens, the incident response lead and system owners agree on what recovery complete means for each class of incident, such as ransomware, data loss, account compromise or third-party outage. Criteria should be observable: affected systems restored, business functions back within agreed thresholds, monitoring in place, and open tasks either closed or accepted as risk. The output is a short, versioned criteria document per incident class, approved by the people who will sign the declaration. Confirm with your own plan owners which criteria they expect, since NIST does not prescribe specific ones.
Assign the declaration authority
Name the role that may declare recovery over, and the role that must be consulted before it does so. Many organizations give the declaration to the incident commander or the business owner of the affected service, with security and legal consulted where regulatory notifications are still open. The output is a written delegation that names roles rather than individuals, includes a deputy, and states what the declarer must confirm. An assessor will look for evidence that the person who declared recovery had the authority to do so.
Build the closure checklist from restored-asset verification
Turn the criteria into a checklist that points to evidence. Each restored system should link to the verification record produced under RC.RP-05, which confirms integrity, normal operating status and remediation of root causes. Items for backups and credentials, such as rotated secrets and confirmed clean restore points, should reference the checks made under RC.RP-03. The output is a completed checklist where every line has an owner, a timestamp and an evidence link. A checklist with unlinked ticks is not evidence of verification.
Confirm open actions and stakeholder obligations
Before declaration, list every open task, exception, deferred remediation and pending external obligation. Each item is either closed, moved to a tracked remediation plan with an owner, or formally accepted as residual risk by the authority named in step two. Stakeholder updates under RC.CO and any regulator or customer notices still in progress should be shown as complete or as explicitly ongoing. The output is a reconciled open-items register attached to the closure record.
Declare the end of recovery in writing
The declaration authority reviews the checklist and open-items register against the criteria and records a decision: recovery complete, complete with accepted residual items, or not yet complete. The record states the date and time, the incident identifier, the criteria version applied and the names of the people who signed. Communicate the declaration to the teams and stakeholders listed in the plan. The output is a signed or approved closure record that stands on its own without the incident chat history.
Run the after-action review
Hold a structured review with responders, system owners and affected business leads while details are still fresh. Cover the timeline of detection, containment, recovery and declaration, what worked, what slowed the response, and where the criteria or plans did not match reality. NIST's Implementation Examples for RC.RP-06 describe an after-action report covering the incident, the response and recovery actions and lessons learned. The output is a draft after-action report reviewed by the incident lead.
Record lessons learned and assign follow-up actions
Convert each finding into a specific improvement with an owner, a status and a link to the affected plan, control or runbook. Route plan changes through the normal improvement process under ID.IM so they are tested rather than silently edited. Lessons that lead to no tracked action should be marked as considered and closed, with the reason. The output is a follow-up register that a later review can check for completion, which is the evidence that lessons actually changed the organization.
Archive the incident record under version control
Store the closure record, checklist, open-items register, after-action report and follow-up register together in the system of record the organization uses for incidents, with access limited to the roles that need it. Keep the criteria version and any revisions traceable, and retain the record for the period set by the organization's legal, regulatory and contractual obligations, which should be confirmed with counsel. The output is a complete, indexed case file that an internal reviewer or external assessor can retrieve without asking the responders for missing pieces.
Evidence that satisfies RC.RP-06 in practice
The closure declaration is the record that the organization decided recovery had ended. RC.RP-06 asks for the end of recovery to be declared against defined criteria, so an assessor will look for a dated, approved statement that names the incident, the people who approved closure and the criteria that were met. Without it, an incident can drift into a permanent 'monitoring' state and nobody can say when operations returned to normal.
- Incident identifier and scope: the declaration names the incident record, the systems and services it covered and any that were excluded.
- Criteria referenced: it points to the criteria baseline and states which were satisfied, with links to the verification records behind each one.
- Approvers: the incident commander or equivalent role signs, and the business owner of affected services co-signs where the plan requires it.
- Date and time: the declaration records when recovery was declared complete and when any residual monitoring period ends.
- Open items: remaining actions, such as deferred patches, are listed with owners so closure does not hide unfinished work.
Ownership sits with the incident commander, and the declaration template should live in the response plan so it is ready before an incident. Confirm with your own incident response process whether the signatory is a single role or a committee, and check that the signed copy is retained in a system the response team can still access during an outage.
The criteria baseline is the set of conditions that must be true before recovery can be declared finished. It is written before an incident, reviewed after each one and used as the test against which the closure declaration is judged. An assessor will ask where the criteria came from, who approved them and whether they cover the systems that matter most to the business, not only the technical restoration steps.
- Technical conditions: restored systems pass integrity checks, required services respond and monitoring covers them again.
- Business conditions: critical functions run at the levels set in the business impact records and affected customers or staff can use them.
- Security conditions: root causes are addressed, credentials tied to the incident are rotated and indicators of compromise are no longer present.
- Documentation conditions: the after-action report and case record are complete before closure is signed.
- Versioning: each criteria set carries a version and date so an assessor can see which version governed a given incident.
The security or resilience lead usually owns the baseline, with input from platform and business owners. Keep it in a version-controlled wiki or document system so changes are traceable, and review it after each significant incident and at least on the cycle your governance process sets.
The after-action report is the narrative record of the incident, the response and recovery actions taken and the lessons learned. NIST's implementation examples for RC.RP-06 describe preparing this report, and the Small Business Quick-Start Guide suggests small organizations prepare one alone or with a vendor or partner. It is the evidence most assessors read first because it shows whether the organization understood what happened.
- Chronology: the report summarizes detection, containment, eradication and recovery in order, with dates tied to the case record.
- Actions taken: it lists response and recovery actions, who performed them and whether they met the criteria.
- Impact: it describes affected services, data and users as far as the investigation established them.
- Lessons learned: each lesson names the gap or success it reflects and points to a tracked follow-up item.
- Review and approval: the author, reviewers and approval date are recorded.
The incident lead drafts it and a separate reviewer checks it, so that facts are not left to one person's memory. Confirm whether your regulators or contracts specify a report format or a deadline, because those requirements can override internal templates.
The lessons-learned tracker turns findings into owned work. A report that lists lessons with no follow-up shows that an organization noticed a problem but did not act on it. The tracker shows each lesson, the action it produced, who owns the action and whether it was completed, which is what assessors check when they test whether improvement is real. It also connects to the ID.IM improvement practices in CSF 2.0.
- Lesson and root cause: each entry states the lesson in one sentence and the cause it addresses.
- Action and owner: every lesson has at least one action with a named owner and a target review date.
- Status history: changes to status are logged, so an assessor can see when an action was opened, changed and closed.
- Linkage: entries link to the incident, the after-action report and any related change or risk record.
- Recurrence check: the tracker is searched for similar lessons across incidents, so repeated findings are visible.
The security operations or resilience manager should own the tracker, with action owners in engineering, operations and business teams. Review it at a fixed cadence between incidents, not only when an incident happens, and confirm that closed actions were verified rather than marked done on paper.
The case timeline is the reconstructed sequence of events, actions and evidence from the incident record. It is the factual backbone for the closure declaration and the after-action report. Without it, the organization is left to reconstruct the response from chat logs and memory, which is hard to defend when an assessor or regulator asks precisely when recovery was verified. A case management tool that keeps one record per incident, with a full audit trail, makes this evidence easier to produce.
- Consolidated events: alerts, actions, decisions and verification steps appear in one ordered view.
- Audit trail: every change to the case records what changed, when and by whom.
- Evidence handling: items collected during recovery carry integrity values and chain of custody entries where they matter for later review.
- Generated reports: the case data can feed the after-action report, which reduces transcription errors.
- Export and retention: the timeline can be exported in a form that remains readable after the platform changes or is decommissioned.
The incident responder owns the case record, and the platform administrator owns its retention and access. DFIR-IRIS is one open-source option that keeps cases, tasks, assets and timelines together with an audit trail, and wiki tools such as XWiki keep page versions for the narrative documents. Confirm that the platform you choose is hosted inside your own boundary and that backups of the case record are tested for restore.
How the declaration, the timeline and the after-action report connect
The declaration that recovery has ended should be the output of a chain of records, not a judgment made in a meeting. Start with the closure criteria the recovery plan defined before the incident: restored systems verified under RC.RP-05, backups checked under RC.RP-03, normal operations confirmed, and root causes shown to be remediated. The incident commander or the named recovery owner then records the declaration against those criteria, naming the date, the people who approved it and any criteria still open with an accepted exception. The after-action report, which RC.RP-06 expects to cover the incident, the response and recovery actions and lessons learned, follows from that declaration. Each record should point to the others: the declaration cites the criteria and the verification evidence, the report cites the declaration date, and each lesson links to the improvement action it created under ID.IM. Without those references, an assessor sampling one incident cannot trace a claim of closure back to proof.
A single case record in an incident management tool is what makes that chain practical to maintain. In DFIR-IRIS, for example, the case can hold the affected assets, indicators of compromise, tasks and evidence items in one place, with an audit trail of changes, and a consolidated timeline can be built from the case data. Ask whether the tool you select lets you attach recovery verification evidence to the same case, whether task closure times and approvals are recorded in the audit trail, and whether the report output can be generated from those fields or must be assembled by hand. Confirm these capabilities in a test case before relying on them, since the answer depends on the version and configuration you deploy. Evidence files should carry hashes and chain of custody entries so that the restored-state evidence referenced in the declaration can be shown to be unchanged.
The after-action report and the lessons learned are only useful if the organization can show what happened to them. Store the final report and the declaration in a controlled document system with version history, such as XWiki, which keeps every change with its author and date and lets reviewers compare versions. Restrict who can approve or edit the final version using role-based permissions, as BookStack does with roles that can be overridden per shelf, book or page. Plan a fixed review point for each lesson, with an owner and a due date, and keep those references in the report. Ask your auditor which records they expect to sample for RC.RP-06 so that the case, the document system and the improvement tracker all produce matching evidence.
What meeting RC.RP-06 costs in money and effort
This table breaks down the cost components of declaring recovery complete and writing the after-action report under RC.RP-06, showing who is paid, whether each cost is one-time or recurring, and what drives it. Use it to build a quote request. No prices or durations are given because none were supplied for this topic, so confirm figures against the written scope.
| Cost component | Who is paid or who bears effort | One-time or recurring | What drives it, and what to ask for in a quote |
|---|---|---|---|
| Recovery-end criteria design | Internal incident response lead, with legal, communications and business owners; optionally an implementation partner drafting the criteria | One-time, then revised after major incidents | Number of critical services and regulatory duties. Ask the partner to show how criteria map to each service and who signs off. |
| Tabletop review of criteria | Facilitator (internal or external) and participants from recovery roles | One-time per plan revision, then periodic | Number of scenarios and participants. Ask whether facilitation, scenario writing and a written findings log are included. |
| Tooling and licenses | Software vendor or open-source project; the organization pays for hosting and administration | Licenses recur if commercial; self-hosted open-source tools remove license spend but keep hosting and admin time | Case management and wiki tools in use, hosting model and retention needs. Ask whether the quote lists license fees separately from hosting and setup work. |
| After-action review time | Incident responders, system owners and a reviewer, typically internal staff | Recurring, per incident | Incident volume and complexity, and how many systems and teams were involved. Ask for a standard review template to limit rework. |
| Evidence upkeep | Records owner, usually internal GRC or security operations staff | Recurring, through the retention period | Volume of case records, evidence hashes and versioned documents, plus retention rules. Ask how records are stored, versioned and retrieved for an assessor. |
| External review of reports | Independent auditor, assessor or certification body for any formal assessment; an outside reviewer if you commission one | Recurring at each assessment cycle | Assessment scope and how many incidents are sampled. NIST does not offer certification for CSF, so confirm with your customer or regulator what review they accept. |
| Regulatory notification duties | Internal legal and compliance staff, plus outside counsel where needed | Recurring, per reportable incident | Notification deadlines in applicable laws and contracts. Confirm with counsel which records the after-action report must support. |
Open-source tools that hold closure records
DFIR-IRIS is an open-source incident response platform licensed under LGPL-3.0-or-later. It keeps each case as one record that gathers assets, indicators of compromise, tasks and evidence, and it keeps a full audit trail of changes made to that record. For closure, the case record is where the team can show what was done, by whom, and in what order, which is the factual base an after-action report draws on.
- Single case record: Assets, IOCs, tasks and evidence sit in one case, so the closure criteria can be checked against recorded tasks rather than memory.
- Audit trail: Changes to the case are logged, which lets a reviewer see when a task was closed and who closed it.
- Consolidated timeline: The platform builds an investigation timeline from case entries, useful for reconstructing the sequence of recovery actions.
- Evidence chain of custody: Evidence items are logged with SHA-256 verification and chain of custody records, which supports the integrity claims made in the closure file.
- Generated reports: Reports are produced from case data, giving a starting draft for the after-action report.
The platform does not prove that recovery was complete, and it does not decide when the criteria are met. Its audit trail records what was entered, not whether the entries are accurate. Confirm with your own deployment how the audit log is protected from edits and how long it is retained.
XWiki is a wiki platform licensed under LGPL-2.1-or-later. Its relevance to RC.RP-06 is version control: every change to a page is kept, so the after-action report can show how its lessons learned and conclusions changed between drafts and reviews. The wiki is a place to write and review the report, not a substitute for the case record it summarizes.
- Change history: Each change is recorded with what changed, when and by whom, which gives reviewers a traceable path from draft to approved version.
- Version comparison: Any two versions of a page can be compared, useful when leadership asks what changed after a review meeting.
- Rollback: Earlier versions can be restored, which helps correct an erroneous edit without losing the record that it happened.
- Review workflow: Pages can be assigned for review before the report is treated as final, so the approval step is visible in the history.
Version history proves that a page changed and who changed it. It does not prove that the lessons learned are accurate or that they were acted upon. Confirm with your own configuration whether the approval workflow, retention settings and access controls meet the policy your organization has adopted for closure records.
BookStack is a documentation platform licensed under MIT. For recovery work, it holds the runbooks and closure checklists that define the criteria for declaring recovery complete. Its role model decides who can read, edit or approve those documents, which matters because a closure declaration is only as credible as the authority of the person who signed it.
- Roles drive abilities: A user's abilities come from the roles assigned to them, so incident commanders, platform owners and auditors can receive different rights.
- Granular overrides: Permissions can be overridden per role at the shelf, book, chapter or page level, which lets a team restrict a closure checklist to named approvers.
- Stable reference copies: Keeping the approved closure criteria in a restricted book gives the team one place to point to when recovery is declared.
- Separation of duties: Read-only access for auditors and edit rights for the document owner can be configured, supporting a clearer approval trail.
BookStack controls access to documents. It does not record the reasoning behind a declaration, and it does not verify that the systems described in a runbook were restored. Confirm with your own deployment which roles exist, who holds them, and whether access changes are logged in a way your assessor can review.
Where end-of-recovery records usually fall short
Most organizations recover from incidents, but few can show when recovery ended and why. The gaps below tend to appear together, and each one weakens the evidence an assessor would use to test RC.RP-06.
Criteria defined after the incident
Teams often agree on what "recovered" means only once systems are running again, which makes the criteria look chosen to fit the outcome. Write the closure conditions into the recovery plan before any incident occurs, such as restored services, verified restored assets and open actions accepted by a named owner. When reviewing a closed incident, check whether the criteria existed with a date earlier than the first recovery action.
Declarations made informally in chat
A message such as "we're good" in a team channel is easy to post and hard to audit. It rarely names the authority that made the call or the criteria that were met. Require a formal declaration record with the incident lead's name, the time, the criteria checked and the stakeholders notified. Chat threads can be linked from that record, but they should not replace it.
After-action reports skipped for minor incidents
Teams often treat small incidents as too minor for a written review, yet NIST's Small Business Quick-Start Guide suggests an after-action report for organizations of any size. Set a threshold in the plan that defines which incidents always receive a report, and record a short justification whenever one is waived. Assessors look for that decision trail as much as for the reports themselves.
Lessons learned never tracked to completion
A lessons-learned section can list good ideas that nobody schedules. Convert each lesson into a tracked action with an owner, a due date and a status, and link it to the improvement work that the ID.IM Subcategories expect. Before declaring closure, confirm that open items are either finished or formally accepted as risk. Review the tracker at the next planning cycle.
Evidence scattered across tools
Timelines may sit in the ticketing system, forensic images in a case tool, approvals in email and restore logs on a backup console. Assembling these after the fact is slow and error-prone. Decide in advance which system is the record of truth for the case and link out to the others from it. A self-hosted case manager such as DFIR-IRIS can hold assets, tasks, evidence and an audit trail in one place.
Questions teams ask about RC.RP-06
How much effort does declaring the end of recovery take?
The effort depends on how many incidents you run through the process, how many recovery criteria you have defined in advance, and how many systems and teams the incident touched. Declaring the end of recovery is a short decision when the criteria were written before the incident. It becomes slow when the team has to agree on criteria during the incident itself. The larger effort is usually the after-action report, which needs a timeline, a record of decisions and actions, and lessons learned drawn from the people involved. Ask any provider to break its quote into the one-time work of defining criteria and templates and the recurring work of writing reports after each incident.
Can a small team handle RC.RP-06 without outside help?
Yes, a small team can handle it alone. NIST's Small Business Quick-Start Guide (SP 1300, February 2024) cites RC.RP-06 and suggests that small businesses prepare an after-action report, either by themselves or with a vendor or partner, and document the end of the incident. The practical requirement is a written definition of what counts as recovered, a named person who makes the call, and a place to keep the record. A small team can do all three internally. Outside help is most useful for the first incident, when the criteria and templates are being set up, or when the team lacks someone with forensic or recovery experience to review the report.
How long does an after-action report take to produce?
No reliable duration is established for every organization, so treat any single number with caution. The time depends on the length of the incident, the number of people to interview, and whether timeline evidence was captured during response. Teams that logged actions as they happened spend far less time reconstructing events than teams working from memory. Ask for a turnaround commitment in writing, and ask what evidence the provider needs before drafting starts. Recovery is not complete until the report is finished and the lessons are assigned to owners, so plan for the report to finish after the systems are back in service.
Will an auditor test RC.RP-06?
An auditor may test it, but the framework itself has no certification. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services. When a customer or contract asks for CSF 2.0 alignment, an independent assessor will usually check whether your records show that recovery end criteria exist, were applied to a real incident, and produced a documented after-action report. Your evidence for this subcategory should include the criteria document, the incident record with the recovery declaration, and the signed after-action report. Confirm with the assessor which format they accept before you rely on a specific template.
Can a partner sign off that recovery is complete?
No. A partner can help prepare the criteria, the records and the report, but the organization owns the decision to declare recovery complete. An implementation partner such as DeployOpen prepares systems, controls and evidence for assessment, and it does not issue audit reports, attestations or certifications. Only an independent auditor, assessor or certification body issues those. Within your organization, the declaration should be made by the person named in your incident response plan, and that person's sign-off should appear in the incident record.
What does a partner need from us to help with RC.RP-06?
A partner needs access to the material that shows how your team actually responded and recovered. Ask your team to provide:
- Your incident response and recovery plans, including the criteria you have defined for ending recovery
- Incident records, tickets, chat logs and any timeline notes from past events
- A list of the systems, owners and recovery roles involved in each incident
- Decisions made about restoration, communication and closure, with the people who made them
- Access to the tools where incident records are kept, if the partner will work inside them
The quote should follow from this written scope. Confirm what happens if material is missing, because gaps in the timeline are the most common reason an after-action report takes longer than planned.
Where to read the RC.RP-06 text and mappings
Start with the primary text. The RC.RP-06 Subcategory sits in Appendix A of NIST CSWP 29, the CSF 2.0 document, under the Incident Recovery Plan Execution (RC.RP) Category in the RECOVER Function. Read the Subcategory statement itself before anything else, because it sets the outcome an assessor will test: the end of recovery is declared against defined criteria, and incident documentation is completed. Note that RC.RP-06 is new in CSF 2.0, so no CSF 1.1 wording exists to fall back on. Your written criteria for declaring recovery over should trace directly to that outcome.
The NIST CSF 2.0 Reference Tool export is the place to check the two Implementation Examples for RC.RP-06 and the informative references behind them. The export lists SP 800-53 Rev. 5.2.0 controls IR-4 and IR-8, ISO/IEC 27001:2022 Annex A controls 5.27 and 8.13, and SP 800-171 Rev. 3 requirements 03.06.01 and 03.06.05. Use these as starting points for your evidence list, not as proof that a mapped control is satisfied. Confirm each mapping against the current release of the referenced standard before you rely on it in a contract or assessment, because the mappings are maintained by NIST and the referenced standards are maintained separately.
The NIST SP 1300 Small Business Quick-Start Guide is the most practical read for smaller teams. It cites RC.RP-06 when it suggests preparing an after-action report, either alone or with a vendor or partner, and documenting the end of the incident. If you plan to bring in an outside party to draft the after-action report, this guide shows the division of work NIST has in mind. Ask your provider to confirm in writing which parts of the report they draft and which parts your incident lead must approve.
