An empty incident list is a claim

A lesson from SOC 2 Type 2: What the Auditor Tests. Play it above, or read it through below.

• An empty list is a disclosure, and the auditor tests it 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". The criterion has two triggering conditions, and an incident is in scope if it meets EITHER one.

  An automated renewal that stopped producing certificates is a control that was not operating effectively, so the outage it caused is 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 presentations get wrong: the implementation guidance says that if there have been no significant incidents that require disclosure, management may disclose that fact.

  So an empty list is permitted, and the question 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 that nothing they produced met either triggering condition. For each incident that does meet a condition, the criterion asks for its nature, the timing surrounding it, and its extent or effect and disposition. A short period does not lower the standard for the zero.

  For example, the auditor requests the pager history, the ticket queue and the status-page record, and the team's answer covers only three weeks, because the retention period is three weeks. The entity cannot support the zero, so the finding is against the description, and the auditor will likely say so in its opinion on the description. Raising the retention to cover the period is one configuration change and one invoice line.

• The auditor tests four records behind the list, not the list itself.

  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 requests to test a zero, then read on.

  They are the declaration criteria, the detection layer, the adjacent populations, and the entity's written definition of a security event or incident. The first has to pre-date the period: severity tiers plus the named owner authorised to declare and escalate, and these make "incident" a dated decision rather than a word applied in hindsight. Most programmes have the least evidence for the second: 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, four sets, each with an emitter and a date field. Reconciliation runs from those records into the report: matching each listed incident to its pager fire proves nothing about the ones missing. A missing entry means the description misstates the period. A pager fire above the declaring threshold that nobody declared also means the declaration control did not operate, a separate deviation.

  The fourth is the entity's written definition of a security event or incident, a disclosure DC 200 says the description may need; the other three get measured against it. Two separate evaluations cover the same events: the incident-response programme is tested for operating effectiveness under CC7.4, and the disclosure is graded under DC4, a description criterion, not a common criterion. A team that has cleared CC7.4 reads a DC4 question as a repeat and answers with the tabletop minutes, and the auditor sends a second evidence request.

• Every breach is an incident. Not every 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 occurred 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.

  The answer is none, and all three. DC 200 defines a system incident as an event that needed action from management to prevent or reduce its effect on the service commitments and system requirements, and counts an attempted unauthorised access as an event. Management declared and closed all three, so all three are system incidents. A breach is the narrower set in which personal data was disclosed, accessed, lost, altered or destroyed, and only a breach starts a statutory notification clock.

  DC4's noun is system incidents, and its two conditions decide which of them the description has to disclose. Whether an event is a breach decides who has to be told and by when; it decides nothing about what the description says. Treating the two as one is correct everywhere else in this job, because everywhere else the question that follows an alert is whether customer data was exposed, and the answer decides every later step. Here the answer decides the notification, not the disclosure.

  An operator who writes "no incidents" meaning "no breaches" has made a claim about a set they never enumerated. For example, a security questionnaire answer 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 blames 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.

• Significance is measured against the number you published.

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

  The description that states a number owes a disclosure. The second condition reads "a significant failure in the achievement of one or more of those service commitments and system requirements". "Those" means the service organization's own commitments: the ones in its contracts, SLAs and published policies. DC2 requires the description to disclose the principal ones, such as an availability number most customers get. "Significant" stays in the condition, so the rule is not "any month over your number". It is "a significant miss of a number you committed to".

  For an availability miss, significance is measured against that number. Disclosure stays a judgment, and the guidance lists other factors, such as fines. A 31-day month holds 44,640 minutes; 99.9% of it tolerates 44.64; one sixty-eight-minute outage uses 1.5 times that allowance and puts the month at 99.848%, which is not a rounding question. The same outage at an organization with no availability commitment anywhere does not meet condition (b). So the standard is a document the team wrote, and tightening it creates 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 because of a pricing decision. Publishing no number does not avoid the problem: DC2's guidance says that when an organization makes the same availability commitment to most of its customers, management would likely disclose it in the description.

  For example, an auditor asks about one month's uptime record, the question goes to the engineering team because they own uptime, and they close it by adding an alert. No control failed: every control the description states operated as designed. The error is in the description: it publishes a number that one month missed and discloses no incident for that month, so the auditor will likely say so in its opinion on the description. Reconcile every published availability number against the last four windows, then change the number or the platform.

• The intrusion started in July, and this period's description likely discloses it.

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

  The description likely discloses the intrusion. The DC4 implementation guidance covers this case: a breach that caused a failure to achieve one or more service commitments and system requirements, 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. Inside 2026-01-01 to 2026-06-30 there was an unremediated exposure and remediation work on it, which is what the criterion's third attribute asks for: extent or effect and disposition, one attribute covering both.

  An incident is not removed from a description because it started earlier than the period. The same guidance adds two qualifications to that rule. "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 what the disclosure contains, and the attack path, the exact record counts and the indicator list are not. A description that reads like an internal retrospective has replaced one defect with another: it has published the details an attacker needs.

  For example, eight months later somebody reading only the current report writes a customer questionnaire answer: no incidents disclosed, so none occurred. Nothing is filed, because nothing failed and nobody disagreed. The record that would have answered the question 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.

• Fix the records behind the list, not the wording of the list.

  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 earliest date any zero in a description can cover. "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 producing alerts the whole time, and that nothing met 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 an unsupported list is not better wording. The fix 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 reads 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 missing entry found early needs only a process change. For example, a customer asks how the zero was verified, and the person who wrote the sentence answers rather than the person who owns the pager. An empty list is the easiest paragraph in the report to write and the hardest claim in it to support. The record that supports the disclosure is built in the same quarter as everything else the team ships.