SOC 2 audit logging requirements (CC7.2) and how to satisfy them
If you're preparing for a SOC 2 Type II audit, your auditor will test whether you actually log and monitor system activity, not just whether you say you do. This page covers exactly what CC7.2 requires, what evidence auditors ask for, and how AuditRails' hash-chained logs satisfy it.
The control
SOC 2 CC7.2: Anomaly Detection and Monitoring
2017 Trust Services Criteria
“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; anomalies are analyzed to determine whether they represent security events.”
In practice, SOC 2 auditors also test the identity and access controls this monitoring depends on. CC6.1 specifically expects login, logout, failed-auth, access-granted, and access-revoked events to be logged, not just anomalies flagged after the fact.
What an auditor asks for
A SOC 2 auditor doesn't take your word that monitoring exists. They sample a date range and ask for the actual log records: who logged in, whose access was granted or revoked, what configuration changed, and whether every entry is provably unaltered. "We have logs somewhere" doesn't pass; a continuous, tamper-evident record for the audit period does.
Retention requirement
AuditRails retains SOC 2 audit logs for a minimum of 1 year by default, matching the framework's own requirement: long enough to cover a full Type II observation period plus the lookback your auditor will sample from. Retention extends automatically if you're also subscribed to a framework with a longer requirement.
What AuditRails captures
Every access-control event your auditor will sample for CC6.1/CC7.2 maps to a single logging call, no separate audit-log integration to build.
import { AuditRails } from '@auditrails/node';
const audit = new AuditRails({ apiKey: 'at_live_...' });
await audit.log({
action: 'access.granted',
actor_id: '...', // required
resource: '...', // required
metadata: {
role: '...', // optional
granted_by: '...', // optional
justification: '...', // optional
}
});What you hand your auditor
Generate an evidence bundle for your audit window and you get a zip containing a PDF summary report, the full event log as NDJSON, and a manifest with SHA-256 checksums of both files plus a hash-chain proof: something you can hand directly to your auditor as supporting evidence, not a screenshot they have to take on faith.
Common ways teams fail this control
- Logging that a user has access, but not when that access was granted, revoked, or by whom. CC6.1 explicitly expects the access.granted/access.revoked pair, not a point-in-time permissions snapshot.
- Failed login attempts never logged at all: only successful ones, which misses exactly the anomaly pattern CC7.2 asks you to monitor for.
- Logs stored in a system anyone with database access can edit or delete: an auditor who asks "can you prove this wasn't altered" and gets no good answer will flag it.
- No consistent actor_id across systems, so an auditor sampling one event can't trace the same person's activity across the rest of the log.
- Retention shorter than the audit period plus lookback window, so evidence for part of the sampled range simply doesn't exist by the time the audit happens.
Frequently asked questions
Does AuditRails make us SOC 2 compliant?
No single tool does. AuditRails gives you the tamper-evident audit-logging evidence CC6.1/CC7.2 require, which is typically one of the harder controls to satisfy from scratch: the rest of your SOC 2 scope (policies, other Trust Services Criteria, your own audit engagement) is separate.
Is AuditRails itself SOC 2 certified?
Not yet: we're actively preparing for a SOC 2 Type II audit and haven't started the formal process. See our security page for the current, honest status.
How long do I need to keep SOC 2 audit logs?
A minimum of 1 year is the common baseline auditors expect, which is what AuditRails retains by default for this framework: enough to cover a Type II observation period and the lookback window your auditor samples from.
Can I verify the logs haven't been tampered with, independent of AuditRails?
Yes: we publish an open-source CLI that independently recomputes the hash chain from an export. It doesn't call our API or trust our infrastructure.
This page describes regulatory obligations for information purposes and does not constitute legal advice. Whether they apply to your organisation should be confirmed with your own advisers.