TSC-CC7.5 Guidance

TSC-CC7.5 requires you to have defined, implemented recovery activities for security incidents, and to prove they work in practice. Operationalize it by documenting your incident recovery procedures (restore, rebuild, validate, and communicate), assigning owners, running recovery exercises, and retaining evidence that recovery steps were executed and reviewed ¹.

Key takeaways:

• Your SOC 2 auditor will look for documented incident recovery activities, not just incident detection and response ¹.
• Evidence wins: tickets, timelines, approvals, post-incident reviews, and recovery test results are the difference between “designed” and “operating” ¹.
• Recovery must be feasible for your actual architecture, third parties, and backup/restore model, and you need to test it ¹.

CC7.5 is the SOC 2 “recovery muscle” criterion. Many teams can show alerting, triage, and containment, but stumble when the auditor asks: “How do you restore normal operations safely after a security incident, and how do you know recovery worked?” The requirement is not asking for a specific technology stack or a particular RTO/RPO target. It is asking for intentional recovery activities that you identify, develop, and implement as part of your security incident program ¹.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to (1) define what “recovery” means for your critical services, (2) document the repeatable steps and decision points, (3) wire those steps into your incident workflow and change management, and (4) retain evidence from both real incidents and tabletop or technical recovery exercises. If you do that, you can usually answer auditor questions without inventing process during fieldwork. The rest of this page is written as a requirement-level implementation guide you can hand to Security, SRE/IT, and Product owners and then audit internally.

Regulatory text

Requirement (excerpt): “The entity identifies, develops, and implements activities to recover from security incidents” ¹.

Operator interpretation: You need documented recovery activities (playbooks/procedures) that are actually used after security incidents to restore systems and data to an acceptable state, validate integrity, and return to business-as-usual with appropriate approvals and review. Auditors will expect you to show (a) the process exists, (b) people follow it, and (c) you learn and improve it over time ¹.

What “recover” includes in practice (scope you should cover):

• Restoring service availability (rebuild systems, failover, restore backups, rotate credentials)
• Restoring trustworthy state (eradicate persistence, verify integrity, confirm clean builds)
• Restoring business operations (customer comms, support runbooks, workarounds)
• Capturing proof (timestamps, approver names, tickets, validation results)

Plain-English requirement (tsc-cc7.5 guidance requirement)

You must be able to answer: “After a security incident, how do we safely get back to normal?” Then you must show that the answer is written down, assigned to owners, and executed consistently. If recovery depends on a third party (cloud host, managed detection, SaaS platform, colocation, backup provider), your recovery procedure must explicitly include that dependency, including how you engage them and how you document outcomes.

Who it applies to

Entities: Organizations undergoing a SOC 2 examination under the AICPA Trust Services Criteria ¹.

Operational contexts where CC7.5 becomes “high friction”:

• Cloud-native environments with ephemeral infrastructure (recovery is “rebuild,” not “restore”)
• SaaS providers with multi-tenant data (recovery must consider tenant isolation and data integrity checks)
• Heavily outsourced operations (recovery steps span third parties and internal teams)
• Regulated customers (recovery is tied to notification and customer assurance expectations, even if not strictly required by SOC 2)

What you actually need to do (step-by-step)

1) Define recovery objectives for “in-scope services”

Create a short inventory of the services and data stores that matter for SOC 2 scope (systems, customer data locations, admin planes). For each, define what recovery means:

• “Service is back online” criteria (technical)
• “Service is safe to resume” criteria (security validation)
• “Customer-impact is addressed” criteria (operational)

Deliverable: Recovery criteria matrix by system/service.

2) Write an Incident Recovery Procedure (one policy, multiple playbooks)

Keep it readable. Auditors reward clarity. Minimum content:

• Trigger: what starts recovery activities (e.g., containment complete, or leadership decision)
• Roles: incident commander, security lead, infrastructure/app owners, comms lead, approver
• Recovery steps: rebuild/restore, credential rotation, patching, configuration resets
• Validation: integrity checks, malware scanning, log review, monitoring “green” criteria
• Return-to-service approvals: who signs off and where it’s recorded
• Evidence requirements: what artifacts must be attached to the incident record
• Post-incident review: required, with owners and due dates

Deliverable: Incident Recovery Standard/Procedure plus system-specific recovery runbooks.

3) Integrate recovery into your incident workflow (tickets, not PDFs)

Recovery must be “implemented,” not just described ¹. Put recovery tasks into the same system where incidents are managed (Jira, ServiceNow, PagerDuty notes, GitHub Issues, etc.):

• Create a recovery checklist template for security incidents
• Require task assignment and completion timestamps
• Require attachments/links to validation outputs and approvals

Deliverable: Incident template with recovery task sections.

4) Build your “recovery evidence pack” requirements

Define what must be retained for each incident (or exercise). Examples:

• Timeline of key events (containment start/end, recovery start/end, return-to-service approval)
• Records of restores/rebuilds (change tickets, run commands output, infrastructure-as-code PRs)
• Identity actions (credential rotation tickets, key revocation logs)
• Validation artifacts (hash comparisons, scan results, monitoring screenshots, test results)
• Communications approvals (internal comms, customer notices if used)

Deliverable: Evidence retention checklist mapped to incident types.

5) Test recovery activities (tabletop plus technical where feasible)

CC7.5 is commonly challenged when teams have never practiced recovery. Run:

• Tabletop exercise: walk through a realistic incident and force recovery decisions
• Technical recovery test: restore from backups, rebuild an environment, validate data integrity where applicable

Deliverable: Exercise report with outcomes, issues found, and remediation tickets.

6) Establish monitoring and review of recovery readiness

Set a cadence for reviewing recovery procedures and lessons learned:

• Review after material incidents
• Review after platform changes (new architecture, new third parties, new backup approach)
• Track corrective actions to closure

Deliverable: Recovery readiness review log and post-incident review register.

Required evidence and artifacts to retain

Auditors typically test both design and operating effectiveness. Keep evidence that is easy to sample:

Core artifacts (nearly always requested):

• Incident Response & Recovery policy/procedure (versioned, approved)
• Recovery runbooks for key systems
• Incident records that show recovery tasks were executed
• Post-incident reviews (PIRs) that include recovery effectiveness and follow-ups
• Recovery exercise/tabletop documentation and resulting action items ¹

High-quality operating evidence (makes audits faster):

• Change records linked to recovery actions (patches, rebuilds, config changes)
• Backup/restore logs or job reports tied to the incident
• Access/key rotation evidence tied to the incident
• “Return to service” approvals (e.g., incident commander sign-off in ticket)

Common exam/audit questions and hangups

Expect your SOC 2 auditor to probe these areas ¹:

1. “Show me a recent incident and how you recovered.”
   Hangup: incident ticket has containment notes but no recovery tasks, no validation, no closure approval.

2. “How do you validate recovery?”
   Hangup: teams equate “service up” with “secure,” but can’t show integrity validation, credential resets, or monitoring stabilization criteria.

3. “What if the incident is caused by a third party?”
   Hangup: no documented engagement path, no records of the third party’s recovery actions, and no internal validation after their fix.

4. “How do you know your recovery procedures stay current?”
   Hangup: runbooks exist, but nobody reviews them after major architecture changes.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why auditors flag it	Fix
Recovery documented only as “restore backups”	Too narrow; misses rebuild, validation, approvals	Add recovery phases: restore/rebuild, eradicate, validate, approve return-to-service
No evidence of execution	“Implemented” is not provable	Force recovery checklists inside incident tickets; require artifacts before closure
“One-size” runbook	Doesn’t match actual systems	Maintain runbooks per critical service/data store; keep them short and owned
Tests are informal	Hard to rely on for operating effectiveness	Write an exercise report, track issues, close corrective actions
Third party dependencies ignored	Recovery may be blocked by suppliers	Add third party contact paths, contractual hooks, and evidence expectations

Enforcement context and risk implications

SOC 2 is an audit framework, not a regulatory enforcement regime, and no public enforcement cases were provided in the source catalog for this criterion ¹. Your practical risk is:

• A qualified SOC 2 opinion or a control exception if recovery activities are not implemented or not evidenced.
• Customer trust impact when you cannot demonstrate orderly recovery and validation after an incident.
• Operational risk: teams improvise recovery under pressure, increasing the odds of data integrity issues or re-compromise.

Practical 30/60/90-day execution plan

Days 1–30: Define and document the minimum viable recovery program

• Confirm SOC 2 scope systems and data stores; draft the recovery criteria matrix.
• Publish an Incident Recovery Procedure with roles, recovery phases, validation, and return-to-service approval.
• Create incident ticket templates with required recovery tasks and evidence fields.
• Identify top third parties that affect recovery (cloud provider, backup provider, managed services) and document engagement steps.

Days 31–60: Implement in workflow and collect initial operating evidence

• Train incident commanders and system owners on the recovery checklist and artifact expectations.
• Run one tabletop focused on recovery decisions and communications; create remediation tickets.
• Update runbooks for the top critical services; assign owners and review cadence.
• Start a recovery readiness review log (what changed, what was reviewed, and who approved).

Days 61–90: Prove operating effectiveness and close gaps

• Run one technical recovery test aligned to your architecture (restore or rebuild plus validation).
• Perform an internal control test: pick incidents/exercises and verify required evidence exists end-to-end.
• Close or formally track corrective actions from PIRs and exercises.
• Package artifacts for audit sampling (policy, runbooks, incident records, exercises, PIRs).

Where Daydream fits (without adding process overhead)

If your bottleneck is evidence quality, Daydream can help by standardizing what your teams attach to incident records (recovery checklists, approvals, validation outputs) and keeping an audit-ready trail across incidents, exercises, and follow-up actions. The win is consistency: fewer one-off spreadsheets, fewer missing links during fieldwork, faster sampling response.

Frequently Asked Questions

What counts as “activities to recover” under CC7.5?

Actions that restore operations and a trusted state after a security incident, such as rebuilds/restores, credential rotation, integrity validation, and formal return-to-service approval ¹.

Do we need documented RTO/RPO targets to satisfy CC7.5?

CC7.5 does not prescribe specific targets in the provided text ¹. Auditors typically focus on whether your recovery activities are defined, implemented, and evidenced for in-scope systems.

We have DR/BCP. Is that enough?

DR/BCP helps, but CC7.5 is specifically about recovery from security incidents ¹. You still need security-specific steps like eradication checks, credential resets, and validation before resuming service.

How do we handle recovery when a cloud/SaaS third party is the root cause?

Document the engagement path (support channels, escalation, decision rights), record what the third party did, then perform your own validation before returning to service. Keep those records attached to the incident.

What evidence is most persuasive to auditors?

Incident tickets showing assigned recovery tasks, timestamps, approvals, and validation artifacts, plus post-incident reviews and recovery exercise reports ¹.

What if we haven’t had a real security incident during the audit period?

Use recovery exercises to show implementation and testing, and retain the same artifacts you would retain for a real incident ¹.

Related compliance topics

• 2025 SEC Marketing Rule Examination Focus Areas
• Access and identity controls
• Access Control (AC)
• Access control and identity discipline
• Access control management

Footnotes

1. AICPA TSC 2017, 2017