Coordinate recovery after a security incident
Turn the recovery plan into assigned tasks. Verify backups before restoring, check systems afterward, and collect the evidence needed to sign off on a return to normal operations.
Tools for incident recovery plan execution
MCP servers for the tools used in these examples.
AWSAutomation examples and starter prompts
Paste a prompt into Claude Code, Microsoft Copilot, or Codex connected to Tracecat MCP. Adapt it to your tools and test before deployment. Human tool approvals and advanced case features require Enterprise.
Run recovery as tracked tasks
Build me a recovery execution workflow in Tracecat. When recovery initiates, convert the recovery plan into case tasks with owners and order of operations: restore priorities, verification steps, and sign-offs. Mirror infrastructure tasks to ServiceNow for the platform team, track progress on the case, and post a rolling status to the incident channel. First help me understand how this maps to RC.RP-01 and RC.RP-02, and why recovery order should follow mission criticality instead of convenience. Ask me which services must come back first. Talk me through handling tasks that stall or fail mid-recovery.
Verify backups before restoring
Build me a backup verification workflow in Tracecat. Before any restore, check that the chosen backup predates the compromise window from the case timeline, verify checksums against the backup catalog in AWS, restore a sample into an isolated environment, and scan it with CrowdStrike before approving it for production restoration. First help me understand how this maps to RC.RP-03 and how restoring a poisoned backup replays the incident. Ask me what our backup tooling is and how far back retention goes. Talk me through how much verification is proportionate at each incident severity.
Confirm restored systems are clean
Build me a post-restore verification workflow in Tracecat. For each restored system, run an EDR scan through CrowdStrike, compare the configuration against our hardening baseline, confirm service health in Datadog, and check that none of the incident's indicators reappear. Write a per-system verification record to the case and require sign-off before it returns to normal operations. First help me understand how this maps to RC.RP-05 and what confirming normal operating status should actually include. Ask me where our hardening baselines live. Talk me through how long restored systems deserve heightened monitoring.
Declare recovery done with criteria
Build me a recovery closure workflow in Tracecat. Encode our end-of-recovery criteria as a checklist: all systems verified, monitoring back to baseline, stakeholders informed, and evidence archived. When the checklist passes, declare recovery complete on the case, have an AI agent assemble the incident documentation in Notion from the case record, and open the retro with its findings feeding our improvement backlog in Linear. First help me understand how this maps to RC.RP-06 and why a declared end with criteria beats incidents that just fade out. Ask me who signs the declaration. Talk me through what the closing documentation must contain for auditors and insurers.
NIST CSF 2.0 mapping: RC.RP
Official NIST category: Incident Recovery Plan Execution. Restoration activities are performed to ensure operational availability of systems and services affected by cybersecurity incidents
The controls and implementation examples below are NIST source material. The automation prompts above are Tracecat-authored starting points, not evidence of compliance or full control coverage.
- RC.RP-01CP-10IR-4IR-8
The recovery portion of the incident response plan is executed once initiated from the incident response process
- Begin recovery procedures during or after incident response processes
- Make all individuals with recovery responsibilities aware of the plans for recovery and the authorizations required to implement each aspect of the plans
- RC.RP-02CP-10IR-4IR-8
Recovery actions are selected, scoped, prioritized, and performed
- Select recovery actions based on the criteria defined in the incident response plan and available resources
- Change planned recovery actions based on a reassessment of organizational needs and resources
- RC.RP-03CP-2CP-4CP-9
The integrity of backups and other restoration assets is verified before using them for restoration
- Check restoration assets for indicators of compromise, file corruption, and other integrity issues before use
- RC.RP-04IR-1IR-8PM-8PM-9PM-11
Critical mission functions and cybersecurity risk management are considered to establish post-incident operational norms
- Use business impact and system categorization records (including service delivery objectives) to validate that essential services are restored in the appropriate order
- Work with system owners to confirm the successful restoration of systems and the return to normal operations
- Monitor the performance of restored systems to verify the adequacy of the restoration
- RC.RP-05CP-10
The integrity of restored assets is verified, systems and services are restored, and normal operating status is confirmed
- Check restored assets for indicators of compromise and remediation of root causes of the incident before production use
- Verify the correctness and adequacy of the restoration actions taken before putting a restored system online
- RC.RP-06IR-4IR-8
The end of incident recovery is declared based on criteria, and incident-related documentation is completed
- Prepare an after-action report that documents the incident itself, the response and recovery actions taken, and lessons learned
- Declare the end of incident recovery once the criteria are met
Control text and SP 800-53 Rev 5 references from the official NIST CSF 2.0 and OLIR releases.
Build your own security automation
Adapt a starter prompt with your coding assistant, choose where AI agents or fixed workflows fit, and test with your tools.