Incident Response Plan for SOC 2

What this control should accomplish

When a security or availability incident occurs, the team can quickly declare it, assign leadership, coordinate containment and recovery, preserve important facts, and make communication decisions through a known process.

How to implement Incident Response Plan

1. 1

   Define when to declare an incident

   Give responders plain examples and a clear route for declaring suspected security, privacy, availability, or customer-impacting incidents without waiting for perfect certainty.

   You should end up with: Incident declaration and severity guide

2. 2

   Assign roles and authority

   Name primary and backup incident commanders, technical leads, communications owners, record keepers, and legal or privacy contacts, including the decisions each may make.

   You should end up with: Current incident role and authority roster

3. 3

   Document the response flow

   Create usable steps for intake, classification, escalation, containment, evidence preservation, investigation, recovery validation, communication, and closure.

   You should end up with: Approved incident response plan and quick checklist

4. 4

   Prepare resilient communications

   Document primary and alternate contact methods, secure collaboration locations, executive escalation, and how the team will work if ordinary identity or messaging is unavailable.

   You should end up with: Incident contact and out-of-band communication plan

5. 5

   Preserve the decision record

   Use a consistent incident record for timestamps, facts, hypotheses, actions, approvals, customer impact, evidence links, and unresolved questions.

   You should end up with: Incident record format and evidence location

6. 6

   Exercise and improve the plan

   Run a realistic scenario, observe role handoffs and decisions, record gaps, update the plan, and verify high-risk corrective actions.

   You should end up with: Exercise report and closed improvement actions

Evidence to keep, and what it should prove

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.

Which records should you prepare for the audit?

How an auditor may test this control

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.

• Confirm the intended control outcome

  Determine whether the control is designed to achieve this result: When a security or availability incident occurs, the team can quickly declare it, assign leadership, coordinate containment and recovery, preserve important facts, and make communication decisions through a known process.

• Confirm ownership and operating cadence

  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.

• Establish the complete audit record set

  Reconcile the full-period incident register to declared incidents found in security cases, on-call records, service incidents, and customer-support escalation sources, and reconcile the exercise schedule to exercise records. For a zero-incident period, preserve the exact full-period queries, source coverage, zero-result exports, and management confirmation; an exercise demonstrates preparedness but is not an actual incident occurrence.

• Prepare the as-of-date evidence for a Type 1 engagement

  The current approved response plan, verified role and contact roster, severity and declaration paths, secure evidence location, and a recent exercise or actual incident record showing the process is usable at the review date.

• Prepare period evidence for a Type 2 engagement

  Every declared security, privacy, availability, or customer-impacting incident during the review period and every incident-response exercise due under the period-effective exercise schedule, including completed, cancelled, missed, and rescheduled exercises. If no incidents occurred, retain a full-period zero-result incident-register export, reconciled intake-source exports, and an attributable management confirmation rather than creating a fictional incident record.

• Inspect the policy / design artifacts

  Documents that define the control, its scope, ownership, and expected way of working.

  • Inspect Incident response plan

    For each selected record, confirm it demonstrates The company has an approved, current response process for declaration, command, escalation, containment, evidence preservation, investigation, recovery, communication, and closure.

    • Scope and effective version
    • Approver and date
    • Declaration route
    • Response phases
    • Communication paths
    • Evidence location

  • Inspect role assignments

    For each selected record, confirm it demonstrates Primary and backup responders are named by role, reachable, and authorized to make defined technical, executive, privacy, legal, and communication decisions.

    • Response role
    • Primary assignee
    • Backup assignee
    • Contact method
    • Decision authority
    • Last verified date

  • Inspect severity matrix

    For each selected record, confirm it demonstrates Responders use consistent business, customer, data, service, and technical factors to classify incidents and reach the appropriate escalation path.

    • Severity levels
    • Decision factors
    • Company-specific examples
    • Required escalation
    • Response owner
    • Effective version

• Inspect the approval / review evidence

  Records showing that an accountable person reviewed, approved, challenged, or accepted the work.

  • Inspect tabletop records

    For each selected record, confirm it demonstrates The response team practiced a defined scenario, exercised role and communication decisions, identified gaps, and assigned improvements.

    • Scenario and date
    • Participants and roles
    • Timeline or prompts
    • Decisions made
    • Findings
    • Actions and owners

• Trace the control from design to operation

  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.

Common implementation and evidence gaps

• The plan is generic and does not name the company's actual systems, contacts, or authority.
• Only one person can lead or access key response tools.
• The team has no safe communication path if ordinary identity or messaging is compromised.
• Responders take action but do not preserve timestamps, evidence, and decision rationale.
• An exercise identifies gaps that never receive owners or verification.

Before you call this control ready

• Can any employee find the declaration route and reach the current on-call contact?
• Do primary and backup leaders know which containment and communication decisions they may make?
• Could the team coordinate if its ordinary identity or messaging service were unavailable?
• Does the incident record capture facts, actions, approvals, impact, and evidence links?
• Can the latest exercise findings be traced to completed and verified improvements?

Trust Services Criteria references

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.

• CC7.3
• CC7.4
• CC7.5

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.

Related controls to review next