Evidence retention is one of the least glamorous parts of a compliance program, and one of the most consequential when things go wrong. You may have the most well-designed controls in your industry — but if you can't produce evidence that those controls operated at a specific point in the past, the auditor has no basis for an opinion. A control that ran without documented evidence is, from an assurance standpoint, a control that didn't run.
The challenge is that the frameworks you're most likely to operate under — SOC 2, ISO 27001, HIPAA — each approach retention differently, and the overlap is imperfect. Teams running dual or triple framework compliance often develop ad hoc retention practices that satisfy no framework fully. This post is an attempt to make the requirements concrete.
SOC 2: No Prescribed Retention Period, But Auditors Have Expectations
SOC 2 is silent on specific retention periods. The AICPA Trust Services Criteria don't prescribe "keep these records for X years." What they do require is that evidence is sufficient for the auditor to assess control operation — and the auditor defines sufficiency based on the observation period of the report and the nature of the controls being tested.
In practice, this means:
- For a six-month Type II observation window, you need evidence covering the full six-month period for every tested control. If your observation window runs from June to November, your access review evidence needs to include the reviews that ran in July and October (assuming quarterly cadence), not just the most recent one.
- After the report is issued, how long do you retain the underlying evidence? Most audit firms advise retaining evidence for the duration of the report's usefulness plus a buffer — generally, at least two annual audit cycles (two years). The reason: if a control finding is disputed, or if a security incident occurs and regulators ask for your historical compliance record, you need the supporting documentation.
- Your own system description and risk assessment documentation should be retained for as long as the system is in scope — and for at least three years after a major scope change.
The absence of a mandatory retention period in the SOC 2 framework is not a license to discard evidence promptly. It's a delegation of judgment to the organization — which means your retention policy needs to exist and be documented, and your actual practices need to match it.
ISO 27001: Control A.7.5 and the Documented Information Requirement
ISO 27001:2022 handles retention through the concept of documented information — a category that covers both documents (policies, procedures, plans) and records (evidence that procedures were followed). Annex A control A.5.33 (formerly A.12.1.1) addresses document control, and the standard's clause 7.5 establishes requirements for maintaining and retaining documented information.
ISO 27001 requires that you determine "the period for which documented information is retained" as part of your information security management system (ISMS) design. The standard doesn't specify a universal period — it delegates the determination to the organization based on legal, regulatory, and operational requirements. But critically, it requires that the determination be made and documented. A retention schedule that says "we keep things as long as seems reasonable" doesn't satisfy the 7.5 clause. You need a written retention schedule by document and record type, with defined periods and disposal procedures.
What most organizations running ISO 27001 land on, in the absence of overriding regulatory requirements, is a three-year minimum retention for ISMS operational records (access reviews, vulnerability scans, incident logs, change management records) and permanent or indefinitely-long retention for foundational ISMS documentation (the Statement of Applicability, risk treatment plan, and information security policy). The three-year figure aligns with typical re-certification cycles (initial certification plus two annual surveillance audits) and provides enough history for any third-party investigation that references the certification period.
HIPAA: Where Retention Is Explicit and Lengthy
HIPAA's Security Rule takes a more prescriptive approach than either SOC 2 or ISO 27001. Under 45 CFR 164.316(b)(2)(i), covered entities and business associates must retain documentation of their security policies and procedures for six years from the date of creation or the date it was last in effect, whichever is later.
This six-year requirement applies to your written security policies, risk analysis documentation, workforce training records, security incident logs, and the documentation of your security program's implementation. It does not apply uniformly to every piece of operational evidence — but it does set a floor for the core program records that regulators would examine in a HIPAA enforcement action or breach investigation.
For organizations running SOC 2 alongside HIPAA (common for health SaaS companies), the practical approach is to set retention at six years for all compliance program records, using HIPAA's explicit requirement as the governing standard. This eliminates the complexity of maintaining different retention schedules for different frameworks against the same underlying records.
We're not saying six years is the right answer for every organization — if you have a compelling cost or privacy reason to retain less, you can do so for records that fall strictly outside HIPAA scope. We're saying that for a team running both frameworks, harmonizing upward to the most restrictive requirement simplifies operations significantly.
What Formats Actually Hold Up in an Audit
Evidence format is a practical question that often gets overlooked in retention planning. The same underlying fact — "an access review happened on October 14" — can be documented in several ways, and not all of them are equally durable as audit evidence.
Timestamped System Exports
Exports from your identity provider, SIEM, or ticketing system that show timestamped activity are generally the strongest evidence format because they come from a system of record with tamper-evident logging. A CSV export from Okta showing when group memberships changed, or a Jira activity log showing when a change management ticket was reviewed and approved, is harder to challenge than a manually edited spreadsheet. Auditors treat system-generated records differently from manually created ones — both can be valid, but system records have presumed authenticity that manual records don't.
PDF Snapshots
Generating a PDF from a system view at the time of a review (screen capture, exported report) captures the state at a moment in time but is static — it doesn't show subsequent changes. PDFs are acceptable for point-in-time evidence (Type I control states, policy versions) but less useful for demonstrating operational continuity over a period. If you rely on PDFs for Type II evidence, you need one per review cycle, dated, not a single snapshot taken during audit preparation.
Email and Chat Records
Email threads and Slack messages documenting review decisions are technically valid evidence — they're timestamped, attributable, and show deliberation. In practice, auditors find them difficult to work with because they're narrative rather than structured. An email chain documenting an access review decision takes much longer to review and assess than a system-generated report with the same information. Email evidence also ages poorly: platforms change, archives are incomplete, search functions fail. It's a last-resort evidence format, not a primary one.
Structured Audit Logs
The gold standard for operational evidence is structured, queryable audit log data: records written to an immutable log by the system performing the action, with a defined schema, timestamps, and actor identity. AWS CloudTrail, Okta System Log, and GitHub audit log are examples. These records can be queried by date range, filtered by action type, and exported in machine-readable format for auditor review. If your compliance tool ingests and stores this data in a structured format, your evidence package is far more auditor-friendly than one assembled from ad hoc exports.
A Scenario: The Retention Gap at Audit Time
A 45-person SaaS company completed their first SOC 2 Type II with a nine-month observation window. During audit execution, the auditor requested evidence of quarterly access reviews for the observation period. The team had run three reviews — in month two, month five, and month eight of the observation window — and had documented each in a shared spreadsheet.
The spreadsheet for the month-two review had been overwritten in month five when the team reused the file. The version history in their document storage showed some earlier states, but not the exact snapshot from the review date. The auditor was able to reconstruct partial evidence from a combination of Okta export logs and an email thread, but the access review for month two was cited as an exception due to incomplete evidence. The underlying control had operated — the review genuinely happened — but the evidence couldn't demonstrate it with the specificity required.
This is the most common retention failure we've seen in practice: the event happened, but the record of the event was not preserved in a format that survived the review cycle. The fix isn't a more elaborate spreadsheet — it's a system that writes immutable records when controls operate, not spreadsheets that get edited and overwritten.
Building a Retention Schedule That Works Across Frameworks
A practical retention schedule for a team running SOC 2 plus one or more of ISO 27001 and HIPAA:
| Record Type | Retention Period | Governing Standard |
|---|---|---|
| Information security policy (current and superseded versions) | 6 years from last effective date | HIPAA 164.316(b)(2) |
| Risk assessment and risk treatment plan | 6 years | HIPAA / ISO 27001 cl.7.5 |
| SOC 2 / ISO 27001 audit reports and supporting workpapers | 7 years | Internal standard (auditor retention norms) |
| Access review records (each certification cycle) | 3 years minimum | ISO 27001 / SOC 2 observation coverage |
| Change management records | 3 years | SOC 2 CC6.8 evidence requirement |
| Security incident logs and response records | 6 years | HIPAA / ISO 27001 A.5.25 |
| Vendor security assessment records | 3 years after vendor relationship ends | SOC 2 CC9.2 / ISO 27001 A.5.22 |
| Workforce training and awareness records | 6 years | HIPAA 164.316(b)(2) |
| Backup test records | 3 years | SOC 2 Availability TSC evidence |
The retention schedule itself is a compliance artifact — it should be reviewed annually, version-controlled, and approved by whoever owns your compliance program. If you operate in a state with additional data protection requirements (California's CPRA, for instance, has specific retention limitation obligations for personal data), those requirements layer on top of and may shorten some of the periods above for specific data categories.
The audit trail is only as good as the records in it. Design your retention program to preserve evidence in formats that survive the cycles between audits — because the records you need most are always the ones from the period that's hardest to reconstruct.