A quiet year still needs incident response evidence in a SOC 2 Type 2. Show a current plan with assigned roles, an exercise that tests it, proof that alerts and security events were reviewed and triaged, and records of how you decided that nothing met the definition of an incident. An empty incident log with no supporting detail invites questions.
What do the criteria ask for?
Three criteria cover this ground. CC7.3 says the entity evaluates security events to determine whether they could have or did result in a failure to meet its objectives, which the criteria call security incidents, and takes actions to prevent or address such failures. CC7.4 says the entity responds to identified incidents by executing a defined incident response programme to understand, contain, remediate and communicate. CC7.5 covers activities to recover from identified incidents.
A Type 2 report covers a period and includes tests of operating effectiveness. The auditor cannot test response to an incident that never happened, so they test what did happen: the way you detected, evaluated and handled events, and whether the programme is ready.
What does the AICPA point to?
The points of focus under CC7.3 include procedures for responding to incidents and evaluating their effectiveness periodically, communicating detected events to those responsible for the security programme and acting on them, and procedures to analyse incidents and determine system impact. Under CC7.4 they include assigned roles and responsibilities, procedures to contain and resolve incidents, restoring operations, communication protocols, and periodic evaluation of the effectiveness of response activities.
In short, a programme that exists on paper, has owners, is evaluated and is exercised.
Which evidence works when there were no incidents?
The plan. A written incident response plan with severity definitions, roles, contact routes, containment steps, communication rules and a review date. Keep version history showing the annual review.
The exercise. A tabletop or simulation during the period, with a scenario, attendees, decisions, gaps found and actions closed. This is the strongest evidence that the programme works.
The triage record. Alerts and security events that were reviewed. A ticket queue with timestamps, severity decisions and outcomes, including false positives, shows that evaluation happens. If you use monitoring tools, export alert history and a sample of triage notes.
Near misses and minor events. A phishing report from an employee, a blocked login attempt campaign, a vulnerability in an internet facing system. For each: how you evaluated it, why it was or was not classed as an incident and what you changed.
Periodic review. Minutes of a monthly or quarterly review where someone responsible for security looks at events and trends. CC7.4 asks management to review incidents and identify needed changes, and an honest review of "no incidents, three near misses" counts.
Test of tools. Evidence that detection and alerting work: a synthetic alert test, an on call page test or a log pipeline check.
Contact readiness. Current contact lists for responders, legal, key vendors and any customers with notification duties, with dates of last verification.
How do you word the "nothing happened" statement?
Say what is true. For example: "No events met our definition of a security incident during the period. The security team reviewed N alerts and M reports; these were closed as benign or low severity with the attached notes." Provide the data behind it. Avoid claiming that nothing happened if you do not monitor well enough to know.
What mistakes cause trouble?
- An alert queue that nobody reads, producing an empty log for the wrong reason.
- A plan that names people who left.
- Tabletop exercises that never produce action items.
- Classifying everything as a non incident without a written definition.
- No record of how the plan is communicated to staff.
- Incident tools set up in month ten, leaving most of the period without evidence.
What to do
- Review and re-approve the plan, and confirm named roles are current.
- Write severity definitions and a one paragraph definition of a security incident.
- Schedule a tabletop in the first half of the period and record decisions and actions.
- Route all alerts and reports into one ticket queue with severity and outcome fields.
- Hold a monthly review of events and near misses, and keep minutes.
- Test an alert path quarterly and keep the result.
- Prepare a clear period summary with numbers for the auditor.
Quick check
Will an auditor accept an empty incident log?
Often only with supporting evidence: the plan, an exercise, records that events were monitored and triaged and a review showing how you decided nothing qualified. The log alone says little.
Do we need a real incident to pass?
No. The criteria test whether your programme is defined, assigned, exercised and evaluated. A tested programme with no incidents can pass.
Sources
- AICPA, 2017 Trust Services Criteria with revised points of focus (2022): CC7.3, CC7.4, CC7.5 and the Type 2 definition.
How Safeguard helps automate this
Quiet periods are when evidence goes missing, because nobody thinks about it. Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code instead of screenshots, and monitoring runs between audits. Technical evidence comes from your real code and dependencies: scans, SBOMs and reachability, which feed the vulnerability side of event triage. The remediation agent can open tested fix pull requests for vulnerable dependencies. It is off by default, every category starts on Manual, and you choose which categories run automatically and at what approval level. Safeguard helps you prepare and keep evidence ready; your independent auditor tests it. Book a call.
Last reviewed: 18 October 2026.
