SOC 2 does not hand you a list of log sources or a retention number. It asks you to show, with evidence, that you detect and respond to security events. For most companies that means central logging, detection rules, a way to handle alerts and enough history to cover the audit period. This guide explains which Trust Services Criteria are about logging and what an auditor wants to see.
Not legal advice
SOC 2 is an attestation by an independent CPA firm against the AICPA Trust Services Criteria. Your auditor decides what evidence is enough for your controls.
The criteria that are about logging
Every SOC 2 report covers the Security criteria, also called the Common Criteria (CC). Logging and monitoring sit mainly in the CC6 and CC7 series:
| Criterion | What it asks | Logs you need |
|---|---|---|
| CC6.1 | Logical access is restricted and controlled | Sign-ins, failed sign-ins, MFA events, role changes |
| CC7.1 | Detect configuration changes and new vulnerabilities | Change logs, cloud audit logs, vulnerability scan results |
| CC7.2 | Monitor system components for anomalies that point to attacks or errors | Security events from endpoints, network, cloud and applications |
| CC7.3 | Evaluate security events to decide whether they are incidents | Alerts with context and a record of the decision |
| CC7.4 | Respond to incidents with a defined process | Case history: who did what and when |
| CC4.1 | Monitor whether controls keep working | Evidence that logging and alerting were active over the period |
What an auditor asks for
- A list of in-scope systems and proof their logs reach a central place.
- Detection rules or alert definitions, and who receives the alerts.
- Samples of alerts from the audit period and what was done with them.
- Access control on the logs, and an audit trail of who changed settings.
- Proof that logging did not stop for long stretches during the period.
The last point is where many teams struggle: a Type II report covers an observation period (often 3 to 12 months), and gaps in that period are findings.
How long to keep logs for SOC 2
SOC 2 sets no fixed retention period. In practice you keep logs at least as long as the observation period plus some margin, so the auditor can sample from any month. Many teams settle on 12 months. If you also fall under PCI DSS, HIPAA or the GDPR, those rules decide; see log retention by regulation.
A setup that works for a small team
- Send identity, cloud, endpoint and application logs to one platform.
- Turn on tested detection rules for sign-ins, privilege changes and exposure of known vulnerabilities.
- Route alerts to one queue and close each one with a short note: that note is your CC7.3 evidence.
- Keep an export or report per month, so collecting evidence at audit time takes hours, not weeks.
How LogPulse supports SOC 2 evidence
LogPulse collects logs centrally in the EU, runs detection rules from the Detection Hub that are mapped to MITRE ATT&CK, and rolls signals up into notables with a risk score, so a small team works a short queue. Notables and cases keep the history of what was decided. The audit trail of your own LogPulse organisation (sign-ins, role and setting changes) is kept for 180 days in the _audit index on every plan. See the SIEM page for how it works.
Our own status
LogPulse itself is preparing for a SOC 2 Type II audit and is not certified yet; the current status is on Compliance & Trust. LogPulse produces evidence for your SOC 2 programme; it does not make you SOC 2 compliant on its own.