Controls5 May 2026 7 min read

SOC 2 Security Monitoring: SIEM, Alerts, and Evidence

Build a SOC 2-compliant security monitoring program. Learn SIEM options, what to alert on, how to document alert review, and the CC7.2 evidence auditors expect.

Key Takeaways

CC7.2 requires the entity to monitor the system to detect anomalies and potential threats.
A SIEM (Datadog, Splunk, Sumo Logic) or SIEM-equivalent aggregates logs and provides correlation and alerting.
Alerts must be actionable, assigned, and documented — not just emailed and ignored.
For AWS-centric companies, Security Hub + GuardDuty + CloudWatch provides SIEM-like capabilities without a dedicated SIEM.
Monthly security review meetings with documented minutes satisfy the CC4.2 deficiency reporting requirement.

In this guide

Security Monitoring and SOC 2 CC7.2
What to Log and Where
SIEM Options for SaaS Companies
What to Alert On
Alert Review and Documentation
Security Monitoring Evidence

Security Monitoring and SOC 2 CC7.2

CC7.2 requires the entity to monitor system components and the operation of those controls on an ongoing basis to detect anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives.

The key word is "ongoing" — one-time checks or annual reviews don't satisfy CC7.2. Monitoring must be continuous, and the output (alerts, reports, findings) must be reviewed by a human who can take action. The challenge is building a monitoring program that produces actionable signal without overwhelming alert fatigue.

What to Log and Where

A comprehensive CC7.2 monitoring program covers multiple log sources: Infrastructure layer (CloudTrail API calls, VPC Flow Logs, AWS Config changes), Platform layer (container runtime logs, Kubernetes audit logs, ECS task logs), Application layer (application error logs, authentication events, data access events), and Endpoint layer (EDR telemetry, MDM events).

Centralize logs in a single platform for correlation — AWS CloudWatch Logs, Datadog, Splunk, or Sumo Logic. Log correlation is what separates a SIEM from a collection of individual log sources. A SIEM can correlate an authentication failure in CloudTrail with an unusual API call five minutes later and trigger a single alert, reducing investigation time.

SIEM Options for SaaS Companies

AWS Security Hub: native AWS tool that aggregates findings from GuardDuty, Config, Inspector, Macie, and third-party integrations. Not a full SIEM but provides a centralized security findings console. Suitable as a starting point for small teams.

Datadog Security Monitoring: cloud-native SIEM that integrates with CloudTrail, application logs, and 400+ integrations. Detection rules written in SQL-like query language. Good for teams already using Datadog for APM and infrastructure monitoring.

Splunk Cloud: enterprise-grade SIEM with the most mature detection rule ecosystem. High cost but highest capability. Suitable for larger SaaS companies with dedicated security teams.

Sumo Logic Cloud SIEM: mid-market option with good AWS integration and pre-built SOC 2 detection content. Cloud Security Operations Center (CSOC) add-on provides managed detection.

What to Alert On

High-priority alerts (immediate response required): Root AWS account login, IAM policy change on a privileged role, GuardDuty HIGH severity finding, public S3 bucket detected, production security group opened to 0.0.0.0/0, failed MFA attempts exceeding threshold, CloudTrail disabled or logging paused.

Medium-priority alerts (review within 24 hours): User accessing production systems outside business hours for the first time, large data export (S3 GetObject on >10,000 objects), new IAM access key created, EC2 instance launched in an unexpected region, application error rate spike >50%.

Low-priority items (weekly review): Access key age >60 days, MFA not enrolled for new user account after 7 days, vulnerability scan findings summary, software dependency CVE notification.

Alert Review and Documentation

Alerts must be reviewed and actioned to satisfy CC7.2. Configure your alerting to create a ticket in Jira or your ITSM for every High priority alert. Require that each ticket is assigned, investigated, and closed with a resolution note. The ticket history is your CC7.2 evidence.

Hold a monthly security review meeting: review all Medium and Low alerts from the month, review open vulnerability findings, review access review results, and update the risk register if new risks are identified. Keep meeting minutes. This meeting is your CC4.2 deficiency reporting evidence — it demonstrates that monitoring findings are escalated to management.

Review your alert rules annually and tune them: suppress false positives, add new rules for emerging threats, and retire rules that no longer apply. Document the rule review.

Security Monitoring Evidence

(1) SIEM or monitoring tool configuration showing enabled log sources and detection rules. (2) Alert routing configuration showing High priority alerts go to Jira or ticketing. (3) Sample alert tickets from the audit period showing investigation and resolution. (4) Monthly security review meeting minutes from the audit period. (5) AWS Security Hub findings dashboard screenshot. (6) Alert rule tuning records showing annual review of detection rules.

Frequently Asked Questions

Do we need a dedicated SIEM tool for SOC 2, or can we use AWS-native tools?

AWS-native tools (Security Hub, GuardDuty, CloudWatch, Config) provide strong coverage for CC7.2 and may be sufficient for small teams. A dedicated SIEM adds correlation across non-AWS sources (endpoints, SaaS applications, network devices) and is expected in larger or more mature environments. Start with AWS-native tools and add a SIEM as the team grows.

How do we evidence that we are actually reviewing alerts, not just receiving them?

The best evidence is a ticketing trail: each alert creates a ticket, the ticket is assigned, updated with investigation notes, and closed with a resolution. Monthly security review meeting minutes that reference specific alert categories also demonstrate review. Auditors are skeptical of "we check Slack" as the primary evidence of alert review.

What is alert fatigue, and how does it affect SOC 2 compliance?

Alert fatigue occurs when a security team receives so many alerts that they stop investigating each one carefully, leading to missed genuine threats. For SOC 2, alert fatigue is a CC7.2 risk — if alerts are ignored because there are too many, the monitoring control is not operating effectively. Tune your rules aggressively to reduce false positives and ensure every alert that fires can be actioned.

Should we enable all available detection rules in our SIEM from day one?

No. Start with a small set of high-fidelity rules covering the most critical threat scenarios. Add rules incrementally, tuning each one to minimize false positives before enabling the next. A SIEM with 200 enabled rules generating 1000 daily alerts is less effective than one with 20 rules generating 10 actionable alerts daily.

How do we handle after-hours alerts when the team is small?

Define an on-call rotation using PagerDuty or Opsgenie. Configure only High-severity alerts to page the on-call engineer. Medium and Low alerts should route to a queue reviewed the next business day. Document the on-call policy in your incident response plan — auditors want to see that High severity events can be responded to 24/7.