Think of the file in your SharePoint that has gone longest without anyone opening it. The lease. The as-built drawing of the installation. The expert report from that dispute. The certificate for the machine your predecessor bought. Now think which of them you will need one day, and how urgently. It is probably the same one. By mid-August Microsoft finishes rolling out the ability to delete exactly that file automatically, on the grounds that Copilot will answer better for it. It does not delete anything by itself — somebody has to configure it — but the button will be there, and it will be very easy to press.
What is actually shipping, and what is not
The notice sits in the Microsoft 365 message center under the reference MC999442, titled "Retention based on last accessed for OneDrive and SharePoint files". Preview started in late June 2026 and general availability in late July; Microsoft expects both to complete by mid-August. In plain terms: on top of retaining or deleting by created, modified or labelled date, you can now do it by "nobody in your organisation has opened this in X". For now it applies to Microsoft 365 file types; other formats, the notice says, in a future rollout.
Before going further, the honest part, because skipping it turns the rest of this piece into scaremongering: this deletes nothing on its own. The notice itself says the rollout is automatic and requires no admin action; what arrives is the option in a dropdown, not a live policy. If nobody creates a retention policy with a delete action on that condition, not a single file will disappear from your tenant. Our worry is not the rollout. It is how easy the gesture is, and the quality of the argument that will be used to ask for it.
Because the argument is written into the notice itself: the feature "will help delete obsolete data, which will improve the quality and relevance of Microsoft 365 Copilot responses". It is a technically sound reason — an index full of junk degrades any retrieval system — and at the same time it is the first Microsoft 365 deletion feature we have seen justified by the quality of an AI's answers. Worth noticing, because it changes who asks for the button: the person who wants Copilot to answer better is not the person who will need the 2021 file in 2029, and neither of them is the one who signs the big customer's compliance questionnaire.
The trigger is no longer a property of the file
Here is what we find genuinely interesting, and we have not seen it written anywhere. Created date and modified date are properties of the document: somebody wrote them by doing something deliberate to it. "Last accessed" is not a property of the document; it is a measurement of your organisation's behaviour. A file does not become old because nobody looks at it, any more than a fire extinguisher expires because nobody uses it.
And the consequence is uncomfortable, because for a whole family of documents the relationship between access frequency and value is inverse. Signed contracts, deeds, certificates of conformity, final drawings, audit reports, minutes: they get opened once when signed and are not touched again until there is a problem. Nobody having opened them in three years does not mean they are surplus; it means there has been no inspection, no claim and no dispute in three years. That is good news about the company, not a verdict on the file.
And nobody has said yet what counts as "opening"
This is the question that decides whether the feature is useful or dangerous, and today it has no public answer. Neither the message center notice nor the Microsoft Learn page on retention for SharePoint and OneDrive defines which event updates that last-accessed date. The latter mentions the retention starts based on created, modified, labelled and event, and says nothing yet about the new condition. It is a Ctrl+F: check it yourself before taking our word for it.
We are not going to invent the answer. We are going to write down the four questions whose answers completely change the outcome, because they are the ones we would put to Microsoft before configuring anything:
- Does what the OneDrive sync client does when it refreshes a folder on somebody's laptop count as an access?
- What about a tool that walks the whole tenant — antivirus, a migration, a third-party backup, an eDiscovery export? If it counts, the clock never reaches zero and the policy deletes nothing: false comfort.
- Does Copilot reading the file to ground an answer count? There is a certain humour in it: a feature meant to improve Copilot whose clock is reset by Copilot itself.
- And the one that matters most to us: for a file that existed before the feature arrived, from when is it counted? With no prior history, does the clock start today, or is a date inherited that nobody knows how it was computed?
Notice that the two possible errors point in opposite directions and both are bad. If almost everything counts as an access, you build a cleanup policy that cleans nothing and feel great about it. If almost nothing counts, you delete live documents that simply get consulted rarely. Configuring an irreversible deletion on top of an undocumented signal is exactly the kind of decision you cannot later defend in writing, and in writing is how audits get answered.
93 days, and they are days of silence
The deletion mechanics are documented, and worth being clear about because they set your only real margin. When a delete-only policy hits its deadline, a periodic job — which can take up to seven days to run — moves the document to the first-stage recycle bin. If somebody empties it, it goes to the second stage. A 93-day period spans both, and at the end the document is permanently deleted wherever it sits. That number is your full recovery window: not the one in your Microsoft 365 contract, not the one in your retention policy. Ninety-three days.
And now the part we consider the most important in this whole article. Those 93 days pass in silence, by construction. Every other kind of data loss has a detection signal: somebody raises a ticket because they cannot find something. Here the policy deletes, with surgical precision, exactly the files nobody looks at. Nobody will miss them, because "nobody looks at them" was the selection criterion. There will be no ticket. There will be no phone call. To top it off, Microsoft's documentation is explicit that the recycle bin is not indexed and therefore cannot be searched, so an eDiscovery search cannot find its contents to place a hold on them. It does not even turn up in a search. Translated into a work plan: detecting this failure cannot be reactive; it has to be in the calendar before the problem exists.
The three lifelines people think they have
When we put this on the table in a meeting, the answer is usually one of these three. None of them holds.
"There is the recycle bin." It is, and it lasts 93 days counted from a moment you will not notice. The file sits in the first-stage recycle bin, which users can see — the users of a site nobody, by definition, goes into; and if somebody empties it, it moves to the second stage, which users cannot see and from which only a site collection admin can restore. Either way it is a three-month net you have to go and look at, and nobody is going to go.
"There is version history." SharePoint keeps a minimum of 500 major versions by default, true, and it is an excellent feature for the "I overwrote the document" mistake. But the documentation leaves no room for doubt: when the retention action is to delete the document, all versions not in the Preservation Hold library are deleted at the same time, following the current version. It protects you from editing badly, not from deleting.
"We have a retention policy." That is precisely the thing doing the deleting. A retention policy answers "how long should this exist"; a backup answers "how do I get this back when the system does exactly what I told it to do". Different tools, different owners, different failure modes. When the only answer to "and if we get it wrong?" is "well, there is the recycle bin", what you have is a retention policy standing in for a backup.
We wrote this recently about a far more serious case and the substance is the same: when the system deletes and the copy goes with it, the data does not come back. There the deletion was accidental and here it is a feature doing its job, but the vanished data does not tell the two apart.
Microsoft sells the airbag separately, and that is the data point
We have spent years repeating that Microsoft 365 does not do your backups, and years watching sceptical faces. The argument was settled a while ago and we do not need to be the ones to win it: Microsoft sells a product called Microsoft 365 Backup, pay-as-you-go, with a list price of $0.15 per GB per month of protected content. That price list is the official answer to the question. If the platform already kept your data mistake-proof, there would be no gigabyte meter next to it.
That said, and even though this paragraph shoots us in the foot: a backup does not fix what was deleted before the backup existed. The documentation is clear that deleted content expires from the backups once the backup retention period lapses — Microsoft's own example is 365 days from when the backup is taken. Buying backup in September does not bring back what a policy took away in August, and three hundred and sixty-five days of restore points are a good deal less than the years a last-accessed policy handles without blinking. We are not resellers of any particular platform — we recommend on the merits, not on the commission — so we will not tell you that is the only option either: there are third-party tools and there are small tenants where the sums come out differently. What we will tell you is that protecting the data in Microsoft 365 is a decision somebody makes, not a box that comes ticked.
And one billing detail worth keeping in mind if somebody is going to run numbers: the charge is calculated on protected content plus deleted content held in the second-stage recycle bin. Microsoft's official example is a 1 GB site with 0.5 GB in the second-stage bin and a 1 GB mailbox with a 1 GB archive: 3.5 GB billed. Which means that in the months after a big cleanup you keep paying for what you deleted until it expires from the backup. It is consistent and well documented; it is simply not what people assume when they calculate the savings from deleting.
Deleting is not the only lever for better Copilot answers
If the problem you want to solve is Copilot pulling odd things out of a corner of SharePoint, there is a tool that does exactly that without destroying anything. It is called Restricted Content Discovery and it is a per-site setting: the content stops appearing in organisation-wide search and in Copilot responses, and the AI entry points disappear from the site — the Copilot button, the AI actions menus, creating pages with AI. The documentation insists on two things we find decisive: it does not change permissions, whoever had access carries on working as before, and it does not remove content from the search index, so eDiscovery and Purview auto-labelling keep working. It is the difference between pulling down the shutter and throwing out the filing cabinet.
# Take a site out of Copilot and org-wide search reach, deleting nothing
Set-SPOSite -Identity <url-del-sitio> -RestrictContentOrgWideSearch $true
# Check a site's status
Get-SPOSite -Identity <url-del-sitio> | Select RestrictContentOrgWideSearch
# What is worth measuring before a cleanup: the recycle bin users do NOT see
Get-PnPRecycleBinItem -SecondStage
With its small print, also in the documentation, which we would rather say ourselves: it needs a Microsoft 365 Copilot licence and SharePoint Advanced Management, it cannot be applied to OneDrive, the page itself warns that overusing it reduces available content and hurts the relevance of answers, and on sites with more than 500,000 items the change can take over a week to take effect. But it is reversible, and that word is worth a lot here.
How we would do it
Not a top-ten list. Five decisions in the order we would take them, and the first is the one most people skip.
- Look first, delete later. The question is not "how long do we keep it?", it is "what exactly would this take away?". Auto-apply label policies support simulation mode when the condition is sensitive information types or a keyword and property query: it shows you which files the label would land on before it lands. With one nuance worth not confusing, because it is easy to: simulation tells you the scope, not what the last-accessed clock will eventually delete. Even so it is a great deal more than whoever switches it straight on will know.
- Disposition review instead of automatic deletion for anything legal, contractual, financial or technical documentation: when the period expires a human decides, not a timer. It costs one signature every few months and turns a silent loss into a decision with a name attached. And note the detail that settles the whole design: the notice says the new condition can be applied with a retention policy or a retention label, and disposition review only exists with a label: the documentation says so in as many words, it is not available for a retention policy. Retention policies do not get simulation mode either — that belongs to auto-apply retention label policies — and even there Microsoft only offers it for specific conditions; whether the new last-accessed condition is on that list, nobody has said yet. We would go the label route for the first reason, which is written down, and check the second in the wizard before promising anyone anything.
- Do not start with the whole tenant. Pick a site where the cost of being wrong is low — old marketing material, drafts, templates — and leave contracts, drawings, quality records and personnel files out from day one. Widening the scope later is easy. Recovering is not.
- Write down what "access" means in your tenant, with the answer Microsoft gives you or the test you run yourself. If you cannot write it down, you cannot explain it to an auditor, and if you cannot explain it to an auditor, do not enable it over data that auditor can ask you for.
- Decide on the backup beforehand, not on day 94. If the answer to "what if this takes something we needed?" is the recycle bin, then your recovery plan lasts ninety-three days and you did not know it. Same as we said about restoring versus recovering in a ransomware incident: a backup you have never tried to restore does not count as a backup.
What we know and what we do not
The feature is not bad and we are not going to pretend otherwise. The problem it solves is real: there are tenants with years of sediment where nobody knows what is in there any more, and that sediment does not just cost storage, it also widens the surface of anything that reads documents, Copilot included. We will use it. How many Spanish companies will switch it on in delete mode this autumn, no idea: we have not measured it and we are not going to make it up. And we still do not know what counts as an access.
The one thing we will say, entirely on purpose, is what we would not do: switch this on in delete mode, across the whole tenant, in mid-August — precisely when the rollout completes and precisely when half the staff is away. A month in which almost nobody opens almost anything is the worst imaginable moment to debut a feature that measures exactly that. If you must touch it in August, touch it with a label and disposition review, and in simulation if the wizard offers it. September will have time, and it will have people to ask whether they really do not need that file. If you like, we can have that conversation with you, and also the one about how many years you have to keep each thing, which almost nobody has had and which is what actually decides the period.
By the way, if you are going through the tenant these days, this goes well in one sitting with the other pending review: the connected applications holding permanent permission over your documents. One question is what deletes itself and the other is who reads it without asking; both are answered by looking at the same SharePoint.
Sources (verified): the feature announcement, its preview and general availability dates, the initial limitation to Microsoft 365 file types, the "no admin action required" line and the sentence about the quality of Copilot responses come from message MC999442 in the Microsoft 365 message center. The deletion mechanics — the periodic job that can take up to seven days, the path through the first- and second-stage recycle bins, the 93 days spanning both, the second stage not being visible to end users, the recycle bin not being indexed and therefore not findable by an eDiscovery search, the default minimum of 500 major versions, the fact that deleting the document deletes at the same time all versions not in the Preservation Hold library, — come from "Learn about retention for SharePoint and OneDrive" on Microsoft Learn. The $0.15/GB/month list price, the expiry of deleted content once the backup retention period lapses (365 days in Microsoft's example) the 3.5 GB billed in the official worked example and the Get-PnPRecycleBinItem -SecondStage command in the code block, from "Pricing model for Microsoft 365 Backup". Everything on Restricted Content Discovery — that it does not change permissions, that it does not remove content from the search index and that eDiscovery and auto-labelling keep working, that it cannot be applied to OneDrive, the Copilot and SharePoint Advanced Management licensing requirement, the warning about excessive use, the two Set-SPOSite and Get-SPOSite commands in the code block and the over-a-week propagation on sites with more than 500,000 items — from "Restrict discovery of SharePoint sites and content". That disposition review is label-only is stated in as many words in "Disposition of content": "Triggering a disposition review at the end of the retention period is a configuration option that's available only with a retention label. Disposition review isn't available for a retention policy." That simulation mode belongs to auto-apply retention label policies, and only with sensitive information or keyword and property query conditions, comes from "Automatically apply a retention label". That neither the notice nor the retention page defines what counts as last accessed is our own check against those same documents on 2 August 2026; if Microsoft publishes it later, this part of the article expires and we will be glad. Ours, not our sources': that last accessed measures behaviour rather than a property of the document, the inverse relationship between access frequency and value in legal documentation, the silent-failure argument, the five decisions and what we would not do in August.
How long would a mistakenly deleted file survive in your company?
We go through what your tenant retains and deletes today, what happens on day 94, and whether what you have is a backup or just a recycle bin. Recommending on the merits, not on the commission.
Talk to everyWAN