An empty incident list is a claim

A lesson from Surviving the SOC 2 Audit. Play it above, or read it through below.

• An empty list is a disclosure. It gets graded like one.

  The common read: Nothing got breached, so there is nothing to report.

  It does not hold, and the customer data is not why. DC4 covers identified system incidents that, verbatim, "(a) were the result of controls that were not suitably designed or operating effectively or (b) otherwise resulted in a significant failure in the achievement of one or more of those service commitments and system requirements". Two triggering conditions, and an incident reaches the criterion by clearing EITHER one.

  An automated renewal that stopped producing certificates is a control that was not operating effectively, so the outage it caused sits inside the first condition on its own. Harm to customer data is not a condition anywhere in that sentence. An empty list is not a violation either, which is the half most readiness decks have backwards: the implementation guidance says that if there have been no significant incidents that require disclosure, management may disclose that fact.

  So the empty list has a sanctioned form, and what changes is what it claims. "No identified system incidents" asserts that the entity's own detection and declaration criteria ran across the whole of 2026-01-01 to 2026-06-30 and produced zero results. For each incident that does clear a condition the criterion asks for its nature, the timing surrounding it, and its extent or effect and disposition. The zero gets no discount for being short.

  It arrives as an evidence request the team returns incomplete: the pager history, the ticket queue and the status-page record, and the answer covers three weeks of retention. The dead renewal is a control that was not operating, and how it tested is a separate question. What the entity cannot support is the zero, so the finding lands on the description, and the auditor will likely say so in the opinion on it. Raising the retention to cover the period is one configuration change and one invoice line.

• The list is not what gets tested. The four records behind it are.

  The common read: The incident list is the evidence, so the auditor tests the list I hand over and there is nothing behind it left to test.

  Name the four records an auditor pulls to test a zero, then read on.

  The declaration criteria, the detection layer, the adjacent populations, and the description's own definition of a security event. The first has to pre-date the period: severity tiers plus the named owner authorised to declare and escalate, which is what makes "incident" a dated decision rather than a word applied in hindsight. The second is where most programmes are thinnest: a compliance platform's incident tracker holds the record after you declare, and it does not detect and it does not declare.

  The third produces the findings. Pager fires at or above the declaring severity, tickets carrying the incident type, status-page entries, and months the error budget closed negative are four sets that already exist, each with an emitter and a date field. The reconciliation runs from those records into the report and never the other way: matching each listed incident to its pager fire proves the listed ones are real and nothing about the ones missing. A hole in the list is an evidence failure, not a control weakness.

  The fourth is the description's own definition of a security event, and the other three get measured against it. Two gradings run over the same events: the incident-response programme is tested for operating effectiveness under CC7.4, and the disclosure is graded as part of the description under DC4, a description criterion and not a common criterion. A team that has cleared CC7.4 reads a DC4 question as a repeat of it and answers with the tabletop minutes, which arrives as a second evidence request, filed against nobody.

• Every breach is an incident. Almost no incident is a breach.

  The common read: An incident is only an incident once data was exposed, so a period with no breach is a period with no incidents.

  Three events sat inside the period: malware quarantined before it extracted anything, a brute-force run that never established a session, and a storage bucket left readable that held no personal data. Say how many statutory notification clocks those three started, and how many of them DC4's noun covers, then read on.

  None, and all three. A period with no breach is not a period with no incidents. An incident is a confirmed or suspected policy violation, an unauthorised access attempt, or a system compromise. A breach is the narrower subset in which personal data was actually exposed, and it is that subset, not the wider one, that starts a statutory notification clock. All three were declared, timed and closed, and none of them started a clock.

  DC4's noun is incidents. The narrower word decides who has to be told and by when, it decides nothing about what the description says, and the two decisions get made by different people reading different records. The reflex that collapses them is correct everywhere else in this job, because everywhere else the question that follows an alert is whether customer data moved, and that question routes everything downstream of it, from the page to the lawyer. Here it routes the notification and leaves the disclosure question untouched.

  An operator who writes "no incidents" meaning "no breaches" has made a claim about a set they never enumerated. It arrives as a security questionnaire answer that contradicts the report the customer already holds: the questionnaire says one security incident, contained and closed, and the description covering the same period says none were identified. Procurement files it against the questionnaire, because the questionnaire is the newer document and somebody in sales owns it. Deciding which list an event goes on, at declaration time, costs one line in the runbook.

• You published the yardstick. The criterion measures against it.

  The common read: Significance is the auditor's judgement, so an outage this small is below anything the criterion would call a significant failure.

  Only the description that states a number. The second condition reads "a significant failure in the achievement of one or more of those service commitments and system requirements", and the word doing the work is "those": it points back at the commitments the description states under DC2, principal service commitments and system requirements. "Significant" stays in the condition and keeps working, so the rule is not "any month over your number", it is "a significant miss of the number you stated".

  That number is the only thing significance gets measured against. A 31-day month holds 44,640 minutes; 99.9% of it tolerates 44.64; one sixty-eight-minute outage spends that allowance 1.5 times over and lands the month at 99.848%, which is not a rounding question, though a month closing one second over would be. The same outage against a description carrying no availability number crosses nothing here. So the yardstick is a document the team wrote, and tightening it manufactures disclosures.

  In a 31-day month 99.95% tolerates 22.32 minutes and 99.5% tolerates 223.2, so the same sixty-eight minutes is 3.0 times the allowance under the tighter number and 0.30 of it under the looser one: two teams on identical infrastructure owe different disclosures over a pricing decision. Publishing nothing is not the escape: DC2 requires the principal service commitments and system requirements to be described, and the 2022 revised implementation guidance asks for MORE detail, noting that the practice of referring to descriptions published elsewhere is often insufficient.

  It arrives as an auditor's question about one month's uptime record, filed to the engineering team because uptime is theirs and closed by adding an alert. There is no control to write up: every control the description states operated as designed. What is wrong is the description: it publishes a number one month missed and discloses no incident for it, so the auditor will likely say so in the opinion on it. Reconcile every published availability number against the last four windows, then change the number or the platform.

• The intrusion started in July. The disclosure is this period's.

  The common read: The intrusion started before the period opened, so it belongs to whichever report covers the period it started in.

  It likely discloses it. The DC4 implementation guidance works this case directly: a breach that occurred six months before the period started and had not been fully remediated during the period is one management would likely need to disclose. The date the intrusion began is not the test. What sat inside 2026-01-01 to 2026-06-30 was an unremediated exposure and the work done against it, which is what the criterion's third attribute asks for: extent or effect and disposition, one attribute covering both.

  An incident does not fall out of a description by having started earlier than the period. Two calibrations come with that, both from the same guidance. "Likely" is the guidance's own word and it stays: this is management's disclosure decision against the criterion, and the auditor opines on the description management wrote. A disclosure is also not a post-mortem: disclosures are not intended to be made at a detailed level that might increase the likelihood that a hostile party could exploit a security vulnerability.

  So nature, timing, and extent or effect and disposition is the shape of it, and the attack path, the exact record counts and the indicator list are not. A description that reads like an internal retrospective has traded one defect for another, and it has published a map.

  It arrives as a customer questionnaire answer written eight months later by somebody reading only the current report: no incidents disclosed, so none occurred. Nothing is filed, because nothing failed and nobody disagreed. The record that would have settled it is a restoration ticket that exists and was never connected to a disclosure decision. Connecting the two is one query over open remediation items whose incident predates the period, run before the description is drafted rather than after a customer asks.

• The list is not the deliverable. The record behind it is.

  The common read: The incident disclosure is a writing task, so a thin list is fixed by wording the sentence more carefully.

  Put a date on the earliest incident record you could produce today, then read on. That date is the real left edge of every zero a description asserts. "No identified system incidents" claims that a declaring threshold was applied across the whole of 2026-01-01 to 2026-06-30, by somebody who owned the call, over a detection layer that was emitting the whole time, and that nothing cleared either triggering condition. Three of those four are records with date fields on them.

  The fourth is a sentence, and it is the only part most programmes can produce. So the fix for a thin list is not wording. It is three fields on the incident record, a declared_at, a declared_by and the threshold that was met, emitted by the tracker the team already runs, plus a scheduled job that walks the pager history for the period and prints every fire with no matching declaration. That job is short enough to write in an afternoon.

  Run it in month two of the period, not week two of fieldwork: a hole found early is a process change. It arrives as a customer asking how the zero was verified, answered by the person who wrote the sentence rather than the person who owns the pager. An empty list is the cheapest paragraph in the report and the most expensive claim in it. The record that makes the disclosure survivable gets built in the same quarter as everything else the team ships.