SOC 2 log retention: how long to keep logs

Retention is the control where the damage stays invisible until it is permanent. A missing policy is a gap you close in an afternoon. A deleted log is gone. No remediation brings January back in September, and nobody notices the loss until an auditor asks for a date that no longer exists in the system.

What the criteria actually say

Nothing about days. The criteria are written as objectives to be met rather than settings to be configured,¹ which is why searching them for a retention period returns nothing. That absence is not an oversight. A period long enough for a payments company running twelve month reports would be arbitrary for a five person team on a first three month window.

What exists instead are two constraints, and together they produce a number for your specific report. The first is how the examination works. The second is what you wrote in your own policy.

The arithmetic that sets the floor

A Type 2 examination tests whether controls operated over a period, which means the auditor selects instances from inside that period and tests each one.² The selection happens after the period closes, not during it. That gap is the part retention planning leaves out.

Work a real calendar.

1. January 1. The observation period opens. Everything your systems write from this date forward is inside the report.
2. June 30. The period closes. Six months, the length a buyer most often names when a three month window is not enough for them.
3. July. Fieldwork starts and the prepared by client list arrives. Requests keep coming for as long as testing runs, and follow up requests land after the first pass.
4. September 30. The report is issued. Month nine, counting from the day the period opened.
5. The sample can be any day in the period. Including January 2. On September 30 a January 2 log record is 271 days old, and it has to still be there.

So the floor is the period length plus the tail, where the tail runs from the period closing to the final evidence request. Nine months, near enough. Retention settings do not come in nine month increments, and the next step any of the tools below offer is 365 days. That is where twelve comes from.

Two things push past that floor rather than pulling back from it. Consecutive Type 2 periods run end to end, so period two opens while period one is still being examined and the two windows overlap in your logs. 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 covers picking the window itself, which is the input this whole calculation depends on.

Your own policy is the second floor

The examination tests your controls against your description of them.³ That cuts both ways here. If your information security policy states twelve months of audit log retention and the only record you hold is 90 days of CloudTrail Event history, the problem is not the standard. A control is operating differently from the way it was described, which is the definition of an exception.

Two fixes are honest. Raise the retention until it matches the policy, or write the policy to match what you genuinely retain and can prove. Leaving the two mismatched manufactures a finding out of a document nobody had to write that way. What happens when a control fails covers how that reads in a finished report.

Pick the higher of the two floors. Derive the number from your calendar first, then write that number into the policy, rather than copying a retention period out of a template and discovering in month eight what it committed you to.

Defaults that expire evidence inside the period

Here is the table nobody publishes. Every row was opened on the vendor’s own documentation on August 1, 2026 and links back to the page it came from. The middle column answers one question: does the default survive a six month period plus a three month fieldwork tail, which is 271 days of the oldest record.

The four that catch people out

Four of those rows are worth reading twice, because in each one the surface a founder assumes is the record turns out not to be.

CloudTrail Event history is not your audit trail

It is a 90 day console view, and it is separate from any trail or event data store you create. Changing a trail does not change it, and it cannot be extended. The ongoing record is the trail or the Lake event data store, and if neither exists then 90 days is genuinely all you have.

Google Cloud Data Access logs are off

Admin Activity and System Event logs land in the _Required bucket and keep 400 days whether you configure anything or not. Data Access logs, the ones that show who read what, are disabled by default outside BigQuery. Retention is beside the point until they are turned on, because nothing is being written.

The Google Cloud _Default bucket holds 30 days

One command fixes it and the command is in the table. This is the single most common way a Google Cloud account looks well instrumented in month one and has nothing to sample in month eight. Raise it before the period opens, not after.

Google Workspace keeps six months, and its own export keeps sixty days

Six months of log events is exactly one six month period with no tail at all, and there is no admin setting that extends it. The BigQuery export is the way out, and its table expiration defaults to 60 days, so an export configured and forgotten deletes faster than the logs it was meant to preserve.

The connector setup pages for AWS, GitHub, Google Cloud and Google Workspace walk through the read-only permissions each one needs, which is a different question from how long the source system keeps what it is reading.

What to do this week

1. Write down your period dates first. Start date, end date, and a realistic issuance date. Every retention decision below is downstream of those three dates, and guessing them wrong by a month is how a setting ends up 30 days short.
2. Open each console and read the actual value. Not the vendor default, not this page. The value on your account, which somebody may have changed for a cost reason two years ago.
3. Set every window you control to 365 days. Log storage is cheap relative to re-running a period. Where the tool offers no setting, the fix is an export, and the export needs its own retention checked.
4. Screenshot the setting once it is right. The configuration screen showing the retention value, the scope it applies to and the date is itself evidence for the criteria that cover monitoring.
5. Put a recheck on the calendar. Once before the period opens and once before fieldwork starts. A retention change made mid period by somebody optimizing a bill is silent until it is not.

The evidence checklist lists what each of these systems has to produce and how often, and the prepared by client list is the request that arrives in July in the calendar above. Retention is what decides whether answering it is a query or an apology.

Keeping a second copy

Every fix on this page is a setting, and settings are free. The part that costs something is remembering to check them while a period is running, which is why continuous collection matters more than any single retention number.

Polara G.R.C. pulls the recurring evidence from AWS, GitHub, Google Cloud and Google Workspace as the period runs and stores it against the control it belongs to. A copy taken in February is still there in September even if the source system rotated it out in June. That does not remove the reason to raise the retention windows. It removes the scenario where a default you never saw is the only thing standing between you and a period you have to run again.