Log retention: what each framework actually requires (HIPAA, PCI, SOC 2, CMMC) — in plain English

Most breaches aren't discovered the day they happen. The average dwell time before detection still sits above 100 days, which means when your incident response team finally starts pulling logs, the events they need are already gone. Log retention isn't a box-checking exercise — it's the difference between a forensic investigation and a shrug.

The problem is that every compliance framework has different rules, and most of the summaries floating around online collapse the nuance into something useless. "Keep logs for one year" is the kind of advice that gets you through an audit and leaves you blind during an actual incident. Let's go framework by framework and get specific.

Why log retention is the silent compliance landmine

Here's the failure mode nobody talks about: organizations configure log retention on day one of a compliance push, then never touch it again. The SIEM ingestion pipeline grows, storage costs spike, someone trims the retention window from 13 months to 6 months to save money, and nobody updates the policy document. A year later, an auditor or an attacker forces the issue.

There's also the collection gap. Retention requirements are meaningless if you're not collecting the right logs in the first place. A 365-day window on your Windows Server event logs does nothing for you if you're not forwarding authentication events from Microsoft 365, network flow data from Cloudflare, or endpoint telemetry from CrowdStrike Falcon. Retention and collection are two separate problems, and frameworks tend to specify one while assuming you've already solved the other.

Finally, "immediately available" and "retained" are not the same thing. PCI DSS learned this and wrote the distinction into the spec explicitly. Hot storage and cold archive have different costs, different query latencies, and different implications for how fast you can respond. Keep that distinction in mind as we go through each framework.

HIPAA: 6 years (and the catch about audit logs)

HIPAA's log retention requirement is 6 years, and most covered entities know that number. What they miss is where it comes from and what it actually applies to.

The 6-year figure comes from 45 CFR § 164.530(j), which requires covered entities to retain documentation of their policies and procedures for 6 years from the date of creation or the date when it was last in effect, whichever is later. That's the administrative side. For technical safeguards, the Security Rule under 45 CFR § 164.312(b) requires covered entities to implement hardware, software, and procedural mechanisms to record and examine activity in information systems containing ePHI — but it does not explicitly state a retention period for those audit logs.

In practice, OCR (the HHS Office for Civil Rights) applies the 6-year documentation standard to audit log records as well when they investigate breaches, because audit logs are considered part of the documentation that demonstrates compliance with the Security Rule. Treat 6 years as your operational requirement.

The catch: state law can exceed federal minimums. California's CMIA and New York's SHIELD Act both have provisions that can push retention obligations higher depending on your patient population. If you're a multi-state health system, your retention floor might actually be higher than 6 years without you knowing it.

What you should actually be logging under HIPAA: login and logout events for any system touching ePHI, failed authentication attempts, access to patient records (read, write, delete), privilege escalation, configuration changes to security controls, and data export or transmission events. If you're running Epic or Cerner, those applications generate their own audit trails — but you need to make sure those logs are being exported into your SIEM or log management platform (Splunk, Microsoft Sentinel, Elastic) rather than siloed in the application database where a database admin can touch them.

6-year retention on high-volume audit logs from a large EHR is not cheap if it all lives in hot storage. We'll cover the math at the end.

PCI DSS: 1 year, with last 3 months immediately available

PCI DSS v4.0 Requirement 10.7.1 is direct: audit log history must be retained for at least 12 months, with at least the most recent 3 months available for immediate analysis. This is one of the cleaner requirements in the PCI world because it actually acknowledges the tiered storage model.

What counts as a log under PCI? Requirement 10.2 spells it out: individual user access to cardholder data, all actions taken by anyone with root or administrative privileges, access to audit trails themselves, invalid logical access attempts, use of and changes to identification and authentication mechanisms, initialization/stopping/pausing of audit logs, and creation/deletion of system-level objects. If you're running a cardholder data environment (CDE), every system in scope needs to generate these events.

The "immediately available" clause is significant. It means your last 3 months of logs need to be in a system where a QSA can ask you to pull records and you can deliver them in minutes, not hours. Shipping 90-day-old logs out of cold archive during an assessment is not acceptable. In practice, this usually means your SIEM or log management tool holds 90 days of hot data, with months 4–12 in a cheaper tier.

AWS CloudWatch Logs with a 90-day retention window feeding into S3 Standard for months 3–12 is a common architecture for smaller merchants. Larger environments running CrowdStrike, Palo Alto Networks firewalls, and F5 load balancers in front of their CDE tend to push everything into Splunk or Microsoft Sentinel with tiered storage policies.

One thing PCI v4.0 added that v3.2.1 didn't emphasize enough: you need to detect and alert on audit log failures. If your log pipeline breaks, you need to know within seconds, not after your next weekly review. Requirement 10.7.2 is explicit about this. NinjaOne and similar RMM platforms can monitor log forwarding health if you're a managed service provider handling PCI clients.

SOC 2: whatever you commit to in your own policy (yes, really)

SOC 2 has no mandated retention period. None. The AICPA's Trust Services Criteria don't specify a number of days, months, or years. What they require is that you define a policy, implement it consistently, and that your auditor can verify you did what you said you would do.

CC7.2 covers monitoring of system components for anomalies. CC6.1 covers logical access controls and the logs that support them. But the retention period? That's between you and your auditor.

This sounds liberating until you realize it creates a different kind of landmine. Because you're writing the policy, you own the commitment. If your SOC 2 policy says you retain logs for 1 year and your auditor finds that your Microsoft 365 audit log retention was set to 90 days for half the audit period, that's a finding — not because 90 days is inherently wrong, but because it doesn't match what you promised. The policy is the standard you're held to.

In practice, most SOC 2 Type II policies I see in the wild commit to either 90 days or 1 year. Startups with minimal infrastructure tend to go 90 days because it's defensible and cheap. Companies in the B2B SaaS space with enterprise customers who are themselves PCI or HIPAA covered tend to go 1 year because their customers' security questionnaires require it.

If you're setting your SOC 2 log retention policy for the first time, set it to 1 year. The cost delta between 90 days and 1 year is small if you're using cloud-native log storage, and it gives you room to support customers with stricter requirements without reopening your policy every time someone asks. It also gives you a meaningful forensic window. Cloudflare's audit logs, your Okta authentication logs, your AWS CloudTrail — all of it on a 1-year window is the right call.

CMMC L2: based on 800-171 — see specific control families

CMMC Level 2 maps directly to NIST SP 800-171 Rev 2, all 110 controls. The logging requirements come from the Audit and Accountability (AU) family, specifically controls 3.3.1 through 3.3.9.

3.3.1 requires you to create and retain system audit logs to enable monitoring, analysis, investigation, and reporting of unlawful or unauthorized activity. 3.3.2 requires you to ensure the actions of individual users can be traced to those users. Neither control specifies a retention period numerically.

Here's where it gets practical: NIST SP 800-171A, the assessment guide, and the CMMC assessment process look at whether your retention period is sufficient to support incident response and forensic investigation. The Defense Industrial Base (DIB) community consensus that has emerged from C3PAO assessments is that 1 year is the defensible minimum. Some prime contractors building to the DFARS clause requirements are pushing their subs toward 3 years, particularly for logs related to CUI access.

The specific log types that matter under 800-171 for CMMC L2: user authentication to systems processing CUI, privileged access events, configuration changes, account creation and deletion, failed access attempts, and data transfer events involving CUI repositories. If you're using Microsoft 365 GCC High for CUI storage (which the DoD is increasingly pushing), your Microsoft Purview audit logs need to be flowing somewhere with a retention policy attached — Microsoft's default 90-day audit log retention in standard E3 licensing is not sufficient. You need E5 or the Microsoft 365 Advanced Audit add-on to get the right log types and then you need to export them.

EMASS documentation and your System Security Plan (SSP) need to reflect your actual retention configuration. C3PAO assessors will pull your SIEM configuration and compare it to your SSP. Gaps there are findings that can block your CMMC certification.

Cheap retention: S3 Glacier Deep Archive math at $1/TB/month

The most common objection to long-term log retention is cost. It's largely a solved problem if you architect it correctly.

AWS S3 Glacier Deep Archive costs $0.00099 per GB per month — effectively $1 per TB per month. For most organizations, the question is how much log data you're actually generating.

Let's run the numbers. A 500-person company with Microsoft 365, CrowdStrike Falcon on all endpoints, Cloudflare for edge traffic, and a modest AWS environment will generate roughly 50–150 GB of compressed log data per day depending on activity. Call it 100 GB/day to be conservative. That's about 3 TB/month, or 36 TB/year. At Glacier Deep Archive rates, storing a full year of logs costs approximately $36/month. Six years for HIPAA compliance: $216/month in storage costs.

The catch with Glacier Deep Archive is retrieval time: standard retrieval is 12 hours. That's fine for logs that are more than 90 days old and you're doing forensic investigation, not real-time response. Your architecture should look like this: 90 days in your SIEM or a hot log store (Elasticsearch, Splunk, Microsoft Sentinel), then automated export to S3 Standard-IA for months 3–12, then lifecycle policy to Glacier Deep Archive for anything older.

Tools like NinjaOne can handle log collection from endpoints and push to S3. Cloudflare's Logpush sends edge logs directly to S3. CrowdStrike has native S3 integration for log export. The pipeline is not complicated — the complexity is in the policy and the monitoring to make sure the pipeline doesn't silently break.

If you're on Azure, Blob Storage Archive tier is comparable at roughly $0.00099/GB/month. Google Cloud Archive Storage is similar. The cloud economics here heavily favor compliance. There's no excuse for deleting logs that regulators want you to keep.

---

Quick reference: retention minimums by framework

| Framework | Minimum Retention | Immediately Available | Notes | |---|---|---|---| | HIPAA | 6 years | Not specified | Applies to audit logs supporting Security Rule documentation | | PCI DSS v4.0 | 12 months | Last 3 months | Req. 10.7.1 | | SOC 2 | Policy-defined | Policy-defined | 1 year recommended | | CMMC L2 / 800-171 | 1 year (consensus) | Not specified | SSP must match actual config |

---

Log retention is infrastructure, not paperwork. Get the collection right first — if you're not capturing authentication events from your identity provider, network flow data, and endpoint telemetry, the retention window is irrelevant. Then tier your storage so the last 90 days is always hot and the rest is in cold archive. Document your retention period in your policy and make your technical configuration match it exactly.

The frameworks above are your legal floor. Your forensic needs should set the ceiling.

Run the free Exposure Report and validate public-surface findings — because the logs you can't see are the ones that will matter most when something goes wrong.