CC7.5 Recovering from security incidents

Recovery work after an identified security incident is identified, developed and carried out. Points of focus: the affected environment is returned to working order by rebuilding systems, updating software, patching and reconfiguring; the nature of the incident, recovery steps and prevention measures are communicated internally and externally as appropriate; the root cause is found; architecture or preventive and detective controls are changed to stop recurrence; lessons learned improve response and recovery procedures; and incident-recovery testing is performed periodically using scenarios weighted by how likely and how severe threats are, components that can impair availability, loss of key personnel, and revision of plans from the results.

Source: SOC 2 (2017 Trust Services Criteria), CC7.5. The statement above is our statement of the clause, read from the published text and cited so you can check it against the official text, not the instrument verbatim. Open SOC 2 (2017 Trust Services Criteria) in the compliance library.

These are criteria, not controls: you design controls that meet them, and which criteria are in scope follows the categories your report covers (Security always; Availability, Confidentiality, Processing Integrity and Privacy only if chosen). A Type 2 report tests that the controls operated across the period, so the evidence asked for is samples across that period, not one copy.