Skip to content
AuditFront
CC7.5 SOC 2

SOC 2 CC7.5: System Operations - Incident Recovery

What This Control Requires

The entity identifies, develops, and implements activities to recover from identified security incidents. Recovery planning and processes are established and in place to restore systems or assets affected by security incidents to normal operations.

In Plain Language

Containing a breach is only half the battle. Getting back to normal operations - safely and completely - is where many organisations stumble. CC7.5 covers the recovery phase: restoring systems, verifying their integrity, and confirming the root cause is fully addressed before going back to business as usual. This means having tested recovery procedures, reliable backups you've actually restored from, the ability to rebuild systems from known-good configurations, and clear criteria for when it's safe to resume normal operations. Recovery without verifying the compromise is gone is a recipe for reinfection. Auditors want to see documented recovery procedures, tested backup and restoration capabilities, evidence of successful recovery from past incidents, and integration with your broader incident response and business continuity framework. Backups that have never been tested are one of the most common and most dangerous findings.

How to Implement

Write recovery procedures for each type of security incident in your risk assessment and IR playbooks. Cover restoration from backups, system rebuilds, data recovery, and service verification steps specific to each scenario. Build a comprehensive backup strategy. Define requirements for every critical system: backup frequency (daily, hourly, continuous), retention periods, storage locations (on-site plus off-site or cloud), and encryption. Automate backups, monitor them for success, and store copies somewhere that wouldn't be affected by the same incident as your primary systems. Test backup and recovery regularly. Run restoration tests at least quarterly for critical systems - full system recoveries, individual file restores, and database point-in-time recoveries. Document results including recovery time and any issues. Track actual recovery times against your RTOs. Define criteria for returning to normal operations after an incident. Verify the root cause has been addressed, confirm restored systems are clean, validate all data has been recovered and is consistent, and get management sign-off before closing the incident. Tie incident recovery into business continuity planning. Account for system dependencies, have communication plans for stakeholders during recovery, and prepare alternative processing arrangements in case recovery takes longer than expected. Document every recovery activity. Record what was restored, the method used, how long it took, any data loss, and issues encountered. Feed this back into your procedures to improve recovery times and refine RTO and RPO targets.

Evidence Your Auditor Will Request

  • Documented recovery procedures for different security incident scenarios
  • Backup configuration documentation including schedules, retention, and storage locations
  • Backup and recovery test results including recovery times and success/failure outcomes
  • Criteria and sign-off records for returning to normal operations after incidents
  • Recovery documentation from actual incidents including timelines and lessons learned

Common Mistakes

  • Backups are performed but never tested for recoverability, creating false confidence
  • Recovery procedures are not documented, forcing ad hoc recovery during high-stress situations
  • Backups are stored in the same environment as production, leaving them vulnerable to the same incident
  • Recovery time objectives (RTOs) are defined but never validated through testing
  • Recovered systems are put back into production without verifying they are free from compromise

Related Controls Across Frameworks

Framework Control ID Relationship
ISO 27001 A.5.29 Equivalent
ISO 27001 A.5.30 Related
ISO 27001 A.8.13 Related
nist-csf RC.RP-01 Equivalent

Frequently Asked Questions

What is the difference between RTO and RPO?
Recovery Time Objective (RTO) is the maximum acceptable time to restore a system after an incident. Recovery Point Objective (RPO) is the maximum acceptable data loss measured in time - an RPO of 1 hour means you could lose up to 1 hour of data. Define both for each critical system based on business impact analysis, and validate them through actual testing.
How should we protect backups from ransomware?
Follow the 3-2-1 rule: at least 3 copies of data on 2 different media types with 1 copy off-site or offline. Use immutable storage that prevents deletion or modification. Air-gapped or offline backups are the gold standard for critical data. And critically, test that you can restore from these backups even if your primary backup infrastructure is compromised.
How often should we test full system recovery?
At least annually for critical systems, with quarterly tests for individual components (file restores, database recoveries). More frequent tests for your most critical services are better. Also test after any significant change to backup infrastructure, storage, or recovery procedures. The goal is confidence that when you need those backups, they actually work.

Track SOC 2 compliance in one place

AuditFront helps you manage every SOC 2 control, collect evidence, and stay audit-ready.

Start Free Assessment