An incident response plan is documented and maintained
When an incident happens, the worst time to figure out what to do is during the incident itself. Adrenaline, pressure, and incomplete information make ad hoc decisions unreliable. A documented incident response plan defines roles, communication channels, escalation paths, and decision points in advance so the team can execute under pressure. The plan must be maintained and tested; a plan that was written two years ago and never reviewed is only slightly better than no plan at all.
Implementation steps
- 1
Write an incident response plan covering key phases
Document the plan using a recognized framework such as NIST SP 800-61. Cover all phases: preparation, detection and analysis, containment, eradication and recovery, and post-incident review. Include: severity classification criteria, escalation contacts for each severity level, containment decision trees for common incident types (ransomware, account compromise, data breach), and communication templates for internal and external notifications.
confluence notion google-docs pagerduty opsgenie - 2
Assign roles and ensure coverage
The plan must name specific roles: incident commander, communications lead, technical lead, and legal liaison. Each role needs a primary and backup. Store contact information in a location accessible outside your primary systems, because in a major incident your email or Slack may be unavailable or untrusted. Review role assignments every six months and update when people leave.
pagerduty opsgenie google-drive lastpass 1password - 3
Review and update the plan at least annually
Schedule an annual review of the IR plan to incorporate lessons learned from incidents and exercises, changes in the technology environment, and updates to legal notification requirements. After any significant incident, conduct a post-incident review and update the plan based on what worked and what did not. Version-control the plan and record when it was last reviewed and by whom.
confluence github google-docs drata vanta
Evidence required
Incident response plan with review history
Evidence that an IR plan exists, has been recently reviewed, and assigns clear roles.
- - Incident response plan document with version history and last review date
- - Role assignment matrix with primary and backup contacts
- - Post-incident review records from past incidents or exercises
Related controls
Incident response roles and contacts are designated and current
Response and Recovery
Incident response exercises are conducted at least annually
Response and Recovery
Security incidents are reported to CISA when applicable
Response and Recovery
Security logs are collected centrally and retained for investigation
Response and Recovery