SOC 2 logging requirements: what auditors actually ask for

Search for “SOC 2 logging requirements” and you’ll find confident lists that don’t agree with each other. There’s a reason: SOC 2 doesn’t prescribe specific logs. It’s a criteria-based framework - the Trust Services Criteria describe outcomes like “the entity monitors system components for anomalies” and “logical access is restricted and monitored”, and it’s your auditor who decides what evidence demonstrates them. That flexibility is a feature for the framework and a trap for a small team: you can’t check off a list, and you find out what was expected when the evidence request lands.

What follows is the practical version: the host-level evidence auditors ask small companies for in practice, and how to be the team that exports it in an afternoon rather than the one reconstructing it from grep.

What the evidence requests look like in practice

Across the criteria that touch infrastructure (logical access and system operations, in TSC terms), the requests cluster into five families:

1. Access logs - “show us who logged into production.” The bedrock ask. For a sampled period, auditors want to see SSH and console access to production hosts: who, when, from where. The follow-up separates prepared teams from scrambling ones: “this login here - was it authorised, and how would you have known if it wasn’t?” A pile of auth.log lines answers the first question; only monitoring with alerting answers the second.

2. Change detection - “how do you know if a critical file was modified?” Configuration files, binaries, scheduled jobs, SSH keys. The auditor isn’t asking whether change happens - they’re asking whether unauthorised change would be noticed. This is file integrity monitoring territory, and “we’d notice eventually” is not an answer that closes a finding.

3. Anomaly detection and alerting - “prove the alert fired and someone responded.” The criteria expect monitoring for anomalies and response to them. In evidence terms: show an alert, the notification that went to a human, the acknowledgement, and the resolution - a complete story, timestamped. Teams with escalation policies and alert history export this; teams whose alerting is a Slack channel screenshot their scrollback and hope.

4. Retention - “show us the same evidence from seven months ago.” A Type II audit covers a period, commonly 6-12 months, and samples from anywhere inside it. Whatever your observation window is, your log and event retention has to at least match it - discovering in month nine that retention was 30 days is one of the classic small-company findings.

5. Review - “who looks at this, and when?” Monitoring nobody reads fails the spirit of the criteria, and auditors probe for it. Regular review of security events - even lightweight, even AI-assisted triage with human handling of what escalates - needs to be demonstrably happening.

The pattern behind all five

Notice what’s common: none of the requests are for logs, exactly. They’re for stories with evidence - access happened and was monitored, change happened and was detected, an anomaly happened and a human responded. Raw syslog satisfies none of them by itself; the connective tissue (detection, alerting, acknowledgement, retention) is the actual requirement.

That’s also why the DIY approach costs so much at audit time. The logs exist somewhere on each host; assembling them into stories - per request, per sample, across a fleet - is the fortnight of engineering time that makes everyone dread audit season.

Having the answers ready

This is the job AlertKick’s compliance evidence module was built for: the same eBPF agent that detects logins, file changes, and anomalous processes writes each event into an evidence timeline mapped to compliance controls, with alert-to-response history attached and retention configurable to match your audit window. When the request list arrives, the answer is a generated report, not an archaeology project.

Worth saying plainly: no tool makes you SOC 2 compliant - policies, process, and the audit itself are yours, and the compliance-automation platforms handle the org-level controls. What the host-level layer solves is the five families above, which are exactly the requests that otherwise consume engineering weeks.

If SOC 2 is on your roadmap, the cheapest preparation is starting the evidence clock early: install the agent now and walk into audit season with months of access, change, and alerting history already collected - instead of a retention gap exactly where the sample landed.