7 Audit Log Integrity Controls That Stop Tampering
Attackers who gain an admin credential usually try to erase the evidence before anything else, which makes audit log integrity a survival property, not a compliance checkbox. The short answer for defenders: ship logs to storage that cannot be rewritten, verify them with cryptographic digests, and gate the few remaining delete paths behind factors a stolen key cannot satisfy. AWS CloudTrail enables log file integrity validation by default on new trails and begins delivering signed digest files in about an hour, so the cheapest control is often already half-deployed and merely unverified. This guide covers seven controls in the order that gives you the most protection for the least operational pain, with the trade-offs that vendor documentation actually states.
Why Logs Get Deleted First
When an intruder lands in a workload, logging is high on the target list because destroying the timeline destroys the investigation. A trail that lands in a writable bucket behind ordinary IAM permissions is one API call away from disappearing, and an attacker with the right role can also stop the trail itself or repoint delivery. Three failure modes repeat across incidents: deletion of delivered objects, suspension of the recording source, and rewriting of configuration so future events never reach storage. The controls below map one-to-one against those failure modes. None of them requires exotic tooling, but they do require separating who can write logs from who can ever remove them, the same separation-of-duties logic behind break-glass access controls.
Verify Signed Digest Files
Start with proof rather than locks. Log file integrity validation on a trail causes CloudTrail to publish digest files alongside the logs, and each digest records hashes of the log files delivered in the window. When you need to prove that an archived file is byte-for-byte what the service delivered, you run the validation command from the CloudTrail CLI against the bucket and read the result. The digest chain turns your archive into evidence: even if someone replaced a log object, the replacement will not match the signed digest you kept elsewhere. Two practical notes from the field. Keep a copy of the digests in a second account, because digests stored next to the logs they vouch for share the same blast radius. And treat a failed validation as an incident trigger, not a retry, because the failure itself is the signal worth paging on. If you have not yet looked at which events your trails record, the exercise pairs well with webhook security controls for adjacent delivery paths.
Lock Objects With WORM
The second layer is write-once-read-many storage. Per the Amazon S3 documentation, a version locked in compliance mode cannot be deleted or overwritten by anyone, including the account root user, and the retention period cannot be shortened once set. That is exactly the property you want for a log archive: even total compromise of the account’s credentials does not unlock yesterday’s evidence. Object Lock requires bucket versioning, and it protects individual object versions, which means new versions can still be written on top of a locked one but the locked version survives. Choose the retention mode deliberately. Governance mode lets privileged users with a bypass permission remove locks, which is convenient for mistakes and equally convenient for an attacker who holds that permission; compliance mode removes the escape hatch entirely, which is why it belongs on the log archive. Set a default retention period at the bucket level so every delivered log inherits the lock automatically, and size the period to your longest realistic investigation horizon rather than your shortest compliance requirement.
Gate Deletes With MFA
For buckets where WORM does not fit, MFA delete raises the cost of every destructive operation. The mechanics matter for planning: only the bucket owner root account can enable MFA delete, and every permanent version delete then needs a second factor from an approved device, supplied as a serial number plus the current code in the same request. The design forces an attacker to possess not just credentials but something physical or virtual outside the account. The trade-offs are real and documented: you cannot enable it from the console, only the CLI or API, and it cannot coexist with lifecycle configurations, so buckets that rely on lifecycle expiration are not candidates. In practice teams accept the friction precisely because the operations it slows down, permanent version deletes and versioning-state changes, are rare and dangerous by definition. Treat it as a guardrail for the log archive bucket tier where you need deletability eventually, but not today.
Lock Azure Retention Policies
The same discipline exists on Azure. Immutable blob storage supports time-based retention policies and legal holds, and the lifecycle is two-stage on purpose: a policy starts unlocked for testing, then you lock it. Per Microsoft’s documentation, a locked time-based retention policy cannot be deleted, and you can extend its retention period but never shorten it. Microsoft recommends locking after a short test window, on the order of a day, because the unlocked state is meant for validation rather than steady operation. If your platform logs or exported activity data land in Azure, the playbook transfers directly: unlocked policy while you confirm delivery and alerting, then lock, then record the lock event itself as your evidence that the archive became tamper-evident from that moment on.
Defense-in-Depth Checklist
Run the deployment in this order; each row states what the control blocks and roughly what it costs you.
| Control | What it blocks | Operational cost |
|---|---|---|
| 1. Enable trail digest validation | Undetected log modification | Near zero; verify monthly |
| 2. Copy digests to a second account | Digest loss with the archive | One replication job |
| 3. Object Lock compliance retention on the archive | Deletes by any user, including root | No early deletes, ever |
| 4. MFA delete on versioned buckets | Programmatic version deletes | Root-only setup; no lifecycle |
| 5. SCP denying trail stop or delete | Trail suspension by a member account | Org policy review |
| 6. Lock Azure retention policies | Policy removal or shortening | One lock step after testing |
| 7. Quarterly validation drill | Silent control decay | An hour per quarter |
The drill in row seven is the one teams skip and later regret: run the digest validation, attempt a test delete you expect to fail, and confirm the failure appears in monitoring. A control you have never seen fail is a hypothesis, not a control. Review method: vendor documentation cited below, reviewed October 2026; the checklist itself is this article’s own working method, not a vendor template.