How Long Do You Need to Keep SOC 2 Audit Evidence — and Where Should You Store It
Understand SOC 2 evidence retention requirements by evidence type, what storage formats auditors accept, what makes stored evidence tamper-proof, and the most common storage mistakes that cause audit failures.
Introduction
Most SOC 2 conversations focus on the audit itself — what auditors check, how controls are tested, what a clean opinion looks like. Far less attention goes to what happens between audits: the quiet, unglamorous discipline of collecting, organizing, and storing the evidence that makes the audit possible in the first place.
That gap is exactly where audit failures happen.
A company can have genuinely strong security controls and still produce a qualified opinion — or extend an audit by weeks — because its evidence is stored inconsistently, formatted in ways auditors cannot verify, or simply missing for a portion of the observation period. Evidence problems are not rare edge cases. They are one of the most common reasons SOC 2 audits go sideways.
This guide answers the questions that do not get asked often enough: How long do you actually need to retain different types of evidence? What formats do auditors accept and which do they push back on? What makes stored evidence genuinely tamper-proof versus just technically inaccessible? And what are the storage mistakes that silently set teams up to fail?
If you are building your evidence program from scratch, preparing for your first Type II audit, or trying to understand why your last audit took longer than it should have, this is the guide you need.
What Counts as SOC 2 Audit Evidence?
Before discussing how long to keep evidence and where to store it, it helps to be precise about what evidence actually means in a SOC 2 context.
SOC 2 evidence is any record that demonstrates a control was operating as designed during the audit observation period. The key phrase is during the observation period. An auditor reviewing a Type II report covering July 2025 through June 2026 needs to see evidence that each control operated throughout that entire window — not just that it existed at some point.
Evidence falls into two broad categories: system-generated and human-generated.
System-generated evidence comes directly from tools and platforms: access logs, authentication records, configuration exports, scan reports, deployment logs, and automated alerting records. This evidence is generally more reliable because it is produced by systems rather than people, and its timestamps are harder to manipulate.
Human-generated evidence includes things like access review sign-off records, change approval tickets, vendor assessment documentation, training completion reports, and meeting notes from security reviews. This evidence depends on consistent human behavior over time and is where gaps are far more common.
Both categories matter. Auditors use them together to build a picture of whether your controls were real and operational — or theoretical and intermittent.
Retention Requirements by Evidence Type
The AICPA does not publish a single, prescriptive retention schedule for SOC 2 evidence. What it does establish is that evidence must be sufficient to support the auditor's conclusions about control effectiveness across the entire observation period. In practice, this means your retention decisions need to be grounded in three inputs: the observation period itself, your own written retention policy, and any regulatory requirements that apply to your industry.
Here is how retention requirements play out across the most common evidence categories.
Access Control Evidence
Minimum retention: 12 months, recommended 24 months
Access control evidence includes user provisioning and deprovisioning records, access review logs, privilege change records, and MFA enrollment and enforcement logs. For Type II audits with a 12-month observation period, you need to demonstrate access reviews were completed each quarter — which means you need records covering all four review cycles, not just the most recent one.
Keep in mind that access review evidence is one of the categories auditors sample most aggressively. They will often request records for specific terminated employees to verify deprovisioning happened within the timeframe your policy commits to. If those records are gone, you cannot demonstrate the control operated correctly for those instances — even if it did.
Retain at minimum the full observation period plus 90 days buffer. For organizations in regulated industries such as healthcare or financial services, HIPAA and PCI DSS requirements may push this to 6 or 7 years, which should override the SOC 2 minimum.
Change Management Evidence
Minimum retention: 12 months, recommended 24 months
Change management evidence covers ticket records showing approval workflows, deployment logs, rollback documentation, and emergency change post-reviews. Auditors use this evidence to verify that changes to production systems did not happen outside your defined process.
A specific risk here is infrastructure-as-code and CI/CD pipeline changes. Many teams have excellent ticketing discipline for application changes but inconsistent records for infrastructure changes made via Terraform, CloudFormation, or Kubernetes configuration updates. Both need to be covered and retained with the same rigor.
Vulnerability Management Evidence
Minimum retention: 12 months, recommended 18–24 months
Vulnerability management evidence includes scan reports, remediation tickets, patching logs, and exception documentation for accepted risks. The retention requirement is not just for the most recent scan — auditors want to see that scans ran consistently throughout the observation period and that findings were remediated within your policy's stated SLA windows.
Critically: retain not just the scan output but the remediation evidence. A scan report that shows a critical vulnerability was detected in October with no corresponding remediation ticket for that finding is worse than no scan at all — it documents a gap rather than demonstrating a control.
Security Training Records
Minimum retention: 24 months
Training completion records are straightforward but frequently lost. You need records showing every employee in scope completed required security awareness training within the policy's required window — typically annually. Retain these for at least two full training cycles, because auditors reviewing a Type II renewal will often compare current year completion rates to the prior year.
If training is delivered through a platform that auto-purges records after 12 months, that is a configuration problem you need to address before your next audit cycle.
Incident Response Records
Minimum retention: 24–36 months
Incident response evidence includes records of any security events that triggered your incident response process: detection timestamps, response actions taken, communication records, post-mortems, and closure documentation. Even incidents that turned out to be false alarms should be documented and retained — they demonstrate your monitoring and response process is active.
For organizations subject to breach notification regulations, incident records may need to be retained for 3–7 years depending on jurisdiction. The most restrictive requirement in your regulatory environment should govern.
Vendor Risk Management Evidence
Minimum retention: 24 months
Vendor evidence includes annual review documentation, copies of vendor SOC 2 reports or equivalent certifications, contract security terms, and risk acceptance records for vendors that do not meet your baseline requirements. Because vendor reviews typically happen annually, you need at least two cycles of records to demonstrate the process is recurring rather than one-time.
Backup and Disaster Recovery Test Records
Minimum retention: 24 months
DR test evidence needs to include not just that a test was scheduled but that it was executed and its results documented. This means test plans, execution logs, results including any recovery time measurements, and sign-off by an appropriate approver. Retain at minimum the last two full test cycles.
Audit Logs and System Logs
Minimum retention: 12 months active, 24 months archived
System and audit logs are the most voluminous evidence category and the one most commonly misconfigured for retention. Log retention has two distinct phases: active retention in a searchable platform where logs can be queried in real time, and archive retention in cold or warm storage for compliance purposes.
Auditors typically need logs to be retrievable, not just stored. A log file in an S3 bucket that takes a week to restore from Glacier tape is not operationally accessible for audit purposes. Maintain at least 90 days of active, searchable log access. Archive the remainder for the full retention period.
What Storage Formats Do Auditors Actually Accept?
This is an area where teams often make assumptions that create problems. Auditors do not have a single accepted file format list, but they do have requirements around verifiability, completeness, and authenticity. Here is how to think about format decisions for each major evidence type.
System-Generated Exports vs. Manual Screenshots
System-generated exports — CSV reports, PDF exports directly from platforms, API-driven evidence exports — are significantly more credible than screenshots. A CSV export from your identity provider showing all active users with their last login date and MFA status is a first-party record. A screenshot of that same screen can be edited in any image editor in under a minute.
This does not mean screenshots are never acceptable. For demonstrating a specific configuration state, a screenshot may be the most practical option. But screenshots as the only evidence for a control are a credibility problem. Auditors routinely ask for corroborating evidence when primary evidence is screenshot-dependent.
Best practice: Use system-generated exports as your primary evidence wherever the platform supports it. Use screenshots only as supplementary evidence to illustrate specific configuration states.
PDF Reports
PDF is the most universally accepted format for policy documentation, scan reports, and vendor certificates. For policies, the PDF should include metadata showing when it was generated, who approved it, and what version it represents. PDFs with no metadata, no version information, or creation dates that do not align with the period being audited raise questions.
For vulnerability scan reports exported as PDFs, ensure the report includes the scan timestamp, the scope of the scan, and the tool and version that generated it. A PDF that simply lists findings with no provenance information is less reliable than one that clearly identifies when and how it was generated.
Log Files
Raw log files in standard formats — JSON, CSV, syslog — are acceptable and often preferable to reformatted or summarized log exports because they preserve original structure. If you are exporting logs from a SIEM or log management platform for archival purposes, export in the native format the tool supports rather than converting to a proprietary format that requires special software to read.
Ensure that log files include consistent, reliable timestamps in UTC. Log files with inconsistent timezone handling or missing timestamps for portions of the observation period are a significant red flag for auditors.
Ticketing System Records
For change management and access review evidence, exports from ticketing systems such as Jira, ServiceNow, or GitHub Issues are acceptable in CSV or PDF format. Include all relevant fields: ticket creation date, requester, approver, approval timestamp, and resolution date. Partial exports that omit approval timestamps make it impossible to verify that approval happened before the change was implemented.
Evidence Packages in Compliance Platforms
An increasing number of organizations use dedicated compliance platforms — Vanta, Drata, Sprinto, Secureframe, and similar tools — that compile and package evidence automatically. Evidence packaged through these platforms is generally well-structured and auditor-familiar. Most major audit firms have worked with these platforms directly and understand their output formats.
If you use a compliance platform, confirm that its evidence exports include the underlying source data and not just a platform-generated summary. Auditors want to see the actual evidence, not a compliance platform's certification that the evidence exists.
What Makes Stored Evidence Genuinely Tamper-Proof?
Tamper-evidence is a meaningful concept in SOC 2 evidence management, and it is frequently misunderstood. Many teams assume that evidence stored in a cloud platform is automatically tamper-proof because it is "in the cloud." It is not.
True tamper-evidence requires demonstrating not just that evidence exists but that it has not been modified since it was originally created. Here is what that looks like in practice.
Immutable Storage Configurations
Major cloud platforms — AWS S3, Google Cloud Storage, Azure Blob Storage — support object immutability configurations that prevent modification or deletion for a specified period. AWS S3 Object Lock with Compliance mode, for example, prevents any user — including root account users — from deleting or overwriting objects during the lock period.
This is a meaningful control. Evidence stored in a bucket with Object Lock in Compliance mode for 24 months cannot be retroactively altered. That is a genuinely stronger statement than "we store evidence in S3."
If you are not using immutability configurations on your evidence storage, you should be. It is a low-effort configuration change with significant audit credibility value.
Cryptographic Hashing
For critical log files and evidence artifacts, cryptographic hashing provides a verifiable chain of custody. At the time of collection, generate a SHA-256 hash of each evidence file. Store that hash separately from the file itself. When an auditor — or your own team — needs to verify that a file has not been tampered with, regenerate the hash and compare.
This approach is used in digital forensics and legal evidence management for the same reason it matters in SOC 2 contexts: it creates a mathematical proof that a file is unchanged from its original state.
Audit Logging of Evidence Access
Ironically, one of the things auditors look for is evidence about your evidence: who has accessed your compliance documentation, whether anyone has modified it, and when changes occurred. Maintain audit logs for your evidence storage environment itself. If someone edits a policy document or deletes an evidence artifact, that action should be logged.
This means your evidence repository needs the same logging and monitoring discipline you apply to your production systems.
Version Control for Policy Documents
For policy documents and procedure documentation, version control systems — Git repositories, document management platforms with version history, or dedicated GRC tools — provide a verifiable change history. Auditors can see not just the current state of a policy but when it was last changed, what changed, and who approved the change.
Storing policy documents in a shared drive folder with no version history creates an unverifiable record. The document might have been updated yesterday to reflect what the audit requires. Version control with commit history makes that kind of retroactive modification visible.
Write-Once, Read-Many (WORM) Storage
For log archives and evidence that must be retained for regulatory purposes, WORM storage is the gold standard. Once written, the data cannot be modified. Cloud-native WORM implementations — AWS S3 Glacier with Vault Lock, Azure Immutable Blob Storage — provide durable, compliance-grade storage at reasonable cost for the volumes involved.
The Most Common Storage Mistakes That Cause Audit Failures
Understanding what to do is only half the picture. Understanding where teams actually go wrong is equally valuable.
Storing Evidence in Personal Drives and Email
This is more common than any compliance-focused organization would like to admit. Access review sign-offs emailed to a manager and never formally archived. Vendor SOC 2 reports downloaded to a personal laptop folder. Change approval screenshots saved in someone's Downloads folder.
When that person leaves the company — or when their laptop is replaced — the evidence is gone. Evidence that exists only in personal storage is evidence that does not exist for audit purposes.
Establish a single, shared, access-controlled evidence repository as a non-negotiable baseline. Everything that constitutes audit evidence goes there, regardless of how a team member initially received or created it.
Collecting Evidence Once at Audit Time
One of the most common patterns for first-time SOC 2 programs is what might be called the "sprint to the finish" approach: controls operate all year with minimal documentation, then in the weeks before the audit, the team frantically collects whatever evidence they can find to demonstrate the year's activity.
This approach has two problems. First, many evidence artifacts are time-sensitive — access review sign-offs, scan reports, change approval records — and cannot be retroactively reconstructed after the fact. Second, evidence collected in a frenzied sprint is inconsistent, incomplete, and often raises more questions than it answers.
Evidence should be collected continuously and systematically throughout the observation period, not assembled under audit pressure. Treat evidence collection as an operational discipline, not an audit preparation task.
Inconsistent Timestamp Handling
Log files and evidence artifacts with inconsistent timezone handling are a source of subtle but significant problems. If your application logs use UTC, your SIEM enriches them to local time, and your evidence exports reflect a third timezone, establishing a coherent timeline of events becomes difficult — and auditors trying to correlate evidence across systems will push back.
Standardize on UTC across all logging systems and evidence exports. Document that standard in your logging policy. Enforce it in your log management configuration.
Retaining Evidence Without an Organized Structure
Having evidence and being able to find and present it are two different things. Auditors work on tight timelines and expect to receive evidence in response to specific requests quickly. If your evidence repository is a flat folder of files with inconsistent naming conventions, no organization by control or time period, and no index, finding the right artifact under audit time pressure is genuinely difficult.
Organize your evidence repository by control domain and time period. A folder structure aligned to the TSC criteria — with subfolders by quarter or month — makes evidence retrieval fast and reduces the risk that something gets overlooked during an evidence request.
Not Verifying That Stored Evidence Is Actually Retrievable
This is the evidence equivalent of never testing your backups. Teams configure evidence retention, assume it is working, and discover during the audit that the log archive from Q3 of the observation period cannot be retrieved because the archival job failed silently, the access credentials rotated and were not updated, or the storage tier selected requires a multi-day retrieval window.
Test evidence retrieval periodically and document the test. If you archive logs monthly, verify a sample retrieval quarterly. If evidence is stored in cold storage, confirm the retrieval process works and the timeline is acceptable before you are in an audit situation where you need it in 24 hours.
Deleting Evidence Before the Retention Period Expires
Storage costs money. Compliance teams without clear retention policies sometimes make ad hoc decisions to delete older evidence to reduce storage costs, without realizing they are destroying material that an auditor — or a future audit cycle — will need.
Implement a documented retention policy with specific retention periods for each evidence category. Use lifecycle management rules in your cloud storage platform to enforce those periods automatically. Never allow manual deletion of compliance evidence outside the documented process.
Over-Relying on Your Compliance Platform as the Source of Truth
Compliance automation platforms are valuable tools. They automate evidence collection, organize controls, and provide audit-ready packages. They are not, however, infallible. Platform outages, integration failures, and collection gaps can result in missing evidence that no one notices until the audit begins.
Treat your compliance platform as a collection and organization layer, not as the authoritative evidence store. Maintain independent access to the underlying source systems and verify periodically that the platform's evidence matches what those systems actually show.
Building an Evidence Retention Policy That Holds Up
An evidence retention policy is not just a document — it is the operational backbone of your compliance program between audits. A policy that holds up under auditor scrutiny has these characteristics.
It is specific about retention periods for each evidence category rather than applying a single blanket retention window. "We retain all compliance evidence for 12 months" does not account for the different requirements of incident records, training completions, and vendor assessments.
It identifies a responsible owner for evidence management — not just a team, but a named role. When evidence retention is everyone's responsibility, it becomes no one's.
It specifies the approved storage location or locations and prohibits storage in personal drives, email archives, or other non-sanctioned locations.
It includes a review cycle — typically annual — to update retention periods as regulatory requirements evolve and as the audit scope changes.
It is enforced through technical controls where possible: automated lifecycle policies in storage platforms, automated evidence collection in compliance tools, and access controls that prevent unauthorized deletion.
The Bottom Line: Evidence Is Your Audit
In a SOC 2 audit, evidence is not a support function for the audit. Evidence is the audit. Everything the auditor concludes about whether your controls operated effectively derives from the evidence you can produce. Strong controls with weak evidence produce qualified opinions. Adequate controls with excellent, well-organized, tamper-evident evidence produce clean ones.
The organizations that consistently produce clean SOC 2 reports do not treat evidence management as an afterthought. They build evidence collection into operational workflows so that it happens continuously and automatically. They store evidence in structured, access-controlled, immutable repositories. They test retrieval, verify completeness, and maintain a retention policy that reflects actual requirements — not just what seemed reasonable when someone wrote the first draft.
Evidence management is not glamorous work. It does not make headlines and it rarely generates executive enthusiasm. But it is the work that determines whether an audit succeeds or stumbles — and that makes it worth doing right.
Conclusion
SOC 2 evidence retention is not a compliance checkbox. It is the operational infrastructure that makes your audit credible, your controls verifiable, and your organization defensible when a customer's procurement team asks the hard questions.
Get the retention periods right for each evidence type. Store evidence in formats auditors can verify and trust. Apply immutability configurations and version control to protect the integrity of what you collect. And eliminate the storage habits — personal drives, sprint-mode collection, inconsistent timestamps, untested retrieval — that quietly undermine programs that are genuinely trying to do the right thing.
Your auditor will arrive with a list of requests. The only question is whether your evidence program has been building toward that moment all year — or scrambling to catch up in the final weeks.