Learn · SOC Reports
A Security Incident During
Your Observation Period
An incident does not automatically prevent a SOC 2 report or force a qualified opinion. The examination asks whether the controls you described operated as you described them — and an incident your own monitoring detected, escalated and contained is evidence for those controls, not against them.
Three questions get collapsed into one. Did a control fail? Does that failure mean a trust services criterion was not achieved? And must the incident be disclosed in the system description? They have different answers and different evidence — and the second and third can each modify the opinion, by different routes.
Plain-English explainer · AT-C 205 examination · DC section 200 · Last reviewed August 2026
A security incident during your observation period does not, by itself, cost you the report or qualify the opinion. A SOC 2 examination tests whether the controls described in Section 3 were suitably designed and — in a Type 2 — operated effectively across the period to achieve the applicable Trust Services Criteria. An incident your monitoring detected, your response process handled, and you remediated and evidenced is the system working. What damages a report is narrower: a control that did not operate as described with nothing compensating, a description that claims controls not actually being performed, or an incident that should have been disclosed and was not. The criteria are written on the assumption that things go wrong. CC7.1 requires detection and monitoring procedures that identify configuration changes introducing new vulnerabilities and susceptibilities to newly discovered ones — the criterion the worked example below actually fails. CC7.2 requires monitoring for anomalies indicative of malicious acts, CC7.3 evaluating security events for whether they have caused a failure to meet objectives, CC7.4 responding by executing a defined incident-response programme to understand, contain, remediate and communicate, and CC7.5 recovery. Those five criteria only mean anything if incidents happen. If the document itself is new to you, start with how to read a SOC 2 report.
Four words, four meanings
Event, incident, exception, deficiency
Most of the panic in the first 48 hours comes from using these four interchangeably. They are defined terms, they escalate in one direction only, and each step requires a separate judgement. Two are defined by the AICPA description criteria; two belong to the auditor.
System event
DC section 200 works from an occurrence that could lead to the loss of, or disruption to, operations, services or functions and could cause a failure to achieve service commitments or system requirements (paraphrased). Most events are noise, and noise stays out of the report.
System incident
A system event that requires action by management to prevent or reduce its impact on the achievement of service commitments and system requirements. The dividing line is action required, and your own published severity matrix is what defines that line.
Exception (deviation)
A finding in a test of controls: the control did not operate as described for one or more items in the tested population. The attestation standards require the practitioner to investigate the nature and cause of a deviation and to consider what it means for the rest of the examination.
Deficiency
The auditor’s judgement that a control was not suitably designed or did not operate effectively, so an applicable criterion may not have been achieved. Exceptions are inputs; deficiencies are conclusions. Only deficiencies move the control-effectiveness opinion — description problems and scope limitations reach it by their own routes. One vocabulary note: “significant deficiency” and “material weakness” belong to SOX and ICFR reporting. Neither term appears in a SOC 2 opinion, and buyers import them constantly.
So an incident becomes an audit matter only if it points at a control that did not operate as described, or if it meets DC4’s disclosure trigger. Plenty of serious incidents do neither. A credential-stuffing wave your rate limiting absorbed is a severity-3 ticket and a good story for your control narrative, and it stays out of Section 4 entirely.
The escalation ladder
When an incident actually moves the opinion
A SOC 2 is an attestation performed under AT-C section 105 and AT-C section 205 — the assertion-based examination standard as recodified by SSAE No. 21 and later amended by SSAE No. 23 for consistency with the AICPA quality management standards. Those standards require the practitioner, on identifying deviations, to make specific inquiries and perform further procedures to understand them and their potential consequences, and to investigate their nature and cause rather than tally them. This is the shape that investigation takes.
| What happened | What the auditor concludes | Where it shows up | Effect on the opinion |
|---|---|---|---|
| Controls detected, escalated and contained the incident exactly as described | The controls operated. The incident evidences operation. | Section 3 disclosure if DC4 is triggered; Section 4 shows the controls tested with no exceptions noted. | Unmodified (clean). |
| A control failed for part of the period, was remediated, and the replacement ran long enough to test | A deviation exists for the failure window; severity, criteria affected and compensating controls are weighed. | Section 4 exception naming the population, items tested and the number and nature of deviations; management’s response, customarily in Section 5 — which sits outside the service auditor’s report. | Commonly unmodified with the exception described — a judgement made on the evidence. |
| A control failed and nothing compensated — the incident ran undetected, or response bypassed the described process | One or more applicable trust services criteria were not achieved for the period. | A basis-for-modification paragraph in Section 1 identifying the criteria affected. | Qualified — fairly stated except for the described matters. |
| The description states or implies controls that were not actually being performed | The description fails the description criteria. DC 200 says so explicitly, and no control deficiency is required to get here. | Section 1, touching the description itself rather than one control. | Qualified or adverse, depending on pervasiveness. |
| The incident destroyed the evidence needed to test controls across the period | The auditor cannot obtain sufficient appropriate evidence — a scope limitation. | Section 1, as a scope qualification or disclaimer. | Disclaimer of opinion, or qualified for scope. |
The row that does the most damage is the description row. DC 200 states that a description is not presented in accordance with the criteria if it states or implies that processes and controls have been implemented when they are not being performed — and that route reaches the opinion on its own, with no control deficiency required, because a Type 2 opinion covers three things: that the description is presented in accordance with the description criteria, that the controls were suitably designed, and that they operated effectively. An incident that exposes a described control as fiction is a description problem, and those are harder to contain because they can be pervasive. None of these outcomes is automatic, either: severity, criteria touched, compensating controls and testability of the remediation are judgements made on evidence. The full taxonomy sits in SOC 2 opinions and exceptions.
Disclosure — DC section 200
What the description must say
Disclosure lives in Section 3, written by management under the AICPA description criteria at DC section 200 — which apply to SOC 2 only; SOC 1 description requirements sit in AT-C section 320.
DC4 requires, for identified system incidents that either were the result of controls that were not suitably designed or operating effectively, or otherwise resulted in a significant failure in the achievement of service commitments and system requirements: the nature of each incident, the timing surrounding it, and its extent or effect and disposition.
— DC section 200, criterion DC4, paraphrased
Note what the trigger is. It is not severity as your engineers rank it, and customer-data impact is not the trigger in its own right — though theft or unauthorised use of sensitive information is one of the indicators the guidance says makes disclosure likely. The trigger is whether a control was ineffective, or whether the incident significantly undermined what you promise customers. The implementation guidance lists indicators that disclosure is likely — among them that the incident led to a significant change in the controls used to detect, prevent, mitigate, remediate or recover from incidents; to public disclosure required by law or regulation; to fines or sanctions from a legal or regulatory agency; to theft, alteration or unauthorised use of sensitive information including personally identifiable or health information; to a demand for payment to restore encrypted information; or to general public knowledge of the incident.
The same guidance sets the level of detail, and it is more protective than teams assume: incident disclosures are not intended to be made at a level of detail that might increase the likelihood of a hostile party exploiting a vulnerability. They exist so report users understand the nature of the risks faced and the impact of those risks materialising. In practice, a few careful paragraphs — what class of incident, when, what was affected, what was done, where it stands — rather than an attack narrative. Two neighbours matter as well: DC9 requires a Type 2 description to disclose significant changes during the period, which a serious incident usually produces; and DC 200 notes that additional disclosures may be needed, including significant interpretations such as what you treat as a security event or incident. Where nothing meets the threshold, management may say so explicitly — a positive statement of nothing to report is a stronger artefact than silence.
Worked example
One incident, carried end to end
An illustrative scenario rather than a client engagement: a B2B SaaS provider running a twelve-month Type 2 from 1 January to 31 December 2026, with Security, Availability and Confidentiality in scope. An exposed access key surfaces in April. Follow the artefacts.
14 Apr, 02:41
A detection rule fires on anomalous API calls from an unfamiliar network range using a long-lived key belonging to a data-pipeline service account. This is CC7.2 working — monitoring components for anomalies indicative of malicious acts.
02:53 – 03:20
On-call acknowledges; ticket INC-2026-0147 opened at severity 2 against the published matrix; key disabled, sessions revoked, role scoped down. Containment inside 40 minutes, evidenced by pager records and the ticket audit log rather than recollection.
15 Apr
Log review concludes the key was committed to a public repository on 28 March. Three objects in a non-production bucket were listed, none downloaded, no customer data accessed — written down with the queries that support it.
17 Apr
Root-cause analysis signed off: secret scanning in CI was switched off for one repository during a migration on 12 March and never re-enabled. The preventive control failed; the detective control worked. The failure maps to CC7.1 — detection and monitoring procedures that identify configuration changes introducing new vulnerabilities — because switching the scanner off was itself the configuration change.
24 Apr
Remediation deployed — scanning re-enabled across all 214 repositories with a blocking pre-commit hook, and all nine pipeline service accounts moved to one-hour federated credentials. A new control enters the register with an effective date.
30 Apr
Six customers whose contracts require notification of security events regardless of data impact receive a written summary. Who was told, when, and what they were told is filed with the ticket.
12 May
Compliance re-tests the new configuration independently of the engineers who shipped it and files the result. This is the step most teams skip and the one auditors most reliably ask for.
18 Jan 2027
Fieldwork. The failed control is tested across the period and the exception stands for 12 March – 24 April. The replacement is tested over its own window, 24 April – 31 December, sampling 25 of 214 repositories as of five dates. For incident response, the auditor accepted the population of 38 after reconciling it to the SIEM alert export, then selected 12 — every severity-1 and severity-2 ticket, four severity-3 tickets, and INC-2026-0147, which was already disclosed under DC4.
26 Feb 2027
Report issued. Section 3 discloses the incident under DC4 — nature, timing, extent and disposition. Section 4 carries the exception and the clean result on the replacement control. The opinion is unmodified.
The outcome hinges on three unglamorous facts. Detection was automated and time-stamped, so CC7.2 and CC7.4 could be tested against system records. The root cause named a control rather than a person, so the exception scoped to a window — 12 March to 24 April — instead of hanging over the whole period. And the replacement ran for eight months before fieldwork closed, so it could be tested in its own right. Move this incident to 15 December and two of those three advantages disappear.
What it looks like on the page
The same incident, in report language
Teams argue about outcomes they have never seen written down. Here is the April key exposure as it would appear in three places in the document. Every block below is illustrative wording written for this page — it is composed, and it comes from no real report.
Section 4 — control, test and result (illustrative wording, composed for this page)
Control
Automated secret scanning is enabled on all source-code repositories.
Test performed
Inspected the secret-scanning configuration for a haphazard selection of 25 of 214 repositories as of five dates across the period.
Results
Exception noted. For one repository, scanning was disabled from 12 March 2026 to 24 April 2026 following a platform migration and was not re-enabled until remediation was deployed.
Section 3 — the DC4 disclosure (illustrative wording, composed for this page)
On 14 April 2026 the entity identified anomalous API activity originating outside its normal network ranges, traced to a long-lived credential belonging to a data-pipeline service account. The credential was disabled and associated sessions revoked the same day. Investigation determined that the credential had been exposed in a public source-code repository on 28 March 2026 because automated secret scanning had been disabled for that repository during a platform migration. Observed activity was limited to listing objects in a non-production storage bucket; no production or customer data was accessed. Secret scanning was re-enabled across all repositories and pipeline service accounts were migrated to short-lived federated credentials, effective 24 April 2026.
Roughly ninety words, written at the protective level of detail the description criteria call for: class of incident, dates, what was affected, disposition — with no rule logic, host names or exploit path.
Section 1 — basis for a qualified opinion, had nothing compensated (illustrative wording, composed for this page)
The controls stated in the description did not operate effectively throughout the period 1 January 2026 to 31 December 2026 to provide reasonable assurance that detection and monitoring procedures identified changes to configurations resulting in the introduction of new vulnerabilities (criterion CC7.1), because automated secret scanning was disabled for one source-code repository from 12 March 2026 to 24 April 2026. In our opinion, except for the matter described in the preceding paragraph, in all material respects, the controls stated in the description operated effectively throughout the period to provide reasonable assurance that the service organisation’s service commitments and system requirements were achieved based on the applicable trust services criteria.
In the worked example the opinion was unmodified, because a detective control caught the exposure and the replacement was independently tested for eight months. This block shows what the same facts produce when nothing compensates: the criterion is named, and the window is stated on the face of the opinion.
While it is still live
The first 72 hours
The incident is the engineers’ job; the record of it is yours. Almost every audit position that collapses later collapses here, in the hours when nobody is thinking about fieldwork — logs rotate, alerts get tuned, tickets close and reopen, severity gets re-graded once the outcome is known. Seven actions, none of which slow the response down.
- 1
Preserve the triggering alert and its rule version. Tuning the detection stack mid-response is normal and it overwrites the exact artefact that proves detection worked. Export the alert, the rule as it stood, and the routing record before anyone edits them.
- 2
Extend log retention on the affected sources before rotation reclaims them. Authentication logs, API gateway logs, CI logs, object-store access logs. A 30-day default is shorter than the road to fieldwork, and no reconstruction replaces the original.
- 3
Record severity changes as changes. Re-grading after closure is defensible when who changed it, when, and why is written down. A silent re-grade looks like the matrix was fitted to the outcome, and the ticket audit log shows the edit anyway.
- 4
Keep the ticket open until root cause is documented. A ticket closed at containment and reopened a week later carries two closure timestamps and an obvious question. One ticket, one lifecycle, with the RCA attached before it closes.
- 5
Snapshot the pre-remediation configuration state. A before/after diff is what turns “we fixed it” into evidence. Once the fix ships, only the fixed state survives, and the auditor is left inspecting an assertion.
- 6
Capture pager and on-call records the same week. These are the independent corroboration for acknowledgement and containment times, and they age out of most tools fastest of anything you will need.
- 7
Write the factual timeline from system records within the week. Timestamps, sources, and the queries that produced them. Written at week one it is evidence; written at month six it is recollection, and it reads that way.
Evidence
What the CPA firm actually requests
Testing an incident is population work before it is anything else: the auditor establishes the complete set of incidents for the period, satisfies themselves it is complete, selects items, and examines each one against the process you described.
| Artefact requested | What it has to show | Why it gets sent back |
|---|---|---|
| The complete incident population | A system-generated export of every ticket in the period — identifier, opened timestamp, severity, owner, closed timestamp — with the query visible, the record count, and the export date. | A hand-maintained spreadsheet, or a filtered view showing only the tickets you want discussed. Completeness is tested before anything is sampled. |
| Independent completeness corroboration | A second source the population reconciles against — SIEM alert export, pager history, ticketing-system audit log. | A management statement that the list is complete. Written representations are required, but they do not substitute for evidence. |
| The incident ticket, with its alert | Detection source, the alert and its rule, routing to the responder, triage and containment timestamps, severity assigned against the published matrix, actions, approvals, closure. | Tickets created days later to document the event retrospectively — the creation timestamp is in the audit log. Alert screenshots with nothing tying them to the ticket. |
| Root-cause analysis | A dated document with a named owner, the causal chain, and the specific control that failed or was absent, mapped to a criterion where possible. | Undated documents, or an RCA concluding “human error” with no control named. CC7.5 expects the root cause of an incident to be determined. |
| Remediation evidence | The change ticket and approval, the deployment record, and the resulting configuration state — an infrastructure-as-code commit, a policy diff, a dated configuration export. | A ticket marked Done. The auditor tests the state of the system, so send what the configuration looks like after the change, with a date on it. |
| Proof the remediation was tested | An independent re-test after the fix — date, tester, method, result — and, where the control has run long enough, the auditor’s own sample across its operating period. | Self-attestation by the engineer who shipped the change. The most common gap, and the one that turns a manageable exception into an argument. |
| Communications record | Internal escalation records and any customer, regulator or law-enforcement communications, with dates and recipient categories. Recipient lists are routinely redacted; the fact and timing are not. | A draft notification with no send record. CC7.4 expects communication protocols to be implemented, which means executed. |
How many items, and where the numbers come from
The AICPA publishes no mandatory table of SOC 2 sample sizes. What exists is a convention tied to control frequency that most firms work from. Treat that as market practice, not a rule — the standards require a sample sufficient to reduce sampling risk to an acceptably low level, and firms differ on the numbers below by a couple of items either way.
| Control frequency | Typical sample (market practice) | What the auditor inspects | Most common rejection |
|---|---|---|---|
| Annual | 1 of 1 | The single execution with its date, owner and approval — the annual risk assessment, the penetration test report, the DR exercise record. | An artefact dated outside the period, or one with no evidence that anybody reviewed or approved it. |
| Quarterly | 2 of 4 | The completed record for each selected quarter, tied to a date that actually falls inside that quarter. | Two artefacts from the same quarter, or a quarter where the review was “carried forward” from the previous one. |
| Monthly | 2 to 5 of 12 | The dated output for each selected month, plus evidence that the reviewer acted on what it showed. | Twelve months of reports generated in one batch during fieldwork — the generation timestamps give it away. |
| Weekly | 5 to 8 of ~52 | System-generated output for the selected weeks, with the operator and the timestamp visible on the artefact. | Undated screenshots, or a selected week with no run and no explanation of why it was skipped. |
| Daily | 20 to 25 | Automated job logs, console records or scheduler history for each selected day. | Selecting business days only for a control that runs every day — the population has to match the control. |
| Many times daily / continuous | 25 to 40 | Individual instances — access grants, change tickets, alerts triaged — drawn across the whole period. | Selections clustered in one or two months, which fails the requirement that testing cover the period. |
| Event-driven (incident response) | Full population where small; otherwise a judgemental selection weighted to severity, always including any incident disclosed under DC4 | For each selected incident: the ticket, the originating alert, the severity assessment, the RCA and the closure record. | A population that cannot be reconciled to an independent source — that fails the test before sampling even starts. |
One procedural point worth planning around: where the auditor is sampling and cannot apply the designed procedure to a selected item, and no alternative procedure works, the standards direct that the item be treated as a deviation. An incident ticket you cannot evidence carries a cost — it counts against you. Separately, management’s written representations must cover known deficiencies in internal control, knowledge of actual or suspected fraud or noncompliance, and communications from regulators — including those received between the period end and the report date.
Writing the management response
Management’s response to an exception is customarily placed in Section 5, which is other information provided by the service organisation that the service auditor’s report does not cover. Nobody tested a word of it, which is exactly why buyers read it closely for tone. Four elements make it land. Acknowledge the deviation in the auditor’s own terms rather than restating it more favourably — a response that describes a different finding than Section 4 does is the first thing an experienced reviewer notices. Name the cause as a control rather than a person or a vendor. State the remediation with its effective date, because the date is what reviewers write down. And state whether the remediation has been independently tested, and by whom.
Three habits damage it: disputing the finding without producing the evidence that would settle it, asserting “no customer impact” without saying how that was established, and describing the fix in the future tense. A planned control is a plan.
Timing
The same incident, five different reports
Where an incident falls in the period changes what can be tested, which changes what the report says, which changes what a buyer concludes — while nothing about the incident itself changes. See choosing your observation period for how period length interacts with this.
| When in the period | What can still be tested | Likely sample size | What the report will say | How a buyer reads it |
|---|---|---|---|---|
| Month 1–3 of a 12-month period | The replacement control has eight or nine months of operation, so it can be tested as a control in its own right. | A full sample over the replacement’s own window — for a daily control, roughly 20 to 25 selections spread across it. | An exception scoped to a stated window, then a separate Section 4 line for the replacement control with no exceptions noted. | The strongest position available: a failure found early, fixed, then independently tested for most of the period. |
| Mid-period | Two populations for one control objective — the original control up to the failure, the replacement from its effective date. | Sizes prorated to each window. Market practice is to keep the replacement’s sample at roughly half the annual convention rather than a token one or two items. | Two rows in Section 4 with explicit effective dates, one of them carrying the deviation. | Normal and defensible to an experienced reader, provided the effective dates are stated plainly. |
| Final 30 days | Design and implementation of the replacement, and its effective date. Most firms want roughly 30 to 90 days of operating history before they will sample a replacement as a control in its own right. Label that as market practice; no standard sets a minimum operating window. | None for operating effectiveness. Inspection of the implemented configuration as of a single date. | An exception, and a management response describing a remediation this report does not test. | The weakest position. Expect follow-up questions from every enterprise reviewer, and expect the next report to be the real answer. |
| After period end, before the report is signed | Outside the tested period, inside the auditor’s subsequent-events procedures under AT-C 205, which require inquiry about events up to the report date that could significantly affect the subject matter. | No sampling. Inquiry, inspection of the incident record, and a written representation covering the interval. | Either nothing at all, or a disclosure the auditor requires where silence would mislead report users. | Entirely dependent on disclosure. Handled openly it is a footnote; discovered later by a customer, it is a credibility problem a clean opinion cannot repair. |
| Straddling the boundary — starts inside the period, continues after it | The in-period portion is tested normally. The post-period portion falls to subsequent-events procedures, and the description has to be written so a reader can tell the two halves apart. | Testing covers the in-period window; the auditor also inspects the post-period containment and remediation record to judge disposition. | A DC4 disclosure stating the incident’s status as at the description date, including where remediation was still in progress at period end. | Buyers read the disposition sentence first. “Open at period end, closed on [date], re-tested on [date]” answers it; “ongoing” generates a call. |
Which raises the obvious question: can you move the period so the incident falls outside it? The dates are printed on the front of the report, an abruptly shortened window invites the exact question you are avoiding, and DC 200 contemplates disclosing an incident that occurred before the period began where it was not fully remediated during it. You cannot reliably outrun this with a calendar.
Edge cases
Where this gets contested
The straightforward cases resolve themselves. These are the ones that generate the calls.
The engagement is a Type 1
A Type 1 reports on the fairness of the description and the suitability of design of controls as of a specified date, so there is no operating-effectiveness conclusion for an incident to modify. Two exposures survive that. DC4 applies as of the description date, so an incident meeting the trigger still has to be disclosed. And where the incident shows that a control the description presents as implemented was absent on the as-of date, the description fails the description criteria — the more serious of the two, because it reaches the opinion through the description element rather than through any single control.
The incident happened before the period started
DC 200’s guidance works through exactly this: a breach six months before the period began, not fully remediated during the period, would likely need disclosure so users understand the risks faced. A pre-period incident fully closed pre-period generally does not. An open one follows you in.
You find it after the period, but it happened during it
This is new information about the period examined, and the standards treat it that way. If it shows a control did not operate when testing said it did, the period’s result changes however good the remediation looks now. Where this surfaces after issuance, the standards require the practitioner to respond to facts that, had they been known at the report date, may have changed the report.
The incident is genuinely after the period end
The auditor must inquire about events up to the report date and act where one is significant enough that non-disclosure would mislead users. If management declines, the standards contemplate the practitioner disclosing it in the report and modifying the opinion, or withdrawing. Concealment routes you to a worse report than the one you were trying to protect.
The incident falls in the bridge-letter gap
A bridge letter, or gap letter, is management’s own statement covering the interval between the period end and a current date. The CPA firm performs no procedures over it, so it carries no assurance — your signature is the only one on it. Asserting that there have been no material changes to the control environment while an incident sits inside that gap is the kind of representation that surfaces badly when the next report covers the same dates. The workable answer is to state the incident in the bridge letter with its remediation date, and let the next examination test the fix.
The incident was at a subservice organisation
Carve-out limits what is tested while your disclosure obligations continue. DC 200 says management should consider disclosing known incidents at a subservice organisation regardless of whether the carve-out or inclusive method is used — and expect to show the monitoring you performed over that provider.
It touched systems outside the described boundary
The tempting answer is that it is out of scope. DC 200 asks a harder question — whether the incident arose from controls shared across your systems, and whether segmentation would prevent the same thing inside the described system. Where shared controls are ineffective, disclosure becomes more likely. Redrawing the boundary afterwards reads exactly as it is.
A customer failed to operate a CUEC
Where the report assigns a complementary user entity control — customers configure SSO, revoke their own users — the description can state that achieving the criterion depends on that user entity control, and a DC4 disclosure can characterise the incident’s origin. The service auditor does not test CUECs and the report does not adjudicate one customer’s failure to operate one. Either way it leaves your own detection and response obligations untouched, because those apply whatever the incident’s origin.
The root-cause analysis is privileged
Common where counsel commissioned the forensics. The auditor still needs evidence about detection, containment, the failed control and remediation. The workable pattern is a separate non-privileged factual timeline and control-level findings produced for the examination, with privilege decisions taken by your counsel. TCSA does not advise on privilege; we assemble the non-privileged evidence set so the question does not stall fieldwork.
One theme runs through all of them: the standards are far more tolerant of a bad event than of a concealed one — which is why written representations, subsequent-events inquiry, and the practitioner’s option to modify or withdraw all exist.
Objection handling
What the buyer’s security team will ask
In roughly the order they arrive. None of these answers requires you to argue that the incident was unimportant, and each one ends in an artefact you can actually send.
“You had a breach. How is the opinion clean?”
Because the opinion answers a narrower question: whether the description is fairly presented and the described controls operated effectively to achieve the applicable criteria. CC7.2 to CC7.5 assume incidents occur — they require monitoring for anomalies, evaluating security events, executing a defined response programme, and recovery. A detected, contained, remediated incident is those criteria operating.
What to send: The report itself, restricted-use and under NDA, with the Section 3 disclosure and the Section 4 results for the detection and response controls flagged by page number.
“Then why is there an exception at all?”
Because a preventive control failed for a stated window, and deviations are reported with the extent of testing that found them — how many items were tested and the number and nature of the deviations. The exception is the report working. The better questions are which criteria it touched, what compensated, and whether the fix was independently tested.
What to send: The full Section 4 row — control, test performed, population, items tested, deviations — plus the management response and the replacement control’s own test result.
“Your exception is in access control, and our policy treats that as disqualifying.”
An exception is scoped to one control and one stated window; the domain heading above it is a filing convention in the report’s own layout. A policy that disqualifies on the heading disqualifies on where the auditor filed the row. Ask which criterion the reviewer is worried about — that question is answerable from the basis paragraph and the test results, and the answer usually shows the criterion was achieved through other controls or was remediated on a dated timeline.
What to send: The failed control’s row with its window, the criteria named in the basis-for-modification paragraph where the opinion was modified, the replacement control’s test result, and your access-review evidence for the quarters after the fix.
“We need a bridge letter covering the incident window.”
A bridge letter is management’s unaudited assertion about the interval between the period end and today; it carries no practitioner assurance, and it cannot cure an exception inside the period, because the period has already been reported on. What it can do is state that the control environment described in the report remains in place, list the changes since period end, and give the status of remediation with dates.
What to send: A bridge letter on your letterhead naming the report period, today’s date, changes since period end, and the remediation status with its effective date — described in the letter itself as unaudited.
“Will you commit to an out-of-cycle or shortened next period?”
Sometimes worth doing, and rarely the cheapest answer. A shortened period means a second full examination: fees, a fresh evidence pull for every control in scope, and sample sizes that shrink with the window, so the new report carries less tested evidence per control than the one you already have. In most cases the stronger response is an early remediation effective date on the current cycle plus a next period that starts the day after this one closed, so the replacement control accumulates a full window of operating history. Where a contract genuinely requires an out-of-cycle report, price it before promising it.
What to send: Your next period’s start and end dates in writing, the remediation effective date, and — where you offer one — an interim scope agreed with the CPA firm.
“Our procurement policy bars vendors with a reportable incident in the last 12 months.”
A policy written that way excludes every vendor that detects and reports, and retains the ones whose monitoring is quiet because it is weak. Say that once, then reframe to the question the policy is trying to answer: were the applicable criteria achieved, and is the cause closed. Offer the independently tested remediation as the decision input, and ask whether there is an exception route that takes evidence — most policies have one, and it usually runs through the security team rather than procurement.
What to send: A one-page dated summary — incident class, detection control, containment interval, root-cause control, remediation effective date, and the CPA firm’s test result over the replacement window — plus the report under NDA.
“The incident was in the press and your report does not mention it.”
Worth checking rather than deflecting. First the dates: an incident outside the period may legitimately sit outside the description. If it falls inside, public knowledge of a system incident is one of the indicators DC 200 gives for disclosure being likely — so silence in Section 3 is a fair question, and one a vendor should answer in a sentence.
What to send: The period dates from the front of the report, the Section 3 disclosure where the incident falls inside them, and a dated one-paragraph statement where it falls outside.
“Send us the forensic report.”
Usually unavailable, and rarely the artefact that answers the question. What can be shared under NDA is the factual timeline, the control that failed, the remediation and its effective date, and evidence that the remediation was independently tested. That answers the real question — is it recurring, and is it fixed — without distributing an exploitation roadmap.
What to send: The factual timeline, the failed control, the remediation with its effective date, and the independent test result. Nothing naming hosts, keys, detection-rule logic or exploit paths.
Communication
How to brief customers
Lead with the period and the opinion, then point to the page — Section 3 for the disclosure, Section 4 for the control and its test result. Give four facts in order (what happened, how it was detected, how it was contained, what changed and when it took effect), name the independent testing, and say plainly that you are withholding exploitation detail because the description criteria direct you to.
Illustrative customer statement — the worked example, written out
Our SOC 2 Type 2 covers 1 January to 31 December 2026 and the opinion is unmodified. Section 3 discloses one incident. On 14 April 2026 our monitoring flagged anomalous API calls using a data-pipeline service-account credential; on-call acknowledged within twelve minutes and the credential was disabled and sessions revoked within forty minutes. Investigation found the credential had been exposed in a public repository on 28 March because automated secret scanning had been switched off for that repository during a migration. Activity was limited to listing objects in a non-production bucket; no production or customer data was accessed. Scanning was re-enabled across all 214 repositories with a blocking pre-commit hook effective 24 April 2026, and pipeline service accounts moved to one-hour federated credentials. The CPA firm tested the replacement control from 24 April to 31 December and noted no exceptions. Section 4 carries the exception for 12 March to 24 April.
Every sentence there is checkable against the report. That is the whole trick — a reviewer who can verify four facts stops asking for a fifth.
| Asking party | What they actually need | What you send | What you never send |
|---|---|---|---|
| Customer security review | Whether detection worked and whether the cause is closed. | The report under NDA with Section 3 and the relevant Section 4 rows flagged, the remediation effective date, and the CPA firm’s test result on the replacement control. | Forensic reports, detection-rule logic, hostnames, key material, raw logs. |
| Procurement / vendor risk | A defensible file entry: dates, opinion, status. | A one-page dated incident summary and the report’s cover page showing the period and the opinion. | Undated reassurance in email. It gets quoted back a year later, without the context. |
| Legal / contracts | Whether contractual notification obligations were met, and on what clock. | The notification record — who was told, when, and the category of recipient — with the contract clause it answers. | Recipient lists, and any characterisation of legal exposure. That is counsel’s call. |
| Regulator / supervisory authority | Statutory content on a statutory clock. | Whatever the applicable regime prescribes, filed through counsel. | A SOC 2 report offered as a substitute for a statutory notification. Different audience, different trigger. |
The clocks that run in parallel
Statutory and contractual breach notification is a separate obligation with its own audiences and deadlines. Under GDPR Article 33 a controller notifies the supervisory authority of a personal data breach within 72 hours of becoming aware of it where feasible, and a processor notifies the controller without undue delay. US state breach-notification statutes each set their own trigger, content and deadline, and they apply by the residence of the affected individuals rather than by where your company sits. For US-listed registrants, Item 1.05 of Form 8-K requires disclosure of a cybersecurity incident determined to be material, generally within four business days of that determination. India’s DPDP Act 2023 requires a Data Fiduciary to intimate the Data Protection Board and each affected Data Principal of a personal data breach.
None of these is discharged by a DC4 disclosure, and a DC4 disclosure is not discharged by any of them — different audience, different trigger, different clock. Tranquility Cybersecurity gives no legal advice on any of them; the point here is only that the SOC 2 disclosure sits alongside these obligations rather than inside them. If the incident is still open while a deal is live, give a dated status rather than reassurance — the same discipline described in what to tell customers while a SOC 2 is in progress. Keep the report restricted-use and under NDA; SOC 3 is the publishable version.
Where TCSA sits in this. Preparing for an examination and issuing the opinion are separate jobs. Tranquility Cybersecurity does readiness and implementation, builds the evidence set, drafts and stress-tests the system description, and coordinates the examination with independent licensed CPA firms — the opinion always comes from the CPA firm, which audits, attests and signs. When an incident lands mid-period the work is time-critical: reconstruct a defensible timeline from system records, map the failure to a specific control and criterion, get remediation to an effective date early enough to be testable, and prepare the DC4 disclosure before fieldwork rather than during it. Scoping an examination? Our SOC 2 audit preparation overview covers the sequence; engagements are quoted as a fixed fee from $4,000 for early-stage startups, after scoping, with the CPA firm’s attestation fee billed separately.
Incidents and SOC 2 — Common Questions
What an incident does and does not do to your report, and what the auditor will ask for.
Does a security incident automatically qualify a SOC 2 opinion?
No. The opinion addresses whether the description is fairly presented and whether the described controls were suitably designed and operated effectively to achieve the applicable Trust Services Criteria over the period. Criteria CC7.2 through CC7.5 presuppose that incidents occur — they require monitoring for anomalies, evaluating security events, executing a defined incident-response programme, and recovery. An incident your controls detected, contained and remediated is evidence those criteria were achieved. A modification follows only where the auditor concludes a criterion was not achieved, or the description was not fairly presented.
Do we have to disclose the incident in the SOC 2 report?
If it meets the DC4 trigger, yes. Criterion DC4 in DC section 200 requires disclosure of identified system incidents that resulted from controls that were not suitably designed or operating effectively, or that otherwise caused a significant failure to achieve service commitments and system requirements — specifically the nature of the incident, its timing, and its extent or effect and disposition. Your internal severity rating is not the test, and customer-data impact is an indicator informing the judgement rather than the trigger itself. Where nothing meets the threshold, management may state that fact explicitly.
What is the difference between an exception and a qualified opinion?
An exception, or deviation, is a finding in the test of one control: for some items in the tested population the control did not operate as described. A qualified opinion is a conclusion about the whole examination — that except for specified matters, the description is fairly presented and controls operated effectively. Reports routinely carry exceptions under an unmodified opinion. The bridge between them is the auditor’s evaluation of severity, the criteria affected, whether other controls compensated, and whether deviations aggregate into a failure to achieve a criterion.
We are doing a Type 1 — does the incident still matter?
Yes, though the exposure is different. A Type 1 opines on the fairness of the description and the suitability of design of controls as of a specified date, so there is no operating-effectiveness conclusion for an incident to modify. Description criterion DC4 still applies as of the description date, so an incident meeting the trigger still has to be disclosed. The sharper risk is implementation: if the incident shows that a control the description presents as implemented was absent on the as-of date, the description fails the description criteria — and that reaches the opinion through the description element rather than through any single control.
Should we shorten or move the observation period to exclude the incident?
It rarely works. The period dates appear on the front of the report, so an abruptly shortened or shifted window invites exactly the question you are trying to avoid. The description criteria also contemplate disclosing an incident that occurred before the period began where it was not fully remediated during the period, so moving the boundary does not necessarily move the disclosure. A shorter period also carries less tested evidence, which shortens the report’s commercial shelf life independently.
What evidence will the CPA firm ask for after an incident?
Expect a population-first request: a system-generated export of every incident in the period, plus a second source such as SIEM alerts or on-call records so completeness can be corroborated. Then, per selected incident — the ticket with system timestamps, the alert and its routing record, the severity assessment against your published matrix, a dated root-cause analysis naming the control that failed, remediation evidence showing changed state rather than intent, proof the remediation was tested independently, and the communications record.
Our incident happened in the last month of the period. What now?
You are in the hardest timing case. Market practice is that firms want roughly 30 to 90 days of operating history before they will sample a replacement control as a control in its own right, so the report will likely show an exception with a design-level fix and no independent operating evidence behind it. Two things help: get the remediation to a documented effective date immediately, so the next period starts with the control already running; and prepare the DC4 disclosure and management response carefully, because for this period they are doing more work than usual.
The incident was at a subservice organisation. Does it affect our report?
Potentially, in two ways. On disclosure, DC 200 guidance says management should consider disclosing known incidents at a subservice organisation regardless of whether the carve-out or inclusive method is used — carve-out limits testing while your disclosure obligations continue. On controls, your own vendor-monitoring controls are in scope, so the auditor will examine how you learned of the incident, how quickly, and what you did. Under the inclusive method the provider’s controls are tested directly.
We found the incident after the period ended. Is it still in scope?
That depends on when it happened, rather than when you found it. If it occurred during the period, discovering it later is new information about the period under examination, and the auditor will reassess the affected controls and test results. If it occurred after the period end, it falls within subsequent-events procedures: AT-C section 205 requires the practitioner to inquire about events up to the report date that could significantly affect the subject matter, and to act where non-disclosure would mislead report users.
Can we tell customers the incident proves our controls worked?
Say something narrower and more defensible. Claim what the report supports: that the incident was detected by a specific monitoring control, escalated and contained within a stated time, that the root cause was a named control failure, and that the replacement control was tested by the CPA firm over its operating period with the stated result. Avoid framing an incident as a success story — reviewers hear that as spin. Facts with dates and independent testing behind them persuade on their own.
Related reading: SOC 2 opinions and exceptions, choosing your observation period, SOC 2 report anatomy, common SOC 2 pitfalls, subservice organizations, how long a report stays usable, the Trust Services Criteria, and the SOC 2 hub.
Written By Expert Auditors
Keep Exploring
Related Reading
SOC 2 Opinions & Exceptions
Unmodified, qualified, adverse, disclaimer — and why exceptions are not qualification.
Read moreSOC 2 Observation Period: 3, 6 or 12 Months?
No AICPA minimum. Why short windows leave low-frequency controls untested.
Read moreSOC 2 and Penetration Testing
No criterion mandates a pen test — your own control description does. Timing, scope and what gets rejected.
Read moreSOC 2 Common Pitfalls
The ten predictable mistakes that stall first examinations — and the fixes.
Read moreSOC 2 Knowledge Hub
Type 1 vs Type 2, criteria, timelines and audit prep — all guides.
Read moreHow to Read a SOC 2 Report
All five sections annotated, an 8-step reviewer checklist, and the red flags.
Read moreGet in touch
Book a free consultation or send us your requirements. We respond within 24 hours.
Quick Call
Pick a time slot
Send Requirements
Get a custom quote in 24 hours