Skip to main content

Implementing Email Data Loss Prevention and Encryption

This guide provides an end-to-end walkthrough for configuring Data Loss Prevention (DLP) policies to protect sensitive information in email. By implementing these controls, any email containing regulated data (e.g., PII, PHI) will be automatically encrypted or blocked, preventing data leaks and ensuring compliance.

TL;DR
  • Define what data is sensitive using built-in Sensitive Information Types (SITs) or custom ones (e.g., UIN).
  • Create DLP policies in Microsoft Purview and Google Workspace to detect this data in outgoing emails.
  • Configure policies to automatically encrypt emails containing sensitive data or block them from leaving the organization.
  • Tailor policies for different groups like faculty, staff, and students, who have different data handling needs.
  • Start policies in an audit-only mode to test for false positives before rolling out full enforcement.
  • Regularly review policy hit reports to fine-tune rules and educate users.

Background and Scope​

Email is a primary channel for communication but also one of the most common ways sensitive information can be accidentally leaked. Universities handle a vast range of sensitive data, from student records (PII) and protected health information (PHI) to confidential research data. Without proper controls, an employee or student can easily email a file containing Social Security numbers or other regulated data to an external address, potentially causing a data breach with significant legal and reputational consequences.

Data Loss Prevention (DLP) is a strategy and set of tools designed to mitigate this risk by detecting sensitive content and preventing its unauthorized sharing. For email, DLP policies can scan messages and attachments for patterns like credit card numbers, SSNs, or other defined sensitive data types. When a policy rule is triggered, the DLP system can take an automated action, such as blocking the email, warning the sender, or—most importantly for enabling secure collaboration—encrypting the message.

Encryption ensures that even if an email is intercepted or sent to the wrong recipient, only authorized individuals can read the content. Modern solutions like Microsoft Purview Message Encryption and Google Workspace Client-Side Encryption allow organizations to send protected emails that are shielded from unauthorized access. This guide focuses on implementing DLP with a primary action of automatic encryption, which addresses multiple compliance requirements (FERPA, HIPAA), aligns with NIST's Cybersecurity Framework, and supports a Zero Trust security model.

Scope: This guide covers configuring DLP policies for the two primary email platforms: Microsoft 365 (Exchange Online), managed via the Microsoft Purview portal, and Google Workspace (Gmail), managed through the Google Admin console. We assume the necessary licensing and administrative permissions are in place.

Prerequisites​

RequirementMin Version/LicenseNotes
Microsoft 365 LicensingM365 A3/E3 or higherCore DLP for Exchange is in A3/E3. Advanced features like DLP for Teams, Endpoint DLP, and trainable classifiers require A5/E5 or the E5 Compliance add-on.
Google Workspace LicensingEducation Plus / EnterpriseGmail DLP rules and advanced encryption (like Client-Side Encryption) require an Enterprise or Education Plus edition.
Email Encryption ServicePurview Message Encryption (AIP)Included with eligible M365 licensing; verify it is enabled with Get-IRMConfiguration (see procedure). No separate RMS SKU is required.
Administrative RolesCompliance Administrator, Exchange Administrator (Microsoft), or Gmail Administrator (Google)Required to create and manage DLP policies in the respective platforms.

Procedure​

Step 1 - Define Sensitive Data

A successful DLP strategy depends on accurately identifying what counts as sensitive data. Both Microsoft and Google provide predefined detectors and allow for custom definitions.

  • Predefined Sensitive Information Types (SITs): Both platforms offer built-in detectors for common data like U.S. Social Security Number, Credit Card Number, Driver's License Number, and various international identifiers. These use pattern matching, checksums, and keywords to identify data with a given confidence level (low, medium, high). It is best practice to start with these predefined types, as they are maintained by the vendor and cover most regulatory needs.

  • Custom Sensitive Information Types: Universities often have unique identifiers that require protection. For the Texas A&M University System, the UIN (Universal Identification Number) is a key example. You can create a custom SIT to detect the UIN.

    • In Microsoft Purview, navigate to Data Classification > Sensitive info types to create a new SIT. You can define it using a regular expression (e.g., \b\d{9}\b) combined with supporting keywords (like "UIN", "Universal Identification Number") to increase accuracy and reduce false positives.
    • In Google Workspace, you can create custom content detectors in the Admin console (Data protection > Manage detectors) using regular expressions for the same purpose.

  • Sensitivity Labels vs. Content Detection: In Microsoft 365, you can use sensitivity labels (e.g., "Confidential," "Highly Confidential") to classify data. DLP policies can be triggered by these labels, which can be applied by users manually or by an auto-labeling policy. While an auto-labeling policy can also apply encryption, a DLP policy acts in real time as the email is being sent, providing more immediate protection against leaks. This guide prioritizes DLP for send-time enforcement, though using both methods provides defense-in-depth.

Step 2 - Configure Microsoft 365 (Purview) DLP

These steps will create two policies in Exchange Online: one to encrypt emails with PII and another to block highly confidential labeled data.

A. Verify Encryption is Enabled
Before creating a policy that encrypts, ensure Microsoft Purview Message Encryption is active.

  1. Connect to Exchange Online PowerShell with an admin account.
  2. Run Get-IRMConfiguration and check that AzureRMSLicensingEnabled is $True.
  3. If it is not, run the following command to enable it:
    Enable-PurviewMessageEncryption.ps1
    Set-IRMConfiguration -AzureRMSLicensingEnabled $true
  4. Verify that encryption templates are available by running a test.
    Test-EncryptionConfig.ps1
    Test-IRMConfiguration -Sender <your_admin_email@domain.com> -Recipient <your_admin_email@domain.com>
    The output should show a PASS result for all checks, confirming templates like "Encrypt-Only" and "Do Not Forward" are available.

B. Create Policy A: Encrypt External PII Emails

  1. In the Microsoft Purview portal, go to Data Loss Prevention > Policies and click Create policy.
  2. Choose the U.S. Personally Identifiable Information (PII) Data template under the Privacy category.
  3. Name the policy Encrypt External PII Emails.
  4. For Locations, select only Exchange email. Scope it to a test group initially, or All if ready.
  5. Choose to Customize advanced DLP rules.
  6. Edit the default rule. Set the condition to trigger when Content contains SITs like U.S. Social Security Number and Credit Card Number. Set the instance count to 1 or more to catch any occurrence.
  7. Add a second condition: Content is shared with people outside my organization. This ensures the rule only applies to external email.
  8. For the Action, choose Restrict access or encrypt the content. Select the option to Encrypt the email message (using the "Encrypt-Only" template is recommended).
  9. Enable User notifications and customize the Policy Tip to inform the sender: "This email contains sensitive information and will be automatically encrypted to protect the data in transit per university policy."
  10. Do not allow user overrides for this policy to ensure consistent protection.
  11. Set incident report severity to Medium and turn the policy on in Test mode first before switching to Turn it on right away.

C. Create Policy B: Block Highly Confidential Emails

  1. Create another policy, this time starting with the Custom template.
  2. Name it Block Confidential Data Emails (External).
  3. Scope it to the Exchange email location.
  4. Create a new advanced rule with the condition Content contains sensitivity labels and select your Confidential or Highly Confidential labels.
  5. Add the condition Content is shared with people outside my organization.
  6. For the Action, choose to Restrict access or encrypt the content, but this time select the option to Block people outside the organization from receiving the content.
  7. Customize the Policy Tip: "This email is labeled as Confidential and cannot be sent to external recipients per university policy. Please use an approved sharing method or contact IT for assistance."
  8. Save and enable the policy, starting in test mode.
Step 3 - Configure Google Workspace (Gmail) DLP

In Google Workspace, DLP is configured via Data protection rules in the Admin console. The user experience differs from Outlook, as notifications typically occur after the send attempt.

  1. In the Google Admin Console, open Security > Data protection (older tenants may still see Apps > Google Workspace > Gmail > Compliance).
  2. Create a new Data protection rule (or Content compliance rule if using the legacy path).
  3. Give the rule a name, like Quarantine Outbound PII.
  4. Under Email messages to affect, check Outbound.
  5. Add an expression that triggers If ANY of the following match the message.
  6. For the expression, choose Predefined content match. Select detectors like Credit Card Number and US Social Security Number. Set the confidence threshold to High to minimize false positives.
  7. Define the action to take if the conditions are met. The most practical options are:
    • Quarantine message: Safest starting point. Holds the email for admin review, allowing you to check for false positives before rejecting legitimate mail. Select this and choose or create an admin quarantine.
    • Reject message: Blocks the email and sends a bounce-back notice to the sender. Customize the rejection notice: "Email blocked: Sensitive information detected. Per university policy, this data cannot be sent via unencrypted email. Please use an approved secure method."
  8. For this guide, select Quarantine message and configure notifications to be sent to a compliance officer.
  9. Save the rule. It will become active for the Organizational Unit (OU) it was applied to.
Gmail user experience

Unlike Outlook's real-time policy tips that appear before sending, Gmail users are typically notified after they hit send, via a bounce message or quarantine notification. Proactive user education is critical to explain this process and avoid confusion.

Step 4 - Tailor Policies for Different Populations

A one-size-fits-all policy is not ideal in a university environment. Use groups (Microsoft) or Organizational Units (Google) to apply different rules to different populations based on their roles and data handling needs.

  • Students: Policies for students should generally be the most restrictive, as it is rare for a student to have a legitimate need to email sensitive institutional data.

    • Action: Block any detected sensitive data in outbound emails. Do not allow overrides.
    • Implementation: Create a dedicated policy scoped to the "All Students" group/OU with a Block action and a high-severity alert for IT/Security.

  • Staff (HR, Finance, Registrar): These users regularly handle sensitive data as part of their job and may need to share it with external vendors (e.g., benefits providers, auditors).

    • Action: Encrypt by default. Block only for very high volumes of data or when sent to untrusted personal email domains. Allow overrides with a business justification for certain roles, with the override action logged for review.
    • Implementation: Scope a policy to "Staff" groups that uses Encrypt as the primary action. Add exceptions for approved partner domains (e.g., allow sending to @partnerdomain.com).

  • Faculty & Researchers: They handle student data (FERPA) and potentially highly sensitive research data (CUI, HIPAA, IP). They need to collaborate externally but require strong protection.

    • Action: Encrypt by default for PII. Block any data labeled Highly Confidential or matching specific research project identifiers, unless it is being sent to a whitelisted collaborator domain.
    • Implementation: Use a combination of content detection and sensitivity labels. For researchers with specific compliance needs (e.g., CUI for DoD contracts), create a dedicated, highly restrictive policy scoped to their group that enforces encryption and may block sharing to all but explicitly approved domains.

Compliance Alignment​

Implementing DLP with automatic encryption is not just an IT initiative but a core compliance function. These controls provide a technical safeguard to enforce policies and demonstrate due diligence to auditors and regulators.

RegulationRequirementDLP Solution
FERPAPrevents unauthorized disclosure of student education recordsEncrypting emails containing student PII is a reasonable method to protect this data in transit
HIPAASecurity Rule requires protection for electronic PHIEncrypting emails containing health data is a critical safeguard for transmission security
PCI-DSSProhibits sending unprotected credit card numbers via emailDLP policy that detects and blocks or encrypts this data is a direct control
GLBARequires safeguarding financial informationDLP prevents sensitive data from being inadvertently exposed via email
NIST 800-171 / CMMCRequires encryption of CUI during transmissionDLP policy configured to detect and encrypt CUI-labeled data directly addresses this requirement
State Breach LawsMany states include "safe harbor" for encrypted dataProactive encryption can significantly reduce legal and financial risk

The audit logs and incident reports generated by the DLP system serve as crucial evidence of compliance, showing that controls are not only in place but are actively monitoring and protecting data.

Best Practices​

  • Start in Audit/Test Mode: Always run new policies in a test mode first. This allows you to review what the policy would have done without impacting users, helping you identify and fix false positives before enforcement.
  • User Education is Critical: Use clear, helpful Policy Tips. Prepare communication plans to inform users about why emails might be encrypted or blocked. Emphasize that the controls are there to protect both them and the university.
  • Fine-Tune with Thresholds and Exceptions: A rule that is too aggressive will frustrate users. Adjust instance counts (e.g., trigger on 3 SSNs instead of 1) or confidence levels to balance security with usability. Use exceptions for legitimate business workflows, such as allowing encrypted communication with a trusted third-party partner.
  • Integrate with Sensitivity Labels: Encourage users to manually apply sensitivity labels. This complements DLP by allowing users to proactively protect data, and the labels provide persistent protection that stays with files wherever they go.
  • Monitor and Review Regularly: Treat DLP as a continuous process. Schedule quarterly reviews of DLP incident reports to identify trends, discover gaps in your policies, and find opportunities for user training. Keep policies updated as new regulations or data types emerge.
  • Plan for Incident Response: Define a process for handling high-severity alerts. Who is notified when an attempt to send a large volume of PII is blocked? The security team should have a runbook for investigating serious incidents and following up as needed.

Reference & FAQs​

Glossary​

TermDefinition
DLPData Loss Prevention - tools and processes to ensure sensitive data is not lost, misused, or accessed by unauthorized users
SITSensitive Information Type - a pattern-based classifier that detects sensitive information
PIIPersonally Identifiable Information - data that can identify a specific individual
FERPAFamily Educational Rights and Privacy Act - protects privacy of student education records
HIPAAHealth Insurance Portability and Accountability Act - provides data privacy for medical information
UINUniversal Identification Number - unique 9-digit identifier for Texas A&M students and staff
Message EncryptionService that encrypts email messages to prevent unauthorized access

Known Limits​

Platform Differences

Microsoft 365 (Outlook) provides real-time Policy Tips that can warn users before they send a problematic email. Google Workspace (Gmail) typically notifies users after the send attempt is made (via a bounce or quarantine notice). This difference in user experience requires clear communication and training.

Gmail Integration with Purview

Microsoft Purview can ingest Gmail data for archival and eDiscovery purposes using data connectors. However, Purview DLP policies cannot enforce real-time blocking or encryption on emails sent from Gmail. Native Gmail DLP policies must be configured in the Google Admin console for that purpose.