A user recently deleted a top-level folder in SharePoint. It was eventually restored, but management now wants to prevent anything similar from happening by removing delete permissions for everyone across the tenant. After I explained that this would likely break normal file operations, the proposal changed to removing delete permissions from top-level folders, breaking inheritance, and configuring permissions manually throughout the environment. That could mean hundreds of hours of work and still create major usability and maintenance problems.
I suggested using retention policies, version history, alerts, recovery features, or other governance controls instead, but management considers retention a compliance responsibility and does not expect that team to implement it. Am I right that globally removing delete permissions—or applying this model retroactively across every site—is a bad approach?
4 Answers
Breaking inheritance across every top-level folder can work in a small, carefully managed environment, especially if the structure is standardized and automated. It is not something I would retrofit manually across a large tenant. Export the current permissions, define groups and roles, automate the changes where possible, and test thoroughly before expanding the model.
A common compromise is to restrict deletion only in especially sensitive libraries or locations, while leaving ordinary collaborative libraries functional.
Yes, this is likely to cause more problems than it solves. In SharePoint, delete permission affects more than just permanently removing a file. Users may also lose the ability to rename or move items, clean up obsolete content, and perform other normal library operations. The result is usually a buildup of clutter and frustrated users.
Document the risks and get the request, scope, and approval in writing. If management still wants it, pilot the change on one representative site first and measure the impact before touching the rest of the environment.
The important thing is to make the business owner accept the tradeoff. Removing delete access does not eliminate risk; it shifts the risk toward undeletable junk, broken workflows, support tickets, and users finding workarounds. Send a concise written summary explaining the expected side effects, estimated effort, recovery alternatives, and the result of a limited pilot. If they still approve it, at least the decision and warnings are documented.
The safer approach is layered protection: use appropriate retention or data-loss policies, version history, recycle-bin recovery, alerts for unusual deletion activity, and clear ownership of important libraries. Permissions should follow the business workflow rather than being globally restricted because of one incident.
Retention may be owned by compliance, but IT often has to configure and validate the technical settings. This is worth escalating as a joint governance decision instead of treating it as a simple permission change.
Recovery features are useful, but they should support a sensible prevention strategy rather than justify making every library effectively read-only.
Moving files can be affected too, so the pilot should test renaming, moving, editing, syncing, and normal cleanup—not just deletion.