Incidents and SOC 2
A breach in the middle of the audit: how the report treats it.
Teams hit by a breach partway through a Type 2 window often assume the report is lost. It rarely works that way. The auditor is not marking you down because something went wrong; it is checking whether your controls behaved the way your description says they do. A well-handled incident can be some of the best evidence you produce. A hidden one can end the engagement.
Back to SOC 2 services01 · Three questions
The three questions an auditor works through
Take them in order and the effect on the report usually becomes clear.
- Did the response controls work? Detection, escalation, containment and customer communication each have a control in your description. The incident becomes a live sample of every one of them.
- Did a preventive control fail? If a control that should have stopped the incident was missing or not running, the auditor weighs whether that is a single deviation or a wider deficiency that leaves a criterion unmet.
- Must the description say so? The description criteria require certain incidents to be disclosed, whatever the answers to the first two questions.
Only a significant deficiency can move the opinion away from unmodified. Deviations appear in the testing section of a Type 2 and are common in reports that are otherwise clean. The opinions and exceptions page explains each opinion type.
02 · Two versions
Same breach, two very different reports
Illustrative: one leaked access key, handled two ways.
Illustrative scenario. A SaaS company is four months into a twelve-month Type 2 window. An engineer pushes a cloud access key to a public code repository. The same afternoon, someone uses it to list the contents of a storage bucket.
Controls held
Caught and contained
- Secret scanning raises an alert within minutes
- On-call follows the runbook: key revoked, access logs reviewed
- The ticket records each step with system timestamps
- A post-incident review adds a pre-commit check, which then runs for eight more months
Controls missing
Reported by a customer
- No scanning was running, though the description said it was
- A customer flags the exposure three weeks later
- Nobody can say what was read, because bucket logging was off
- The fix ships in the final month, with little time to show it working
On the left, the auditor sees response controls operating, with a description disclosure needed only if a commitment was missed. On the right, a described control did not exist: a deviation at the least, and commonly a deficiency serious enough to put the opinion at risk.
03 · Where it fell
Where the incident sits on the calendar
The date decides how much of the recovery the auditor can actually see.
| When it happened | What the auditor looks at | What usually follows |
|---|---|---|
| Before the period opened | Whether the fix was in place and working once the window began | Commonly outside the opinion, though questions are likely |
| Early in the period | The response, the root cause, and months of the corrected control running | The strongest position: failure and recovery are both on record |
| Late in the period | The response and a fix with little operating history | The failure is visible; the recovery mostly is not |
| After the period, before the report is dated | Whether it reveals anything about controls during the period, and whether readers need to know | Inquiry as a subsequent event, and disclosure in some cases |
| Type 1 report | Whether the design addresses the cause on the report date | No operating history is tested |
An incident at a subservice organization is examined through that vendor's own report and your monitoring of it. One outside your system boundary matters only if it exposes a weakness in a control that is in scope.
04 · Disclosure
When the system description has to mention it
Disclosure and the opinion are separate questions.
DC 200, the criteria a SOC 2 system description is measured against, calls for two kinds of incident to be described. The first kind happened because a control was badly designed or not working. The second caused a significant miss of a service commitment or system requirement. For each, the description explains what occurred, when, how widely it reached and how it was resolved.
Describing an incident does not by itself change the opinion. A company can disclose a breach plainly and still receive an unmodified opinion, because the opinion turns on whether controls met the criteria, not on whether something bad happened.
Silence costs more than the incident
Before dating the report, the auditor questions management about incidents and collects written representations. A known incident kept out of those answers can lead to a modified opinion or to the firm withdrawing. Raise it early, with the root cause and the fix.
05 · Records to keep
The trail to start in the first hour
Evidence written during the incident beats evidence rebuilt afterwards.
- A register you can prove is whole. Every incident in the period, with a way to show none was left off, such as a saved ticket query by category.
- Times taken from tools. Alert, acknowledgement, containment and closure times from systems, not pieced together from chat.
- Root cause tied to a control. Which control should have prevented or caught the incident, and why it did or did not.
- The fix and a second pair of eyes. The change, its approval, and evidence that someone other than its author confirmed it works.
- Customer and commitment impact. Who was told, under which contract terms, and whether any commitment was missed.
If the fix replaces a tool or a process, the description has to reflect that too; the page on mid-period changes covers how.
Sources: AICPA, DC section 200, 2018 Description Criteria for a Description of a Service Organization's System in a SOC 2 Report (revised implementation guidance, 2022); AICPA attestation standards, AT-C section 205, examination engagements; AICPA guide, SOC 2 Reporting on an Examination of Controls at a Service Organization.
Questions after a breach
Should we pause the audit after a breach?
Speak to the CPA firm first. Pausing is rarely the default.
The period is fixed in the engagement, and changing it is a decision for you and the firm together. A shifted or shortened period has its own effect on what buyers see. The usual course is to finish the window with the incident handled and disclosed.
Will customers see the incident in the report?
If disclosure is required, yes, in the description.
Readers see what the description discloses and any deviations in the testing section. That is a good reason to write the incident up accurately, with the remediation beside it.
Is an incident at our cloud provider our problem?
Partly.
Under the carve-out method the provider's controls sit outside your opinion, but your controls for monitoring that provider are inside it. Show that you noticed, assessed and acted.
Does a blocked ransomware attempt count?
Usually as an event your controls handled.
A blocked attempt is commonly logged as an event or a low-severity incident under your own classification. It is useful proof that detection worked, and seldom anything the description must disclose.
Do we have to notify customers to protect the report?
Notify because contracts and law say so.
Notification duties come from contracts and laws, not from SOC 2. The auditor tests whatever communication control you describe, and a missed contractual notice may count as a missed commitment.
Make incidents leave a clean trail.
A SOC 2 readiness assessment from Auditify sets up incident handling that records timestamps, owners and fixes as it runs.