SOC 2 Audit Logging for Monitoring Tools: What Auditors Look For

Monitoring tools come up in SOC 2 audits in two places. The auditor wants to see that you monitor availability and performance (the AV trust services criterion), and that you log who is changing the monitoring configuration (the CC trust services criterion). The first is easy: any uptime monitor produces enough evidence. The second is where most teams underprepare. This guide covers what SOC 2 auditors actually look for, what your monitoring tool should log, and how to demonstrate the controls during the audit.

What SOC 2 cares about for monitoring

SOC 2 is principles-based, not prescriptive. The auditor does not check that you bought a specific tool. They check that you have controls in place to support the trust services criteria you committed to.

Two criteria typically touch monitoring tools. Availability (AV): you monitor your service for outages and respond to them. Common Criteria (CC), specifically CC7.2 (system operations monitoring) and CC8.1 (change management): you have controls around who can change monitoring configuration and how those changes get logged. The first is straightforward. The second is the bar most teams trip over.

What auditors expect to see in the logs

Four categories of log entry will be requested during a SOC 2 audit. Make sure your monitoring tool produces all four and that you can hand them over for the audit period.

• User access: who logged in, when, from what IP. Tied back to a named human, not a shared account.
• Configuration changes: every change to a monitor (create, update, delete), every change to a notification rule, every change to an API key. Includes who made the change and what changed.
• Incident events: every detected outage, with timestamps, duration, and the notifications that were sent.
• Administrative actions: plan changes, user invitations, role changes, password resets. The auditor wants to see the full trail of administrative activity.

The retention period that satisfies the auditor

SOC 2 does not specify a retention period; auditors typically expect at least 12 months of logs, sometimes longer for Type 2 audits that cover a multi-quarter operating period.

Practical guidance: retain audit logs for 13 months minimum so you cover the full Type 2 operating period plus a buffer. Retain incident events and check logs for at least 90 days for AV criteria. Many monitoring tools offer this on Business or higher tiers; verify before committing to a vendor.

Controls the auditor will test

The audit will test the operating effectiveness of your controls, not just their existence. Four common tests touch monitoring.

• Sample of access changes: the auditor picks 5 to 10 entries from the audit log and asks you to demonstrate the corresponding ticket or change request. Make sure your change management process is tracked outside the monitoring tool itself.
• Sample of incidents: the auditor picks 3 to 5 incidents from the period and asks for the response trail. Pre-stage your runbooks and postmortem template.
• API key inventory: the auditor asks who has API keys, when they were last used, and whether the scopes are appropriate. Run a quarterly key review and document it.
• Monitor coverage: the auditor asks how you decide what to monitor. Have a written policy that names the criteria; an undocumented 'we know what's important' answer fails the test.

Vendor-side controls to verify

Your monitoring vendor's own SOC 2 report is part of your audit. The auditor will ask for it.

Verify before committing: does the vendor have a SOC 2 Type 2 report? When was it issued and what is the operating period? Are the relevant criteria (AV, CC) covered? Is there a User Entity Considerations section that lists controls you are responsible for implementing on top of the vendor's? Take this seriously; a vendor without a current SOC 2 report can compromise your audit.

The minimum control set to pass a SOC 2 audit on monitoring

Use a monitoring tool that produces user access logs, configuration change logs, incident logs, and administrative action logs with at least 13 months of retention. Maintain a written monitoring policy that names the services you cover and the criteria for adding new ones. Track configuration changes through a ticket system or git PR so each change has a documented justification. Review API keys quarterly. Run a yearly tabletop exercise of incident response. Document everything. With those five controls in place, monitoring is a green check on your SOC 2 audit, not a stumbling block.