In this module

AD4.1 Why Data Protection Is the Fourth Priority

5-6 hours · Module 4 · Free

Operational Objective

You've secured authentication (MFA + conditional access), email delivery (Safe Links + Safe Attachments + anti-phishing), and device health (compliance policies + CA enforcement). But all three layers protect access to data — none of them protect the data itself. A user who passes MFA, receives clean email, and uses a compliant device has full access to every document, spreadsheet, and email they can reach. They can download client contracts to a USB drive, forward financial reports to a personal email address, share an HR document with the entire organization, or accidentally email a spreadsheet of customer credit card numbers to a vendor. Data protection — sensitivity labels and DLP policies — classifies the data by sensitivity and enforces rules about what can be done with it, where it can be shared, and who can access it. This is the layer that protects the data after a legitimate user (or a compromised account that passed all three access controls) reaches it.

Deliverable: Understanding of what E3 data protection capabilities include, the deployment sequence for labels and DLP, and the specific data risks that this module addresses.

Estimated completion: 25 minutes

Figure AD4.1 — The four-layer defense model. Identity controls who signs in. Email controls what arrives. Devices control where access happens. Data protection controls what happens to the data itself — classification, encryption, sharing restrictions, and automated prevention of data loss. Without Layer 4, the data is unprotected once a user reaches it.

What E3 includes for data protection

Your M365 E3 license includes two data protection capabilities at no additional cost:

Microsoft Purview Information Protection (manual sensitivity labels). You can create sensitivity labels, publish them to users, and users can manually apply them to documents and emails in Office apps (Word, Excel, PowerPoint, Outlook). Labels can apply visual markings (headers, footers, watermarks) and encryption. You can set default labels so every new document starts with a label. You can configure mandatory labeling so users must choose a label before saving or sending. All of this is included in E3.

Microsoft Purview Data Loss Prevention (basic DLP). You can create DLP policies that detect sensitive information types (credit card numbers, national insurance numbers, passport numbers, and 300+ other types) in Exchange Online, SharePoint Online, and OneDrive for Business. When a match is found, the policy can notify the user (policy tip), notify the admin, block the action, or require a business justification override. This is included in E3.

What E3 does NOT include: auto-labeling policies (automatically applying labels based on content scanning — requires E5), Endpoint DLP (monitoring and blocking sensitive data on the device itself — clipboard, USB, printing — requires E5), DLP for Teams chat messages (requires E5), and trainable classifiers (machine learning-based content classification — requires E5). This module works entirely within E3 capabilities.

The practical difference between E3 and E5 data protection is manual vs automatic classification. On E3, users choose labels manually (with the default label handling most documents automatically). On E5, auto-labeling policies scan existing and new content for sensitive information types and apply labels without user involvement. E5 also extends DLP beyond email and SharePoint to endpoint devices (blocking USB copy of labeled content) and Teams chat (detecting credit card numbers pasted into chat messages). If your organization upgrades to E5 in the future, the labels and DLP policies you build in this module transfer directly — E5 adds automation on top of the E3 foundation, not a replacement.

The data risks this module addresses

Before deploying labels and DLP, understand the specific data risks in your environment. These are the incidents that happen in production:

Accidental external sharing. A user shares a SharePoint folder with a vendor to collaborate on a project. The folder also contains internal financial documents from a different project. The vendor now has access to financial data they should never have seen. Sensitivity labels with sharing restrictions prevent this — a document labeled "Internal" can't be shared externally, regardless of the folder it's in.

Email to wrong recipient. A user emails a spreadsheet of employee salary data to the wrong distribution list — the entire company sees it instead of just the HR team. DLP with sensitive information type detection catches the salary data (it matches patterns for national insurance numbers and salary amounts) and blocks the send with a policy tip: "This email contains sensitive personal data. Are you sure you want to send it to All Staff?"

Departing employee data exfiltration. An employee who has given notice downloads client lists, pricing spreadsheets, and engineering designs to their personal OneDrive or emails them to a personal address. DLP policies detect the bulk download or external email and alert the admin. Sensitivity labels with encryption ensure that even if the files are downloaded, they can't be opened outside the organization's domain.

Accidental public sharing. A user creates a SharePoint sharing link for a document and selects "Anyone with the link" instead of "People in your organization." The document is now accessible to anyone on the internet who has the link. SharePoint external sharing controls restrict the default sharing scope and require authentication for external access.

Checking your current data protection state

Before building labels and DLP, check what's already in place. Navigate to purview.microsoft.com → Solutions → Information Protection → Labels. If you see existing labels (Microsoft may have created default labels for your tenant since October 2025), review them before creating new ones — you may be able to use and modify them rather than starting from scratch.

Check for existing DLP policies: purview.microsoft.com → Solutions → Data Loss Prevention → Policies. If no policies exist, you're starting clean. If default policies exist, review what they detect and what actions they take — some default policies are in audit mode and need to be switched to enforcement.

Check your SharePoint external sharing configuration: navigate to admin.microsoft.com → SharePoint → Sharing. Note the current setting: "Anyone" (most permissive — anonymous links), "New and existing guests" (requires authentication), "Existing guests" (only guests already in your directory), or "Only people in your organization" (no external sharing). Record this setting — you'll tighten it in AD4.6.

Connect-SPOService -Url https://northgateeng-admin.sharepoint.com
Get-SPOTenant | Select-Object SharingCapability, DefaultSharingLinkType,
    DefaultLinkPermission, RequireAcceptingAccountMatchInvitedAccount |
    Format-List

This shows your current SharePoint sharing configuration: who can share, what the default link type is, and whether external recipients must authenticate. These settings form the baseline that you'll tighten in this module.

Discovering what sensitive data you already have

Before building DLP policies, understand what sensitive data exists in your environment right now. Microsoft Purview includes a basic content scan that identifies sensitive information types in Exchange, SharePoint, and OneDrive — even without DLP policies deployed.

Navigate to purview.microsoft.com → Data Classification → Overview. If data classification is enabled (it's on by default for E3), the dashboard shows: total sensitive content items discovered, the most common sensitive information types found, and the locations with the most sensitive content.

If the dashboard is empty, data classification scanning may need time to complete its initial scan (up to 14 days for large tenants). Check back after a week.

The dashboard answers a critical question: where is your sensitive data right now? If it shows 500 documents containing credit card numbers in SharePoint, you know exactly which sites need DLP attention. If it shows 2,000 emails with National Insurance Numbers, you know the volume of sensitive data flowing through email. This data shapes your DLP policy priorities — protect the most common sensitive data types first.

Additionally, check whether Microsoft has already created default sensitivity labels for your tenant. Since late 2025, new tenants and eligible existing tenants receive default labels automatically. Navigate to purview.microsoft.com → Information Protection → Labels. If you see labels like "Public," "General," "Confidential," and "Highly Confidential" that you didn't create, Microsoft deployed them. Review the settings — they may align with your taxonomy or need modification. Don't create duplicate labels if defaults already exist; modify the existing ones to match your requirements.

Compliance Myth: "Data protection is only needed for regulated industries like healthcare and finance"

Every organization has data that shouldn't be shared externally — client contracts, employee records, financial reports, pricing strategies, intellectual property. GDPR applies to every organization that processes personal data of EU/UK residents (which includes employee data). The question isn't whether you have sensitive data — it's whether you know where it is and who has access to it. Sensitivity labels answer the first question (classification). DLP policies answer the second question (enforcement). Regulation is one driver, but accidental data exposure affects every organization regardless of industry.

The deployment sequence for data protection

Data protection follows the same phased approach as the previous modules: design first (label taxonomy), then deploy in monitor mode (labels without enforcement, DLP in audit), then enforce (mandatory labeling, DLP blocking).

The sequence for this module: design the label taxonomy (AD4.2 — 4 labels, simple and clear), create and publish labels (AD4.3 — Purview portal walkthrough), configure protection settings (AD4.4 — encryption, watermarks, content marking), set default and mandatory labeling (AD4.5 — every document gets a label), tighten SharePoint sharing (AD4.6 — restrict external sharing by default), build DLP policies (AD4.7 — audit mode first for 2 weeks), configure policy tips (AD4.8 — educating users when they almost share something they shouldn't), then monitor and report (AD4.9-AD4.10).

Total deployment time: 2-3 weeks. Week 1 for label design, creation, and publishing (labels appear in Office apps within 24 hours of publishing). Week 2 for DLP policies in audit mode and SharePoint sharing controls. Week 3 for DLP enforcement after reviewing audit data. Don't rush week 2 — the audit data from DLP policies in simulation mode is critical for identifying false positives before you enable blocking. Enforcing DLP without audit data is the data protection equivalent of enabling ASR rules in block mode without testing: it will break legitimate workflows and generate support tickets that undermine the program's credibility.

Decision point

You're about to start deploying sensitivity labels. Your manager asks: "Should we wait until we have E5 so we can use auto-labeling? Manual labeling depends on users remembering to label their documents." How do you respond?

Option A: Wait for E5 — auto-labeling is more reliable than manual labeling.

Option B: Deploy manual labels now on E3, then add auto-labeling later if E5 becomes available. Manual labeling with default labels covers 80%+ of documents because the default label applies automatically to every new document — the user only changes it when the content warrants a different classification.

The correct answer is Option B. Default labeling means every new document starts with a label (typically "Internal") without any user action. The user only needs to manually change the label when the content is more sensitive (Confidential) or less sensitive (Public). With default labeling, 80%+ of documents are correctly labeled without auto-labeling because most documents are internal — the default is correct. Auto-labeling (E5) adds value for retroactively labeling existing documents and for catching misclassified content, but it's an enhancement, not a prerequisite. Deploy now, improve later.

Try it: Assess your current data protection state

Run these four checks and record your baseline:

1. Sensitivity labels: purview.microsoft.com → Information Protection → Labels. Count existing labels (0 = starting fresh, 4+ = review existing). 2. DLP policies: purview.microsoft.com → Data Loss Prevention → Policies. Count existing policies and note their mode (audit or enforce). 3. SharePoint sharing: admin.microsoft.com → SharePoint → Sharing. Record the current external sharing level. 4. PowerShell sharing check: Run Get-SPOTenant | Select SharingCapability and record the result.

These four data points are your data protection baseline. After deploying labels, DLP, and sharing controls in this module, measure the same metrics — the delta shows the improvement for your quarterly management report.

A user on a compliant device with valid MFA emails an Excel spreadsheet containing 200 customer credit card numbers to an external vendor. No DLP policies are configured. What happens?

MFA blocks the email because it contains sensitive data — No. MFA authenticates the user's identity. It doesn't inspect email content.

Safe Attachments blocks the email because it detects credit card numbers — No. Safe Attachments scans for malware, not sensitive data content. It detonates attachments in a sandbox looking for malicious behavior, not PII.

Device compliance blocks the email because the content is sensitive — No. Device compliance checks the device health (encryption, OS, firewall, AV). It doesn't inspect email content.

The email is delivered successfully — no control inspects the content for sensitive data, so the credit card numbers reach the external vendor without any warning or block — Correct. Without DLP policies, there is no content inspection. Layers 1-3 (identity, email, device) control access and delivery, not content. Layer 4 (data protection with DLP) is the control that detects credit card numbers in outbound email and blocks or warns. This is exactly the gap this module fills.

Operational Artifact — Data Protection Deployment Sequence

Phase 4 of your security improvement plan: design label taxonomy (AD4.2), create and publish labels (AD4.3), configure protection settings (AD4.4), enable default labeling (AD4.5), tighten SharePoint sharing (AD4.6), deploy DLP in audit mode (AD4.7), configure policy tips (AD4.8), enforce DLP after 2-week audit (AD4.9). Total deployment: 2-3 weeks. Prerequisites: Modules AD1-AD3 complete (identity, email, device layers operational). All capabilities in this module are included in E3 — zero additional licensing cost.

You're reading the free modules of M365 Security: From Admin to Defender

The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts.

View Pricing See Full Syllabus

← Previous Next →