Framework Category
Incident Recovery Plan Execution
Incident Recovery Plan Execution involves restoring systems and operations after an incident.
It includes verifying backup integrity, prioritizing recovery actions, ensuring restored assets are secure, and reestablishing normal operations.
Recovery concludes when predefined criteria are met and documentation is finalized.
Implementation Questions
RC.RP-01
The recovery portion of the incident response plan is executed once initiated from the incident response process
Has your organization established documented procedures to initiate recovery processes during or immediately following security incident response?
Linking response to recovery is the concern here, specifically whether you have documented procedures to kick off recovery during or right after incident response. Recovery procedures should be triggered at appropriate points during incident handling to minimize downtime and data loss, rather than waiting until all response activities are complete.
Have all personnel with recovery responsibilities been formally trained on the recovery plans and their specific authorization levels?
Recovery-team readiness is what's being verified: whether everyone with recovery duties has been formally trained on the recovery plans and their specific authorization levels. Proper awareness ensures that during a crisis, personnel understand their roles, know what actions they're authorized to take, and can execute recovery procedures without delays or confusion.
RC.RP-02
Recovery actions are selected, scoped, prioritized, and performed
Has your organization defined criteria for selecting recovery actions during incident response, and are these criteria followed when responding to security incidents?
Recovery action selection is being evaluated here: whether you have defined criteria for choosing recovery actions during incident response and apply them consistently when incidents occur. Having predefined criteria helps ensure that recovery efforts are systematic, prioritized correctly, and aligned with business needs rather than being ad hoc or inconsistent.
Does your organization have a process to reassess and update recovery plans based on changes in organizational needs and available resources?
Keeping recovery plans current is the point of this item, namely whether you reassess and update them as organizational needs and available resources change. As organizations evolve, their recovery requirements and capabilities change, requiring updates to recovery time objectives, recovery point objectives, and recovery strategies.
RC.RP-03
The integrity of backups and other restoration assets is verified before using them for restoration
RC.RP-04
Critical mission functions and cybersecurity risk management are considered to establish post-incident operational norms
Does your organization use business impact assessments and system categorization records to prioritize the restoration of essential services during recovery operations?
Recovery prioritization is what's being assessed: whether you use business impact assessments and system categorization records to decide which essential services are restored first during recovery.
Does your organization have a documented process for verifying successful system restoration and confirming the return to normal operations after an incident or outage?
Recovery validation is the concern here: the question is whether you have a documented process to verify successful system restoration and confirm a return to normal operations after an incident or outage. The process should include verification steps with system owners to confirm functionality, data integrity, and that business operations can resume normally.
Does your organization have a process to monitor and verify the performance of restored systems after recovery operations?
After system restoration following an incident or disaster, it's crucial to verify that systems are functioning properly and meeting performance expectations. This monitoring helps identify any lingering issues that might affect system functionality, security posture, or data integrity that weren't immediately apparent during the restoration process.
RC.RP-05
The integrity of restored assets is verified, systems and services are restored, and normal operating status is confirmed
Does your organization scan restored assets for indicators of compromise and verify remediation of root causes before returning them to production use?
After a security incident, restored systems or data may still contain hidden malware, backdoors, or vulnerabilities that caused the original compromise.
Does your organization validate the integrity and completeness of restored systems before returning them to production?
Recovery assurance is the concern: whether you validate the integrity and completeness of restored systems before returning them to production. This includes checking that all critical components, data, configurations, and security controls have been properly restored and are operating as expected.
RC.RP-06
The end of incident recovery is declared based on criteria, and incident-related documentation is completed
Does your organization create after-action reports following security incidents that document the incident details, response actions taken, recovery procedures, and lessons learned?
After-action reports are critical documents that capture the complete lifecycle of a security incident, from detection through resolution, and identify opportunities for improvement. These reports help organizations learn from incidents, refine response procedures, and prevent similar incidents in the future by documenting what happened, how the team responded, what worked well, and what could be improved.
Has your organization established formal criteria for declaring the end of an incident recovery phase?
Defining clear criteria for when an incident is considered resolved helps ensure all necessary recovery steps are completed and normal operations can resume. These criteria might include system stability for a defined period, confirmation that vulnerabilities have been addressed, verification that no malicious activity remains, and completion of all required documentation.
ResponseHub is the product I wish I had when I was a CTO
Previously I was co-founder and CTO of Progression, a VC backed HR-tech startup used by some of the biggest names in tech.
As our sales grew, security questionnaires quickly became one of my biggest pain-points. They were confusing, hard to delegate and arrived like London busses - 3 at a time!
I'm building ResponseHub so that other teams don't have to go through this. Leave the security questionnaires to us so you can get back to closing deals, shipping product and building your team.
