By Editorial team · Published · Last updated
SOC 2 reports don't technically expire, but the industry treats 12 months as the practical shelf life. Here's what to do when yours goes stale.
SOC 2 reports don't have a hard expiration date defined by the AICPA or any regulatory body. A report issued in 2024 covering a 2023 audit period remains technically valid indefinitely as an attestation of what was true during that period. The problem is practical, not legal: enterprise buyers, procurement teams, and vendor risk management programs apply their own staleness policies, and the de facto industry standard is 12 months.
Under SSAE 18 (the AICPA standard governing SOC 2 engagements), a Type II report covers a defined observation period — typically 6 or 12 months — and the auditor opines on controls as of and during that period. The report doesn't 'expire' because it isn't a certification with a defined validity window. It is an attestation of historical fact.
The market, however, applies a different logic: an enterprise security team reviewing a vendor's SOC 2 during procurement wants assurance that current controls are operating, not that controls operated 18 months ago. The practical staleness threshold is 12 months from the report's period-end date — not from the issuance date. A report covering January–December 2024, issued in February 2025, effectively becomes 'stale' in December 2025 from a buyer's perspective.
The goal is to keep your current report always within 12 months of its period-end date. The cleanest way to do this is a continuous audit program: start your next Type II observation period the day your current report is issued. That means you're always in observation, fieldwork, or report issuance — which sounds burdensome but, with a GRC platform like Vanta, Drata, or Secureframe running continuous evidence collection, requires minimal incremental effort.
A Type I report covers a single point in time and is inherently less durable than a Type II from a buyer's perspective. Enterprise buyers are more likely to accept a 10-month-old Type II than a 4-month-old Type I, because the Type II provides evidence of sustained operation. If you're still on a Type I, the staleness question will come up faster — another argument for moving to Type II as soon as possible.
If you're a buyer reviewing a vendor's SOC 2 and the report is more than a year old, the first action is to contact the auditor of record listed on the report's cover page. The auditor can confirm whether a renewal engagement is underway and provide a timeline estimate. If the vendor can't identify their auditor or the auditor doesn't confirm an active engagement, treat that as a vendor risk flag — the program may have lapsed.
If you're a service organization, the cleanest way to handle SOC 2 validity in customer contracts is to reference the framework rather than a specific report. A contract clause that says 'Provider will maintain SOC 2 Type II compliance and provide a current report upon written request' performs better over time than 'Provider has obtained SOC 2 Type II certification (Report dated [date])' — the latter requires a contract amendment every time you renew. Work with your legal counsel to draft vendor security addendum language that references ongoing compliance rather than a point-in-time document.
For customers reviewing inbound vendor security, a standard vendor risk policy should include: maximum acceptable report age (typically 12 months from period-end), acceptable bridge letter window (typically 90 days), and escalation procedure for vendors whose reports have lapsed. Documenting this policy once and applying it consistently is more defensible than making case-by-case exceptions for preferred vendors.
The most operationally efficient SOC 2 programs run as continuous cycles rather than annual projects. In a continuous model, the Type II observation period begins the day the previous report is issued, fieldwork starts 3 months after the period opens, and a new report is issued every 6–12 months with minimal readiness overhead. GRC platforms (Vanta, Drata, Thoropass, Scrut) support this model by maintaining continuous evidence collection between cycles rather than activating only when a new engagement begins. The practical result is that your report is never more than 12 months old and your evidence is always current — eliminating both bridge letter requests and the readiness scramble that characterizes annual-project compliance programs.