If you enabled S3 Object Lock on your audit log bucket and selected Governance mode, a user with one IAM permission can still delete those logs. The Amazon S3 console sends the override header by default, so from the console it is not even a deliberate act. It is a normal delete that succeeds.

There is a second version of the same mistake. If you enabled Object Lock on a bucket that already held objects, those existing objects are not protected. Only new writes pick up the default retention.

Both cases produce the same outcome: a team that believes it has immutable audit logs and does not. Both are fixable, and this post ends with how.

What is S3 Object Lock?

S3 Object Lock is an Amazon S3 feature that prevents object versions from being deleted or overwritten for a fixed period or indefinitely. It implements write-once-read-many (WORM) storage: once a record is written, the storage layer itself refuses to modify or remove it until the retention period expires.

Four structural facts before the modes make sense:

Versioning is required, and how you get it depends on the path. When you create a bucket with Object Lock enabled, versioning is enabled automatically. When you enable Object Lock on an existing bucket, versioning is a separate prerequisite step you perform first. Object Lock operates on object versions, each version carries its own retention properties, and uploading a new version does not release the lock on prior ones. General-purpose buckets only, not directory buckets.

Object Lock cannot be disabled once enabled on a bucket. One-way decision at the bucket level.

Retention overrides lifecycle rules. If a lifecycle policy expires objects after 90 days and retention runs seven years, retention wins. Lifecycle expiration does not apply to objects still under retention.

Existing buckets are supported. Since November 20, 2023, Object Lock can be enabled on an existing bucket through the console, CLI, API, or SDKs, with no AWS Support engagement. The same release added S3 Replication support for Object Lock buckets, which matters later.

What is the difference between Governance mode and Compliance mode?

Both enforce a retention period. The difference is who can override it.

Governance mode protects objects from deletion by most users, but a principal holding the s3:BypassGovernanceRetention permission can alter retention settings or delete the object. The request must include the header x-amz-bypass-governance-retention:true, and the Amazon S3 console includes that header by default.

Compliance mode protects the object version absolutely for the duration of the retention period. No user can overwrite or delete it, including the root user of the AWS account. The retention mode cannot be changed and the retention period cannot be shortened. Per AWS's documentation, the only way to delete an object under Compliance mode before its retention date expires is to delete the associated AWS account.

The fifth row is the part most write-ups omit. A bypass user does not have to delete anything to defeat Governance mode. They can issue a PutObjectRetention request with empty parameters, removing the retention period outright and leaving the object in place. Nothing appears destroyed. The protection is simply gone.

Why does the distinction matter for audit logs?

Because of one question an auditor asks, which we covered in SOC 2 Audit Logging for File Transfers: show me the mechanism that prevents a compromised administrator from modifying or deleting the logs that record their actions.

Governance mode does not answer it. The administrator is exactly the principal likely to hold the bypass permission, and a privileged account acting maliciously or being compromised is the threat you are defending against. A control a privileged user can switch off is not a control against a privileged user.

Compliance mode answers it, because enforcement does not live in your application, your IAM policy, or your operational discipline. It lives in the storage layer, below anything your systems can reach.

The claim changes shape as a result. "We retain audit logs for seven years" is a policy statement. "These records cannot be deleted by anyone, including our own root account, until 2033" is a property of where the bytes sit. The second survives an adversarial reading.

One precision point, because it cuts against the easy version of this argument. Amazon S3 Object Lock has been assessed by Cohasset Associates for SEC Rule 17a-4(f), FINRA Rule 4511, and CFTC Regulation 1.31. In that assessment, Cohasset's opinion is that Object Lock meets the SEC non-rewriteable, non-erasable requirement with retention applied in either Compliance mode or the less restrictive Governance mode.

So the argument for Compliance mode is not that regulation forbids Governance. It is that the compromised-administrator threat model forbids it. Those are different claims and only the second one holds.

Worth knowing that this finding does not generalize across vendors. Cohasset's assessment of MinIO Object Storage, for example, covers the product specifically when Object Lock mode is set to Compliance. If you are running an S3-compatible backend, read that vendor's assessment rather than assuming Amazon's conclusions apply.

Immutability alone does not meet the rule

A point that gets lost when teams treat Object Lock as the finish line. Cohasset's assessment of Amazon S3 also addresses the SEC requirement to store a duplicate copy of records separately from the original, which is satisfied through Cross-Region Replication rather than by Object Lock.

Non-erasability and redundancy are separate requirements. A single immutable copy meets one of them. If you are storing records under a recordkeeping rule rather than for internal assurance, replicate them, and note that replication for Object Lock buckets arrived alongside the existing-bucket support in November 2023.

What does Compliance mode cost you?

It is unforgiving, which is the point, but choose it deliberately.

You are committing to the storage bill. Data under seven-year Compliance retention will be stored for seven years whether you still want it or not. No early exit. Plan capacity for high-volume event streams.

Mistakes are permanent. Write the wrong data, or the right data with a typo'd retention period, and it stays. You can guard the typo case: the s3:object-lock-remaining-retention-days condition key in a bucket policy enforces minimum and maximum allowable retention, which prevents someone setting seventy years instead of seven.

Test in Governance mode first. AWS explicitly recommends validating retention settings in Governance mode before creating a Compliance-mode retention period. Prove the pipeline writes what you expect, at the cadence you expect, with the retention you intend, then move.

Keep the bypass permission scarce. Even during Governance-mode testing, s3:BypassGovernanceRetention should go to as few principals as possible, and its use should be monitored through CloudTrail.

What is a legal hold, and when do you use it?

A legal hold is a separate Object Lock mechanism with no retention period attached. It freezes an object version indefinitely until someone with the appropriate permission explicitly removes it.

Retention periods and legal holds are independent and can apply to the same object version. Retention answers "keep this until a date." Legal hold answers "keep this until I say otherwise," which is what litigation or an open investigation requires when the end date is unknowable in advance.

Practical pattern: Compliance-mode retention as the baseline, legal hold applied selectively when a matter opens.

How do you verify what you actually have?

Five checks.

1. Confirm the retention mode on a real object. Not the bucket default, an actual written object:

aws s3api get-object-retention \
  --bucket your-audit-bucket \
  --key path/to/record.jsonl \
  --version-id <version>

If Mode returns GOVERNANCE, you have a retention policy, not immutability.

2. Run the same check against your oldest objects. If Object Lock was enabled on an existing bucket, everything written before that moment is unprotected unless someone went back and applied retention. Default retention applies to new objects only. Find the enablement date, pick an object written before it, and see what get-object-retention returns. This one takes longer than check one because you have to establish the date first.

3. Audit who holds s3:BypassGovernanceRetention. Under Governance mode, that is the list of principals who can delete or silently unlock your evidence. Most organizations have never enumerated it.

4. Test your retrieval tooling against a delete marker. Delete markers are not WORM-protected and can be placed regardless of retention period or legal hold. The underlying locked version survives and remains retrievable, so this is not evidence destruction, but an ordinary read reports the object as gone. Place one in a test bucket and confirm your export or investigation tooling still finds the version underneath. MinIO behaves the same way.

5. Try to delete something. In a test bucket, with a Compliance-mode object under retention, attempt a delete and confirm it fails. A control you have never exercised is a control you are assuming.

What if check one comes back GOVERNANCE?

You can fix it, and the fix runs in the direction you want.

An object under Governance-mode retention can be changed to Compliance mode with a PutObjectRetention request specifying COMPLIANCE, provided the caller holds s3:BypassGovernanceRetention and sends the bypass header. The same permission that makes Governance mode weak is what lets you upgrade out of it.

The reverse does not work. Once an object version is under Compliance mode, the mode cannot be changed and the retention period cannot be shortened. The path is one-way, which is the correct asymmetry.

For objects already written, S3 Batch Operations applies retention across large sets, up to billions of objects in a single job, which is the practical tool for the existing-bucket gap in check two. Set the bucket default to Compliance for everything new, then run Batch Operations backward across what was already there.

How MnemoShare handles this

MnemoShare exports audit events to customer-managed object storage with Object Lock enabled in Compliance mode, with configurable retention. Records are written outside the application's write path, so the application cannot alter its own evidence after export.

Object Lock semantics vary across S3-compatible implementations. MinIO carries its own Cohasset assessment covering Compliance mode, and assessments exist for several other S3-compatible platforms, but support elsewhere ranges from partial to absent. If you are deploying against a non-AWS backend, confirm Compliance-mode behavior with your storage vendor before treating the guarantee as equivalent.

The storage layer is one half. The other half is that each exported record carries a SHA-256 hash computed over a deterministic serialization and chained to the previous record, so a third party can recompute the chain and detect any gap, reorder, or modification independently. Object Lock prevents records from being deleted. The hash chain proves the set is complete and unaltered.

More detail is on our security page and in our audit and compliance capabilities.

The short version

If the requirement is "keep records for N years," Governance mode is a reasonable and more forgiving choice. If the requirement is "prove these records cannot have been altered, including by us," Governance mode does not meet it and Compliance mode does.

Run check one against your own audit bucket. It takes about thirty seconds and does not require anyone's permission. If it returns GOVERNANCE, you now know both what that means and how to change it.

See how the audit export works