SharePoint Online DLP policies decide who can share a file. Strac decides what leaves it, redacting sensitive data across SharePoint, Copilot, and every app.
.webp)
SharePoint Online DLP is any control that detects sensitive content stored in SharePoint and acts on it before it leaves the people who should see it. Natively, that means Microsoft Purview DLP policies scoped to SharePoint sites, working alongside sensitivity labels, sharing settings, and site permissions.
SharePoint is where Microsoft 365 keeps its documents. Teams files live in it, OneDrive shares the same engine, and Copilot grounds its answers in it. A policy that protects SharePoint therefore protects much more than one app, and a gap in SharePoint shows up everywhere Microsoft 365 reaches.
The distinction worth holding on to is simple. A permission decides who can open a file. DLP decides what may happen to the data inside it. For the broader picture, including where the native model stops, read SharePoint data security.
SharePoint Online DLP is any control that detects sensitive content stored in SharePoint and acts on it before it leaves the people who should see it. Natively, that means Microsoft Purview DLP policies scoped to SharePoint sites, working alongside sensitivity labels, sharing settings, and site permissions.
SharePoint is where Microsoft 365 keeps its documents. Teams files live in it, OneDrive shares the same engine, and Copilot grounds its answers in it. A policy that protects SharePoint therefore protects much more than one app, and a gap in SharePoint shows up everywhere Microsoft 365 reaches.
The distinction worth holding on to is simple. A permission decides who can open a file. DLP decides what may happen to the data inside it. For the broader picture, including where the native model stops, read SharePoint data security.
Three shifts turned SharePoint from a document store into an exposure surface.
The first is sprawl. Every Team creates a site, every project creates a library, and permissions are inherited, broken, and re-granted until nobody can say who has access to what. The second is sharing by link. "Anyone" and "People in your organization" links are convenient and rarely expire, so a file shared once for a quarterly review stays reachable for years.
The third is AI. Microsoft 365 Copilot respects permissions, which sounds reassuring until you remember that the permissions were never cleaned up. Copilot does not create oversharing; it makes oversharing searchable in plain English. The same is true of any AI agent connected to SharePoint through Microsoft Graph or an MCP server, covered in depth in Microsoft Copilot security.
Native controls are worth configuring well before anything else is added. In the Microsoft Purview portal, open Data loss prevention, then Policies, and create a policy. The steps below follow the order the wizard uses.
Choose the template or start custom. Regulatory templates for HIPAA, PCI DSS, GDPR, and US financial data give you a working set of sensitive information types. A custom policy lets you add your own types, such as customer IDs, contract numbers, or project code names.
Scope the locations. Select SharePoint sites and apply the policy to all sites or to named ones. Start with the libraries that hold regulated data: finance, HR, legal, and customer success. Add OneDrive accounts and Teams chat and channel messages when the same data travels there.
Define the conditions. Combine sensitive information types, trainable classifiers, and sensitivity labels with a minimum instance count and a confidence level. "Ten or more card numbers at high confidence" behaves very differently from "any card number."
Set the actions. Restrict access for people outside the organization, block external sharing, or block everyone except the owner and last modifier. Scope the Microsoft 365 Copilot location so labeled content is excluded from Copilot processing.
Write the policy tips and alerts. A policy tip explains to the user, in the document itself, why the action was flagged. Alerts route matches to the security team with the severity and the volume threshold you choose.
Run it in simulation mode first. Simulation shows what the policy would have matched without enforcing anything. Review the matches, tune the conditions, then turn on enforcement.
For the tenant-wide version of this walkthrough, see how to implement a data loss prevention policy in Microsoft 365 and the licensing notes in Microsoft Purview DLP.
Classify before you enforce. Apply sensitivity labels to the libraries that matter and use them as policy conditions. A labeled file carries its classification into Copilot, email, and downloads.
Limit sharing at the site level. Set external sharing on sensitive sites to existing guests only, set default links to specific people, and put an expiry on "Anyone" links where you keep them at all.
Clean up before Copilot rollout. Review sites with broken inheritance, "Everyone except external users" grants, and stale guest accounts. Restricted Content Discovery keeps named sites out of Copilot and organization-wide search while you fix them.
Watch the overrides. Every override with a business justification is a signal. A rule that is overridden weekly is either wrong or describing a real workflow you need to support.
Review Activity explorer and the DLP alerts queue. Filter for policy matches, overrides, and file egress by site. Trends tell you where to tighten; false positives tell you where to loosen.
Train the people behind the policy tips. A user who understands why a share was restricted finds the approved path. A user who does not finds a personal account.
Purview policies are good at permission decisions inside Microsoft 365. The limits are structural, not configuration mistakes, and they are covered in detail in Office 365 DLP limitations.
Native DLP restricts the file; it does not remove the data. A spreadsheet with one column of Social Security numbers is either blocked in full or shared in full. There is no option to share the file with the sensitive column masked.
Coverage stops at the tenant. The same customer export can be downloaded, pasted into ChatGPT, dropped in Slack, or uploaded to a personal Google Drive, and each of those needs its own tool and its own policy language.
Image content is inconsistent. A screenshot of a card number, a scanned ID, or a photographed contract in a library needs OCR, and coverage depends on licensing and location.
Enforcement depends on the right license tier across every user. Mixed licensing produces mixed protection, and the gaps are rarely where you expect.
Blocking tells you a file cannot leave. Redaction lets it leave safely. The first stops collaboration; the second keeps it going without the regulated fields.
Finding sensitive data is only half the job. The bigger SharePoint risk is who can reach it: a document shared with "Anyone with the link," a site opened to external guests, an OneDrive folder inherited from a departed employee. Native SharePoint tells you a file was shared; it does not fix the exposure. Strac does.
Strac runs four jobs across SharePoint and OneDrive:
Strac connects to SharePoint through the SharePoint DLP integration with API-based, agentless access. It scans every site and library, historical and new, using detectors from the catalog of sensitive data elements for PII, PHI, PCI, credentials, and source code. OCR reads images, and deep inspection covers PDF, DOCX, XLSX, PPTX, and ZIP contents.
When a file matches a policy, Strac acts on the data and the permission together:
The controls above govern data already in SharePoint. Strac’s endpoint agent closes the two paths a file travels between a laptop and SharePoint, before it ever lands:
Paired with the SaaS controls, sensitive data is governed on the way in, at rest, and on the way out. See endpoint DLP for the full 13-channel enforcement model.
A SharePoint-only control is a SharePoint-shaped hole. The same file leaves through several other doors, and Strac covers each with the same detectors and one policy.
Every surface above maps to evidence for HIPAA, PCI DSS, SOC 2, ISO 27001, GDPR, and CCPA, and most teams see live scanning within minutes of connecting SharePoint.
Microsoft 365 Copilot reads across SharePoint and OneDrive to answer prompts, and AI agents now reach the same data through the Microsoft 365 MCP server and the SharePoint MCP server. Any sensitive file sitting in an over-shared site is now instantly retrievable by an assistant.
Strac closes both the human path and the AI path: it redacts sensitive data at the source, and inspects the Copilot / MCP retrieval so what the assistant returns is already clean, with per-user identity enforced. See MCP DLP and AI DLP.
| Capability | Native SharePoint / Purview | Strac |
|---|---|---|
| Detect PII/PHI/PCI in files & lists (OCR) | Partial | Yes |
| Find public links & external/guest sharing | Partial | Yes |
| Remove public access automatically | No | Yes |
| Revoke external / guest members | No | Yes |
| Redact sensitive data inside a file | No | Yes |
| Alert owner + security in Slack / Teams | No | Yes |
| Protect Copilot & MCP-agent retrieval | No | Yes |
| Licensing | E5 for full DLP | Any tier, agentless |
Strac closes the gap behind both native policy and the data inside the file. Start at Office 365 data loss prevention, or compare approaches in the SharePoint security tool guide.
Permissions, sharing settings, and labels all fail eventually. A link outlives its purpose, a site inherits the wrong group, and Copilot reads a library nobody reviewed. The data layer is the backstop: redact the sensitive fields, revoke the links that should not exist, and apply one policy everywhere a SharePoint file can travel, and an overshare never becomes a breach.
Book a demo to see Strac protect the data in your SharePoint Online.
SharePoint data does not only leak through sharing; it leaks through the AI tools employees paste it into. Strac pairs SharePoint DLP with Shadow AI discovery and AI data governance, so you see every GenAI tool in use and govern what data can reach it. See Shadow AI and AI data governance.
Mostly. SharePoint Online DLP is Purview DLP scoped to SharePoint sites. Purview defines the policy; SharePoint is one of the locations it enforces in, alongside OneDrive, Exchange, Teams, endpoints, and Copilot.
Because Purview restricts files and permissions inside Microsoft 365. It does not redact the sensitive fields, and it does not follow the data into Slack, Google Workspace, personal clouds, or browser AI tools. Strac adds that data layer across every surface.
Yes, by redacting rather than blocking. Strac masks the regulated fields and lets the share proceed with a short explanation to the user. The contract reaches the partner; the Social Security numbers stay behind.
Not on its own. Copilot inherits whatever permissions exist, and permission cleanup is never finished. That is why the data layer matters: redact sensitive fields at rest and in responses, and an overshared file stops being a disclosure.
It is one location in a tenant-wide program, not a standalone project. The same detectors should cover SharePoint, OneDrive, Teams, Outlook, and Copilot. See Office 365 data loss prevention and secure file sharing in Microsoft 365 for the full picture.
Comparing options? See the best SharePoint & OneDrive DLP solutions.
.avif){kind=icon}
.gif)
