Notifications
Clear all
Topic starter
20/08/2026 5:42 pm
TL;DR: SharePoint does not detect or remove PHI on its own, and Strac’s analysis says that leaves scanned forms, PDFs, images, versions, and synced copies exposed unless deletion is automated. For healthcare and insurance teams, the issue is not storage alone but governed removal, auditability, and retention enforcement across the full SharePoint and OneDrive content lifecycle.
NHIMG editorial — based on content published by Strac: How to Delete PHI in SharePoint Automatically
Questions worth separating out
Q: How should healthcare teams automatically delete PHI in SharePoint without breaking workflows?
A: Start by classifying where PHI can appear, then apply OCR-based detection to uploaded files, scans, and images before using policy rules to delete, redact, or escalate.
Q: Why do collaboration platforms fail to control regulated data retention by themselves?
A: They are built to store and share content, not to interpret clinical identifiers, find PHI in images, or enforce lifecycle deletion across every copy.
Q: What do security teams get wrong about PHI deletion in SaaS storage?
A: They often assume deleting the visible file removes the regulated data everywhere.
Practitioner guidance
- Define PHI deletion scopes by content location Map where PHI can persist across SharePoint, OneDrive sync paths, file versions, previews, and shared links, then make each location part of the deletion policy.
- Require OCR-backed detection before retention decisions Do not rely on folder names, metadata, or user declarations.
- Tie deletion workflows to HIPAA audit evidence Log what was detected, what was removed, where it was removed from, and whether any version or sync copy remained.
What's in the full article
Strac's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step PHI deletion flows across SharePoint libraries, synced OneDrive directories, and historical file versions
- Policy examples for auto-delete, alert-only, and approval-based workflows for different PHI classes
- Operational handling for scanned records, PDFs, embedded images, and attachment cleanup
- Audit log and retention examples for HIPAA-aligned evidence collection
👉 Read Strac's analysis of automatic PHI deletion in SharePoint →
SharePoint PHI deletion: are your controls actually enough?
Explore further
20/08/2026 6:26 pm
PHI deletion is a lifecycle control, not a cleanup task. The article’s core point is that storage systems rarely solve governed deletion on their own. Once PHI is spread across primary files, versions, sync clients, and shared references, the control objective becomes lifecycle enforcement. For healthcare and insurance teams, the right frame is not "can the platform store this?" but "can the platform prove the data is gone?".
A question worth separating out:
Q: Who is accountable when PHI leaks from SharePoint?
A: Accountability sits with the covered entity or business associate, not the cloud provider alone. The provider can sign a BAA, but the organisation is still responsible for configuring access, logging, sharing, and DLP correctly. HIPAA compliance is therefore a shared contractual arrangement with operational accountability remaining inside the customer environment.
👉 Read our full editorial: Automatic PHI deletion in SharePoint exposes a HIPAA gap
