Intrusion Detection Requirements for SOC 2 Compliance

One of the most common questions we get at Agency is whether SOC 2 actually requires intrusion detection — and like many SOC 2 questions, the answer depends on understanding the difference between what the Trust Service Criteria technically say and what auditors practically expect. Here is what we have learned from guiding dozens of companies through this exact question.

SOC 2's Trust Service Criteria address intrusion detection through several criteria related to system monitoring, threat identification, and incident response. Unlike prescriptive frameworks that specify particular technologies, SOC 2 uses principles-based language that describes what your controls should achieve without dictating how to achieve it. This gives organizations flexibility in implementation but also creates ambiguity about what auditors expect. In practice, what we see across our client base is that intrusion detection capability — in some form — is expected by virtually every SOC 2 auditor, and the companies that approach it strategically build detection programs that satisfy auditors while providing genuine security visibility.

This guide maps the relevant Trust Service Criteria to intrusion detection, explains what auditors actually evaluate, provides implementation guidance including cloud-native tools, and details how to collect and present detection evidence for your SOC 2 audit.

Relevant Trust Service Criteria

Primary Criteria Related to Intrusion Detection

Criterion	Full Language	Connection to Intrusion Detection
CC6.6	The entity implements logical access security measures against threats from sources outside its system boundaries	Intrusion detection at system boundaries identifies unauthorized access attempts, malicious traffic, and exploitation attempts from external threat actors
CC6.8	The entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software	Intrusion detection identifies malware delivery attempts, command-and-control communication, and malicious code execution
CC7.1	To meet its objectives, the entity uses detection and monitoring procedures to identify changes to configurations that result in the introduction of new vulnerabilities, and susceptibilities to newly discovered vulnerabilities	Intrusion detection identifies exploitation of both known and newly discovered vulnerabilities; detection monitoring is a core component of this criterion
CC7.2	The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives	This is the most directly relevant criterion — it explicitly requires monitoring for anomalies indicative of malicious activity, which is the definition of intrusion detection

Supporting Criteria

Criterion	Connection to Intrusion Detection
CC7.3	The entity evaluates security events to determine whether they could or have resulted in a failure of the entity to meet its objectives (security incidents) and, if so, takes actions to prevent or address such failures — detection events trigger the evaluation process described in this criterion
CC7.4	The entity responds to identified security incidents by executing a defined incident response program — intrusion detection findings are the primary input that activates incident response
CC3.2	The entity identifies risks to the achievement of its objectives across the entity and analyzes risks as a basis for determining how risks should be managed — intrusion detection data feeds into risk assessment by providing empirical evidence of threats targeting the organization
CC4.1	The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning — detection capabilities are among the controls that should be periodically evaluated for effectiveness

How Auditors Map Detection to Criteria

What we tell clients is that auditors do not look for a single "intrusion detection" checkbox. Instead, they evaluate your detection capabilities across multiple criteria. A well-implemented detection program provides evidence for CC6.6, CC6.8, CC7.1, and CC7.2 simultaneously, while a poorly implemented one may fail to adequately address any of them.

Auditor Question	Criterion Being Evaluated	What Good Evidence Looks Like
How do you detect unauthorized access attempts at your system boundary?	CC6.6	Network monitoring logs showing detection of blocked and alerted external threats; firewall and IDS/IPS alert records
How do you detect malicious software in your environment?	CC6.8	Endpoint detection alerts, malware scanning results, and evidence of blocked malware delivery attempts
How do you monitor for new vulnerabilities being exploited?	CC7.1	Detection rules configured for known CVE exploitation patterns; threat intelligence feeds integrated with detection tools
How do you identify anomalous activity that may indicate a security incident?	CC7.2	SIEM correlation rules, behavioral anomaly detection, alert review records, and incident investigation examples

What Auditors Expect

Minimum Expectations vs Best Practices

Area	Minimum Auditor Expectation	What We Recommend	Why We Recommend More
Detection coverage	Some form of monitoring for systems within the SOC 2 scope	Detection capability covering all production systems, network boundaries, and critical internal services	Partial coverage creates gaps that auditors may question and that threat actors will exploit
Alert review	Evidence that detection alerts are reviewed periodically	Defined SLAs for alert review (critical: 1 hour, high: 4 hours, medium: 24 hours, low: 72 hours) with evidence of adherence	Undefined review timelines lead to alert fatigue and missed incidents; SLAs demonstrate operational maturity
Incident escalation	Documented process for escalating detected threats	Alert routing to specific teams with automated escalation when review SLAs are not met	Manual escalation processes break down under real-world conditions; automation ensures consistency
Detection testing	Not always explicitly required	Annual testing of detection rules through simulated attacks or purple team exercises	Untested detection creates false confidence; auditors increasingly ask whether detection has been validated
Log retention	Logs retained for the observation period at minimum	12-month minimum retention for security logs; longer for forensic-relevant data	Short retention makes incident investigation impossible and limits the evidence available during audits

Common Audit Findings Related to Detection

In our experience, these are the intrusion detection-related findings we see most frequently in SOC 2 audits.

Finding	Frequency	Impact	How to Prevent
No evidence of alert review	Very common	Exception or qualified finding for CC7.2	Implement documented alert review process with timestamped evidence of review activities
Detection does not cover all in-scope systems	Common	Exception for CC7.1 or CC7.2	Map detection coverage to the SOC 2 system boundary; ensure every in-scope system has appropriate monitoring
No documented incident escalation path from detection alerts	Common	Observation for CC7.3/CC7.4	Define and document the path from detection alert to incident response activation
Detection rules have not been updated during the observation period	Moderately common	Observation for CC7.1	Establish a quarterly detection rule review and update process
No evidence that detection capability has been tested	Increasingly common	Observation for CC4.1	Conduct annual detection testing — simulate attacks and verify alerts fire correctly

IDS/IPS Implementation Guidance

Cloud-Native Detection Tools

For cloud-native organizations — which represent the majority of our SOC 2 client base — cloud provider detection tools provide the fastest path to compliance.

AWS

Service	What It Detects	SOC 2 Relevance	Cost Model
AWS GuardDuty	Malicious activity and unauthorized behavior across AWS accounts; analyzes CloudTrail, VPC Flow Logs, and DNS logs	Addresses CC6.6, CC7.1, CC7.2 — detects unauthorized access, reconnaissance, credential compromise, and data exfiltration patterns	Per-million events analyzed; typical cost $100-$1,000/month for most environments
AWS CloudTrail	API activity logging across all AWS services	Foundation for CC7.1, CC7.2 — provides the log data that detection tools analyze	Free for management events; data event logging at $0.10 per 100,000 events
AWS Security Hub	Aggregates findings from GuardDuty, Inspector, Macie, and partner tools; provides compliance scoring	Centralized view for CC7.2 evidence; demonstrates aggregated detection capability	$0.0010 per finding check per month
Amazon Inspector	Automated vulnerability assessment for EC2 instances and container images	Supports CC7.1 — identifies vulnerability exposure in running workloads	Per-instance and per-image pricing; typically $500-$3,000/month
AWS WAF	Web application firewall with rule-based and managed rule set detection	Addresses CC6.6 — detects and blocks web application attacks at the boundary	$5 per web ACL + $1 per rule + $0.60 per million requests

Azure

Service	What It Detects	SOC 2 Relevance	Cost Model
Microsoft Defender for Cloud	Threat detection across Azure resources; container security; vulnerability assessment	Addresses CC6.6, CC6.8, CC7.1, CC7.2 — comprehensive cloud workload protection	Free tier available; enhanced features at $15/server/month and per-resource pricing
Azure Sentinel	Cloud-native SIEM with AI-powered threat detection, hunting, and automated response	Addresses CC7.1, CC7.2 — centralized detection with correlation across data sources	Per-GB ingestion pricing; typically $2,000-$20,000/month depending on log volume
Azure Network Watcher	Network monitoring, diagnostics, and flow logging	Supports CC6.6, CC7.2 — provides network-level visibility for detection	Per-check pricing for monitoring; flow log storage costs apply
Microsoft Defender for Endpoint	Endpoint detection and response for servers and workstations	Addresses CC6.8, CC7.2 — host-level threat detection and response	Included with certain Microsoft 365 plans; standalone at $5.20/device/month

GCP

Service	What It Detects	SOC 2 Relevance	Cost Model
Security Command Center (SCC)	Threat detection, vulnerability identification, and security posture management across GCP	Addresses CC6.6, CC7.1, CC7.2 — centralized security findings and threat detection	Standard tier free; Premium tier pricing varies by organization size
Chronicle Security	Cloud-native SIEM for threat detection, investigation, and response	Addresses CC7.1, CC7.2 — centralized log analysis and correlation with Google threat intelligence	Annual subscription pricing based on data volume
VPC Flow Logs	Network traffic metadata logging for VPC networks	Supports CC6.6, CC7.2 — provides network-level visibility	Per-GB pricing for generated logs
Cloud Armor	DDoS protection and web application firewall	Addresses CC6.6 — boundary protection with detection and blocking	Per-policy and per-request pricing

Multi-Cloud and Hybrid Environments

For companies operating across multiple cloud providers or hybrid environments, centralized detection is critical. What we recommend is selecting a SIEM or detection platform that can ingest data from all sources and provide a unified view.

Approach	Tools	Best For	Estimated Annual Cost
Cloud-native tools per provider + centralized SIEM	GuardDuty + Defender + SCC feeding into Datadog Security or Elastic Security	Multi-cloud organizations with security engineering resources	$40,000-$120,000 depending on scale
Managed detection and response (MDR)	Arctic Wolf, Expel, or Red Canary covering all environments	Organizations without dedicated security operations	$50,000-$200,000 depending on scope
Open-source SIEM with cloud integrations	Wazuh as the centralized platform with cloud provider log integrations	Budget-conscious organizations with security engineering capability	$15,000-$50,000 (primarily infrastructure and labor costs)

SIEM Integration

Why SIEM Matters for SOC 2

In our experience, auditors increasingly expect some form of centralized log analysis and correlation — a SIEM or SIEM-equivalent tool. Individual detection tools generate alerts in isolation, but a SIEM provides the correlation and aggregation that demonstrates mature detection capability.

SIEM Capability	SOC 2 Evidence Value
Log aggregation from multiple sources	Demonstrates comprehensive monitoring coverage across the system boundary (CC7.2)
Correlation rules that identify multi-step attacks	Shows sophisticated detection capability beyond simple signature matching (CC7.1)
Alert dashboards and reporting	Provides visual evidence of monitoring activity for auditors (CC7.2)
Incident timelines	Demonstrates the investigation workflow from detection to resolution (CC7.3, CC7.4)
Retention and search	Enables evidence retrieval for any point during the observation period (supports all criteria)

SIEM Options by Company Size

Company Size	Recommended SIEM Approach	Expected Cost	Why
Early-stage startup (10-25 employees)	Cloud-native tools with built-in alerting (GuardDuty + CloudWatch Alarms)	$2,000-$8,000/year	Minimizes cost and operational overhead while satisfying basic detection requirements
Growth-stage (25-100 employees)	Cloud-native tools feeding into a lightweight SIEM (Datadog Security, Panther, or Elastic Cloud)	$15,000-$40,000/year	Provides correlation and centralized alerting without requiring dedicated security operations headcount
Mid-market (100-500 employees)	Full SIEM deployment (Splunk Cloud, Elastic Security, or Sentinel) with defined detection engineering process	$40,000-$120,000/year	Scale requires centralized detection; dedicated detection rules and investigation workflows
Enterprise (500+ employees)	Enterprise SIEM with dedicated security operations team or MDR service	$100,000-$300,000+/year	Complex environments require extensive detection coverage, 24/7 monitoring, and rapid response capability

Evidence Collection for Audits

Building an Evidence Package

What we recommend is preparing the intrusion detection evidence package well before the audit fieldwork begins. Here is the evidence we help clients compile.

Evidence Item	Description	How to Collect	Typical Format
Detection architecture diagram	Visual representation of where detection capabilities are deployed relative to the system boundary	Create or update during detection implementation; review quarterly	Network diagram with detection sensors highlighted; Lucidchart, draw.io, or similar
Detection tool configuration	Screenshots or exports showing enabled detection services, configured rules, and alert routing	Export from detection tool admin console	Screenshots with timestamps; configuration export files
Alert review records	Evidence that alerts were reviewed within defined timeframes throughout the observation period	Ticketing system exports (Jira, ServiceNow, PagerDuty) showing alert triage and resolution	Filtered ticket exports showing detection-related tickets with timestamps
Incident records triggered by detection	Evidence that detection alerts led to incident investigation and response	Incident management records linked to detection alerts	Incident reports with timeline showing detection as the initiating event
Detection metrics dashboard	Summary of detection activity over the observation period — alert volumes, response times, false positive rates	SIEM dashboard export or custom report	Dashboard screenshot or PDF export covering the observation period
Detection rule update records	Evidence that detection rules were reviewed and updated during the observation period	Change management records for detection rule modifications	Change tickets or version control logs for detection rule changes
Detection testing evidence	Records of detection capability testing (simulated attacks, purple team exercises)	Test plan and results documentation	Test report showing scenarios tested, expected results, and actual results

Evidence Presentation Tips

In our experience, how you present detection evidence matters almost as much as the evidence itself. Auditors are evaluating large volumes of evidence across many controls, and well-organized evidence accelerates the review process and reduces follow-up questions.

Tip	Why It Matters
Map each evidence item to specific Trust Service Criteria	Helps the auditor understand how the evidence satisfies the criterion without having to make the connection themselves
Include timestamps in all evidence	Demonstrates that the evidence falls within the observation period
Show the full lifecycle: detection to response	Evidence that shows an alert being generated, reviewed, escalated, investigated, and resolved is far more compelling than evidence of alert configuration alone
Prepare a detection coverage summary	A one-page summary showing which systems are covered by which detection tools prevents the auditor from questioning whether coverage gaps exist
Include at least one incident example	Walking the auditor through a real (even minor) incident from detection to resolution demonstrates the entire process is operational

Key Takeaways

• In our experience, SOC 2 criteria CC6.6, CC6.8, CC7.1, and CC7.2 collectively create a strong expectation for intrusion detection capability — while no single criterion uses the phrase "intrusion detection system," auditors consistently expect detection controls as evidence for these criteria
• What we tell clients is that the most frequent detection-related audit finding is not missing tools but missing evidence of alert review — deploying detection is necessary but demonstrating that alerts are reviewed and acted upon within defined timeframes is what auditors actually evaluate
• We recommend cloud-native detection tools (AWS GuardDuty, Azure Defender, GCP Security Command Center) as the foundation for cloud-native SOC 2 environments — these tools provide the fastest path to detection capability with the lowest operational overhead, and auditors accept them as appropriate detection controls
• In our experience, companies pursuing SOC 2 should implement centralized log aggregation even if they do not deploy a full SIEM — the ability to search, correlate, and present logs from across the system boundary is increasingly expected by auditors and is essential for incident investigation
• What we recommend is preparing intrusion detection evidence as a complete package mapped to specific Trust Service Criteria, including architecture diagrams, alert configuration, alert review records, incident examples, and detection metrics — this structured approach reduces auditor follow-up questions significantly
• In our experience, detection coverage must align precisely with the SOC 2 system boundary — systems within scope that lack detection monitoring create audit exceptions, while spending on detection for out-of-scope systems provides no compliance value
• We help clients select the right detection tools for their cloud environment, configure alerts that generate auditor-ready evidence, build operational alert review processes, and compile evidence packages that satisfy SOC 2 auditors across CC6.6, CC6.8, CC7.1, and CC7.2