RC.RP-06: The end of incident recovery is declared based on criteria, and incident-related documentation is completed

To meet the rc.rp-06: the end of incident recovery is declared based on criteria, and incident-related documentation is completed requirement, you must define objective “recovery complete” criteria, require an authorized recovery closeout decision, and finish the incident record (actions, approvals, lessons learned, residual risk, and follow-up tasks) before the incident is formally closed. This turns recovery from a judgment call into a controlled, auditable step.

Key takeaways:

• Define measurable recovery exit criteria per incident severity and system criticality, then enforce them with a closeout checklist.
• Require a documented closeout declaration by a named authority (usually Incident Commander with business owner sign-off for critical systems).
• Treat “documentation complete” as a gating control, not an afterthought; retain evidence that recovery was validated and follow-ups were tracked.

RC.RP-06 is a recovery governance control: it forces you to decide, with evidence, when an incident is truly “over,” and it requires you to finish the paperwork that proves what happened and what you did about it. The requirement text is short, but operationally it touches incident response, IT operations, business ownership, risk management, and often third-party management when a provider or vendor is involved.

Most teams can restore service and still fail RC.RP-06 because they lack (1) explicit exit criteria, (2) clear authority to declare recovery complete, or (3) a disciplined documentation package that is consistently completed. That gap creates real audit pain: reviewers look for a control point where recovery transitions into normal operations and where you captured enough detail to support later decisions (discipline, customer communications, insurance claims, regulator questions, litigation holds, and control improvements).

This page gives you requirement-level guidance you can implement fast: what to define, who must approve, what to evidence, what auditors ask, and how to avoid common closeout failures. Source references are to the NIST Cybersecurity Framework (CSF) 2.0 and its transition materials (NIST CSWP 29; NIST CSF 1.1 to 2.0 Core Transition Changes).

Regulatory text

Requirement excerpt: “The end of incident recovery is declared based on criteria, and incident-related documentation is completed” (NIST CSWP 29; NIST CSF 1.1 to 2.0 Core Transition Changes).

Operator interpretation (what you must do):

1. Set criteria that define “recovery complete” for your environment (availability, integrity, security validation, monitoring, and business acceptance).
2. Declare recovery complete only when those criteria are met, and record who made the declaration and on what basis.
3. Complete incident documentation as part of the recovery-to-close transition, including what happened, what changed, residual risk, and required follow-ups.

This is a gating requirement. If you cannot show criteria, a declaration, and completed documentation, an assessor can reasonably conclude recovery is informal and incident handling is not controlled.

Plain-English interpretation of the requirement

You need a “finish line” for recovery that is not subjective. “Recovery complete” means you restored service and validated that systems are stable and trustworthy enough to return to normal operations. Then you must complete the incident record so the organization can prove due care and learn from the event.

A practical way to think about RC.RP-06: no incident is closed until the closeout checklist is complete and approved.

Who it applies to

Entities: Any organization that runs a cybersecurity program using NIST CSF 2.0 concepts (NIST CSWP 29).

Operational context:

• Security incident response (SOC/IR), IT operations, SRE, and service owners
• Business continuity and disaster recovery (BC/DR) coordination for major incidents
• Risk and compliance (GRC) oversight for closure quality and evidence retention
• Third parties when they host or support affected systems, provide tooling, or caused/experienced the incident conditions

Where it matters most: high-impact systems, regulated data environments, customer-facing outages, ransomware or destructive malware events, and incidents requiring coordinated restoration across multiple teams.

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

Step 1: Define “recovery complete” exit criteria (make it measurable)

Create a short standard, then tailor by severity tier. Your criteria should cover five areas:

Criteria category	What “met” looks like (examples you can adapt)	Evidence source
Service restoration	Business service is operating within agreed performance/availability expectations	Monitoring dashboards, status page history, change tickets
Integrity validation	Data integrity checks passed; known bad artifacts removed; backups validated if used	Hash/check reports, DB consistency checks, backup restore logs
Security validation	Root cause addressed or risk accepted; IOCs mitigated; access controls re-validated	EDR/SIEM searches, vulnerability scans, IAM reviews
Stability & monitoring	Increased monitoring enabled for a defined period; no recurrence signals	Alerting rules, incident watch logs
Business acceptance	System owner confirms acceptable to resume normal operations	Recorded approval in ticket/IR platform

Keep the criteria short enough that responders can apply them under pressure. If the criteria take more than a page, teams will skip them.

Step 2: Assign authority to declare the end of recovery

Document the roles that can declare recovery complete and who must concur. A workable model:

• Incident Commander (IC): proposes recovery closeout after verifying criteria evidence
• Service/System Owner: confirms business acceptance for critical services
• Security Lead: confirms security validation is complete or documents residual risk acceptance
• GRC/Risk (as needed): reviews completeness for high-severity incidents, ensures follow-ups are tracked

Write the rule as a control statement: “Recovery may be declared complete only by the Incident Commander after documented verification of recovery exit criteria, with required approvals based on severity.” This aligns with the “declared based on criteria” language (NIST CSWP 29).

Step 3: Use a recovery closeout checklist as a gating control

Operationalize RC.RP-06 with a required checklist embedded in your incident workflow tool (IR platform, ticketing system, or case management). Minimum checklist items:

• Recovery exit criteria met (attach evidence links)
• Customer/employee communications closed out (if applicable)
• All emergency changes documented and converted to standard change records
• Temporary access or break-glass accounts removed or time-bounded
• Monitoring elevated and owner assigned
• Post-incident review (PIR) scheduled or completed (based on severity)
• Follow-up tasks created with owners and due dates (don’t leave tasks in meeting notes)

If you do only one thing: make “Close incident” impossible until the checklist is complete.

Step 4: Complete incident-related documentation (define the minimum record)

Define a “minimum incident record” template. Keep it consistent across incidents so you can evidence maturity. Include:

1. Timeline: detection, triage, containment, eradication, recovery start, recovery declaration
2. Scope and impact: systems, data types, customers, business functions impacted
3. Actions taken: key commands/changes, playbooks used, third-party coordination points
4. Decision log: why key decisions were made (shutdowns, restores, ransom decision path if relevant)
5. Root cause / contributing factors: confirmed cause or best-supported hypothesis, plus gaps found
6. Recovery validation evidence: links/attachments proving exit criteria met
7. Residual risk statement: what remains risky, who accepted it, and compensating controls
8. Lessons learned and corrective actions: preventive and detective control improvements, owners assigned
9. Regulatory or contractual notification analysis: whether notice was required and how you decided

This is the “documentation is completed” part of RC.RP-06 (NIST CSWP 29).

Step 5: Track follow-ups to closure (don’t confuse incident closure with risk closure)

A common operational gap: the incident is “closed,” but action items never land. Solve this by splitting:

• Incident close (RC.RP-06): recovery complete + documentation complete
• Remediation close: corrective actions complete, validated, and risk reduced

Your IR process should create problem tickets / risk items for longer-term remediation. RC.RP-06 still requires you to document those follow-ups and assign ownership before closing the incident record.

Step 6: Ensure third-party recovery is covered

If a third party provides infrastructure, SOC tooling, or application support, your criteria and documentation must still be complete. Add two explicit checklist items:

• Third-party incident report received or documented as pending with a due date
• Third-party actions validated (patch applied, configuration corrected, credentials rotated, logs preserved)

This prevents a “black box recovery” where you cannot defend the declaration decision.

Required evidence and artifacts to retain

Retain evidence in a consistent location with controlled access (IR case system or GRC repository). Recommended artifacts:

• Recovery exit criteria standard (policy/procedure) mapped to RC.RP-06 (NIST CSWP 29)
• Per-incident closeout checklist with completion status and approvals
• Recovery declaration record: who declared, timestamp, and evidence references
• Incident timeline and action log (including emergency changes)
• Validation outputs: scan results, monitoring screenshots/exports, integrity checks, restore verification
• Communications approvals and artifacts (internal updates, customer notices, status page posts)
• PIR notes/report and corrective action register with assigned owners
• Third-party correspondence and provider post-incident report (when applicable)

If you need one audit-friendly package: a single PDF export or case report that contains the declaration, criteria evidence links, and completed documentation fields.

Common exam/audit questions and hangups

Expect these questions from internal audit, external assessors, and regulators mapping to NIST outcomes:

1. “Show me the criteria for declaring recovery complete.” They will look for written criteria, not verbal practice (NIST CSWP 29).
2. “Who is authorized to declare recovery complete?” They will test segregation of duties and business sign-off for critical services.
3. “Prove you met your criteria for this incident.” They will sample incidents and ask for monitoring, scan evidence, and approvals.
4. “Where is the documentation, and is it consistent?” They will look for a standard template and completed fields.
5. “How do you ensure follow-up actions actually get done?” They will ask to see corrective actions tracked to closure, even if outside the incident ticket.

Hangup: teams often present a PIR slide deck but cannot show the actual recovery declaration gate or criteria evidence.

Frequent implementation mistakes and how to avoid them

• Mistake: “Recovered” equals “service is back.”
  Fix: require security and integrity validation as explicit exit criteria, not optional notes.
• Mistake: Closeout authority is unclear.
  Fix: name the Incident Commander role and required approvers by severity tier; enforce in workflow.
• Mistake: Documentation is scattered across chat, email, and personal notes.
  Fix: require all critical decisions and evidence links to be captured in the incident record before closure.
• Mistake: Emergency changes are not reconciled.
  Fix: add a checklist item to convert emergency changes into standard change records with approvals.
• Mistake: Third-party dependency is ignored.
  Fix: add third-party report and validation checkpoints; document what you asked for and what you received.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific actions.

Operationally, RC.RP-06 reduces three categories of risk:

• Recurrence risk: declaring recovery too early leads to re-infection, repeated outages, or persistent access.
• Governance risk: without a recorded declaration and criteria, you cannot defend decisions under scrutiny (board, auditors, regulators, insurers).
• Learning debt: incomplete documentation weakens root-cause analysis and remediation tracking, which increases future incident impact.

A practical 30/60/90-day execution plan

First 30 days (foundation)

• Draft and approve Recovery Exit Criteria Standard aligned to RC.RP-06 language (NIST CSWP 29).
• Define authority model (IC + required approvers by severity).
• Build a closeout checklist in your incident tooling with required fields and approval capture.
• Train ICs and service owners on what “recovery declared” means in practice.

Day 31–60 (operate and harden)

• Run the checklist on every incident; do spot checks for completeness.
• Create the minimum incident record template and require it for closure.
• Add third-party closeout requirements (report request + validation evidence).
• Start a corrective action register linked to each incident.

Day 61–90 (audit readiness)

• Perform a mini-audit: sample incidents and verify you can produce an end-to-end closeout package.
• Refine criteria by severity and system tier based on what teams struggled to evidence.
• Establish recurring evidence collection for RC.RP-06 (policy, workflow configuration screenshots, sample closed incidents).
• If you use Daydream, map RC.RP-06 to a control owner and set recurring evidence reminders so closeout packages stay consistent as staff and tooling change.

Frequently Asked Questions

Who should be allowed to declare the end of incident recovery?

Assign the Incident Commander to declare recovery complete, but require business/service owner sign-off for critical services. For higher-severity incidents, include a security lead concurrence to confirm validation and residual risk handling.

What counts as “criteria” for recovery complete?

Criteria should be objective checks that confirm service restoration, integrity, security validation, and stability monitoring. If a criterion cannot be evidenced (log, scan, monitoring output, approval), it is too vague to use as a gate (NIST CSWP 29).

Can we close the incident before the post-incident review happens?

You can, if your process requires PIR scheduling, assigns owners, and records follow-up tasks before incident closure. Document the decision and keep the PIR output linked to the incident record once completed.

How do we handle incidents where a third party controls the affected system?

Require a third-party incident summary or report, record what validations they performed, and document your own validation steps (monitoring, access reviews, compensating controls). Closeout should reflect what you know, what you asked for, and what remains open.

What evidence do auditors usually want to see for RC.RP-06?

They typically ask for the written exit criteria, a closed incident record with approvals, and proof the criteria were met (monitoring exports, scan results, integrity checks). They also look for consistency across multiple sampled incidents.

Our tooling doesn’t support approvals. How do we comply?

Use the ticketing system’s existing controls (restricted status transitions, required fields, comment-based attestations) and capture explicit named approvals in the incident record. If approvals happen in chat, copy the approval statement into the case with timestamps and participants.