SOC 2 CC7.5: incident recovery, explained for startups

What CC7.5 asks you to show about incident recovery, and what proves it.

After an incident you restore what broke and learn from it. Backups you have tested, a postmortem with action items, and changes made because of them. The loop has to close.1

CC7.5 is a common criterion, so it is part of every SOC 2 report.

What usually proves it

An auditor wants records from the period being examined, pulled from the systems that hold them rather than written up afterwards. Dates matter. A record with a date and a named owner carries more weight than a screenshot with neither. For CC7.5, the usual records are these.

  • Postmortems with root cause and action items
  • Backup restore test records
  • Tickets closing the action items

What Polara asks about it

The free readiness assessment asks 7 questions that bear on CC7.5. A yes becomes a task to show the proof. A no becomes a task to fix the gap, with the steps written out.

  • Incident Response Plan exists and is approved? If yes, show it: incident Response Plan with approval signature, on-call escalation chart, tabletop exercise notes, or incident response runbook. If no, the fix: approve an incident response plan with roles, severity levels, and escalation paths.
  • Root cause analysis performed for high-severity incidents? If yes, show it: postmortem template, completed root cause analysis for a past incident, action item tracker, or root cause analysis document. If no, the fix: adopt a post-incident review template that records root cause and corrective actions, and apply it to every high-severity incident.
  • Databases and volumes backed up? If yes, show it: AWS Relational Database Service (RDS) automated backup settings, S3 bucket for backups, backup job schedule, or backup success logs. If no, the fix: enable automated backups for databases and volumes and export the backup configuration.
  • Backups encrypted? If yes, show it: relational Database Service (RDS) backup encryption settings, S3 bucket encryption, key management service (KMS) key policy, or encrypted backup report. If no, the fix: enable encryption on backup storage and export the configuration.
  • Multi-region or multi-zone recovery strategy? If yes, show it: DR architecture diagram, AWS multi-region setup, failover runbook, or DR environment inventory. If no, the fix: define a recovery strategy across zones or regions and document the recovery objectives.
  • DR/BCP tested at least annually? If yes, show it: disaster recovery test results report, tabletop exercise notes, recovery time and recovery point test summary, or remediation task list. If no, the fix: run a disaster recovery test at least annually and retain the test record and lessons learned.

It also asks, for context:

  • Backup frequency.

Policies, templates and connected evidence

A policy states the rule, a template gives you the record to keep, and a connected system pulls the proof from the source. An auditor checks that the three agree: the cadence in the policy, the dates in the record and what the system shows.

In the policy pack, the Incident Response Policy and Business Continuity and Disaster Recovery Policy cover CC7.5.

Free templates that help, printed in full with Word, PDF or Excel downloads:

If you also run ISO 27001, the Annex A controls A.5.27, learning from incidents, A.5.29, security during a disruption, A.5.30, technology continuity and A.8.13, backups ask for overlapping evidence. One record can serve both when it names what it proves.

Where it goes wrong

One gap a remediation playbook covers here is incident Response Plan. The fix: draft an incident response plan and get executive approval. The proof: signed incident response plan document (PDF with executive signature).

An auditor asks two things about it. Is there a documented incident response plan? Has the IR plan been approved by management and communicated to the team?

Is it in your scope?

Yes, always. CC7.5 is one of the 33 common criteria, and the common criteria are in every SOC 2 report, Type 1 or Type 2. The common criteria. Every SOC 2 report covers them, whatever else you add: governance, risk, access, operations, change and vendors. Most of the work in any SOC 2 sits here.

Polara Labs is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.

System operations: the criteria around it

CC7.5 is one of 5 criteria in system operations, CC7.1 to CC7.5. Reading a group together shows how its outcomes fit, and one record often serves more than one of them.

Before it: CC7.4, incident response. After it: CC8.1, change management. All the criteria are on the Trust Services Criteria page, grouped by category.

Questions

What does SOC 2 CC7.5 ask a startup to show?
After an incident you restore what broke and learn from it. Backups you have tested, a postmortem with action items, and changes made because of them. The loop has to close.
What evidence proves CC7.5?
The usual evidence is postmortems with root cause and action items, backup restore test records and tickets closing the action items. An auditor tests it across the report period, so dated records matter more than a written promise.

Sources

  1. TSP Section 100, Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy AICPA. The criteria themselves, including the common criteria every SOC 2 report covers.

Get audit-ready without a compliance team.

The readiness assessment is free, with no payment and no card. Star is $2,000 one time to get on the platform and close your gaps. Orbit is $7,800 a year, and your SOC 2 Type 2 audit is included in every contract year. You can be audit-ready starting at about a week.

Take the free assessment

Polara Labs is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.