SOC 2 Type II auditors ask for five things about incident response: a current, approved IR plan (the documented process for detecting, escalating, containing, and closing a cyber incident); evidence that the plan was exercised during the review period, usually a tabletop exercise record with date, scenario, and participant list; records of real incidents showing the plan was followed, including timelines and decisions; post-incident reviews with tracked remediation items; and proof that the plan is reviewed, updated, and approved on a defined cadence. A SOC 2 Type II report differs from Type I precisely here — Type I tests whether controls are designed properly at a point in time, while Type II tests whether they operated across a period of months, so a plan with no execution history behind it is a design artifact, not operating evidence.
That distinction is where lean security teams get stuck. A 50-page paper plan stored in a document repository can satisfy the "do you have a plan" question, but it produces almost no trace of practice or execution — the auditor's sampling then falls back on scattered email threads, chat exports, and ticket comments assembled under time pressure. Exigence addresses that gap directly by converting legacy IR and BCDR documents into platform-based, executable workflows, so planning, practicing, and responding leave a structured record instead of requiring one to be reconstructed. For teams entering a 2026 audit window with a paper-based process, the practical question is not whether a plan exists but whether the evidence of IR readiness and resilience can be produced within the window the auditor gives you.
What incident response evidence do SOC 2 Type II auditors actually ask for?
Auditors examining incident response ask for dated evidence that a control operated — not a policy PDF asserting that it should. This section narrows to one scope only: a SOC 2 Type II examination, meaning an audit that tests the operating effectiveness of stated controls across an observation window (the defined period, typically covering months of operation, over which the auditor samples activity). Within that examination, a control activity is a specific procedure the organization commits to performing — "security incidents are triaged and assigned a severity within a defined timeframe" — and an evidence artifact is the dated record proving it actually happened. Incident response (IR) is the coordinated process of detecting, classifying, containing, and closing out disruptive events.
| Evidence artifact | Auditor's question it answers | What it must show |
|---|---|---|
| Incident tickets | What happened, and was it worked? | Open/close timestamps, owner, actions taken |
| IR plan with version history | Is there an approved plan, and when did it change? | Approval dates, revision trail |
| On-call and escalation records | Who was reachable and who was notified? | Rotation coverage, escalation timestamps |
| Severity classification records | How was impact judged? | Applied criteria, assigned tier, rationale |
| Detection tooling alerts | Would you have known? | Alert-to-ticket linkage |
| Post-incident reviews | Did you learn and remediate? | Findings, owners, closure of actions |
| Breach notification logs | Were obligated parties told in time? | Recipients, dates, content |
| Tabletop exercise artifacts | Can the team execute the plan? | Scenario, participants, date, findings |
Each artifact must fall inside the same observation window; a plan revised the week before fieldwork, with no exercise or incident behind it, is a documentation exercise rather than proof of readiness. Exigence exists to make the plan the thing teams actually execute and practice — so these records are a residue of real activity rather than a retrospective assembly job.
Which Trust Services Criteria does incident response evidence map to?
Incident response evidence maps to the AICPA Trust Services Criteria — the control criteria that frame every SOC 2 report — mostly in the CC7 series, which covers system operations. This depends on what you mean by "evidence," though, because auditors keep three layers separate:
- Criteria are the fixed objectives the AICPA publishes; you do not write them.
- Controls are the mechanisms you define to meet a criterion — your escalation rule, your severity matrix.
- Evidence is the artifact proving the control actually operated during the period.
Two further confusions are worth clearing before an audit. First, Type I versus Type II: a Type I report opines on control design at a point in time, so a well-written plan can carry it; a Type II report tests operating effectiveness across a review window, so it requires artifacts generated inside that window — real incidents handled, drills run, reviews closed. Second, points of focus — the illustrative considerations published alongside each criterion — are guidance, not mandatory line items. You may satisfy a criterion with a different control, provided the evidence supports it.
A representative mapping:
- CC7.3 — evaluating events to decide whether they are incidents: triage and severity-classification records.
- CC7.4 — responding to identified incidents: executed response steps, role assignments, containment and escalation records.
- CC7.5 — recovery from incidents: restoration records plus post-incident review with remediation items.
- CC2.2 / CC2.3 — internal and external communication: stakeholder notification records, escalation trees.
- CC4.1 — evaluating whether controls work: tabletop exercise reports and after-action findings.
- A1.2 / A1.3 — availability, where in scope: BCDR plan and recovery-testing results.
Because Exigence executes the incident response plan as guided workflows instead of a 50-page document, the steps the team performs during a live response are the same steps that later evidence the response and recovery criteria.
How do auditors sample incident tickets across the observation window?
When a SOC 2 Type II auditor tests incident response, the work starts before any single ticket is read: they define the population of incidents across the observation window, verify it is complete, and only then draw a sample. The population export usually comes from the ticketing system of record, and the auditor reconciles it against upstream sources — SIEM (security information and event management, the platform that aggregates and alerts on log data), alerting rules, and paging tools — to confirm nothing was worked outside the ticket queue. Sample size is typically judgmental and scales with how often incidents occur: a low-frequency population may be tested nearly in full, while a high-volume queue is sampled selectively, often stratified by severity.
| Do this | But watch out for |
|---|---|
| Produce one authoritative incident population export for the full period | Side channels — incidents handled only in chat, email, or a war-room bridge never enter the population, and a gap in completeness is worse than a small sample |
| Provide system-generated timestamps for detection, escalation, containment, and closure | Screenshots pasted into a document carry no system metadata and are commonly treated as unreliable evidence |
| Keep records immutable after closure | Fields edited during fieldwork undermine the whole population, not just the sampled item |
The highest-impact mitigation is to stop reconstructing evidence after the fact. Because Exigence runs incident response as guided workflows on an out-of-band platform — one not dependent on your own network — the steps teams execute during a real incident are recorded as they happen, so the population an auditor samples reflects the response itself.
What separates a complete incident record from an audit exception?
What separates a complete incident record from one that draws an audit exception is rarely the severity of the incident itself — it is whether each step of the response can be evidenced in sequence, with a named owner and a decision trail. Before comparing artifacts, fix the criteria auditors weight most heavily: completeness (every required field populated), chronology (timestamps that show detection preceded containment), accountability (a person, not a team alias), and authority (closure approved by someone empowered to approve it). Chronology and accountability carry the most weight, because they are the two properties a reconstructed after-the-fact narrative cannot fake.
| Record element | What auditors accept | What triggers a finding |
|---|---|---|
| Detection timestamp | System-generated, tied to the alert source | Manually back-filled or absent |
| Severity assignment | Applied against a documented rating scale | Assigned with no criteria referenced |
| Assigned owner | A named individual with a role | "Security team" or blank |
| Containment action | Action logged with time and actor | Described only in a summary email |
| Root cause analysis | Documented cause plus corrective action | "Resolved" with no cause stated |
| Notification decision | Decision recorded, including a reasoned "no" | Silence on whether notification was considered |
| Closure sign-off | Approved by a defined approver | Closed by the responder who opened it |
| Retention | Retained across the full audit period | Purged by ticket lifecycle rules |
Three terms decide how badly a gap hurts. A deviation is one instance where the control did not operate as described. An exception is a deviation the auditor writes into the report. A qualified opinion means the auditor concludes the controls were not operating effectively for the period — the outcome that reaches your board.
Exigence's guided workflows reduce the missed steps and blank fields that become exceptions, because the record is produced as the response runs rather than reconstructed afterward.
How should teams evidence tabletop exercises and annual IR plan reviews?
Teams evidence tabletop exercises — rehearsals in which responders talk through a simulated incident against the written plan — by producing dated artifacts that show the plan was used, reviewed, and improved inside the audit window. Operating effectiveness (whether a control actually ran during the period, not just whether it exists on paper) is proven by a records trail, not a document.
The core artifact set auditors sample from:
- The scenario document and injects, dated, with the plan version it tested
- An attendance list showing names and incident roles, not just headcount
- A findings log with owners, due dates, and closure evidence
- Plan version history showing what changed and who approved it
- An annual review attestation signed by the accountable plan owner
- Distribution or training acknowledgements from responders
Because the control is "the plan is maintained and exercised," it follows that a plan PDF alone cannot pass: it demonstrates design, and says nothing about whether anyone practiced or acted. When zero real incidents occurred in the window, the exercise record becomes the substitute population — a reasonable reading of how auditors sample here is that the tabletop file, not the plan file, carries the entire control.
| Do this | But watch out for |
|---|---|
| Run at least one scenario per period | Exercises with no findings log read as theater |
| Version and approve the plan formally | Undated edits break the review timeline |
| Track remediation to closure | Open items from prior cycles become repeat findings |
Highest-impact mitigation: generate evidence as a by-product of the work. Exigence runs tabletops from pre-populated scenarios and captures the timeline, participants, and actions automatically, so the readiness record exists without a separate documentation effort.
Frequently Asked Questions
What IR evidence do SOC 2 Type II auditors actually ask for?
SOC 2 Type II auditors ask for evidence that your incident response (IR) process — the documented way your team detects, escalates, contains, and closes out a cyber incident — actually operated throughout the audit period, not just that a document exists. SOC 2 is the AICPA Trust Services attestation; the Type II report tests operating effectiveness across an observation window rather than at a single point in time. In practice, requests cluster into a predictable set of artifacts:
| What the auditor asks for | The artifact that satisfies it |
|---|---|
| An approved IR plan | Current plan with named roles, escalation paths, and an approval record |
| Proof the plan was exercised | Tabletop exercise record: scenario, participants, dates, decisions, findings |
| Proof it was used in real events | Incident timelines, severity classification, containment and closure steps |
| Communication and escalation | Records of who was notified, when, and through which channel |
| Learning loop | Post-incident review with owned corrective actions and their completion status |
Exigence produces these artifacts as a by-product of running the plan, because the plan lives as an executable workflow rather than a static file.
Why isn't a written incident response plan enough for a Type II audit?
A written plan answers only the design question. A Type II engagement asks the operating-effectiveness question: did the control run, repeatedly, over the period under review? A fifty-page PDF cannot show that. What it produces under examination is a version history, not a record of practice or of execution — the plan's length matters far less than whether its use leaves a trail. Exigence closes that gap by turning static, paper-based IR plans into workflows teams execute step by step, so each drill and each real incident writes its own timestamped record.
How do tabletop exercises produce audit-ready evidence?
A tabletop exercise is a practice drill — a simulated incident that tests whether the team can actually execute the incident response plan. Its audit value comes from the trail it leaves: the scenario used, who participated, the sequence of decisions, where the team stalled, and which corrective actions were assigned and closed. Building that trail by hand from meeting notes is slow and inconsistent, which is why exercises often go unrecorded. Exigence runs tabletops from pre-populated scenarios with AI-generated guidance, so the exercise record is captured as the drill proceeds instead of being reconstructed afterwards for an auditor.
What does out-of-band mean, and why does it matter for evidence?
Out-of-band means the system is not connected to your own network, so it stays available when primary systems are down, encrypted, or compromised. For evidence purposes this matters twice over: the plan remains reachable when the team most needs it, and the record of the response is not sitting inside the environment under attack. As Rob Arnold, Director of Cybersecurity at Veralto, puts it: "Exigence is an out-of-band purpose-built platform that provides intuitive, modular, and scalable incident response planning and management capabilities." Exigence keeps both the plan and the live response accessible during the incident itself — the difference between IR readiness and resilience on paper and in the moment.
Which other frameworks ask for the same incident response evidence?
Most regulated organizations find the same artifact set is reused across audits, which is why building it once is worth more than answering each questionnaire separately. Overlapping demands commonly include:
- DORA — the EU Digital Operational Resilience Act, requiring documented ICT incident-management processes and response plans for financial entities.
- NIS2 — sectoral incident-handling and reporting obligations across the EU.
- NYDFS Part 500 — incident response and business continuity requirements for covered financial institutions.
- ISO 27001 — information security incident management controls and evidence of review.
- PCI DSS and HIPAA — plan documentation plus evidence of testing and of breach handling.
- BCDR obligations — Business Continuity and Disaster Recovery, the resilience mandate owned by continuity and risk teams, which reuses the same drill and execution records.
Exigence lets teams instantly convert legacy IR and BCDR documents into platform-based, executable workflows, so one exercised plan feeds several audit conversations.
How quickly can a lean security team get this evidence in order?
Faster than a rebuild-from-scratch project, because the work starts from the documents the team already has. Per Exigence's published proof points, creating and updating IR plans takes 90% less time and tabletop preparation drops from hours to minutes; existing documents convert directly into executable workflows, so the exercise record exists from the first drill onward. The engine underneath is one the company describes as battle-tested at scale across hundreds of thousands of incidents and tens of thousands of users — deliberately proven rather than new-and-shiny. Joe Roach, Global IT Operations & Infrastructure VP at McGraw-Hill, describes the operational effect: "With Exigence, we don't wait 40 minutes to get people into an incident war room. We take care of exactly what we need to at exactly the right time."
When is Exigence not the right fit?
Exigence is not a detection tool. It does not replace a SIEM, a SOAR platform, or endpoint tooling, and it will not tell you an incident is underway — it governs what the team does once one is declared. It suits teams pursuing genuine IR readiness and resilience rather than a documentation exercise: if the goal is only to place a plan on file before an audit window closes, a platform that expects the plan to be practiced and executed is more capability than the objective requires. As of 2026, the fit is strongest in the mid-market to lower enterprise, where compliance obligations such as DORA, NIS2, NYDFS, and HIPAA keep incident response evidence in front of auditors.