According to Microsoft's own documentation on Microsoft 365 Backup, the scenario that drove the product's creation is, most of the time, not a sophisticated attack — it's "accidental or malicious deletion or overwrite of content by an employee." That line describes the everyday reality of any company that works out of a shared folder: someone deletes the wrong folder, or saves a file over the version that still mattered.
The reason Microsoft sells a separate product for this problem is simple: what already ships with Microsoft 365 — the former Office 365 — was designed for the everyday mistake, within a short window, not to bring back anything after months have passed. Once that window closes, the file doesn't come back through normal means, and often nobody notices until someone needs that exact document.
For whoever approves the IT budget, the question that matters isn't "is the cloud secure." It's: when someone deletes or overwrites something by mistake, how much time does the company have to notice — and what happens after that window closes.
The mistake nobody sees happening
In a Microsoft 365 shared folder, by default more than one person has permission to delete and overwrite what's in there. That's what makes the folder useful for the whole team to work together. It's also what makes the mistake easy: one wrong click on an entire folder, a file saved with the same name as one that already existed, a year-end cleanup that swept away something still in use.
Overwriting is the trickier of the two. When a file is deleted, the company at least knows it's gone — the folder visibly shrinks. When a file is overwritten, the name stays in the same place, the same size as always, and nobody notices the content changed until someone opens the document and finds pages, clauses, or an entire spreadsheet missing.
According to Microsoft's documentation on how retention settings work, when a document has a retention policy applied, a copy is automatically kept in a preservation library whenever someone edits or deletes the content. The detail that goes unnoticed is the condition: that extra copy only exists if someone configured that policy beforehand. Without it, editing or deleting a file leaves no additional copy beyond the standard recycle bin and version history.
And the recycle bin has a deadline. According to Microsoft's official documentation on OneDrive retention and deletion, removed items stay in the site recycle bin for 93 days — after that, recovery through normal means is no longer possible. For whoever notices the problem the next day, 93 days feels like a wide margin. For whoever only realizes it when a client asks for a specific contract back — weeks or months later — that window may already have closed without anyone knowing.
The gap between the mistake and the discovery is, in practice, the real problem. It isn't the deletion itself — it's how long the company takes to notice something is missing, while the recovery window keeps running out without anyone knowing it needs to be raced against.
Why the usual approach falls short
The usual way of handling this is trusting that "it's in the cloud" is guarantee enough. That phrase isn't wrong about what the cloud actually offers — physical redundancy, staying up even if one piece of equipment fails — but it answers a different question than the one that matters here. Redundancy protects against Microsoft losing the data in a data center failure. It doesn't protect against the company itself deleting or overwriting what belongs to it.
Another version of the same habit is leaving a shared folder with permissions that are too broad: everyone can edit, everyone can delete, and nobody decided that on purpose — it just grew as the team grew, and nobody reviewed it afterward. The more people who can delete an entire folder, the higher the chance someone does it by accident, and the lower the chance of quickly identifying who did.
The third common habit is never having tested recovery. The company knows a recycle bin exists, but nobody has ever tried pulling an old file from it to see if it was still available, comparing the restored version against the one that was needed, or timing how long the process takes. Finding out the window has already closed, or that the recovered version isn't the right one, in the middle of a real emergency is the worst possible moment to learn that.
What has to be in place
An environment prepared for this kind of everyday mistake rests on mechanisms you can verify, not on trusting that "the cloud handles it."
A backup kept separate from the default recycle bin, with a retention window longer than the native feature's few months — for the document that won't be needed again until a year from now.
Delete permission restricted to whoever actually needs it, instead of granted to the whole folder by default. Someone who only needs to read or edit a document doesn't need the ability to delete the entire folder.
Periodic recovery drills on a real file, to know, before it's actually needed, how long the process takes and whether the recovered version is the one the company expected to find.
One person tracking what changes in the most critical folders, instead of leaving discovery to depend on a client calling to ask about a missing contract.
Regular review of who has access to each shared folder, so the list of who can delete keeps up with who actually still works with that content — not who worked with it two years ago.
This is how Skills IT works: with backups kept separate from the native recycle bin, delete permission restricted to whoever needs it, and periodic recovery drills to make sure the file comes back when it's needed.
The payoff for the business
The payoff here isn't abstract. A company that discovers the deletion or overwrite the same day has a simple task ahead: restore a file from the recycle bin, or from a recent backup. A company that discovers it weeks later faces something else entirely: rebuilding the document from memory, asking someone who may no longer work there to send the information again, or accepting that the content simply doesn't exist anymore.
There's also what LGPD puts on the table when the folder that disappeared holds client or employee data. According to Brazil's National Data Protection Authority, a security incident is an event that compromises the confidentiality, integrity, availability, or authenticity of personal data — meaning losing access to data counts too, not just leaking it. When that incident poses relevant risk to the people involved, notifying the authority has to happen within three business days. A company that only realizes the problem months later has already missed that window without even knowing it existed.
There's a less visible gain too: nobody has to decide, in the middle of a rush, whether that file saved two years ago is "probably still there." With a known, tested retention window, the answer is already settled before the problem happens — and the team spends its time working, instead of rebuilding what already existed before.
A starting checklist
- Ask how long a deleted or overwritten file stays recoverable at your company today. If the answer is "not sure," that's the first gap to close.
- List who can delete each important shared folder. If the answer is "everyone," it's worth reviewing before someone finds out by accident.
- Have someone test recovering an old file. If the process takes longer than expected, or the recovered version isn't the right one, better to find out now.
- Check whether any backup exists beyond the default recycle bin. Without one, the company's recovery window is exactly the recycle bin's window, and nothing more.
- Agree, in writing, on who gets notified when a sensitive document goes missing. Without a clear path, discovery ends up depending on coincidence — a client calling to ask, a contract someone looks for and can't find.
