Data classification policies are the rules an organization uses to sort its data into categories that determine how each category is handled. They are usually written by security or compliance teams and framed around confidentiality: public, internal, confidential, restricted. For storage, two other dimensions matter at least as much. How valuable is the data to the business over time, and how long must it be kept? A classification that captures only sensitivity tells a storage team how to protect data and nothing about where to put it or when to remove it.
This post looks at classification from the storage side: the dimensions that drive placement and retention, how to make a policy enforceable and why most classification efforts stall.
A classification useful for storage answers three separate questions about each data set. They are independent, and collapsing them into a single label loses information.
| Dimension | Question | What it drives in storage |
|---|---|---|
| Sensitivity | Who may see it, and what happens if it leaks? | Access control, encryption, location, audit logging |
| Value | What does losing it, or losing access to it, cost? | Protection level, number of copies, backup, recovery targets |
| Retention | How long must it be kept, and when must it go? | Lifecycle rules, immutability, legal hold, deletion |
The combinations are instructive. Public marketing video is low in sensitivity, moderate in value and has no fixed retention. Access logs are low in day-to-day value and may carry a strict retention requirement. A training data set for an AI model can be enormous, expensive to recreate and subject to deletion rules if it contains personal data. None of those is described adequately by a confidentiality label.
Sensitivity is fairly stable over a data set's life. Value is not. Most data is accessed heavily when new and rarely afterward, and its value to operations falls accordingly, though its value as a record may persist. Classification for storage has to include that time dimension, because it is what justifies moving data to cheaper protection or media as it ages.
The practical expression is a small set of rules: data in this class stays on the performance tier for 90 days, moves to the capacity tier until year three and is then deleted or archived. Those rules are implemented as lifecycle policies, described in the post on S3 lifecycle policies, and they only work if the class of each object is known to the storage system.
Retention requirements come in two forms. Minimums say data must be kept for at least a given period, usually from records regulation. Maximums say it must not be kept longer than necessary, usually from privacy law. A classification policy should state both for each class. A class with only a minimum accumulates forever. A class with only a maximum risks deleting something a regulator expects to see.
Where a minimum is mandatory, immutability enforces it: objects under a retention lock cannot be deleted early by anyone. Where a maximum applies, deletion has to actually happen and be demonstrable, which is harder than it sounds once versions and replicas exist. The posts on data deletion verification and data retention after AI training cover that side.
A classification policy that lives only in a document is applied inconsistently. For storage to act on it, the class has to be attached to the data in a form the system can read. On object storage there are three places to put it. The bucket is the coarsest: everything in a bucket shares a class, and bucket-level settings such as Object Lock, versioning and policy enforce it. Object tags are finer, allowing lifecycle rules and access policies to select objects by class within a bucket. Object metadata carries descriptive detail for applications and catalogs.
Bucket-level classification is the most robust, because it does not depend on every writer tagging correctly. A layout in which each bucket holds one class, as discussed in the post on S3 bucket design, lets the storage platform enforce most of the policy by configuration.
The cheapest moment to classify data is when it is created. An application that writes records knows what they are. An instrument that produces images knows the project. Requiring a class at the point of write, by directing each kind of data to its bucket or applying a default tag, costs almost nothing. Classifying years of existing unlabelled data is a different matter. It needs discovery tools, sampling and decisions by data owners who may have moved on, and it is where most classification programs run out of energy.
A workable approach is to classify all new data from a given date and to treat the backlog by exception: apply a conservative default class to existing data sets as a whole, then refine only the largest or riskiest.
Three causes account for most failures. The scheme has too many classes, so nobody can apply it consistently. Four or five combined classes cover most organizations. Ownership is unclear, so no one is authorized to say that a data set may be deleted. And nothing changes as a result of classifying, so the effort looks like paperwork. The remedy for the last is to connect each class to a concrete storage outcome, including its cost, so that classifying data correctly moves it to cheaper protection or removes it. The post on storage quotas and chargeback describes how to make that cost visible.
Scality RING exposes an S3 interface, so lifecycle, versioning and retention settings are managed through the same API that applications already use. It is multi-tenant, with accounts, buckets and policy-based isolation, which allows each class of data to be held in buckets whose settings enforce its handling. RING supports versioning and S3 Object Lock for classes with mandatory retention.
Erasure coding and replication are selectable per policy, and RING can span multiple sites, so protection level and location can follow the value and sensitivity of each class within one platform. RING runs on standard x86 servers in the customer's own facility.
Classification earns its keep when it changes what the storage system does. A short policy that maps every data set to a protection level, a location and an end date is worth more than a detailed taxonomy that stops at the label.