SharePoint Permissions Stop at the Download Button: A DLP Guide for HR Data

An HR coordinator downloads the employee master spreadsheet to finish it at home. A manager saves a copy to personal OneDrive. Someone exports a CSV of employee records to a laptop. Payroll needs the file, so it gets emailed to an external address.

Same file. Same data. Four locations, and not one of them is the locked-down HR SharePoint site everyone points to when asked whether HR data is secure.

That is the gap this guide closes. By the end you will have a custom classifier that recognizes your HR data anywhere it goes and a DLP policy that acts on it, built step by step in Microsoft Purview.

Why the locked-down HR site is not the answer#

The standard setup sounds airtight: HR builds a secure SharePoint site, permissions are locked down, external sharing is disabled. On paper, done.

Then work happens, and the file starts moving through downloads, copies, exports, and emails. Sometimes it is not even the same file anymore: people tweak it, add tabs, paste rows into new documents. The data fragments and multiplies.

This is where the real data loss risk lives. Once a document leaves the HR site, site permissions no longer protect the data. You can have the cleanest SharePoint permissions model in the world and still leak HR data from OneDrive, local devices, and mailboxes.

The mindset shift that fixes it: Microsoft 365 does not protect locations. It protects data it can recognize. Locking down SharePoint is necessary, but it only protects data while it stays in the site. The moment HR data moves to a user's OneDrive, another SharePoint site, a Teams file, or an email attachment, the original security boundary is gone. And if Microsoft Purview cannot recognize the HR data itself, DLP cannot trigger, alerts will not fire, and policies will not block the movement. This is exactly why so many DLP projects stall: a few template policies get switched on, boxes get checked, and HR data keeps slipping through.

The two-part machine: classifiers and DLP#

Protecting HR data in motion takes two pieces working together:

• Classifiers tell Microsoft what to look for.
• DLP policies tell Microsoft what to do when it finds it.

Purview offers three main classifier approaches:

1. Sensitive Information Types (SITs): pattern-based detection, like credit cards, ABA routing numbers, or your own internal formats such as employee IDs.
2. Exact Data Match (EDM): table-based detection for database exports, CSVs, and structured datasets where you care about specific records.
3. Trainable Classifiers / Document Fingerprinting: content-based detection, where you feed Microsoft a large sample of documents (offer letters, pay stubs, performance reviews) and train it to recognize them over time.

For HR, we start with Sensitive Information Types because they are flexible, pattern-driven, and a great foundation for DLP policies.

Why HR almost always needs custom SITs#

Microsoft ships a long list of built-in SITs: credit card numbers, bank account numbers, government IDs. Useful, with two catches. They often generate a ton of false positives, and they almost never cover your internal HR constructs, employee IDs, staff IDs, internal reference numbers. Scroll the default SIT list and you will find very little that is truly HR-specific.

So protecting HR data nearly always means creating custom SITs that match your actual patterns. Say your employee IDs start with EMP-, followed by 4 to 6 digits, often near keywords like "Employee ID" or "Staff ID." That pattern shows up in employee master spreadsheets, team rosters, HR system exports, and onboarding documents. Teach Microsoft to recognize it and you suddenly have visibility into where HR data lives across SharePoint, OneDrive, Teams, and Exchange Online.

Not sure which data types to start with? Use this discovery worksheet to audit what you should prioritize protecting:

Get a copy of the worksheet (opens in new tab)

The licensing line you will hit#

• Microsoft 365 Business Premium includes DLP and the built-in sensitive info types, but not custom SITs.
• Enterprise plans (E5) or Purview add-ons unlock custom sensitive info types, which is what HR-specific classifiers like custom employee IDs require.

For organizations serious about HR data, especially regulated or higher-risk environments, the Purview add-on for Business Premium or enterprise licensing is usually worth it.

Step 1: Build the custom SIT#

1. Go to Data classification → Sensitive info types.
2. Click Create to build a new SIT.
3. Give it a meaningful name and description, for example name TMinus_EmployeeID with description Identifies internal employee IDs in HR documents.
4. Define a pattern:
   • Use a regular expression describing your employee ID format, structured like EMP-1234 or EMP-1234-5678.
   • Add supporting elements, nearby keywords such as "Employee ID", "Staff ID", and "Internal ID".
5. Set confidence levels: start at Medium while testing, then refine if you see too many false positives or missed matches.

You can also tune where in the document it looks (entire doc versus the first 300 characters) and how close supporting keywords must sit to the pattern. The target: specific enough to avoid noise, flexible enough to catch real-world variations.

Step 2: Prove it works before it can block anything#

Never put a blocking policy in front of an untested classifier. In the SIT testing experience, upload a mix of files:

• Files that should match: employee roster spreadsheets, employee record documents.
• Files that should not match: generic docs with random numbers, HR docs without IDs.

You want confident matches on the right files and no matches on the wrong ones. In our test run, the employee record and team roster both matched at Medium confidence, while a random file with no employee IDs returned "no sensitive information found." That is exactly the validation you need before moving on.

Step 3: Turn recognition into enforcement with DLP#

In Purview:

1. Go to Data Loss Prevention → Policies → Create policy.
2. Choose a Custom policy, not a template.
3. Name it, for example HR - Protect Employee IDs.
4. Select the locations to protect: Exchange email, SharePoint sites, OneDrive accounts, and Teams chats and channel messages.
5. Add a rule with conditions: when this content is shared from Microsoft 365 AND with people outside my organization AND the content contains your custom SIT (such as TMinus_EmployeeID), instances 1 to Any.
6. Choose the actions: restrict or encrypt content in those locations, block access for everyone or everyone external, trigger alerts and incident reports, and show policy tips to the user.
7. Turn the policy on in simulation mode first.

Simulation mode is not optional#

Skip simulation and two bad things happen: you block far more than you meant to (angry users, support tickets), or you discover the classifier was not ready and you have been enforcing on noisy matches.

Simulation mode shows you how many matches you would get across SharePoint and OneDrive, which locations actually hold the sensitive data, and whether reality matches your expectations. Use the results to tune scope and rules before anything gets blocked.

One more trick: exclude approved locations like the official HR SharePoint site from enforcement while still monitoring everywhere else. Now DLP is doing its real job, finding HR data where it should not be: personal OneDrives, random sites, outbound email.

What users and admins actually see#

When a user tries to email a file with employee IDs externally, Outlook shows a policy tip at the top of the message: "Your email conflicts with your organization's policy." Depending on configuration, you can block the send entirely, allow an override with justification (generally not recommended for very sensitive data), or just warn and log while the policy is still rolling out.

On the admin side, Purview raises alerts whenever users try to send or share protected HR content, with the details that matter: who sent it, what they tried to send, where it was headed, and which rule triggered. Governance and forensic visibility in the same place.

The same story, replayed with DLP on#

Run the opening scenario again. HR exports a spreadsheet with employee data, saves it to SharePoint, a copy gets downloaded, and someone emails it to payroll externally.

Without DLP and custom SITs, you are relying purely on people doing the right thing. SharePoint permissions helped only while the file stayed in the site, and you have almost no visibility once it spreads.

With DLP and custom SITs, Microsoft recognizes the employee IDs inside the file itself. The external email triggers the policy, and you choose the outcome: block it, warn the user, or log and alert for review.

Same people. Same workflow. Very different outcome.