Nobody Has Opened That Share Since 2019. It Is Still Your Problem.

What the last-accessed date measures

A posture inventory carries a last-accessed column, and it is the most attractive column in the report. Sort on it and a block of the estate falls off the bottom. A file share carried through a datacenter consolidation. A site collection from a program that closed. Read counts near zero going back years.

The column earns its place, and it misleads when it gets read as a risk score. What it measures is the population of people who open the store, and that population left for reasons of its own: a reorganization, a system replacement, a program that ended.

Everything else about the store held. Classification says it holds regulated records, and it said that before anyone looked at the usage. The permissions still resolve, to a group that has grown through reorganizations since the last person read a file there. A notification obligation reads what was taken, and the date of the last legitimate read carries no weight in it.

Low usage changes one thing, and it runs the wrong way. Five properties survive the years of silence.

• The classification results hold, and the records are the same class they were the day they were created
• The permissions still grant, to a group that gained members through every reorganization
• It is discoverable in litigation on the same terms as content created this quarter
• An exfiltration is measured by the records taken and the people they identify, on the same terms as any other store
• Detection turns on the auditing: with none enabled there is no baseline for an unusual read to stand out against, and with it enabled a first read in years is a strong signature

A last-accessed date describes the people who used to read it. They moved on and the records stayed where they were.

Everyone agrees and the store survives another cycle

The conversation has a predictable shape, because the incentives inside it are fixed. Security proposes disposal. The business unit confirms they have not opened it in years. The platform team says they can run the deletion whenever. Everyone in the room agrees it should go, and it appears on the next cycle's report unchanged.

The reason is an asymmetry every person asked to sign can see. Keeping data past its time produces a line on a report that already carries other lines. Destroying data somebody later needs produces a meeting with your name at the top. One cost is spread thin across a program. The other lands on one person with a date attached.

So the answer comes back as a deferral, and it arrives dressed as progress. The store gets archived, moved to cheaper storage, or cut to a handful of named people with another look promised next quarter. Each of those is worth doing, and each leaves the content and its obligations where they were.

This is also the one action in a data security program that cannot be walked back. An enforcement policy set too tight gets turned down the same afternoon. A deletion is permanent the moment it runs, so the person who signs has to be somebody whose job already includes signing things of that kind.

Ask who carries the cost of keeping it and the answer is a program. Ask who carries the cost of destroying it and the answer is a name.

Retention is the question underneath the stale store

Move the question off usage and onto obligation and somebody can answer it. What class of record is in there, how long must the company hold that class, and has the period run out.

Obligations come in a few shapes, and the shapes matter here more than the citations. Some classes carry a minimum period, which makes early destruction the offense. Some carry an outer limit, where holding personal information past the purpose that justified collecting it becomes the exposure. Some periods the company set for itself, in a privacy notice or a customer contract, and those bind just as firmly. The specifics belong to counsel and records management, and a schedule a security team assembled from reading regulations will fail its first challenge.

The artifact that resolves this is a retention schedule. Where the organization has a records function, the schedule exists: record classes, each with a period and a trigger event that starts the clock. It predates the tenant it now has to govern and describes records in business language, so it reaches storage accounts only through a join. Making that join against the classification results is the step that gets left out of scope, and it turns a shrug about low usage into a sentence with a date in it.

Both platforms carry out the retention they are configured with. Whether anybody in the organization can authorize that configuration is the question this article is about, and it is answered inside your records function. Four things get recorded per store before disposal is a question worth asking.

• The record class its contents map to, established from the classification results
• The schedule line that governs that class, with the version it came from
• The retention period, the event that starts the clock, and the date that event occurred
• Whether this is the authoritative record or a copy of one held elsewhere

The hold check comes before everything else

One instruction overrides the schedule completely. Where content falls under a legal hold, disposition is suspended for as long as the hold stands. The period underneath keeps running, so a period that expires mid-hold means disposal proceeds once the hold is released. The hold outranks everything else in the program, and the mechanism should refuse to execute until the check comes back.

The check is harder than it sounds, because a hold and an inventory are written in different vocabularies. A hold names a matter, a set of custodians and a range of dates. The inventory names a storage account, a site collection, a mailbox. Somebody has to map one onto the other, and that somebody sits with legal or with whoever administers eDiscovery.

Placing a hold has an owner and an occasion behind it. Lifting one waits on somebody remembering to ask. So a matter closes, the instruction stays in force, and every store it touched stays frozen under a decision that is years old. Lifting it needs a signature too, from the same office, for the same reason.

Run the hold question as a standing input with a date on the answer, because an answer given some months back describes a set of matters that has moved on. The check returns five things in writing before anything is destroyed.

• The matters currently open, with the custodians and date ranges each one covers
• The stores in scope, mapped from those custodians and ranges by whoever administers the hold
• The date the check ran and the person who ran it
• Holds attached to closed matters, handed back to the office that placed them
• Written confirmation that the mechanism skips any store on the hold list

What makes a disposition defensible

Defensible means the decision holds up when somebody with an interest in attacking it looks two years later. The content is gone by then, so the only thing left to examine is the record of how the decision was made. That record is the deliverable.

Assembling it before asking for a signature changes the conversation. An approver asked whether the company still needs a decade of files is being asked to predict the future, and waiting costs them nothing. An approver handed a completed pack confirms a documented position.

In the three Purview and Securiti data security posture engagements CWS has delivered, the disposition decisions that actually closed were the ones with a records schedule and a named authority already behind them. Where those were missing, stores got argued one at a time and most were still open at the end of the cycle.

Records management in Purview runs the execution end of this as a workflow: a retention label can require a disposition review, the review routes to named reviewers in stages, and a record of the disposition is kept afterward. The pack and the delegated authority are the configuration and the inputs that workflow runs on, and assembling both is work that happens outside the product.

What evidence a disposition record has to carry, and how far disposition authority can be delegated, are CWS positions. They build on established records management practice and go past what it prescribes. The version worth building delegates the authority once and applies it per class: records management writes a standing procedure for a defined class of store, fixes what a pack has to contain, and security executes under an authority somebody else granted in writing.

That is the honest answer about who should be deciding. Security can see the exposure and produce every piece of evidence in the pack. Whether the company still needs a record is a call that sits elsewhere: records management owns the schedule, counsel owns the hold, and the business owns the process behind the content. A disposition record that survives being questioned holds seven things.

• What the content was, from classification evidence, with a retained sample
• The record class and the schedule line, with its version and date
• The retention period, the trigger event, and the date the period expired
• The hold check, its date, and the person who ran it
• Who was notified, when, and what came back
• The approver by name and role, and the written authority they acted under
• The method, the date it ran, the recovery window, and the log the platform produced

Build the pack before you ask for the signature. Two years later it is the only artifact anybody can inspect.