SOC 2 Incident Response Process Process

Learn how to implement a SOC 2 Incident Response Process aligned with CC7.3 and CC7.4, including detection, response, evidence, and audits.

SOC 2 Processes
SOC 2 Incident Response Process Process

Overview

The Incident Response Process is the structured approach used to identify, respond to, contain, and remediate security and operational incidents affecting systems and data. It ensures incidents are handled consistently, escalated appropriately, and reviewed to meet SOC 2 CC7 monitoring and response requirements.

Step-by-Step Process

  1. Detect and report incident

    Any employee or automated monitoring tool identifies a potential security or availability incident and reports it immediately through the designated alerting channel. The Security Lead ensures reports are centralized in the incident management system. The output is a logged incident with an initial timestamp.

    Role: All Employees / Security Lead

  2. Triage and classify incident

    The Security Lead or on-call responder reviews the incident details to confirm whether it meets the incident definition and assigns a severity level based on impact and urgency. Classification includes incident type, affected systems, and potential data impact. The output is a severity-assigned incident record.

    Role: Security Lead

  3. Initiate incident response

    For confirmed incidents, the Security Lead activates the incident response plan and assigns responders based on severity. Communication channels and tracking tickets are established immediately. The output is an active incident with assigned owners.

    Role: Security Lead

  4. Contain and mitigate impact

    Assigned responders take actions to contain the incident, such as isolating systems, revoking access, or disabling services. All actions are documented in the incident record with timestamps. The output is reduced or eliminated ongoing impact.

    Role: Security Engineer

  5. Investigate root cause

    The response team analyzes logs, alerts, and system behavior to determine the root cause of the incident. Findings are documented, including contributing factors and detection gaps. The output is a documented root cause analysis.

    Role: Security Engineer

  6. Recover systems and services

    Systems are restored to normal operation following validation that threats have been removed. Recovery steps are verified and approved by the Security Lead. The output is restored services with documented recovery confirmation.

    Role: IT Operations

  7. Communicate and escalate as required

    The Security Lead communicates incident status to management and, if applicable, coordinates customer or regulatory notifications. All communications are logged for audit purposes. The output is a complete communication record.

    Role: Security Lead

  8. Perform post-incident review

    After closure, the Security Lead conducts a post-incident review to document lessons learned and required control improvements. Action items are tracked to completion. The output is a dated post-incident review report.

    Role: Security Lead

What You Need Before Starting

  • Approved Incident Response Policy
  • Access to incident management and alerting tools
  • System and application log access
  • On-call schedule and escalation matrix

Evidence Your Auditor Expects

  • Incident ticket with creation date, severity, and closure timestamp
  • PagerDuty alert log showing incident trigger time and acknowledgements
  • Post-incident review document dated and approved by Security Lead
  • Slack incident channel export with timestamps of key communications

How This Looks In Your Tools

PagerDuty

Log in to PagerDuty and navigate to Services > Select the affected service > Incidents. Review automatically generated incidents or create a new incident using New Incident, ensuring the title, urgency, and service are completed.

Acknowledge the incident from the Incidents view and assign responders using the Assign button. Use the Notes tab to document containment and mitigation actions with timestamps. Ensure the incident is resolved by selecting Resolve and entering resolution details before closure.

Jira

In Jira, navigate to Projects > Security or IT Operations project and select Create. Choose the Incident issue type, complete required fields including severity, affected systems, and reporter, then submit.

Use the issue workflow to move the ticket through Triage, In Progress, and Resolved statuses. Document investigation findings and root cause in the Description or Comments section, and attach supporting logs or screenshots before transitioning to Done.

Slack

Create a dedicated incident channel using Channels > Create Channel and name it according to the incident ID (e.g., incident-2026-001). Invite all responders and stakeholders immediately.

Use pinned messages to highlight incident summary, current status, and next steps. After resolution, export the channel conversation via Workspace Settings > Import/Export for evidence retention.

Common Audit Findings

Incidents not formally logged
This occurs when teams resolve issues informally without creating an incident record. Enforce mandatory incident logging and train staff to report all suspected incidents through approved tools.
Missing severity classification
Severity is often skipped during fast-moving incidents, reducing audit traceability. Use required fields in incident tools to prevent progression without severity assignment.
Incomplete post-incident reviews
Post-incident reviews may be delayed or undocumented due to resource constraints. Schedule reviews as a required closure step and track action items in Jira.
Lack of evidence for response timing
Auditors frequently see gaps in response timestamps. Ensure alerts, acknowledgements, and actions are time-stamped automatically in PagerDuty and retained.

Related Processes

Key Roles

All Employees / Security LeadSecurity LeadSecurity EngineerIT Operations