SOC 2 Audit Log Requirements: What Your SaaS Actually Needs

What Specific Audit Log Capabilities Does SOC 2 Require?

SOC 2 does not hand you a checklist of fields to log. Instead, it defines Trust Services Criteria (TSC) — outcome-based controls that your audit logs must satisfy. The ambiguity is intentional: AICPA wants the criteria to apply across different architectures. But for engineering teams, this ambiguity creates confusion. Here is a concrete mapping of what auditors actually look for.

The four controls that most directly depend on audit logging are CC6.1 (logical access security), CC7.2 (system monitoring), CC7.3 (evaluation of detected events), and CC8.1 (change management). Each one translates to specific logging capabilities that your system must demonstrate over the full observation period — typically six to twelve months.

How Does CC6.1 Translate to Audit Log Requirements?

CC6.1 covers logical access controls. Auditors want to see logs that prove your system tracks who accesses what, when, and from where. At minimum, this means logging:

• Authentication events — successful and failed login attempts, MFA challenges, session creation and expiry
• Authorization decisions — permission grants, role changes, access denials
• Resource access — reads of sensitive data, API calls to protected endpoints, file downloads
• Actor context — user ID, IP address, user agent, and geographic location for each event

The key point auditors stress: you must log both successful and failed access attempts. Logging only successful actions misses the detection signal for brute force attacks, credential stuffing, and privilege escalation attempts. A common audit finding is that failed authentication events are logged to application error logs but not to the audit trail — these are different systems with different retention and query capabilities.

What Does CC7.2 Require for System Monitoring?

CC7.2 mandates continuous monitoring of system components to detect anomalies and potential security events. This goes beyond simple logging — your audit trail must support real-time or near-real-time detection capabilities. Auditors evaluate three things:

• Completeness — are all critical system components instrumented? Gaps in coverage are findings.
• Timeliness — are events captured in real-time or is there a delay? Batch-processed logs with multi-hour delays are a weakness.
• Alerting — can your team be notified of anomalies? Logs that nobody monitors are logs that provide no protection.

AuditKit addresses CC7.2 through real-time event streaming via GraphQL subscriptions and SIEM integration. Events are captured synchronously within the same database transaction as the action, ensuring zero delay between action and audit record. SIEM streaming to Splunk, Datadog, or Elastic enables automated anomaly detection rules that satisfy the alerting requirement.

How Should You Handle CC7.3 Event Evaluation?

CC7.3 requires that when your monitoring detects a potential security event, you evaluate it and respond appropriately. From an audit log perspective, this means your logs must support investigation workflows:

• Search and filter — query events by actor, action type, resource, time range, and tenant
• Correlation — trace a single user session across multiple events to reconstruct a sequence of actions
• Export — generate evidence packages for incident reports and post-mortems
• Integrity — prove that the logs have not been modified since the events occurred

The integrity requirement is where most homegrown solutions fail. If your audit logs are stored in a regular database table that DBAs can modify, you cannot cryptographically prove the logs are unaltered. Hash chaining — where each event's hash depends on the previous event — provides this guarantee. AuditKit's verification endpoint and CLI tool allow you to demonstrate chain integrity to auditors on demand.

What About CC8.1 Change Management?

CC8.1 requires that changes to infrastructure, data, software, and procedures are controlled and logged. For SaaS applications, this means your audit trail should capture:

• Configuration changes — feature flags, environment variables, system settings
• Schema changes — database migrations, API version changes
• Permission changes — role definitions, access policy updates
• Deployment events — code releases, rollbacks, infrastructure scaling

Many teams overlook change management logging because it crosses the boundary between application logs and infrastructure logs. The audit trail should capture application-level changes (permissions, settings, features) while your CI/CD pipeline handles deployment logging. AuditKit captures the application layer; integrate it with your deployment tooling to create a complete picture.

What Is the Minimum Retention Period for SOC 2 Audit Logs?

SOC 2 does not specify an exact retention period, but auditors expect logs to cover the full observation window plus a reasonable buffer. For Type II audits with a twelve-month observation period, you should retain at least fifteen months of audit data. Some regulated industries (healthcare, financial services) require longer retention — up to seven years.

Implement tiered storage: keep recent events in hot storage for fast querying, and archive older events to cold storage for cost efficiency. AuditKit supports configurable retention policies per tenant, with automatic archival and the ability to restore archived events for compliance reviews.

SOC 2 Audit Log Checklist: What to Implement Before Your Audit

• Log all authentication events (success and failure) with actor context
• Log all authorization decisions and permission changes
• Log access to sensitive resources with timestamps and actor identity
• Implement real-time or near-real-time event capture (no batch delays)
• Connect audit logs to alerting/SIEM for anomaly detection
• Enable search, filter, and correlation across the audit trail
• Implement tamper-evident integrity (hash chaining or equivalent)
• Support compliance exports (CSV, PDF evidence packages)
• Configure retention to cover your observation window plus buffer
• Log configuration and permission changes for CC8.1
• Enforce tenant isolation so customers cannot access other tenants' logs
• Document your logging architecture for the auditor's review

Key Takeaways

• SOC 2 maps to four key controls: CC6.1, CC7.2, CC7.3, and CC8.1 — each requires specific logging capabilities.
• Log both successful and failed access attempts — auditors flag missing failure logs as findings.
• Real-time capture and SIEM integration satisfy the monitoring requirement (CC7.2).
• Hash chaining provides the integrity guarantee that database permissions alone cannot.
• Retain logs for at least the observation window plus buffer — fifteen months minimum for Type II.