A user recently deleted a top-level folder in our SharePoint environment. We restored it, but now my manager wants to prevent a repeat by removing delete permissions for everyone across the tenant. After I explained that this could break normal file operations, he suggested allowing deletion only at the top level and breaking inheritance throughout the folder structure. That would require a huge amount of work and could still disrupt renaming, moving, editing, and general document management. I suggested using retention, versioning, alerts, or other recovery controls instead, but he believes compliance should handle retention and insists this is how permissions were managed in the past. Am I right that this approach is excessive and likely to cause more problems than it solves?
4 Answers
If management insists, protect only genuinely sensitive libraries or folders and use groups or roles for the people who need elevated rights. Breaking inheritance across an existing environment is risky and labor-intensive, especially if there are many sites. A scripted, documented permission model can work for a small, well-controlled footprint, but retrofitting it broadly is likely to cause complaints and unexpected failures.
Use recovery and governance features instead of trying to make the entire tenant behave like a locked-down file server. Version history, the recycle bins, retention policies, alerts, and appropriate backup coverage can all reduce the impact of accidental deletion. Retention may involve compliance, but IT often has to configure the technical implementation.
The safest practical response is to document the proposed change, clearly state the expected side effects, and ask for written approval. Then test it on a noncritical site for a week or two. That gives everyone evidence before a tenant-wide permission change causes operational problems.
Yes, applying a blanket no-delete policy is likely to create a mess. Users still need a way to clean up obsolete files, and SharePoint permissions have side effects beyond simply preventing deletion. Document the risks, get the instruction in writing, and consider piloting any change on one site before touching the wider environment.
Removing delete access can also prevent users from renaming or moving files, so the impact should be tested rather than assumed.
Backups and recovery are still important, but prevention only helps when it does not break ordinary work. A targeted policy is better than disabling deletion everywhere.