SOC 2 Security Incident Detection Process

Learn how to implement the SOC 2 Security Incident Detection process under CC7 using CrowdStrike, SentinelOne, and AWS GuardDuty.

SOC 2 Processes
SOC 2 Security Incident Detection Process

Overview

Security Incident Detection is the process of continuously monitoring systems and environments to identify potential security events and indicators of compromise. It ensures timely identification and escalation of incidents in alignment with SOC 2 CC7.2 and CC7.3 requirements.

Step-by-Step Process

  1. Define detection scope

    The Security Lead defines which systems, cloud accounts, endpoints, and networks are in scope for security monitoring. This includes production, staging, and critical third-party integrations. The output is a documented monitoring scope approved by security leadership.

    Role: Security Lead

  2. Configure detection tools

    The Security Lead or Security Engineer configures endpoint and cloud detection tools to monitor all in-scope assets. Default and custom detection policies are enabled based on organizational risk. The output is active detection coverage across defined systems.

    Role: Security Engineer

  3. Establish alert severity criteria

    The Security Lead defines severity levels (e.g., Low, Medium, High, Critical) and mapping criteria for alerts generated by detection tools. This ensures consistent triage and escalation. The output is a documented severity matrix.

    Role: Security Lead

  4. Monitor alerts continuously

    Security Analysts review alerts in detection tools on an ongoing basis, at minimum daily. Alerts are acknowledged, triaged, or escalated based on severity. The output is a reviewed and dispositioned alert queue.

    Role: Security Analyst

  5. Validate potential incidents

    Security Analysts investigate alerts to determine whether they represent true security incidents. Investigation includes reviewing logs, affected assets, and user activity. The output is a determination of true positive or false positive.

    Role: Security Analyst

  6. Escalate confirmed incidents

    Confirmed incidents meeting escalation criteria are reported to the Security Lead according to the incident response plan. Notifications include incident details, timestamps, and impacted systems. The output is a formally escalated incident record.

    Role: Security Analyst

  7. Document detection activities

    All alerts, investigations, and escalations are documented in the ticketing or incident management system. Documentation includes timestamps, actions taken, and responsible personnel. The output is an auditable incident detection log.

    Role: Security Analyst

  8. Review detection effectiveness

    The Security Lead periodically reviews alert trends and false positives to improve detection rules. Changes are approved and implemented as needed. The output is updated detection configurations and review notes.

    Role: Security Lead

What You Need Before Starting

  • Approved security monitoring scope document
  • Access to endpoint and cloud security tools
  • Incident response plan and escalation matrix
  • Defined severity classification criteria

Evidence Your Auditor Expects

  • CrowdStrike alert list screenshot showing alerts with timestamps from the last 90 days
  • Incident investigation tickets with creation and closure dates
  • Severity classification document with last reviewed date
  • Detection tool configuration export dated within the audit period

How This Looks In Your Tools

CrowdStrike

Log in to the CrowdStrike Falcon console and navigate to Activity > Detections to review active and historical alerts. Use filters to sort by severity, status, and date to identify high-risk detections.

To validate incidents, select a detection ID and review the Process Tree, Host Timeline, and Indicators of Attack. Document findings and disposition directly in the linked ticketing system or case notes.

SentinelOne

Log in to the SentinelOne Management Console and go to the Threats dashboard to view detected threats. Use the left-hand filters to sort by threat level, site, and mitigation status.

Click into a threat to review Storyline, affected endpoints, and remediation actions. Update the threat status and document investigation notes according to internal procedures.

AWS GuardDuty

Log in to the AWS Management Console and navigate to GuardDuty > Findings to view active and archived findings. Use filters to sort by severity, resource type, and finding age.

Select a finding to review details such as affected AWS resources, IP addresses, and timestamps. Export findings or link them to an incident ticket for further investigation and escalation.

Common Audit Findings

Alerts not reviewed timely
This occurs when monitoring responsibilities are unclear or understaffed. Prevent this by assigning daily alert review ownership and documenting review timestamps.
Incomplete monitoring scope
Some systems are excluded from detection due to poor asset tracking. Maintain an up-to-date asset inventory and review monitoring coverage quarterly.
Lack of documented investigations
Alerts are reviewed but not formally documented. Require ticket creation for all investigated alerts and periodically audit ticket completeness.
Severity criteria not consistently applied
Analysts apply subjective judgment without clear guidance. Use a documented severity matrix and train analysts on its use.

Related Processes

Key Roles

Security LeadSecurity EngineerSecurity Analyst