From Novice to Ninja: a new CISOs guide to DLP

Congratulations, CISO! 🎉 Great job in landing your new role, where protecting sensitive data isn’t just a job—it’s a daily tightrope walk over a pit of cyber threats, compliance demands, and evolving technology.

Now that you’re at the steering wheel, your inbox is probably overflowing with security concerns, regulatory requirements, and a few “fun” audit emails. Don’t worry, you’re in good company. This guide is here to give you actionable steps to set up your Data Loss Prevention (DLP) strategy, ensuring you don’t just survive in this role—you thrive.

So, what does being a CISO mean? Well, you’re now the go-to person when sensitive data sneaks out, malicious insiders get a bit too curious, or someone clicks that suspicious link promising free money from an unknown relative in Timbuktu. No pressure, right? But here’s the deal: inaction is risk. Delaying or overlooking the core elements of a solid DLP strategy could lead to breaches that cost more than your next cybersecurity budget.

To make your journey smoother, I’ve prepared a handy worksheet that you can use right now to take action on your Data Loss Prevention strategy. These aren’t just checkboxes—these are critical steps to lock down your organization’s data and avoid waking up to a breach nightmare.

You can Download the worksheet below.

Here’s what you can expect see inside:

1. Classifying Data and Why It’s Important

Why it matters: Not all data is created equal. By classifying your data, you can prioritize resources and security measures where they’re needed most. Would you protect the company picnic plan with the same force as your customers’ financial information? (Spoiler: probably not!)

Example:

  • High-risk data: Customer credit card details, proprietary code, or confidential HR files—things you’d never want to see in the wrong hands.
  • Medium-risk data: Internal meeting notes, marketing strategies—sensitive, but not catastrophic if leaked.
  • Low-risk data: Public reports, customer FAQs—this is the stuff you’d share at a conference.

Take Action Today: Review your organization’s data and start tagging it by risk level. Ask yourself, “What would happen if this data got out?” and use that to guide your classification efforts

2. Why and How to Identify Sensitive Data

Why it matters: You can’t protect what you don’t know exists. Sensitive data is often hidden across different platforms—sometimes even in the most unexpected places (like a random email attachment or NTFS file shares). Identifying it is the first step to ensuring it stays secure.

Example:

  • Sensitive Data: Personally Identifiable Information (PII) like social security numbers or health records, intellectual property (IP), and anything that’s subject to regulations like GDPR or HIPAA.
  • Surprise Discovery: Finding a list of client emails attached to a forgotten project buried in a shared folder.

Take Action Today: Use a discovery tool or audit your data manually. Start with cloud storage, email servers, and shared folders. Look for data that could lead to a privacy violation or financial loss if exposed.

3. Developing a Data Handling Policy

Why it matters: A solid data handling policy is the foundation of your DLP strategy. Without clear rules in place, sensitive information can slip through the cracks, exposing your organization to unnecessary risk. Your data handling policy ensures everyone—from top execs to interns—understands the dos and don’ts of handling sensitive information.

Example:

  • Clear Guidelines: For high-risk data like financial information, the policy might mandate encryption during transfer and restricted access to authorized personnel only.
  • Real-Life Scenario: Imagine your marketing team accidentally sharing a file with customer details over an unsecured network. A proper data handling policy would prevent this by enforcing secure file transfer practices.

Take Action Today: Draft a policy that covers how different types of data (high, medium, low risk) should be handled. It should specify everything from encryption requirements to access control and data retention periods. Involve key stakeholders (Legal, IT, HR) to ensure all bases are covered.

Now that you know the key steps to securing your organization’s data, it’s time to plan it out, partner with your internal stakeholders, and take action. DLP isn’t a one-person job—it’s a team effort that involves collaboration across IT, Legal, HR, and beyond. The risks of inaction are far too high, so don’t wait until something goes wrong. Proactively implementing these best practices today will not only protect your data but also strengthen your leadership as a new CISO.

Enhance your DLP to tackle Shadow AI

Technology is necessary. But it’s not sufficient. You can buy all the tools in the world, but if you don’t have a strategy, you’ll just have expensive tools that don’t work together.

The organisations that will win aren’t the ones that block AI. They’re the ones that govern it. And that requires a framework, a way of thinking about the problem that goes beyond technology.

The Four Pillars of AI-Ready DLP Strategy

Pillar 1: Context-Aware DLP – Monitor What’s Actually Leaving

Traditional DLP is blind to the most dangerous channels: email, teams and then the browser. When an employee copies proprietary code into ChatGPT or pastes a financial forecast into Claude, your legacy DLP sees nothing. The data never touches your network. It never hits your email gateway.

Context-aware DLP changes this. It monitors what employees copy and paste into AI tools in real time, before the data reaches external LLMs. But it’s smarter than simple blocking as it understands context.

What this means:

  • Real-time prompt inspection: Detect when sensitive data (source code, customer records, financial projections, API keys) is about to be pasted into ChatGPT, Claude, Gemini, or Copilot
  • Semantic analysis, not regex: Understand that a paragraph describing an M&A deal is confidential, even if it doesn’t match a pattern
  • Graduated responses: Allow, warn, or block based on data type, user role, and destination AI tool
  • User coaching, not just blocking: When someone tries to paste customer data into ChatGPT Free, warn them and redirect them to an approved alternative.

Implementation strategy: Start with your highest-risk data types (source code, financial data, legal documents, customer records) and your most-used AI tools (ChatGPT, Claude, Copilot). Deploy browser-based DLP agents or extensions that monitor copy-paste activity without requiring heavy endpoint agents.

Tools to evaluate: Microsoft Purview (integrated with M365 Copilot), ForcePoint DLP

Pillar 2: Use Enterprise AI – Give employees a secure option

The fundamental problem with Shadow AI is that employees use free tools because they’re better, faster, and easier than approved alternatives. Block ChatGPT Free without providing an enterprise alternative, and you’ve just created a game of whack-a-mole. Employees will find the next tool.

The solution is not to block AI. It’s to provide better AI.

Enterprise AI tools like Microsoft 365 Copilot and Claude Enterprise offer:

  • Data residency and compliance: Your data stays in your environment or in compliant data centres
  • No model training: Your conversations don’t train public models
  • Audit trails: Complete visibility into what was asked and what was answered
  • Governance controls: Admins can set policies on what data can be used, which users can access the tool, and what outputs are allowed
  • Better performance: Higher rate limits, priority processing, and custom fine-tuning

Implementation strategy:

  1. Assess your user base: Which teams use AI most? (Engineering, legal, finance, marketing)
  2. Pilot with high-value teams: Start with teams handling sensitive data or high-risk workflows
  3. Make it genuinely better: Higher limits, faster responses, better features than free alternatives
  4. Communicate clearly: Tell employees why you’re providing this tool and what it protects
  5. Measure adoption: Track migration from free tools to enterprise tools

The business case: A developer using ChatGPT Free might paste proprietary code. A developer using Claude Enterprise with audit trails and data residency guarantees won’t. The cost of one IP leak often exceeds the annual cost of enterprise AI for your entire engineering team.

Pillar 3: Data Handling Policies – Guide, Don’t Prescribe

Most data handling policies are written like laws: “AI is prohibited except in the following approved cases.” This approach fails because:

  • Employees don’t read them
  • They’re too rigid to adapt to new tools
  • They create a culture of workarounds, not responsibility

Better approach: Guide with principles, not rules.

Your updated data handling policy should:

Define what data can go where:

  • Green zone (approved for AI): General business questions, non-sensitive research, learning and development
  • Yellow zone (requires approval): Customer data, financial projections, internal strategy documents
  • Red zone (never): Source code with credentials, unreleased product roadmaps, M&A materials, personal employee data

Specify which tools are approved for which data:

  • Approved for all data: Microsoft 365 Copilot, Claude Enterprise (with audit trails)
  • Approved for non-sensitive data only: ChatGPT Plus (with user responsibility)
  • Not approved: ChatGPT Free, Gemini Free, any tool without audit trails or data residency guarantees

Establish clear consequences:

  • First violation: Coaching and education
  • Repeated violations: Escalation to manager and security team
  • Malicious violations: Disciplinary action

Pillar 4: DSPM for AI – Visibility Into What’s Already Exposed

By the time you deploy context-aware DLP and enterprise AI, some data has already leaked. Employees have already pasted code into ChatGPT. Contractors have already uploaded files to personal cloud storage. Former employees still have access to sensitive systems.

Data Security Posture Management (DSPM) for AI gives you visibility into this exposure.

DSPM answers questions that DLP cannot:

  • Which sensitive data is accessible to which users?
  • Which data has been shared externally (intentionally or not)?
  • Which AI tools have already received sensitive data?
  • Which users have excessive access to sensitive data?
  • Which data is at highest risk of exposure?

Implementation approach:

  1. Discover what you have: Scan your data repositories (cloud storage, databases, collaboration tools, SaaS applications) to identify sensitive data
  2. Classify automatically: Use AI-powered classification to label data by sensitivity (PII, financial data, source code, legal documents, customer data)
  3. Map access: Understand who can access what data and why
  4. Identify exposure: Find data that’s been shared externally, stored in personal accounts, or accessible to contractors
  5. Prioritize remediation: Focus on highest-risk exposure first (e.g., customer data shared with external vendors, source code in personal cloud storage)

Tools to evaluate: Concentric AI (semantic intelligence for unstructured data), Nightfall AI (data lineage and exfiltration prevention), Microsoft Purview (integrated with Microsoft ecosystem).

Putting It Together: A 90-Day Implementation Roadmap

Month 1: Foundation

  • Audit current DLP and insider risk tools: What gaps exist?
  • Identify highest-risk data types: Where is your crown-jewel data?
  • Assess AI tool usage: Which tools are employees using? Which data are they pasting?
  • Update data handling policies: Draft new guidance on AI use
  • Pilot context-aware DLP: Deploy to one high-risk team (engineering, finance, legal)

Month 2: Enablement

  • Deploy enterprise AI tools: Pilot with teams identified in Month 1
  • Implement DSPM: Scan your data repositories and identify exposure
  • Train managers: Help them understand the new policies and their role in enforcement
  • Launch user coaching: When violations occur, educate rather than punish
  • Measure baseline: How much sensitive data is currently being pasted into free AI tools?

Month 3: Scale and Optimize

  • Expand context-aware DLP: Roll out to all users
  • Expand enterprise AI: Make it available to all teams
  • Remediate high-risk exposure: Address findings from DSPM
  • Refine policies: Based on real-world usage, adjust guidance
  • Measure impact: How much has sensitive data exposure to free AI tools decreased?

The Governance Mindset

The organisations that will win in the Shadow AI era aren’t the ones with the most tools. They’re the ones with the clearest strategy.

That strategy rests on a simple principle: Assume employees will use AI. Design controls that let them use it safely.

This means:

  • Visibility first: Know what data is where and who can access it
  • Enablement second: Provide approved tools that are better than free alternatives
  • Guidance third: Tell employees how to use AI responsibly
  • Enforcement last: Only block when necessary; coach when possible

Technology enables this strategy, but strategy drives technology. Without a clear framework, you’ll deploy tools that don’t talk to each other, policies that contradict each other, and controls that frustrate employees without protecting data.

With a clear framework, you transform Shadow AI from a crisis into a managed risk.

Your DLP strategy is not ready for Shadow AI

RSAC 2026 was packed with announcements But if you listened carefully (like really carefully) one theme cut through everything else. Not zero trust. Not incident response. Not even quantum-resistant cryptography.

Shadow AI.

Every major vendor had something to say about it. Every security leader the Kroll team spoke to was worried about it. And every organisation in the room was already dealing with it, whether they knew it or not. The conversation wasn’t theoretical. It was urgent. It was practical. And it was happening everywhere.

This isn’t speculation. This is what the industry is converging on. My Kroll team was there. I’ve been tracking the key vendor announcements and speaker sessions. Here’s some of what’s heard: 

It’s Already Inside.

The numbers hit you first. And they’re staggering.

MetricFinding
AI Tools in Use665 different applications
Data Exposures579,000+ incidents
Enterprise AI Prompts Analysed22 million

Source: Harmonic Security’s analysis of 22 million enterprise AI prompts,

The shift from Shadow IT to Shadow AI is subtle but critical. Previously, Shadow IT was about unsanctioned software (ex. Dropbox instead of SharePoint, Slack instead of Teams.) You could see it. You could block it. You could audit it. It was visible.

Shadow AI is different. It’s not a tool your employees are installing on their machines. It’s a service they’re accessing through a browser. Free-tier ChatGPT. Claude. Gemini. Even Microsoft’s own free Copilot. They’re logging in from their personal accounts, pasting data into a chat window, and getting answers. No VPN. No proxy. No conditional access. No audit trail. No visibility.

The thing that matters the most, is that their use of it is not malicious. It’s not rogue employees trying to steal data or sabotage the company. It’s people trying to get their jobs done faster. A developer asking ChatGPT to review code. A project manager asking Claude to summarise a contract. A financial analyst asking Copilot to model a scenario. A customer service representative asking an AI to draft a response. These are normal, everyday tasks. The problem is that they’re happening outside your security perimeter.

As one CISO from 1Password put it at RSAC:

“People aren’t trying to break your security. They’re trying to do their job.” And that’s exactly the problem. The motivation is innocent. The risk is real.

Key Point: Shadow AI isn’t a future risk. The numbers show it’s already in your organisation, right now. And it’s growing

What is actually leaving the door

Not all data is equal. And not all Shadow AI exposure is the same. Some of it is harmless. Some of it is problematic.

The data walking out the door isn’t random. It’s the stuff that matters most to your organisation:

  • Source code and intellectual property. Thse are the crown jewels of software companies.
  • Legal documents and contracts. Things that contains sensitive terms, pricing, obligations. etc.
  • Financial projections and budgets. Operational plans, Business plans and more.
  • Customer records and personally identifiable information (PII). Most of of which are regulatory liability especially here in Europe where GDPR penalties can break an company.
  • Strategic plans and board materials.
  • API keys and credentials. Things that malicious actors will give direct access to your systems.

There six (6) applications are driving most of the exposure. You can probably guess which ones: ChatGPT, Claude, Gemini, Copilot, and a handful of others. The concentration is so high that if you could control just those six tools, you’d eliminate the vast majority of your Shadow AI risk.

But here’s the problem that keeps security leaders awake at night: most of this is happening through personal accounts. Not corporate accounts. Not managed devices. Personal accounts.

Free-tier ChatGPT. A Gmail account. A personal laptop. No SSO. No conditional access. No multi-factor authentication. No audit trail. No visibility.

And (this is the part that should genuinely concern you) OpenAI and other vendors use your data to train their models (especially if you are using the Free one). Your source code. Your financial data. Your customer information. It’s all feeding the next version of the model. It’s all being used to make the AI smarter. And you have no control over it.

Remember kids: If you are not paying for the product, You are the Product.

Key Point: It’s not random data. It’s your most sensitive IP and it’s going through personal accounts with zero visibility or control.

The Agent Problem (Shadow AI 2.0)

If Shadow AI 1.0 was about employees pasting data into ChatGPT, Shadow AI 2.0 is about agents doing it for them. Automatically. Without asking. Without thinking. Without a human in the loop.

And that’s a fundamentally different problem.

An agent isn’t a chatbot. It’s not a tool you interact with. It’s a piece of software that can take actions. It can read your emails. It can access your files. It can make API calls. It can execute code. It can send messages. It can modify data. And it can do all of this without a human pressing a button. Without a human approving the action. Without a human even knowing it happened.

At RSAC, we heard about real incidents. Not hypothetical scenarios. Real things that have already happened:

  • GitHub MCP agents rewriting their own code to bypass security controls
  • Slack AI agents accessing channels they shouldn’t and sharing information
  • Email agents sending messages and making commitments without human approval
  • Autonomous agents exfiltrating data to external systems
  • Agents modifying their own prompts to become more dangerous

Cisco had a keynote at RSAC that nailed it perfectly:

“With chatbots, you worry about the wrong answer. With agents, you worry about the wrong action.” A chatbot gives you bad information. You can ignore it. An agent takes bad action. You can’t undo it.

With autonomous agents, you don’t have seconds. You have the time it takes for the agent to execute. Which could be milliseconds. Which could be before you even know something happened.

Key Point: Agents don’t need a human to make a mistake. They can make mistakes all on their own. And by the time you know about it, it’s too late.

Why Your DLP Isn’t Built for This

Your Data Loss Prevention (DLP) system is probably doing a decent job (keyword: probably). It’s catching files being emailed to personal accounts. It’s blocking USB drives. It’s monitoring file shares. It’s preventing copy-paste to cloud storage. It’s working hard to keep data inside your organisation.

But it wasn’t built for this. It wasn’t built for Shadow AI. And it’s starting to show.

Here are five critical gaps that your DLP can’t address:

  • No inspection of conversational streams: DLP looks at files and emails. It doesn’t understand the context of a conversation. You can paste an entire database into ChatGPT, and your DLP won’t see it. It won’t flag it. It won’t block it. Because it’s not a file. It’s a conversation.
  • No intent detection: Is the user asking for a summary, or are they exfiltrating data? Is the agent gathering information for a legitimate task, or is it stealing credentials? DLP can’t tell the difference. It doesn’t understand intent.
  • No non-human identity (NHI) governance: Your DLP was built for humans. Agents are neither human nor traditional service accounts. They operate in a grey zone. They have permissions. They have access. But they’re not governed like users or service accounts.
  • Can’t handle 665 tools: You can’t block every AI tool. Some are sanctioned. Some are essential. Some are used by specific departments. Your DLP can’t distinguish between them at scale. It can’t understand which tools are approved and which aren’t.
  • Can’t detect prompt injection: An attacker can craft a prompt that tricks an agent into revealing sensitive data, bypassing controls, or taking dangerous actions. Your DLP won’t catch it. Because it doesn’t understand prompts.

This isn’t any specific Security vendor takedown. It’s not saying DLP is bad or useless. DLP is still essential. But it’s a reality check. DLP was built for files and humans. Agents are neither. And until your DLP understands agents, it’s going to miss a lot of risk.

Key Point: DLP was built for files and humans. Agents are neither. Your existing tools are blind to this risk.

What was shown in RSA

Here’s what we saw at RSA 2026. These are announcements from major vendors about capabilities that are available now or coming in the next 90 days:

Microsoft

Microsoft made several announcements focused on AI governance and agent control. Read the full details in their Secure Agentic AI End-to-End blog post:

  • Agent 365: A control plane for managing AI agents across your organisation. Think of it as the governance layer for agents—visibility, control, and audit trails.
  • Shadow AI Detection: Built into Entra Internet Access to identify unauthorised AI tool usage. It detects when employees are using unapproved AI tools and reports it.
  • Prompt Injection Protection: Entra Internet Access now detects and blocks prompt injection attacks. This is critical for protecting agents from being tricked into dangerous actions.
  • Purview DLP for Copilot: Extended DLP policies to cover Microsoft 365 Copilot interactions. Your DLP rules now apply to Copilot conversations, not just files.
  • Security Dashboard for AI: Centralised visibility into AI agent activity and risk. One place to see what’s happening with AI across your organisation.
  • Data Security Posture Agent: Automated credential scanning and exposure detection in Purview. An agent that hunts for exposed credentials and sensitive data.

Google Cloud

Google’s approach focuses on agent-specific threats and model security. Details are available in RSAC ’26 Supercharging agentic AI Defense:

  • Agentic SOC: Security operations centre designed specifically for agent-driven threats. Not just monitoring agents—understanding them.
  • Model Armor: Prompt injection mitigation for Gemini and other models. Protects the model itself from being manipulated.
  • AI Protection in Security Command Centre: Threat detection and response for AI-driven attacks. Treats AI threats as a distinct category.
  • Autonomous Agent Threat Research: Mandiant’s research showing autonomous agents rewriting their own code—a new class of threat that didn’t exist before.

Other Key Announcements

  • Astrix: Four-method AI agent discovery architecture for full visibility and control. They’re building the visibility layer that most organisations need.
  • 1Password: Unified Access for governing credentials across humans, agents, and machines. Treating agents as first-class identities that need credential governance.

The pattern is clear: the industry is moving from detection to governance. From blocking to understanding. From reactive to proactive. The vendors aren’t saying “block all AI.” They’re saying “understand your AI, govern it, and use it safely.”

Key Point: The tools are arriving. The question is whether your organisation is ready to use them.


In the next post, I’ll list down what has been highlighted as the way forward.

(click here)


Sources:

How to actually delete data…(in M365)

As I was watching YouTube, I happen to see in my FYP this gem of a skit from SNL: MacGruber: Epstein Files – SNL.

This got me thinking of how one can go about in effectively deleting data that you don’t want other people to see in M365 without resorting to strapping the documents to an explosive. (seriously go watch the skit!)

This article is about that. Some days you build walls. Other days you tear them down.


As Data Defenders, our bread and butter is protection: from applying encryption, access controls, monitoring. But occasionally the job flips. A regulator orders you to delete everything you hold on a data subject. Or someone hits “reply all” on a spreadsheet full of passport numbers. Now you’re not guarding the vault. You’re burning the documents.

The difference between doing this well and doing it badly?

Read the story of Clearview AI, who was told to delete UK facial recognition data and fined ÂŁ7.5 million for failing. And Serco, who was ordered to erase 10 years of unlawfully processed employee biometrics.

Both cases prove the same point: Deletion isn’t the absence of action. It’s a discipline.

Data Spillage and Regulatory Deletion

Data landing where it shouldn’t, it could be that data was sent to wrong recipient, wrong system, wrong country. The clock starts ticking immediately.

But this is not the only scenario where deletion matters. There are two distinct situations that demand the same discipline:

Data Spillage: Sensitive information escapes its boundaries. A spreadsheet of salaries sent to the entire company. Customer records emailed to a personal address.

Regulatory Order: A data protection authority instructs you to erase specific data, often following a breach investigation or unlawful processing finding. This is not optional. The regulator sets the timeline. The penalty for non-compliance is public, financial, and lasting. (see the linked cases for Clearview and Serco above)

Both situations share the same requirement: complete, verifiable, irreversible deletion. Not user deletion. Not admin deletion. Forensic deletion with an audit trail.

This what “deleted” actually means in Microsoft 365:

  • User deletion = item sits in Recycle Bin for 93 days, recoverable by anyone with permissions
  • Admin deletion = item moves to second-stage Recycle Bin, still recoverable
  • Version history = every previous save remains intact, invisible to users but fully restorable

True deletion means stripping every copy, every version, every trace from every location. And doing it fast enough to matter. That is where most organisations fail. Not from lack of intent. From lack of tooling.

The Tools: Microsoft Purview Priority Cleanup

Microsoft 365 offers three ways to delete data. Most people already knows the first two. The third is the one you need.

Option A: Manual deletion. Users delete emails. Admins empty recycle bins. This takes hours, misses version history, and leaves forensic traces everywhere. It’s manual and cumbersome to check.

Option B: eDiscovery search and purge. Faster, scripted, covers Exchange Online. But it stops at 10 items per mailbox on E3 licences. It cannot touch SharePoint or OneDrive files. And it fails silently against retention holds.

Option C: Priority Cleanup. This is the tool built for the job.

Priority Cleanup sits inside Purview Data Lifecycle Management. It uses KQL queries to find content across Exchange Online, SharePoint Online, and OneDrive. It bypasses retention policies and legal holds. It enforces a two-person approval rule. And it leaves an audit trail that satisfies regulators.

The trade-off is time. Priority Cleanup takes up to seven days for full propagation. It requires an E5 licence. And it cannot delete records marked as regulatory records or items locked in active eDiscovery review sets.

Guide: Setup your Priority Cleanup

Here’s the step by step guide to get Priority clean up working. (note that this requires an E5 license*

  • 1: In Microsoft Purview, go to the Data Lifecycle Management solution, select Priority cleanup
  • 2: Create a priority clean up
  • 3: Give it a name and then choose which type of policy to create

Adaptive scopes let you set rules instead of picking individual locations. You might target “all mailboxes in the Finance department” or “all SharePoint sites with ‘Project X’ in the URL.” The policy updates automatically when people join, leave, or sites change. This suits large organisations with frequent movement. To learn more about adaptive scopes, read this: https://learn.microsoft.com/en-us/purview/purview-adaptive-scopes

Static scopes require you to select specific mailboxes, sites, or OneDrive accounts by name. The policy only applies to what you selected. If the situation changes, you must update it manually. This suits known, fixed incidents where precision matters more than flexibility.

For most data spillage responses, my recommendation is to use Static.

  • 4: Choose the location where you want to apply the policy

Note: If you need to run it in Exchange AND SharePoint/OneDrive, you will need to create 2 policies.

  • 5: Select your target location. In this example. I’ve selected 2 users mailboxes that will be in scope of the policy.
  • 6: Use KQL Editor to specify what you are looking for. Pro tip: The more specific your query is the better the outcome.
  • 7: Choose when the content is to be deleted. Pro tip: In most regulatory mandate, it is ASAP.
  • 8: Set your approvers. Manage The Three approvers

Priority Cleanup enforces a two-person rule. The person who creates the policy cannot approve it. You must assign at least one reviewer per stage, and each stage requires specific roles.

Priority Cleanup Admin
Creates and manages policies. Enables or disables the feature. Can approve items in the initial approval stage. This role sits in the Organisation Management group by default. If you create a custom role group, you must add it manually.

Retention Manager
Handles the retention review stage. Checks that deletion aligns with your organisation’s retention schedule. Ensures you are not destroying records that must be kept. Required roles: Retention Management, Data Classification Content Viewer, Data Classification List Viewer, Disposition Management.

eDiscovery Admin
Performs the final legal and compliance review. Confirms no active litigation or investigation would be compromised by deletion. Required roles: Search and Purge, Hold, Review, Data Classification Content Viewer, Data Classification List Viewer, Disposition Management.

Critical point: Assign these roles before you create the policy. If an approver lacks the correct permissions, policy creation fails immediately. You cannot fix this mid-process.

  • 9: Decide how you want to run it. Pro tip: Simulation is a good start. You don’t want to start deleting files without getting some insights first.
  • 10: Tick the box to bypass eDiscovery holds and retention and save settings.

Limitations and Caveats

Priority Cleanup is not a magic eraser.

  • E5 licence required. E3 tenants need the emergency scripts from earlier in this playbook.
  • Up to seven days. Not instant. Plan accordingly.
  • Two-person rule enforced. The creator cannot approve their own policy.
  • Mail-enabled security groups unsupported. Approvers must be individual users with correct roles pre-assigned.
  • Records and review sets are protected. Items marked as regulatory records or held in active eDiscovery review sets will not delete.
  • Teams chat excluded. Separate process required.

Proper data deletion is a skill. It requires the right tools, the right permissions, and the right process. Most importantly, it requires proof, an audit trail showing what was deleted, when, and by whom.

Unlike certain government file releases, where pages arrive heavily redacted, incomplete, or somehow “missing” entirely, Priority Cleanup gives you certainty. No black bars. No gaps. No questions about what happened to the originals.

Just gone.


For the detailed Microsoft Learn article that covers this topic, go over to the following links:

Search and Purge and Priority Clean up Exchange

You can also read-up on the detailed outcome of this solution from my fellow MVPs

Practical365 and the 2 part series for Michev: Priority Clean up – Part 1 & Priority Clean up – Part 2

Protecting Your Data from Geopolitical Threats: A Practical DLP guide.

Here’s how you can use Microsoft Purview’s Data Loss Prevention (DLP) policies to safeguard your information from unauthorised access today.


Important:

As a best practice, always conduct a business impact assessment first. Doing activities 1 and 2 can disrupt legitimate business operations. Ask yourself:

  • Do we have suppliers, partners, or customers in these regions?
  • Are there ongoing projects requiring data exchange that will go to this region?
  • Could this affect our global workforce or remote employees?

1. Block Risky IP Addresses

Start by implementing IP-based restrictions in your DLP policies. Block known IP addresses from high-risk countries to prevent data exfiltration attempts. This creates your first line of defence against unauthorised access from these regions.

You can do this through Defender for Cloud apps: https://learn.microsoft.com/en-us/defender-cloud-apps/ip-tags

2. Restrict File Sharing to Risky Platforms

Many data breaches happen through seemingly innocent file sharing. Block access to popular file-sharing services hosted in these regions:

Here’s a few popular mail and file sharing sites for the 2 countries mentioned in the Microsoft Security Program post.

Russian platforms:

• Yandex.Disk (https://360.yandex.com/disk/)

• Mail.ru Cloud (https://mail.ru/)

Chinese platforms:

• Baidu Pan (https://pan.baidu.com/)

• Tencent Weiyun (https://www.weiyun.com/)

Configure your DLP policies to detect and block uploads to these services automatically.

You can also create a policy to block uploads to a group of domains, so that end-user will NOT be able to uploaded sensitive data through their devices. The can be configured for Purview Endpoint DLP.

3. Monitor Email Communications

Email remains a primary vector for data theft. Block or monitor communications with popular email services from these regions, including Yandex.Mail, Mail.ru, QQ Mail, and 163.com. Your DLP policies can flag or prevent sensitive data from being sent to these domains.

4. Track Your Data’s Journey

Use Purview Information Protection’s Track and Trace feature to maintain visibility over your sensitive documents. This powerful tool shows you:

• Who’s accessing your protected files

• Where they’re being opened

• When access attempts occur

It’s like having a GPS tracker for your most valuable data.

5. Regular Health Checks with SharePoint Advanced Management

Don’t set and forget. Use SharePoint Advanced Management to regularly review:

• Which files are being shared externally

• Who has access to sensitive documents

• Unusual sharing patterns that might indicate compromise.

Think of it as your monthly data health check-up.

Read up on how SharePoint Advance management works here: https://learn.microsoft.com/en-us/sharepoint/advanced-management


Additional tips:

Tip 1 : Start with monitoring and alerting rather than outright blocking. This lets you understand your data flows before implementing restrictions. You can always tighten controls once you’ve mapped legitimate business needs.

Tip 2: Consider creating exceptions for specific, verified business partners rather than blanket country blocks. This gives you granular control whilst maintaining necessary business relationships.

Remember, technology is only as strong as the people using it. Train your team to recognise suspicious requests and understand why these protections matter.

Recommended solutions when Encryption breaks your workflows

If you’ve read my previous blog post on what breaks when you turn on Encryption with sensitivity labels (read it here: When Encryption breaks reality)

Now we will look into how we can remediate it with these practical solutions that works in the real world.

1. Establish clear data storage policies

The recommended solution: Codify in your Information Security Standards that confidential or sensitive data must NOT be stored in third-party systems.

Why this works: By keeping sensitive data within Microsoft 365’s ecosystem, you maintain full control over encryption, access permissions, and audit trails. Microsoft 365 provides native integration between all its services—from SharePoint and OneDrive to Teams and Outlook—ensuring encrypted documents work seamlessly across your organisation’s approved platforms.

Implementation tip: Create a simple classification guide that shows users exactly which data types belong where. Make it clear that “Confidential” and above stays in Microsoft 365, while “General” business information can live elsewhere.

2. Educate users on platform selection

The recommended solution: Train your end-users on what platforms to use, when to use them, and how to properly share confidential data.

Why this works: Most encryption-related issues stem from users not understanding the boundaries of their tools. When people know that encrypted documents won’t work in Dropbox, they’ll choose SharePoint instead.

Implementation tip: Create simple decision trees: “Need to share confidential data externally? Use secure email with expiry dates. Need to collaborate on sensitive documents? Use SharePoint with guest access controls.”

3. Configure service accounts for automation

The recommended solution: For AI and RPA systems (especially in-house built ones), add the named user accounts that run these systems to your encryption policies as approved users.

Why this works: Many automation systems use dedicated service accounts to access files. By explicitly granting these accounts decryption rights, your automated workflows continue functioning while maintaining security controls.

Implementation tip: Create a dedicated security group for automation accounts and include this group in your sensitivity label encryption settings. This makes it easier to manage permissions as you add more automated systems.

4. Implement data minimisation for BI tools

The recommended solution: Third-party BI tools should not access confidential data directly. Instead, use data minimisation, anonymisation, and masking techniques.

What this means: Data minimisation involves only sharing the minimum data necessary for analysis. Data anonymisation removes personally identifiable information, while data masking replaces sensitive values with realistic but fake data that maintains statistical properties.

Why it’s important: This approach protects sensitive information while still enabling business intelligence. Your sales dashboard can show trends and patterns without exposing individual customer details or confidential pricing information.

Implementation tip: Create sanitised data exports specifically for BI tools, removing or masking sensitive fields before the data leaves your secure environment.

5. Standardise PDF readers organisation-wide

The recommended solution: Ensure all devices run the same, supported version of PDF readers using Intune, Group Policy, or IT deployment checklists.

Why this works: Consistency eliminates the “it works on my machine” problem. When everyone uses Adobe Reader/Acrobat version 22 or later, encrypted PDFs open reliably across your organisation.

Implementation tip: Include PDF reader version checks in your device compliance policies. Set up automatic updates where possible, and create a simple verification script for IT teams to run during device setup.

6. Map your external ecosystem

The recommended solution:: Understand what software your vendors, suppliers, and customers are using before sharing encrypted documents.

Why this works: Knowing that your vendor/ partner/ supplier/ law firm uses LibreOffice or your client prefers Google Docs helps you choose the right sharing method upfront, avoiding embarrassing “I can’t open your file” conversations.

Best practice examples:

  • Maintain a simple spreadsheet of key partners and their preferred platforms
  • Ask about software compatibility during vendor onboarding
  • Include system requirements in your standard contract templates
  • Create partner-specific sharing guidelines for your teams

7. Identify critical platform dependencies

The recommended solution: In connection to item 6, note which critical partners use non-Microsoft platforms that could be impacted by encrypted data sharing, then ensure users know the right channels for sensitive data exchange.

Why this works: This builds on your data storage policies (solution 1) and user education (solution 2) by creating specific guidance for high-stakes relationships.

Implementation tip: For critical partners who can’t handle encrypted files, establish secure alternatives like password-protected SharePoint links with expiry dates, or use secure email gateways that work across platforms.


Two additional best practices you shouldn’t miss

8. Create encryption exception processes

The recommended solution: Establish a formal process for temporarily removing encryption when legitimate business needs arise.

Why you need this: Sometimes encrypted documents genuinely need to be shared with systems that can’t handle them. Rather than having users work around security controls, create an approved exception process with proper approvals, time limits, and audit trails.

9. Implement regular compatibility testing

The recommended solution: Schedule quarterly tests of your encryption policies against your actual business workflows.

Why this matters: Software updates, new vendor relationships, and changing business processes can break previously working encryption setups. Regular testing catches these issues before they impact critical business operations.

Implementation tip: Create a simple test matrix covering your most common document types, sharing scenarios, and external platforms. Run through this checklist each quarter and after major system updates.


Remember: The goal isn’t perfect security—it’s effective security that people can actually use.

When Encryption Meets Reality: What Actually Breaks When You Deploy Sensitivity Labels

Microsoft Purview’s sensitivity labels are brilliant for protecting your organisation’s data—until they’re not. While the encryption capabilities of labels like “Highly Confidential” and “Internal Only” provide robust security, they can also create unexpected roadblocks that’ll have your users reaching for the IT helpdesk.

I’ve previously written several blog post on the subject that you can read

Adding to what I’ve already mentioned above, let’s explore the seven other common issues when encryption through sensitivity labels meets the real world.

1. Third-Party Cloud Storage Platforms

What breaks: Dropbox, Adobe Creative Cloud, DocuSign, and similar platforms

Why it happens: Purview treats these as external environments and blocks access to encrypted content. Your beautifully protected document becomes a digital paperweight the moment someone tries to edit it outside the Microsoft 365 ecosystem.

2. AI and RPA Systems

What breaks: Third-party artificial intelligence tools and robotic process automation systems

Why it happens: These systems need to read and process your data, but encryption renders the content unreadable to external AI engines.

The impact: Your automated processing stops working, chatbots can’t access knowledge base documents, and data extraction workflows grind to a halt.

3. Business Intelligence Dashboards

What breaks: Third-party analytics platforms that pull data from encrypted Excel files.

Why it happens: BI tools can’t decrypt and read the underlying data in your spreadsheets, leaving your dashboards empty or displaying errors.

The impact: Executive reports fail to update, sales dashboards show no data, and business intelligence grinds to a halts

4. Legacy Adobe PDF Readers

What breaks: Adobe versions older than Adobe Reader/Acrobat 22

Why it happens: Older Adobe versions lack the necessary components to handle Purview’s encryption standards.

The impact: Users with older software installations can’t open encrypted PDFs, creating accessibility issues across different departments or external partners.

As per Microsoft the version that supports labelling is version 22.003.20258

Adobe’s official documentation is more update and it shows version 23.003.20201.1ec7624

In my personal experience, I’ve seen devices that has Acrobat 21, 19 and 15 not even be able to open up encrypted PDF files.

5. Online PDF Viewers

What breaks: Browser-based PDF viewers (with the exception of Microsoft Edge)  and 3rd party PDF reader apps.

Why it happens: These lightweight PDF viewers (ex. Nitro PDF and PDFgear) don’t have the decryption capabilities required for Purview-protected documents.

The impact: Document previews fail, web-based workflows break. Users using 3rd party reader apps either is not able to open the files or gets an error message when they open an encrypted PDF.

6. Open Source Office Suites

What breaks: LibreOffice, OpenOffice, and similar free alternatives

Why it happens: These applications lack the proprietary decryption libraries needed to handle Microsoft’s encryption.

The impact: Your vendors, remote branch offices or sub-member firms who runs their own IT systems who are using these free office software suddenly can’t access company documents, creating a two-tier system of document access.

I’ve checked the LibreOffice documentation and could not find any mention of support for RMS.

7. Non-Microsoft Productivity Platforms

What breaks: Google Workspace (Docs, Sheets, Slides) and Apple iWork (Pages, Numbers, Keynote)

Why it happens: Competing platforms don’t support Microsoft’s encryption standards—hardly surprising, but often overlooked during planning and deployment.

You can read more about that here:

Does sensitivity label applied docs can be opened in google docs if I add my google account while applying the label?

Also, Google Workspace has a competing data classification scheme: Enable or disable a classification label which is why I think it not likely that Google will make this cross-platform work.

The impact: Cross-platform collaboration becomes impossible, and BYOD policies clash with security requirements.


If you encounter any of these, read part 2 with my recommended actions/ workarounds.

When Purview SIT NAMES gives me headaches

There are now 326 built-in Purview SIT (as of 07-June-2025). The new addition great but Microsoft needs to do a better job in managing how SIT’s documented and communicated to it’s users. Here’s my quick rant on this matter:

Rant 1: The Update list that is stuck in February 2024

    The official Microsoft page (Sensitive information type entity definitions) hasn’t been updated since February 7, 2024. Seriously? 1 year and five months and counting.

    Why it’s frustrating: We’re stuck creating custom SIT because the docs are MIA. (Although, I did win a project out of creating custom SIT – but still!)

    Rant #2: Inconsistencies in SIT naming

    If you compare the SIT names in the In the official documentation against the SIT names that you get in the Purview portal, the names that are used shows up are different.

    You can see in this image below that in the Purview Portal (left), There are items such as Hungarian Social Security number versus Hungary Social security number.

    Some of the names have an added n (Australian instead of Australia), some have the words Identification spelled out instead of ID. There’s a long list of inconsistencies with the naming.

    Admittedly, from within their XML data, the names are correct. So now I ask the product team, why have the names in the documentation title be different then?

    Rant 3: No announcements when new Built-it SITs are out

    There are no announcement to the Purview community when new built-in SITs comes out. I had to manually check every now and then by exporting a list of SIT and comparing it with previous data. Good thing I keep a track of what comes out (read my latest post on the matter: https://www.linkedin.com/pulse/12-new-sits-available-microsoft-purview-victor-wingsing-uzzze/)


    Advise to Purview admins

    Use the Immutable IDs when deploying SITs. Use the following command to export all the ID in a csv file

    Get-DlpSensitiveInformationType | Select-Object Name, Identity | Export-Csv -Path "SIT_Names_and_IDs.csv" -NoTypeInformation
    
    Change the path name to a location where you want the file to be exported.

    Using the Immutable Identity (ID) is better when deploying your Purview policies as names could easily change but these ID (as the name implies) are immutable. This makes your deployment scripts future-proof.

    When to use Purview Information Barriers and Purview DLP

    At first glance, it’s easy to think that if you have Data Loss Prevention (DLP) capabilities where you have policies monitoring internal data flows, then Information Barriers might be an unnecessary extra. After all, DLP diligently scans every email, document, and chat for sensitive content. This is certainly the sentiment that I often get when talking to Cyber Security teams.

    This made me realise 2 things:

    • Microsoft needs to do a better job in marketing/ promoting Purview Information Barriers and
    • Information Barrier has it’s own purpose that DLP cannot do.

    What is Purview Information Barrier

    Microsoft Purview Information Barrier is designed to restrict communication and collaboration between defined groups within an organisation. It’s primary function is to ensure that teams with conflicting interests (think of trading and research groups in financial services) cannot interact with each other. By enforcing internal boundaries, these policies help maintain confidentiality and avoid accidental data leakage between sensitive departments. (ex. Insider Trading)

    With Purview Information Barrier, you can create a policies that can automatically prevent internal teams from communicating with each other through Microsoft teams. These include the following actions:

    In SharePoint and OneDrive, Information Barriers can prevent the following unauthorized collaboration:

    Capabilities shared by Information Barrier in Microsoft Purview DLP

    You probably noticed that the activities above such as “Sharing a file with another” and “Sharing content with another user” can already be done within Microsoft Purview DLP. In essence, yes, that is correct. An admin can setup a policy to BLOCK these file sharing to another user.

    Where DLP falls short and Information Barriers shine

    While Purview DLP is effective at blocking explicit sending or sharing actions, it misses scenarios where access is already granted, which is where Purview Information Barriers come in to the rescue. DLP policies activate when a user actively sends data, but if sensitive information is already shared through granted permissions, the DLP policy remains dormant. For example, if User A (Finance) adds User B (Sales) as a member to the Finance Teams site or SharePoint site, User B gains immediate access to all files without any explicit sharing event, leaving DLP unable to intervene.

    Alternatively, User A could simply send a meeting invite and start a Teams call with screen sharing, bypassing the trigger for DLP.

    Another example, consider a situation where User A uploads a confidential document to a shared folder that automatically grants access to a broader group—here, Information Barriers would prevent unauthorised viewing by restricting access at the source, whereas DLP would not block the document being placed in that shared location.

    Strategy in using BOTH Information Barrier and DLP

    You should view Purview Information Barriers as a key part of your data governance and protection strategy. Relying solely on DLP leaves gaps that Information Barriers can fill—by preventing risky internal interactions before they even happen. Here’s a few actionable items that you can do today:

    • Start by reviewing your organisation’s internal communication flows to identify potential conflicts of interest and assign segmented rules that restrict who can communicate with whom.
    • Work with your Corporate Communications, Human Resources teams and Legal team to identify when and where to apply restrictions between groups of users.
    • Ensure these barriers align with your overall compliance and governance framework, and conduct regular testing to confirm their effectiveness. Then codify these in your data governance policies
    • Finally, train your teams on why these measures are necessary and how to adhere to them.

    Adopting a dual strategy with both DLP and Information Barriers will provide much stronger data protection stance, reducing the chance of inadvertent data leaks from within.

    References:

    Using eReaders with Microsoft Purview Information Protection: A “Remarkable” Case Study

    I’ve already decided what I’ll buy first when I win the lottery and it’s going to be the Remarkable Paper Pro.

    I saw a C-level executive from a client using this device in a meeting and I was immediately impressed by its design. The form factor, the way it writes like paper and the feature where you can just write on-top of a PDF files is just so cool.

    This same client later asked whether implementing sensitivity labelling for PDF files would impact their users as they have many of whom use this device for reading and annotating documents whilst travelling (especially VIPs). So…I decided to investigate.

    Remarkable Paper Pro: Technical Overview

    • Operating System: Codex (custom Linux-based OS)
    • Supported formats: Limited to PDF and ePub
    • Web capabilities: No built-in browser

    File Management Options

    • Email: Direct file sharing via email.
    • Cable transfer: USB connection for importing/exporting
    • Cloud integration: Syncs with personal Google Drive, Dropbox and OneDrive
    • Remarkable custom app: The device can import files through my.remarkable.com

    Device limitation (for Device Management or Data Security)

    • The Operating system (a Linux OS) cannot be onboarded to Microsoft Device Management or Intune
    • The Operating system does not have browser to access the Microsoft authentication portal
    • Users accessing corporate data are limited to do it in 3 general ways (sending it to the device via email, via usb cable, or via syncing the files from their Personal online storage aka Personal Dropbox, OneDrive, Google Drive)
    • Though reMarkable tablet can open, view, and annotate password-protected PDFs. However, this feature is limited to basic password protection and does not extend to Microsoft Purview’s advanced encryption methods, such as Rights Management Services (RMS) or Microsoft Information Protection (MIP).

    Users will encounter issues only when using sensitivity labels with encryption to PDF files. This limitation exists because the Remarkable devices cannot process Microsoft Purview’s advanced encryption methods, lacking both the necessary authentication capabilities and OS support to decrypt protected content.

    The device also has no browser to authenticate with Microsoft services and its custom Linux-based OS (Codex) cannot be integrated with Microsoft’s security ecosystem. This makes it not possible to work on encrypted PDFs.

    However, if PDF files are merely labelled without encryption applied (visual marking only), users will experience no impact whatsoever. These files remain fully accessible and maintain all annotation capabilities, as the labelling exists purely as metadata without affecting the file’s core accessibility.

    Potential Solutions

    Simple approach: Instruct executives to use sensitivity labels without encryption for PDF files they need to access on their Remarkable devices. Implement DLP monitoring to track PDFs sent to personal email addresses, providing security oversight without disrupting workflow.

    Moderate approach (but Costly): Issue corporate Onyx Boox eReaders as an alternative. Onyx Boox is a direct competitor of Remarkable but the key difference is that it runs on Android OS.

    The big benefit: these Android-based (Android 13 OS) devices support Microsoft authentication and can be properly integrated with MDM solutions, allowing full compatibility with encrypted documents.

    It also cost less than the Remarkable Paper Pro, but buying an extra corporate device (even at $499 USD) just for reading PDF files and note taking might not be taken well by your CFO.

    Complex approach: Create a special sensitivity label variant without encryption specifically for executive use cases involving eReaders. This label would maintain visual markings and tracking capabilities while ensuring accessibility on the Remarkable device.

    Supporting your current Remarkable device users today.

    If supporting Remarkable devices for VIP users is necessary, focus on monitoring data flow rather than blocking device use.

    Set up DLP policies that track document transfers to personal emails and cloud services used with Remarkable. Include:

    • Alerts when sensitive documents are transferred
    • Required business justification for transfers
    • Time limits on sensitive document access
    • Targeted security training for Remarkable users
    • Regular reviews of transferred documents
    • Clear audit logs of document movement (once reviews are done)

    This approach balances users device preferences with security needs. Monitoring works better than banning devices that senior staff prefer to use.


    Reference:

    Deep dive in PDF labeling and data protection

    Let’s cut to the chase – PDFs are everywhere in your organisation, and they’re housing your sensitive data. I’m talking about those finalised e-signed contracts, bank statements, and countless other critical documents. While we’re all busy protecting our Office files with fancy security measures, PDFs often slip through the cracks. But here’s the thing – they need the same level of classification and protection as your typical .docx or .xlsx files.

    Here’s the different ways you could label PDF files and simple to follow deployment strategy to enable PDF data classification to your data.

    Labeling PDFs: Three Approaches

    1. Label data natively in Microsoft Office then save it as PDF
    2. Label data using Adobe Acrobat
    3. Label data using the Microsoft Purview In

    Read all the way to the end to see what would happen if you use the “Open in PDF Word” function to an encrypted PDF file.

    Approach 1: Label natively using Microsoft Office then save it as a PDF

    Approach 1: Label Then Save as PDF
    This approach is something you can do now. This method involves applying a sensitivity label directly to an Office document in an application like Microsoft Word, and then saving it as a PDF. Although the label transfers to the PDF, note that if your label incorporates encryption, you must disable the PDF/A option when saving. The resulting PDF will display protection via Purview Information Protection, and its custom properties will indicate the applied label.

    Created a New word document
    Saved as a PDF. The document security shows no security as the label that I used is just a plain label without any encryption.
    Custom values shows the label that I used.

    TAKE NOTE that if your label has ENCRYPTION turned on, then you need to unselect the PDF/A option as you save it.

    The security tab displays that it’s protected by Purview Information Protection.
    The custom properties shows the Privileged/ Protected / Encrypted label used

    Approach 2: Label data using Adobe Acrobat PDF Reader

    Here’s where it gets interesting (and a bit challenging). Most of us view these PDFs through web browsers or PDF readers, with Adobe being the undisputed king of the PDF world. In fact, Adobe’s so dominant that in most organisations I’ve worked with, it’s practically become the default way to handle PDFs – much like how we all say “Google it” instead of “search for it”.

    Unlike your Microsoft Office suite (Word, Excel, PowerPoint, Outlook), Adobe Acrobat doesn’t play nicely with Sensitivity labels. The “solution”? Mucking about in the Windows registry. Yes, you read that right – registry editing. Adobe’s own support documentation lists down the exact steps to do this. Source (Adobe MPIP Support: https://helpx.adobe.com/enterprise/kb/mpip-support-acrobat.html)

    Sure, tweaking the registry is not difficult to do. But imagine rolling this out across thousands of machines in your enterprise. Any experienced IT admin who’s attempted large-scale registry changes will tell you that it’s not fun.

    There is a way to do this via Intune to simplify things. You can read it here from Simon Skotheimsik’s blog: https://skotheimsvik.no/how-to-use-intune-to-enable-sensitivity-labels-on-pdf-files

    Image from: Adobe

    This option is great if you need to add the same Header, Footer or Watermark that you use in your Word, Excel and PowerPoint files to your PDF.

    Approach 3: Label data using the Microsoft Purview Information Protection client

    This client must be installed first to your Windows devices before it would work, you can get it here: https://www.microsoft.com/en-gb/download/details.aspx?id=53018

    Once installed, you now have a tool that can label PDF files and do so much more. There are some limitation to this that you’ll see below. The client application can be launched by right clicking a file and selecting Apply sensitivity label with Microsoft Purview.

    One big benefit of using this client is that you can select multiple files or even an entire folder and mass label them in 1 go. You can use this to MANUALLY label all the files sitting inside a PC or even in a Shared Network Drive.

    The limitation.

    The limitation of using this tool is that you will not be able label data while a PDF is open, there is no label interface inside of Adobe Acrobat, also with this tool cannot apply headers, footers or watermarks. This is by design as the client is an application/ process that applies labels outside of office files. Read it here: https://learn.microsoft.com/en-us/purview/sensitivity-labels-office-apps#when-office-apps-apply-content-marking-and-encryption

    Opening Encrypted PDF in Word?

    This was a question to me by a client: What happens when a user tries to open a PDF in Word?

    Most of us by now know that you can open and edit a PDF in Word (if you don’t know how, please check this: https://support.microsoft.com/en-us/office/opening-pdfs-in-word-1d1d2acc-afa0-46ef-891d-b76bcd83d9c8

    The short answer is that your data is still protected. Here’s what happens when I tried to open an encrypted PDF file in Word.

    Here’s the original PDF file that I have encrypted.

    After using Word to open the PDF. A pop-up prompt asked me select how I want the file to be opened.

    From the Preview window, I can already see that the data is encrypted by Microsoft IRM Services. This gives me confidence that the data is protected.

    Then upon opening the file, all I can see are the hashed data. The text + image in the original file is no longer readable.

    Deployment strategy

    Now that you know how labels works for PDFs. Let’s talk about Deployment.

    Begin with Approach 1 because it leverages familiar tools like Microsoft Word and allows you to secure sensitive PDFs right from the document creation stage. This straightforward step minimises the learning curve and reduces the likelihood of errors, enabling your team to adopt essential security measures immediately.

    Once the basics are in place, invest in user education to ensure proper application and management of sensitivity labels. Training reinforces security compliance and builds a strong foundation, empowering your staff to understand and uphold data protection practices across the organisation.

    After establishing confidence in Approach 1, transition to the Microsoft Purview Information Protection client (Approach 3) to enable scalable, mass labelling across devices and shared drives. This phased progression not only improves operational efficiency and consistency but also sets the stage for introducing more advanced options like registry adjustments (Approach 2) when additional formatting or watermark requirements arise.

    References:

    All Adobe related guides: