The entity responds to identified security incidents by executing a defined incident response program to understand, contain, remediate, and communicate security incidents, as appropriate.
When an incident is declared, you follow a documented playbook, not improvising. The playbook covers: understand the scope, contain the damage, eradicate the root cause, recover to normal operations, and communicate to affected parties. Auditors will look for evidence that the plan was actually followed during any incidents in the audit period, and that you tested it even if no real incidents occurred.
These are typical controls and implementation steps. Your systems and environment may differ.
Typical Control Incident Response Plan with defined phases and roles
Implementation Steps
Publish a written Incident Response Plan covering: preparation, detection, containment, eradication, recovery, and post-incident review, each phase must have defined steps and role owners
Assign a Security Response Team (SRT) with named roles: Incident Commander, Technical Lead, Communications Lead, and alternates for each
Document containment playbooks for the most likely scenarios: ransomware, unauthorized access, data exfiltration, DDoS, these can be appendices to the IR Plan
Run an annual tabletop exercise; document participants, scenario, findings, and any plan updates made as a result, this is the primary evidence of CC7.4 in a zero-incident period
Typical Control Incident Response Plan with defined phases and roles
Evidence Artifacts
Incident Response Plan document with effective date and management sign-off
Security Response Team roster with roles assigned
Tabletop exercise summary: scenario, participants, findings, and action items, with completion date
If real incidents occurred: incident ticket showing the response phases documented (contain, eradicate, recover, communicate)
📅Annual tabletop exercise; plan reviewed annually; per-incident documentation as incidents occur
Cross-framework mappings coming in v1.1
When we add ISO 42001 and ISO 27001, you'll see which controls map to this criterion.
ISO
ISO 42001
AI Management Systems
ISO
ISO 27001
Information Security
Mapping data will appear here automatically when the frameworks are published.
CC7.5
Recovery from security incidents
System Operations
4 evidence1 control
CC8.1
Authorized change management process
Change Management
8 evidence2 controls
CC9.1
Risk mitigation for business disruptions
Risk Mitigation
4 evidence1 control
CC9.2
Vendor and business partner risk management
Risk Mitigation
4 evidence1 control
Help us build what matters.
Vote for the next framework, subscribe for updates, and let us know if you'd contribute.
What should we add next?
Vote for the framework you need most.
0
ISO 42001
0
ISO 27001
0
CMMC
0
CPCSC
Stay Updated
Get notified when new frameworks and features are added.
On-premises implementation and evidence
Incident Response Plan with defined phases and roles
Implementation steps
Write and publish the Incident Response Plan; it must define the IR lifecycle phases, the Security Response Team membership, and the communication chain for P1/P2 incidents
For containment: document how to isolate a compromised host (disable NIC, remove from VLAN, pull from domain) without destroying forensic evidence
For communication: define when customers, regulators, and cyber insurance must be notified, timelines are often legally required (72-hour breach notification under PIPEDA and Law 25)
Conduct a tabletop exercise annually using a realistic scenario (e.g., a server running ransomware); document the exercise, who attended, decisions made, and plan gaps identified
Tools / systems
Security Onion (forensics)
Wazuh (IOC investigation)
Firewall appliance (network isolation)
Incident Response Plan (policy)
Evidence artifacts
Incident Response Plan with management approval signature and effective date
