Incident Response
Incidents require containment, investigation, remediation, recovery validation, root-cause analysis, corrective actions, and post-incident review where appropriate.
Use this guide to put the control into operation, decide what records to retain, and check that an auditor can trace the evidence back to the work your team performed.
Maintained by GreenHat Security · Reviewed August 21, 2026
Incidents are contained without destroying important evidence, the service is recovered and validated, contributing causes are understood, and corrective work is tracked until it is demonstrably complete.
First SOC 2 program
Keep one incident timeline, record containment and recovery decisions, hold a blameless review for material incidents, and place every corrective action in the normal engineering tracker with an owner and due date.
As the company scales
Use scenario playbooks, forensic preservation, coordinated eradication and recovery gates, structured cause analysis, risk-ranked action governance, recurrence monitoring, and executive review of overdue work.
Open the incident record, capture the initial report and timestamps, protect relevant logs or system state, and document who has response authority.
You should end up with: Initial timeline and preserved evidence references
Balance urgency, customer impact, evidence needs, and reversibility when isolating identities, hosts, integrations, traffic, or data paths.
You should end up with: Containment decision and action log
Build the timeline, test hypotheses, determine affected scope, and identify technical, process, detection, and organizational conditions that allowed the event.
You should end up with: Supported cause and impact analysis
Remove or reduce the cause, restore service through an approved path, and verify security, data integrity, access, monitoring, and customer-facing behavior before closure.
You should end up with: Remediation and recovery validation record
Document what happened, what worked, what failed, lessons, remaining risk, and specific corrective actions without relying on memory alone.
You should end up with: Approved post-incident review
Assign owners, due dates, priority, completion proof, and verification for each action; escalate overdue or risk-accepted items.
You should end up with: Corrective-action tracker with verified closure
Build the evidence set in three layers: what defines the control, who approved or reviewed it, and what proves it operated. Collect operating records when the work happens so they remain dated, attributable, correctly scoped, and traceable to the underlying activity.
Before sharing, remove unrelated personal or customer data, never expose passwords, tokens, or secret values, preserve enough source context to authenticate the record, and use the secure exchange approved for the engagement.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
Confirm what the record proves
Material incidents receive a supported analysis of timeline, contributing technical and process conditions, lessons, remaining risk, and improvements.
Include this context
Incident and review date
Include this context
Participants
Include this context
Supported cause analysis
Include this context
Impact and timeline
Include this context
Lessons
Include this context
Corrective-action links
Weak evidence to avoid
A document naming human error as root cause without supporting evidence, contributing conditions, timeline, remaining risk, or tracked improvements.
Confirm what the record proves
An authorized owner confirmed containment, remediation, recovery validation, communication follow-up, evidence preservation, and residual-risk disposition before closure.
Include this context
Incident ID
Include this context
Closure criteria
Include this context
Open residual risk
Include this context
Approver
Include this context
Approval time
Include this context
Decision and exceptions
Weak evidence to avoid
A ticket automatically closed when service recovered without approval, recovery validation, remaining-action review, or residual-risk decision.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
Confirm what the record proves
Each declared incident has a stable, attributable timeline connecting known facts, impact, decisions, evidence, response actions, recovery, and closure.
Include this context
Incident ID
Include this context
Opened and closed times
Include this context
Commander and responders
Include this context
Affected scope
Include this context
Timeline and evidence links
Include this context
Final status
Weak evidence to avoid
A post-event summary with no incident ID, contemporaneous timeline, named decision-makers, evidence links, or clear closure state.
Confirm what the record proves
Responders recorded what they isolated, blocked, revoked, or changed, why that action was chosen, who authorized it, and its observed effect.
Include this context
Incident ID
Include this context
Action and target
Include this context
Decision time
Include this context
Actor or approver
Include this context
Reason and expected effect
Include this context
Observed result
Weak evidence to avoid
A note saying access was disabled with no affected identity, timestamp, actor, reason, scope, or validation of containment.
Confirm what the record proves
Post-incident improvements retain priority, owner, original due date, status history, completion proof, and verification.
Include this context
Incident and action ID
Include this context
Action and priority
Include this context
Owner
Include this context
Opened and due dates
Include this context
Status history
Include this context
Completion and verification
Weak evidence to avoid
A lessons list marked done without owners, original dates, linked engineering work, completion proof, or effectiveness verification.
Type 1
The current containment, evidence-preservation, recovery, post-incident, and closure process, active action tracker, and latest qualifying incident or exercise evidence showing the design is usable at the review date.
Type 2
Every declared incident in the full-period incident register, with containment, remediation, recovery, closure, and the documented decision on whether cause analysis or post-incident review applied; plus every containment, recovery, and post-incident tabletop or exercise due under the period-effective schedule, at least annually, including due, completed, cancelled, missed, and rescheduled occurrences. Preserve the original scheduled occurrence when an exercise moves and link it to the replacement date and final result. If no incidents occurred, retain the full-period zero-result register, reconciled declaration-source exports, and an attributable management confirmation; an exercise remains a separate preparedness occurrence, not an actual incident.
Reconcile all declared incidents from the incident register to security, on-call, service-impact, and support declaration sources, then verify each incident has response and closure records and an explicit cause-review decision. Separately reconcile every exercise due on the period-effective calendar to its attendance, results, findings, and corrective actions, retaining cancelled, missed, and rescheduled occurrences and linking each original date to any replacement. For a zero-incident period, retain exact full-period queries and zero-result exports plus management confirmation; do not count an exercise as an actual incident or omit it from the scheduled exercise population.
Use this checklist to prepare for procedures an auditor may perform. The exact steps and sample selection depend on your engagement scope and the service auditor's professional judgment.
Determine whether the control is designed to achieve this result: Incidents are contained without destroying important evidence, the service is recovered and validated, contributing causes are understood, and corrective work is tracked until it is demonstrably complete.
Compare the documented owner with the intended role (CISO / Incident Commander / Privacy-Legal Owner), then compare dated records with the stated cadence: Per event/incident; tabletop at least annually.
Reconcile all declared incidents from the incident register to security, on-call, service-impact, and support declaration sources, then verify each incident has response and closure records and an explicit cause-review decision. Separately reconcile every exercise due on the period-effective calendar to its attendance, results, findings, and corrective actions, retaining cancelled, missed, and rescheduled occurrences and linking each original date to any replacement. For a zero-incident period, retain exact full-period queries and zero-result exports plus management confirmation; do not count an exercise as an actual incident or omit it from the scheduled exercise population.
The current containment, evidence-preservation, recovery, post-incident, and closure process, active action tracker, and latest qualifying incident or exercise evidence showing the design is usable at the review date.
Every declared incident in the full-period incident register, with containment, remediation, recovery, closure, and the documented decision on whether cause analysis or post-incident review applied; plus every containment, recovery, and post-incident tabletop or exercise due under the period-effective schedule, at least annually, including due, completed, cancelled, missed, and rescheduled occurrences. Preserve the original scheduled occurrence when an exercise moves and link it to the replacement date and final result. If no incidents occurred, retain the full-period zero-result register, reconciled declaration-source exports, and an attributable management confirmation; an exercise remains a separate preparedness occurrence, not an actual incident.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
For each selected record, confirm it demonstrates Material incidents receive a supported analysis of timeline, contributing technical and process conditions, lessons, remaining risk, and improvements.
For each selected record, confirm it demonstrates An authorized owner confirmed containment, remediation, recovery validation, communication follow-up, evidence preservation, and residual-risk disposition before closure.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
For each selected record, confirm it demonstrates Each declared incident has a stable, attributable timeline connecting known facts, impact, decisions, evidence, response actions, recovery, and closure.
For each selected record, confirm it demonstrates Responders recorded what they isolated, blocked, revoked, or changed, why that action was chosen, who authorized it, and its observed effect.
For each selected record, confirm it demonstrates Post-incident improvements retain priority, owner, original due date, status history, completion proof, and verification.
Use the categories that apply to this control: connect any policy or design artifact to its approval or review record, then trace a selected operating record through execution, result, and any exception or remediation.
These identifiers help you navigate related Trust Services Criteria. They do not reproduce the criteria or prove that this control fully addresses them in your environment.
Confirm final scope, mappings, and testing expectations with your service auditor. SOC 2® is an AICPA trademark; GreenHat Security is not affiliated with or endorsed by AICPA.