Object Lock has two retention modes, and the choice between them is usually made in the ten seconds it takes to create a bucket, by whoever happened to be setting up the repository. Governance and compliance protect a stored object in the same way from the outside. They differ entirely in who can undo that protection, and that difference decides what happens when a retention period turns out to be wrong.
The mode is not a security dial running from medium to high. It is a statement about which mistakes the organization would rather live with. Governance keeps a documented escape route and accepts that it can be abused. Compliance removes the escape route and accepts that an error made once is carried until the retention date passes.
What the mechanism protects against in general is covered in the wider discussion of what Object Lock guarantees. What follows is only the mode decision and the operational consequences that flow from it.
Object Lock is enabled when the bucket is created, and versioning comes with it. That is the first irreversible step, since a bucket without Object Lock cannot generally be converted into one later. The mode itself appears in two places. A bucket can carry a default retention mode and period applied to every new object, and an individual object version can carry its own retention set at upload or afterward.
Most backup software writes retention per object, which means the bucket default is often a backstop rather than the setting in force. Both layers need reading before any conclusion is drawn about what a repository is holding, because a bucket configured for governance can hold objects written in compliance mode and the object always wins.
Legal hold sits outside this. It has no date and no mode, it is applied and removed by a specific permission, and it stays until someone clears it. That makes it a useful instrument during an investigation and a poor substitute for a retention policy.
In governance mode, a retention period can be shortened or removed by any identity holding the permission to bypass governance retention, sending a request that explicitly asks for the bypass. Two things matter operationally. The bypass is a distinct permission rather than a property of being an administrator, and the request that uses it is a normal API call that appears in the access log.
So governance mode is only as strong as the list of identities holding that permission. In a small environment the list is short, which is an advantage, and it tends to be short because nobody has looked at it rather than because someone curated it. The backup software's own account almost never needs the bypass permission, since deleting protected data early is not part of a backup job, which makes it a good example of keeping the service account narrow.
The practical control is therefore not the mode by itself. It is the answer to a question the team can ask today. Which identities can bypass governance retention on this bucket, when was that granted, and does an alert fire when a bypass request is made. If the answer is unknown, governance mode protects less than the configuration suggests.
| Situation | Under governance mode | Under compliance mode |
|---|---|---|
| Retention period set far too long | Shortened by an identity with the bypass permission | Cannot be shortened, the capacity is committed until expiry |
| Data must be removed for a legal or contractual reason | Possible, with a logged bypass request | Not possible through the API before the retain until date |
| Administrative credentials are compromised | Deletion possible if the bypass permission was granted | Deletion not possible by any identity, including the account owner |
| Hardware refresh before retention expires | Old objects can be cleared once copied | Source objects stay until expiry, so both systems coexist |
| Retention needs to be longer than first set | Extended at any time | Extended at any time, since only shortening is blocked |
The row that catches teams is the hardware refresh. Compliance mode objects cannot be deleted before their retention expires, so a repository migration does not free the old system on the day the copy finishes. Copying data to a new platform creates new objects there, and retention has to be established again on the target, while the source keeps its own locks running to their original dates. A three year retention chosen casually can mean a three year overlap between an old array and its replacement.
The same arithmetic applies to capacity. Under compliance mode the storage a retention period implies is not an estimate that can be revised later, it is a commitment, which is why the mode belongs in the same conversation as how the repository was sized rather than being treated as a security setting with no cost attached.
Retention periods are set wrong in both directions, and the modes respond differently to each. A period that is too short is equally weak under both, since the protection simply ends earlier than the recovery plan assumes, and neither mode has an opinion about whether the number was sensible.
A period that is too long is where the modes separate. Under governance, the correction is a bypass request, logged and reversible in the sense that it can be done at all. Under compliance, there is no correction. An accidental extra digit, a value entered in days when the field expected years, or a policy applied to a bucket receiving hourly incrementals rather than monthly fulls, all become facts for the duration. This is why a new compliance bucket is worth testing with a short retention first, verifying that a delete request fails as expected, before the real period is configured.
Mode also changes how an expiry is handled at the other end, since a governance object can be cleaned up early while a compliance object stays until the date arrives. That distinction shapes what happens when the retention lock expires and how quickly capacity comes back.
ARTESCA provides immutable backup storage through S3 Object Lock, and both retention modes behave as the S3 API defines them. Object Lock is enabled at bucket creation, retention can be set by default on the bucket or per object by the backup software, and a compliance mode retention period can be extended but not shortened or removed.
Because ARTESCA runs on infrastructure the customer operates, the consequences of a compliance decision land on hardware the customer owns. Capacity committed by a long retention is capacity in the customer's own racks, and a migration or refresh has to account for locked objects that will still be present on the source system after the copy is complete.
Mode selection is per bucket rather than per system, so a single deployment can hold a compliance bucket for the copies that must be beyond reach and a governance bucket for the working set where operational correction is still wanted.
Treat the decision as one made per bucket, driven by what the bucket holds. A bucket receiving the long term copies that would be used after a serious incident is a reasonable candidate for compliance mode with a retention period chosen conservatively. A bucket holding short cycle operational restore points is usually better in governance mode, where a sizing mistake is recoverable.
Record four things for every bucket: the mode, the retention period, the date the bucket was created and the reason the mode was chosen. Reasons are forgotten faster than settings, and the person who has to justify a large compliance bucket to a finance review eighteen months later will be a different person.
Review the identities that can bypass governance retention on a schedule, quarterly is enough, and confirm that a bypass request produces a visible alert rather than only a log entry. Before enabling compliance mode on a new bucket, write down the expiry date of the first object it will hold and check that the hardware expected to be in service on that date is the hardware being bought now.