{"id":74985,"date":"2026-09-15T00:30:46","date_gmt":"2026-09-15T06:30:46","guid":{"rendered":"https:\/\/www.scalahosting.com\/blog\/?p=74985"},"modified":"2026-09-15T00:30:47","modified_gmt":"2026-09-15T06:30:47","slug":"object-lock-compliance-vs-governance","status":"publish","type":"post","link":"https:\/\/www.scalahosting.com\/blog\/object-lock-compliance-vs-governance\/","title":{"rendered":"Object Lock Compliance vs Governance Mode: Getting Ransomware-Proof Backups Right"},"content":{"rendered":"\n

Both modes lock a storage bucket into write-once-read-many (WORM) behavior; the difference is who can break the lock early. Governance mode can be overridden by credentials that hold special bypass rights. Compliance mode cannot be overridden by anyone, including your cloud account’s root user, until the retention period expires. For production backups, rehearse your settings in governance mode, then run compliance mode. The choice works the same on Amazon S3 and Backblaze B2, and SPanel<\/a> delivers backups into either.<\/p>\n\n\n\n

Why the mode matters more than the lock<\/strong><\/h2>\n\n\n\n
\"Object<\/figure>\n\n\n\n

Immutable backups exist because ransomware hunts backups first. A 2024 Sophos study<\/a> of 2,974 organizations hit by ransomware found attackers targeted backups in 94% of incidents and succeeded 57% of the time, with median recovery costs of $3 million when backups fell versus $375,000 when they held. Object Lock answers that threat by refusing deletion until a retention clock runs out.<\/p>\n\n\n\n

But immutability is a contract with fine print, and the retention mode is the fine print. Pick governance mode and the contract carries an escape clause for anyone holding the right permission. Pick compliance mode and there is no escape clause at all, for attackers and for you alike. Getting backups right<\/a> means knowing exactly what each mode refuses to do, and for whom.<\/p>\n\n\n\n

What the two modes share<\/strong><\/h2>\n\n\n\n

Everything else about Object Lock behaves identically. A retention period protects an object version for a fixed time, and a default retention on the bucket applies one automatically to every new upload, counted from the moment it lands. Locks attach to individual versions, so a new backup doesn’t alter the previous one’s configuration. Attempts to permanently delete a locked version are refused; on S3, a simple delete without a version ID removes nothing either, merely stacking a removable delete marker on top.<\/p>\n\n\n\n

Per AWS’s<\/a> and Backblaze’s<\/a> documentation, retention periods can always be extended, neither provider charges a fee for the lock beyond the storage it holds in place, and enabling Object Lock on a bucket is permanent on both platforms. The two modes diverge on exactly one question: can anybody loosen the lock before it expires?<\/p>\n\n\n\n

Governance mode: a lock with a master key<\/strong><\/h2>\n\n\n\n

Governance mode protects objects from everyone except users who hold bypass rights. On Amazon S3, overriding or removing a governance lock requires the s3:BypassGovernanceRetention permission plus an explicit x-amz-bypass-governance-retention:true header on the request, a two-step design meant to prevent accidental overrides. One caution straight from AWS’s docs: the S3 console sends that header by default, so a console user who holds the permission deletes governance-locked objects as if the lock weren’t there. On Backblaze B2, the equivalent is an application key capability<\/a> called bypassGovernance, required for shortening or removing a governance-mode retention.<\/p>\n\n\n\n

Read that threat model carefully. Governance mode fully protects against the credential that matters most in a hosting scenario, the scoped backup key stored on your server, and against everyday accidents like a cleanup script pointed at the wrong folder. It does not protect against an attacker who compromises a cloud identity holding bypass rights. If any live credential can loosen the lock, stealing that credential loosens the lock.<\/p>\n\n\n\n

That is why AWS itself positions governance mode as the place to test retention settings before creating compliance-mode locks. It is a rehearsal space with adult supervision, not a vault.<\/p>\n\n\n\n

Compliance mode: a lock with no key at all<\/strong><\/h2>\n\n\n\n

In compliance mode, a locked version cannot be overwritten or deleted by any user, the account root included. The mode cannot be changed and the period cannot be shortened; AWS states that the only way to remove compliance-locked data before its date is to delete the entire AWS account. Backblaze matches the posture: compliance-mode retention cannot be removed by any user, and retention dates move in one direction only, later.<\/p>\n\n\n\n

This is the variant regulators trust and is often a compliance requirement for organizations dealing with large volumes of sensitive information.<\/p>\n\n\n\n

The strength cuts both ways. A long retention period or a large number of backups increase storage bills, and a lock placed on the wrong data is a lock you live with. Compliance mode punishes sloppy setup precisely because it’s set in stone, so it’s important to know what you’re doing before you start using it.<\/p>\n\n\n\n

Why a server breach cannot break the lock<\/strong><\/h2>\n\n\n\n

The credential you are most likely to lose is the scoped backup key sitting on your server. Both modes stop that key cold, so a stolen server key cannot loosen the lock. Compliance mode goes further and stops a stolen cloud-admin identity too. SPanel is deliberately never handed a credential that can change a retention mode, so even a full server takeover cannot touch a compliance-locked backup.<\/p>\n\n\n\n

Side by side<\/strong><\/h2>\n\n\n\n
<\/th>Governance mode<\/th>Compliance mode<\/th><\/tr><\/thead>
Delete or overwrite before expiry<\/td>Only with bypass rights (S3: permission plus explicit header; B2: bypassGovernance capability)<\/td>No one, including account root<\/td><\/tr>
Shorten or remove the retention<\/td>Yes, with those rights<\/td>Never<\/td><\/tr>
Extend the retention<\/td>Yes<\/td>Yes<\/td><\/tr>
Change the mode on a locked version<\/td>Yes, with bypass rights<\/td>No<\/td><\/tr>
Stops a stolen server backup key<\/td>Yes<\/td>Yes<\/td><\/tr>
Stops a stolen cloud-admin identity<\/td>No<\/td>Yes<\/td><\/tr>
Built for<\/td>Rehearsals and reversible tests<\/td>Production backups and regulated data<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Legal hold: the third setting, briefly<\/strong><\/h2>\n\n\n\n

Both platforms also offer a legal hold: the same WORM protection with no expiry date, applied per object and removable only by a user with the specific permission. Holds are independent of retention periods, so an object can carry both, and the protection survives until the last of the two lapses. Holds exist for audits and litigation, where the requirement is “until further notice.” Backup rotation wants predictable expiry, so retention periods do the daily work.<\/p>\n\n\n\n

The decision for backups<\/strong><\/h2>\n\n\n\n

Use governance mode for exactly one thing: proving your configuration. Create a bucket, set a short governance retention, point SPanel at it, attempt deletions with different credentials, run a restore. When the behavior matches expectations, set the bucket’s default retention to compliance mode with your production window and let the schedule carry on. New uploads inherit the new default; versions locked during the rehearsal keep their original settings until they expire.<\/p>\n\n\n\n

Window sizing is the second half of the decision. A month of recovery points covers the gap between an intrusion and its discovery for most small businesses; regulated industries usually need far longer. Extension is always available and shortening never is in compliance mode, so start modest and grow deliberately.<\/p>\n\n\n\n

Where SPanel fits<\/strong><\/h2>\n\n\n\n

SPanel treats locked storage as a destination. Amazon S3 (or any S3-compatible provider) and Backblaze B2 are supported backup destinations, two of the four an SPanel server can run at once, and the whole backup<\/a> system is included with every ScalaHosting managed VPS. The retention mode is chosen on the bucket, inside your AWS or Backblaze account: SPanel uploads on schedule, and the bucket seals whatever arrives. The panel needs no credential that can change the mode, and it is never given one.<\/p>\n\n\n\n

Setup is covered step by step in our guides to ransomware-proof SPanel backups with S3 Object Lock and Backblaze B2 and SPanel.<\/p>\n\n\n\n

Before you commit<\/strong><\/h2>\n\n\n\n
    \n
  1. Rehearse on a test bucket with governance mode or a one-day compliance window.<\/li>\n\n\n\n
  2. Attempt a deletion with the backup key, then with an admin identity. The first refusal shows the lock working; what happens with the second is exactly the difference between the modes.<\/li>\n\n\n\n
  3. Restore one file and one database through SPanel to prove the return path.<\/li>\n\n\n\n
  4. Set the bucket default to compliance mode with your production window.<\/li>\n\n\n\n
  5. Keep bypass rights out of day-to-day identities, add a lifecycle rule for expired versions, and review the window quarterly.<\/li>\n<\/ol>\n\n\n\n

    FAQ<\/strong><\/h2>\n\n\n\n

    Q:<\/strong> Which Object Lock mode should I use for ransomware protection?<\/strong><\/p>\n\n\n\n

    A:<\/strong> Compliance mode in production. Governance mode exists to protect against mistakes and to let you test settings safely; an attacker holding bypass-capable credentials walks through it by design.<\/p>\n\n\n\n

    Q:<\/strong> Can the AWS root user delete compliance-locked backups?<\/strong><\/p>\n\n\n\n

    A:<\/strong> No. AWS’s documentation is explicit that no user, root included, can delete or overwrite a compliance-locked version, and that the only early exit is deleting the AWS<\/a> account itself. Backblaze B2’s compliance mode likewise refuses every user.<\/p>\n\n\n\n

    Q:<\/strong> Can attackers really bypass governance mode?<\/strong><\/p>\n\n\n\n

    A:<\/strong> Only by obtaining credentials that carry the bypass rights: s3:BypassGovernanceRetention on S3 or the bypassGovernance capability on a B2 application key. Modern intrusions go after exactly those identities, which is why governance mode should be treated as accident protection rather than attack protection.<\/p>\n\n\n\n

    Q:<\/strong> Can I change the retention period after it is set?<\/strong><\/p>\n\n\n\n

    A:<\/strong> Extending works in both modes with ordinary retention permissions. Shortening or removing works only in governance mode, and only with bypass rights. Compliance mode allows no reduction by anyone.<\/p>\n\n\n\n

    Q:<\/strong> Do the two modes cost different amounts?<\/strong><\/p>\n\n\n\n

    A:<\/strong> No. Neither Amazon S3 nor Backblaze B2 charges for the lock itself in either mode; you pay for the storage that locked versions occupy until retention expires. The real difference is flexibility, and compliance mode locks in your mistakes along with your backups.<\/p>\n\n\n\n

    Q:<\/strong> Does SPanel require a particular Object Lock mode?<\/strong><\/p>\n\n\n\n

    A:<\/strong> No. SPanel writes backups into whatever bucket you give it, and the mode is bucket configuration inside your storage account. Whichever you choose, keep the credentials SPanel uses free of retention and bypass rights.<\/p>\n\n\n\n

    Locks that don’t negotiate<\/strong><\/h2>\n\n\n\n

    Ransomware works because deletion is usually possible for whoever asks with the right stolen key. Compliance mode removes the possibility, and SPanel, included with every ScalaHosting managed VPS, keeps the locked bucket fed on schedule. Rehearse once in governance mode, commit to compliance mode, and the conversation with the next intruder is over before it starts.<\/p>\n\n\n\n