SOC 2 log retention: working out how long to keep logs

This is one of the few controls where a mistake cannot be undone. A missing document can be written in an afternoon. A log that was deleted in March is simply gone, and you find out when the auditor asks for a March date. Getting this right costs almost nothing. Getting it wrong can cost you a whole period.

Work out your own number first

A Type 2 tests whether controls ran over a period. The auditor picks instances from inside that period and tests each one.² The key detail is timing: the picking happens after the period closes. Retention plans that stop at the period end miss the months that follow. Here is a real calendar.

1. January 1. The observation period opens. From here on, what your systems record belongs to the report.
2. June 30. The period closes after six months, a length buyers ask for when three is not enough.
3. July. Fieldwork begins and the prepared by client list arrives. Requests keep coming while testing runs, and follow ups arrive after the first round.
4. September 30. The report is issued in month nine, counted from the opening day.
5. Any day can be sampled. January 2 included. On September 30 that log line is 271 days old. It still has to exist.

So your floor is the period length plus the tail, the tail being the stretch from period close to the last evidence request. Call it nine months. Tools do not offer nine month settings, and the next step up is usually 365 days. That is where twelve comes from.

Two things push the number higher. Back to back Type 2 periods overlap, since period two opens while period one is still being examined. And a customer reading the report in month ten can ask a question that sends you back to the same records. How long the observation period has to be helps you pick the window, which is the input to all of this.

Why the criteria stay silent on days

The criteria are written as goals, not settings.¹ That is why a search of the document for a retention period comes up empty. It is on purpose. A figure that fits a payments company running twelve month reports would make no sense for a five person team on its first three month window. So the standard leaves the number to your calendar and your policy.

Your policy creates a second floor

The auditor tests your controls against how you described them.³ That matters here. Say your security policy promises twelve months of audit logs, and the only record you have is 90 days of CloudTrail Event history. The standard is not the problem. Your control is running differently from your description, and that is an exception.

There are two honest fixes. Raise retention to match the policy, or rewrite the policy to match what you really keep and can prove. Leaving them out of step creates a finding from a sentence nobody forced you to write. What happens when a control fails shows how that looks in a finished report. Use whichever floor is higher. Derive the number from your calendar, then put that number in the policy.

Eleven defaults, checked against 271 days

We opened each vendor's own documentation on August 1, 2026, and every row links to the page it came from. The third column asks one question. Does the default keep the oldest record alive through a six month period and a three month fieldwork tail?

Four rows worth a second look

CloudTrail Event history is only a console view

It holds 90 days and sits apart from any trail or event data store. Editing a trail does not extend it. Your lasting record is the trail or the Lake store, and without one of them, 90 days is all there is.

Google Cloud Data Access logs start switched off

Admin Activity and System Event logs go to the _Required bucket for 400 days on their own. Data Access logs, which show who read what, are disabled outside BigQuery until you enable them. No logs written means nothing to retain.

The _Default bucket keeps 30 days

A single command, shown in the table, fixes it. Skip it and an account that looks well instrumented in month one has nothing to sample by month eight. Change it before the period opens.

Workspace keeps six months, and its export keeps sixty days

Six months covers one six month period with zero tail, and no admin setting extends it. The BigQuery export is the escape route, but its tables expire after 60 days by default. Set it up and forget it, and the copy dies before the original.

Our connector guides for AWS, GitHub, Google Cloud and Google Workspace cover the read-only permissions each one needs. That is a separate question from how long each source keeps its own data.

What this costs, and what getting it wrong costs

Every fix above is a setting, and settings are free. Log storage at a small company's volume is a minor line on a cloud bill. You do not need a consultant for any of it. One engineer with the table above and an hour of console time can do the whole list.

The expensive outcome is a lost period. If the auditor cannot sample, you run the period again, which means another stretch of calendar while the deal waits. On our software, which is $199 a month, cancel any time, the software side of a rerun is small. The calendar is the real loss.

That is why continuous collection helps. Our software pulls recurring evidence from AWS, GitHub, Google Cloud and Google Workspace while the period runs, and files it against the right control. A copy taken in February is still there in September, even if the source rotated it out in June. You should still raise the retention windows. The copy just removes the case where one unnoticed default forces a rerun.

A one week retention checklist

1. Write down three dates. Period start, period end, and a realistic issue date. Everything else follows from them, and a month of error is how a setting ends up 30 days short.
2. Read the live value in each console. Not the documented default and not this page. Someone may have lowered it to trim a bill two years ago.
3. Set every window you control to 365 days. Where there is no setting, use an export, and check the export's own retention.
4. Screenshot the correct setting. A capture showing the value, its scope and the date counts as evidence for the monitoring criteria.
5. Book two rechecks. One before the period opens and one before fieldwork. A mid period change made to save money stays silent until an auditor asks.

The evidence checklist lists what each system must produce and how often. The prepared by client list is the July request in the calendar above, and retention decides whether answering it is a quick query or an awkward email.

Your next step

Not sure whether your logging covers the criteria at all? The free readiness assessment takes about 15 minutes and returns a readiness assessment, score, gap list and one AI sample policy, including where monitoring falls short. When you are ready to collect evidence continuously, the pricing page lays out the monthly and yearly plans, and how audits are priced through our preferred pricing program.