CC7.5
Recovery from Security Incidents
SOC 2 · 2017 TSC (2022 Revised Points of Focus) · Last verified July 2026
Objective
The entity identifies, develops, and implements activities to recover from identified security incidents.
Points of focus
- Restores the affected environment to functional operation
- Communicates information about the event and recovery actions to management and others as appropriate
- Determines root cause of the event
- Implements changes to prevent and detect recurrences
- Improves response and recovery procedures from lessons learned
- Implements periodic incident-recovery plan testing
Implementation notes
CC7.5 requires planned recovery from security incidents: rebuild or restore systems, communicate what happened and what changed, find root cause, and implement preventive and detective improvements. SaaS teams should standardize blameless postmortems with owners and due dates, verify corrective actions before closing the incident record, and feed lessons into detection rules and the IR plan. Pair application-level recovery with backup restore testing and, where availability is claimed, broader DR exercises that include loss of key people and critical dependencies. Document test scenarios, participants, results, and plan revisions. AICPA points of focus explicitly expect periodic incident-recovery plan testing — untested backups are a frequent audit and operational failure mode.
Audit tip: Link each material incident to a postmortem, completed corrective actions, and — at least annually — a recovery test with observed results.
Evidence auditors typically request:
- Post-incident review / blameless postmortem with root cause and action items
- Tickets proving preventive control changes (patches, detections, access fixes)
- Updated IR or recovery procedures after lessons learned
- Backup restore or incident-recovery test records for the period
- Management communication summarizing recovery status
Common gaps
- Incidents closed when service is 'up' with no root-cause analysis
- Action items from postmortems never completed or verified
- No recovery testing — backups unproven
- IR plan unchanged despite repeated similar incidents
Cross-Framework Mapping
| Framework | Requirement | Implementation note |
|---|---|---|
| SOC 2 | CC7.5 | This control |
| ISO 27001 | A.5.27, A.5.29, A.5.30 | Learning from incidents, disruption readiness, and ICT continuity |
| HIPAA | 164.308(a)(7)(ii)(B), 164.308(a)(7)(ii)(C) | Disaster recovery and emergency mode operations |
| GDPR | Article 32(1)(c) | Ability to restore availability and access to personal data in a timely manner |
Primary sources
- AICPA Trust Services Criteria: AICPA TSP Section 100 — 2017 Trust Services Criteria with 2022 Revised Points of Focus