Should organisations rely on SharePoint permissions or add DLP for PHI protection?

Why permissions alone do not answer a PHI protection question

SharePoint permissions are an access gate, not a content control. They answer who can open a site or library, but PHI risk usually appears after the first click, when content is copied, forwarded, exported, synced, or preserved in places that permissions no longer govern. If the question is protection of PHI, a permissions-only model leaves the highest-risk leakage paths untreated.

DLP is the control that follows the content as it moves. It can inspect labels, file content, sharing behaviour, and policy conditions so that protected data is blocked, warned on, or constrained even when a user already has legitimate library access. That is why organisations should treat permissions as necessary but insufficient for PHI.

In practice, the distinction is between permission-aware retrieval and downstream content handling. The first is about whether a person can reach the item; the second is about whether the item can be moved into a form or location that creates exposure.

Where PHI leakage happens after access is granted

Once a user can read a file, several ordinary workflows can create exposure: sharing links externally, downloading to unmanaged devices, syncing to endpoints, copying into email or chat, printing, or reusing content in a new document. These are the moments where PHI often escapes the original SharePoint boundary.

DLP matters because it can act on the content regardless of the route it takes. A file that is technically accessible inside SharePoint may still need restrictions if it contains patient data, payment details, clinical notes, or other regulated information that should not persist outside approved handling conditions. Permissions do not answer those lifecycle questions.

That is also why over-sharing problems are often broader than SharePoint itself. NHIMG’s Enterprise AI Copilot Security Guide makes the same point for modern collaboration tools: access control decides reach, but data-loss controls decide whether sensitive content can be propagated, labelled, or reused unsafely.

What a better control stack looks like for regulated data

For PHI, the right pattern is layered control. Use SharePoint permissions to enforce least-privilege library access, then add DLP so the organisation can govern sharing, copying, retention, and risky exfiltration paths. If the environment includes sync, external sharing, or downstream collaboration tools, DLP becomes the mechanism that keeps the policy intact outside the original repository.

A mature implementation also needs clear policy design. PHI rules should be anchored to classification, labels, and known handling conditions, not just folder location. If the control only looks at where a file sits, it will miss the more important question: what can happen to the content after authorised access has already occurred?

For the privilege side of the equation, the Privileged Access Management Guide is a useful reminder that access should always be narrowed first, but the answer to PHI protection does not stop there. The same governance mindset applies: reduce unnecessary access, then add controls that constrain misuse, sharing, and persistence.

Risk and Threat Considerations

PHI exposure often happens through normal user behaviour rather than a dramatic breach. The main risk is that an organisation mistakes “someone can open the library” for “the data is safe”, even though the most damaging event is usually uncontrolled redistribution after access.

Failure mechanism: Users with legitimate SharePoint access can copy, sync, share, or export PHI into channels that permissions no longer govern, and without DLP the control boundary ends too early.

Impact: Regulated data can persist in email, endpoints, external shares, chat systems, backups, or personal storage, increasing breach, compliance, and patient-privacy exposure even when the original library was correctly permissioned.

Practitioner Guidance

What to prioritise: Treat PHI protection as a content-governance problem, not only an access-control problem. If the data classification is sensitive enough to trigger regulatory concern, permissions should be the first gate and DLP the second gate.

What to verify: Confirm that DLP policies cover the actual leakage paths your users use most, including sharing, download, sync, copy/paste, and external transmission. A policy that only watches one channel is usually a false sense of coverage.

Decision rule: If the content can still move outside the original SharePoint location in a way that would matter for privacy or compliance, add DLP and test it against real user workflows before relying on permissions alone.

Practitioner takeaway: For PHI, permissions reduce exposure to the repository, but DLP reduces exposure to the data itself, and that is the control difference that matters most.

Related resources from NHI Mgmt Group

• What breaks when organisations rely on SharePoint alone to manage PHI exposure?
• What breaks when organisations rely on SharePoint permissions instead of PII monitoring?
• Why do inline DLP programs struggle when organisations rely on proxies alone for cloud data protection?
• What breaks when organisations rely on policies alone instead of DLP for ISO 27001 PII protection?