SOC 2 FundamentalsSOC 2Evidence RetentionAudit EvidenceComplianceEvidence Collection

SOC 2 Evidence Retention: How Long to Keep Audit Evidence and What Format Auditors Expect

How long should you retain SOC 2 audit evidence? What format? This guide covers evidence retention best practices, storage requirements, and how to organize evidence for repeatable audits.

SecureSpect Team··7 min read

What the AICPA Says About Evidence Retention

The AICPA's Trust Services Criteria do not specify a minimum evidence retention period. This is intentional — the criteria are principles-based, and evidence requirements are determined by the scope of the engagement and the auditor's professional judgment.

That said, auditors and legal counsel generally recommend retaining SOC 2 audit evidence for a minimum of three years, based on:

  • Audit standards: AT-C Section 205 (Examination Engagements), which governs SOC 2 examinations, requires auditors to retain their workpapers for at least 5 years. Your evidence supports those workpapers.
  • Statutes of limitations: US statutes of limitations for contract claims typically run 3–6 years. If a customer later disputes a claim about your security posture, you want evidence going back at least 3 years.
  • Type II renewal cycles: You need current-period evidence for each audit. Retaining prior periods allows you to respond to "what changed from year to year" questions from customers and auditors.
  • Practical recommendation: Retain SOC 2 audit evidence for 3 years minimum. 5 years is better practice and aligns with your auditor's own retention obligation.

    Types of Evidence and What to Retain

    Automated Evidence (highest value)

    Automated, timestamped evidence is the gold standard for SOC 2 audits. It demonstrates that controls operated throughout the observation period, not just when someone assembled a screenshot for the auditor.

    What to retain:

    • CloudTrail logs (compressed, ideally with log file validation enabled)
    • AWS Config configuration snapshots and change history
    • GuardDuty finding records
    • Access review completion records
    • Automated scan results (vulnerability scans, security checks)
    • SecureSpect control check results with timestamps
    Format: Retain in their original format (JSON, CSV, compressed logs). Auditors can access these directly in your auditor portal or via evidence packages.

    Storage: S3 with Object Lock (WORM — Write Once Read Many) is the appropriate storage mechanism for tamper-evident evidence retention. Configure lifecycle rules to transition to S3 Glacier Instant Retrieval after 90 days for cost management while maintaining immediate access.

    resource "aws_s3_bucket_object_lock_configuration" "evidence" {
    

    bucket = aws_s3_bucket.evidence.id

    rule {

    default_retention {

    mode = "COMPLIANCE"

    years = 3

    }

    }

    }

    Manual Evidence (acceptable with context)

    Manual evidence — screenshots, exports, emails — is accepted by auditors but carries less weight than automated evidence. It requires more effort to produce and is harder to maintain continuously.

    What to retain:

    • Access review completion documentation (signed off, dated)
    • Vendor SOC 2 reports received and reviewed (with date of review noted)
    • Security awareness training completion records
    • Incident response records
    • Change management approvals for significant changes
    • Board or management meeting minutes where security was discussed
    • Policy acknowledgment signatures
    Format: PDF is preferred for long-term retention. Screenshots should be labeled with the date captured, the person who captured them, and what they demonstrate.

    Storage: Organized in a structured folder hierarchy accessible to auditors through your auditor portal.

    Policies and Procedures

    Your security policies are themselves audit evidence. Retain:

    • Every version of each policy, with effective date
    • Evidence that policies were communicated to employees (training records, acknowledgment signatures)
    • Evidence that policies were reviewed and updated at the required cadence
    Format: PDF with version control. Store in an auditor-accessible location.

    Organizing Evidence for Repeatable Audits

    The most common complaint from engineering teams during their second or third audit is that evidence is scattered across S3 buckets, local drives, email threads, and shared drives. Organizing evidence into a consistent structure from day one pays dividends at every subsequent audit.

    Recommended structure:

    /evidence
    

    /[year]-[period] # e.g., 2026-jan-dec

    /access-reviews

    /vendor-assessments

    /training-records

    /infrastructure

    /cloudtrail

    /config-snapshots

    /guardduty-findings

    /soc2-control-checks

    /change-management

    /deployment-approvals

    /pr-exports

    /incident-records

    /policies

    /versions

    /acknowledgments

    This structure mirrors how auditors organize their workpapers. When an auditor asks "Can you show me access review evidence for Q2?" you can navigate directly to the folder.

    Evidence That Requires Specific Formats

    Some evidence types have implicit format requirements based on what auditors are testing:

    Access reviews: Auditors want to see not just that a review was conducted, but who was reviewed, what access they had, who conducted the review, and what actions were taken. A list of usernames with "reviewed" checked is insufficient. The review record should show access privileges at time of review and any changes made as a result.

    Vendor assessment reviews: Auditors want to see your assessment of the vendor's SOC 2 report, not just that you have the report. A brief review note — date received, observation period covered, exceptions noted, CUECs reviewed — demonstrates that you actually engaged with the report.

    Incident records: Incident documentation should follow your [incident response process](/blog/soc2-incident-management-guide): detection date, severity, systems affected, timeline of response actions, root cause, corrective actions, and closure date.

    Evidence Gaps That Create Audit Findings

    The most common evidence retention failures that generate Type II findings:

  • Gap in automated evidence collection: If GuardDuty was disabled for two weeks, CloudTrail didn't log for a period, or your monitoring platform was misconfigured, you have a gap in your evidence trail that may require explanation.
  • Point-in-time evidence for continuous controls: Taking a single screenshot of IAM policies at audit time doesn't demonstrate that the policy was in place throughout the observation period. Continuous, timestamped evidence is required.
  • Missing review documentation: The review happened but wasn't documented. For access reviews, training, and vendor assessments, documentation is the control — the action without documentation provides no audit value.
  • Expired policies: Policies that haven't been reviewed or updated in 2+ years suggest the program is stagnant. Review and re-issue policies annually.
  • Using SecureSpect for Evidence Retention

    SecureSpect generates and retains timestamped control check results for every check it runs. This addresses the most critical evidence retention requirement: continuous, automated evidence that controls operated throughout the observation period.

    For each check, SecureSpect records:

    • The check date and time
    • The resource evaluated
    • The result (pass/fail)
    • The SOC 2 criteria the check maps to
    • The specific finding (if failing)

    This data is available through the auditor portal for the duration of your subscription and can be exported for long-term retention in your own storage.

    Automate your SOC 2 evidence collection

    Connect your AWS and GitHub environments and start collecting audit-ready evidence today. Free to start.

    Start Free →More Articles