Retention & log integrity
Retention and log integrity is about two questions an investigator or auditor will ask long after the logs were written: are they still here, and can we trust that nobody changed them? Cloud providers make it easy to fail both. Audit trails often ship with short default windows that can expire evidence before a typical intrusion is even discovered, and by default those logs frequently live in the same account they record, where a compromised administrator can delete the record of their own actions. This sub-topic looks past whether logging is switched on and asks whether the log store itself is durable, immutable, and outside the blast radius of the workloads it watches. We assess retention duration against the longest window you actually answer to, and the tamper-resistance controls that make a log admissible rather than merely present.
Overview
What this check looks like in practice
Logs are only evidence if they are still there and provably unaltered when you need them. Default retention windows are often far shorter than an investigation or an audit period, and logs stored in the same account they record can be deleted by the very identity that was compromised. We check how long logs are kept and how hard they are to tamper with.
Why it matters
In a cloud breach the audit log is usually the primary forensic evidence that exists, which makes it the first thing a capable attacker tries to erase and the first thing an auditor tries to verify. If logs are retained only briefly but an intrusion goes undiscovered for longer, the trail of the initial compromise has already aged out by the time anyone goes looking, and the investigation starts blind. Worse, when logs are stored in the same account and reachable by the same over-privileged identity that was compromised, deleting or altering them can be a single API call, and without integrity validation you cannot demonstrate to an insurer or regulator that what remains is complete. Auditors treat retention and tamper-resistance as a direct control test, so a gap here is an incident-response weakness and an audit finding at the same time.
What we assess
What we look for
- Retention windows sized to the longest applicable requirement -- regulatory minimum, audit lookback, and realistic attacker dwell time -- rather than the provider default
- Audit logs delivered to a dedicated, separately-governed logging account or project, isolated from the workloads they record so a compromise there cannot reach them
- Immutability enforced at the storage layer -- S3 Object Lock, Azure immutable blob (WORM), or GCS locked bucket retention -- not just a policy that says logs should not be deleted
- Cryptographic integrity validation enabled so alteration or gaps are detectable, such as CloudTrail log-file validation digest chains
- Delete and lifecycle permissions restricted to a tiny, monitored set of principals, with no everyday role able to expire or purge the log store
- Lifecycle and cost-tiering rules reviewed to confirm they archive rather than silently delete logs before the retention window closes
- Logs encrypted at rest with a controlled key, and the read path to them least-privilege and itself audited
- MFA-delete or equivalent protection on the log archive, and separation of duties so the identity that writes logs cannot destroy them
Across your clouds
AWS, Azure & Google Cloud
AWS
CloudTrail with log-file validation (SHA-256 digest chains) delivered to a dedicated log-archive account created by Control Tower or Organizations; the destination S3 bucket protected with Object Lock in compliance mode (WORM) and a restrictive bucket policy, encrypted with a KMS key the workload accounts cannot use. CloudWatch Logs retention is set explicitly per log group rather than left at Never Expire, and CloudTrail Lake event data stores can retain events for extended multi-year lookback (up to ten years).
Azure
Activity logs and resource Diagnostic settings exported to a Log Analytics workspace with the interactive and long-term Archive tiers configured for the required duration, and/or to an immutable Storage account using time-based retention policies or legal hold (WORM). Resource locks and Azure RBAC restrict who can alter retention or delete the log store, and storage-service encryption with a customer-managed key in Key Vault protects logs at rest.
Google Cloud
Cloud Audit Logs routed through aggregated log sinks to a separate, restricted logging project, landing in a Cloud Storage bucket with a locked retention policy (Bucket Lock WORM) or in a Cloud Logging log bucket with a configured retention period. Object versioning and CMEK protect integrity and confidentiality, and IAM on the sink destination is scoped so workload identities cannot delete or shorten retention on the archive.
Example finding
Central CloudTrail logs retained 90 days in the same account, with delete permitted and no Object Lock
Risk: The trail can expire well inside the window many intrusions stay undiscovered, so the record of an initial compromise may be gone before an investigation begins. Because the bucket lives in a workload account and any administrator role can delete objects, an attacker who gains that access can erase the evidence of their own activity, and with no log-file validation or immutability there is no way to demonstrate to an auditor or insurer that the remaining logs are complete and unaltered.
Fix: Route the organization trail to a dedicated log-archive account, enable log-file validation, and store logs in an Object Lock (compliance-mode) bucket with a retention period covering your longest audit and dwell-time window.
Remediation
How to close it
- 1 Determine the governing retention floor by taking the longest of your regulatory minimum, your audit lookback period, and a realistic attacker dwell-time window, and set that as the target for every log store.
- 2 Consolidate audit logs into a dedicated logging account or project that is separately governed, so no workload identity can reach the archive.
- 3 Turn on storage-layer immutability -- S3 Object Lock in compliance mode, Azure immutable blob time-based retention, or GCS Bucket Lock -- so retained logs cannot be altered or deleted before the window closes.
- 4 Enable cryptographic integrity validation where the provider offers it (CloudTrail log-file validation) so tampering or gaps become detectable.
- 5 Restrict delete, lifecycle, and retention-change permissions to a minimal, monitored set of principals, and alert on any attempt to modify the log store.
- 6 Review lifecycle and cost-tiering rules to confirm they transition logs to cheaper archival storage rather than deleting them, and encrypt the archive with a controlled key.
Compliance evidence
Questions
How long do we actually need to keep logs?
Long enough to satisfy the strictest thing you answer to -- take the longest of your regulatory minimum (PCI-DSS expects at least a year of audit history with the most recent months immediately available; HIPAA requires six years of retention for required documentation), your audit lookback period, and a realistic time-to-discovery for an intrusion. We assess your configured retention against that combined floor rather than the provider default, and flag where cost-tiering or lifecycle rules would delete evidence before it expires.
Isn't a bucket policy that blocks deletes good enough?
No. A policy can be changed or overridden by anyone with permission to edit it, so it protects logs only until an attacker reaches that permission. Storage-layer immutability -- Object Lock, immutable blob, or locked bucket retention -- enforces write-once-read-many at the platform level so the objects genuinely cannot be altered or deleted for the retention period, even by an account administrator. That distinction is what makes a log defensible as evidence.
Do you verify integrity by reading our log contents?
No. The review is read-only and configuration-focused: we confirm that integrity validation is enabled, that immutability and retention are set correctly, that the archive sits outside the workload blast radius, and that delete permissions are tightly held. We establish that the trail is durable and tamper-resistant without mining what the logs contain.
More in logging & monitoring
See where you stand
A health check finds and prioritizes real exposure. It is not a certification or a promise you will never be breached — closing the findings is what changes your risk.
Related domain surfaces
The rest of what we assess
The same read-only assessment covers every domain — see what else it looks at.
