SOC 2 Compliance with a SIEM: Meeting the Trust Services Criteria

SOC 2 has become the de facto trust standard for SaaS and technology companies — and increasingly a prerequisite for closing enterprise deals. While SOC 2 covers far more than security monitoring, a SIEM is one of the most efficient ways to satisfy a cluster of its requirements and generate the evidence auditors demand. This guide explains exactly where a SIEM fits.

What SOC 2 Actually Is

SOC 2 (Service Organization Control 2) is an auditing framework developed by the AICPA. It assesses how well a service organisation protects customer data against five Trust Services Criteria: Security (the only mandatory one), Availability, Processing Integrity, Confidentiality, and Privacy. A SOC 2 report is the output of an independent auditor's examination.

There are two report types: Type I assesses whether controls are designed appropriately at a point in time; Type II assesses whether they operated effectively over a period (typically 3–12 months). Type II is the one customers really want — and it is where a SIEM proves its worth, because it generates continuous evidence over the observation period.

Where a SIEM Maps to the Trust Services Criteria

The Security criterion is built on the Common Criteria (CC series), several of which a SIEM directly supports:

The Evidence a SOC 2 Auditor Wants

For a Type II audit, the auditor is not asking "do you have a SIEM?" — they are asking "prove it has been operating effectively for the entire observation period". A SIEM produces exactly this kind of evidence:

• Continuous log collection records — demonstrating monitoring was active throughout the period, with no gaps
• Alert history — showing security events were detected and triaged
• Incident response records — linking alerts to the actions taken
• Access monitoring logs — evidencing who accessed what, supporting CC6
• Configuration of detection rules — showing monitoring is meaningful, not nominal

Retention and SOC 2

SOC 2 observation periods run 3–12 months, and auditors review evidence across the whole window. Your SIEM retention must comfortably exceed your audit period so the evidence is available when the auditor arrives. This makes affordable long retention a practical SOC 2 enabler — see our log retention guide for how to size this without runaway storage cost.

Why Self-Hosted Helps for SOC 2 — and Confidentiality

The Confidentiality criterion concerns protecting data designated as confidential. A self-hosted SIEM keeps your security telemetry — which itself contains sensitive access and configuration data — within your own environment rather than a third party's, simplifying your data-flow story for the auditor. It also gives you complete control over the evidence, with no dependency on a cloud vendor's availability or export capabilities during an audit.

Practical Steps Toward SOC 2 Readiness

1. Deploy your SIEM well before the observation window opens — you need it running continuously across the entire Type II period
2. Cover access and operations — prioritise identity, infrastructure, and application logs to hit CC6 and CC7
3. Document your monitoring controls — auditors want the policy as well as the evidence
4. Enable continuous reporting — so evidence accumulates automatically rather than being reconstructed
5. Set retention beyond your audit period — so nothing falls off before the auditor reviews it
6. Run incident response and keep records — even drills demonstrate the process operates