Microsoft Purview: Enterprise Implementation Guide

Audience: IT Administrators, Security Engineers, Compliance Officers, and Technical Implementation Leads.

Assumed knowledge: A foundational understanding of Microsoft 365 services (Exchange, SharePoint, Teams), general IT administration concepts, and basic PowerShell. This guide will provide context for all Purview-specific features.

Scope: This guide provides a detailed, step-by-step procedure for implementing a comprehensive data governance framework using the core components of the Microsoft Purview suite within a Microsoft 365 E5/A5 environment. It covers the entire lifecycle from foundational policy decisions to advanced monitoring.

Out of scope: This guide does not cover advanced API integration with third-party systems, detailed migration strategies from other security platforms, or deep architectural planning for the Azure Purview Data Map (though its relationship is explained).

TL;DR

Foundation & Governance: Make strategic decisions on data classification, establish auditing, and set up compliance tracking.
Know & Protect: Discover sensitive data with SITs and classifiers, then apply Sensitivity Labels with encryption to protect it at the source.
Access Control & Sharing: Secure the containers (SharePoint sites, Teams) where data lives—harden sharing settings, implement site lifecycle governance, and enable Copilot protection.
Monitoring & Investigation: Leverage Insider Risk Management, Audit Logs, Retention policies, and eDiscovery to maintain visibility and respond to incidents.
Prevention & External Controls (Later): Implement DLP, Communication Compliance, and Power Platform controls—these are significant undertakings that may overlap with existing tools (Proofpoint, CASB).
Prepare for AI: A well-governed Purview environment is the critical foundation for securely deploying Microsoft Copilot.

Implementation Roadmap

This guide is structured to prioritize internal data protection and Copilot readiness first, followed by monitoring, and finally external prevention controls that may require coordination with existing security tools.

Implementation Priority

Phases 0-6 should be completed first to secure your data and prepare for Copilot. Phases 7-9 provide monitoring and legal capabilities. Phases 10-12 (DLP, Communication Compliance) are significant undertakings that may overlap with existing tools like Proofpoint DLP, Elastic SIEM, or third-party CASB solutions—coordinate with those teams before implementing.

Background & Context

In the modern enterprise, data is everywhere: in emails, chat messages, cloud files, and applications. This data sprawl, combined with increasingly stringent regulations and the rise of powerful AI tools, creates a significant governance challenge. Without a clear strategy, organizations risk data breaches, regulatory fines, and the misuse of sensitive information.

The Zero Trust security model provides the guiding principle: "never trust, always verify." This means we must move beyond protecting the network perimeter and apply protection directly to the data itself. Microsoft Purview is the suite of tools that enables this data-centric Zero Trust approach within the Microsoft 365 ecosystem.

This guide serves as a complete playbook for implementing Purview. It is designed for the technical implementers who will configure the system, but it begins with the strategic decisions that must be made by leadership to ensure the technology is aligned with the organization's goals. Following this guide will establish a robust and repeatable framework for data governance, information protection, and compliance.

Prerequisites

Requirement	Minimum / Version	Notes
Licensing	Microsoft 365 E5/A5	Or equivalent compliance add-ons (e.g., E5/A5 Compliance, E5/A5 Information Protection & Governance). This guide assumes full A5 licensing which includes all Purview features.
Permissions	Appropriate admin roles	The initial setup may require `Global Administrator`. Subsequent phases require roles like `Purview Administrator`, `Compliance Administrator` or `Security Administrator`. This guide advocates for using least-privileged roles for each phase.
Environment	Microsoft 365 Tenant	A functioning tenant with Exchange Online, SharePoint Online, OneDrive for Business, and Microsoft Teams.
Compliance Manager Templates	FERPA, HIPAA, NIST 800-171	Premium templates may be needed for specific assessments. A5 includes 3 premium templates. [6]
PowerShell Modules	Latest stable versions	This guide uses PowerShell for automation and advanced configuration. Key modules include `Microsoft.Graph.Identity.Directory` for roles and the `ExchangeOnlineManagement` module for connecting to the compliance endpoint.

A5 Features Covered in This Guide

Feature	Phase	Part	Notes
Unified Audit Log (Premium)	Phase 1	Foundation	1-year retention, advanced events
Customer Lockbox	Phase 1	Foundation	Microsoft engineer access control
Privileged Access Management (PAM)	Phase 1	Foundation	Just-in-time admin access
Compliance Manager	Phase 1.5	Foundation	Compliance score and assessments
Sensitive Information Types	Phase 2	Know & Protect	Custom and built-in classifiers
Trainable Classifiers	Phase 2	Know & Protect	ML-based document classification
Data Security Posture Management	Phase 2.5	Know & Protect	Unified risk dashboard
SharePoint Advanced Management	Phase 3	Access Control	Site lifecycle, sharing governance
Sensitivity Labels + Encryption	Phase 4	Access Control	Rights management, visual marking
Customer Key / DKE (Optional)	Phase 4.5	Access Control	Customer-managed encryption keys
Conditional Access + MDCA	Phase 5	Access Control	Zero Trust enforcement
Information Barriers	Phase 5.5	Access Control	Ethical walls between groups
Restricted Content Discovery	Phase 6	Access Control	Copilot protection, search restrictions
Insider Risk Management	Phase 7	Monitoring	Behavioral analytics, risk detection
Adaptive Protection	Phase 7.5	Monitoring	Dynamic DLP based on risk level
Records Management	Phase 8	Monitoring	File plans, disposition review
eDiscovery Premium	Phase 9	Monitoring	Legal hold, review sets, custodians
Data Loss Prevention (DLP)	Phase 10	Prevention	Multi-location policy enforcement
Endpoint DLP	Phase 10	Prevention	Device-level data protection
Power Platform DLP	Phase 11	Prevention	Connector-based data policies
Communication Compliance	Phase 12	Prevention	Email/Teams content monitoring

PAYG / Add-On Features (Optional)

Feature	Phase	Part	Licensing
Microsoft Priva	Phase 16	Extensions	Pay-per-request
Azure Purview (Unified Data Governance)	Phase 14	Extensions	Azure subscription + scanning costs
Extended Audit Log Retention (10 years)	Phase 1	Foundation	Add-on to A5

Part 1: Foundation & Governance

This section establishes the strategic and technical foundation for your Purview implementation. Complete these phases first before moving to data protection.

Phase 0: Leadership and Policy Decisions

Phase Objective

Establish the strategic foundation for your Purview implementation by documenting leadership decisions on data classification, security posture, DLP philosophy, retention strategy, AI governance, monitoring scope, and platform role assignments. These decisions directly drive all subsequent technical configuration.

Decision Point

This is the most critical phase of the entire implementation. The technical configuration in subsequent phases is a direct translation of the strategic decisions made here. Without clear, documented answers from leadership, the project risks being misaligned with the unique needs of a Tier 1 Research University (compliance with FERPA, HIPAA, NIST 800-171/CMMC, ITAR) and state laws (Texas Public Information Act).

Decision 1: Define the Data Classification Standard

Why It Matters: In a university environment, "one size fits all" fails. A simple corporate "Confidential" label is insufficient when you must distinguish between student records (FERPA), health data (HIPAA), and export-controlled research (ITAR). This decision defines the "Digital Price Tags" for your data, directly impacting how research is shared and protected.

Best Practice / Recommendation: Adopt a Higher Education Model that balances openness for fundamental research with strict controls for regulated data.

The Decision to be Made: Choose a classification taxonomy.

Option	Pros	Cons	Recommended For
A: Corporate Simple (e.g., `Public`, `Internal`, `Confidential`)	Simple for general staff. Fast adoption.	Fails to distinguish between types of regulated data (e.g., FERPA vs. HIPAA), making it hard to apply specific encryption rules required for grants.	Administrative departments with no research or student data handling.
B: Higher Ed & Research (e.g., `Public`, `General`, `Confidential - FERPA`, `Restricted - Research/HIPAA`)	Allows granular control: "Confidential" restricts external sharing but allows internal access; "Restricted" applies heavy encryption for CUI/ITAR. Aligns with grant requirements.	Requires training users to distinguish between "Confidential" and "Restricted."	Strongly Recommended for Texas A&M. This supports both open collaboration and strict compliance.

Decision 2: Establish the Default Security Posture

Why It Matters: Universities are collaborative by nature, but "Open by Default" creates massive liability. With the rise of AI (Copilot) and ransomware, a permissive environment allows threats to spread laterally. This decision determines if new SharePoint sites and Teams are "fortresses" or "public squares."

Best Practice / Recommendation: Adopt a Balanced Default. While "Secure by Default" is ideal for corporate, it can stifle academic collaboration. A balanced approach protects identity but allows controlled collaboration.

The Decision to be Made: Define your baseline security settings.

Option	Pros	Cons	Recommended For
A: Permissive (Open) (Sharing: "Anyone" links allowed; Default Label: None)	Zero friction for faculty collaboration.	High risk of data leaks (e.g., Student UINs exposed). AI tools will surface sensitive data to unauthorized users.	Not Recommended. Creates unacceptable risk for a state institution.
B: Balanced (Identity-Based) (Sharing: "New/existing guests"; Default Label: "General")	Requires authentication for all access (no anonymous links). Allows external collaboration with peers.	Users must invite collaborators explicitly.	Recommended. Balances the need for global research collaboration with the requirement to audit access.
C: Restrictive (Fortress) (Sharing: "Internal only"; Default Label: "Restricted")	Maximum security. Aligns with NIST 800-171.	Breaks fundamental research workflows. Faculty will move data to non-approved IT (Shadow IT) to get work done.	Only for specific Secure Enclaves handling CUI/ITAR data.

Decision 3: Determine the Data Loss Prevention (DLP) Philosophy

Why It Matters: Faculty often share large datasets. If a DLP policy blocks a legitimate grant proposal because it "looks like" PII, IT becomes the enemy. Conversely, failing to block SSN exfiltration is negligence.

Best Practice / Recommendation: Warn with Override. This approach respects the user's intent while creating an immutable audit trail.

The Decision to be Made: Choose an enforcement model.

Option	Pros	Cons	Recommended For
A: Strict Block	Zero tolerance for data egress.	High false positives will disrupt grant applications and faculty work.	Only for SSNs and Credit Card Numbers.
B: Warn with Override	Educates users ("Did you mean to send this?"). Allows legitimate business/research to proceed. Logs the justification for audit.	Relies on user honesty.	Recommended for most data types (FERPA, Intellectual Property).

Decision 4: Define Retention & Records Strategy

Why It Matters: As a state entity, Texas A&M is subject to the Texas Public Information Act (FOIA) and State Records Retention schedules. Keeping everything forever ("Digital Hoarding") makes FOIA requests expensive and exposes the university to liability. Deleting too soon violates state law.

Best Practice / Recommendation: Automated Lifecycle. Differentiate between "transient" communication and "official" records.

The Decision to be Made: Choose a lifecycle strategy.

Option	Pros	Cons	Recommended For
A: Hoard Everything (Retain Forever)	"Safe" from accidental deletion.	Massive storage costs. Nightmare scenario for FOIA/eDiscovery search and review costs.	Not Recommended.
B: Targeted Retention (Teams Chats: 1 Year; Official Records: 7+ Years)	Reduces "noise" in legal searches. Aligns with the informal nature of Chat vs. formal Records.	Users must understand that Chat is not a filing cabinet.	Recommended. Treat Teams Chat as ephemeral (1 year) and Email/SharePoint as long-term storage (State Record retention).

Decision 5: AI & Copilot Governance Stance

Why It Matters: Microsoft Copilot respects user permissions too well. If a sensitive HR document is shared with "Everyone" (a common error), Copilot will summarize it for any student worker who asks. We must "sanitize" the environment before unleashing AI.

Best Practice / Recommendation: Restricted Content Discovery (RCD). Identify high-risk sites (HR, Legal, Dean's Offices) and strictly hide them from AI indexing.

The Decision to be Made: Choose an AI readiness posture.

Option	Pros	Cons	Recommended For
A: Open Access	Instant ROI on Copilot features.	High risk of internal data leakage (Salary data, Student grades).	Only for environments with perfect permission hygiene (Rare).
B: Restricted Discovery	Proactively hides sensitive sites from AI/Search. Prevents accidental oversharing.	Users must navigate directly to sensitive files; they won't appear in general search.	Strongly Recommended. Secure the "Crown Jewels" (HR/Legal) immediately using RCD policies.

Decision 6: Insider Risk & Communication Monitoring Scope

Why It Matters: Microsoft Purview includes powerful tools to detect insider threats (Insider Risk Management) and monitor communications for policy violations (Communication Compliance). However, these tools raise significant privacy concerns that must be addressed by leadership before deployment. [4][5]

Best Practice / Recommendation: Targeted Deployment with Privacy Controls. Start with high-risk scenarios (departing employees, export-controlled research) and enable pseudonymization to protect user privacy during investigations.

The Decision to be Made: Define the monitoring scope and privacy posture.

Option	Pros	Cons	Recommended For
A: No Monitoring	Maximum privacy. No risk of misuse.	Blind to insider threats. Cannot detect data exfiltration by departing employees.	Not Recommended given regulatory requirements.
B: Targeted High-Risk	Focuses on departing users, CUI handlers, and specific policy violations. Pseudonymizes identities until escalation.	Requires HR integration for departure signals.	Recommended. Balances security with privacy expectations.
C: Broad Monitoring	Maximum visibility across all users and communications.	Privacy concerns. May create hostile environment if perceived as surveillance. Faculty governance issues.	Only for specific regulated enclaves with explicit consent.

Decision 7: Purview Platform Role Assignments

Why It Matters: Microsoft Purview has its own Role-Based Access Control (RBAC) system that is separate from Entra ID administrative roles. These Purview-specific roles control who can configure policies, investigate cases, view sensitive content, and manage compliance features. Without clear role assignments, you risk either over-privileged accounts (security risk) or under-privileged admins who cannot complete their work.

Best Practice / Recommendation: Adopt a Functional Role Separation model where roles align to job functions. Use Privileged Identity Management (PIM) for just-in-time access to high-privilege roles.

The Decision to be Made: Define your Purview RBAC strategy and identify role holders.

Role	Capability	Typical Assignees	Privacy Consideration
`Compliance Administrator`	Full Purview access - policies, labels, DLP, retention	Compliance Lead (1-2 people max)	Can configure all policies
`Information Protection Admin`	Sensitivity labels, DLP policies, auto-labeling	Security/Compliance analysts	Cannot see content, only policy config
`eDiscovery Manager`	Case-level investigation access	Legal team members	Can see content within assigned cases
`eDiscovery Administrator`	All cases + case administration	Legal IT liaison (1-2 people)	Can access ALL eDiscovery cases
`Records Management`	Retention policies, file plans, disposition	Records Management team	Can manage lifecycle but not content
`Insider Risk Management Analyst`	IRM case investigation	HR Security liaison	Can see behavioral patterns; enable pseudonymization
`Communication Compliance Analyst`	Review flagged communications	HR/Compliance reviewers	Can read flagged messages
`Content Explorer List Viewer`	See where sensitive data exists (file names only)	Auditors, compliance staff	Cannot see actual content
`Content Explorer Content Viewer`	See actual sensitive content in Content Explorer	Limited investigators	High privilege - assign sparingly
`Audit Manager`	Search and export audit logs	Security Operations	Can see all activity logs

Critical Considerations:

Content Explorer Content Viewer grants the ability to see the actual sensitive content discovered by Purview—assign this role only to personnel with a demonstrated need
eDiscovery Administrator can access ALL cases across the organization—typically limit to 1-2 people with documented justification
Consider Privileged Identity Management (PIM) for just-in-time activation of high-privilege roles like eDiscovery Administrator
Document justification for each role assignment in your governance records

Approach	Description	When to Use
A: Minimal	Only 2-3 people with Compliance Administrator	Small teams, limited compliance staff
B: Functional (Recommended)	Roles aligned to job functions (Legal→eDiscovery, HR→IRM, Records→Retention)	Medium to large organizations with clear separation of duties
C: Granular	Detailed role assignments with strict content viewer separation and PIM	Large organizations with strict least-privilege requirements

Phase 1: Foundational Setup - Tenant Preparation & Licensing

Decision Point

This phase implements the Roles & Responsibilities decisions made in Phase 0, including Decision 7 (Purview Platform Role Assignments). Leadership must identify the personnel who will be assigned powerful administrative roles like Purview Administrator, Compliance Administrator, eDiscovery Manager, and specialized roles like Content Explorer Content Viewer. The technical team will then execute these assignments based on that direction.

Background & Context

Think of this phase as checking the foundation of a house before you start building. If the foundation is weak, everything built on top of it is at risk. For a Purview implementation, the foundation consists of three pillars:

Licensing (The "Tools"): We must verify the Microsoft 365 A5 licenses. In Higher Ed, this is critical because A5 unlocks the 1-Year Audit Log retention (essential for academic year investigations) and automated classification features that save limited staff time.
Auditing (The "Security Cameras"): The Unified Audit Log is the central security camera system for the entire Microsoft 365 environment. Without it, you are operating blind. Investigating a security incident, proving compliance to a State Auditor, or understanding the impact of a policy becomes impossible.
Permissions (The "Keys"): Using a Global Administrator account for daily tasks is a massive security risk. This phase focuses on the principle of least privilege, where we assign specific "keys" (admin roles like Purview Administrator or Compliance Administrator) to the people who need them.

Prerequisites

Requirement	Minimum / Version	Notes
Role / Permission	`Global Administrator`	Required for initial role assignment. Do not use for daily tasks.
PowerShell Module	`ExchangeOnlineManagement`	V3.0.0+. Required for Audit Log configuration.
PowerShell Module	`Microsoft.Graph`	Required for Identity and Group management.

Procedure / Implementation

Step 1 – Verify and Assign Licenses

Goal: Ensure the admin account and pilot users have the A5 license required to test advanced features like Auto-Labeling and Endpoint DLP.

Click-Ops (Microsoft 365 Admin Center):

Navigate to https://admin.microsoft.com.
Go to Users > Active users.
Select your admin account.
Click the Licenses and apps tab.
Verify Microsoft 365 A5 for Faculty (or Student) is checked.

PowerShell (Bulk Verification):

# Connect to Microsoft Graph
Connect-MgGraph -Scopes User.Read.All

# Check License for a specific user
$User = Get-MgUser -UserId "admin@tamu.edu" -Property AssignedLicenses
$User.AssignedLicenses | Select-Object SkuId

# A5 SkuId typically starts with "e97c048c..." (varies by tenant type)
# Use Get-MgSubscribedSku to map IDs to Names

Step 2 – Enable the Unified Audit Log (Premium)

Goal: Turn on the "Black Box" recorder. We also enable Audit (Premium) features to ensure we capture critical forensic data like MailItemsAccessed (did the hacker actually read the email?) and extend retention to 1 year.

Click-Ops (Purview Portal):

Navigate to https://purview.microsoft.com.
Select Audit in the left navigation.
If you see a banner: "Start recording user and admin activity", click Start recording.
Note: If the banner is gone, auditing is active.

PowerShell (Enable & Configure Premium):

Connect-ExchangeOnline

# 1. Enable the Root Log Ingestion
Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true

# 2. Enable Audit (Premium) for High-Value Users (Faculty/Staff)
# This forces the capture of "MailItemsAccessed" and "Send" events.
# Critical for investigating compromised accounts in a university setting.
$HighValueUsers = Get-Mailbox -ResultSize Unlimited -Filter {RecipientTypeDetails -eq "UserMailbox"}

foreach ($User in $HighValueUsers) {
    Set-Mailbox -Identity $User.Identity -AuditEnabled $true -AuditLogAgeLimit 365.00:00:00
}

Write-Host "✅ Audit Log Enabled with 1-Year Retention for all users." -ForegroundColor Green

Step 3 – Assign Purview Roles (Least Privilege)

Goal: Stop using Global Admin. Create a dedicated Purview Administrator who can manage policies but cannot see the content of files (protecting privacy).

Click-Ops (Purview Portal):

Go to Settings > Roles & scopes > Role groups.
Search for Purview Administrator.
Click Edit > Choose users > Add.
Select your admin account (or a specific "Purview Admin" identity).
(Optional) Use Security Groups instead of direct user assignment for increased flexibility and assignment of RBAC permissions.

PowerShell (Microsoft Graph):

# Connect to Graph
Connect-MgGraph -Scopes "RoleManagement.ReadWrite.Directory"

$RoleName = "Compliance Administrator"
$UserUPN = "admin_compliance@tamu.edu"

# Get the Role Definition
$Role = Get-MgRoleManagementDirectoryRoleDefinition -Filter "DisplayName eq '$RoleName'"

# Get the User
$User = Get-MgUser -UserId $UserUPN

# Assign the Role
New-MgRoleManagementDirectoryRoleAssignment -PrincipalId $User.Id -RoleDefinitionId $Role.Id -DirectoryScopeId "/"

Write-Host "✅ User $UserUPN assigned to $RoleName." -ForegroundColor Green

Step 4 – Enable Customer Lockbox (A5 Feature)

Goal: Ensure Microsoft engineers cannot access your tenant data during support requests without explicit approval. This is particularly important for FERPA and HIPAA compliance where unauthorized access to student/patient data must be prevented. [2]

Why It Matters for Higher Ed: When Microsoft support needs to troubleshoot an issue, they may need to access your tenant data. Customer Lockbox ensures you maintain control over this access—critical when that data includes student records or research data.

Click-Ops (Microsoft 365 Admin Center):

Navigate to https://admin.microsoft.com.
Go to Settings > Org settings > Security & privacy.
Select Customer Lockbox.
Toggle Require approval for all data access requests to On.
Designate approvers (should be senior IT staff or Compliance Officers).

PowerShell: Customer Lockbox is configured via Admin Center only No PowerShell cmdlet available - this is intentional for security

Step 5 – Enable Privileged Access Management (PAM)

Goal: Implement just-in-time, just-enough access for high-risk administrative tasks. PAM ensures that even Global Admins must request and receive approval before executing sensitive operations.

What is PAM?

Privileged Access Management creates an additional approval layer for sensitive admin tasks. Instead of admins having standing permissions to do anything, PAM requires:

Admin requests permission for a specific task (e.g., "Run eDiscovery search")
Designated approver reviews and approves
Admin has limited time window to complete task
Full audit trail of the request, approval, and execution

Why PAM Matters for Higher Ed:

FERPA Compliance: Prevents unauthorized bulk access to student records, even by IT staff
Research Protection: Stops rogue admins from exporting CUI/ITAR research data
Separation of Duties: Enforces multi-person approval for sensitive actions
Audit Trail: Creates defensible documentation for compliance audits

Higher Ed Tasks to Protect with PAM:

Task	Risk	PAM Protection
eDiscovery searches	Bulk access to emails/files	Require approval before search
Mailbox export	Complete mailbox access	Time-limited export permission
Retention policy changes	Could delete evidence	Multi-approver required
Sensitivity label admin changes	Could weaken protection	Approval + audit
Audit log export	Privacy-sensitive data	Manager approval

Click-Ops (Microsoft 365 Admin Center):

Navigate to https://admin.microsoft.com.
Go to Settings > Org settings > Security & privacy.
Select Privileged access.
Click Create policy and enable privileged access.
Configure Default Approval Group:
- Create a mail-enabled security group (e.g., PAM-Approvers@tamu.edu)
- Add IT Security Director, Compliance Officer, Deputy CIO
- This group approves requests when no task-specific approver is set
Create Task-Specific Policies:

Example Policy 1: eDiscovery Search

Policy type: Role-based
Policy scope: eDiscovery Manager role
Access type: Request approval
Approver group: PAM-Approvers@tamu.edu or Legal Counsel
Max duration: 4 hours

Example Policy 2: Mailbox Export

Policy type: Task-based
Task: New-MailboxExportRequest
Access type: Request approval
Approver group: HR Director (for HR mailboxes), Legal (for litigation)
Max duration: 2 hours

PowerShell:

Connect-ExchangeOnline

# Enable PAM at the organization level
Enable-ElevatedAccessControl -AdminGroup "PAM-Approvers@tamu.edu" -SystemAccounts @()

# Create policy for eDiscovery role
New-ElevatedAccessApprovalPolicy -Name "eDiscovery Access" `
    -Type RoleGroup `
    -RoleGroupName "eDiscovery Manager" `
    -ApprovalType AutoApproval `
    -ApproverGroup "PAM-Approvers@tamu.edu" `
    -MaxElapsedAccessTime 04:00:00

# Verify PAM is enabled
Get-ElevatedAccessApprovalPolicy | Format-Table Name, Type, ApprovalType, ApproverGroup

Start Small

Begin with PAM policies for your highest-risk tasks (eDiscovery, mailbox export, audit log access). Don't try to protect every admin task initially—it will create approval fatigue. Expand PAM coverage gradually based on risk assessment.

Approval Availability

Ensure your PAM approver group has adequate coverage. If all approvers are unavailable, legitimate admin work is blocked. Consider:

Multiple approvers across time zones
Documented emergency bypass procedures
Backup approvers for vacation/leave coverage

Security & Compliance Considerations

Privacy & Legal Review

Before enabling comprehensive auditing, consult with your institution's Privacy Officer and Legal Counsel. In higher education:

Faculty governance bodies may need to be informed about audit capabilities
Student privacy protections under FERPA apply to audit logs containing student activity [1]
State employment laws may govern monitoring of employee activities

Key Security Considerations:

Consideration	Recommendation
Audit Log Access	Restrict access to audit logs to a small group. Create a dedicated `Audit Readers` security group.
Log Export Controls	Audit log exports may contain PII. Treat exported logs as sensitive data.
Retention vs. Privacy	1-year retention is valuable for investigations but increases exposure window. Document justification.
Service Account Protection	Accounts with `Compliance Administrator` role are high-value targets. Require MFA and Conditional Access.

Compliance Alignment:

Regulation	Audit Requirement	A5 Capability
FERPA	Must maintain access logs for education records	✅ Unified Audit Log captures SharePoint/OneDrive access [1]
HIPAA	Audit controls required (§164.312(b))	✅ Audit (Premium) provides detailed access logging [2][3]
NIST 800-171	3.3.1 - Create and retain system audit logs	✅ 1-year retention meets requirement

Validation & Success Criteria

#	Validation Item	Test Method	Success Criteria
1	Audit Log Active	Check Purview Audit portal	"Start recording" banner is gone
2	Premium Configured	`Get-Mailbox <user> \| FL Audit*`	`AuditLogAgeLimit` = `365.00:00:00`
3	Role Verification	Sign in as `Compliance Administrator`	Can access Purview portal; cannot access Exchange Admin Center
4	Customer Lockbox	Check Admin Center > Org settings	Toggle shows On; approvers designated

Validation Script

# Quick validation script for Phase 1
Connect-ExchangeOnline

# Check Audit Status
$AuditConfig = Get-AdminAuditLogConfig
Write-Host "Audit Ingestion Enabled: $($AuditConfig.UnifiedAuditLogIngestionEnabled)" -ForegroundColor $(if($AuditConfig.UnifiedAuditLogIngestionEnabled){"Green"}else{"Red"})

# Check sample user audit settings
$SampleUser = Get-Mailbox -ResultSize 1
Write-Host "Sample User Audit Age Limit: $($SampleUser.AuditLogAgeLimit)" -ForegroundColor Cyan

Sub-Phase 1.5: Compliance Manager Setup

What is Compliance Manager?

Compliance Manager is your compliance command center—a dashboard that tracks your organization's compliance posture against regulatory frameworks, recommends improvement actions, and provides a quantifiable Compliance Score to measure progress.

Compliance Manager is particularly valuable because it:

Tracks improvement actions automatically as you implement Purview controls
Provides assessment templates for FERPA, HIPAA, NIST 800-171, and more
Quantifies compliance posture with a score you can report to leadership
Maintains evidence of your compliance journey for auditors

Understanding Compliance Score

Score Component	Description	Example
Microsoft-Managed	Actions Microsoft performs for you	Data encryption at rest
Customer-Managed	Actions you must configure/document	Enabling DLP policies, training staff
Total Score	Combined score out of possible maximum	650/1000 = 65% compliant

Step 1 – Access Compliance Manager and Review Baseline

Goal: Access Compliance Manager, understand your current baseline score, and identify the highest-impact improvement actions.

Click-Ops (Purview Portal):

Navigate to Compliance Manager from the Purview portal home.
Review your Compliance Score (shown prominently at top).
Note the score breakdown:
- Points from Microsoft-managed actions
- Points from Customer-managed actions (your responsibility)
- Points you've achieved vs. potential maximum
Click on the score to drill into contributing assessments.

Initial Baseline: Your score will be low before implementing Purview controls—this is expected. Each phase in this guide will improve your score automatically as Compliance Manager detects your configuration changes.

Step 2 – Add Assessment Templates for Your Regulations

Goal: Add regulatory assessment templates relevant to higher education so Compliance Manager tracks the right requirements.

Recommended Templates for Higher Education:

Template	Regulation	Who Needs It
FERPA	Student privacy	All institutions
HIPAA	Health data	Institutions with health services
NIST 800-171	CUI protection	Institutions with DoD research
NIST CSF	Cybersecurity framework	Recommended for all
CMMC	Defense contractor requirements	DoD research institutions
GDPR	EU data protection	Institutions with EU students/partners

Click-Ops:

Navigate to Compliance Manager > Assessments.
Click + Add assessment.
Select Template (e.g., "FERPA Baseline").
Select Group (create a group like "Higher Education Compliance").
Review and Create assessment.
Repeat for each relevant regulation.

A5 Includes Premium Templates

Your Microsoft 365 A5 license includes access to 3 premium assessment templates at no additional cost. Choose wisely—NIST 800-171, HIPAA, and CMMC are common premium choices for research universities.

Step 3 – Assign Improvement Actions to Stakeholders

Goal: Assign improvement actions to appropriate team members so work is tracked and distributed.

Click-Ops:

Navigate to Compliance Manager > Improvement actions.
Filter by Status: Not started and Your actions (Customer-managed).
For each high-impact action:
- Click the action name.
- Click Assign and select appropriate user.
- Set Implementation status (e.g., "In progress").
- Add notes about target completion date.

Common Action Assignments:

Action Category	Assign To
Configure DLP policies	Security Team
Enable MFA	Identity Team
Document retention policies	Records Manager
Complete privacy training	HR / Training Team
Review access permissions	Data Owners

Step 4 – Configure Automatic Testing

Goal: Enable continuous testing so Compliance Manager automatically detects when you've implemented controls.

How It Works: Many improvement actions have automated testing that checks your M365 configuration. When you enable DLP policies, configure retention, or set up labels, Compliance Manager automatically updates the status and adds points to your score.

Click-Ops:

Navigate to an improvement action.
Check if Test type shows "Automatic" or "Manual."
For automatic actions, no further work needed—Compliance Manager will detect implementation.
For manual actions, upload evidence when complete (documentation, screenshots, policies).

What Gets Auto-Tested:

Control	Auto-Tested?
DLP policies enabled	✅ Yes
Sensitivity labels published	✅ Yes
Retention policies configured	✅ Yes
Audit logging enabled	✅ Yes
User training completed	❌ Manual - upload completion records
Written policies documented	❌ Manual - upload policy documents

Track Progress Throughout Implementation

As you complete each phase in this guide, return to Compliance Manager to:

Verify your score increased
Update improvement action statuses
Upload any required evidence
Review newly available actions

Suggested Checkpoints:

After Phase 2 (Discovery): Score should increase 50-100 points
After Phase 3 (SharePoint Governance): Score should increase 50-75 points
After Phase 4 (Labels): Score should increase 100-150 points
After Phase 10 (DLP): Score should increase 150-200 points
After Phase 8 (Retention): Score should increase 100-150 points

Part 2: Know & Protect Your Data

This section focuses on discovering what sensitive data you have and applying protection at the source through Sensitivity Labels. Complete these phases before moving to access control.

Phase 2: Discovery & Identity (Know Your Data)

Phase Objective

Discover and classify your sensitive data by deploying Sensitive Information Types (SITs), Trainable Classifiers, and Content Explorer. This phase answers the fundamental question: "What sensitive data do we have, and where does it live?" The insights gained here directly inform the protection policies you'll create in subsequent phases.

Decision Point

Before implementing discovery, leadership must make key decisions about data visibility and content inspection:

Content Viewer Access: Who should be able to see actual file contents in Content Explorer? (Recommend: Minimal personnel with documented justification)
Custom SIT Scope: Will you create institution-specific SITs (Student IDs, Grant IDs)? (Recommend: Yes, to capture university-unique data patterns)
Trainable Classifier Investment: Will you invest time in training custom classifiers for document types unique to your institution (research proposals, IRB forms)? (Recommend: Start with 1-2 high-value document types)

Background & Context

Before you can protect your data, you must know what you have and where it lives. This phase implements the "Know Your Data" pillar of Microsoft's data protection framework. For a research university, this is particularly critical because:

Diverse Data Types: You're not just protecting corporate data—you have student records (FERPA), research data (CUI/ITAR), health information (HIPAA), and intellectual property, each with different regulatory requirements.
Distributed Ownership: Unlike a corporation where IT controls data, university data is created and managed by thousands of faculty, researchers, and staff across decentralized departments.
Historical Accumulation: Years of ungoverned file storage mean sensitive data exists in unexpected places—personal OneDrives, old SharePoint sites, and email archives.

What This Phase Accomplishes:

Activity	Tool	Outcome
Define what's sensitive	Sensitive Information Types (SITs)	Patterns and keywords that identify PII, research data, etc.
Teach the system to recognize documents	Trainable Classifiers	ML models trained on your document types
Find where sensitive data lives	Content Explorer	Visual map of sensitive data across M365
Understand how data is being used	Activity Explorer	Real-time view of labeling and DLP activity

Why This Matters for Copilot

Every piece of data that Copilot can access will be searched and potentially surfaced in responses. This phase ensures you can identify sensitive content so that subsequent phases can restrict Copilot's access to it.

Prerequisites

Requirement	Details	Notes
Phase 1 Complete	Audit logging enabled, roles assigned	Content Explorer requires audit data
Role / Permission	`Compliance Administrator` or `Information Protection Admin`	For creating SITs
Role / Permission	`Content Explorer List Viewer`	To see file locations (not content)
Role / Permission	`Content Explorer Content Viewer`	To preview actual file content (assign sparingly)
PowerShell Module	`ExchangeOnlineManagement` (IPPS Session)	For SIT creation via PowerShell
Time Allowance	24-48 hours for initial scan	Content Explorer needs time to index

Content Viewer Privacy Implications

The Content Explorer Content Viewer role allows seeing actual file contents, not just locations. For FERPA compliance, restrict this role to the minimum personnel necessary and document the business justification.

Step 0 – Review Built-in Sensitive Information Types

Goal: Before creating custom SITs, understand the 300+ built-in detectors Microsoft provides. Many common patterns (SSN, Credit Cards, HIPAA identifiers) are already available and maintained by Microsoft.

Click-Ops (Purview Portal):

Navigate to Data classification > Classifiers > Sensitive info types.
Review the list of built-in SITs. Key ones for Higher Education include:

Built-in SIT	Regulation	Use Case
U.S. Social Security Number (SSN)	Multiple	Employee/student records
All Full Names	FERPA/HIPAA	Combined with other SITs
U.S. Individual Taxpayer Identification Number (ITIN)	Tax compliance	Financial aid
Credit Card Number	PCI-DSS	Bursar, payment processing
U.S. / U.K. Passport Number	ITAR	International research, travel
Drug Enforcement Agency (DEA) Number	HIPAA	Health services
SWIFT Code	Financial	International research funding
All Medical Terms and Conditions	HIPAA	Student health services

Test a Built-in SIT:
- Click on U.S. Social Security Number (SSN).
- Click Test in the top menu.
- Enter a test SSN: 123-45-6789 and some context text.
- Verify detection works as expected.

Best Practice: Use built-in SITs where possible. They are:

Maintained and updated by Microsoft
Tested across millions of tenants
Optimized for performance

Only create custom SITs for organization-specific patterns (like your UIN format) that built-ins cannot detect.

Step 1 – Create Custom Sensitive Info Type (SIT) for UIN

Goal: Create a custom classifier that identifies the Texas A&M UIN format (XXX-00-XXXX) with High Confidence, verified by the presence of specific keywords anywhere in the file.

Click-Ops (Purview Portal):

Go to Information Protection > Classifiers > Sensitive info types.
Click + Create sensitive info type.
Name: TAMU Employee/Student UIN.
Description: Detects TAMU UINs with supporting keywords. Click Next.
Patterns: Click + Create pattern.
- Confidence level: Select High confidence.
- Primary element: Select Regular Expression.
  - ID: StudentUIN
  - Value: \b\d{3}-?00-?\d{4}\b
  - Select String match.
- Supporting elements: Select Keyword list.
  - ID: UINKeywords
  - Keywords: Add "UIN", "Universal ID", "Student ID", "TAMU ID", "Universal Identification Number".
  - Select Word match.
  - Click Done.
- Character proximity: Check the box for Anywhere in the document.
- Click Create.
Click Next through the remaining screens and click Create.

PowerShell (Exact Match Configuration):

Connect-IPPSSession

# 1. Define the Rule Package XML
$RulePackageXML = @"
<?xml version="1.0" encoding="utf-8"?>
<RulePackage xmlns="http://schemas.microsoft.com/office/2011/mce">
  <RulePack id="$(New-Guid)">
    <Version major="1" minor="0" build="0" revision="0"/>
    <Publisher id="$(New-Guid)"/>
    <Details defaultLangCode="en-us">
      <LocalizedDetails langcode="en-us">
        <PublisherName>Texas A&amp;M University</PublisherName>
        <Name>TAMU Custom SIT Package</Name>
        <Description>Custom sensitive information types for TAMU</Description>
      </LocalizedDetails>
    </Details>
  </RulePack>
  
  <Rules>
    <!-- TAMU UIN Pattern -->
    <Entity id="$(New-Guid)" patternsProximity="300" recommendedConfidence="85" relaxProximity="true">
      <Pattern confidenceLevel="85">
        <IdMatch idRef="Regex_TAMU_UIN"/>
        <Any minMatches="1">
          <Match idRef="Keyword_UIN"/>
        </Any>
      </Pattern>
      <LocalizedStrings>
        <Resource idRef="Regex_TAMU_UIN">
          <Name default="true" langcode="en-us">TAMU Employee/Student UIN</Name>
          <Description default="true" langcode="en-us">Detects TAMU UINs with supporting keywords</Description>
        </Resource>
      </LocalizedStrings>
    </Entity>
    
    <Regex id="Regex_TAMU_UIN">\b\d{3}-?00-?\d{4}\b</Regex>
    
    <Keyword id="Keyword_UIN">
      <Group matchStyle="word">
        <Term>UIN</Term>
        <Term>Universal ID</Term>
        <Term>Student ID</Term>
        <Term>TAMU ID</Term>
        <Term>Universal Identification Number</Term>
      </Group>
    </Keyword>
  </Rules>
</RulePackage>
"@

# 2. Save to temporary file
$TempFile = [System.IO.Path]::GetTempFileName() + ".xml"
$RulePackageXML | Out-File -FilePath $TempFile -Encoding UTF8

# 3. Upload the Rule Package
New-DlpSensitiveInformationTypeRulePackage -FileData ([System.IO.File]::ReadAllBytes($TempFile))

# 4. Clean up
Remove-Item $TempFile

Write-Host "✅ Custom UIN SIT created successfully." -ForegroundColor Green

# 5. Verify
Get-DlpSensitiveInformationType | Where-Object {$_.Name -like "*TAMU*"}

Simplified Alternative

For simpler SITs, you can use the Purview portal UI (as shown in Click-Ops) and export the rule package later for documentation:

# Export existing SIT for documentation/backup
$SIT = Get-DlpSensitiveInformationType -Identity "TAMU Employee/Student UIN"
Export-DlpSensitiveInformationTypeRulePackage -Identity $SIT.RulePackId -Path "C:\Backup\TAMU_SIT.xml"

Step 2 – Create Custom SIT for Research Grants

Goal: Detect documents related to specific high-risk grants (CUI/ITAR) by looking for Grant IDs in common formats, combined with supporting keywords.

Click-Ops (Purview Portal):

Navigate to Data classification > Classifiers > Sensitive info types.
Click + Create sensitive info type.
Name: TAMU Research Grant ID
Description: Detects research grant award IDs with supporting context keywords. Click Next.
Patterns: Click + Create pattern.
- Confidence level: Select High confidence.
- Primary element: Select Regular Expression.
  - ID: GrantID
  - Value: \b[A-Z]{2,5}-\d{4}-\d{4,6}\b
  - Select String match.
- Supporting elements: Select Keyword list.
  - ID: GrantKeywords
  - Keywords: Add "Grant", "Award", "Principal Investigator", "PI", "Co-PI", "NSF", "NIH", "DOD", "DOE", "DARPA", "Funding", "Sponsored Research", "Award Number", "Grant Number", "Federal Award".
  - Select Word match.
  - Click Done.
- Character proximity: Set to 300 characters (or check Anywhere in the document for broader detection).
- Click Create.
Click Next through the remaining screens and click Create.

PowerShell (XML Rule Package):

Connect-IPPSSession

# 1. Generate unique GUIDs for the rule package
$RulePackId = [guid]::NewGuid().ToString()
$PublisherId = [guid]::NewGuid().ToString()
$EntityId = [guid]::NewGuid().ToString()

# 2. Define the Rule Package XML
$RulePackageXML = @"
<?xml version="1.0" encoding="utf-8"?>
<RulePackage xmlns="http://schemas.microsoft.com/office/2011/mce">
  <RulePack id="$RulePackId">
    <Version major="1" minor="0" build="0" revision="0"/>
    <Publisher id="$PublisherId"/>
    <Details defaultLangCode="en-us">
      <LocalizedDetails langcode="en-us">
        <PublisherName>Texas A&amp;M University</PublisherName>
        <Name>TAMU Research Grant SIT Package</Name>
        <Description>Custom sensitive information type for research grant identification</Description>
      </LocalizedDetails>
    </Details>
  </RulePack>
  
  <Rules>
    <!-- TAMU Research Grant ID Pattern -->
    <Entity id="$EntityId" patternsProximity="300" recommendedConfidence="85">
      <Pattern confidenceLevel="85">
        <IdMatch idRef="Regex_Grant_ID"/>
        <Any minMatches="1">
          <Match idRef="Keyword_Grant_Context"/>
        </Any>
      </Pattern>
      <Pattern confidenceLevel="75">
        <IdMatch idRef="Regex_Grant_ID"/>
        <Any minMatches="1">
          <Match idRef="Keyword_Agency"/>
        </Any>
      </Pattern>
      <LocalizedStrings>
        <Resource idRef="$EntityId">
          <Name default="true" langcode="en-us">TAMU Research Grant ID</Name>
          <Description default="true" langcode="en-us">Detects research grant award IDs (e.g., NSF-2024-1234) with supporting context</Description>
        </Resource>
      </LocalizedStrings>
    </Entity>
    
    <!-- Primary Regex: Matches common grant ID formats -->
    <!-- Examples: NSF-2024-1234, NIH-2023-123456, DOD-2024-5678 -->
    <Regex id="Regex_Grant_ID">\b[A-Z]{2,5}[-_]?\d{4}[-_]?\d{4,6}\b</Regex>
    
    <!-- Supporting Keywords: Grant-related terminology -->
    <Keyword id="Keyword_Grant_Context">
      <Group matchStyle="word">
        <Term>Grant</Term>
        <Term>Award</Term>
        <Term>Principal Investigator</Term>
        <Term>PI</Term>
        <Term>Co-PI</Term>
        <Term>Co-Principal Investigator</Term>
        <Term>Funding</Term>
        <Term>Sponsored Research</Term>
        <Term>Award Number</Term>
        <Term>Grant Number</Term>
        <Term>Federal Award</Term>
        <Term>Subaward</Term>
        <Term>Contract Number</Term>
        <Term>Cooperative Agreement</Term>
      </Group>
    </Keyword>
    
    <!-- Agency Keywords: Federal funding agencies -->
    <Keyword id="Keyword_Agency">
      <Group matchStyle="word">
        <Term>NSF</Term>
        <Term>NIH</Term>
        <Term>DOD</Term>
        <Term>DOE</Term>
        <Term>DARPA</Term>
        <Term>NASA</Term>
        <Term>USDA</Term>
        <Term>EPA</Term>
        <Term>ONR</Term>
        <Term>AFOSR</Term>
        <Term>ARO</Term>
        <Term>National Science Foundation</Term>
        <Term>National Institutes of Health</Term>
        <Term>Department of Defense</Term>
        <Term>Department of Energy</Term>
        <Term>Office of Naval Research</Term>
      </Group>
    </Keyword>
  </Rules>
</RulePackage>
"@

# 3. Save to temporary file
$TempFile = [System.IO.Path]::GetTempFileName() -replace '\.tmp$', '.xml'
$RulePackageXML | Out-File -FilePath $TempFile -Encoding UTF8

# 4. Upload the Rule Package
try {
    New-DlpSensitiveInformationTypeRulePackage -FileData ([System.IO.File]::ReadAllBytes($TempFile))
    Write-Host "✅ TAMU Research Grant ID SIT created successfully." -ForegroundColor Green
}
catch {
    Write-Host "❌ Error creating SIT: $_" -ForegroundColor Red
}

# 5. Clean up temporary file
Remove-Item $TempFile -ErrorAction SilentlyContinue

# 6. Verify creation
Write-Host "`nVerifying SIT creation..." -ForegroundColor Cyan
Get-DlpSensitiveInformationType | Where-Object { $_.Name -like "*Grant*" } | 
    Select-Object Name, RecommendedConfidence, Publisher |
    Format-Table -AutoSize

Expanding for Export Control

For grants involving Controlled Unclassified Information (CUI) or ITAR, consider adding additional patterns:

<!-- ITAR/EAR Markers -->
<Keyword id="Keyword_Export_Control">
  <Group matchStyle="word">
    <Term>ITAR</Term>
    <Term>EAR</Term>
    <Term>Export Controlled</Term>
    <Term>CUI</Term>
    <Term>Controlled Unclassified</Term>
    <Term>NOFORN</Term>
    <Term>Distribution Statement</Term>
    <Term>DFARS</Term>
  </Group>
</Keyword>

Step 3 – Deploy Content Explorer (The Scan)

Goal: Visualize where this data lives.

Click-Ops (Purview Portal):

Navigate to Data classification > Content explorer.
Locate Custom sensitive information types on the list.
Click TAMU Employee/Student UIN.
Analyze the Graph:
- SharePoint: Are UINs appearing in "Public" sites?
- OneDrive: Are faculty storing student rosters in personal folders?
- Exchange: Are UINs being emailed externally?
Action: Export the summary report. This is your "Business Case" to leadership.

PowerShell: Note: Content Explorer is a visualization tool; there is no direct PowerShell equivalent for the graphical view. Use the UI for analysis.

Step 4 – Configure Trainable Classifiers (A5 Feature)

Goal: Use machine learning to detect document types that can't be identified by patterns alone. Unlike SITs (which look for specific text patterns), Trainable Classifiers understand document structure and context.

Why It Matters for Higher Ed:

Transcripts look similar across institutions but don't have a single regex pattern
Research proposals have consistent structure but variable content
Student disciplinary letters follow templates but contain different names/dates

Built-in Classifiers Available (A5):

Classifier	Use Case	FERPA/HIPAA Relevant
Resumes	HR, Career Services	No
Source Code	Research IP protection	No
Harassment	Communication Compliance	No
Threat	Communication Compliance	No
Profanity	Communication Compliance	No
Discrimination	Communication Compliance	No
Targeted Harassment	Student safety	Yes
Adult Content	Acceptable use	Yes

Click-Ops (Purview Portal):

Navigate to Data classification > Classifiers > Trainable classifiers.
Review the list of Pre-trained classifiers.
To create a custom classifier (e.g., "Academic Transcript"):
- Click + Create trainable classifier.
- Name: Academic Transcript - TAMU
- Description: Detects official and unofficial academic transcripts.
- Click Next.
Seed Content:
- Create a SharePoint site: Trainable Classifier Seed Content
- Upload 50+ positive examples (actual transcripts—redact real student data)
- Click Add SharePoint site as seed content.
Training:
- Wait 24-48 hours for initial processing.
- Review items the classifier identifies and mark as Match or Not a match.
- Provide at least 200 feedback responses for optimal accuracy.
Publish:
- Once accuracy reaches acceptable threshold (aim for >80%), click Publish.
- Classifier is now available for use in DLP and auto-labeling policies.

Custom Classifiers to Consider for Higher Ed:

Classifier Name	Training Content	Use Case
Academic Transcript	Official transcripts (redacted)	FERPA protection
Research Proposal	Grant proposals	IP and export control
Student Disciplinary Record	Conduct letters (redacted)	FERPA protection
FERPA Consent Form	Signed consent forms	Release authorization tracking
Export Control Document	ITAR/EAR classification forms	CUI protection

Training Data Privacy

When creating training sets, use redacted or synthetic documents when possible. If using real documents, ensure the SharePoint site containing seed content is heavily restricted and the documents are deleted after training completes.

Step 5 – Enable and Review Activity Explorer

Goal: While Content Explorer shows you where sensitive data exists, Activity Explorer shows you what's happening to that data in real-time.

What Activity Explorer Tracks:

Activity Type	Example	Why It Matters
Label applied	User labeled file as "Confidential - FERPA"	Tracks adoption of labeling
Label changed	User downgraded from "Restricted" to "General"	Potential data exfiltration attempt
Label removed	User removed protection	Security concern
File read	Sensitive file accessed	Audit trail for FERPA
DLP policy matched	Email with SSN detected	Policy effectiveness
File copied to cloud	OneDrive sync of sensitive file	Shadow IT detection
File copied to USB	Endpoint DLP detection	Data exfiltration

Click-Ops (Purview Portal):

Navigate to Data classification > Activity explorer.
Set the date range (default is last 30 days).
Filter by Activity:
- Click Activity filter.
- Select activities relevant to your investigation (e.g., LabelApplied, DLPRuleMatch).
Filter by Sensitive Info Type:
- Click Sensitive info type filter.
- Select your custom TAMU Employee/Student UIN.
Analyze Patterns:
- Are users consistently labeling documents?
- Are DLP policies catching violations before they happen?
- Is there unusual activity from specific accounts?

Export for Reporting:

Click Export to download activity data as CSV.
Use this data for:
- Compliance reporting to FERPA auditors
- Identifying users who need additional training
- Measuring policy effectiveness

Baseline Your Environment

In the first 30 days, establish baseline metrics:

How many DLP matches per day?
What percentage of sensitive files are labeled?
Which locations have the most sensitive data?

Use this baseline to measure improvement over time.

Step 6 (Advanced) – Exact Data Match for Student Records

Goal: Detect sensitive data by matching against an actual database of known values rather than patterns. This provides the highest accuracy for detecting specific individuals' data.

Why EDM for Higher Ed:

SITs detect any 9-digit number matching the UIN pattern
EDM detects only UINs that exist in your student database
Dramatically reduces false positives
Required for high-confidence detection of specific individuals

Example Use Case: Instead of flagging any XXX-00-XXXX pattern, EDM only flags documents containing actual student UINs from your Banner/Colleague system.

Architecture Overview:

Side-by-Side Comparison: SIT vs EDM

Here's a diagram showing when to use each approach:

Click-Ops (High-Level Process):

Create EDM Schema:
- Navigate to Data classification > Exact data matches > EDM schemas.
- Define columns: UIN, FirstName, LastName, Email.
- Designate UIN as the primary searchable field.
Prepare and Hash Data:
- Export student data from Banner to CSV (secure process!).
- Use the EDM Upload Agent to hash and upload data.
- Delete the source CSV immediately after upload.
Create EDM-based SIT:
- Navigate to Sensitive info types > Create.
- Select Exact data match as the detection method.
- Link to your EDM schema.
Test and Deploy:
- Test against known documents containing student data.
- Use in DLP policies for highest-accuracy detection.

Data Handling Requirements

The CSV file containing actual student UINs is highly sensitive FERPA data.

Generate on a secured, compliant system
Transfer via encrypted channel only
Delete immediately after EDM upload completes
Document the entire process for FERPA audit trail

PowerShell (EDM Upload Agent):

# This runs on a dedicated secure workstation, not your admin PC
# Download EDM Upload Agent from Microsoft

# Hash and upload the data
EdmUploadAgent.exe /UploadData /DataStoreName "StudentRecords" `
    /DataFile "C:\Secure\students.csv" `
    /HashLocation "C:\Secure\hash" `
    /Schema "C:\Secure\schema.xml" `
    /AllowedBadLinesPercentage 5

Sub-Phase 2.5: Data Security Posture Management (DSPM)

What is DSPM?

Data Security Posture Management is a unified dashboard that consolidates insights from all Purview discovery tools. Instead of checking Content Explorer, Activity Explorer, and SIT matches separately, DSPM provides an executive-level view of your data security posture with actionable recommendations.

DSPM is particularly valuable for higher education because it:

Aggregates risk signals across your diverse data landscape (research, FERPA, financial)
Prioritizes remediation based on sensitivity and exposure level
Tracks improvement over time with posture scoring
Surfaces oversharing that could expose data to Copilot or external users

DSPM Dashboard Components

Dashboard Element	What It Shows	Action to Take
Posture Score	Overall data security health (0-100)	Track trend over time; set target score
Data at Risk	Sensitive content with inadequate protection	Prioritize for labeling/DLP policies
Overshared Data	Files with excessive permissions	Review and restrict access
Sensitive Data Map	Visual distribution across M365	Identify high-concentration areas
Recommendations	AI-generated remediation steps	Work through priority order

Configure DSPM Dashboard

Goal: Enable and configure DSPM to provide ongoing visibility into your data security posture.

Prerequisites:

Phase 2 SITs and classifiers configured
Content Explorer has completed initial scan (24-48 hours after Phase 2 start)

Click-Ops (Purview Portal):

Navigate to Data security posture management from the Purview portal home.
If this is your first visit, DSPM will begin aggregating data from other Purview tools.
Configure Posture Score Goals:
- Click Settings (gear icon).
- Set target posture score (recommended: start at current + 10 points).
- Define priority data types (FERPA, Research, Financial).
Review Sensitive Data at Risk:
- Click Data at risk card.
- Filter by sensitivity label status (Unlabeled, Under-protected).
- Export list for remediation planning.
Analyze Oversharing:
- Click Overshared data card.
- Review files shared with "Everyone except external users" or "All employees."
- Flag for access review in Phase 4 or Phase 6.

Key Metrics to Monitor:

Metric	Target	Remediation Approach
% of sensitive data labeled	> 80%	Auto-labeling policies (Phase 4)
Overshared sensitive files	< 5%	Access reviews, SAM (Phase 6)
Unprotected high-sensitivity	0	DLP blocking policies (Phase 5)
Stale sensitive content	Trending down	Retention policies (Phase 8)

DSPM for Copilot Readiness

Goal: Use DSPM specifically to assess Copilot exposure risk before enabling M365 Copilot.

Why This Matters: Copilot can surface any content a user has access to. If sensitive files are overshared, Copilot could inadvertently expose them in responses. DSPM helps identify these risks before Copilot deployment.

Copilot Readiness Assessment:

Navigate to DSPM > Overshared data.
Filter to show only files with:
- Sensitivity: High or Confidential
- Sharing: Broad internal access or external links
For each flagged item, determine:
- Should this file exist? (If stale, mark for retention/deletion)
- Is sharing appropriate? (If not, restrict permissions)
- Is sensitivity label correct? (If under-labeled, relabel)

Pre-Copilot Checklist:

DSPM posture score ≥ 70
< 100 overshared sensitive files
All "Highly Confidential" content has restricted access
Research data locations excluded from general access

Integration with SAM

DSPM findings feed directly into SharePoint Advanced Management (SAM) for remediation. When DSPM identifies overshared content, use SAM's Data Access Governance to run access reviews (covered in Phase 6).

Full Discovery Phase Data Flow

Here's a comprehensive diagram showing how all Phase 2 components work together:

Validation & Success Criteria

#	Validation Item	Test Method	Success Criteria
1	Built-in SITs Available	Purview > Classifiers > SITs	300+ built-in types visible
2	Custom SITs Created	Search SIT list	`TAMU Employee/Student UIN` and `TAMU Research Grant ID` appear
3	SIT Detection Test	Use "Test" function with sample UIN	High confidence match returned
4	Content Explorer Populated	Check after 24-48 hours	Data locations visible for custom SITs
5	Activity Explorer Active	Filter by SIT	Activities logged for sensitive data access
6	Trainable Classifier Published	Check classifier status

Security & Compliance Considerations

Privacy: Content Explorer allows admins to see filenames and locations of sensitive files. Ensure access to this tool is restricted to only those who absolutely need it for compliance auditing.
False Positives: During the first week, monitor the UIN detector. If it flags generic 9-digit numbers (like phone numbers without dashes), tune the SIT by requiring closer proximity to the keyword "UIN" (e.g., within 50 characters).

Continue to Part 3

Now that you've discovered your sensitive data, proceed to Part 3: Access Control & Sharing Governance to clean up your environment before applying labels.

This section focuses on securing the containers where data lives—SharePoint sites, Teams, and OneDrive. It also covers Zero Trust access controls, Information Barriers, and Copilot protection.

Why SharePoint Governance Comes Before Sensitivity Labels

For existing, established environments, we recommend cleaning up your data estate before applying sensitivity labels:

Reduce the Blast Radius: By first identifying orphaned sites, enforcing ownership, and removing stale content, you significantly reduce the volume of data that needs to be labeled and protected.
Establish Accountability: Site Lifecycle Management ensures every site has a responsible owner who will be accountable for properly labeling their content.
Prevent Label Sprawl: Labeling content in an ungoverned environment often results in over-labeling or inconsistent labeling as users panic about unmanaged data.
Lower Processing Overhead: Auto-labeling policies are more efficient when they don't have to scan through abandoned sites and orphaned content.

For net-new environments (greenfield deployments), you could create labels first. But for mature environments with years of organic growth, governance first is the pragmatic approach.

Phase 3: SharePoint & Teams Governance (Permission & Lifecycle)

Decision Point

This phase implements two critical governance strategies:

Permission Hygiene: Restricting how data is shared externally (e.g., expiring "Anyone" links).
Site Lifecycle Management: Implementing automated accountability (Ownership, Attestation, Inactivity) to reduce sprawl and ensure every site has a responsible owner.

Background & Context

Before applying labels, we must secure the container (SharePoint Site/Team). A file encrypted with the strongest label is still at risk if it sits in a site accessible to "Everyone" or if the site has been abandoned by its owners.

In a university environment like Texas A&M, "organic sharing" leads to permission creep. We will tackle this by:

Setting Secure Defaults: Enforcing expiration on anonymous links and changing the default share link to "View" instead of "Edit".
Automated Lifecycle Management: Using the SharePoint Admin Center to automatically nag site owners to certify their sites, add co-owners, and clean up inactive spaces.

Prerequisites

Requirement	Minimum / Version	Notes
Role / Permission	`SharePoint Administrator`	Required for Sharing and Lifecycle policies.
Licensing	SharePoint Advanced Management	Required for advanced Site Lifecycle Management policies (Ownership, Attestation, Inactivity). Included in A5.
PowerShell Module	`Microsoft.Online.SharePoint.PowerShell`	Latest stable version.

Site Lifecycle Policy Rollout Strategy

Procedure / Implementation

Step 1 – Harden External Sharing & Links

Goal: Implement a "Secure by Default" posture.

"Anyone" links expire in 30 Days.
Default link permission changed from Edit to View.
Idle session timeout enabled.

Click-Ops (SharePoint Admin Center):

Navigate to https://<tenant>-admin.sharepoint.com.
Go to Policies > Sharing.
External sharing:
- Set SharePoint and OneDrive to Anyone (if required for research) or New and existing guests for a more secure environment.
More external sharing settings:
- Check Guest access to a site or OneDrive will expire automatically after and set to 30 days.
- Check People who use a verification code must reauthenticate after and set to 30 days.
File and folder links:
- Choose the type of link: Set to Specific people (only the people the user specifies).
- Choose the permission: Set to View (Default to Read-Only).
"Anyone" links:
- Check These links must expire within this many days and set to 30.
- Set File permissions to View.

warning

If this policy was never previously set, enforcing any time period on links will automatically deactivate any existing links that were created n-30 daygs ago (or chosen period). Be sure to use the Anyone links report available to run in the SharePoint admin center to know your blast radius and exact users to contact before changing this setting. Located at Reports > Data access governance > Sharing links.

Click Save.

PowerShell (Automation):

Connect-SPOService -Url "https://tamu-admin.sharepoint.com"

# 1. Set "Anyone" links to expire in 30 days
Set-SPOTenant -RequireAnonymousLinksExpireInDays 30

# 2. Set default link type to "Specific People" (Internal/Guest) instead of "Anyone"
Set-SPOTenant -DefaultSharingLinkType Internal

# 3. Set default link permission to "View" (Read-Only)
Set-SPOTenant -DefaultLinkPermission View

# 4. Enforce Idle Session Timeout (Sign out inactive browser sessions)
Set-SPOTenant -IdleSessionSignOut $true -IdleSessionSignOutWarnAfterSeconds 2700 -IdleSessionSignOutSignOutAfterSeconds 3600

Write-Host "✅ Sharing settings hardened: 30-day expiry, View-only default." -ForegroundColor Green

Before configuring sharing policies, you must understand the five types of sharing links and their security implications. This knowledge is essential for making informed governance decisions.

📋 Comprehensive Sharing Link Reference

Link Type	Who Can Access	Authentication Required	Trackable	Revocable	Security Level
Anyone	Anyone with the link (public)	❌ No	❌ No	✅ Yes	🔴 Lowest
People in your organization	Any authenticated org user	✅ Yes (org account)	⚠️ Limited	✅ Yes	🟡 Medium
People with existing access	Only those already granted	✅ Yes	✅ Full	N/A	🟢 High
Specific people (internal)	Named org users only	✅ Yes	✅ Full	✅ Yes	🟢 High
Specific people (guests)	Named external users	✅ Yes (guest account)	✅ Full	✅ Yes	🟢 High

Detailed Link Type Analysis

1. "Anyone" Links (Anonymous)

Aspect	Details
Use Case	Public-facing content, wide distribution to unknown recipients
Risk	Link can be forwarded, posted publicly, or discovered by bad actors
Audit Trail	Cannot track who accessed the content, only that it was accessed
Best Practice	❌ Disable for sensitive environments; if required, enforce short expiration (7-30 days) and View-only permissions
Microsoft Limitation	⚠️ Cannot restrict "Anyone" links to specific file types or content categories—it's all or nothing at the tenant/site level

2. "People in Your Organization" Links

Aspect	Details
Use Case	Internal broad sharing (announcements, policies, templates)
Risk	Any employee can access, including those who shouldn't see sensitive content
Audit Trail	Logged as `SharingSet` but individual access not tracked unless user opens file
Best Practice	⚠️ Use sparingly; not appropriate for HR, Legal, or research data
Hidden Danger	These links don't "break" when users leave—anyone new in the org can still access

3. "People with Existing Access" Links

Aspect	Details
Use Case	Sharing a direct link without expanding permissions
Risk	Minimal—only generates a convenient URL for already-authorized users
Audit Trail	Full tracking via existing permissions
Best Practice	✅ Safest option for most internal sharing
Behavior	This creates a link but does NOT change permissions—users who can't access will get "Access Denied"

4. "Specific People" Links (Internal)

Aspect	Details
Use Case	Controlled sharing with named colleagues
Risk	Low—permissions are explicit and auditable
Audit Trail	Full tracking with user identity
Best Practice	✅ Preferred method for sharing sensitive content
Permission Accumulation	⚠️ These permissions accumulate over time—use Access Reviews to clean up

5. "Specific People" Links (Guests/External)

Aspect	Details
Use Case	Collaboration with external partners, vendors, research collaborators
Risk	Medium—external users have legitimate access but are outside org security controls
Audit Trail	Full tracking; guest access logged in Entra ID
Best Practice	✅ Require MFA via Conditional Access; set expiration on guest accounts
Guest Lifecycle	⚠️ Microsoft does NOT automatically remove guest accounts when collaboration ends—implement Access Reviews

🚨 What Microsoft Forces vs. What You Can Control

Understanding Microsoft's limitations helps you plan where custom solutions may be needed.

Things Microsoft Allows You to Control

Setting	Control Level	Where to Configure
Tenant-wide sharing capability	✅ Full	SPO Admin > Sharing
Per-site sharing capability	✅ Full	SPO Admin > Site settings
Default link type	✅ Full	SPO Admin > Sharing
Default link permission	✅ Full	SPO Admin > Sharing
Anyone link expiration	✅ Full	SPO Admin > Sharing
Guest expiration	✅ Full	SPO Admin > Sharing
Block download for unmanaged devices	✅ Full	SPO Admin > Access control

Things Microsoft Limits or Forces

Limitation	Impact	Workaround
Site Lifecycle Email Customization Requires Global Admin	While Microsoft now allows email customization (see Custom Email Notifications below), enabling it requires a Global Administrator to configure a custom sender domain first—a one-time setup that unlocks branding for SharePoint Admins.	✅ Have Global Admin configure custom sender domain in M365 Admin Center, then customize emails in SharePoint Admin
No Granular "Anyone" Link Controls	Cannot allow "Anyone" links for specific file types (e.g., PDFs only) or specific users. It's tenant/site level only.	Use site-level sharing overrides to lock down sensitive sites
No Native "Break Inheritance" Alerts	Users can break permission inheritance at any level without notification to admins or site owners	Custom solution: Power Automate + Graph API to monitor `RoleDefinitionBindingsDirect` changes
Guest Access Has No "Last Activity" Auto-Removal	Guest accounts persist indefinitely even if never used or inactive for years	Implement Entra ID Access Reviews or custom Graph API cleanup
Sharing Link Forwarding Cannot Be Blocked	"Specific People" links can still be forwarded (recipient sees "Access Denied" but knows content exists)	Sensitivity Labels with Rights Management prevent forwarding at file level
No Pre-Approval Workflow for External Sharing	Cannot require manager approval before external sharing	❌ Requires custom Power Automate/Logic App solution
Site Creation Restrictions Are Blunt	Can disable self-service site creation but cannot require approval workflow natively	Use SharePoint site design + approval flow for controlled provisioning
Permission Reports Are Limited	Native reports don't show inherited vs. direct permissions at scale	Use third-party tools or custom Graph API scripts

Microsoft Recommendations We Disagree With

Microsoft Default	Our Recommendation	Rationale
Default sharing: "People in your organization"	Change to: "Specific people"	"Org-wide" links create invisible permission sprawl
Guest access: No expiration	Set: 30-90 day expiration	Prevents orphaned guest accounts
"Anyone" links: Enabled	Disable or: 7-14 day expiration	Anonymous links are highest risk
Site creation: Self-service enabled	Disable or: Require provisioning request	Prevents SharePoint sprawl

🔧 Where Custom Solutions Are Required

The following scenarios cannot be addressed with native Microsoft tooling and require custom development:

1. Branded Site Lifecycle Notifications → Now Partially Addressed!

UPDATE: Native Customization Available

Microsoft now allows customization of Site Lifecycle Management emails! See Custom Email Notifications for setup instructions. The native solution covers most use cases.

When you still need a custom solution: If you need branding beyond Microsoft's limits (e.g., embedded images, HTML templates, integration with ticketing systems), a custom Power Automate flow may still be valuable:

Power Automate Flow:
Scheduled trigger (daily)
Query Graph API for sites matching lifecycle criteria
Check against custom SharePoint list of "notified sites"
Send branded email via custom connector
Log notification in tracking list

Estimated Effort: 8-16 hours development + testing (only if native customization is insufficient)

Problem: Users can share externally without any pre-approval, only post-incident detection via DLP.

Solution Architecture:

Power Automate + SharePoint:
Intercept sharing dialog (not possible natively)
   Alternative: Block external sharing at site level
Provide custom "Request External Access" button
Route to manager/data owner for approval
Upon approval, temporarily enable sharing for that user/file
Auto-revoke after defined period

Reality Check: ⚠️ True pre-approval interception is not possible. The practical solution is to block external sharing by default and provide a request/approval process.

Estimated Effort: 24-40 hours development + testing

3. Permission Inheritance Break Monitoring

Problem: Users can break permission inheritance anywhere, creating hidden access exceptions.

Solution Architecture:

Azure Function + Graph API:
Scheduled scan of sites/libraries/folders
Detect HasUniqueRoleAssignments = true
Compare against baseline (approved exceptions)
Alert security team on new inheritance breaks
Optional: Auto-remediate by restoring inheritance

Estimated Effort: 16-24 hours development + testing

4. Orphaned Permission Cleanup

Problem: When users leave, their permissions often remain, especially on shared content.

Solution Architecture:

Azure Automation + Graph API:
Query disabled user accounts from Entra ID
Scan SharePoint sites for permissions granted to disabled users
Generate report for site owners
Optional: Auto-remove after grace period

Note: This is DIFFERENT from site ownership (handled by lifecycle policies)—this addresses individual file/folder permissions.

Estimated Effort: 16-24 hours development + testing

5. Cross-Site Permission Visibility

Problem: No native way to see "what can User X access across all SharePoint sites?"

Solution Architecture:

Power BI + Graph API Connector:
Enumerate all sites via Graph API
For each site, enumerate permissions
Build permission matrix: Users × Sites × Access Level
Visualize in Power BI with filters
Schedule daily refresh

Estimated Effort: 24-32 hours development + testing

Third-Party Alternatives: ShareGate, Rencore, AvePoint offer this capability out-of-box.

Step 2 – Block Legacy Authentication

Goal: Block apps that don't support Modern Auth (MFA).

Click-Ops:

Policies > Access control.
Apps that don't use modern authentication: Select Block access.
Click Save.

PowerShell:

Set-SPOTenant -LegacyAuthProtocolsEnabled $false
Write-Host "✅ Legacy Authentication Blocked." -ForegroundColor Green

Step 3 – Review Data Access Governance Reports

Goal: Before hardening sharing settings, understand your current exposure using the built-in Data Access Governance reports. These reports (included with SharePoint Advanced Management/A5) show you exactly what's shared and with whom.

Available Reports:

Report	What It Shows	Use Case
Sharing links	All "Anyone" and "People in org" links	Identify blast radius before expiring links
Sensitivity labels on files	Files by label across all sites	Verify labeling adoption
Shared with "Everyone except external users"	Overshared content	Find permission creep
Sites shared with "Everyone except external users"	Sites with org-wide access	Identify sites to restrict
Oversharing baseline report	Sites exceeding sharing thresholds	Prioritize remediation

Click-Ops (SharePoint Admin Center):

Navigate to https://<tenant>-admin.sharepoint.com.
Go to Reports > Data access governance.
Before changing sharing settings, run the Sharing links report:
- Click Sharing links > Anyone links.
- Export the report to CSV.
- Identify links created more than 30 days ago (these will break when you enable expiration).
- Contact affected users before enabling the policy.
Run the Oversharing baseline:
- Click Oversharing baseline report > Create report.
- Set thresholds (e.g., sites shared with >100 users).
- Use results to prioritize sites for permission review.

PowerShell (Export Sharing Links Report):

Connect-SPOService -Url "https://tamu-admin.sharepoint.com"

# Get all sites with anonymous links
$Sites = Get-SPOSite -Limit All | Where-Object { $_.SharingCapability -eq "ExternalUserAndGuestSharing" }

$Report = @()
foreach ($Site in $Sites) {
    # Note: Detailed link enumeration requires Graph API or admin report export
    $Report += [PSCustomObject]@{
        SiteUrl = $Site.Url
        SharingCapability = $Site.SharingCapability
        LastContentModified = $Site.LastContentModifiedDate
    }
}

$Report | Export-Csv -Path "C:\Reports\SharingSummary.csv" -NoTypeInformation
Write-Host "✅ Sharing summary exported. Use Admin Center for detailed link reports." -ForegroundColor Green

Pre-Change Communication

Before enabling link expiration, email users identified in the "Anyone links" report:

"On [DATE], we are implementing a 30-day expiration policy for anonymous sharing links. Links you created before [DATE-30] will stop working. If you have ongoing collaborations using these links, please reshare using 'Specific people' links or guest access."

Step 4 – Configure Block Download Policy (High-Risk Sites)

Goal: For sensitive sites (HR, Legal, Research with CUI), allow viewing in browser but block downloading, printing, or syncing when accessed from unmanaged devices.

Why It Matters: A user on a personal laptop can view a confidential document but cannot save a local copy that persists after their session ends.

Click-Ops (SharePoint Admin Center):

Navigate to Policies > Access control.
Under Unmanaged devices, select Allow limited, web-only access.
Click Save (this sets the tenant default).

For Specific Sites (More Restrictive):

Navigate to Sites > Active sites.
Select the sensitive site (e.g., HR-Confidential).
Click Policies tab.
Under Unmanaged device access, select Block download.

PowerShell (Site-Specific Block Download):

Connect-SPOService -Url "https://tamu-admin.sharepoint.com"

# Block download for specific sensitive sites
$SensitiveSites = @(
    "https://tamu.sharepoint.com/sites/HR-Confidential",
    "https://tamu.sharepoint.com/sites/Legal-Matters",
    "https://tamu.sharepoint.com/sites/Research-CUI"
)

foreach ($SiteUrl in $SensitiveSites) {
    Set-SPOSite -Identity $SiteUrl -ConditionalAccessPolicy BlockDownloadPolicy
    Write-Host "✅ Block Download enabled for: $SiteUrl" -ForegroundColor Green
}

Requires Conditional Access Integration

Full enforcement of "Block Download" requires a Conditional Access policy in Entra ID that targets SharePoint Online and uses session controls. This is configured in Phase 6. The SharePoint setting above prepares the site; the CA policy enforces it.

Deep Dive: SharePoint Access Control Architecture

Understanding SharePoint's layered access control is essential for implementing effective governance. This section explains how permissions work, where they can be configured, and what Microsoft allows vs. restricts.

📋 SharePoint Permission Model Explained

Permission Inheritance Hierarchy

SharePoint uses a top-down permission inheritance model:

Tenant Settings (SPO Admin)
    ↓ (can restrict but not expand)
Site Collection
    ↓ (inherits by default)
Site (Web)
    ↓ (inherits by default)
Document Library
    ↓ (inherits by default)
Folder
    ↓ (inherits by default)
Item/File

Key Principle: Child objects inherit parent permissions by default. At any level, inheritance can be "broken" to apply unique permissions—but this creates governance risk.

Permission Levels Explained

Permission Level	What It Allows	Use Case
Full Control	Everything + change permissions + delete site	Site owners, admins
Design	View, add, update, delete, approve, customize	Site designers (rare)
Edit	View, add, update, delete lists/libraries	Content contributors
Contribute	View, add, update, delete list items and documents	Standard users
Read	View only	Read-only stakeholders
View Only	View in browser only, no download	Sensitive content viewers
Limited Access	Auto-granted for subfolder access	System-generated

The "Everyone" Problem

SharePoint has several "everyone" groups that cause permission sprawl:

Group	Who's Included	Risk Level
Everyone	All users including external guests	🔴 Critical
Everyone except external users	All org users (30,000+ at TAMU)	🔴 High
All authenticated users	Anyone with Microsoft account	🔴 Critical
Site Members	Explicit site membership	🟡 Medium
Visitors	Read-only group	🟢 Low

Finding "Everyone" Permissions:

Connect-SPOService -Url "https://tamu-admin.sharepoint.com"

# Get sites shared with "Everyone except external users"
$Sites = Get-SPOSite -Limit All
$OversharedSites = @()

foreach ($Site in $Sites) {
    $Permissions = Get-SPOSiteGroup -Site $Site.Url | Where-Object { 
        $_.Users -contains "c:0-.f|rolemanager|spo-grid-all-users/$TenantId" -or
        $_.Title -eq "Everyone except external users"
    }
    if ($Permissions) {
        $OversharedSites += [PSCustomObject]@{
            Url = $Site.Url
            Title = $Site.Title
            Groups = ($Permissions.Title -join ", ")
        }
    }
}

$OversharedSites | Export-Csv -Path "C:\Reports\OversharedSites.csv"
Write-Host "Found $($OversharedSites.Count) sites shared with Everyone" -ForegroundColor Yellow

Broken Inheritance: The Hidden Risk

When inheritance is broken at any level, that object has unique permissions that don't change when parent permissions change. This creates:

Permission Sprawl: Thousands of unique permission sets across the tenant
Audit Difficulty: No single report shows all permissions
Orphaned Access: Users retain access even when removed from parent groups
Copilot Exposure: Copilot respects item-level permissions, so broken inheritance with oversharing = AI exposure

Detecting Broken Inheritance (Graph API):

# Requires Microsoft Graph PowerShell module
Connect-MgGraph -Scopes "Sites.Read.All"

$SiteId = "your-site-id"
$DriveId = "your-drive-id"

# Get items with unique permissions (broken inheritance)
$Items = Get-MgDriveRootChild -DriveId $DriveId -Recurse
$UniquePermItems = $Items | Where-Object { $_.Permissions -ne $null }

Write-Host "Found $($UniquePermItems.Count) items with unique permissions" -ForegroundColor Yellow

Access Control at Each Layer

Layer	What You Control	Native Tools	Limitations
Tenant	Global defaults, external sharing capability	SPO Admin Center	Broad—affects all sites
Site Collection	Site-level sharing, access requests, groups	Site Settings > Permissions	Cannot delegate admin
Site	Local groups, member management	Site Settings > Site permissions	Inherits from collection
Library	Library-specific permissions	Library Settings > Permissions	Usually inherited
Folder	Folder-specific permissions	Folder > Manage access	⚠️ Creates sprawl
Item	Per-item permissions	Item > Manage access	⚠️ Creates sprawl

🚨 Access Control: What Microsoft Limits

Cannot Prevent Permission Inheritance Breaking

Problem: Any user with "Manage Permissions" (Full Control or custom) can break inheritance at any level.

Impact: A site owner can grant "Everyone except external users" access to a single folder containing PII, bypassing all site-level controls.

Native Solution: None. Microsoft does not provide a setting to prevent inheritance breaking.

Workaround Options:

Audit-based detection: Use Graph API to scan for broken inheritance weekly
DLP policies: Detect when sensitive content is exposed via permissions
Sensitivity Labels: Apply "Restricted" label that overrides permissions with encryption
Conditional Access: Use session controls to enforce app-only access

Problem: When a user clicks "Share," the share happens immediately. There's no native "request approval before sharing externally" workflow.

Impact: By the time DLP detects and alerts, the content is already shared.

Workaround Options:

Block external sharing by default at site level
Create custom "Request External Access" process via Power Automate
Use Sensitivity Labels with encryption to prevent external access regardless of sharing

Problem: The "Allow sharing only with users in specific domains" setting is an allowlist/blocklist at tenant level—you cannot vary this by site.

Example Issue: Research wants to share with MIT (mit.edu) but HR should only share internally.

Workaround Options:

Create separate site collections with different sharing settings
Use Sensitivity Labels to block external recipients at the file level
Use DLP policies to block external sharing of specific content types

Cannot Audit "Who Accessed What" Retroactively for Specific Files

Problem: The Unified Audit Log records events, but there's no native "show me everyone who accessed file X in the past year" report.

Impact: Incident response requires manual search or Graph API scripting.

Workaround Options:

Use eDiscovery to search audit logs by file path
Build custom Power BI report from audit log data
Third-party tools: Microsoft Defender for Cloud Apps (MDCA) Activity Log

Cannot Enforce "Need to Know" Access Patterns

Problem: SharePoint is built on broad collaboration, not compartmentalized access. No native support for mandatory access controls or security levels.

Impact: Cannot enforce "only users with Secret clearance can access this content" without manual processes.

Workaround Options:

Sensitivity Labels with encryption tied to specific security groups
Information Barriers (Phase 5.5) for segment-based isolation
Site Access Restriction (SAR) for nuclear-option isolation from search/Copilot
Azure AD Dynamic Groups based on user attributes + site permissions

🔧 Access Control Best Practices for Higher Ed

Recommended Access Control Model

Based on higher education governance requirements:

Site Type	Recommended Access Model	Rationale
Department sites	Site Owners (2) + Members (department)	Clear ownership, limited scope
Project sites	Site Owners (2) + Named Members	No "Everyone" groups
Research sites	Explicit membership only + Sensitivity Label	Research data requires controlled access
Course sites	Instructor (Owner) + Students (Members via group)	Tied to course enrollment system
HR/Legal sites	Explicit membership + SAR/RCD	Crown jewels protection
Public sites	Read-only for org, limited editors	Prevent accidental oversharing

Access Review Recommendations

Implement periodic access reviews for sensitive sites:

Review Type	Frequency	Reviewer	Tool
Site membership	Quarterly	Site Owner	SharePoint UI or custom
External guest access	Monthly	Site Owner + IT	Entra ID Access Reviews
"Everyone" permissions	Weekly (automated)	IT Security	Custom PowerShell/Graph
Broken inheritance scan	Weekly (automated)	IT Security	Custom PowerShell/Graph
Sensitivity label compliance	Daily (automated)	Compliance	Purview DLP

Permission Reporting Script

# Comprehensive permission audit for a site
# Requires PnP.PowerShell module

Connect-PnPOnline -Url "https://tamu.sharepoint.com/sites/HR-Confidential" -Interactive

# Get all unique permissions in the site
$Report = @()

# Site-level permissions
$SitePerms = Get-PnPSiteCollectionAdmin
$Report += [PSCustomObject]@{ Level = "Site Admin"; Object = "Site Collection"; Principals = ($SitePerms.Title -join "; ") }

# Get all lists/libraries
$Lists = Get-PnPList | Where-Object { $_.Hidden -eq $false }

foreach ($List in $Lists) {
    # Check if list has unique permissions
    $HasUnique = Get-PnPList -Identity $List.Title -Includes HasUniqueRoleAssignments
    if ($HasUnique.HasUniqueRoleAssignments) {
        $ListPerms = Get-PnPListItemPermission -List $List.Title
        $Report += [PSCustomObject]@{ 
            Level = "Library (UNIQUE)"; 
            Object = $List.Title; 
            Principals = "Has unique permissions - review manually" 
        }
    }
    
    # Check items with unique permissions
    $Items = Get-PnPListItem -List $List.Title -PageSize 500
    foreach ($Item in $Items) {
        if ($Item.HasUniqueRoleAssignments) {
            $Report += [PSCustomObject]@{ 
                Level = "Item (UNIQUE)"; 
                Object = "$($List.Title)/$($Item.FieldValues.FileLeafRef)"; 
                Principals = "Has unique permissions - review manually" 
            }
        }
    }
}

$Report | Export-Csv -Path "C:\Reports\SitePermissionAudit.csv" -NoTypeInformation
Write-Host "Audit complete. Found $($Report.Count) permission entries." -ForegroundColor Green

Part 2: Site Lifecycle Management (New Governance)

This section implements the three-phase rollout (Ownership, Attestation, Inactivity).

Note: All policies start in Simulation Mode (Phase 1) to measure blast radius before sending automated emails to all users.

📋 Site Lifecycle Management: Complete Reference

What Is Site Lifecycle Management?

Site Lifecycle Management (SLM) is a SharePoint Advanced Management feature that automates governance of SharePoint sites throughout their existence—from creation to deletion. It addresses the common problem of "site sprawl" where hundreds or thousands of sites are created but never properly maintained or decommissioned.

The Three Pillars of Site Lifecycle

Pillar	Question It Answers	What Happens
Ownership Policy	"Who is responsible for this site?"	Ensures every site has multiple owners for redundancy
Attestation Policy	"Is this site still needed?"	Periodic owner confirmation that site is active and permissions are correct
Inactivity Policy	"Is anyone using this site?"	Detects dormant sites based on activity metrics

Policy Configuration Options

Ownership Policy Options:

Setting	Options	Recommendation
Minimum owners required	1, 2, 3	2 (redundancy without overhead)
Who can be owner	Site owners, Site admins, Both	Both (flexibility for larger sites)
Scope	All sites, Specific sites, Site templates	Start with All sites
Notification frequency	Weekly, Monthly, Quarterly	Monthly (balances awareness and fatigue)
Simulation mode	On/Off	Start On, transition to Off after review

Attestation Policy Options:

Setting	Options	Recommendation
Attestation frequency	3, 6, 9, 12 months	6 months (annual is too long, quarterly is fatiguing)
Who must attest	All owners, Any owner, Specific owners	Any owner (reduces bottleneck)
Grace period after non-response	7, 14, 30, 60 days	30 days (reasonable time to respond)
Non-compliance action	None, Read-only, Delete	Start with None, graduate to Read-only
Scope exclusions	By template, By site	Exclude Team sites connected to active Teams

Inactivity Policy Options:

Setting	Options	Recommendation
Inactivity threshold	3, 6, 9, 12 months	6 months (balances cleanup with legitimate dormancy)
Activity metrics counted	Views, Edits, Both	Both (some sites are "read-only references")
User types counted	Internal, External, Both	Internal only (external bots shouldn't extend life)
Non-compliance action	None, Notify, Read-only, Archive	Start with Notify
Re-certification period	Extends life by 3, 6, 12 months	6 months (owner can easily re-certify)

What "Activity" Means

Microsoft's inactivity detection uses these signals:

Activity Type	Counts as Active?	Notes
File views/opens	✅ Yes	Including previews
File edits/uploads	✅ Yes
Site page visits	✅ Yes	Home page, wiki pages
Search queries on site	⚠️ Maybe	If user clicks result
Admin operations	❌ No	Prevents admin activity from extending life
Automated processes	⚠️ Depends	Power Automate flows may or may not count
External user access	⚠️ Configurable	Can be included or excluded

Custom Email Notifications

Email Customization Now Available!

Microsoft now allows customization of Site Lifecycle Management notification emails—but only if a Global Administrator first configures a custom sender domain in the Microsoft 365 Admin Center.

Prerequisites for Email Customization:

A Global Administrator must configure the "Send email notifications from your domain" setting in the Microsoft Admin Center (MAC)
This changes the default sender from noreply@sharepoint.com to a custom address like noreply@yourdomain.com
Once enabled, the email customization options appear in all three Site Lifecycle Management policy types

How to Enable Custom Email Sender:

Sign in to the Microsoft 365 Admin Center as a Global Administrator
Navigate to Settings > Org settings > Organization profile
Select Send email notifications from your domain
Configure your custom sender email (e.g., noreply@tamu.edu)
Complete DNS verification if required

What You Can Customize (Once Enabled):

Field	Limit	Dynamic Variables Available
Sender	Custom domain email	None (set at tenant level)
Subject	100 characters	`$UserDisplayName`, `$SiteName`
Message body	500 characters	`$UserDisplayName`, `$SiteName`, `$SiteUrl`
Policy guideline URL	Valid HTTP link	None
Policy guideline text	Customizable	None

Example Custom Email:

Subject: Action Required: $SiteName needs your attention

Message: Hi $UserDisplayName, your SharePoint site "$SiteName" requires certification to confirm it's still actively used. Please review and certify at $SiteUrl. For guidance on our site governance policy, see our IT documentation.

📚 Reference: Site Lifecycle Management - Customize Email Notifications

What Microsoft Doesn't Let You Customize

Limitation	Impact	Workaround
Email customization requires Global Admin	SharePoint admins cannot enable this alone	Coordinate with tenant Global Admin to enable custom sender domain
Attestation questions are fixed	Cannot ask custom questions like "What budget funds this site?"	Create supplementary surveys linked from emails
No departmental delegation	Cannot let department IT manage lifecycle for their sites only	Use site collections with separate admins
No approval workflow for certification	Owner certification is immediate, no manager review	Custom approval workflow if needed
"Read-only" is all-or-nothing	Cannot make site read-only for external users only	Manual intervention required
No auto-archive to external storage	Sites can be read-only or deleted, but not auto-exported	Build custom archive process

Lifecycle Policy Decision Matrix

Use this matrix to decide your policy configuration:

Site Type	Ownership Requirement	Attestation Frequency	Inactivity Threshold	Non-Compliance Action
Department sites	2 owners	12 months	12 months	Read-only
Project sites	2 owners	6 months	6 months	Read-only → Delete
Research grant sites	2 owners	6 months	None (use retention)	Never delete
Course sites	1 owner (instructor)	Exclude	Semester-based	Archive after term
Personal OneDrive	N/A	N/A	HR trigger on departure	Transfer or delete
Team-connected sites	Managed by Teams	Exclude	Managed by Teams policies	Use Teams lifecycle

Integration with Microsoft Teams

⚠️ Critical: SharePoint sites connected to Microsoft Teams have special considerations:

Scenario	Behavior	Recommendation
Team is active, site is "inactive"	Site may show as inactive if users only use Teams UI	Exclude Team-connected sites from inactivity policy
Team is deleted	SharePoint site enters "Deleted sites" retention	Configure Teams expiration policy separately
Team is archived	SharePoint site becomes read-only	No SLM policy needed
Team has no owners	Both Teams and SharePoint ownership policies apply	Align policies to avoid double-notification

Recommendation: Use Microsoft Teams lifecycle policies for Team-connected sites and SharePoint lifecycle policies for standalone sites.

Policy A: Site Ownership (Accountability)

Goal: Ensure every site has at least 2 owners (redundancy). Prevents "Ownerless" sites when faculty/staff leave.

Click-Ops:

Go to SharePoint Admin Center > Policies > Site lifecycle management.
Select Require site owners.
Create Policy:
- Policy Scope: All sites (OneDrive excluded by default).
- Ownership criteria:
  - Required number of owners: 2.
  - Who can be an owner: Site owners and admins.
- Notifications:
  - Send to: Current owners and active site members.
  - Message: "Action Required: Add a second owner to maintain site supportability."
- Mode: Select Simulation.
Click Save.

Transition to Active (Phase 2): After reviewing simulation reports, edit policy and switch Mode to Active.

Policy B: Site Attestation (Validation)

Goal: Require owners to confirm every 6 months that the site is still needed and permissions are accurate.

Click-Ops:

Go to SharePoint Admin Center > Policies > Site lifecycle management.
Select Require site attestation.
Create Policy:
- Policy Scope: All sites.
- Frequency: Every 6 months (or 12 or 3 based on risk).
- Attestors: Site owners and admins.
- Enforcement:
  - Start with Do nothing (No auto-archive yet).
  - Future State: "Set to Read-Only" after 3 failed notifications.
- Mode: Select Simulation.
Click Save.

Transition to Active (Phase 3): Switch to Active mode to start sending monthly batches of attestation emails.

Policy C: Inactive Sites (Cleanup)

Goal: Identify sites with no activity for 6 months and ask owners to certify or delete them.

Click-Ops:

Go to SharePoint Admin Center > Policies > Site lifecycle management.
Select Detect inactive sites.
Create Policy:
- Policy Scope: All sites.
- Inactivity threshold: 6 months.
- Recipients: Site owners and admins.
- Certification: "Certifying keeps the site active for another year."
- Enforcement:
  - Start with Do nothing.
- Mode: Select Simulation.
Click Save.

Transition to Active (Phase 4): Switch to Active mode. Sites certified by owners are reset for 6 months. Unresponsive sites appear in a report for IT review.

Communication Templates

Template

Subject: Important: Changes to File Sharing Settings - Action May Be Required

To: All Faculty and Staff

Body:

As part of our ongoing commitment to data security and compliance with [FERPA/HIPAA/State regulations], we are implementing enhanced sharing controls in SharePoint and OneDrive.

What's Changing (Effective [DATE]):

Anonymous ("Anyone") sharing links will now expire after 30 days
The default permission for shared links will be "View" instead of "Edit"
Guest access to shared content will expire after 30 days of inactivity

What You Need to Do:

Review your shared links: Go to OneDrive > My files > Shared to see what you've shared
Update critical shares: If you have ongoing collaborations requiring permanent access, consider inviting collaborators as guests instead of using anonymous links
No action needed for links shared with specific people (@tamu.edu addresses)

Why This Matters: These changes help ensure that shared data doesn't remain accessible indefinitely, reducing the risk of unauthorized access to sensitive student and research information.

Questions? Contact the IT Help Desk or visit [knowledge base link].

Validation & Success Criteria

#	Validation Item	Test Method	Success Criteria
1	Anonymous Link Expiration	Create "Anyone" link on test file	Expiry date shows 30 days from today
2	Default Permission	Share file with colleague	Default toggle is "Can view"
3	Legacy Auth Blocked	Test with old Outlook client	Connection rejected
4	Lifecycle Simulation	Check Site Lifecycle dashboard	Reports generating, no emails sent
5	Block Download	Access sensitive site from personal device	Can view but not download
6	Data Access Reports	Run "Anyone links" report	Report generates with accurate data

Validation Script

Connect-SPOService -Url "https://tamu-admin.sharepoint.com"

# Validate tenant settings
$Tenant = Get-SPOTenant

Write-Host "=== Sharing Settings Validation ===" -ForegroundColor Cyan
Write-Host "Anonymous Link Expiry: $($Tenant.RequireAnonymousLinksExpireInDays) days" 
Write-Host "Default Link Type: $($Tenant.DefaultSharingLinkType)"
Write-Host "Default Link Permission: $($Tenant.DefaultLinkPermission)"
Write-Host "Legacy Auth Enabled: $($Tenant.LegacyAuthProtocolsEnabled)"
Write-Host "Idle Session Signout: $($Tenant.IdleSessionSignOut)"

# Check for expected values
$Issues = @()
if ($Tenant.RequireAnonymousLinksExpireInDays -ne 30) { $Issues += "Anonymous link expiry not 30 days" }
if ($Tenant.DefaultLinkPermission -ne "View") { $Issues += "Default permission not View" }
if ($Tenant.LegacyAuthProtocolsEnabled -eq $true) { $Issues += "Legacy auth still enabled" }

if ($Issues.Count -eq 0) {
    Write-Host "`n✅ All settings validated successfully!" -ForegroundColor Green
} else {
    Write-Host "`n⚠️ Issues found:" -ForegroundColor Yellow
    $Issues | ForEach-Object { Write-Host "  - $_" -ForegroundColor Yellow }
}

Security & Compliance Considerations

Scale: Microsoft limits notifications to avoid spamming. If a user receives an attestation email, they won't get another lifecycle email for 30 days.
Actionable Messages: These policies use Outlook Actionable Messages (buttons inside the email). Ensure Exchange Online isn't blocking actionable messages for internal senders.
Research Sites: Research projects often go dormant for months and then reactivate. The Inactivity Policy allows owners to simply click "Certify" to keep the site without forced deletion, protecting grant data.

Phase 4: Protection - Sensitivity Labels & Information Protection

Phase Objective

Apply persistent protection to your sensitive data by creating and deploying Sensitivity Labels. Labels embed protection (encryption, visual marking, access restrictions) directly into files and emails, ensuring data remains protected regardless of where it travels.

Decision Point

We are now implementing the Classification Taxonomy defined in Phase 0.

Confidential - FERPA: Internal access only, visual marking.
Restricted - Research/HIPAA: Encrypted (Co-Author permissions for internal users), external sharing prohibited.

Background & Context

Sensitivity labels are the "Digital Price Tags" for your data. In a Zero Trust model, we stop relying on the network to protect the file. Instead, we embed the protection into the file itself.

If a researcher copies a file labeled "Restricted - Research/HIPAA" to a USB drive and loses it, the file is useless to the thief because they cannot authenticate against the Texas A&M Azure AD to decrypt it.

Prerequisites

Requirement	Minimum / Version	Notes
Role	`Compliance Administrator`	Required for Label management.
Licensing	Microsoft 365 A5	Required for Service-Side Auto-Labeling (applying labels to data at rest).
PowerShell	`ExchangeOnlineManagement`	V3.0.0+.

Procedure / Implementation

Step 1 – Create the "Restricted" Label (Encryption)

Goal: Create a label that enforces encryption but allows internal collaboration (Co-Authoring).

Click-Ops (Purview Portal):

Navigate to Information Protection > Labels.
Click + Create a label.
Name/Display Name: Restricted - Research/HIPAA.
Description: "High Risk Data (HIPAA/CUI). Encrypted. External Sharing Prohibited."
Scope: Select Items (Files, Emails) and Groups & sites (to enable container labeling later).
Protection settings:
- Check Apply encryption.
- Check Apply content marking.
Encryption:
- Assign permissions now.
- User access content expires: Never.
- Offline access: Always.
- Assign permissions: Click Add users or groups > All users in your organization.
- Permissions: Select Co-Author (Custom > Edit/View/Save).
- Why Co-Author? If you select "Viewer", researchers cannot collaborate on grants, and they will bypass the system.
Content Marking: Add a Footer: RESTRICTED DATA - TEXAS A&M SYSTEM. Font color: Red.
Click Create label.

PowerShell (Creation Only): Note: We recommend UI for permission assignment due to GUID complexity.

Connect-IPPSSession

New-Label -Name "Restricted - Research/HIPAA" `
    -DisplayName "Restricted - Research/HIPAA" `
    -Tooltip "High Risk Data. Encrypted. External Sharing Prohibited." `
    -EncryptionEnabled $true `
    -ContentMarkingEnabled $true `
    -ContentMarkingHeader "RESTRICTED DATA - TEXAS A&M SYSTEM" `
    -ContentMarkingHeaderFontColor "Red" `
    -ContentMarkingHeaderFontSize 12

Step 1a – Create Complete Label Taxonomy

Goal: Implement the full classification taxonomy defined in Phase 0.

Label Hierarchy:

Click-Ops - Create Each Label:

Label	Encryption	Marking	Default For	Notes
Public	None	Footer: "Public Information"	Published research, press releases	No restrictions
General	None	None	Default for all content	Internal use, low risk
Confidential - FERPA	Yes - View Only (External)	Header + Footer	Student records	External recipients can view but not edit
Restricted - Research/HIPAA	Yes - Co-Author (Internal Only)	Header + Footer + Watermark	CUI, HIPAA, ITAR	Block all external access

Label 1: Public

Navigate to Information Protection > Labels > + Create a label
Name: Public
Description: "Information approved for public release. No confidentiality requirements."
Scope: Items (Files, Emails)
Protection: None
Content Marking: Footer only - "PUBLIC INFORMATION - TEXAS A&M UNIVERSITY"
Click Create

Label 2: General (Default)

Click + Create a label
Name: General
Description: "Internal business information. Not intended for public release but low risk if disclosed."
Scope: Items (Files, Emails), Groups & sites
Protection: None
Content Marking: None (reduces visual clutter for everyday documents)
Click Create

Label 3: Confidential - FERPA

Click + Create a label
Name: Confidential - FERPA
Description: "Student education records protected under FERPA. Internal access only. External sharing requires consent."
Scope: Items (Files, Emails), Groups & sites
Protection Settings:
- ☑️ Apply encryption
- ☑️ Apply content marking
Encryption:
- Assign permissions now
- User access expires: Never
- Allow offline access: Always
- Assign permissions:
  - All users in your organization → Co-Author
  - Any authenticated users → Viewer (allows external view if explicitly shared)
Content Marking:
- Header: CONFIDENTIAL - FERPA PROTECTED
- Footer: This document contains student education records protected under FERPA (20 U.S.C. § 1232g)
- Font color: Orange
Click Create

Step 1b – Configure Container Labels (Teams & SharePoint Sites)

Goal: Apply sensitivity labels to Teams and SharePoint sites to control privacy, external sharing, and access from unmanaged devices at the container level, not just individual files.

Why Container Labels Matter:

A file's label can be changed by users (unless locked)
A site's label controls the environment where files live
Combined, they provide defense in depth

Container Settings Available:

Setting	What It Controls
Privacy	Public (anyone in org) vs. Private (members only)
External sharing	Override tenant defaults per sensitivity
Unmanaged device access	Full, limited, or blocked
External user access	Allow/block guest additions to Teams

Click-Ops - Enable Container Labels:

First, enable the feature (one-time setup):

Navigate to Information Protection > Labels
Click on your Confidential - FERPA label
Click Edit label
On the Scope page, ensure Groups & sites is checked
Continue to Groups & sites settings:
- Privacy: Private - only team owners and members can access
- External user access: Uncheck "Let group owners add people outside the organization"
- Unmanaged devices: Select "Allow limited, web-only access"
Save changes

PowerShell (Enable Container Labels Tenant-Wide):

# This requires Azure AD PowerShell - run once to enable the feature
Connect-AzureAD

$Setting = Get-AzureADDirectorySetting | Where-Object { $_.DisplayName -eq "Group.Unified" }

if ($null -eq $Setting) {
    $Template = Get-AzureADDirectorySettingTemplate | Where-Object { $_.DisplayName -eq "Group.Unified" }
    $Setting = $Template.CreateDirectorySetting()
}

$Setting["EnableMIPLabels"] = "True"
Set-AzureADDirectorySetting -Id $Setting.Id -DirectorySetting $Setting

Write-Host "✅ Container labels enabled for Groups & Sites" -ForegroundColor Green

Container Label Matrix:

Label	Privacy	External Sharing	External Guests	Unmanaged Devices
General	Public or Private	Existing guests	Allowed	Full access
Confidential - FERPA	Private	Existing guests only	Blocked	Limited (web-only)
Restricted - Research/HIPAA	Private	Only people in org	Blocked	Blocked

Step 1c – Configure Advanced Message Encryption (A5 Feature)

Goal: Extend email encryption with branding, expiration, and revocation capabilities beyond standard Office Message Encryption.

A5-Exclusive Capabilities:

Feature	Standard OME	Advanced Message Encryption (A5)
Encryption	✅	✅
Custom branding	❌	✅
Message expiration	❌	✅
Message revocation	❌	✅
Multiple templates	❌	✅

Click-Ops (Exchange Admin Center):

Navigate to https://admin.exchange.microsoft.com
Go to Mail flow > Rules
Click + Add a rule > Apply Office 365 Message Encryption

Or configure via Purview Sensitivity Label:

Edit your Restricted - Research/HIPAA label
Under Encryption, configure:
- Set an expiration for email access:
  - ☑️ Enable
  - Days after email is sent: 30
- Allow users to revoke access:
  - ☑️ Enable (users can revoke from outlook.office.com/encryption)

Custom Branding Template:

Navigate to Purview > Information Protection > Encryption
Click Branding templates > + Create
Configure:
- Template name: TAMU Research Communication
- Portal text: "This message contains confidential Texas A&M research data."
- Logo: Upload university logo
- Background color: Maroon (#500000)
- Disclaimer: "Unauthorized access or distribution is prohibited."

PowerShell:

Connect-ExchangeOnline

# Create custom branding template
New-OMEConfiguration -Identity "TAMU Research Communication" `
    -ExternalMailExpiryInDays 30 `
    -IntroductionText "This message contains confidential Texas A&M research data." `
    -DisclaimerText "Unauthorized access or distribution is prohibited under federal and state law." `
    -OTPEnabled $true `
    -SocialIdSignIn $false  # Require work/school account, not Google/Facebook

# Apply to mail flow rule
New-TransportRule -Name "Encrypt Research Data" `
    -ApplyOMEConfigurationForEmailMessageEncryptedByAzureRMS $true `
    -OMEConfigurationToApply "TAMU Research Communication" `
    -HeaderContainsMessageHeader "msip_labels" `
    -HeaderContainsWords "Restricted"

Write-Host "✅ Advanced Message Encryption configured" -ForegroundColor Green

Revocation Considerations

When a user revokes access to an encrypted email:

External recipients immediately lose access Audit log captures the revocation event Consider documenting a process for when revocation is appropriate (suspected breach, accidental send)

Step 2 – Publish Labels (The Policy)

Goal: Make labels visible to the Pilot Group.

Click-Ops:

Information Protection > Label policies.
Click Publish label.
Choose labels: Select Public, General, Confidential - FERPA, Restricted - Research/HIPAA.
Users/Groups: Select IT_Security_Pilot.
Policy Settings:
- Default label: General.
- Mandatory labeling: Unchecked (for now).
- Justification: Checked (Users must explain why they lower a label).
Name: Global Label Policy - Pilot.

PowerShell:

$PilotGroup = "IT_Security_Pilot@tamu.edu"

New-LabelPolicy -Name "Global Label Policy - Pilot" `
    -Labels "Public", "General", "Confidential - FERPA", "Restricted - Research/HIPAA" `
    -AddDistributionGroup $PilotGroup `
    -Mandatory $false `
    -JustificationRequired $true `
    -DefaultLabel "General"

Step 3 – A5 Service-Side Auto-Labeling (Data at Rest)

Goal: Automatically find and encrypt high-risk data sitting in OneDrive/SharePoint without user interaction. This is an A5 exclusive feature.

Click-Ops:

Information Protection > Auto-labeling.
Create auto-labeling policy.
Template: Custom.
Name: Auto-Encrypt High Volume PII.
Locations: SharePoint sites and OneDrive accounts.
- Scope: Select specific Research sites for the pilot.
Rules:
- Condition: Content contains U.S. Social Security Number (High confidence).
- Instance count: 10 to Any (High volume).
Label to apply: Restricted - Research/HIPAA.
Mode: Run in simulation mode.
- Critical: This creates a report of what would happen. Do not turn on enforcement until you review the report.

Step 3a – Client-Side Auto-Labeling (Real-Time Recommendations)

Goal: Configure labels to automatically recommend or apply as users create content in Office apps, providing real-time guidance.

Difference from Service-Side Auto-Labeling:

Aspect	Client-Side	Service-Side (Step 3)
When it runs	Real-time as user types	Scheduled scan of stored content
Where	Office desktop/web apps	SharePoint, OneDrive, Exchange at rest
User interaction	Recommendation or auto-apply	Silent application
Licensing	E3+ (recommend), E5 (auto-apply)	E5/A5 only

Click-Ops:

Edit your Confidential - FERPA label
Navigate to Auto-labeling for files and emails
Toggle Auto-labeling for files and emails to On
Conditions:
- Add condition: Content contains
- Select: TAMU Employee/Student UIN (Custom SIT)
- Instance count: 1 to Any
When content matches these conditions:
- Select: Recommend that users apply the label (safer for pilot)
- Or: Automatically apply the label (after pilot validation)
Customized message:

"This document appears to contain student information (UIN detected). The 'Confidential - FERPA' label is recommended to ensure proper protection."
Save

Repeat for Restricted - Research/HIPAA:

Label	Trigger SIT	Instance Count	Action
Confidential - FERPA	TAMU Employee/Student UIN	1+	Recommend
Restricted - Research/HIPAA	U.S. Social Security Number	5+	Auto-apply
Restricted - Research/HIPAA	TAMU Research Grant ID + Export Control keywords	1+	Recommend

PowerShell:

Connect-IPPSSession

# Configure client-side auto-labeling conditions on existing label
Set-Label -Identity "Confidential - FERPA" `
    -AutoApplyType Recommend `
    -Conditions @{
        SensitiveInformationType = @(
            @{Name = "TAMU Employee/Student UIN"; minCount = 1}
        )
    } `
    -AutoLabelingPolicyTip "This document appears to contain student information. Consider applying the Confidential - FERPA label."

Validation & Success Criteria

#	Validation Item	Test Method	Success Criteria
1	Label Visibility	Open Word as pilot user	All 4 labels visible in Sensitivity menu
2	Label Priority	Check label order in portal	Restricted > Confidential > General > Public
3	Encryption - Internal	Apply "Restricted" label, share internally	Co-author can edit
4	Encryption - External	Email "Restricted" file to Gmail	Recipient cannot open (no A&M auth)
5	Container Label	Create Team with "Confidential" label	External sharing blocked, privacy set to Private
6	Client Auto-Label	Type UIN in new Word doc	"Confidential - FERPA" recommendation appears
7	Service Auto-Label	Check simulation report	Correct files identified, acceptable false positive rate
8	Content Marking	Open labeled document	Header/footer/watermark visible

Validation Script

Connect-IPPSSession

Write-Host "=== Label Validation ===" -ForegroundColor Cyan

# List all labels and their settings
Get-Label | Select-Object Name, Priority, ContentType, 
    @{N='Encryption';E={$_.EncryptionEnabled}},
    @{N='Marking';E={$_.ContentMarkingEnabled}} | 
    Format-Table -AutoSize

# List label policies
Get-LabelPolicy | Select-Object Name, Mode, 
    @{N='Labels';E={($_.Labels -join ', ')}},
    @{N='Scope';E={$_.ExchangeLocation}} |
    Format-Table -AutoSize

# Check auto-labeling policies
Get-AutoSensitivityLabelPolicy | Select-Object Name, Mode, 
    @{N='Locations';E={$_.SharePointLocation.Count}} |
    Format-Table -AutoSize

Security & Compliance Considerations

Encryption Key Management

When you enable encryption on sensitivity labels:

Microsoft manages the encryption keys by default (Microsoft-managed keys)
For highest security requirements (ITAR, classified adjacent), consider Customer Key or Double Key Encryption (covered in later phases)
Encrypted files cannot be scanned by third-party DLP tools
eDiscovery can still search encrypted content (super user access)

Key Considerations:

Consideration	Recommendation
Label Priority	Higher sensitivity = higher priority number. Prevents downgrade without justification.
Mandatory Labeling	Enable after pilot to ensure all content is classified. Start with "recommend" mode.
Justification	Always require justification for label downgrades. Creates audit trail.
Guest Access	"Viewer" permission allows external viewing of encrypted content if explicitly shared. "Co-Author" blocks external entirely.
Offline Access	"Always" allows decryption without internet. "Never" requires constant connectivity. Balance usability vs. security.
Mobile Devices	Sensitivity labels work in Office mobile apps. Ensure Intune policies complement label protections.

FERPA Alignment:

FERPA Requirement	Label Implementation
Limit access to school officials with legitimate interest	Encryption restricts to internal users with Co-Author permission
Audit access to education records	Label application and file access logged in Unified Audit Log
Prevent unauthorized disclosure	External sharing blocked by "Restricted" label encryption

Communication Templates

End-User: Introduction to Sensitivity Labels

Template

Subject: New: Sensitivity Labels Now Available in Office Apps

To: Pilot Group

Body:

We're excited to introduce Sensitivity Labels - a new way to classify and protect your documents and emails based on how sensitive they are.

What You'll See:

Starting [DATE], you'll notice a new Sensitivity button in Word, Excel, PowerPoint, and Outlook. This lets you tag your content with the appropriate classification:

Label	When to Use
🌐 Public	Press releases, published research, public-facing content
📁 General	Day-to-day internal documents, meeting notes
🔒 Confidential - FERPA	Student records, advising notes, grade information
⛔ Restricted - Research/HIPAA	HIPAA data, export-controlled research, CUI

What Happens When You Apply a Label:

Public/General: No restrictions, but helps us track data classification
Confidential: Adds header/footer markings, may restrict external sharing
Restricted: Encrypts the file so only authorized Texas A&M users can open it

Quick Start:

Open any Office document
Click Sensitivity in the ribbon (or Home tab)
Select the appropriate label
Save your document

Questions? Contact the IT Help Desk at [phone/email] or visit [knowledge base link].

End-User: What to Do When You See a Label Recommendation

Template

Subject: Guide: Responding to Sensitivity Label Recommendations

To: All Users

Body:

You may see pop-up recommendations in Office apps suggesting a sensitivity label for your document. Here's what to do:

When You See a Recommendation:

A yellow banner will appear saying something like:

"This document appears to contain student information. The 'Confidential - FERPA' label is recommended."

Your Options:

Option	When to Choose
Apply Label	The recommendation is correct - your document contains the identified sensitive data
Dismiss	You've reviewed the content and determined it's a false positive (e.g., test data, sample numbers)
Change Label	The recommendation is close but a different label is more appropriate

Common Scenarios:

Scenario	Recommended Action
Document contains real student UINs	Accept "Confidential - FERPA" recommendation
Document contains sample/test UINs for training	Dismiss recommendation, apply "General"
Research grant proposal with PI information	Accept "Confidential" or upgrade to "Restricted" if export-controlled

Remember: When in doubt, choose the MORE restrictive label. You can always request a downgrade with justification.

IT Staff: Label Policy Deployment Notification

Template

Subject: [IT Staff] Sensitivity Label Policy Deployment - Phase [X]

To: IT Security Team, Help Desk

Body:

Deployment Summary:

Item	Details
Policy Name	Global Label Policy - Pilot
Deployment Date	[DATE]
Scope	[Group/Department]
Labels Included	Public, General, Confidential - FERPA, Restricted - Research/HIPAA
Default Label	General
Mandatory Labeling	No (Phase 1)

Expected User Experience:

Users will see "Sensitivity" button in Office apps within 24 hours
Default label "General" will be suggested for new documents
Auto-labeling recommendations will appear when UINs or SSNs are detected

Known Issues / FAQ:

Issue	Resolution
"Sensitivity button not appearing"	Sign out/in to Office, wait 24 hours for policy sync
"Can't remove encryption from file"	By design - contact data owner to re-share without encryption
"Label recommendation seems wrong"	User can dismiss; report patterns to [email] for SIT tuning

Escalation Path:

Help Desk: Basic label questions, visibility issues
Security Team: Encryption problems, policy exceptions
Compliance: Business justification for label changes, regulatory questions

Monitoring:

Review Activity Explorer daily for the first week:

Label application rates
Override/dismissal rates
Failed encryption attempts

Sub-Phase 4.5: Advanced Encryption (Customer Key & Double Key Encryption)

Optional - For High-Security Requirements Only

This sub-phase covers advanced encryption options for organizations with specific regulatory requirements (ITAR, CUI, CMMC Level 3+, or "classified-adjacent" research). Most implementations do not require this. Microsoft-managed encryption provides excellent security for typical use cases.

When to Consider Advanced Encryption

Encryption Option	Use Case	Complexity
Microsoft-Managed Keys (Default)	Standard enterprise protection	Low
Customer Key	Regulatory requirement for key control; prevent Microsoft access	Medium
Double Key Encryption (DKE)	Most sensitive content where even Microsoft admin access is unacceptable	High

Customer Key Overview

What It Does: You provide your own encryption keys (stored in Azure Key Vault) that wrap Microsoft's encryption keys. This gives you the ability to "revoke" Microsoft's access to your data by destroying your keys.

Prerequisites:

Azure Key Vault (Premium SKU required)
Two separate Azure subscriptions for key redundancy
Microsoft 365 A5 or E5 licensing
Compliance Administrator and Azure subscription permissions

Customer Key Implementation Summary

High-Level Steps:

Create Azure Key Vaults in two separate Azure regions/subscriptions
Generate RSA keys (2048-bit minimum) in each vault
Configure Key Vault access policies for Microsoft services
Register Customer Key with Microsoft via PowerShell
Create Data Encryption Policy (DEP) for Exchange, SharePoint, or Teams
Assign DEP to mailboxes/sites

PowerShell Reference:

# After Key Vault setup, register with M365
Connect-ExchangeOnline

# Create Data Encryption Policy
New-DataEncryptionPolicy -Name "CUI Research DEP" `
    -AzureKeyIDs "https://vault1.vault.azure.net/keys/key1", "https://vault2.vault.azure.net/keys/key2"

# Assign to mailboxes
Set-Mailbox -Identity "researcher@tamu.edu" -DataEncryptionPolicy "CUI Research DEP"

Reference: Set up Customer Key

Double Key Encryption Overview

What It Does: Content is encrypted twice—once with a Microsoft-managed key and once with a key you control in your own infrastructure. Microsoft never has access to your key, meaning even Microsoft support cannot decrypt your content.

Trade-offs:

Benefit	Limitation
Maximum security and control	Cannot use cloud-based search/eDiscovery on DKE content
Meets strict sovereignty requirements	Limited to Windows/Mac Office apps (no mobile/web)
Key revocation stops all access	Requires on-premises or Azure-hosted DKE service

Double Key Encryption Decision Framework

Choose DKE When:

Content is so sensitive that even Microsoft admin access is unacceptable
Regulatory framework explicitly requires customer-held keys (some ITAR interpretations)
Legal or contractual obligation to demonstrate no third-party key access
Content does not need cloud search/eDiscovery (or you'll handle locally)

Do NOT Choose DKE When:

Standard A5 encryption meets regulatory requirements
You need full eDiscovery across all content
Users require mobile/web access to encrypted content
You don't have infrastructure to host DKE key service

Implementation requires:

Azure App Service or on-premises web service hosting the DKE key
Sensitivity label configured with DKE endpoint URL
Client-side Office apps (Word, Excel, PowerPoint) on Windows/Mac

Reference: Double Key Encryption overview

DLP and Prevention Controls - Implement Later

Phase 10 (DLP) is intentionally placed later in this guide. DLP implementation is a significant undertaking that may overlap with existing tools (Proofpoint DLP, Elastic, etc.). Complete Parts 1-4 first to establish a secure foundation, then coordinate with your security team on DLP rollout.

Jump to Part 5: Prevention when you're ready to implement DLP.

Phase 5: Zero Trust Access Control (Entra ID & MDCA)

Phase Objective

Implement Zero Trust access controls using Conditional Access policies and Microsoft Defender for Cloud Apps to enforce context-aware access based on device compliance, location, and risk level.

Decision Point

Before proceeding, confirm your access control philosophy with leadership:

Block vs. Limited Access: Will unmanaged devices be blocked entirely, or allowed with limited functionality (view-only, no download)?
Session Controls: Will you use MDCA session policies to watermark downloads or block copy/paste?
Risk Tolerance: What authentication strength is required for sensitive data access?

Background & Context

Conditional Access is the Zero Trust policy engine. While Sensitivity Labels protect the file itself, Conditional Access protects the session—ensuring that even if a user has permission to a file, they can only access it from trusted contexts.

Example: A faculty member has access to FERPA data. With Conditional Access:

From their managed university laptop: Full access
From a personal device at home: View in browser only (no download, no sync)
From an unfamiliar location with risky sign-in: Blocked, require re-authentication

Prerequisites

Requirement	Details
Licensing	Microsoft Entra ID P1/P2 (included in A5)
Role	`Conditional Access Administrator` or `Security Administrator`
Dependency	SharePoint site policies configured (Phase 3)
Optional	Microsoft Defender for Cloud Apps for session controls

Procedure / Implementation

Step 1 – Configure Endpoint DLP Settings

Goal: Define which apps are "Allowed" to handle sensitive data and force browser compliance.

Click-Ops (Purview Portal):

Data Loss Prevention > Settings > Endpoint DLP settings.
File path exclusions: Add research apps like Matlab.exe, LabView.exe, SPSS.exe to prevent DLP from crashing them.
Browser restrictions:
- Unallowed browsers: Add chrome.exe, firefox.exe, opera.exe.
- Action: Block with override.
- Why? This forces users to use Microsoft Edge (which has native DLP) or install the "Microsoft Purview Extension" for Chrome to access sensitive data.

PowerShell: Not available via PowerShell. Must be configured in UI.

Step 2 – Create "Research Protection" Policy (All Workloads)

Goal: A single unified policy to stop data exfiltration across Email, Teams, SharePoint, and Devices.

Click-Ops:

Data Loss Prevention > Policies > Create policy.
Custom > Name: DLP - Global Research Protection.
Locations: Select Exchange, SharePoint, OneDrive, Teams, and Devices (Endpoint).
Rules > Create Rule:
- Name: Warn - Research Data Egress.
- Conditions:
  - Content contains: TAMU Employee/Student UIN (Custom SIT) OR Sensitivity Label Restricted - Research/HIPAA.
  - Content is shared: With people outside my organization.
- Actions:
  - Restrict access: Block people outside your organization.
  - Audit or restrict activities on devices:
    - Copy to USB: Block.
    - Copy to network share: Block.
    - Print: Block.
- User notifications: On.
  - Policy tips: "You are attempting to share Restricted Research Data externally."
- User overrides: On.
  - Require a business justification.
Mode: Test it out first (Show policy tips).

PowerShell (Rapid Deploy):

Connect-IPPSSession

# Get Identity Objects
$UINSIT = Get-DlpSensitiveInformationType -Identity "TAMU Employee/Student UIN"
$RestrictedLabel = Get-Label -Identity "Restricted - Research/HIPAA"

# Create Policy Container (All Locations)
New-DlpCompliancePolicy -Name "DLP - Global Research Protection" `
    -ExchangeLocation All -SharePointLocation All -OneDriveLocation All `
    -TeamsChatLocation All -EndpointDlpLocation All `
    -Mode TestWithNotifications

# Create Rule (Warn on UIN/Restricted Label Egress)
# Note: Device restrictions (USB Block) are part of the 'Action' logic handled by the policy engine
New-DlpComplianceRule -Name "Warn - Research Data Egress" `
    -Policy "DLP - Global Research Protection" `
    -ContentContainsSensitiveInformation @(@{Name=$UINSIT.Name; minCount="1"}) `
    -ContentContainsSensitivityLabel $RestrictedLabel.ImmutableId `
    -SentToScope NotInOrganization `
    -BlockAccess $true `
    -NotifyUser Owner `
    -NotifyPolicyTipDisplayOption "Dialog" `
    -NotifyAllowOverride "WithJustification" `
    -DeviceRestrictionAction Block 

Validation & Success Criteria

Label Visibility: Pilot users see the "Restricted" label in Word/Excel.
Encryption Test: Email a "Restricted" file to a personal Gmail account. Attempt to open it. It should prompt for A&M login and fail.
Endpoint Block: On a pilot device, try to copy a "Restricted" file to a USB drive. You should receive a Windows Notification blocking the action.
Auto-Labeling: Review the Simulation report to verify it is correctly identifying SSN clusters in SharePoint without false positives.

Continue with Zero Trust Access Control

The Zero Trust Access Control (Phase 5) content continues with Conditional Access and MDCA configuration. This works together with the SharePoint governance policies from Phase 3.

Part 4: Conditional Access Integration

Decision Point

This section implements the "Verify Explicitly" pillar of Zero Trust. We must decide how to handle Unmanaged Devices (personal laptops/phones).

Strategy A (Limited Web Access): Allow users to view/edit files in the browser but block downloads.
Strategy B (Granular Block): Allow users to work freely but block downloads only for "Restricted" files.
Recommendation: Combine both. Use Limited Web Access as the baseline, and MDCA Session Control for deep inspection of high-risk data.

Access control is no longer about Firewalls; it is about Identity and Device Trust.

In a university environment, we cannot simply block personal devices (BYOD). Faculty need to access email from home, and students use personal laptops. However, we cannot allow them to download sensitive research data (CUI/HIPAA) to those insecure devices.

We will use a "Better Together" integration:

Conditional Access (Entra ID): Determines who is logging in and what device they are using.
Defender for Cloud Apps (MDCA): Acts as a reverse proxy. If the device is "Unmanaged," MDCA wraps the session to prevent copy/paste/download/print based on the content of the file.

Additional Prerequisites:

Requirement	Minimum / Version	Notes
Role	`Conditional Access Administrator`	Required for Entra ID policies.
Role	`Security Administrator`	Required for MDCA policies.
Licensing	Microsoft 365 A5	Required for MDCA Session Controls.
PowerShell	`Microsoft.Graph`	For CA Policy creation.

Sub-Part: Configure SharePoint for Limited Access

Before applying policies, we must tell SharePoint how to handle unmanaged devices natively.

Step 1 – Set SharePoint Unmanaged Device Preference

Goal: Ensure SharePoint supports "Web-Only" access. This disables the "Download", "Sync", and "Print" buttons in the browser UI when the session is restricted.

Click-Ops (SharePoint Admin Center):

Navigate to https://<tenant>-admin.sharepoint.com.
Go to Policies > Access control.
Select Unmanaged devices.
Select Allow limited, web-only access.
Click Save.

PowerShell (Automation):

Connect-SPOService -Url "https://tamu-admin.sharepoint.com"
Set-SPOTenant -ConditionalAccessPolicy AllowLimitedAccess
Write-Host "✅ SharePoint configured for Web-Only access on unmanaged devices." -ForegroundColor Green

Part 2: Conditional Access Policy (The Trigger)

Step 2 – Create CA Policy for Unmanaged Devices

Goal: Detect if a device is "Compliant" (Managed by Intune/Hybrid Joined). If NOT, route the session through MDCA for inspection.

Click-Ops (Entra Admin Center):

Navigate to Protection > Conditional Access > Policies.
Click + New policy.
Name: CA001 - Block Downloads on Unmanaged Devices.
Users: All users (Exclude Break-glass Accounts).
Target Resources: Select Office 365 SharePoint Online (Includes OneDrive).
Conditions > Device Filter:
- Configure: Yes.
- Rule: Exclude devices where device.isCompliant Equals True OR device.isHybridAzureADJoined Equals True.
- Logic: This policy now targets ONLY personal/unmanaged devices.
Session:
- Select Use Conditional Access App Control.
- Select Use custom policy.
- Note: This hands off enforcement to Defender for Cloud Apps.
Enable Policy: Report-only (initially), then On.

PowerShell (Automation):

Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"

# Define Conditions (Target SharePoint, Exclude Compliant Devices)
$Conditions = @{
    Applications = @{ includeApplications = @("00000003-0000-0ff1-ce00-000000000000") } # SharePoint App ID
    Users = @{ includeUsers = @("All"); excludeUsers = @("Guest") }
    Devices = @{
        DeviceFilter = @{
            Mode = "Exclude"
            Rule = "device.isCompliant -eq True -or device.isHybridAzureADJoined -eq True"
        }
    }
}

# Define Controls (Route to MDCA)
$SessionControls = @{
    ApplicationEnforcedRestrictions = @{ IsEnabled = $true }
    CloudAppSecurity = @{ 
        IsEnabled = $true
        CloudAppSecurityType = "BlockDownloads" # Maps to Custom Policy
    }
}

# Create Policy
New-MgIdentityConditionalAccessPolicy -DisplayName "CA001 - Block Downloads on Unmanaged Devices" `
    -State "EnabledForReportingButNotEnforced" `
    -Conditions $Conditions `
    -SessionControls $SessionControls

Write-Host "✅ Conditional Access Policy created (Report Mode)." -ForegroundColor Green

Part 3: Defender for Cloud Apps (The Enforcer)

Step 3 – Configure MDCA Session Policy

Goal: If the user is on a personal device (routed by CA above), allow them to work, but Block Download if the file is labeled "Restricted".

Click-Ops (Microsoft Defender Portal):

Navigate to security.microsoft.com > Cloud Apps > Policies > Policy management.
Click + Create policy > Session policy.
Template: Select Block download based on real-time content inspection.
Name: MDCA - Block Restricted Downloads on BYOD.
Session control type: Control file download (with inspection).
Activity Source:
- Device Tag does not equal Intune Compliant.
- App equals Microsoft SharePoint Online.
File Filters:
- Sensitivity Label equals Restricted - Research/HIPAA (Select your specific label).
- Alternatively: Use Data Classification to block files containing TAMU Employee/Student UIN.
Actions:
- Select Block.
- Customize block message: "Download blocked: You are accessing Restricted Research Data from an unmanaged device. Please use a University-issued laptop."
Click Create.

PowerShell: Note: MDCA Session Policies are complex JSON structures not natively supported by the Graph PowerShell SDK. Use the Defender Portal UI for this configuration.

Validation & Success Criteria

Test Managed Device: Log in to SharePoint from a University-managed (Intune Compliant) laptop. Navigate to a "Restricted" file. Download should work normally.
Test Unmanaged Device (BYOD): Log in to SharePoint from a personal computer or incognito window.
- Observation: You should see a URL redirect to *.mcas.ms (indicating the session is proxied).
- Observation: The "Sync" button should be missing (SharePoint Limited Access).
Test Block: On the personal device, attempt to Download a file labeled Restricted - Research/HIPAA.
- Result: You should receive a .txt file instead of the actual document, containing your custom block message.
Test Allow: On the personal device, attempt to download a "General" file.
- Result: Download succeeds. (This proves we are not blocking productivity, only risk).

Security & Compliance Considerations

Copilot Context: Copilot in the browser (Edge sidebar or M365 Chat) respects Conditional Access. If a user is on an unmanaged device and blocked from accessing SharePoint entirely, Copilot cannot summarize those documents for them.
Performance: MDCA proxies the session, which can add milliseconds of latency. This is generally imperceptible for document editing but ensures real-time security.
Emergency Access: Always ensure your "Break-glass" accounts are excluded from the Conditional Access policy to prevent accidental lockout during configuration.

Communication Templates

End-User Announcement:
- Subject: "Security Update: Accessing Files from Personal Devices"
- Body: "To protect university research data, we are updating how files are accessed from personal (non-university) devices. Starting [Date], you will still be able to view and edit files in the web browser on personal devices. However, downloads will be blocked for sensitive files (labeled 'Restricted' or 'Confidential'). To download these files, please use a university-managed device."

Phase 5.5: Information Barriers (Ethical Walls)

Phase Objective

Prevent conflicts of interest by creating "ethical walls" between user segments that should not communicate or share content. This is critical for research universities where competing research groups, athletics compliance, or sensitive HR investigations require strict separation—even when users have the technical permissions to communicate.

Decision Point

Information Barriers are preventive controls, not detective. Before deploying, leadership must decide:

Use Cases: Which groups require isolation? (Competing research labs, Athletics/Compliance, HR Investigations, M&A advisory)
Scope: Bi-directional (neither can contact the other) or one-way (HR can see employee, but not vice versa)?
Impact Tolerance: IB can break existing Teams channels and SharePoint sharing—is the organization prepared for this disruption?

Background & Context

Sensitivity Labels and DLP protect what users can do with data. Information Barriers protect who users can communicate with. In a university environment, this is essential for:

Scenario	Why IB is Needed
Competing Research Labs	Two labs bidding on the same NSF grant should not be able to see each other's proposal drafts in Teams
Athletics Compliance	NCAA rules require separation between boosters and athletes—IB prevents accidental communication
HR Investigations	During an investigation, the investigator should not be able to accidentally message the subject
Technology Transfer	Licensing negotiations require separation between university and potential licensee
Export Control	ITAR research teams may need isolation from foreign national collaborators

Significant User Impact

Information Barriers will disrupt existing collaboration. If two users are currently in the same Teams channel and you apply IB between them, one will be removed. Plan carefully and communicate extensively.

Prerequisites

Requirement	Details	Notes
Phase 1 Complete	Audit logging enabled	IB events are logged
Role	`Compliance Administrator`	Required for IB policy creation
User Attributes	Consistent department/attribute data in Entra ID	IB segments are built on user attributes
Licensing	Microsoft 365 A5	Required for Information Barriers
Scoped Directory Search	Configured in Entra ID	Required for IB to work in Teams

Procedure / Implementation

Step 1 – Define User Segments

Goal: Create logical groups of users based on Entra ID attributes (Department, JobTitle, custom attributes).

Click-Ops (Purview Portal):

Navigate to https://purview.microsoft.com.
Go to Information barriers > Segments.
Click + New segment.
Name: Research-Lab-Alpha.
User group filter: Department equals "Research Lab Alpha".
Click Save.
Repeat for Research-Lab-Beta and any other groups requiring isolation.

PowerShell:

Connect-IPPSSession

# Create segments based on Department attribute
New-OrganizationSegment -Name "Research-Lab-Alpha" -UserGroupFilter "Department -eq 'Research Lab Alpha'"
New-OrganizationSegment -Name "Research-Lab-Beta" -UserGroupFilter "Department -eq 'Research Lab Beta'"
New-OrganizationSegment -Name "Athletics-Boosters" -UserGroupFilter "Department -eq 'Athletics Development'"
New-OrganizationSegment -Name "Athletics-Compliance" -UserGroupFilter "Department -eq 'Athletics Compliance'"

# Verify segments
Get-OrganizationSegment | Format-Table Name, UserGroupFilter

Step 2 – Create Information Barrier Policies

Goal: Define which segments are blocked from communicating with each other.

Click-Ops (Purview Portal):

Navigate to Information barriers > Policies.
Click + New policy.
Name: IB - Block Research Lab Alpha from Beta.
Assigned segment: Research-Lab-Alpha.
Communication and collaboration:
- Select Block.
- Blocked segment: Research-Lab-Beta.
Click Save (policy is inactive until applied).
Create the reciprocal policy: Repeat with segments reversed for bi-directional blocking.

PowerShell:

# Create bi-directional block between competing research labs
New-InformationBarrierPolicy -Name "IB-Alpha-Block-Beta" `
    -AssignedSegment "Research-Lab-Alpha" `
    -SegmentsBlocked "Research-Lab-Beta" `
    -State Inactive

New-InformationBarrierPolicy -Name "IB-Beta-Block-Alpha" `
    -AssignedSegment "Research-Lab-Beta" `
    -SegmentsBlocked "Research-Lab-Alpha" `
    -State Inactive

# Block boosters from compliance staff
New-InformationBarrierPolicy -Name "IB-Boosters-Block-Compliance" `
    -AssignedSegment "Athletics-Boosters" `
    -SegmentsBlocked "Athletics-Compliance" `
    -State Inactive

Step 3 – Apply Information Barrier Policies

Goal: Activate the policies and start enforcement.

Point of No Return

Once applied, IB policies immediately affect Teams, SharePoint, and OneDrive. Users will be removed from channels, lose access to shared sites, and be unable to start new chats with blocked segments.

PowerShell:

# Apply all IB policies (this triggers enforcement)
Start-InformationBarrierPoliciesApplication

# Check application status
Get-InformationBarrierPoliciesApplicationStatus

# Monitor for completion (can take 24-48 hours for large tenants)

Validation & Success Criteria

#	Test	Expected Result
1	User in Lab Alpha tries to start Teams chat with user in Lab Beta	Chat blocked with IB policy message
2	User in Lab Alpha searches for Lab Beta user in Teams	User not discoverable (if directory scoping configured)
3	User in Lab Alpha tries to add Lab Beta user to Team	Add fails with IB policy message
4	User in Compliance reviews existing Team	No boosters visible as members

Security & Compliance Considerations

Copilot Implications: Copilot respects Information Barriers. If Lab Alpha and Lab Beta are blocked, Copilot cannot surface Lab Beta's content to Lab Alpha users, even if file permissions would otherwise allow it.
Audit Trail: All IB enforcement actions are logged in the Unified Audit Log under InformationBarrier operations.
Exceptions: Currently, IB does not support exceptions. If two blocked users need to collaborate, you must modify the segment definitions or create a new segment.

Communication Templates

Template

Subject: Research Team Communication Policy Update

Body: To protect the integrity of competitive research proposals, we have implemented communication barriers between certain research teams.

What this means:

You may notice that some colleagues are no longer visible in Teams search
Existing shared channels with blocked teams will be modified
This is not a reflection of trust—it's a compliance requirement for fair competition

Questions? Contact [Research Compliance Office].

Phase 6: AI Readiness & Copilot Protection (Restricted Content Discovery)

Phase Objective

Protect sensitive data from inadvertent exposure through Microsoft Copilot and enterprise search by implementing Restricted Content Discovery (RCD) and Site Access Restriction (SAR). This is the final phase before monitoring—it ensures AI tools respect data boundaries.

Decision Point

We are defining the "Rules of Engagement" for Microsoft Copilot and Enterprise Search.

Visibility: Should sensitive sites (HR/Legal) appear in global search results? (Recommendation: No, use Restricted Content Discovery).
Access Control: Do we trust Site Owners to manage permissions, or do we enforce a "Hard Lock" at the site level? (Recommendation: Hard Lock via Site Access Restriction for Crown Jewels).
Tenant Strategy: Do we blacklist specific sites (Surgical) or whitelist only approved sites (Nuclear)? (Recommendation: Surgical Blacklisting for a University environment).

Background & Context

The "Copilot Paradox" is simple: Copilot respects user permissions.

If a salary spreadsheet is stored on a SharePoint site with "Everyone" permissions (a common mistake), Copilot will summarize salaries for any student worker who asks.
If a Research Grant folder is "Public" by accident, Copilot uses it to answer questions about proprietary IP.

To "sanitize" the environment for AI without revoking every permission manually, we use two SharePoint Advanced Management (SAM) capabilities included in the A5 license:

Restricted Content Discovery (RCD): "Stealth Mode." The site exists, but it does not appear in Enterprise Search or Copilot references unless the user navigates directly to it.
Site Access Restriction (SAR): "The Bouncer." Even if a file inside the site is shared with "Everyone," the user cannot open it unless they are a member of a specific Security Group defined at the site gate.

Prerequisites

Requirement	Minimum / Version	Notes
Role	`SharePoint Administrator`	Required for Site settings.
Licensing	SharePoint Advanced Management	Included in Microsoft 365 A5. (Also available as an add-on).
PowerShell	`Microsoft.Online.SharePoint.PowerShell`	Latest version required for SAM cmdlets.

Procedure / Implementation

Part 1: Restricted Content Discovery (The "Stealth Mode")

Goal: Hide high-risk sites (HR, Legal, Executive Strategy) from Organization-Wide Search and Copilot. This prevents "accidental discovery" while allowing authorized users to work normally if they have the link.

Step 1 – Identify & Configure RCD Sites

Strategy: Identify the top 50 "Crown Jewel" sites. These usually contain PII, Salaries, or Unpatented IP.

Click-Ops: Currently, RCD is primarily configured via PowerShell. Microsoft is rolling out UI in the SharePoint Admin Center under "Settings", but PowerShell is the reliable method for A5 tenants.

PowerShell (Automation):

Connect-SPOService -Url "https://tamu-admin.sharepoint.com"

# Define your High-Value Assets (HVA)
$SensitiveSites = @(
    "https://tamu.sharepoint.com/sites/HR-Confidential",
    "https://tamu.sharepoint.com/sites/Legal-Counsel",
    "https://tamu.sharepoint.com/sites/Research-StealthProject"
)

foreach ($Site in $SensitiveSites) {
    # Enable Restricted Content Discovery
    # This removes the site from Search Index for general queries
    Set-SPOSite -Identity $Site -RestrictContentOrgWideSearch $true
    
    Write-Host "✅ Site $Site is now hidden from Copilot/Search." -ForegroundColor Yellow
}

Step 2 – Verify RCD Status

Goal: Audit which sites are hidden.

PowerShell:

# Check a specific site
$SiteConfig = Get-SPOSite -Identity "https://tamu.sharepoint.com/sites/HR-Confidential" | Select-Object Url, RestrictContentOrgWideSearch

if ($SiteConfig.RestrictContentOrgWideSearch -eq $true) {
    Write-Host "Site is RESTRICTED." -ForegroundColor Green
} else {
    Write-Host "Site is VISIBLE." -ForegroundColor Red
}

Part 2: Site Access Restriction (The "Hard Lock")

Goal: This is a stronger control than RCD. It overrides file-level sharing.

Scenario: A Site Owner accidentally shares a file in the "Legal" site with "Everyone."
Result: With SAR enabled, "Everyone" still cannot open the file because they are not in the "Legal_Dept_Members" security group.

Step 3 – Configure Site Access Restriction (SAR)

Click-Ops (SharePoint Admin Center): Note: Requires Modern Admin Center.

Navigate to Sites > Active sites.
Select the sensitive site (e.g., "Legal Counsel").
Click Settings (or the Policies tab).
Look for Restricted access control.
Edit:
- Select Restrict access to this site.
- Allowed security groups: Search for and add the Legal_Dept_Members group.
- Critical: Ensure this group contains ALL valid users (including Admins/Auditors) or you will lock them out.
Click Save.

PowerShell (Automation):

# 1. Enable Restricted Access Control on the Site
Set-SPOSite -Identity "https://tamu.sharepoint.com/sites/Legal-Counsel" -RestrictedAccessControl $true

# 2. Add the Allowed Group (The Bouncer List)
# You need the Group GUID or Name
$AllowedGroup = "Legal_Dept_Members" 

Add-SPOSiteRestrictedAccessControlGroup -Identity "https://tamu.sharepoint.com/sites/Legal-Counsel" -GroupName $AllowedGroup

Write-Host "✅ Site Hard-Locked to group: $AllowedGroup" -ForegroundColor Green

Part 3: Tenant-Wide Restricted Search (The "Nuclear Option")

Goal: Invert the model. Nothing is searchable unless explicitly Allowed.

Advisory: This is generally too disruptive for a main University tenant. It is typically reserved for "Secret" enclaves or M&A tenants. We document it here for awareness of A5 capabilities.

Step 4 – (Optional) Enable Tenant Restricted Search

PowerShell:

# DO NOT RUN THIS IN PRODUCTION WITHOUT APPROVAL
# Set-SPOTenant -RestrictedSearchMode $true

# Add Allowed Sites (Whitelist)
# Add-SPOTenantRestrictedSearchAllowedList -SitesList @("https://tamu.sharepoint.com/sites/Public-News")

End-User Experience

Feature	User Context	Experience
RCD (Stealth)	User searches for "Salary" in SharePoint Home.	No Results from the restricted HR site appear.
RCD (Stealth)	User asks Copilot: "Summarize the HR strategy."	Copilot says "I can't find that info" (unless the user has the file open).
RCD (Stealth)	User navigates directly to the HR Site URL.	Site opens, files are visible, local search works.
SAR (Lock)	User receives a link to a file in Legal site.	User clicks link -> "Access Denied" (Even if file permissions say "Everyone").

Copilot Considerations

RCD vs. Copilot: RCD is the primary defense against Copilot "Hallucinating" secrets. By removing the site from the semantic index used for grounding, Copilot is less likely to pull fragments of sensitive data into answers for unrelated questions.
Explicit Context: If a user has an RCD-protected file open in Word, Copilot can read it to summarize it. RCD prevents discovery, not processing.
SAR vs. Copilot: SAR is absolute. If Copilot attempts to reference a file in a SAR-protected site on behalf of a user who is not in the Allowed Group, the access is denied at the API level. Copilot will behave as if the file does not exist.

Validation & Success Criteria

Search Test: Log in as a standard user. Search for a unique keyword that exists only in the RCD-protected site.
- Result: The document should not appear in the results list.
Copilot Test: Ask Copilot M365 Chat: "What is the budget for [Project Name]?" (Where the budget is on an RCD site).
- Result: Copilot should not reference the restricted document.
Access Lock (SAR): Share a file from a SAR-protected site to a colleague who is not in the Allowed Security Group. Have them click the link.
- Result: They receive an Access Denied message, overriding the direct share.

Communication Templates

To Site Owners (HR/Legal):
- Subject: "Enhanced Privacy Applied to [Site Name]"
- Body: "To prepare for Microsoft Copilot and prevent accidental data oversharing, we have enabled Restricted Content Discovery on your site.
- What this means: Your site's content will no longer appear in the university-wide search bar or Copilot results for general users.
- What hasn't changed: You and your team can still access the site directly, use the search bar inside the site, and work on files as normal. This simply prevents 'passive discovery' by unauthorized users."

Part 4: Monitoring & Investigation

This section implements the monitoring, audit, retention, and investigation capabilities. These phases provide visibility into how data is being used and enable legal/compliance response.

Phase 7: Advanced Monitoring & Insider Risk (The "Nerve Center")

Phase Objective

Establish comprehensive monitoring capabilities including Insider Risk Management, Audit Log analysis, and behavioral analytics to detect potential data misuse and enable rapid response.

Decision Point

We are extending governance to monitoring and behavioral analytics.

Insider Risk: Which departing employee behaviors trigger alerts? (File downloads, USB copies, cloud uploads)
Audit Depth: How long do we retain detailed audit logs? (1 year standard, 10 years available as add-on)

Background & Context

Monitoring is the "eyes and ears" of your data protection program. While Labels and DLP prevent accidental data exposure, Insider Risk Management (IRM) detects intentional or negligent data theft.

Key Capabilities:

Insider Risk Management: Correlates user activities over time to detect patterns (e.g., departing employee downloading unusual volumes of data)
Unified Audit Log: Complete record of all M365 activities for investigation and compliance
Adaptive Protection: Automatically tightens DLP policies for users flagged as elevated risk

Prerequisites

Requirement	Minimum / Version	Notes
Role	`Insider Risk Management Admin`	Required for IRM policies
Role	`Audit Reader` or `Compliance Administrator`	Required for audit log access
Licensing	Microsoft 365 A5	Required for IRM and Audit Premium
Dependency	HR connector (optional)	For departure/termination triggers

Procedure / Implementation

This phase implements comprehensive monitoring across four key areas. Each sub-phase builds on the previous to create a complete detection and forensics capability.

Detailed Sub-Phases

The detailed implementation steps for Phase 7 are organized into sub-phases located later in this document (after Phase 9 eDiscovery) to maintain logical flow:

Sub-Phase 7.1: Deep Forensics (Unified Audit Log) - Validate policy enforcement
Sub-Phase 7.2: Insider Risk Management - Departing user detection
Sub-Phase 7.3: Communication Compliance - Campus safety monitoring
Sub-Phase 7.4: Adaptive Protection - Dynamic DLP based on risk score

Scroll down to find these detailed sub-phases, or use the table of contents.

Quick Start: Enable Core Monitoring

Step 1 – Verify Audit Log is Active

Goal: Confirm the Unified Audit Log is recording activities.

Click-Ops:

Navigate to Purview Portal > Audit.
Run a simple search for the last 24 hours.
Verify results appear (file accesses, login events, etc.).

PowerShell (Quick Check):

Connect-IPPSSession

# Check if audit log is enabled
Get-AdminAuditLogConfig | Select-Object UnifiedAuditLogIngestionEnabled

# Quick search
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) -ResultSize 10

Step 2 – Verify IRM Settings

Goal: Ensure Insider Risk Management is properly configured.

Click-Ops:

Navigate to Purview Portal > Insider Risk Management > Settings.
Verify Privacy is set to "Show anonymized versions of usernames" (recommended for universities).
Verify Indicators are enabled for Office 365, SharePoint, Teams, Device.
Verify DLP integration is enabled under Policy Indicators.

Validation & Success Criteria

Audit Active: Perform a file download in SharePoint. Search the Audit Log 30 minutes later for the activity.
- Result: The download event appears with user, file, and timestamp details.
IRM Configured: Navigate to Insider Risk Management > Settings.
- Result: Privacy (Anonymization) is enabled, indicators are active.
Detailed Sub-Phases: Continue to Sub-Phases 7.1-7.4 (located after Phase 9) for complete implementation steps.

Copilot Considerations

Copilot Prompts in Audit: All Copilot interactions are logged in the Unified Audit Log as CopilotInteraction events. You can search for these to understand how users are leveraging AI.
IRM and Copilot: If a user with elevated IRM risk score uses Copilot to summarize sensitive documents, this activity is correlated with their risk profile.

Phase 8: Data Lifecycle, Records & Disposition (The Full Lifecycle)

Decision Point

We are shifting from "Protection" (Security) to "Lifecycle" (Compliance/Legal Liability).

Targeting: Do we treat Faculty and Students the same? (Recommendation: No, use A5 Adaptive Scopes).
Triggers: Do records expire based on creation time (7 years) or a business event (Grant Closure/Graduation)? (Recommendation: Event-Based for Research).
Immutability: Do we need Regulatory Records (WORM) that even IT Admins cannot delete? (Recommendation: Yes, for specific legal/financial instruments).
End of Life: Do items auto-delete, or require human review? (Recommendation: Disposition Review for official records).

Background & Context

Data has a lifespan. Keeping data forever ("Digital Hoarding") creates massive legal liability (eDiscovery costs) and storage bloat. Conversely, deleting data too soon violates State Records laws.

We will implement a Three-Tier Lifecycle Strategy leveraging the full Microsoft 365 A5 stack:

Transient Data (Hygiene): Teams Chats (Auto-delete after 1 year). Targeted dynamically using Adaptive Scopes (e.g., different rules for Students vs. Staff).
General Business Data (Safety Net): Broad retention policies for Exchange/OneDrive to meet the 7-year State Record standard.
High-Value Records (The Vault): Event-Based Retention for Research Grants (starts when the grant closes, not when the file was created), locked with Record labels, and ending with a defensible Disposition Review.

Prerequisites

Requirement	Minimum / Version	Notes
Role	`Compliance Administrator`	Required for Retention Policies.
Role	`Records Management`	Required for File Plan, Events, and Disposition.
Licensing	Microsoft 365 A5	Required for Adaptive Scopes, Event-Based Retention, Regulatory Records, and Disposition.
PowerShell	`ExchangeOnlineManagement`	V3.0.0+.

Procedure / Implementation

Part 1: Smart Targeting (Adaptive Scopes)

Static lists (picking specific users) fail immediately in a university environment with high turnover. Adaptive Scopes automatically update policy membership based on Azure AD attributes.

Step 1 – Create "All Faculty & Staff" Adaptive Scope

Goal: Create a dynamic group that targets all full-time employees (excluding Students and Guests) to apply the 7-year retention policy.

Click-Ops (Purview Portal):

Navigate to Roles & scopes > Adaptive scopes.
Click + Create scope.
Name: Scope - All Faculty and Staff.
Scope type: Users.
Query conditions:
- Attribute: Department Not Equals Student.
- AND
- Attribute: User Type Not Equals Guest.
Click Submit.
- Note: It can take up to 24 hours for the scope to populate.

PowerShell (Automation):

Connect-IPPSSession

# Create the Adaptive Scope logic
# This targets users where Department != 'Student' AND UserType != 'Guest'
New-AdaptiveScope -Name "Scope - All Faculty and Staff" `
    -LocationType User `
    -FilterConditions @{
        "Conditions" = @(
            @{ "Conditions" = @(@{ "Attribute" = "Department"; "Operator" = "NotEquals"; "Value" = "Student" }); "Operator" = "And" },
            @{ "Conditions" = @(@{ "Attribute" = "UserType"; "Operator" = "NotEquals"; "Value" = "Guest" }); "Operator" = "And" }
        );
        "Operator" = "And"
    }

Write-Host "✅ Adaptive Scope Created." -ForegroundColor Green

Part 2: Automated Retention Policies (The Safety Net)

These policies apply broadly to "Containers" (Mailboxes, Sites) to ensure nothing is deleted prematurely by accident, and junk is cleaned up automatically.

Step 2 – Teams Chat Auto-Cleanup (1 Year)

Goal: Ensure informal chats do not become permanent records liable to FOIA.

Click-Ops:

Navigate to Data lifecycle management > Microsoft 365 > Retention policies.
Click + New retention policy.
Name: Retention - Teams Chat Cleanup (1 Year).
Scope:
- Type: Adaptive.
- Scopes: Select Scope - All Faculty and Staff.
Locations: Toggle On for Teams chats and Teams channel messages. (Ensure others are Off).
Retention settings:
- Retain items for: 1 Year.
- Start period: When items were created.
- Action: Delete items automatically.
Click Submit.

PowerShell:

# Note: Linking Adaptive Scopes via PowerShell requires the Scope GUID.
# For simplicity, this script creates a standard Static policy.
# Use UI to link the Adaptive Scope created in Step 1.

New-RetentionCompliancePolicy -Name "Retention - Teams Chat Cleanup (1 Year)" `
    -TeamsChatLocation All -TeamsChannelLocation All -Enabled $true

New-RetentionComplianceRule -Name "Delete Teams Chat > 365 Days" `
    -Policy "Retention - Teams Chat Cleanup (1 Year)" `
    -RetentionDuration 365 -RetentionAction DeleteAndAllowRecovery 

Step 3 – Advanced: Folder-Specific Retention (PowerShell Only)

Goal: Aggressively clean up "Junk Email" and "Deleted Items" after 30 days to save storage and reduce risk, even if the rest of the mailbox is kept for 7 years. This granular control is impossible in the UI.

PowerShell:

# 1. Create the Policy Container
New-RetentionCompliancePolicy -Name "Retention - Aggressive Cleanup (Deleted Items)" `
    -ExchangeLocation All -Enabled $true

# 2. Define the Rule using the -IncludedFolders parameter
# This targets ONLY the 'DeletedItems' and 'JunkEmail' folders
New-RetentionComplianceRule -Name "Purge Deleted Items > 30 Days" `
    -Policy "Retention - Aggressive Cleanup (Deleted Items)" `
    -RetentionDuration 30 `
    -RetentionAction DeleteAndAllowRecovery `
    -IncludedFolders DeletedItems,JunkEmail

Write-Host "✅ Folder-Specific Retention Policy Applied." -ForegroundColor Green

Part 3: Advanced Records & Events (The Vault)

Standard retention counts from "Creation Date". For Research Grants, the clock shouldn't start until the grant closes. This requires Event-Based Retention.

Step 4 – Define the "Grant Closure" Event

Goal: Create the "Trigger" that will eventually start the countdown clock.

Click-Ops (Records Management):

Navigate to Records management > Events > Event types.
Click + Create event type.
Name: Research Grant Closure.
Description: "Triggered when a grant is officially closed in Maestro/Financial System."
Click Create.

Step 5 – Create "Research Record" Label

Goal: A label that locks the file (Record), waits for the event, retains for 7 years, and then triggers Disposition.

Click-Ops:

Records management > File plan > + Create a label.
Name: Record - Research Grant (Event Based).
Retention settings:
- Retain items for: 7 Years.
- Start the retention period based on: When an event occurs.
- Event type: Select Research Grant Closure.
- During retention period: Mark items as a Record. (This locks the file from edits/deletion).
- At end of retention period: Start a disposition review.
Reviewers: Add University_Archivists_Group.
Click Create.
Publish: Publish this label to all Research SharePoint Sites.

Step 6 – Trigger the Event (The "Big Red Button")

Goal: Tell Purview: "Grant NSF-2020 has closed. Start the 7-year clock for all related files."

Click-Ops:

Records management > Events > + Create event.
Event Type: Research Grant Closure.
Name: Closure of Grant NSF-2020.
Asset IDs: Enter the Grant ID (e.g., NSF-2020).
- Critical: This requires that the documents/emails/folders have been tagged with this ID in their metadata (Compliance Asset ID property).
Date: Today's date.
Click Create.
- Result: Purview indexes the tenant. Any file labeled Record - Research Grant AND tagged with Asset ID NSF-2020 will now have its expiration date set to Today + 7 Years.

Part 4: Regulatory Records (WORM)

For highly sensitive legal/financial data (e.g., Bond Issues, Legal Settlements), standard Records are insufficient because Admins can unlock them. Regulatory Records cannot be unlocked, edited, or deleted by anyone (including Global Admins) until the retention period expires.

Step 7 – Enable Regulatory Records (Tenant Level)

Goal: Unlock the "Nuclear Option" for immutability. This is disabled by default to prevent accidental data lockout.

PowerShell:

Connect-IPPSSession

# Enable the feature (One-time action)
Set-OrganizationConfig -EnableRegulatoryRecord $true

Write-Host "✅ Regulatory Records enabled for the tenant." -ForegroundColor Yellow

Click-Ops (Create the Label):

File plan > Create label.
Name: Regulatory - Legal Settlement - Permanent.
Retention settings:
- Check Mark items as a Regulatory Record.
- Warning: Once applied to a file, you cannot remove this label. You cannot delete the file. You cannot edit the metadata. It is WORM (Write Once, Read Many).

Part 5: Disposition (End of Life)

When a record expires, we don't just Shift+Delete. We need a human to verify it can be destroyed and generate a Certificate of Destruction.

Step 8 – Execute the Disposition Review

Goal: The Archivist reviews expired items and approves destruction.

Click-Ops (Reviewer View):

Log in as a user in the University_Archivists_Group.
Navigate to Records management > Disposition.
Select the Pending disposition tab.
Review the list of expired items (e.g., "Grant_123_Final_Report.pdf").
Action: Click the item.
- View content: Open the file to verify it.
- Approve disposal: Mark for permanent deletion.
- Extend retention: Keep for another X years (e.g., "Ongoing Litigation").
Justification: Enter "Audit period passed, approved for destruction."
Click Apply.

Step 9 – Proof of Disposal

Goal: Generate the legal proof that data was destroyed according to policy.

Click-Ops:

Navigate to Records management > Disposition.
Select the Disposed items tab.
Click Export.
Result: A CSV file containing the Filename, Label, Deletion Date, and the Name of the Reviewer who approved it.
- Context: Save this CSV. This is your defense if a judge asks "Why did you delete this evidence?" You answer: "It was destroyed in the normal course of business, per policy, approved by Archivist X on Date Y."

Validation & Success Criteria

Adaptive Scope: Check the scope details in the portal. Click Scope coverage to preview users. Verify Faculty are included and Students are excluded.
Folder Retention: Use the Policy Lookup tool (Data lifecycle > Policy lookup) on a user. Verify two policies exist: one for general items (7 years) and one for "Deleted Items" (30 days).
Record Lock: Apply the Record - Research Grant label to a Word doc. Try to edit the text.
- Result: Word should verify the file is locked/read-only.
Regulatory Lock: Apply the Regulatory label to a test file. Try to remove the label as an Admin.
- Result: Operation failed. (This proves WORM compliance).
Disposition: (For POC) Create a test label with a 1-day retention period. Apply it. Wait 24-48 hours. Verify the file appears in the Disposition tab.

Security & Compliance Considerations

Preservation Lock: To make a Retention Policy legally defensible (and unchangeable even by a rogue admin), you can apply Preservation Lock via PowerShell (Set-RetentionCompliancePolicy -RestrictiveRetention $true). Warning: This is irreversible. Only do this if Legal Mandates it.
Copilot Impact: Once a file is destroyed via Disposition, it is purged from the Semantic Index. Copilot can no longer reason over it. This is a critical "Right to be Forgotten" mechanism.
User Friction: Regulatory Records cause high friction. If a user applies this label by mistake, IT cannot fix it. Only publish Regulatory labels to highly trained staff.

Communication Templates

Faculty Guide:
- Subject: "Closing a Grant? How to Archive your Data"
- Body: "When your research grant officially closes, you no longer need to manually manage the retention. Simply ensure your files are tagged with the 'Research Record' label and the Grant ID. Once the Grant Office marks the project 'Closed' in the system, our retention policy will automatically retain the files for the required 7 years and then alert the University Archivist for review. No action is needed from you."

Phase 9: Response & Investigation (eDiscovery Premium)

Decision Point

We are shifting from "Governance" to "Legal Defense."

Methodology: Do we search everything (Standard) or target specific custodians (Premium)? (Recommendation: Premium Custodian Management).
Processing: Do we export raw PSTs or use Azure to de-duplicate data first? (Recommendation: Review Sets to save 40%+ on outside counsel fees).
Scope: Do we include Teams and Copilot interactions? (Recommendation: Yes, they are discoverable records).

Background & Context

eDiscovery is the process of finding electronic evidence for legal cases or FOIA requests.

Standard eDiscovery (Core): Good for simple searches ("Find emails with keyword 'Project X'"). Exports raw data.
Premium eDiscovery (A5): Essential for complex litigation. It supports Custodian Management (placing a 'person' on hold across all their devices/apps), Legal Hold Notifications, and Advanced Analytics (Email Threading, Near-Duplicate Detection) to drastically reduce the volume of data sent to Legal.

Prerequisites

Requirement	Minimum / Version	Notes
Role	`eDiscovery Manager`	Required to create cases.
Role	`eDiscovery Administrator`	Required to see all cases in the tenant.
Licensing	Microsoft 365 A5	Required for Premium, Custodians, and Review Sets.
PowerShell	`ExchangeOnlineManagement`	V3.0.0+.

Procedure / Implementation

Part 1: Case & Custodian Management

We stop searching "locations" and start managing "people" (Custodians).

Step 1 – Create a Premium Case

Goal: Create a secure container for the investigation.

Click-Ops (Purview Portal):

Navigate to eDiscovery > Premium.
Click + Create a case.
Name: FOIA - Research Grant 2026-X.
Number/Description: Enter the Ticket/Matter ID.
Format: Use the New (Advanced) format if prompted.
Click Create.
Settings: Open the case > Settings > Access & permissions. Add the specific Legal Counsel or Investigator who needs access. Why? Only people explicitly added here can see the data found in this case.

PowerShell (Automation):

Connect-IPPSSession

# Create Premium Case
New-ComplianceCase -Name "FOIA - Research Grant 2026-X" -Description "Investigation into Grant Misuse" -Format "Advanced"

Write-Host "✅ Premium Case Created." -ForegroundColor Green

Step 2 – Add Custodians (The "Human" Hold)

Goal: Place a Legal Hold on everything a specific person owns (Mailbox, OneDrive, Teams Chats) with one click.

Click-Ops:

Open the Case > Data sources tab.
Click Add data source > Add new custodians.
Search: Find "Dr. Smith" (the subject of the FOIA).
Hold Settings:
- Check Place specific data sources on hold.
- Result: This instantly freezes their Exchange, OneDrive, and Teams data. Even if Dr. Smith deletes a file today, it is preserved in the hidden "Recoverable Items" folder.
Review & Finish.

PowerShell: Note: Custodian management is complex in PowerShell. We recommend UI for selecting specific humans, but holds can be scripted.

# Get Case
$Case = Get-ComplianceCase "FOIA - Research Grant 2026-X"

# Create Hold Policy for Dr. Smith's User Principal Name (UPN)
New-CaseHoldPolicy -Name "Hold - Dr. Smith" -Case $Case.Name `
    -ExchangeLocation "dr.smith@tamu.edu" `
    -OneDriveLocation "https://tamu-my.sharepoint.com/personal/dr_smith_tamu_edu" `
    -Enabled $true

Part 2: Collection & Review Sets (The "Filter")

Instead of exporting 50GB of raw data, we collect it into a Review Set to clean it up.

Step 3 – Create a Collection

Goal: Search the Custodians' data for specific keywords.

Click-Ops:

Open Case > Collections > + New collection.
Name: Collection - Grant Keywords.
Custodians: Select "Dr. Smith" (and any others added).
Additional Locations: (Optional) Add shared SharePoint sites.
Conditions (The Query):
- Keywords: "Grant 12345" OR "Project X".
- Date: 2024-01-01 to 2024-12-31.
Save as draft (to estimate) or Submit.
Wait: The system indexes the data.

Step 4 – Commit to Review Set

Goal: "Freeze" the search results and copy them to a secure Azure container for analysis.

Click-Ops:

When the Collection is "Completed", select it.
Click Commit collection.
Select Review Set: Click + Add to new review set. Name it Review Set - Main.
Collection settings:
- Check Collect cloud attachments (modern attachments). Why? If Dr. Smith sent a link to a OneDrive file, this option grabs the actual file at that moment in time, not just the link.
- Check Partially indexed items.
Click Commit.

Part 3: Analytics & Export (The "Savings")

Step 5 – Run Analytics (De-Duplication)

Goal: Remove "noise" (Email threads, duplicates) to reduce reviewer workload.

Click-Ops:

Open Review sets > Review Set - Main.
Click Analytics > Run document & email analytics.
Wait: This uses AI to group near-duplicates.
Filter: Once complete, apply the For Review filter query.
- Result: This hides 40-50% of the volume (e.g., hiding "Re: Re: Re:" emails if the final email contains the full history).

Step 6 – Export

Goal: Generate the final deliverable for Legal Counsel.

Click-Ops:

Select the items to export (or "Select All" in the filtered view).
Click Action > Export.
Options:
- Loose files and PSTs: Best for external counsel.
- Condense conversations: Threading enabled.
Output: A secure download key and Azure Blob link are generated.

Validation & Success Criteria

Hold Verification: Have the test user (Dr. Smith) delete an email related to the case. Run a new Search.
- Result: The deleted email appears in the search results (Preservation Hold Library).
Review Set: Verify that "Cloud Attachments" (linked files) are present in the Review Set as actual readable documents, not just hyperlinks.
Analytics: Check the "Load Sets" report. Verify that "Inclusive Emails" count is lower than "Total Emails" (proving de-duplication worked).

Security & Compliance Considerations

Copilot Discoverability: Copilot prompts and responses are stored in the user's mailbox. A Premium eDiscovery search for keywords will return Copilot interactions if they match the query.
Teams Data: Teams chats are stored in a hidden folder in the mailbox. They are discoverable but appear as "IM" items. Premium eDiscovery reconstructs them into readable "Conversation" threads.
Audit Trail: Every search, preview, and export action performed by the eDiscovery Manager is logged in the Audit Log. This ensures the investigators are also being watched.

Communication Templates

Legal Hold Notification (Automated via Premium):
- Subject: "Legal Hold Notice: Project X Investigation"
- Body: "You have been placed on Legal Hold regarding Project X. Do not delete any documents, emails, or chats related to this matter. Microsoft 365 policies have been applied to your account to preserve data automatically. You may continue to work normally; however, deleted items will be retained in the background for legal review."

Phase 7 Detailed Sub-Phases

The following sub-phases provide detailed implementation steps for Phase 7: Advanced Monitoring & Insider Risk. These are the deep-dive procedures referenced in the Phase 7 overview in Part 4 above.

Phase 7 Sub-Phases: Advanced Monitoring Implementation

The detailed implementation for Phase 7 covers four key areas:

Summary:

Unified Audit Log (Premium): The forensic ledger. Essential for post-breach analysis and validating that your Labels/DLP policies are actually working.
Insider Risk Management (IRM): Detects patterns of behavior (e.g., "User resigned" + "Downloaded 500 files").
Communication Compliance: Detects intent and toxicity (Harassment, Threats, Self-Harm) in Teams/Email.
Adaptive Protection: Dynamically adjusts DLP based on user risk score.

Prerequisites

Requirement	Minimum / Version	Notes
Role	`Audit Manager`	Required for Audit searches.
Role	`Insider Risk Management`	Required for IRM policies.
Role	`Communication Compliance Admin`	Required for Safety policies.
Licensing	Microsoft 365 A5	Required for Audit (Premium), IRM, and Comm Compliance.

Sub-Phase 7.1: Deep Forensics (Unified Audit Log)

The Audit Log is not just for finding hackers; it is how you prove your implementation is working. We will perform targeted searches to validate the policies we created in Phases 3, 4, and 6.

Part 1: Validating Policy Enforcement

Step 1 – Validate Sensitivity Labeling (Did it stick?)

Goal: Confirm that users (or Auto-Labeling policies) are actually applying the "Restricted" label to documents.

Click-Ops:

Navigate to Audit > Search.
Date and time: Last 7 days.
Activities: Search for SensitivityLabelApplied and SensitivityLabelUpdated.
Search.
Analysis: Look at the "Item" column. Are they Research Grant files? If yes, the policy is working.

PowerShell (Targeted Search):

Connect-IPPSSession

# Find files labeled "Restricted" in the last 7 days
$StartDate = (Get-Date).AddDays(-7)
$EndDate = (Get-Date)
$LabelGUID = "Your-Restricted-Label-GUID" # Get via Get-Label

$Logs = Search-UnifiedAuditLog -StartDate $StartDate -EndDate $EndDate `
    -Operations SensitivityLabelApplied `
    -ResultSize 100

# Filter for specific label GUID in the AuditData blob
$Logs | Where-Object {$_.AuditData -like "*$LabelGUID*"} | Select-Object CreationDate, UserIds, Operations, Item

Step 2 – Validate DLP Blocks (The "False Positive" Check)

Goal: Ensure our "Warn" policy is triggering, and identify if we are blocking legitimate research.

Click-Ops:

Activities: Search for DLP rule matched.
Search.
Analysis: Click on a result to see the AuditData. It will tell you which sensitive type triggered it (e.g., "TAMU UIN") and who the user was.

PowerShell (The "Morning Report"):

# Get all DLP matches for the last 24 hours
$DLPLogs = Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) `
    -RecordType ComplianceDLP `
    -ResultSize 500

# Display clean table
$DLPLogs | Select-Object CreationDate, UserIds, Operations, @{Name="Policy";Expression={($_.AuditData | ConvertFrom-Json).PolicyDetails.PolicyName}} | Format-Table -AutoSize

Step 3 – Validate Conditional Access & MDCA (The "Block")

Goal: Confirm that the "Block Downloads on Unmanaged Devices" policy is actually stopping downloads.

Click-Ops (Defender Portal):

Navigate to security.microsoft.com > Cloud Apps > Activity log.
Filter:
- Activity type: Download.
- Action: Block.
Analysis: You should see failed download attempts from non-compliant devices. This proves the "Zero Trust Access" phase is active.

Sub-Phase 7.2: Insider Risk Management (The "Exit Strategy")

Status: 🕵️ INTERNAL THREAT DETECTION Goal: Detect Intellectual Property (IP) theft and Research Espionage using Behavioral Analytics.

DLP detects events. IRM detects patterns. If a professor resigns and immediately downloads 500 files to a USB drive, DLP might miss it (if the files aren't labeled), but IRM will flag the anomaly.

Part 1: Configuration

Step 4 – Configure Indicators & Privacy

Goal: Turn on the sensors and protect user privacy (Anonymization).

Click-Ops:

Insider Risk Management > Settings.
Privacy: Verify "Show anonymized versions of usernames" is On.
- Why: In a university, investigating a tenured professor without cause is a political minefield. Anonymization allows you to see "User_123 stole data" before you unmask them as "Dr. Smith".
Indicators: Select All (Office 365, SharePoint, Teams, Device, Physical Access).
Policy Indicators: Check Turn on DLP integration.
- Why: This allows a low-severity DLP alert (e.g., "User sent 1 sensitive file") to contribute to a High-Severity Risk Score if combined with other actions.

Part 2: The "Departing Researcher" Policy

Step 5 – Create "Data Theft by Departing Users" Policy

Goal: Automatically monitor users who have submitted a resignation.

Click-Ops:

Policies > Create Policy.
Template: Data theft by departing users.
Prerequisites: Configure the Microsoft 365 HR Connector.
- Context: This requires a CSV upload or API connection to Workday/PeopleSoft. It tells Purview who is leaving and when.
Triggers: User is added to HR list (Resignation Date).
Thresholds:
- Download content from SharePoint: > 50 files. (Tune this baseline).
- Copy to USB: Any activity. (Strict for departing staff).
- Rename files: > 20 files. (Obfuscation tactic).
Reviewers: Assign to CISO or Legal Counsel.

PowerShell (HR Connector Upload): Note: You cannot create the policy via PS, but you CAN update the HR data triggers.

# Example of how the HR Connector script looks (requires M365HRConnector module)
# Import-Module Microsoft.Graph.Identity.Governance
# Update-MgHRConnector -Id <ConnectorID> -CsvPath "C:\HR_Data\DepartingFaculty.csv"

Part 3: Investigating an Alert

Step 6 – The Investigation Workflow

Goal: Walk through what happens when an alert fires.

Alert Dashboard: Admin sees "High Severity Alert: User_Anon_555".
User Activity: The timeline shows:
- Monday: User submitted resignation (HR Trigger).
- Tuesday: User downloaded 4GB from "Research Grants" SharePoint.
- Wednesday: User copied 4GB to "WD_MyPassport" (USB).
Action: Admin clicks Confirm Alert.
Unmask: Admin provides justification ("Probable data theft") to reveal the name: "Dr. Jane Doe".
Escalate: Admin creates a Case and adds Legal Counsel.

Sub-Phase 7.3: Communication Compliance (Campus Safety)

Status: 💬 SAFETY & CONDUCT Goal: Title IX Compliance, Student Safety, and Code of Conduct enforcement.

Universities have a "Duty of Care." Communication Compliance scans Teams, Outlook, and Yammer for specific language types (Threats, Harassment, Self-Harm) to intervene before a physical incident occurs.

Step 7 – Create "Student Safety" Policy

Goal: Detect threats or self-harm in student chats.

Click-Ops:

Communication Compliance > Policies > Create.
Template: Detect Harassment or Threat.
Name: Safety - Student Conduct Monitoring.
Supervised Users:
- Select "All Students" (Dynamic Distribution Group based on Dept attribute).
- Note: Separate this from Faculty monitoring (different legal standards).
Reviewers: Add Title IX_Investigators_Group (Student Conduct Office).
- Critical: IT should not be the reviewer.
Locations: Teams Chat (Primary), Exchange Email.
Conditions:
- Content matches: Threat, Harassment, Profanity (Microsoft Pre-trained Classifiers).
- New: Add Self-Harm classifier (A5 Preview).
Action: Flag message. Notify Reviewer.

Step 8 – Reviewer Workflow

Goal: How Title IX handles a flag.

Notification: Reviewer gets an email: "New item for review."
Dashboard: Reviewer logs into compliance.microsoft.com.
Review: They see the message text and the context (previous/next messages) to determine intent.
Action:
- Resolve: (False positive).
- Notify User: (Warning).
- Escalate: (Send to Dean of Students / Campus Police).
- Remove Message: (Wipes it from Teams immediately).

Validation & Success Criteria

Audit Search: Run a search for FileDownloaded events by a specific test user. Verify results appear within 24 hours.
Insider Risk Simulation: Add a test user to the HR Connector CSV as "Resigned". Log in as that user and download 50 files from SharePoint.
- Result: An alert generated in the IRM dashboard within 24 hours.
Safety Trigger: Send a test message with "Threatening language" between two test student accounts in Teams.
- Result: The message appears in the Communication Compliance "Pending" tab for the Title IX Reviewer.

Security & Compliance Considerations

Privacy (Anonymization): Ensure Anonymization is enabled in IRM Settings. This is often a hard requirement for Faculty Senates and GDPR compliance.
Copilot Oversight: Communication Compliance does monitor Copilot prompts. If a student types a harassing prompt into Copilot, it can be flagged just like a Teams message.
Reviewer Stress: Reviewing "Toxic" content is mentally taxing. Ensure the Title IX office has rotation policies for reviewers to prevent burnout.

Sub-Phase 7.4: Adaptive Protection (Dynamic DLP)

Status: 🔄 INTELLIGENT RESPONSE Goal: Dynamically adjust DLP policy strictness based on a user's Insider Risk score—users exhibiting risky behavior get stricter controls automatically.

Why Adaptive Protection Matters

Traditional DLP is static: the same rules apply to everyone. But a user who just submitted their resignation and is downloading unusual volumes of data is a higher risk than a normal user. Adaptive Protection connects IRM signals to DLP actions, creating a dynamic, risk-based security posture.

How It Works

IRM Risk Level	DLP Response	Example Action
Elevated	Block + Alert	User cannot email sensitive files externally; security alerted immediately
Minor	Warn + Override with Justification	User sees warning, must provide business reason to proceed
Minimal	Standard Policy Tips	Normal DLP experience

Step 9 – Enable Adaptive Protection

Goal: Connect IRM risk levels to DLP policy conditions.

Click-Ops (Purview Portal):

Navigate to Insider Risk Management > Adaptive Protection.
Click Get started (if first time) or Settings.
Risk levels for Adaptive Protection:
- Elevated risk level: Users with confirmed IRM alerts or multiple high-severity indicators.
- Minor risk level: Users with unconfirmed alerts or moderate indicators.
- Minimal risk level: All other users (baseline).
Turn on Adaptive Protection: Toggle to On.
DLP Integration: The system will create conditions you can use in DLP policies.

Step 10 – Create Adaptive DLP Policy

Goal: Create a DLP policy that uses IRM risk level as a condition.

Click-Ops (Purview Portal):

Navigate to Data loss prevention > Policies > Create policy.
Template: Custom policy.
Name: DLP - Adaptive Protection for Research Data.
Locations: Exchange, SharePoint, OneDrive, Teams.
Conditions - First Rule (Elevated Risk):
- Content contains: Restricted - Research/HIPAA label.
- AND User's insider risk level is: Elevated.
- Action: Block + Notify security team.
Conditions - Second Rule (Minor Risk):
- Content contains: Restricted - Research/HIPAA label.
- AND User's insider risk level is: Minor.
- Action: Warn + Require business justification.
Conditions - Third Rule (Baseline):
- Content contains: Restricted - Research/HIPAA label.
- Action: Notify user with policy tip.
Save and enable in Test mode first.

Validation

#	Test	Expected Result
1	User with no IRM alerts tries to email restricted file	Standard policy tip
2	User with "Minor" risk level tries same action	Warning + justification required
3	User with "Elevated" risk level tries same action	Blocked + security notified

Privacy Consideration

Adaptive Protection uses IRM data to modify user experience. Ensure your IRM privacy settings (anonymization) are configured per Sub-Phase 7.2 before enabling Adaptive Protection.

Part 5: Prevention & External Controls (Later Phase)

Implementation Warning - Coordinate with Security Team

The phases in this section should be implemented AFTER Parts 1-4 are complete. These are significant undertakings that may overlap with existing tools:

Proofpoint DLP - May already provide email DLP
Elastic/SIEM - May already provide monitoring
Third-party CASB - May overlap with MDCA
Power Platform governance - May require coordination with citizen developer programs

Coordinate with your security architecture team before implementing to avoid conflicts and duplication.

Phase 10: Data Loss Prevention (DLP)

Phase Objective

Implement DLP policies to detect and prevent data exfiltration across email, SharePoint, OneDrive, Teams, endpoints, and browsers. This phase extends protection beyond labeling to active blocking of risky actions.

Decision Point

We are implementing the "Warn with Override" philosophy defined in Phase 0.

SSN/Credit Cards: Strict Block.
Research/FERPA Data: Warn w/ Override (Educational).

Background & Context

With Microsoft 365 A5, we extend DLP beyond just Email. We use Endpoint DLP to stop users from copying research data to USB drives or uploading to personal clouds (Google Drive/Dropbox) via the browser.

Why DLP Comes Later:

DLP requires mature SITs and labels (Phases 2-3) to be effective
False positives in DLP directly impact user productivity
May overlap with existing Proofpoint or third-party DLP
Requires significant testing and tuning

Prerequisites

Requirement	Minimum / Version	Notes
Role	`Compliance Administrator`	Required
Licensing	Microsoft 365 A5	Required for Endpoint DLP
Dependency	SITs (Phase 2) and Labels (Phase 4) must be mature
Coordination	Security team / existing DLP owners	Avoid conflicts

Phase 11: Power Platform DLP

Phase Objective

Extend governance to the "Citizen Developer" stack by implementing Power Platform DLP policies that prevent unauthorized data movement through Power Automate flows and Power Apps.

Background & Context

Researchers and staff increasingly use Power Automate to streamline workflows and Power BI to visualize grant data. Without governance, these tools become massive exfiltration vectors.

Power Platform DLP: Acts as a firewall between connectors. We define that "SharePoint" (Business) cannot talk to "Dropbox" (Non-Business) in the same flow.
Power BI Protection: By integrating Purview labels, we ensure that if a user exports a chart of Student UINs to Excel, the resulting file is automatically encrypted with the "Restricted" label.

Prerequisites

Requirement	Minimum / Version	Notes
Role	`Power Platform Administrator`	Required for Power Platform DLP
Role	`Power BI Administrator`	Required for Power BI tenant settings
Licensing	Microsoft 365 A5	Required for advanced DLP and Label integration
PowerShell	`Microsoft.PowerApps.Administration.PowerShell`	Required for DLP automation

Phase 12: Communication Compliance

Phase Objective

Implement communication monitoring for policy violations, harassment, threats, and regulatory compliance across email, Teams, and Viva Engage.

Background & Context

Use Cases:

Title IX compliance monitoring
Student safety and threat detection
Research collaboration compliance (export control discussions)
HR policy violation detection

Prerequisites

Requirement	Minimum / Version	Notes
Role	`Communication Compliance Admin`	Required
Licensing	Microsoft 365 A5	Required
Legal Review	Privacy implications	Consult with legal before enabling

Part 6: Extensions & Advanced

This section covers extending Purview beyond core M365 to on-premises storage, Azure Purview integration, and PAYG enhancements.

Phase 13: Extending Reach - On-Premises & Other Storage Solutions

Phase Objective

Extend Purview's data protection capabilities beyond Microsoft 365 to on-premises file servers and NAS systems using the AIP Scanner. This phase bridges the gap between cloud governance and legacy infrastructure, ensuring consistent classification and labeling across your entire data estate.

Decision Point

Before extending Purview to on-premises storage, leadership must decide:

Scope: Which file shares and NAS systems contain sensitive data worth scanning? (Start with HR, Finance, Legal, Research data repositories)
Mode: Will the scanner operate in Discovery (audit only) or Enforce (apply labels)? (Recommend: Discovery first, then Enforce after validation)
Label Strategy: Should on-premises files receive the same labels as cloud content, or a separate "On-Prem" sub-label? (Recommend: Same labels for consistent policy enforcement)
Infrastructure Investment: Is the organization prepared to provision and maintain Windows Server infrastructure for the AIP Scanner? (Required for this phase)

Background & Context

Goal

Explain and architecturally plan how Microsoft Purview capabilities (discovery, classification, labeling, potentially DLP actions via Endpoint/Cloud interactions) can be extended to unstructured data stored outside core M365 services, such as:

On-premises file servers
Network-Attached Storage (NAS)
Other enterprise file storage platforms accessible via SMB/NFS

Zero Trust Alignment

Extends explicit verification (classification, labeling) and policy enforcement principles to data regardless of its location ("Protect data wherever it lives"). Ensures consistent governance controls are applied across the hybrid environment.

Implications

Infrastructure Requirements

This phase requires deploying the Microsoft Purview Information Protection (AIP) Scanner on-premises, which involves:

Windows Server infrastructure setup
Service account management
Network connectivity (to shares and cloud)
Careful planning of scan jobs and policies

POC Scope

This phase in the POC is architectural planning, not implementation. Full real-time DLP enforcement like in M365 is not native to the scanner itself, but labels applied by the scanner enable downstream enforcement via Endpoint DLP or cloud DLP when files move.

Required Roles:

Information Protection Admin or Compliance Data Administrator for Purview configuration
Local server administrator permissions
Active Directory service account permissions

Prerequisites

Prerequisite	Description	Validation
Phase 4 Complete	Sensitivity Labels configured and published	Labels visible in Office apps
Phase 10 Complete	DLP policies configured	DLP alerts generating
Windows Server	2016 or later available for scanner	Server provisioned
Network Access	Connectivity to target file shares	SMB/NFS ports open
Service Account	Domain account with appropriate permissions	Account created in AD
Internet Connectivity	Scanner server can reach Azure endpoints	Firewall rules configured

Procedure / Implementation

Step 1: Identify Target On-Premises/External Repositories

Inventory key non-M365 locations holding sensitive unstructured data:

Departmental file shares on Windows Servers
Central NAS storage
Specific cloud file services accessed via SMB

POC Input

Define a representative target for planning purposes:

\\FileServer01\FinanceDocs
\\EnterpriseNAS\ProjectData

Step 2: Understand the AIP Scanner Architecture

The Microsoft Purview Information Protection (AIP) Scanner is the primary mechanism for extending Purview classification and labeling to on-premises file shares (SMB/NFS) and on-premises SharePoint Server sites.

Architecture Components:

Component	Description
Scanner Service	Windows service installed on a server (physical/VM) within the corporate network
Network Access	Requires network line-of-sight to target file shares
Cloud Connectivity	Requires internet connectivity to communicate with Purview service in Azure
Service Account	Dedicated service account for authentication and file access

Why This Matters

The scanner bridges the gap between on-premises unstructured data and cloud-based Purview governance policies.

Reference: Learn about the Microsoft Purview Information Protection scanner

Step 3: Plan Scanner Deployment

Infrastructure Requirements

Requirement	Specification
Operating System	Windows Server 2016 or later (recommended)
Sizing	CPU/RAM based on data volume and desired scan speed
Scaling	Consider multiple scanner nodes in a cluster for large environments

Service Account Configuration

Create a dedicated domain service account with the following permissions:

Permission Type	Requirement	Notes
Share Permissions	Read (minimum for discovery)	Read/Write/Modify if applying labels/protection
Purview Roles	`Compliance Data Admin` or `Information Protection Admin`	Via Entra ID for registration/reporting
Local Server	Administrator	On scanner server(s)
Service Rights	"Log on as a service"	Local policy setting

Network Requirements

Required Connectivity:
├── Scanner Server → Target File Shares (SMB: 445, NFS: 2049)
├── Scanner Server → Purview Service Endpoints (HTTPS: 443)
│   ├── *.protection.outlook.com
│   ├── *.aadrm.com
│   └── [Additional Microsoft endpoints per documentation]
└── Scanner Server → Azure AD (HTTPS: 443)

Firewall Configuration

Ensure firewall rules allow communication between scanner server(s) and Purview service endpoints. Consult Microsoft's endpoint documentation for the complete list.

Step 4: Conceptual Scanner Configuration

4.1 Register Scanner Cluster

In Purview portal, navigate to Information Protection > AIP Scanner to create a scanner cluster profile.

4.2 Authenticate Scanner Node

On the scanner server, use PowerShell to connect the node to the tenant:

# Authenticate using App Registration (recommended)
Set-AIPAuthentication `
    -AppId "<AppReg_ClientID>" `
    -AppSecret "<AppReg_ClientSecret>" `
    -TenantId "<TenantID>"

# Or use Certificate authentication for enhanced security
Set-AIPAuthentication `
    -AppId "<AppReg_ClientID>" `
    -CertificateThumbprint "<CertThumbprint>" `
    -TenantId "<TenantID>"

4.3 Define Content Scan Jobs

Configure scan jobs in Purview portal or via PowerShell:

Setting	Options	Description
Repositories	UNC paths (e.g., `\\Server\Share\*`)	Target locations to scan
Scanner Mode	`Discover` or `Enforce`	Audit only vs. apply actions
Auto-labeling Rules	SIT-based conditions	e.g., "If > 5 SSNs, apply 'Confidential'"
Default Label	Label name	Applied to all scanned content if no rule matches
File Types	Extensions to include/exclude	Scope of scan
Schedule	Continuous or Scheduled	Scan timing

Step 5: Understand Integration of Scan Results

After scans complete and report, results integrate with Purview:

Purview Component	Integration
Content Explorer	Discovered SITs appear under "On-premises repositories" filter
Activity Explorer	Label application actions logged under scanner service account
Data Classification Overview	On-prem findings contribute to overall sensitivity dashboards

Unified Visibility

This integration provides unified visibility across cloud and on-premises unstructured data within the Purview portal.

Step 6: Understand Policy Enforcement on Labeled On-Premises Data

Labels applied by the scanner enable downstream protection:

Persistent Protection

If a label with encryption is applied on-premises, the file remains encrypted and requires authorized credentials to open, even if moved off the share.

Cloud DLP Awareness

If a file labeled Confidential on-premises is attached to an Outlook email, Exchange Online DLP policies will recognize the label and enforce relevant rules (e.g., block external sending).

Endpoint DLP Awareness

Defender for Endpoint can read sensitivity labels on files. An Endpoint DLP policy can block copying a file labeled Highly Confidential from the network share to a USB, based on the label applied by the scanner.

Key Value Proposition

The primary value is consistent classification and enabling other Purview/Defender components to enforce policy based on that classification when the data moves or is accessed.

Step 7: Consider Alternative/Complementary Approaches

Data Connectors

For some platforms, Purview offers connectors to ingest third-party data (e.g., Box, Slack) into M365 for retention/eDiscovery. Less common for direct file share replacement but part of the ecosystem.

Azure Purview Data Map

The broader Azure Purview service excels at scanning structured data (SQL DBs, data lakes) and on-premises sources beyond files for cataloging and lineage. While the AIP scanner is key for labeling/protecting on-premises files for M365 compliance integration, the Data Map offers wider data governance visibility.

Convergence

These capabilities are converging but often serve distinct primary purposes today. See Phase 13 for Data Map details.

PowerShell Reference

# =============================================================================
# AIP Scanner PowerShell Commands
# Run on Scanner Server after installing AIP client/scanner
# =============================================================================

# --- Prerequisites ---
# Install AIPService module (included with AIP client)
# Connect-AipService

# --- Authentication ---
# Authenticate the scanner service account to the tenant
Set-AIPAuthentication `
    -AppId "<AppReg_ClientID>" `
    -AppSecret "<AppReg_ClientSecret>" `
    -TenantId "<TenantID>"

# --- Scan Operations ---
# Start a manual scan cycle
Start-AIPScan -ScanType Full      # Complete rescan of all repositories
Start-AIPScan -ScanType Incremental  # Scan only new/modified files

# Get current scanner status
Get-AIPScannerStatus

# --- Configuration ---
# Configure scan job (complex - often easier via portal)
# Example snippet (conceptual - requires full config object):
# Set-AIPScannerConfiguration `
#     -Schedule Continuous `
#     -Repository '\\FileServer01\FinanceDocs' `
#     -Enforce On

# --- Service Management ---
# Stop scanner service
Stop-AipScanner

# Start scanner service  
Start-AipScanner

# Get scanner configuration
Get-AIPScannerConfiguration

End-User Experience

Aspect	Experience
Scanner Operation	Transparent to users accessing file shares. Users don't see the scanner running.
Labeled Files	If the scanner applies labels, users opening those files in compatible Office apps will see the applied label (banner, status bar) and be subject to its protections (encryption, markings).
Consistency	The experience is identical to files labeled in the cloud.

Copilot Considerations

Discoverability Limitation

Copilot for M365 does not natively connect to or index on-premises file shares scanned only by the AIP scanner.

Requirements for Copilot Indexing

For Copilot to use on-premises file content, that content generally needs to be either:

Method	Description
Synced/Migrated	Moved or synced to SharePoint Online or OneDrive where Microsoft Search can index it
Indexed via Connectors	Microsoft Search configured with connectors to crawl and index the on-premises repositories

Labels Still Matter

Protection Persists

If on-premises data is made searchable/accessible to Copilot via methods above, the sensitivity labels applied by the AIP scanner remain critical. Copilot will respect the encryption and permissions defined by those labels, preventing access to sensitive on-premises content for unauthorized users even if it's indexed.

Validation & Success Criteria

#	Validation Item	Success Criteria
1	Architecture Explained	Can clearly articulate the scanner's role, components, and data flow
2	Integration Points Explained	Can explain how scanner results appear in Content/Activity Explorer and how labels enable downstream DLP/Endpoint policy enforcement
3	Configuration Steps Outlined	Detailed documentation of necessary steps (Server, Service Account, Purview Config, Scan Jobs) even if not performed
4	Copilot Interaction Clarified	Can explain that the scanner itself doesn't make data Copilot-ready, but labels applied do provide protection if the data becomes indexed/accessible later

Communication Templates

Internal Communication - IT/Infrastructure/Storage Admins

Template

Subject: Planning Deployment of Microsoft Purview Information Protection Scanner for On-Premises Shares

Body:

As part of extending our data protection strategy, we plan to deploy the AIP Scanner to discover and potentially apply sensitivity labels to data on key file shares like [\\Server\Share].

This requires:

A dedicated Windows Server VM
A service account with read/write permissions to the shares
Network connectivity to Purview cloud services

We need your assistance in:

Provisioning VM
Granting permissions
Configuring firewall rules

The goal is to achieve consistent classification and protection across cloud and on-premises data. Initial scans will likely be in discovery mode.

Please contact [Name] to schedule a planning session.

Phase 14: Integrating with Azure Purview Data Map (Data Governance)

Phase Objective

Achieve unified data governance visibility across your entire enterprise data estate—including SQL databases, data lakes, multi-cloud sources, and SaaS applications—by integrating with Azure Purview Data Map. This phase extends Zero Trust data principles beyond M365 to structured and unstructured data wherever it resides.

Decision Point

Azure Purview Data Map is a separate Azure service with its own pricing model. Leadership must decide:

Strategic Fit: Does the organization need unified data governance across SQL databases, data lakes, and multi-cloud sources beyond M365? (If yes, proceed with planning)
Budget: Is there budget for Azure consumption-based pricing for scanning and cataloging? (Required for implementation)
Timing: Should Data Map implementation follow M365 Purview maturity, or run in parallel? (Recommend: After M365 Purview is stable—typically 6-12 months post-implementation)
Ownership: Which team owns Data Map—IT Security, Data Engineering, or a dedicated Data Governance team? (Varies by organization)

Background & Context

Goal

Understand how the Microsoft Purview compliance features (labels, DLP, retention configured in M365) relate to and can integrate with the broader Azure Purview Data Map service for unified data governance across the entire enterprise data estate.

Zero Trust Alignment

Extends the principles of data discovery, classification, and protection beyond M365 to other data silos, providing a unified view necessary for comprehensive Zero Trust data governance.

Implications

Separate Service & Pricing

Azure Purview Data Map is a separate Azure service with its own Pay-As-You-Go Azure subscription-based pricing model based on:

Scanning frequency and volume
Data map population
Resource usage

It requires configuration within the Azure portal and setting up scanning for diverse data sources.

Supported Data Sources Include:

SQL databases (Azure SQL, SQL Server, etc.)
Azure Synapse Analytics
Azure Blob Storage / Data Lake
AWS S3
On-premises servers
And many more...

Continuing Phase 13 and Remaining Phases

Here's the continuation from where I cut off:

## Key Capabilities

### 1. Data Discovery & Cataloging

Scans and maps data assets across diverse environments:

| Environment | Examples |
|:------------|:---------|
| On-premises | SQL Server, Oracle, File shares |
| Azure | Azure SQL, Synapse, Blob Storage, Data Lake |
| Multi-cloud | AWS S3, AWS RDS, GCP BigQuery |
| SaaS | Various supported applications |

**Extracts:**
- Metadata (schema, columns, data types)
- Data lineage (how data flows between systems)
- Classifications (using SITs)

### 2. Data Classification

Uses the **same** built-in and custom SITs defined in the M365 Purview portal to automatically classify data found in scanned sources.

```mermaid
flowchart LR
    A[M365 Purview Portal] -->|SIT Definitions| B[Azure Purview Data Map]
    B -->|Scans| C[SQL Database]
    B -->|Scans| D[Data Lake]
    B -->|Scans| E[Blob Storage]
    C -->|Classification Tags| F[Data Catalog]
    D -->|Classification Tags| F
    E -->|Classification Tags| F

Example: Tagging SQL columns containing PII (SSN, email addresses) automatically during scan.

3. Sensitivity Label Integration (Evolving)

Allows applying M365 Sensitivity Labels directly to schematized data assets:

Asset Type	Label Support
SQL columns	✅ Supported
Azure Data Factory assets	✅ Supported
Power BI datasets	✅ Supported
File-based assets	✅ Via AIP Scanner integration

Evolving Capability

This extends M365 labels beyond files/emails to structured data sources. Enforcement mechanisms vary by source type and continue to evolve.

4. Data Catalog

Provides a searchable business glossary and catalog for data consumers and stewards:

Business Glossary: Define business terms and link them to technical assets
Asset Discovery: Search and browse data assets across the enterprise
Data Stewardship: Assign owners and experts to data assets
Collaboration: Enable data consumers to request access and provide feedback

5. Data Estate Insights

Offers dashboards visualizing:

Insight	Description
Classification Distribution	Where sensitive data types exist across sources
Glossary Coverage	How well business terms map to technical assets
Asset Inventory	Types and counts of data assets by source
Scan Health	Status and results of scanning operations

6. Data Lineage

Automatically visualizes how data flows and transforms between different systems:

Value: Understand data dependencies, impact analysis for changes, and regulatory compliance (proving where data originated).

Integration with M365 Purview Compliance

Unified Classifiers

Feature	Benefit
Same SITs	Consistent detection logic across unstructured (M365) and structured (Azure Purview) data
Same Trainable Classifiers	Reuse ML-based classifiers across platforms
Custom SITs	Define once, use everywhere

Unified Labels (Vision)

Strategic Direction

The vision is for Sensitivity Labels defined in M365 Purview to be seamlessly applicable and recognized across Azure Purview Data Map assets, providing a single classification taxonomy for the entire enterprise.

Current State:

Labels can be applied to many asset types
Full end-to-end enforcement parity is still evolving across all source types
Some integrations require additional configuration

Compliance Manager Integration

Insights from Azure Purview scans can inform Compliance Manager:

Integration Point	Benefit
PII Discovery	Identifying PII in databases informs data protection controls
Evidence Collection	Scan results can serve as evidence for compliance assessments
Risk Assessment	Understanding data distribution helps assess compliance risk

Considerations for Enterprise Rollout

Licensing & Cost

Cost Factor	Description
Azure Subscription	Required - separate from M365 licensing
Scanning	Pay per scan based on data volume
Data Map Size	Costs scale with number of assets cataloged
Runtime	Compute costs for scanning operations

Budget Planning

Implement cost controls and monitoring in Azure to manage expenses. Start with limited scope and expand gradually.

Scope & Phasing

Recommended Approach

Implementing Azure Purview Data Map is often a separate, significant project usually undertaken after M365 Purview compliance controls are mature.

Suggested Phasing:

Phase	Scope
Phase 1	Scan 2-3 critical SQL databases
Phase 2	Add data lakes and blob storage
Phase 3	Expand to multi-cloud sources
Phase 4	Full enterprise data estate

Skills Requirements

Skill Area	Required For
Azure Administration	Service provisioning, networking, security
Data Governance	Glossary management, stewardship processes
Database Administration	Understanding source systems for scanning
Security/Compliance	Classification policies, label management

Why This Matters

For enterprises with significant data assets outside M365, the Azure Purview Data Map provides the necessary unified visibility and governance capabilities to extend Zero Trust data principles across the entire data landscape. It complements the M365-focused features detailed in this runbook.

Phase 15: Specific Regulatory Focus - FERPA Protection

Phase Objective

Apply your Purview implementation specifically to FERPA compliance by leveraging sensitivity labels, DLP, retention, and eDiscovery to protect student education records. This phase demonstrates how the general Purview toolkit addresses the specific requirements of the Family Educational Rights and Privacy Act.

Decision Point

FERPA compliance requires applying previously configured Purview features with a student-data focus. Leadership must decide:

Scope Definition: How broadly will you define "education records"? (FERPA's definition is broad—work with Registrar and Legal to create a comprehensive inventory)
Label Strategy: Will FERPA data receive a dedicated label (e.g., Highly Confidential - FERPA Protected) or use existing labels with FERPA-specific policies? (Recommend: Dedicated label for clear identification)
Access Model: Who constitutes "school officials with legitimate educational interest"? (Define specific groups, not broad categories like "All Faculty")
Consent Workflow: How will you handle third-party disclosure requests requiring student consent? (Document process before implementation)

Background & Context

Goal

Demonstrate how the previously configured Microsoft Purview features (Sensitivity Labels, DLP, Retention, Audit, eDiscovery, potentially Restricted Search) can be specifically leveraged to help meet the requirements of the Family Educational Rights and Privacy Act (FERPA) for protecting "education records."

Zero Trust Alignment

Applies Zero Trust principles (verify explicitly, least privilege, assume breach) specifically to the context of sensitive student data, ensuring:

Appropriate access controls
Prevention of unauthorized disclosure
Response capabilities aligned with FERPA rights

Implications

Application Phase

This section applies the general Purview toolkit to the specific needs of educational institutions or entities handling student data. No new features are configured, but existing ones are viewed through the FERPA lens.

Understanding the broad definition of "education records" is key to successful implementation.

Prerequisites

Prerequisite	Description
Phases 1-11 Complete	Core Purview features configured
FERPA Training	Understanding of FERPA requirements and definitions
Data Inventory	Knowledge of where student data resides
Stakeholder Alignment	Registrar, Legal, IT aligned on approach

Applying Purview Features for FERPA Compliance

1. Identifying FERPA Data ("Education Records")

The Challenge

FERPA defines "education records" broadly – anything directly related to a student maintained by the institution:

Included	Excluded
Grades and transcripts	Sole possession notes
Class schedules	Law enforcement records
Discipline records	Employment records (if unrelated to student status)
Financial aid information	Medical records (often HIPAA)
Emails about a specific student	Alumni records (post-attendance)
Advisor notes in systems

Identification Challenge

Identification requires looking beyond standard PII. Generic PII scans are insufficient for FERPA's broad definition.

Purview Solution (Leveraging Phase 2 & 4)

Custom Sensitive Information Types (SITs)

Create SITs using regex, keywords, and dictionaries specific to the institution:

<!-- Example: Student ID Number Pattern -->
<Entity id="student-id-pattern" patternsProximity="300" recommendedConfidence="85">
  <Pattern confidenceLevel="85">
    <IdMatch idRef="Regex_Student_ID"/>
    <Match idRef="Keyword_Student_Context"/>
  </Pattern>
</Entity>

<!-- Regex for Student ID (adjust to your format) -->
<!-- Example: S followed by 8 digits -->
<Regex id="Regex_Student_ID">S\d{8}</Regex>

<!-- Context Keywords -->
<Keyword id="Keyword_Student_Context">
  <Group matchStyle="word">
    <Term>student</Term>
    <Term>enrollment</Term>
    <Term>registrar</Term>
    <Term>transcript</Term>
  </Group>
</Keyword>

Recommended Custom SITs:

SIT Name	Detection Method	Example Pattern
Student ID Number	Regex	Institution-specific format (e.g., `S\d{8}`)
FERPA Keywords	Keyword list	"FERPA", "Education Record", "Transcript"
Academic Terms	Keyword list	"GPA", "Class Roster", "Student Schedule"
Special Programs	Keyword list	"IEP", "504 Plan", "Disciplinary Action"
Financial Aid Terms	Keyword list	"Financial Aid Award", "FAFSA", "Scholarship"
Course Codes	Dictionary	List of institutional course codes
Building/Location Names	Dictionary	Campus building and location names

Trainable Classifiers

Train classifiers to recognize common education record document types:

Classifier Name	Document Types
Academic Transcript	Official and unofficial transcripts
Student Application	Admissions applications
Disciplinary Letter	Conduct violation notices
FERPA Consent Form	Release authorization forms
Grade Report	Individual and class grade reports

Content Explorer Validation

Use Content Explorer to discover where content matching FERPA-specific SITs and classifiers resides across M365.

2. Protecting FERPA Data (Access Control)

The Challenge

FERPA requires limiting access to "school officials" with a "legitimate educational interest." This is a strict need-to-know basis.

Purview Solution (Leveraging Phase 4 & 6)

Sensitivity Label Configuration

Create a dedicated label: Highly Confidential - Education Record (FERPA Protected)

Setting	Configuration
Encryption	✅ Apply encryption
Permissions	Specific M365 groups only (see below)
Markings	Watermark/Header/Footer: "CONFIDENTIAL - FERPA PROTECTED"
Auto-labeling	Triggered by FERPA-specific SITs/classifiers

Critical Permission Configuration

Do NOT assign to broad groups like 'All Employees' or 'All Faculty'. Permissions should be minimal (e.g., Viewer or Reviewer unless editing is part of their legitimate interest).

Example Permission Groups:

Group Name	Role	Permissions
`RegistrarsOffice`	Records management	Co-Owner
`FinancialAidAdvisors`	Aid administration	Reviewer
`AcademicDeans`	Academic oversight	Reviewer
`AcademicAdvisors`	Student advising	Viewer
`FERPAComplianceTeam`	Compliance monitoring	Co-Owner

Conditional Access Policies (Phase 6)

Implement CA policies for SharePoint sites containing education records:

Policy	Condition	Action
FERPA Site - Managed Device Required	Accessing Registrar SharePoint site from unmanaged device	Block or limit to web-only
FERPA Site - Location Restriction	Accessing from outside approved locations	Require MFA + compliant device
FERPA Data - Session Control	Any access to FERPA-labeled content	App-enforced restrictions via MDCA

3. Preventing Unauthorized Disclosure (Data Leakage)

The Challenge

Stop education records from being shared inappropriately:

Externally (to non-institutional parties)
Internally (to staff without legitimate educational interest)

Purview Solution (Leveraging Phase 5)

DLP Policy 1: External Block (High Priority)

Setting	Configuration
Name	FERPA - Block External Sharing
Condition	Content contains `Highly Confidential - Education Record (FERPA Protected)` label OR matches FERPA SITs/classifiers AND Content is shared externally
Action	Block sharing (Email, Teams, SPO/ODB)
Policy Tip	"This content appears to be a FERPA-protected education record. External sharing is prohibited by institutional policy and federal law."
Override	❌ No overrides allowed
Alert Severity	High

DLP Policy 2: Internal Warning (Medium Priority - Optional)

Setting	Configuration
Name	FERPA - Internal Sharing Warning
Condition	Content contains FERPA label/SITs AND Content is shared internally with large groups or users outside expected roles
Action	Notify user with Policy Tip
Policy Tip	"This appears to be an Education Record. Ensure recipients have a legitimate educational interest before sharing."
Override	✅ Allow with justification (logged)
Alert Severity	Medium

4. Governing FERPA Data Lifecycle (Retention & Disposal)

The Challenge

Institutions need:

Defined retention schedules for different types of education records
Some records retained permanently, others temporarily
Defensible disposal processes

Purview Solution (Leveraging Phase 8)

Retention Label Examples

Label Name	Record Status	Retention Period	End Action
`Record - Academic Transcript - Permanent`	✅ Record	Forever	None
`Record - Admissions Application (Not Enrolled) - 3yr`	✅ Record	3 years	Auto-delete
`Record - Disciplinary File - 7yr PostGrad`	✅ Record	7 years after graduation (event-based)	Disposition review
`Record - Financial Aid - 5yr`	✅ Record	5 years after last enrollment	Disposition review
`Record - Advising Notes - 3yr PostGrad`	❌ Not a record	3 years after graduation	Auto-delete

Application Methods

Method	Use Case
Manual labeling	Ad-hoc records, exceptions
Auto-labeling policies	High-confidence document types
Default label on library	Records repositories

Disposition Review

Use disposition review for records requiring human verification before destruction:

Provides audit trail of destruction decisions
Ensures compliance with institutional policy
Documents justification for retention extensions

5. Responding to FERPA Rights (Access & Amendment Requests)

The Challenge

Students have rights under FERPA to:

Inspect and review their education records
Request amendments to inaccurate records
Consent to disclosure (with exceptions)

Institutions need efficient ways to locate, provide, and manage these records. Auditing access is critical.

Purview Solution (Leveraging Phase 9 & 11)

eDiscovery for Student Requests

Request Type	eDiscovery Approach
Access Request	Create case, search by student ID/name + FERPA SITs/labels, export for review
Amendment Request	Use review sets to manage discussion, track changes, document resolution
Third-Party Request	Verify consent, search and export with appropriate redactions

Search Query Example:

StudentID:S12345678 OR "John Smith" AND (SensitivityLabel:"FERPA Protected" OR ContentType:Transcript OR ContentType:GradeReport)

Audit Log for Access Tracking

Search the audit log to demonstrate compliance and investigate unauthorized access:

Audit Search	Purpose
`Accessed file` filtered by student ID	Who accessed specific student records
`Accessed mailbox item` filtered by student name	Email access to student information
Activities on Registrar SharePoint site	Comprehensive access log for records repository

Copilot Considerations for FERPA

Access Control is Primary

Critical Safeguard

Copilot respects Sensitivity Label encryption and permissions. If the Highly Confidential - Education Record (FERPA Protected) label is correctly applied with restricted permissions, Copilot cannot access that data for unauthorized users.

This is the most crucial FERPA safeguard for Copilot.

Defense in Depth

Layer	Protection
Sensitivity Labels	Encryption prevents unauthorized access
Restricted Content Discovery	Prevents Copilot from discovering FERPA content in broad searches
DLP Policies	Prevents Copilot from being used to share FERPA data externally
Permissions	Underlying SharePoint/OneDrive permissions respected

Restricted Search for FERPA Sites

Apply Restricted Content Discovery (Phase 10) to sites containing large amounts of FERPA data:

# Restrict Registrar site from org-wide search/Copilot discovery
Set-SPOSite -Identity "https://contoso.sharepoint.com/sites/Registrar" `
    -RestrictContentOrgWideSearch $true

Validation & Success Criteria

#	Validation Item	Test	Success Criteria
1	Identification	Search Content Explorer	Content tagged with custom `Student ID Number` SIT or `Academic Transcript` classifier appears
2	Protection - Encryption	Apply FERPA label to test document, access as unauthorized user	Access blocked with appropriate message
3	Protection - Markings	Apply FERPA label to test document	Watermark/header/footer visible
4	Prevention - DLP	Attempt to email FERPA-labeled document externally	Block triggered, policy tip displayed
5	Governance - Retention	Apply transcript label	Permanent retention applied, deletion blocked
6	Governance - Disposition	Apply disciplinary file label	Disposition review triggered at end of retention
7	Response - eDiscovery	Search using test student ID	Relevant test records found and displayed
8	Response - Audit	Search audit log for test record access	Access events logged with user, time, action

Phase 16: Microsoft Priva (PAYG Enhancement)

Pay-As-You-Go Enhancement

Microsoft Priva is NOT included in Microsoft 365 A5. It is a separate, pay-as-you-go (PAYG) service billed based on the number of subject rights requests processed. Evaluate the ROI based on your institution's privacy request volume before implementing.

Phase Objective

Implement privacy rights management with Microsoft Priva to efficiently handle Data Subject Rights Requests (DSRs), manage privacy risks, and demonstrate compliance with privacy regulations like GDPR, CCPA, and emerging state privacy laws.

Why Priva for Higher Education?

Higher education institutions receive increasing volumes of privacy-related requests:

Student DSRs: Students requesting access to or deletion of their education records
Employee DSRs: Faculty/staff exercising privacy rights over their HR data
Research Subjects: Participants in research studies exercising data rights
International Compliance: GDPR requirements for EU students and partners
State Law Compliance: California (CCPA/CPRA), Virginia (VCDPA), Colorado, etc.

Manual processing is unsustainable:

Challenge	Without Priva	With Priva
Finding all data	Manual search across systems	Automated discovery
Response time	Days to weeks	Hours to days
Consistency	Variable by handler	Standardized workflow
Audit trail	Manual documentation	Automatic logging
Scalability	Linear staff increase	Platform handles volume

Priva Components

Component	Function	Use Case
Subject Rights Requests	Automated DSR workflow	Process access, deletion, export requests
Privacy Risk Management	Identify overexposed personal data	Find risky data practices
Privacy Policies	Create data minimization policies	Enforce retention and handling rules

Prerequisites

Requirement	Details
Phases 1-5 Complete	SITs, labels, and DLP must be in place
Priva License	Purchased separately (PAYG)
Privacy Officer Identified	Role to manage Priva workflow
DSR Volume Estimate	Assess ROI based on expected request volume

Step 1 – Evaluate Priva ROI for Your Institution

Goal: Determine if Priva's cost is justified by your privacy request volume and compliance requirements.

ROI Calculation Framework:

Cost Factor	Estimate
Current DSR processing time	__ hours per request
Average staff hourly rate	$__
Annual DSR volume	__ requests
Annual manual cost	(Hours × Rate × Volume)
Priva licensing cost	$__ per request or per user/month
Break-even point	When Priva cost < manual cost

Decision Criteria:

Volume	Recommendation
< 50 requests/year	Manual processing likely more cost-effective
50-200 requests/year	Evaluate Priva, may break even
> 200 requests/year	Priva likely provides strong ROI

Additional Factors:

Risk reduction: Consistent, auditable process reduces legal exposure
Staff focus: Frees privacy staff for strategic work
Scalability: New privacy laws will increase request volume

Step 2 – Configure Subject Rights Requests

Goal: Set up automated DSR workflow to handle data access, deletion, and export requests.

Click-Ops (Purview Portal):

Navigate to Privacy > Subject rights requests.
Click Settings to configure:
- Approvers: Who reviews completed requests before response
- Notifications: Email alerts for new requests and deadlines
- Data sources: Which M365 locations to search (Exchange, OneDrive, SharePoint, Teams)
Click + Create request to start a new DSR:
- Request type: Access, Delete, Export, or Tagged list
- Data subject: Enter identifier (email, name, employee ID)
- Deadline: Auto-calculated based on regulation (GDPR: 30 days, CCPA: 45 days)

Request Workflow:

Request Types:

Type	What It Does	Typical Use
Access	Finds and packages all data about a person	"What data do you have about me?"
Delete	Finds data and facilitates deletion	"Please delete my information" (with exceptions)
Export	Packages data in portable format	Data portability requests
Tagged list	Creates list for manual review	Complex requests requiring human judgment

Step 3 – Configure Privacy Risk Management

Goal: Identify and remediate privacy risks such as overexposed personal data or stale data that should be deleted.

Click-Ops:

Navigate to Privacy > Privacy risk management.
Review the Overview dashboard for detected risks:
- Data overexposure (widely shared personal data)
- Data minimization opportunities (old data to delete)
- Data transfers (personal data leaving your organization)
Create Privacy Policies:
- Data overexposure policy: Alert when personal data is shared with large groups
- Data minimization policy: Flag personal data older than retention requirement
- Data transfer policy: Alert when personal data is sent externally

Policy Example - Data Overexposure:

Policy Name: Personal Data Overexposure Alert
Condition: Document contains PII (SITs from Phase 2)
AND Shared with: > 50 internal users OR external users
Action: Alert Privacy Team

Step 4 – Higher Ed DSR Workflow Example

Scenario: A student submits a GDPR access request asking "What personal data does the university hold about me?"

Priva Workflow:

Step	Action	Who
1	Student submits request via privacy portal	Student
2	Identity verification (confirm student identity)	Registrar/Privacy Office
3	Create Priva access request with student email	Privacy Team
4	Priva searches Exchange, OneDrive, SharePoint, Teams	Automated
5	Priva groups results by data type	Automated
6	Privacy Team reviews, redacts third-party info	Privacy Team
7	Manager approves final package	Privacy Manager
8	Export generated and sent to student	Automated
9	Request closed with full audit trail	Automated

Handling Complexities:

Complexity	How Priva Helps
Student is also an employee	Single search across all roles
Data in professor's OneDrive	Included in search scope
Need to redact other students' info	Review/redact interface
Must retain some records (FERPA)	Partial delete with documentation
30-day GDPR deadline	Deadline tracking with alerts

Priva vs. Content Search

Capability	Content Search (A5)	Priva (PAYG)
Purpose	General investigation	Privacy-specific workflow
Workflow	Manual export and review	Guided DSR workflow
Identity matching	Manual query building	Smart subject matching
Grouping	Manual organization	AI-powered grouping
Audit trail	Manual documentation	Automatic logging
Deadline tracking	Manual calendar	Built-in with alerts
Redaction	Separate tool needed	Built-in redaction
Cost	Included in A5	Per-request pricing

Recommendation: Use Content Search for occasional, simple requests. Consider Priva when volume exceeds 50+ requests/year or when you need defensible, auditable DSR processes.

Validation & Success Criteria

#	Validation Item	Test Method	Success Criteria
1	Priva License Active	Admin Center > Billing	Priva subscription visible
2	Data Sources Connected	Priva Settings	All M365 locations enabled
3	Test DSR Processed	Create test access request	Results returned and exportable
4	Workflow Configured	Check approvers and notifications	Approvers can access queue
5	Privacy Policies Active	Privacy Risk Management	At least one policy enabled

Part 7: Validation & Rollout

This section covers demonstrating your implementation to stakeholders and executing enterprise rollout.

Phase 17: POC Demonstration Guidance & Enterprise Rollout

Phase Objective

Transition from POC to production by effectively demonstrating configured capabilities to stakeholders, securing executive buy-in, and executing a phased enterprise rollout using a "Crawl-Walk-Run" approach. This phase translates technical implementation into measurable business value and establishes ongoing governance.

Decision Point

Before demonstrating to stakeholders and planning enterprise rollout, leadership must decide:

Demo Audience: Who are the key stakeholders requiring demonstration? (Executives, Legal, Compliance, IT Security, Department Heads)
Rollout Strategy: Will you use "Crawl-Walk-Run" phased approach or target specific departments first? (Recommend: Phased by feature maturity and risk tolerance)
Success Metrics: How will you measure implementation success? (Define KPIs: label adoption rate, DLP incident reduction, audit coverage)
Governance Model: Who owns ongoing policy management post-rollout? (Establish Data Governance Committee with clear roles)
Training Investment: What level of end-user training is required? (Depends on label complexity and user population)

Background & Context

Goal

Effectively demonstrate the configured Purview capabilities and associated controls (Conditional Access, MDCA, Power Platform DLP, Restricted Search) to key stakeholders
Highlight value and Zero Trust alignment
Outline a clear, actionable plan for transitioning from POC to phased enterprise deployment

Zero Trust Alignment

The demo showcases how the implemented controls work together to enforce Zero Trust principles across the data lifecycle and access patterns:

Principle	Demonstration
Verify Explicitly	Conditional Access policies, MFA requirements, device compliance
Least Privilege	Sensitivity label permissions, restricted access groups
Assume Breach	DLP blocking, Insider Risk detection, audit logging

Implications

Success Factors

A successful demo and clear plan are critical for securing resources and driving adoption for the full rollout. Tailoring the message to the audience is key.

This phase translates technical configuration into business value and compliance assurance.

Preparing the Demonstration

1. Full Validation

Before any demo, rigorously re-validate all configured features from Phases 1-14 (excluding skipped/optional items):

Use the validation steps outlined in each phase
Ensure test data, users, and expected outcomes are ready
Verify blocks, alerts, logs, and restricted access are reproducible
Test timing - some features have delays (DLP alerts, Activity Explorer)

2. Demo Scenarios & Assets

Prepare end-to-end scenarios demonstrating user and admin experiences for key risks:

Scenario	Risk Demonstrated	Features Shown
External PII sharing	Data leakage	DLP block, policy tip, alert
Unmanaged device access	Endpoint risk	CA limited access, MDCA block
Confidential document leaked	Persistent protection	Encryption blocking unauthorized access
Legal discovery request	Response capability	eDiscovery search, hold, export
Access audit requirement	Compliance proof	Audit log search results
Departing employee data theft	Insider threat	IRM alert, pattern detection

Prepare Assets:

Asset Type	Examples
Labeled documents	Word/Excel/PDF with various sensitivity labels
Test emails/chats	Messages containing SITs (SSN, credit cards)
Test user accounts	Separate browser profiles or VMs for different personas
Target sites	SharePoint sites with different restrictions
Search keywords	Pre-defined queries that return expected results

Backup Plan

Capture screenshots/videos of key outcomes as reliable backups in case live systems have latency or unexpected issues during the demo.

3. Environment Readiness

Item	Verification
Test devices	Managed and unmanaged devices available
Test user accounts	Active with appropriate licenses
Pilot groups	Correctly configured with test users
Licenses	E5/A5 features activated
Browser profiles	Separate profiles for different test users

4. Audience Tailoring

Prepare different focus areas based on audience:

Audience	Focus
Technical (IT/Security)	Configuration details, integration, troubleshooting
Compliance/Legal	Regulatory mapping, eDiscovery, audit trails
Executives	Risk reduction, ROI, business value

5. Co-Presenter Coordination

If presenting with others, assign clear roles:

Role	Responsibility
"User" presenter	Performs actions triggering policies
"Admin" presenter	Shows portal views, configuration, alerts
"IT/Security" presenter	Explains technical "how"
"Compliance/Legal" presenter	Explains business "why"

Practice the flow and handoffs smoothly before the actual demo.

Structuring the Demonstration

Introduction (All Audiences) - 5 minutes

## Demo Introduction Slide

### POC Goals
- ✅ Protect sensitive data across M365
- ✅ Govern data lifecycle with defensible retention
- ✅ Comply with regulatory requirements
- ✅ Respond to legal and audit requests
- ✅ Implement Zero Trust data principles

### Capabilities Demonstrated
- Microsoft Purview (Labels, DLP, Retention, eDiscovery, IRM, Comm Comp)
- Conditional Access & MDCA
- Power Platform DLP
- Restricted Content Discovery

### Context
- Leveraging E5/A5 licensing investment
- Building foundation for secure Copilot deployment

Technical Demo (Compliance/IT Team) - 30-45 minutes

Walk through portals and client applications with live demonstrations:

Demo 1: Sensitivity Labels

Step	Action	Show
1	Apply label in Word	Label selection, visual markings
2	Apply label in Outlook	Email classification
3	Demonstrate encryption	Unauthorized user blocked
4	Show admin view	Label configuration in Purview portal

Demo 2: Data Loss Prevention

Step	Action	Show
1	Send email with PII externally	Policy tip, block message
2	Share labeled doc in Teams	Block notification
3	Show DLP alert	Incident in Purview portal
4	Show policy config	Conditions, actions, exceptions

Demo 3: Conditional Access & MDCA

Step	Action	Show
1	Sign in from "unmanaged" device	Limited web access or block
2	Attempt to download confidential file	MDCA block (if configured)
3	Show CA policy	Conditions, grant controls
4	Show MDCA session policy	Access/session controls

Demo 4: Retention & Records

Step	Action	Show
1	Apply record label	Label application in SharePoint
2	Attempt to delete record	Immutability - deletion blocked
3	Show Policy Lookup Tool	Policy application verification
4	Show Disposition queue	Review process (explain workflow)

Demo 5: eDiscovery

Step	Action	Show
1	Show existing case	Case structure, custodians
2	Show active hold	Preserved content locations
3	Run content search	Search query, results preview
4	Show held item	Deleted item still preserved

Demo 6: Search Restriction (RCD)

Step	Action	Show
1	Org-wide search for restricted content	No results returned
2	Site-specific search	Results found
3	Show PowerShell command	Configuration method

Demo 7: Power Platform DLP

Step	Action	Show
1	Create flow mixing connectors	Block when saving
2	Show DLP policy	Connector classification

Demo 8: Audit Log

Step	Action	Show
1	Search for DLP block event	Event details
2	Search for label application	Event details
3	Export results	Audit trail documentation

Demo 9: IRM & Communication Compliance

Step	Action	Show
1	Show policy configuration	Indicators, thresholds
2	Explain workflow	Alert → triage → investigation
3	Show sample alert/case	Timeline, risk factors (use screenshots if no live alert)

Technical Demo Focus Points:

How features are configured
Integration points between services
Admin visibility and dashboards
Troubleshooting approaches (logs, policy lookup)

Executive Demo (Non-Technical Stakeholders) - 15-20 minutes

Focus on outcomes and value using scenarios and key visuals. Use PowerPoint with screenshots rather than extensive live clicking.

Scenario-Based Narrative

Present each scenario as a risk story with resolution:

Scenario 1: Data Leakage Prevention

"An employee tries to email a spreadsheet containing customer PII to an external address..."

What Happened	Result	Business Value
DLP detected SSNs in attachment	Email blocked automatically	Data breach averted
User saw policy tip explaining why	No confusion, clear guidance	Reduced help desk calls
Security team received alert	Visibility into attempted violation	Risk awareness

[Show screenshot of block message and alert]

Scenario 2: Endpoint Security

"A user accesses a sensitive project file from their home computer (unmanaged device)..."

What Happened	Result	Business Value
Conditional Access detected unmanaged device	Web-only access, download blocked	Data stays secure
User could still view and collaborate	Productivity maintained	Business continuity
Access logged for audit	Compliance documentation	Audit readiness

[Show screenshot of limited access experience]

Scenario 3: Persistent Protection

"A document marked 'Highly Confidential' is accidentally leaked outside the organization..."

What Happened	Result	Business Value
Encryption applied by sensitivity label	Unauthorized users cannot open	Protection travels with data
Only authorized users can decrypt	Access control persists	IP protection

[Explain concept with diagram]

Scenario 4: Legal Response

"Legal receives a discovery request for all communications about 'Project Neptune' from the past 2 years..."

What Happened	Result	Business Value
eDiscovery search across M365	Relevant content found in hours, not weeks	Reduced legal costs
Legal hold preserved evidence	Defensible collection process	Litigation readiness
Export for review	Streamlined workflow	Faster response

[Show screenshot of search results]

Scenario 5: Compliance Audit

"Auditors request proof of who accessed sensitive financial records last quarter..."

What Happened	Result	Business Value
Unified Audit Log queried	Complete access history available	Compliance proven
Export with timestamps, users, actions	Documentation for auditors	Audit success

[Show simplified audit log example]

Scenario 6: Insider Threat

"A departing employee begins downloading unusual volumes of files in their final week..."

What Happened	Result	Business Value
Insider Risk Management correlated signals	Pattern flagged automatically	Threat detected early
Investigation case created	HR/Security can review	Risk mitigation

[Show IRM concept diagram or alert screenshot]

Executive Summary Slide

POC Results Summary

Risk Reduction

✅ Automated blocking of sensitive data leakage
✅ Protection persists even if data leaves organization
✅ Insider threats detected through behavioral analysis

Compliance Alignment

✅ [HIPAA/GDPR/FERPA] controls implemented
✅ Defensible retention and disposition
✅ Complete audit trail for regulators

Business Value

✅ Leverages existing E5/A5 investment
✅ Consolidated platform vs. point solutions
✅ Minimal user productivity impact
✅ Foundation for secure AI (Copilot) deployment

Zero Trust Achievement

✅ Verify Explicitly - CA policies, MFA, device trust
✅ Least Privilege - Label-based access, restricted permissions
✅ Assume Breach - DLP, IRM, comprehensive logging

Compliance Manager (If Configured)

Display the dashboard showing improved compliance score related to implemented controls.

Alternative: Checklist Style Demo

For time-constrained presentations, use a phase-by-phase confirmation approach:

Phase	Capability	Status	Key Demo
Phase 0	Leadership Decisions	✅ Complete	Show classification taxonomy
Phase 1	Foundation (Audit, PAM)	✅ Complete	Show audit log, PAM request
Phase 1.5	Compliance Manager	✅ Complete	Show compliance score
Phase 2	Discovery & SITs	✅ Complete	Content Explorer results
Phase 2.5	DSPM Dashboard	✅ Complete	Show posture score
Phase 3	SharePoint Governance	✅ Complete	Show lifecycle policies
Phase 4	Sensitivity Labels	✅ Complete	Apply label, show encryption
Phase 4.5	Customer Key (if used)	⚪ Optional	Show key vault integration
Phase 5	Zero Trust / Conditional Access	✅ Complete	Limited access from unmanaged device
Phase 5.5	Information Barriers	✅ Complete	Cross-segment communication block
Phase 6	Copilot Protection (RCD/SAR)	✅ Complete	RCD demonstration
Phase 7	IRM & Adaptive Protection	✅ Complete	Risk-based DLP trigger
Phase 8	Retention & Records	✅ Complete	Record immutability
Phase 9	eDiscovery	✅ Complete	Search and hold
Phase 10	DLP	✅ Complete	Trigger block
Phase 11	Power Platform DLP	✅ Complete	Connector block
Phase 12	Comm Compliance	✅ Complete	Alert demonstration
Phase 13-15	Extensions (On-Prem, Azure, FERPA)	⚪ Optional	As applicable
Phase 16	Priva (PAYG)	⚪ Optional	DSR workflow demo

Talking Points for Different Audiences

Technical Team (IT, Security)

Topic	Talking Points
Integration	Single pane of glass, unified policies, API/PowerShell access
Management	Easier than point solutions, centralized policy management
Granularity	Flexible conditions, exceptions, scoping
Automation	Auto-labeling, automated retention, policy-driven alerts
Endpoint	Integration with Defender, Endpoint DLP
Performance	Minimal impact on user experience
Tuning	False positive management, policy refinement
Logging	Comprehensive audit capabilities, SIEM integration

Compliance/Legal Team

Topic	Talking Points
Regulatory Mapping	Direct alignment with HIPAA, GDPR, SOX, SEC 17a-4, FERPA
eDiscovery	Efficiency gains, defensible process, legal hold reliability
Records Management	Immutability guarantees, disposition proof
Audit Trails	Complete activity logging, exportable evidence
Automation	Reduced reliance on user compliance actions
Compliance Manager	Continuous assessment, improvement tracking

Executives (CISO, CIO, COO, Legal Counsel)

Topic	Talking Points
Risk Reduction	Quantifiable reduction in breach, insider threat, regulatory fine risk
Compliance Posture	Demonstrable improvement in regulatory alignment
Business Value	ROI from automation, cost comparison vs. alternatives
Investment Leverage	Maximizing E5/A5 license value already purchased
Visibility	Unified view across data estate
Productivity	Minimal negative impact, user guidance vs. obstruction
Scalability	Platform approach, future-ready for AI
Zero Trust	Industry-standard framework achievement

General Staff (Post-Rollout Awareness Sessions)

Topic	Talking Points
Personal Benefit	Labels make classification easy, protection if mistakes happen
Customer Protection	Safeguards for customer/student data
Company Protection	Avoiding breaches, fines, reputation damage
Policy Tips	What they mean, how to respond, when to request exceptions
Support	Where to get help, how to request exceptions
Purpose	Security and compliance focus, not surveillance

Next Steps – Scaling to Enterprise Rollout

Step 1: POC Evaluation & Feedback

Activity	Details
Gather feedback	Survey all participants (technical testers, pilot users, stakeholders)
Analyze DLP results	Review false positives, missed detections
Assess usability	Label confusion, workflow impacts
Document issues	Create issue log with severity and resolution status

Step 2: Executive Buy-in & Funding

Activity	Details
Present POC outcomes	Use demo materials, highlight successes and learnings
Build business case	Quantify risk reduction, ROI, cost comparison
Identify resource needs	Personnel, licenses (add-ons), infrastructure
Secure approval	Budget authorization, project sponsorship

Potential License/Add-on Requirements:

Item	Purpose
E5/A5 Compliance add-ons	For E3 tenants needing advanced features
SharePoint Advanced Management	RCD, advanced site lifecycle
10-year Audit Log retention	Extended compliance requirements
Additional storage	eDiscovery, retention growth

Activity	Details
Update configurations	Apply POC learnings to labels, DLP rules, retention
Expand scope	Additional SITs, locations, user groups
Define ownership	Document policy owners and change processes
Establish governance	Policy review cadence, approval workflows

Step 4: Phased Rollout Plan

"Crawl, Walk, Run" Approach

Crawl Phase (Month 1-2)

Activity	Scope	Mode
Expand pilot	Additional department(s) or wider pilot group	-
Sensitivity Labels	Recommend mode (user education)	Advisory
Basic Retention	Default policies on key locations	Enforce
DLP Policies	Core policies	Audit only

Walk Phase (Month 3-4)

Activity	Scope	Mode
Expand users	Multiple departments, broader scope	-
Auto-labeling	Enable for high-confidence scenarios	Enforce
DLP Policies	Enforce based on audit results	Enforce
Records Labels	Deploy for specific record types	Enforce
AIP Scanner	Pilot deployment for key shares	Discovery
Conditional Access	MFA, basic device trust	Enforce
Disposition Review	Implement review workflows	Enforce

Run Phase (Month 5+)

Activity	Scope	Mode
Full enterprise	All users, all locations	-
Advanced features	IRM, Comm Comp (scoped appropriately)	Enforce
Endpoint DLP	Full device onboarding	Enforce
AIP Scanner	Full deployment to all target shares	Enforce
SIEM Integration	Sentinel or third-party SIEM	Monitor
Power Platform/BI DLP	Broad connector policies	Enforce
Conditional Access	Hardened policies, risk-based	Enforce
Governance maturity	Formal processes, regular reviews	Ongoing

Step 5: Change Management & Training

Training Matrix

Audience	Training Type	Content	Timing
End Users	Video tutorials, Quick reference guides	Labels, policy tips, how to get help	Before rollout to their group
Help Desk	Technical training, Troubleshooting guides	Common issues, escalation paths, policy lookup	Before rollout
IT Admins	Deep-dive sessions, Documentation	Policy management, PowerShell, monitoring	During Crawl phase
Compliance/Legal	Workflow training	eDiscovery, disposition review, audit searches	During Walk phase
IRM/Comm Comp Reviewers	Specialized training	Investigation workflows, privacy considerations	Before enabling features
Executives	Briefings	Dashboard interpretation, escalation triggers	Quarterly

Training Assets to Develop

Asset	Format	Purpose
"Understanding Sensitivity Labels"	Video (3-5 min)	End-user label selection guidance
"What Policy Tips Mean"	Infographic	Quick reference for DLP notifications
"Requesting an Exception"	Step-by-step guide	Process for legitimate business exceptions
"Classifying Your Data"	Decision tree	Help users choose correct labels
"Admin Quick Reference"	PDF/OneNote	Policy lookup, common PowerShell commands
"eDiscovery Workflow"	Process document	Legal team standard procedures
FAQ Document	SharePoint page	Common questions and answers

Communication Plan

Phase	Timing	Audience	Channel	Message
Awareness	4 weeks before	All users	Email, Intranet	"Coming soon" announcement
Education	2 weeks before	Rollout group	Email, Teams	Training links, what to expect
Go-Live	Day of	Rollout group	Email, Teams	It's live, support contacts
Reinforcement	2 weeks after	Rollout group	Email	Tips, FAQ, feedback request
Ongoing	Monthly	All users	Newsletter	Tips, updates, success stories

Step 6: Governance and Roles

Establish/Empower Data Governance Committee

Role	Responsibility	Suggested Members
Executive Sponsor	Strategic direction, funding, escalation	CISO, CIO, or CLO
Data Governance Lead	Day-to-day program management	Dedicated role or Compliance Manager
Data Owners	Classification decisions for their data domains	Department heads or delegates
Compliance Officers	Regulatory alignment, policy review	Legal, Compliance team
Records Managers	Retention schedule management, disposition	Records Management team
IT Security	Technical implementation, monitoring	Security Operations
Privacy Officer	Privacy impact assessment, DSAR handling	Privacy/Legal team

Purview RBAC Role Assignments

Purview Role	Assigned To	Scope
Compliance Administrator	Compliance team leads	Full tenant
Compliance Data Administrator	Data governance team	Full tenant
Information Protection Admin	Security/Compliance analysts	Full tenant
eDiscovery Manager	Legal team	All cases or specific
eDiscovery Administrator	Legal IT liaison	Case management
Records Management	Records team	Retention policies
Insider Risk Management Analyst	HR Security liaison	IRM cases
Communication Compliance Analyst	HR/Compliance	Comm Comp cases
Audit Manager	Security/Compliance	Audit log access

Least Privilege

Periodically review who has privileged roles within Purview to ensure least privilege is maintained. Document justification for each role assignment.

Step 7: Continuous Improvement

Regular Review Cadence

Review Type	Frequency	Participants	Focus
DLP Incident Review	Weekly	Security, Compliance	False positives, policy gaps
IRM/Comm Comp Case Review	Weekly	HR, Legal, Security	Case outcomes, policy tuning
Audit Log Anomaly Review	Weekly	Security	Unusual access patterns
Policy Effectiveness	Monthly	Governance Committee	Metrics, trends, adjustments
User Feedback Review	Monthly	Training, Help Desk	Pain points, improvement opportunities
Executive Dashboard Review	Quarterly	Leadership	Risk posture, compliance status
Comprehensive Program Review	Annually	All stakeholders	Strategy, roadmap, budget

Metrics to Track

Category	Metric	Target Direction
Protection	% of sensitive content labeled	↑ Increase
Protection	DLP policy matches (audit)	↓ Decrease over time
Protection	DLP blocks (enforce)	Stable/↓ Decrease
Prevention	External sharing incidents	↓ Decrease
Compliance	Compliance Manager score	↑ Increase
Response	eDiscovery case completion time	↓ Decrease
Governance	Disposition reviews completed on time	↑ Increase
User Experience	Help desk tickets (Purview-related)	↓ Decrease
User Experience	Training completion rate	↑ Increase

Step 8: Establish Ongoing Maintenance & Governance

Regular Maintenance Activities

Activity	Frequency	Owner	Description
DLP Rule Tuning	Weekly/Monthly	Security	Adjust thresholds, add exceptions
IRM Indicator Review	Monthly	HR/Security	Tune indicators, thresholds
Auto-labeling Policy Review	Monthly	Compliance	Accuracy assessment, refinement
SIT Updates	Quarterly	Compliance	New patterns, retired SITs
Label Taxonomy Review	Quarterly	Governance Committee	Add/modify/retire labels
Retention Schedule Review	Annually	Records/Legal	Regulatory changes, business needs
Role Access Review	Quarterly	IT Security	Verify least privilege
Disposition Queue Monitoring	Weekly	Records	Ensure timely reviews

Staying Current with Microsoft Updates

Activity	Frequency	Owner
Review Message Center	Weekly	IT Admin
Review Purview Roadmap	Monthly	Governance Lead
Attend Microsoft webinars/Ignite	As available	Technical team
Review documentation updates	Monthly	Technical team
Test new features in dev tenant	Before GA adoption	IT Admin

Not "Set and Forget"

Purview is not a "set and forget" system. Continuous monitoring, tuning, and governance are essential to maintain effectiveness, adapt to changes, and ensure the system supports, rather than hinders, the business.

Conclusion and Best Practices

Implementing the full suite of Microsoft Purview and associated Zero Trust controls is a strategic journey, not a one-time project. By following the phased approach outlined in this guide, you have moved from foundational setup to a mature, multi-layered data governance framework.

This comprehensive configuration ensures that your organization's data is:

✅ Discovered - Know what sensitive data you have and where it lives
✅ Classified - Consistent labeling across all data types and locations
✅ Protected - Encryption, permissions, and access controls applied
✅ Governed - Lifecycle management from creation to defensible disposal

Core Principles for Long-Term Success

1. Align with Zero Trust Principles

At every stage, the goal was to implement the three pillars of Zero Trust:

Principle	Implementation
Verify Explicitly	Conditional Access policies verify user identity, device health, location, and risk before granting access
Least Privilege Access	Sensitivity labels restrict access to only those who need it; Purview RBAC limits admin capabilities
Assume Breach	DLP prevents data exfiltration; audit logging captures all activity; IRM detects behavioral anomalies

Foundation for AI

These principles are especially critical as organizations adopt AI tools like Microsoft Copilot. The controls you've implemented ensure Copilot respects data boundaries and doesn't expose sensitive information to unauthorized users.

2. Layer Your Defenses

The strength of Purview is not in any single feature but in their integration:

Integration	Value
Labels → DLP	Classification enables precise policy targeting
Audit Logs → IRM	Activity signals fuel behavioral detection
CA → MDCA	Gatekeeper triggers granular session controls
Labels → Endpoint DLP	Classification persists to device-level enforcement
All → eDiscovery	Unified search across protected content

No single control is a silver bullet; their combined strength provides resilient security.

3. Automate for Scale and Consistency

While manual actions are necessary for edge cases, the true power of the platform is realized through automation:

Automation	Benefit
Auto-labeling policies	Consistent classification without user burden
Automated retention	Defensible lifecycle management at scale
Policy-driven alerts	Real-time response to violations
Automated disposition	Efficient records management

Scale Reality

Manual governance is impossible for organizations with petabytes of data. Automation reduces human error and administrative burden while ensuring consistent policy application.

4. Govern the Full Lifecycle

Data protection isn't just about preventing leaks—it's about managing data from creation to defensible disposal:

By combining information protection with data lifecycle management and records management, you meet both security and compliance obligations, reducing your organization's risk surface over time.

5. Empower, Don't Obstruct

A well-implemented program guides users toward secure behavior:

Approach	Implementation
Clear guidance	Descriptive label names and tooltips
Informative feedback	Policy tips explain why actions are blocked
Justified controls	Users understand the business reason
Exception paths	Legitimate business needs can be accommodated
Training	Users know how to work within the system

User Experience Matters

If security controls are seen as obstacles, users will find workarounds. Design your implementation to make the secure path the easy path.

6. Monitor and Iterate

This is not a "set and forget" system:

Activity	Frequency	Purpose
Review DLP incidents	Weekly	Identify false positives, policy gaps
Analyze audit logs	Weekly	Detect anomalies, verify controls
Gather user feedback	Monthly	Identify friction, improve experience
Review Content Explorer	Monthly	Understand data distribution
Assess policy effectiveness	Quarterly	Tune based on metrics
Strategic review	Annually	Align with business/regulatory changes

The threat landscape, regulatory requirements, and your business will evolve. Your Purview implementation must evolve with them.

Summary: What You've Achieved

By completing this implementation, your organization has built more than just a set of technical controls:

Achievement	Business Value
Unified Classification	Single taxonomy across all data types and locations
Persistent Protection	Data protected regardless of where it travels
Automated Governance	Lifecycle management without manual intervention
Regulatory Alignment	Controls mapped to HIPAA, GDPR, FERPA, SOX, etc.
Rapid Response	eDiscovery and investigation capabilities ready
Behavioral Detection	Insider threats identified through signal correlation
Complete Audit Trail	Every action logged for compliance and forensics
AI Readiness	Foundation for secure Copilot deployment

Looking Forward

This foundation not only protects you against today's risks but also prepares you for future challenges and opportunities:

Future Consideration	How You're Prepared
AI Adoption	Labels and permissions ensure Copilot respects data boundaries
Regulatory Evolution	Flexible framework adapts to new requirements
Hybrid/Multi-cloud	AIP Scanner and Azure Purview extend reach
Remote Work	CA and MDCA secure access from anywhere
M&A Activity	eDiscovery and governance ready for due diligence
Incident Response	Audit logs and investigation tools prepared

Final Recommendations

Start with high-value, high-risk data - Don't try to boil the ocean
Communicate early and often - Change management is as important as technical configuration
Build champions - Identify advocates in each department
Measure and report - Show value to maintain executive support
Stay current - Microsoft continuously enhances Purview capabilities
Document everything - Policies, decisions, exceptions, and rationale
Test before enforcing - Always use audit mode before blocking
Plan for exceptions - Business needs will require flexibility
Integrate with existing processes - Align with ITSM, HR, Legal workflows
Celebrate successes - Recognize the team and share wins

The Journey Continues

Data governance is an ongoing program, not a project with an end date. The framework you've built provides the foundation for continuous improvement and adaptation as your organization and the threat landscape evolve.

Glossary

Quick reference for key terms and acronyms used throughout this implementation guide.

A

Adaptive Protection

Purview feature that dynamically adjusts DLP policy enforcement based on a user's Insider Risk Management risk level. Users with elevated risk (based on behavioral signals) automatically receive stricter DLP controls.

AIP Scanner (Microsoft Purview Information Protection Scanner)

On-premises service installed on Windows Server to scan file shares and SharePoint Server for sensitive information types and apply Purview Sensitivity Labels. Bridges cloud governance policies to on-premises data.

Auto-labeling

Purview capability to automatically apply sensitivity labels or retention labels to content based on conditions (SITs, keywords, trainable classifiers) without user intervention.

C

CA (Conditional Access)

Microsoft Entra ID feature that enforces access controls based on signals including user identity, device compliance, location, application, and risk level. Core Zero Trust gatekeeper.

CASB (Cloud Access Security Broker)

Security solution providing visibility and control over cloud application usage. Microsoft Defender for Cloud Apps (MDCA) is Microsoft's CASB solution.

Comm Comp (Communication Compliance)

Purview feature to monitor communications (email, Teams, Viva Engage) for policy violations including harassment, sensitive information disclosure, and regulatory compliance.

Compliance Manager

Purview tool providing compliance assessments, improvement actions, and compliance score tracking against regulatory frameworks (GDPR, HIPAA, etc.).

Content Explorer

Purview tool providing visibility into where sensitive information types and sensitivity labels exist across M365 locations.

Customer Key

Microsoft 365 feature allowing organizations to provide their own encryption keys (stored in Azure Key Vault) to wrap Microsoft's encryption keys. Provides customer control over key management and the ability to revoke Microsoft's access.

Custodian

In eDiscovery, a person whose data sources (mailbox, OneDrive, etc.) are placed under legal hold and included in case scope.

D

DKE (Double Key Encryption)

Purview encryption method where content is protected by two keys—one held by Microsoft and one held by the customer in their own infrastructure. Provides maximum control for highly sensitive content where even Microsoft admin access is unacceptable.

DLP (Data Loss Prevention)

Policies detecting sensitive content and applying protective actions (block, warn, audit, encrypt) to prevent unauthorized data disclosure. Exists in Microsoft Purview (M365), Endpoint DLP, and Power Platform.

Disposition

Records management process of reviewing content at the end of its retention period to determine if it should be deleted, retained longer, or reviewed further.

DSPM (Data Security Posture Management)

Purview dashboard providing unified visibility into data security posture across M365. Aggregates risk signals, surfaces overshared data, tracks posture score, and provides remediation recommendations.

E

eDiscovery (Electronic Discovery)

Legal process of identifying, collecting, preserving, and reviewing electronically stored information (ESI) for litigation, investigations, or regulatory matters. Purview offers Standard and Premium tiers.

Endpoint DLP

Extension of DLP policies to Windows and macOS devices via Microsoft Defender for Endpoint, controlling actions like copy to USB, print, and upload to cloud.

Entra ID (formerly Azure Active Directory / Azure AD)

Microsoft's cloud-based identity and access management service. Foundation for authentication, authorization, and Conditional Access.

F

FERPA (Family Educational Rights and Privacy Act)

US federal law protecting the privacy of student education records, granting parents/students rights to access and control disclosure of records.

File Plan

Records Management feature in Purview for defining retention labels with detailed descriptors including file plan properties (department, category, citation, etc.).

G

European Union regulation on data protection and privacy, requiring organizations to protect personal data and respect individual privacy rights.

H

HIPAA (Health Insurance Portability and Accountability Act)

US law establishing standards for protecting sensitive patient health information (PHI) from disclosure without consent.

Hold (Legal Hold / eDiscovery Hold)

Preservation mechanism overriding normal retention and deletion policies to ensure content relevant to litigation or investigation is preserved.

I

IB (Information Barriers)

Purview feature creating "ethical walls" that prevent specific groups (segments) from communicating or collaborating in Teams, SharePoint, and OneDrive. Used in financial services, legal, and higher education to prevent conflicts of interest.

IRM (Insider Risk Management)

Purview feature correlating user activity signals over time to detect patterns indicating potential insider threats (data theft, sabotage, policy violations).

Immutability

Records management property preventing content from being edited or deleted, ensuring authenticity and integrity for compliance requirements.

K

KQL (Keyword Query Language)

Query syntax used in Purview eDiscovery, Content Search, and Audit Log searches. Supports keywords, property filters, and Boolean operators.

L

Least Privilege

Security principle granting users only the minimum permissions necessary to perform their job functions, reducing attack surface and limiting breach impact.

Legal Hold

See "Hold"

M

MDCA (Microsoft Defender for Cloud Apps)

Cloud Access Security Broker (CASB) providing visibility, data control, and threat protection for cloud applications. Includes Session Control for real-time access governance.

MFA (Multi-Factor Authentication)

Authentication requiring multiple verification methods (something you know, have, or are) to confirm identity before granting access.

P

PAM (Privileged Access Management)

Microsoft 365 feature providing just-in-time access for privileged administrative tasks. Requires approval before admins can execute sensitive operations, creating audit trails and preventing standing admin access.

PHI (Protected Health Information)

Under HIPAA, individually identifiable health information held by covered entities or business associates, including demographic, medical, and payment information.

PII (Personally Identifiable Information)

Information that can be used to identify an individual, including name, SSN, address, email, phone number, biometrics, etc.

Policy Tip

Real-time notification displayed to users in Office applications or Teams when their action triggers a DLP or other compliance policy. Provides guidance on why the action was flagged and options for proceeding.

Power Platform

Microsoft's low-code/no-code platform including Power Apps (applications), Power Automate (workflows), Power BI (analytics), and Power Virtual Agents (chatbots).

Priva (Microsoft Priva)

Pay-as-you-go privacy management solution providing automated subject rights request (DSR) processing, privacy risk identification, and data minimization policies. Separate from A5 licensing.

Purview (Microsoft Purview)

Microsoft's unified data governance, risk, and compliance solution portfolio. Encompasses information protection, data loss prevention, data lifecycle management, records management, eDiscovery, insider risk management, communication compliance, and more.

R

RBAC (Role-Based Access Control)

Method of restricting system access based on roles assigned to users within an organization, ensuring users only have access to resources needed for their job function.

RCD (Restricted Content Discovery)

SharePoint Advanced Management feature excluding specific sites from organization-wide search results and Microsoft Copilot discovery while maintaining site-level search functionality.

Record (Records Management)

Content declared via a retention label as an official business record, typically requiring immutability (cannot be edited or deleted) for a specified retention period to meet regulatory or business requirements.

Retention Label

Label applied to individual items (documents, emails) specifying retention duration, whether the item is a record, and disposition action (delete, review, or nothing) at the end of retention.

Retention Policy

Broad policy applied to locations (mailboxes, SharePoint sites, Teams channels) setting default retention and deletion rules for all content within those locations.

S

Sensitivity Label

Label applied to content (documents, emails, meetings, sites, Power BI assets) to classify sensitivity level and optionally apply protection (encryption, visual markings, access restrictions).

SIT (Sensitive Information Type)

Pattern definition (using regex, keywords, dictionaries, functions, or machine learning) used by Purview to detect specific types of sensitive data such as SSN, credit card numbers, or custom patterns like student IDs.

SOX (Sarbanes-Oxley Act)

US federal law establishing audit and financial regulations for public companies, including requirements for records retention and internal controls.

T

Trainable Classifier

Machine learning-based classifier in Purview that can be trained on sample content to recognize specific document types or content categories (e.g., contracts, resumes, source code).

U

UAL (Unified Audit Log)

Centralized audit log in Microsoft 365 capturing user and admin activities across services including Exchange, SharePoint, OneDrive, Teams, Entra ID, and more.

Z

Zero Trust

Security model based on the principle of "never trust, always verify." Requires strict identity verification for every user and device attempting to access resources, regardless of network location. Three pillars: Verify Explicitly, Use Least Privilege Access, Assume Breach.

Risk Register Template

Use this template to document risks identified during discovery and planning, and how Purview controls mitigate them. This register should be a living document, reviewed and updated regularly.

How to Use This Template

Identify Risks during discovery phases by reviewing data types, locations, user behaviors, and regulatory requirements
Assess Impact considering business, regulatory, and reputational consequences
Map Controls to specific Purview features and implementation phases
Evaluate Residual Risk after controls are implemented
Assign Ownership for ongoing monitoring and review
Review Regularly (quarterly recommended) to update based on changes

Risk Register

Risk Categories

Category	Description
Data Leakage	Unauthorized disclosure of sensitive data externally
Unauthorized Access	Internal access by users without legitimate need
Compliance	Failure to meet regulatory requirements
Insider Threat	Malicious or negligent actions by employees
Data Governance	Improper retention, disposal, or lifecycle management
AI/Copilot	Sensitive data exposure through AI tools

Sample Risk Entries

R001: Accidental External Email of Customer PII

Field	Value
Risk ID	R001
Risk Description	Employee accidentally emails spreadsheet containing customer PII (SSNs, financial data) to external recipient
Category	Data Leakage
Business Impact	Reputational damage, customer notification costs, potential litigation, regulatory fines
Regulatory Impact	GDPR, CCPA, potentially GLBA
Likelihood (Pre-Control)	Medium
Impact (Pre-Control)	High
Mitigating Purview Controls	• DLP Policy: Block external email containing >X SSNs (Phase 10) • Sensitivity Label: Auto-label files with PII as Confidential with encryption (Phase 4) • Audit Log: Detect and log attempt (Phase 7)
Control Phase(s)	4, 7, 10
Residual Risk	Low
Owner	Compliance Officer
Review Date	YYYY-MM-DD
Notes	DLP policy in enforce mode since MM/DD. Monthly review of false positives.

R002: Unauthorized Access to HR Records

Field	Value
Risk ID	R002
Risk Description	Employees outside HR department access sensitive personnel records on SharePoint
Category	Unauthorized Access
Business Impact	Employee privacy violation, potential legal action, trust erosion
Regulatory Impact	GDPR, CCPA, potentially HIPAA (if health info included)
Likelihood (Pre-Control)	Low
Impact (Pre-Control)	Medium
Mitigating Purview Controls	• Sensitivity Label: Apply 'Highly Confidential - HR' label with encryption and restricted permissions (Phase 4) • Conditional Access: Limit access to HR site from unmanaged devices (Phase 5) • Restricted Content Discovery: Exclude HR site from org-wide search (Phase 6) • Audit Log: Monitor and alert on access (Phase 7)
Control Phase(s)	4, 5, 6, 7
Residual Risk	Low
Owner	HR Director / IT Security
Review Date	YYYY-MM-DD
Notes	Quarterly access review of HR site permissions.

R003: Failure to Retain Financial Records (SOX)

Field	Value
Risk ID	R003
Risk Description	Financial records required for SOX compliance are deleted before 7-year retention requirement
Category	Compliance
Business Impact	Audit failure, inability to respond to regulatory inquiries
Regulatory Impact	SOX
Likelihood (Pre-Control)	Medium
Impact (Pre-Control)	High
Mitigating Purview Controls	• Retention Policy/Label: Apply 7-year retention marked as Record to financial locations/types (Phase 8) • Disposition Review: Ensure records aren't deleted without review (Phase 8) • Audit Log: Track deletion attempts (Phase 7)
Control Phase(s)	7, 8
Residual Risk	Low
Owner	Finance / Legal
Review Date	YYYY-MM-DD
Notes	Annual review of retention schedule with Legal.

R004: Departing Employee Data Exfiltration

Field	Value
Risk ID	R004
Risk Description	Employee who has resigned downloads large volumes of sensitive client data or intellectual property before departure
Category	Insider Threat
Business Impact	IP theft, competitive disadvantage, client trust breach
Regulatory Impact	GDPR, CCPA (if personal data), trade secret laws
Likelihood (Pre-Control)	Medium
Impact (Pre-Control)	High
Mitigating Purview Controls	• Insider Risk Management: Policy for departing users detecting mass download/exfiltration patterns (Phase 7) • DLP/Endpoint DLP: Block USB copy or external email of sensitive labels/SITs (Phase 10) • Audit Log: Forensic investigation capability (Phase 7)
Control Phase(s)	7, 10
Residual Risk	Medium
Owner	HR / Security
Review Date	YYYY-MM-DD
Notes	Detection-focused; complete prevention challenging. HR integration for departure notification critical.

R005: Hostile Work Environment Communications

Field	Value
Risk ID	R005
Risk Description	Employees use Teams or email for harassment, discrimination, or threatening communications
Category	Compliance / HR
Business Impact	Hostile work environment, HR complaints, potential litigation
Regulatory Impact	Employment law, Title VII
Likelihood (Pre-Control)	Medium
Impact (Pre-Control)	Medium
Mitigating Purview Controls	• Communication Compliance: Policy detecting profanity, harassment, threats; route to HR for review (Phase 7/12)
Control Phase(s)	7, 12
Residual Risk	Low
Owner	HR / Legal
Review Date	YYYY-MM-DD
Notes	Privacy considerations documented. Reviewer training completed.

R006: FERPA Violation - Student Records Shared Externally

Field	Value
Risk ID	R006
Risk Description	Student education records shared externally without proper consent
Category	Compliance
Business Impact	FERPA violation, fines, reputational damage, loss of federal funding
Regulatory Impact	FERPA
Likelihood (Pre-Control)	Medium
Impact (Pre-Control)	High
Mitigating Purview Controls	• Custom SITs: Detect Student IDs and education record patterns (Phase 2, 15) • Sensitivity Label: 'Highly Confidential - FERPA Protected' with encryption and restricted access (Phase 4, 15) • DLP Policy: Block external sharing of FERPA label/SITs (Phase 10, 15) • Audit Log: Track access and sharing (Phase 7)
Control Phase(s)	2, 4, 7, 10, 15
Residual Risk	Low
Owner	Registrar / Compliance
Review Date	YYYY-MM-DD
Notes	Custom SIT for institutional Student ID format deployed.

R007: Copilot Exposes M&A Confidential Data

Field	Value
Risk ID	R007
Risk Description	Microsoft Copilot summarizes or surfaces highly confidential M&A data to unauthorized users during search or chat
Category	AI/Copilot
Business Impact	Breach of confidentiality, deal risk, competitive disadvantage
Regulatory Impact	SEC regulations (if public company), NDA violations
Likelihood (Pre-Control)	Low (if controls good)
Impact (Pre-Control)	High
Mitigating Purview Controls	• Sensitivity Label: Apply 'Highly Confidential - M&A' label with encryption and restricted permissions (Phase 4) • Restricted Content Discovery: Exclude M&A site from org-wide search/Copilot discovery (Phase 6) • Conditional Access/Permissions: Ensure only authorized users can access source data (Phase 5)
Control Phase(s)	4, 5, 6
Residual Risk	Low
Owner	Legal / IT Security
Review Date	YYYY-MM-DD
Notes	M&A site created with restricted membership. RCD applied. Label required for all content.

R008: Healthcare Data Breach (HIPAA)

Field	Value
Risk ID	R008
Risk Description	Protected Health Information (PHI) exposed through email, sharing, or unauthorized access
Category	Data Leakage / Compliance
Business Impact	Patient harm, breach notification costs, reputational damage
Regulatory Impact	HIPAA, state health privacy laws
Likelihood (Pre-Control)	Medium
Impact (Pre-Control)	High
Mitigating Purview Controls	• Built-in SITs: Use HIPAA-related SITs for detection (Phase 2) • Sensitivity Label: 'Highly Confidential - PHI' with encryption (Phase 4) • DLP Policy: Block external sharing, require encryption for internal (Phase 10) • Conditional Access: Managed devices required for PHI access (Phase 5) • Audit Log: Comprehensive access tracking (Phase 7)
Control Phase(s)	2, 4, 5, 7, 10
Residual Risk	Low
Owner	Privacy Officer / Compliance
Review Date	YYYY-MM-DD
Notes	Annual HIPAA risk assessment includes Purview controls review.

Blank Template

Copy and complete for each identified risk:

#### RXXX: [Risk Title]

| Field | Value |
|:------|:------|
| **Risk ID** | RXXX |
| **Risk Description** | [Detailed description of the risk scenario] |
| **Category** | [Data Leakage / Unauthorized Access / Compliance / Insider Threat / Data Governance / AI/Copilot] |
| **Business Impact** | [Describe business consequences] |
| **Regulatory Impact** | [List applicable regulations] |
| **Likelihood (Pre-Control)** | [Low / Medium / High] |
| **Impact (Pre-Control)** | [Low / Medium / High] |
| **Mitigating Purview Controls** | • [Control 1 with phase]<br/>• [Control 2 with phase]<br/>• [Control 3 with phase] |
| **Control Phase(s)** | [Phase numbers] |
| **Residual Risk** | [Low / Medium / High] |
| **Owner** | [Role/Team responsible] |
| **Review Date** | YYYY-MM-DD |
| **Notes** | [Implementation status, special considerations] |

Risk Matrix Reference

Use this matrix to assess likelihood and impact:

	Low Impact	Medium Impact	High Impact
High Likelihood	Medium Risk	High Risk	Critical Risk
Medium Likelihood	Low Risk	Medium Risk	High Risk
Low Likelihood	Low Risk	Low Risk	Medium Risk

Impact Definitions

Level	Business	Regulatory	Reputational
Low	Minimal operational disruption, <$10K cost	Minor policy violation, no fine	Internal awareness only
Medium	Moderate disruption, $10K-$100K cost	Reportable incident, potential fine <$100K	Local media, customer complaints
High	Major disruption, >$100K cost	Significant violation, fine >$100K	National media, customer loss

Likelihood Definitions

Level	Frequency	Description
Low	<1x per year	Unlikely to occur, no recent history
Medium	1-4x per year	May occur, some history or near-misses
High	>4x per year	Likely to occur, frequent history

Review Log

Track risk register reviews:

Review Date	Reviewer	Changes Made	Next Review
YYYY-MM-DD	[Name]	Initial creation	YYYY-MM-DD
YYYY-MM-DD	[Name]	Added R007 (Copilot risk), updated R004 residual risk	YYYY-MM-DD

Living Document

This risk register should be reviewed quarterly at minimum, and updated whenever:

New data types or systems are identified
Regulatory requirements change
New controls are implemented
Incidents occur that reveal new risks
Business processes change significantly

*This guide was collaboratively developed by a human subject matter expert and an AI assistant to ensure it is both comprehensive and easy to understand. *

Implementation Roadmap
Background & Context
Prerequisites
- A5 Features Covered in This Guide
- PAYG / Add-On Features (Optional)
Part 1: Foundation & Governance
Phase 0: Leadership and Policy Decisions
Phase 1: Foundational Setup - Tenant Preparation & Licensing
- Background & Context
- Prerequisites
- Procedure / Implementation
- Security & Compliance Considerations
- Validation & Success Criteria
- Sub-Phase 1.5: Compliance Manager Setup
Part 2: Know & Protect Your Data
Phase 2: Discovery & Identity (Know Your Data)
- Background & Context
- Prerequisites
- Side-by-Side Comparison: SIT vs EDM
- Sub-Phase 2.5: Data Security Posture Management (DSPM)
- Full Discovery Phase Data Flow
- Validation & Success Criteria
- Security & Compliance Considerations
Part 3: Access Control & Sharing Governance
Phase 3: SharePoint & Teams Governance (Permission & Lifecycle)
- Background & Context
- Prerequisites
- Site Lifecycle Policy Rollout Strategy
- Procedure / Implementation
- Communication Templates
- Validation & Success Criteria
- Security & Compliance Considerations
Phase 4: Protection - Sensitivity Labels & Information Protection
- Background & Context
- Prerequisites
- Procedure / Implementation
- Validation & Success Criteria
- Security & Compliance Considerations
- Communication Templates
- Sub-Phase 4.5: Advanced Encryption (Customer Key & Double Key Encryption)
Phase 5: Zero Trust Access Control (Entra ID & MDCA)
- Background & Context
- Prerequisites
- Procedure / Implementation
- Validation & Success Criteria
- Part 4: Conditional Access Integration
- Validation & Success Criteria
- Security & Compliance Considerations
- Communication Templates
Phase 5.5: Information Barriers (Ethical Walls)
- Background & Context
- Prerequisites
- Procedure / Implementation
- Validation & Success Criteria
- Security & Compliance Considerations
- Communication Templates
Phase 6: AI Readiness & Copilot Protection (Restricted Content Discovery)
- Background & Context
- Prerequisites
- Procedure / Implementation
- End-User Experience
- Copilot Considerations
- Validation & Success Criteria
- Communication Templates
Part 4: Monitoring & Investigation
Phase 7: Advanced Monitoring & Insider Risk (The "Nerve Center")
- Background & Context
- Prerequisites
- Procedure / Implementation
- Validation & Success Criteria
- Copilot Considerations
Phase 8: Data Lifecycle, Records & Disposition (The Full Lifecycle)
- Background & Context
- Prerequisites
- Procedure / Implementation
- Validation & Success Criteria
- Security & Compliance Considerations
- Communication Templates
Phase 9: Response & Investigation (eDiscovery Premium)
- Background & Context
- Prerequisites
- Procedure / Implementation
- Validation & Success Criteria
- Security & Compliance Considerations
- Communication Templates
- Phase 7 Sub-Phases: Advanced Monitoring Implementation
- Prerequisites
- Sub-Phase 7.1: Deep Forensics (Unified Audit Log)
- Sub-Phase 7.2: Insider Risk Management (The "Exit Strategy")
- Sub-Phase 7.3: Communication Compliance (Campus Safety)
- Validation & Success Criteria
- Security & Compliance Considerations
- Sub-Phase 7.4: Adaptive Protection (Dynamic DLP)
Part 5: Prevention & External Controls (Later Phase)
Phase 10: Data Loss Prevention (DLP)
- Background & Context
- Prerequisites
Phase 11: Power Platform DLP
- Background & Context
- Prerequisites
Phase 12: Communication Compliance
- Background & Context
- Prerequisites
Part 6: Extensions & Advanced
Phase 13: Extending Reach - On-Premises & Other Storage Solutions
Background & Context
- Goal
- Zero Trust Alignment
- Implications
Prerequisites
Procedure / Implementation
- Step 1: Identify Target On-Premises/External Repositories
- Step 2: Understand the AIP Scanner Architecture
- Step 3: Plan Scanner Deployment
- Step 4: Conceptual Scanner Configuration
- Step 5: Understand Integration of Scan Results
- Step 6: Understand Policy Enforcement on Labeled On-Premises Data
- Step 7: Consider Alternative/Complementary Approaches
PowerShell Reference
End-User Experience
Copilot Considerations
- Requirements for Copilot Indexing
- Labels Still Matter
Validation & Success Criteria
Communication Templates
- Internal Communication - IT/Infrastructure/Storage Admins
Phase 14: Integrating with Azure Purview Data Map (Data Governance)
Background & Context
- Goal
- Zero Trust Alignment
- Implications
- 3. Sensitivity Label Integration (Evolving)
- 4. Data Catalog
- 5. Data Estate Insights
- 6. Data Lineage
Integration with M365 Purview Compliance
- Unified Classifiers
- Unified Labels (Vision)
- Compliance Manager Integration
Considerations for Enterprise Rollout
- Licensing & Cost
- Scope & Phasing
- Skills Requirements
Why This Matters
Phase 15: Specific Regulatory Focus - FERPA Protection
Background & Context
- Goal
- Zero Trust Alignment
- Implications
Prerequisites
Applying Purview Features for FERPA Compliance
- 1. Identifying FERPA Data ("Education Records")
- 2. Protecting FERPA Data (Access Control)
- 3. Preventing Unauthorized Disclosure (Data Leakage)
- 4. Governing FERPA Data Lifecycle (Retention & Disposal)
- 5. Responding to FERPA Rights (Access & Amendment Requests)
Copilot Considerations for FERPA
- Access Control is Primary
- Defense in Depth
- Restricted Search for FERPA Sites
Validation & Success Criteria
Phase 16: Microsoft Priva (PAYG Enhancement)
- Why Priva for Higher Education?
- Priva Components
- Prerequisites
- Priva vs. Content Search
- Validation & Success Criteria
Part 7: Validation & Rollout
Phase 17: POC Demonstration Guidance & Enterprise Rollout
Background & Context
- Goal
- Zero Trust Alignment
- Implications
Preparing the Demonstration
- 1. Full Validation
- 2. Demo Scenarios & Assets
- 3. Environment Readiness
- 4. Audience Tailoring
- 5. Co-Presenter Coordination
Structuring the Demonstration
- Introduction (All Audiences) - 5 minutes
- Technical Demo (Compliance/IT Team) - 30-45 minutes
- Executive Demo (Non-Technical Stakeholders) - 15-20 minutes
- POC Results Summary
- Alternative: Checklist Style Demo
- Talking Points for Different Audiences
- Next Steps – Scaling to Enterprise Rollout
- Step 3: Policy Refinement & Finalization
- Step 4: Phased Rollout Plan
- Step 5: Change Management & Training
- Step 6: Governance and Roles
- Step 7: Continuous Improvement
- Step 8: Establish Ongoing Maintenance & Governance
- Conclusion and Best Practices
Core Principles for Long-Term Success
- 1. Align with Zero Trust Principles
- 2. Layer Your Defenses
- 3. Automate for Scale and Consistency
- 4. Govern the Full Lifecycle
- 5. Empower, Don't Obstruct
- 6. Monitor and Iterate
- Summary: What You've Achieved
- Looking Forward
- Final Recommendations
Glossary
- A
- C
- D
- E
- F
- G
- H
- I
- K
- L
- M
- P
- R
- S
- T
- U
- Z
Risk Register Template
How to Use This Template
Risk Register
- Risk Categories
- Sample Risk Entries
Blank Template
Risk Matrix Reference
- Impact Definitions
- Likelihood Definitions
Review Log

Implementation Roadmap​

Background & Context​

Prerequisites​

A5 Features Covered in This Guide​

PAYG / Add-On Features (Optional)​

Part 1: Foundation & Governance​

Phase 0: Leadership and Policy Decisions​

Phase 1: Foundational Setup - Tenant Preparation & Licensing​

Background & Context​

Prerequisites​

Procedure / Implementation​

Security & Compliance Considerations​

Validation & Success Criteria​

Sub-Phase 1.5: Compliance Manager Setup​

Understanding Compliance Score​

Part 2: Know & Protect Your Data​

Phase 2: Discovery & Identity (Know Your Data)​

Background & Context​

Prerequisites​

Side-by-Side Comparison: SIT vs EDM​

Sub-Phase 2.5: Data Security Posture Management (DSPM)​

DSPM Dashboard Components​

Full Discovery Phase Data Flow​

Validation & Success Criteria​

Security & Compliance Considerations​

Part 3: Access Control & Sharing Governance​

Phase 3: SharePoint & Teams Governance (Permission & Lifecycle)​

Background & Context​

Prerequisites​

Site Lifecycle Policy Rollout Strategy​

Procedure / Implementation​

Part 1: Tenant-Level Sharing Settings (Hardening)​

Deep Dive: Understanding SharePoint Sharing Link Types​

Sharing Link Types Explained​

Detailed Link Type Analysis​

Things Microsoft Allows You to Control​

Things Microsoft Limits or Forces​

Microsoft Recommendations We Disagree With​

1. Branded Site Lifecycle Notifications → Now Partially Addressed!​

2. External Sharing Approval Workflow​

3. Permission Inheritance Break Monitoring​

4. Orphaned Permission Cleanup​

5. Cross-Site Permission Visibility​

Deep Dive: SharePoint Access Control Architecture​

Permission Inheritance Hierarchy​

Permission Levels Explained​

The "Everyone" Problem​

Broken Inheritance: The Hidden Risk​

Access Control at Each Layer​

Cannot Prevent Permission Inheritance Breaking​

Cannot Implement Pre-Approval for Sharing​

Cannot Restrict Sharing to Specific External Domains​

Cannot Audit "Who Accessed What" Retroactively for Specific Files​

Cannot Enforce "Need to Know" Access Patterns​

Recommended Access Control Model​

Access Review Recommendations​

Permission Reporting Script​

Part 2: Site Lifecycle Management (New Governance)​

What Is Site Lifecycle Management?​

The Three Pillars of Site Lifecycle​

Policy Configuration Options​

What "Activity" Means​

Custom Email Notifications​

What Microsoft Doesn't Let You Customize​

Lifecycle Policy Decision Matrix​

Integration with Microsoft Teams​

Communication Templates​

Pre-Implementation: Sharing Policy Change​

Validation & Success Criteria​

Security & Compliance Considerations​

Phase 4: Protection - Sensitivity Labels & Information Protection​

Background & Context​

Prerequisites​

Procedure / Implementation​

Validation & Success Criteria​

Security & Compliance Considerations​

Communication Templates​

End-User: Introduction to Sensitivity Labels​

End-User: What to Do When You See a Label Recommendation​

IT Staff: Label Policy Deployment Notification​

Implementation Roadmap

Background & Context

Prerequisites

A5 Features Covered in This Guide

PAYG / Add-On Features (Optional)

Part 1: Foundation & Governance

Phase 0: Leadership and Policy Decisions

Phase 1: Foundational Setup - Tenant Preparation & Licensing

Background & Context

Prerequisites

Procedure / Implementation

Security & Compliance Considerations

Validation & Success Criteria

Sub-Phase 1.5: Compliance Manager Setup

Understanding Compliance Score

Part 2: Know & Protect Your Data

Phase 2: Discovery & Identity (Know Your Data)

Background & Context

Prerequisites

Side-by-Side Comparison: SIT vs EDM

Sub-Phase 2.5: Data Security Posture Management (DSPM)

DSPM Dashboard Components

Full Discovery Phase Data Flow

Validation & Success Criteria

Security & Compliance Considerations

Part 3: Access Control & Sharing Governance

Phase 3: SharePoint & Teams Governance (Permission & Lifecycle)

Background & Context

Prerequisites

Site Lifecycle Policy Rollout Strategy

Procedure / Implementation

Part 1: Tenant-Level Sharing Settings (Hardening)

Deep Dive: Understanding SharePoint Sharing Link Types

Sharing Link Types Explained

Detailed Link Type Analysis

Things Microsoft Allows You to Control

Things Microsoft Limits or Forces

Microsoft Recommendations We Disagree With

1. Branded Site Lifecycle Notifications → Now Partially Addressed!

2. External Sharing Approval Workflow

3. Permission Inheritance Break Monitoring

4. Orphaned Permission Cleanup

5. Cross-Site Permission Visibility

Deep Dive: SharePoint Access Control Architecture

Permission Inheritance Hierarchy

Permission Levels Explained

The "Everyone" Problem

Broken Inheritance: The Hidden Risk

Access Control at Each Layer

Cannot Prevent Permission Inheritance Breaking

Cannot Implement Pre-Approval for Sharing

Cannot Restrict Sharing to Specific External Domains

Cannot Audit "Who Accessed What" Retroactively for Specific Files

Cannot Enforce "Need to Know" Access Patterns

Recommended Access Control Model

Access Review Recommendations

Permission Reporting Script

Part 2: Site Lifecycle Management (New Governance)

What Is Site Lifecycle Management?

The Three Pillars of Site Lifecycle

Policy Configuration Options

What "Activity" Means

Custom Email Notifications

What Microsoft Doesn't Let You Customize

Lifecycle Policy Decision Matrix

Integration with Microsoft Teams

Communication Templates

Pre-Implementation: Sharing Policy Change

Validation & Success Criteria

Security & Compliance Considerations

Phase 4: Protection - Sensitivity Labels & Information Protection

Background & Context

Prerequisites

Procedure / Implementation

Validation & Success Criteria

Security & Compliance Considerations

Communication Templates

End-User: Introduction to Sensitivity Labels

End-User: What to Do When You See a Label Recommendation

IT Staff: Label Policy Deployment Notification