A retention schedule in a policy document does not stop anyone deleting a file.

Read a typical retention line closely and it turns out to be underspecified. "Retain contracts for the required term" leaves at least four things open. When does the clock start: signature date, expiry date, last amendment, or ingest into the archive? What happens at the end: automatic deletion, review queue, or transfer? Who is permitted to intervene before then? And what record is kept of the whole thing having worked?

A storage system cannot infer any of these. It can only apply the parameters it is given. If nobody supplies them, the default is whatever the filesystem does, which is to trust whoever holds the credentials.

The practical test is simple. Pick one record class. Ask which system enforces its period, what would happen if an administrator tried to delete an item inside the period, and where that attempt would be logged. If the answers require a person to promise something rather than a system to refuse something, the control does not exist yet.

Every rule needs five components before it can be configured: a retention class, an enforcement mechanism, a clock start event, a disposition action, and the evidence the arrangement produces. The table below works that translation through for four illustrative classes. The periods shown are examples of how classes are typically structured, not statements of what any specific law requires.

Two things fall out of this table. First, the clock start event is almost always business metadata, not a file timestamp, so it has to be captured at ingest by the application writing the record. Retrofitting it later is expensive and often impossible. Second, the disposition action is a policy decision that differs by class, and the storage system should be configured to reflect that difference rather than applying one behaviour to everything.

The mechanisms themselves are described in more detail under immutable and WORM storage and WORM storage appliances.

A hold is not an extension of the retention clock. It is an override that must sit above the class policy and block disposition entirely, including disposition the schedule would otherwise trigger tomorrow. Treating a hold as "add three years" is the most common design error, because it silently expires.

At scale, holds are difficult for reasons that have little to do with storage. Legal identifies custodians, not paths. Somebody has to resolve a list of people and a date range into the specific objects on the archive, apply the flag, and record who authorised it. Releasing is harder still: a record under two holds must stay held when one is lifted, which means holds need to be tracked individually rather than as a single boolean.

Where the archive supports it, hold state should be readable as a report, so legal can be shown what is currently frozen without asking an administrator to check volumes by hand.

The question an assessor asks is not "is this data protected today". It is "prove the control was in force for the whole period you are claiming". That is a different and much harder thing to produce after the fact.

Four categories usually carry the weight:

• Configuration history. Evidence that the retention policy was applied at ingest and has not been weakened since. A current screenshot proves only the present.
• Refused operations. Log entries showing deletion or modification attempts that the system declined. These are the strongest single piece of evidence, because they show the control acting rather than merely being set.
• Media and volume records. For optical or removable media, the certificate or identifier for each piece of media, where it is, and what it holds. See optical archive systems for how that inventory is maintained.
• Chain of custody. Who handled media, when it moved, and who authorised each movement.

Retain the evidence itself under retention. Audit logs held on a mutable tier are a weak link, and an assessor will notice.

Data retained past its required period is discoverable, has to be secured, and costs money to hold. Over-retention is a liability, not caution. Yet many organisations end up there by default, because deletion feels risky and nobody wants to sign the approval.

Defensible disposition means the deletion is as controlled and as documented as the retention was. The class was defined, the period ran, the hold register was checked and clear, an authorised person approved disposal, the deletion executed, and the record of it survives the record. A disposal you cannot evidence is barely better than no disposal.

This matters most in banking and financial services and healthcare imaging, where volumes are large and classes are mixed on the same infrastructure.

Storage cannot invent a retention schedule and neither can an integrator. Before configuration begins, three things need a named owner: the classification scheme that decides which class a record falls into, the schedule that assigns periods to classes, and the disposal authority that signs off expiry. Without the third, expiry stalls and the archive quietly becomes permanent.

Aban Smart designs, supplies, integrates and supports the storage layer that enforces the schedule you provide. We do not determine retention periods, and we do not advise on what any regulation requires. Those are legal questions for your own advisers. What we can do is make sure that once a decision is made, the system enforces it and can show that it did.

Start at the solutions overview for the wider archive picture, or contact us with a specific record class you are trying to control.