SOC 2 Log Retention: How Long Should You Keep Logs?
“How long does SOC 2 require us to keep logs?” is one of the first questions startups ask when they start their audit.
The honest answer: SOC 2 doesn’t specify a number. What it requires is a policy, and evidence that you follow it.
This is general information, not audit advice. Your auditor has the final say.
Why there’s no fixed number
SOC 2 is based on the AICPA’s Trust Services Criteria. They describe what your controls should achieve, such as monitoring systems for anomalies and responding to incidents, not how long to keep data.
So retention is something you define in your policies. The auditor then checks two things:
- Is the policy reasonable for your risks and commitments?
- Did you actually follow it during the audit period?
What auditors actually look at
The observation period
A SOC 2 Type II report covers an observation period, often somewhere between 3 and 12 months. During testing, auditors sample evidence from across that period:
- “Show us the alerts from this week in March, and how you responded.”
- “Show us who accessed production on this date.”
If your logs only go back 7 days, you can’t produce that evidence. In practice, your retention needs to cover at least the whole observation period, plus time for the audit itself.
Consistency with your other commitments
Your retention policy also has to match:
- Customer contracts and DPAs that promise specific retention
- Other frameworks you follow, such as PCI DSS’s 12-month requirement
- Privacy law limits on how long you keep personal data (see GDPR and log retention)
Why 12 months is the common default
Many companies land on one year for security-relevant logs because:
- It covers a full 12-month Type II observation period
- It lines up with PCI DSS, which many auditors use as a reference point
- It’s long enough for late-discovered incidents, which are common
- It’s short enough to be defensible under data minimization rules
Where Cloudflare fits
If Cloudflare sits in front of your product, it produces evidence auditors care about:
| Evidence | Cloudflare source | Default retention |
|---|---|---|
| Attacks blocked by the WAF | Security Events | 24 hours to 30 days, by plan |
| Traffic anomalies | Analytics API | Varies by plan and dataset |
| Configuration changes | Account audit log | Check your plan |
| Per-request logs | Logpush / Log Explorer | Enterprise only |
The gap is obvious: a 12-month policy and a 24-hour default don’t match. If Cloudflare is part of your control environment, you need a way to keep its data.
A simple policy to start from
- Security-relevant logs (WAF events, auth, admin actions): keep 12 months
- Aggregated traffic analytics: keep 12+ months; they carry less personal data
- Raw request logs with IPs: keep only as long as you need them for security, and write down why
- Review the policy yearly and whenever your audit scope changes
Keep Cloudflare evidence for the whole audit period
MetricKeeper archives your Cloudflare security and traffic analytics on a schedule with a read-only token, so the evidence is still there when the auditor asks about March.