Security Log Retention Requirements: PCI DSS, HIPAA, SOC 2, and GDPR Compared
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Security log retention compliance is typically managed incorrectly in one of two directions: keeping everything forever on the assumption that longer is always safer, or keeping the minimum possible to reduce storage costs without checking whether the minimum satisfies applicable regulations. Both approaches create problems — over-retention creates unnecessary storage cost and GDPR exposure, while under-retention creates compliance failures that appear during audits.
The correct approach is to map each log type to its specific compliance requirement, apply tiered storage that satisfies both the retention period and the immediate-availability requirement, and document the policy explicitly enough that an auditor can verify it without significant additional explanation.
Building the log retention compliance matrix
The compliance matrix is the foundation of defensible log retention: it maps every log type to the specific control number, required retention period, and applicable framework before you design any storage architecture. This section covers how to extract the concrete requirements from PCI DSS v4.0 Requirement 10, HIPAA 45 CFR 164.316(b)(2)(i), SOC 2 CC7.2, and GDPR Article 5(1)(e); combine them into a single per-log-source retention schedule; and implement WORM storage with S3 Object Lock or Azure Immutable Blob to satisfy the tamper-evident integrity controls that PCI and most auditors require before long-retained logs are accepted as evidence.
Identify all applicable frameworks and their specific requirements
For each compliance framework that applies to your organization: identify the specific control number, the required log types, and the required retention period. PCI DSS v4.0: Requirement 10.7.1 (12 months, 3 months immediately available), applies to audit logs for systems in the cardholder data environment. HIPAA: 45 CFR 164.316(b)(2)(i) (6 years), applies to documentation including audit logs of ePHI access. SOC 2: CC7.2 (no specific period, document and follow your policy consistently), applies to all security monitoring logs. GDPR: Article 5(1)(e) (retain only as long as necessary), applies to logs containing EU personal data. Build a table: log source, applicable frameworks, required retention period (the maximum across all applicable frameworks), hot tier duration, and cold tier duration.
Implement log integrity protection before extending retention
Long-retained logs that can be modified are not evidence — they are data. Compliance frameworks require that audit logs be protected from unauthorized modification. Implementation options: (1) WORM storage (Write Once Read Many): AWS S3 with Object Lock in Compliance mode, Azure Immutable Blob Storage, GCP retention policies. Once written, objects cannot be modified or deleted by anyone, including storage administrators, until the retention period expires. (2) Cryptographic integrity: log aggregators can compute a hash of each log batch and store the hash in a separate tamper-evident store — any modification of the log file invalidates the stored hash. (3) Separate log storage from production: logs stored in the same systems that generated them can be modified by the administrators of those systems. Forward logs to a centralized, separately-administered log store where production admins have no write access.
Implementation: tiered storage for multi-framework compliance
Satisfying PCI DSS's 3-month immediate-availability requirement, HIPAA's 6-year retention mandate, and GDPR's data minimization principle simultaneously requires a three-tier storage architecture rather than a single-tier solution. This section covers how to configure AWS S3 with Object Lock in Compliance mode as the cold-tier archive, how to route log data from your SIEM through warm-tier object storage using Athena or native SIEM archive features, and how to set per-table retention periods in Microsoft Sentinel to automate the transition from the Analytics tier to archive storage without manual intervention.
Configure S3 Object Lock for compliance archive storage
AWS S3 with Object Lock in Compliance mode is the most straightforward tamper-evident archive for regulatory compliance. Configuration: create an S3 bucket with Object Lock enabled (requires enabling at bucket creation — cannot be added to an existing bucket), set the default retention period matching your compliance requirement (for a 12-month PCI requirement: set default retention to 365 days in Compliance mode), configure your log shipper (CloudWatch Logs subscription, Fluentd, Logstash) to export log files to this bucket. In Compliance mode: no one, including the root account, can delete or modify objects before the retention period expires. For multi-framework compliance: set the retention period to the maximum across all applicable frameworks (if PCI requires 12 months and HIPAA requires 6 years for the same log type, set retention to 6 years with Compliance mode for that log type).
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The bottom line
Log retention compliance is a mapping exercise, not a 'more is always better' exercise. Map each log type to its specific compliance requirements (PCI DSS is 12 months/3 months hot; HIPAA is 6 years for ePHI access logs; SOC 2 is whatever your documented policy says; GDPR is no longer than necessary with personal data). Build a tiered storage architecture with a SIEM hot tier for recent searchable logs, and WORM object storage (S3 with Object Lock, Azure immutable blobs) for compliance archive. Document your retention policy explicitly — auditors test actual retention against what the policy says, so inconsistencies between policy and implementation become findings. After implementing the architecture, run a retention audit quarterly: pull a sample of logs from the cold tier that were written 11 months ago and confirm they are accessible and unmodified — this tests the archive before an auditor tests it for you.
Frequently asked questions
What does PCI DSS v4.0 specifically require for security log retention?
PCI DSS v4.0 Requirement 10 covers audit log management. Key retention requirements: 10.7.1: all required audit logs must be retained for at least 12 months, with at least the most recent 3 months immediately available for analysis. 'Immediately available' means searchable without a restoration process — archived data that takes 48 hours to retrieve does not satisfy the 3-month immediate availability requirement. Required log types (Requirement 10.2): user access to system components with cardholder data, administrative actions, audit log access and modification, failed authentication attempts, and use of privileged accounts. Log integrity: logs must be protected from modification (10.3) — this requires either write-once storage (WORM), or integrity verification mechanisms that would detect modification. Common implementations: SIEM with a separate log archive S3 bucket with Object Lock (WORM) for 12-month compliance retention.
What does HIPAA require for audit log retention?
HIPAA's Security Rule (45 CFR 164.312(b)) requires covered entities to implement hardware, software, and procedural mechanisms that record and examine activity in information systems that contain or use ePHI. Specifically, the Security Rule requires audit controls as an implementation specification. For retention: HIPAA does not specify a retention period for audit logs directly, but 45 CFR 164.316(b)(2)(i) requires that documentation (including policies, procedures, and records of actions) be retained for 6 years from creation or last effective date. In practice, most healthcare organizations and their auditors interpret this as requiring 6-year retention for access logs to ePHI systems. HIPAA also requires that logs be reviewed regularly — a log that is retained but never reviewed fails the audit control requirement. Implement log review procedures and document the reviews as evidence.
What log retention does SOC 2 require?
SOC 2 does not mandate specific log retention periods — the AICPA Trust Services Criteria (CC7.2) requires that the organization 'monitors system components and the operation of controls' but leaves the specifics to the organization's documented policies. In practice, SOC 2 auditors expect: (1) A documented log retention policy (what is retained, for how long, where it is stored). (2) Consistency between the documented policy and actual retention — if your policy says 12 months but logs are only retained for 3 months, that is an audit exception. (3) Evidence of log review: some organizations fulfill CC7.2 with automated alerting rather than manual log review, but documentation of the review/alerting process is required. Industry norm for SOC 2 is 12-month retention for security logs. Auditors will ask for logs to support findings during the audit period (typically 6-12 months) — ensure those logs are retrievable for the full audit period.
How does GDPR affect security log retention?
GDPR's storage limitation principle (Article 5(1)(e)) requires that personal data not be kept longer than necessary for the purpose for which it was collected. Security logs frequently contain personal data — IP addresses (pseudonymous under GDPR in the EU), usernames, email addresses, and device identifiers. GDPR implications for log retention: (1) Log retention periods must be documented with a legitimate purpose for each retention period. Security investigation and compliance are legitimate purposes, but '7 years just in case' without a specific purpose may not satisfy the necessity test. (2) For EU user logs: consider pseudonymization (hashing usernames in logs while retaining the ability to de-pseudonymize during investigations) to reduce GDPR exposure while maintaining security utility. (3) Retention periods must be communicated in your privacy notice. (4) Data subject access requests can extend to logs — be prepared to search logs for a specific individual's data if requested.
What specific log types must I retain and what is the minimum retention period for each?
Core log types and minimum retention periods synthesized from PCI DSS, HIPAA, and SOC 2: Authentication logs (successful and failed login attempts): 12 months minimum (PCI DSS), 12 months recommended (SOC 2). Privileged access and administrative actions: 12 months minimum (PCI DSS), 6 years for ePHI systems (HIPAA). System and application errors: 12 months minimum. Network security logs (firewall, IDS/IPS): 12 months minimum. User provisioning and deprovisioning: 12 months minimum; retain the provisioning record (what access was granted) separately from access logs at a longer retention period for IAM audit purposes. Database access logs for sensitive data tables: 12 months minimum (PCI DSS for cardholder data), 6 years (HIPAA for ePHI). File integrity monitoring logs: 12 months minimum (PCI DSS). Backup and restore logs: 12 months (retention policy documentation for SOC 2).
What is the most cost-effective architecture for satisfying 12-month and 6-year retention requirements?
Tiered architecture that separates hot (searchable) and cold (compliance archive) storage: (1) Hot tier (0-90 days): SIEM analytics tier — all logs searchable in real-time for detection and investigation. Most expensive storage. (2) Warm tier (90 days - 12 months): compressed log storage in the SIEM's warm tier or object storage with indexing (S3 + Athena, or SIEM's native archive with search capability). Satisfies PCI's 'immediately available for analysis' for the 3-month hot requirement while reducing cost for the remaining 9 months. (3) Cold tier (12 months - 6 years): WORM object storage (AWS S3 with Object Lock compliance mode, Azure immutable blob storage, GCP object retention policy) — satisfies tamper-evident storage requirements at minimal cost (S3 Glacier Instant Retrieval is under $0.005/GB/month). Retrieve via batch restoration for audit or investigation purposes. This three-tier architecture typically costs 1/10th of storing all logs in the SIEM hot tier for 6 years.
How do I document my log retention policy to satisfy auditor requirements?
A compliant log retention policy document should include: (1) Scope: which systems are covered, which log types are covered, and which compliance frameworks the policy is designed to satisfy. (2) Retention schedule table: log type, retention period, storage location, and applicable compliance requirement for each. (3) Storage and access controls: where logs are stored (specific storage systems), who can access them, and how integrity is protected (WORM, cryptographic signing, or hash verification). (4) Review procedures: how often logs are reviewed, what the review process is, and where review records are documented. (5) Policy approval and review: who approved the policy, when it was last reviewed, and the review schedule. (6) Exceptions process: how exceptions to the standard retention periods are requested and approved. An auditor reviewing your log retention program will ask for this document, and they will test your implementation against it — ensure the documented retention periods match the actual log storage configuration.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.