TL;DR: SharePoint can be used for PHI only when Microsoft 365 licensing, a BAA, and tenant controls are in place, but Strac argues the larger risk is that regulated data still leaks through sharing, uploads, version history, and synced devices. The article reframes HIPAA as a data-layer governance problem, not just a contract or platform question, for healthcare teams.
NHIMG editorial — based on content published by Strac: Is SharePoint HIPAA Compliant? Learn how Strac safeguards SharePoint against critical concerns such as data breaches, insider threats, and regulatory non-compliance
By the numbers:
- One company using SharePoint suffered a ransomware attack in June 2023, and the attacker stole hundreds of files.
- Microsoft’s BAA for Office 365 Enterprise and Microsoft 365 Enterprise covers SharePoint use on those plans.
- Strac says its real-time PHI protection spans SharePoint, OneDrive, and the broader Microsoft 365 ecosystem.
Questions worth separating out
Q: How should organisations make SharePoint safe for PHI storage?
A: They should treat SharePoint as a controlled repository, not a default file share.
Q: Why do collaboration platforms create more PHI risk than simple storage systems?
A: Collaboration platforms multiply exposure paths.
Q: What do security teams get wrong about HIPAA and cloud collaboration tools?
A: They often assume a contract or platform certification is enough.
Practitioner guidance
- Restrict PHI to explicitly governed sites Create dedicated SharePoint sites and libraries for PHI, then apply least-privilege access and remove broad sharing groups such as Everyone or All Employees.
- Disable open-ended sharing modes Remove Anyone with the link access, limit external sharing, and review link expiry so patient data cannot be forwarded outside approved workflows.
- Enable content-aware detection and remediation Deploy DLP that can identify PHI in PDFs, scans, spreadsheets, versions, and synced OneDrive folders, then block, redact, or quarantine when policy is violated.
What's in the full article
Strac's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step SharePoint HIPAA configuration guidance for tenant settings, access restrictions, and sharing controls
- Detailed examples of PHI leakage paths through folders, version history, and synced OneDrive devices
- Strac's DLP workflow for scanning, classifying, and redacting sensitive content in Microsoft 365
- The article's compliance checklist for healthcare teams evaluating SharePoint as a PHI repository
👉 Read Strac's guidance on making SharePoint HIPAA-aligned →
SharePoint HIPAA compliance: are your controls keeping up?
Explore further
Contractual compliance is not the same as data governance. A BAA may satisfy a legal prerequisite, but it does not control how PHI moves through sharing links, synced folders, or document versions. HIPAA risk emerges when policy assumes the platform boundary is enough. Practitioners should treat the governance gap as content control, not vendor coverage.
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: SharePoint HIPAA compliance depends on controls, not defaults