SOC 2 Evidence Retention: Build a Schedule You Can Defend

SOC 2 evidence retention starts with a practical question: will the record still exist, with enough context to retrieve and explain it, when the CPA firm asks? There is no useful blanket number of days for every artifact. Set a written schedule by evidence class, confirm the source system can meet it, and preserve the full operating record before a Type 2 period begins.

What does SOC 2 require you to retain?

The AICPA Trust Services Criteria provide criteria for evaluating controls over the scoped system. The AICPA’s SOC suite overview explains that an independent CPA provides the assurance report. Those sources do not give every company one retention period for every kind of evidence. The period and records you need depend on your controls, report scope, planned examination period, customer promises, and other obligations. Agree on the evidence plan with your CPA firm instead of treating a blog’s number as an audit rule.

For a Type 2 examination, the firm may test how controls operated during a period. If a quarterly access review is part of your approved process, keep the dated result of each review, not just the current list of users. If your change control covers every production deployment, make sure the source can produce the complete set of deployments for the period. The CPA firm selects its own samples and decides whether the evidence is sufficient.

Make a schedule by evidence class

Start with the SOC 2 controls and evidence collection map. For each class, record what the source produces and what your team needs to keep. This is a working template, not a prescribed set of periods:

Evidence class	Source and complete record	Retention decision to document
Access reviews	Identity export, review decision, exceptions, and follow-up for every scheduled review	Cover the reviews your control promises and allow later sample retrieval
Production changes	Repository, ticket, deployment, approval, and result records for the scoped population	Check how far each source can query or export history
Security events	Relevant logs, alerts, investigation decisions, and incident records	Balance examination, investigation, customer, and legal needs with storage and privacy
Policies and approvals	Effective policy revision, approver, approval date, and change history	Preserve the version that governed work at each tested date
Vendor reviews	Assessment, source report or reference, decision, exceptions, and reassessment	Check distribution limits and expiration of third-party reports

For every row, add an owner, approved duration or event-based end date, storage location, access group, export method, disposal method, and date of the last retrieval test. Record the reason for the period. Review contracts and applicable law with the right owner before adopting it. The period for a source log can differ from the period for a management review of that log.

The NIST SP 800-53 control catalog is a separate technical reference for thinking about audit-record retention. It does not add a fixed SOC 2 retention number or replace the AICPA criteria.

Test the source before the period starts

A written schedule is weak if a vendor account drops history before you can export it. Pick one early date in the candidate period and try to retrieve its record now. Save the query, filters, account, environment, timezone, export format, row count, and the person who checked the result. Repeat for systems with different defaults or account tiers.

If a source cannot preserve the planned window, change its configuration or establish an approved export process before relying on that control. Do not reconstruct a missing historical result and present it as contemporaneous. Record the gap and discuss it with the CPA firm. The audit populations guide shows how to check that a later export covers the full group of events from which samples may be drawn.

Decide what belongs in Git

FileGRC is a Git-native GRC workspace for SOC 2 work. JSON holds structured records, Markdown holds long-form work, and Git supplies the change history. That makes a dated retention schedule, control links, collection notes, and safe evidence references easy to inspect. The free local software does not operate your source systems or decide what your CPA firm will accept.

Treat Git history as part of the storage decision. Removing a file from the latest revision may leave it in prior commits, clones, backups, and shared exports. Do not commit plaintext credentials, private keys, tokens, recovery codes, or personal data that may need erasure. Keep sensitive artifacts in an approved restricted source or evidence store, and put a safe reference plus source, scope, date, collector, and verification notes in the program record. Use the evidence repository guide to choose between a fixed attachment and a reference.

FileGRC’s starter Data Retention Schedule is a proposal. Review it against your real systems and commitments, approve the rules your team can follow, and test them. A starter record does not show that a retention control operated.

What happens when the period ends?

Before deletion, check the schedule’s trigger and any customer, legal, security, or open examination need that extends retention. Confirm who can authorize disposal, which copies exist, and how the result will be recorded. Where a hold applies, record its owner and scope. Keep enough metadata to explain what was disposed of and why without retaining the sensitive content indefinitely.

This review also catches the opposite problem: keeping every raw export forever can increase access and privacy risk. A good schedule lets your team answer both questions, “Can we produce the evidence?” and “Why do we still have it?”