SOC 2 CC7.5: Recovering From Identified Security Incidents

SOC 2 CC7.5 requires a company to identify, develop, and implement the activities that recover the environment after a security incident, and to learn from the incident so it does not repeat. It closes the CC7 series (System Operations), taking over where the response criterion ends. A frequent finding under it is a team that restores service quickly but never determines root cause, tests its recovery, or improves its procedures.

What does SOC 2 CC7.5 require?

In plain terms, CC7.5 is the recovery and learning stage of the incident lifecycle. Detection and evaluation happen under CC7.3, and containment and immediate response under CC7.4. CC7.5 governs what it takes to get the affected systems back to a known-good state and to close the loop so the same incident is less likely to recur.

Recovery here means more than restarting a service. The criterion expects the affected environment to be restored to functional operation, which often involves rebuilding systems from clean images, restoring data from backup, reapplying patches, and correcting the access controls or configurations that the incident touched. That is why CC7.5 leans heavily on backup and disaster-recovery capability: the ability to restore cleanly is what makes recovery from a serious incident possible at all.

The other half of CC7.5 is improvement. The criterion asks the company to determine the root cause, implement changes that prevent and detect a recurrence, improve its response and recovery procedures from the lessons learned, and test its recovery plan on a periodic basis. Recovery that stops at getting back online, without root cause or a tested plan, is the part auditors most often find missing.

What are the CC7.5 points of focus?

The AICPA defines 6 points of focus for CC7.5. Because the Trust Services Criteria are AICPA copyrighted material, the points of focus below are paraphrased and grouped by theme rather than reproduced verbatim; consult the official TSC document for exact wording.

• Restore the affected environment. Recovery activities return the affected environment to functional operation by rebuilding systems, updating software, installing patches, modifying access controls, and changing configurations as needed.
• Communicate about the incident. Information about the nature of the incident, the recovery actions taken, and the steps needed to prevent future incidents is communicated to management and to other internal and external parties as appropriate.
• Determine root cause. The underlying root cause of the incident is identified, not just the symptom that was cleared.
• Prevent and detect recurrence. Additional architecture or changes to preventive and detective controls are implemented so the same class of incident is prevented or caught quickly if it happens again.
• Improve response and recovery procedures. Lessons learned are analyzed and fed back into the incident-response plan and the recovery procedures.
• Test the recovery plan. Incident-recovery plan testing is performed periodically, using scenarios based on threat likelihood and impact, accounting for the possible loss of key personnel and system components, and revising resilience and continuity plans based on the results.

How do you meet CC7.5 in cloud environments?

Cloud environments meet CC7.5 by combining the platform's recovery primitives with a disciplined root-cause and improvement loop:

• Restore from clean, versioned sources. Recovery rebuilds from infrastructure-as-code and hardened images and restores data from point-in-time backups or snapshots, so a compromised resource is replaced rather than patched in place.
• Backup and multi-zone resilience. Automated backups and multi-availability-zone or cross-region redundancy provide the recovery capacity, and restores are verified rather than assumed.
• Root-cause and preventive change. Each significant incident produces a documented root-cause analysis, and the resulting control changes (a new detection rule, a tightened policy, an architecture change) flow through the change process under CC8.1.
• Recovery testing. Restore drills and game-day exercises validate that backups are usable and that recovery meets the recovery-time objective, with the results retained as evidence.

How do you meet CC7.5 on-prem?

On-prem environments carry more of the recovery machinery themselves, since the backup and disaster-recovery stack is owned rather than inherited. The backup and disaster recovery on-prem guide covers the detail; for CC7.5 the shape is:

• Owned backup and standby capacity. Recovery relies on backups and, often, a warm-standby server that can become production after a data refresh, with transaction logs shipped offsite so the recovery point is recent.
• Clean rebuilds from a runbook. A version-controlled build runbook lets a hardened server be rebuilt to a known-good state, which is the on-prem equivalent of redeploying from an image.
• Restoration testing on a cadence. At least one restoration test per quarter during the observation period takes a backup, restores it to an isolated environment, and verifies the data is complete and usable, which also validates the recovery-time objective.
• Root cause, communication, and improvement. A post-incident review determines root cause, communications go to management and affected parties, and the lessons feed documented changes to the recovery procedures and a periodic disaster-recovery tabletop.

Cloud vs on-prem at a glance

What evidence do auditors expect for CC7.5?

How does CC7.5 map to ISO 27001:2022?

The overlap is direct: A 5.27 is the ISO control for learning from incidents, which matches the root-cause and improvement focus of CC7.5, while A 8.13 and A 8.14 provide the backup and redundancy that the restore-the-environment focus depends on. Evidence produced for CC7.5 can be reused for all three. The SOC 2 to ISO 27001 control mapping covers the full crosswalk across all five Trust Services Categories.

Related criteria

CC7.5 completes the incident lifecycle that runs through the CC7 series. Evaluation under CC7.3 decides that an event is an incident, response under CC7.4 contains and remediates it, and CC7.5 recovers the environment and feeds the lessons back into the program. Its recovery and continuity focus also connects to risk mitigation under CC9.1, which covers business-disruption risk and business continuity more broadly, and the preventive and detective changes it drives are implemented through the change management of CC8.1.

Frequently Asked Questions

What does SOC 2 CC7.5 mean?

SOC 2 CC7.5 means the company identifies, develops, and implements the activities needed to recover from a security incident. That covers restoring the affected environment to a known-good state and closing the loop by determining root cause, preventing recurrence, improving procedures, and testing the recovery plan.

What evidence satisfies CC7.5?

The core evidence is an incident-recovery or BCDR plan, backup configuration and success logs, restoration test records that validate the recovery-time objective, post-incident root-cause reviews, change records for preventive and detective improvements, and disaster-recovery tabletop results.

What is the difference between CC7.4 and CC7.5?

CC7.4 is the response: containing, remediating, and communicating a confirmed incident. CC7.5 is the recovery and learning that follows: restoring the environment, determining root cause, preventing recurrence, improving procedures, and testing the recovery plan. CC7.4 stops the bleeding; CC7.5 restores the system and hardens it against a repeat.

How often should recovery and restoration testing be performed for CC7.5?

CC7.5 expects recovery-plan testing on a periodic basis. A common cadence is at least one restoration test per quarter during the observation period plus a disaster-recovery tabletop at least annually, with the results used to revise the recovery and continuity plans.

How does CC7.5 relate to backup and disaster recovery?

Backup and disaster recovery provide the capacity CC7.5 depends on. Restoring the affected environment usually means rebuilding systems and restoring data from backup, so backup coverage, verified restores, and redundancy are what make recovery from a serious incident possible and testable.