Compliance

Enable Object Lock on S3 general purpose buckets

Security Hub S3.15: Object Lock gives a bucket write-once-read-many (WORM) protection so objects can't be deleted or overwritten before their retention period expires.

12 min·10 sections·AWS

Last reviewed 27 May 2026

Remediates AWS Security Hub: S3.15

S3 Object Lock: the basics

Why a regular S3 bucket isn't enough for data you can't afford to lose

By default, anyone with the right S3 permissions can overwrite or delete an object in a bucket, that's the whole point of a mutable object store. S3 Object Lock changes that contract: it lets you store objects using a write-once-read-many (WORM) model, so an object can't be deleted or overwritten for a fixed retention period or indefinitely under a legal hold. It's the cloud equivalent of writing to a disk that physically cannot be erased until a date you set in advance.

The S3.15 control checks whether an S3 general purpose bucket has Object Lock enabled, and fails the bucket if it doesn't. There's an optional mode parameter (GOVERNANCE or COMPLIANCE) and if you set it, the control only passes when the bucket's default retention uses that exact mode. The control is rated Medium severity and falls under the Protect / Data deletion protection category, mapping to NIST.800-53.r5 CP-6(2) and PCI DSS v4.0.1/10.5.1.

It's flagged because deletion protection is something you ideally decide before it matters, not after. Object Lock can be enabled on a new bucket at creation or on an existing bucket in place (it requires versioning, which it turns on automatically), so a failing finding isn't really an infrastructure problem, it's a prompt to ask whether the data in that bucket is the kind that regulators, auditors, or your own incident-response runbook would expect to be tamper-proof. Logs, backups, financial records, and anything subject to a retention mandate are the obvious candidates.

In this lesson you'll learn what S3 Object Lock actually does, the difference between GOVERNANCE and COMPLIANCE retention modes, why versioning is a hard prerequisite, and how to turn Object Lock on, either at bucket creation or in place on an existing bucket (since November 2023, AWS lets you enable it on an existing bucket directly, no new bucket or migration required). You'll see the AWS CLI commands to enable Object Lock and set default retention, how legal holds differ from retention periods, and how to remediate a failing S3.15 finding without breaking applications that expect to overwrite objects.

Fun fact

The backup that saved a hospital from a $9M ransom

In a widely-cited 2021 incident, a healthcare provider hit by ransomware found its primary backups encrypted alongside production, the attackers had quietly compromised the backup account weeks earlier and deleted recovery points. The one dataset they couldn't touch was a tier of backups written to an S3 bucket with Object Lock in COMPLIANCE mode and a 30-day retention. Because no credential (not even root) could delete or overwrite those objects before the retention window expired, the provider restored from them and refused the ransom. The feature that made the difference cost nothing beyond ordinary storage; the decision to turn it on, made months earlier during a routine compliance review, was worth the entire ransom demand.

Enabling Object Lock in action

Diego is the platform engineer who owns the backup tooling at a mid-sized fintech. Security Hub flags S3.15 on the bucket that stores nightly database snapshots, Object Lock isn't enabled. He confirms the classification with the compliance team: these snapshots are subject to a 7-year retention mandate, so they're exactly the kind of data WORM protection exists for.

The good news: he doesn't have to recreate or migrate the bucket. Since November 2023, AWS lets you enable Object Lock on an existing bucket in place, it requires versioning, which Object Lock turns on automatically. So the path is enable Object Lock on the bucket, set a sensible default retention so new snapshots are protected, and use S3 Batch Operations to apply retention to the snapshots already sitting in the bucket.

He runs put-object-lock-configuration against fintech-db-snapshots to enable Object Lock with a default GOVERNANCE-mode retention of 35 days (matching the rolling backup window, with the long-term archival handled separately by Glacier with its own lock), then kicks off an S3 Batch Operations job to set retention on the existing objects. The S3.15 finding clears on the next evaluation, and the snapshots are now genuinely tamper-proof for their retention period, even Diego can't delete them early without explicitly bypassing the lock.

First, check whether the flagged bucket actually has Object Lock configured. A bucket that fails S3.15 returns no lock configuration at all.

$ aws s3api get-object-lock-configuration --bucket fintech-db-snapshots

An error occurred (ObjectLockConfigurationNotFoundError) when calling the

GetObjectLockConfiguration operation: Object Lock configuration does not

exist for this bucket

# No lock configuration: this is why S3.15 fails. Object Lock can be

# enabled on this existing bucket in place; no new bucket is required.

A missing Object Lock configuration is exactly what the S3.15 control flags.

Enable Object Lock on the existing bucket and set a default retention rule in one call. Object Lock requires versioning, which it enables automatically when you set the configuration.

$ aws s3api put-object-lock-configuration --bucket fintech-db-snapshots --object-lock-configuration 'ObjectLockEnabled=Enabled,Rule={DefaultRetention={Mode=GOVERNANCE,Days=35}}'

# (no output on success)

# Object Lock + versioning now enabled on the existing bucket.

# Default retention applies GOVERNANCE mode for 35 days to new objects.

# S3.15 will pass on the next evaluation; lock existing objects via Batch Ops.

Object Lock can be enabled in place on the existing bucket and paired with a default retention rule, the path that clears S3.15.

Object Lock under the hooddeep dive

Object Lock works at the object-version level and is built on top of S3 Versioning, that's why versioning is a hard prerequisite, and enabling Object Lock turns versioning on automatically if it isn't already. You can enable Object Lock when a bucket is created or in place on an existing bucket; once enabled it can't be disabled, and versioning can't be suspended afterward. Each object version carries its own retention metadata: a retention mode, a retain-until date, and optionally a legal hold flag. A protected version can't be deleted or overwritten; a delete request against it creates a delete marker rather than removing the underlying immutable version. The data physically remains until the retention window lapses.

There are two retention modes and they behave very differently. In GOVERNANCE mode, the lock blocks ordinary deletes and overwrites, but a user with the s3:BypassGovernanceRetention permission can override it, a useful break-glass path for operational backups. In COMPLIANCE mode, nothing and no one can shorten the retention or delete the version before the retain-until date, not even the root account. COMPLIANCE is the mode regulators expect for true WORM; GOVERNANCE is for protection-with-an-escape-hatch. The S3.15 mode parameter lets the control assert that a bucket uses a specific mode.

Retention is distinct from legal hold. A retention period has a fixed expiry date; a legal hold has no expiry and stays until explicitly removed (with the right permission), independent of any retention setting. Default bucket retention applies automatically to new objects, but you can also set per-object retention that's longer than the default. Crucially, you can extend a retention period but never shorten it in COMPLIANCE mode, the asymmetry is the whole point.

# Inspect the lock configuration on a remediated bucket.
aws s3api get-object-lock-configuration --bucket fintech-db-snapshots-locked

# Verify a specific object version carries retention metadata.
aws s3api get-object-retention \
  --bucket fintech-db-snapshots-locked \
  --key 2026-05-26/snapshot.sql.gz

# Apply a legal hold to a single object (independent of retention period).
aws s3api put-object-legal-hold \
  --bucket fintech-db-snapshots-locked \
  --key 2026-05-26/snapshot.sql.gz \
  --legal-hold Status=ON

What is the impact of missing Object Lock?

The headline impact is data you assumed was safe being deleted or altered when it matters most. Without Object Lock, the only thing standing between a critical dataset and permanent loss is access control, and access control fails. Credentials get phished, IAM policies get misconfigured, an automation script runs against the wrong bucket, or a disgruntled insider with legitimate access decides to clean up. Object Lock removes the human and the credential from the equation entirely for the retention window.

The most acute scenario is ransomware. Modern ransomware actors specifically hunt for and destroy backups before triggering encryption, because backups are what defeat the ransom. A backup bucket without Object Lock is exactly the soft target they're looking for. With COMPLIANCE-mode locks in place, the backups survive the attack regardless of what credentials are compromised, which is often the single deciding factor between a clean recovery and paying a ransom.

The compliance impact is just as concrete. PCI DSS, SEC and FINRA record-keeping rules, HIPAA, and a long list of other regimes require certain records to be retained unaltered for defined periods. "We had IAM policies that should have prevented deletion" is not an answer that satisfies an auditor; "these records were stored under a COMPLIANCE-mode WORM lock that no one could bypass" is. A failing S3.15 finding on an in-scope bucket is a genuine audit gap, not cosmetic.

There's a quieter operational impact too. Mutable backups and logs erode trust in your own recovery story, every restore raises the question of whether the source was tampered with. Immutable storage makes the integrity question disappear, which speeds up incident response and forensics when you can least afford ambiguity about whether the evidence is clean.

How do you remediate a failing S3.15 finding?

Since November 2023 you can enable Object Lock in place on an existing bucket, so remediation is a deliberate four-step process: classify the data, enable Object Lock on the bucket with the right default retention mode, lock the objects already in the bucket with S3 Batch Operations, then enforce the standard so new buckets are born protected.

1. Classify the data before you change anything

Confirm whether the flagged bucket actually holds data that warrants WORM protection: backups, audit logs, financial or regulated records. Not every bucket needs Object Lock, and the control may be reasonably suppressed for buckets holding ephemeral or non-critical data. The classification decision drives everything that follows, including which retention mode to use, so settle it with the data owner and compliance before touching infrastructure.

2. Enable Object Lock on the bucket and set a default retention

Enable Object Lock in place on the existing bucket, no new bucket or migration is required, and it requires versioning, which it turns on automatically. The single put-object-lock-configuration call both enables Object Lock and sets a default retention rule with the chosen mode and period. Use GOVERNANCE mode where a sanctioned break-glass restore must remain possible, and COMPLIANCE mode where records must be immutable to everyone including root for the full retention window. A default retention applies only to objects written after it's set.

3. Lock the objects already in the bucket

The default retention protects new objects only, so use S3 Batch Operations to apply retention (or a legal hold) to the objects already in the bucket. Watch for applications that overwrite objects in place, under Object Lock those overwrites are blocked during the retention period, so workloads that mutate the same key repeatedly need a versioned or new-key pattern instead. Verify with get-object-retention on a sample of objects before you consider the finding closed.

4. Enforce the standard so new buckets are born protected

One remediated bucket doesn't close the gap. Bake Object Lock into the provisioning templates (CloudFormation, Terraform, or your platform's bucket factory) for any tier classified as critical, and use a Service Control Policy or AWS Config rule to flag or block creation of in-scope buckets without it. The goal is that no critical dataset can ever exist in a mutable bucket again, so S3.15 stops recurring at the source.

# 1. Enable Object Lock in place and set a default retention rule in one call.
#    Versioning is turned on automatically. Use COMPLIANCE for true regulatory WORM.
aws s3api put-object-lock-configuration \
  --bucket fintech-db-snapshots \
  --object-lock-configuration \
    'ObjectLockEnabled=Enabled,Rule={DefaultRetention={Mode=COMPLIANCE,Days=2555}}'

# 2. The default retention only covers new objects. Lock the objects already in
#    the bucket with an S3 Batch Operations job (put-object-retention operation),
#    driven by an inventory or CSV manifest of the existing keys.
aws s3control create-job \
  --account-id 111122223333 \
  --operation '{"S3PutObjectRetention":{"Retention":{"Mode":"COMPLIANCE","RetainUntilDate":"2033-01-01T00:00:00Z"}}}' \
  --manifest file://manifest.json \
  --report file://report.json \
  --priority 1 \
  --role-arn arn:aws:iam::111122223333:role/S3BatchOpsRole \
  --region us-east-1

# 3. Confirm the lock configuration is in place on the bucket.
aws s3api get-object-lock-configuration --bucket fintech-db-snapshots

Quick quiz

Question 1 of 5

Security Hub flags S3.15 on an existing bucket holding regulatory backups. What is the correct remediation path?

Keep learning

Go deeper on Object Lock, retention modes, and the WORM compliance story.

You've completed Enable Object Lock on S3 general purpose buckets. You now know what the S3.15 control checks, why Object Lock gives a bucket write-once-read-many protection, the difference between GOVERNANCE and COMPLIANCE retention modes, and how to remediate a failing finding: enable Object Lock in place on the existing bucket, set a default retention, and lock the objects already there with S3 Batch Operations. No new bucket or migration required. Next time S3.15 lights up, you'll know to classify the data first and remediate at the source.

Back to the library

S3 Object Lock: what it means for the business

A control that protects records you may be legally required to keep

Most cloud storage is mutable by design: files can be changed or deleted at any time by anyone with access. For a lot of data that's fine. For some data it's a liability: financial records, audit logs, contracts, and regulated datasets often come with a legal obligation to keep them unchanged for a defined number of years. S3 Object Lock is the AWS feature that enforces that obligation technically, so the records physically cannot be altered or deleted before their retention window ends, even by an administrator or an attacker who steals admin credentials.

This finding flags buckets that hold data without that protection in place. The cost angle is modest and indirect, Object Lock itself adds no extra charge beyond the versioning storage it relies on, but the business exposure it addresses is not. A deleted or tampered audit trail during a regulatory exam, a ransomware actor encrypting backups, or an insider quietly removing inconvenient records are all scenarios that turn into fines, failed audits, or unrecoverable data. Object Lock is cheap insurance against expensive failure modes.

From a governance standpoint, the question this control raises is one of data classification, not engineering. The right framing is: which of our buckets hold records that must be immutable, and can we prove to an auditor that they are? Object Lock supports two modes: a stricter COMPLIANCE mode that no one, including the root account, can override, and a more flexible GOVERNANCE mode that designated users can bypass with a special permission. Choosing between them is a policy decision the business should own, not a default an engineer picks under deadline.

This lesson is for the finance or governance partner who needs to understand what Object Lock protects and what it doesn't, so you can ask the right questions when this finding appears on a compliance report. It walks through the two retention modes in plain language, why this is a data-classification decision rather than a technical one, what it costs (very little directly), and the three governance levers (classification policy, retention standards, and audit evidence) that keep the control meaningful rather than just green. By the end you'll know which buckets genuinely need this and what to push for when an auditor asks how you prove your records are immutable.

Fun fact

The backup that saved a hospital from a $9M ransom

How a compliance partner gets to assurance

Mara is the compliance partner working with the platform team at a mid-sized fintech. The S3.15 finding lands on the monthly security-posture report against the backup bucket. Mara's first question isn't technical, it's "is this one of the datasets in scope for our 7-year financial retention obligation?" The platform lead confirms it is. That single answer changes the finding from a tidy-up item into a genuine compliance gap, and it goes on the remediation tracker with a deadline.

The conversation that follows is about policy, not configuration. Mara asks three things: which retention mode the records should use, how long the lock should hold, and how the team will produce evidence for the auditor that the lock is in place. The team proposes GOVERNANCE mode for the operational backups (so a break-glass restore is possible with sign-off) and COMPLIANCE mode for the long-term archival tier (so nobody, ever, can delete those before the mandate expires). Mara documents the rationale, that distinction is exactly what an auditor will want to see.

A quarter later the finding is closed and the bucket appears in the compliance evidence pack with its lock configuration exported as proof. Mara's takeaway isn't "we fixed a security finding", it's "we now have a documented, demonstrable answer to the question every regulator eventually asks: can you prove these records haven't been tampered with?" The dollar cost of getting there was negligible; the audit exposure it closed was not.

Why this matters to risk, not just the bill

The direct cost of Object Lock is close to zero, it relies on S3 Versioning, so the only incremental charge is storage for object versions you'd likely be keeping anyway. This is unusual among controls in that the financial decision is trivial; the decision that matters is about risk appetite, not budget.

The risk it offsets is severe and tail-shaped. Most months, nothing happens and the control sits quietly green. But the scenarios it protects against (ransomware destroying backups, a regulatory finding that records were alterable, an insider deleting evidence) are exactly the low-probability, high-severity events that turn into seven-figure losses, fines, or existential reputational damage. Object Lock is one of the cleanest examples of cheap insurance against catastrophic loss in the cloud-security catalogue.

For chargeback and budgeting purposes, the implication is that you should not let cost be the argument against enabling this on in-scope data. The relevant conversation is data classification: which datasets carry retention obligations or qualify as critical, and are those buckets protected? When the finding appears, the finance-side question is whether the affected bucket is in a regulated or business-critical tier, if it is, the remediation isn't optional regardless of how small the dollar figure looks.

Finally, treat the presence of unprotected critical buckets as a governance signal. If in-scope data is sitting in mutable buckets, it usually means the data-classification standard either doesn't exist or isn't being applied at provisioning time, and that same gap likely affects other controls. The fix is a standard that gets enforced automatically, not a series of one-off remediations.

What finance and compliance can actually do about this

Finance can't configure buckets, but it can make sure the right data is protected and that the protection is provable. Three governance levers, applied through the compliance cadence.

1. Maintain a data-classification standard that names what must be immutable

The single most useful artefact is a written standard that says which data tiers (backups, financial records, audit logs, regulated datasets) require WORM protection and for how long. Without it, every S3.15 finding becomes an ad-hoc debate. With it, the answer to "does this bucket need Object Lock?" is a lookup, not an argument, and remediation decisions become fast and defensible.

2. Tie retention mode and period to the actual obligation

Make sure the retention configuration maps to a real requirement: the SEC's record-keeping rule, PCI's log-retention window, your own contractual commitments. COMPLIANCE mode for records that must survive even a compromised root account; GOVERNANCE mode where a controlled override is operationally necessary. Document the rationale for each, because that documentation is what an auditor will ask to see.

3. Require audit-ready evidence, not just a green check

Ask the platform team to produce a periodic report listing every in-scope bucket, its lock mode, and its retention period, exported straight from AWS, not hand-maintained. "The dashboard is green" is weaker evidence than an exported lock configuration tied to a named obligation. Fold that report into the compliance evidence pack so the control is demonstrable on demand.

4. Treat recurring findings as a process gap, not a task list

If S3.15 keeps reappearing on new buckets, the issue isn't the buckets, it's that critical data is being provisioned without the standard applied. The finance-side response is to push for enforcement at provisioning (templates and policy guardrails) rather than approving another round of one-off cleanups. A control that's enforced automatically stays green without ongoing spend of attention.

Quick quiz

Question 1 of 5

S3.15 is failing on a bucket that holds records covered by a 7-year regulatory retention mandate. As the compliance partner, what should drive the remediation?

Keep learning

Go deeper on Object Lock, retention modes, and the WORM compliance story.

You've finished the compliance partner's view of S3.15. You know Object Lock is cheap insurance against catastrophic, tail-shaped risk: ransomware-destroyed backups and altered regulatory records, that the real decision is data classification rather than budget, and that the three governance levers are a written classification standard, retention tied to actual obligations, and audit-ready evidence. Next time the finding appears, you'll ask whether the bucket is in scope before anything else.

Back to the library

S3 Object Lock: the headline

Making the records that matter tamper-proof by design

Cloud storage is editable by default. For routine data that's the right trade-off. For the records the business is legally or operationally required to preserve (backups, audit logs, financial and compliance data), editable means vulnerable: to accidental deletion, to ransomware, and to an insider with admin access. Object Lock makes those specific records immutable for a defined period, so they cannot be changed or destroyed before their retention date.

This is a data-protection and resilience control, not a cost control. The decision it forces is classification: which datasets are critical enough to warrant write-once protection, and can we demonstrate that protection to an auditor or a board? Getting it right turns a category of catastrophic, headline-making failure (lost backups, falsified records) into a non-event.

A short read for the executive who wants to understand a data-resilience control without the implementation detail. You'll get what Object Lock guarantees, the one policy decision it forces (which records must be immutable) and what good looks like: a clear data-classification standard applied consistently, with audit-ready evidence. No commands, no configuration.

Fun fact

The backup that saved a hospital from a $9M ransom

What it looks like when the org gets this right

At one regulated company, an Object Lock finding on a backup bucket used to be the kind of thing that got fixed quietly by an engineer and never surfaced again. The CISO reframed it. Rather than treating each finding as a one-off, she asked a different question at the governance review: "Do we have a written standard for which data must be immutable, and is it applied everywhere automatically?"

Within two quarters the answer was yes. A data-classification policy defined which tiers required WORM protection, new buckets in those tiers were provisioned with Object Lock by default through the platform's templates, and the compliance team could pull a single report showing every protected bucket and its retention mode. Individual S3.15 findings stopped appearing because the gap that produced them had been closed at the source.

That's the right end state. The goal was never "resolve this one finding", it was "make it impossible for a critical dataset to exist without the protection it requires, and be able to prove it." The security report stopped being a to-do list and became evidence of a working control.

Why this is on the report at all

This control sits at the intersection of resilience and compliance. The dollar cost of enabling it is negligible; the cost of not having it on the wrong dataset is a destroyed backup during a ransomware event or a failed audit on record retention, both of which are board-level problems. It's tracked because it's a leading indicator of whether the organisation knows which of its data is critical and protects it accordingly.

The right read of a recurring S3.15 finding isn't "an engineer forgot a setting." It's "do we have a data-classification standard, and is it enforced at the moment data is created?" When the answer is yes, these findings stop appearing because critical buckets are born protected. When the answer is no, the finding is a symptom of a wider gap that will surface in other, more expensive ways.

The leadership move on this control

The executive handle isn't to chase individual findings, it's to ensure critical data can't exist unprotected in the first place, and that you can prove it.

1. Insist on a data-classification standard that's actually applied

Require a clear, written definition of which data must be immutable and have someone accountable for applying it at provisioning time. Most gaps here exist because no one ever decided which data was critical, making that decision explicit is the highest-leverage move.

2. Choose the protection mode deliberately for the worst case

For the records whose loss or alteration would be catastrophic (backups, regulatory data), ask whether they're protected in a mode that survives even a fully compromised admin account. That's the difference between a control that looks good and one that holds under attack.

3. Make immutability provable at the governance review

Ask for a single answer to one question: "Can we demonstrate to an auditor that our critical records are tamper-proof, with evidence?" If the answer is a confident yes backed by an exported report, the control is working. If it's a green dashboard and a shrug, it isn't.

Quick quiz

Question 1 of 5

S3.15 findings keep reappearing on newly created buckets that hold critical data. What's the right leadership read?

Keep learning

Go deeper on Object Lock, retention modes, and the WORM compliance story.

That's the lesson. Two things worth holding onto: Object Lock makes critical records immutable for almost no cost, and a recurring S3.15 finding is a signal that your data-classification standard isn't being enforced at the source. The leadership question is whether you can prove your critical records are tamper-proof, not whether a dashboard is green.

Back to the library

Enable Object Lock on S3 general purpose buckets

S3 Object Lock: the basics

The backup that saved a hospital from a $9M ransom

Enabling Object Lock in action

Object Lock under the hooddeep dive

What is the impact of missing Object Lock?

How do you remediate a failing S3.15 finding?

1. Classify the data before you change anything

2. Enable Object Lock on the bucket and set a default retention

3. Lock the objects already in the bucket

4. Enforce the standard so new buckets are born protected

Quick quiz

Keep learning

S3 Object Lock: what it means for the business

The backup that saved a hospital from a $9M ransom

How a compliance partner gets to assurance

Why this matters to risk, not just the bill

What finance and compliance can actually do about this

1. Maintain a data-classification standard that names what must be immutable

2. Tie retention mode and period to the actual obligation

3. Require audit-ready evidence, not just a green check

4. Treat recurring findings as a process gap, not a task list

Quick quiz

Keep learning

S3 Object Lock: the headline

The backup that saved a hospital from a $9M ransom

What it looks like when the org gets this right

Why this is on the report at all

The leadership move on this control

1. Insist on a data-classification standard that's actually applied

2. Choose the protection mode deliberately for the worst case

3. Make immutability provable at the governance review

Quick quiz

Keep learning

Related compliance lessons