As enterprise organizations continue delivering on Board-level directives to roll out AI and Agentic AI capabilities across their entire user base, CISOs are often contending with keeping the day-to-day security operations well calibrated to address the risks your enterprise is facing. I’ve heard many CISOs say that turning your attention to execute on this Board directive in a responsible way is a large part of what’s keeping you up at night. This is a precarious position to be in. It’s a well-established notion that across sectors, security shops are under-resourced. Gartner’s observation that many organizations “lack a meaningful data security program that includes process, governance and technology” is resonant to several CISOs, particularly to those who feel knowing where to start is a complicated question. Consequently, SecOps teams are a bit scattergun. Let’s first recognize core truths here; you don’t want to roll out enterprise AI at scale without the safety net of a robust Data Security Program. You also don’t want to face rushed rollouts of Microsoft Purview capabilities under AI deployment pressure. The issue is, how does someone in your position go about explaining the prioritized order you should be taking? In this blog series, I’ll provide a practical approach for building a data security program with Microsoft Purview. This approach aims to maximize the investments your organization has made into Microsoft 365 E5 but will be future-proof even if you are sensing there’s a step up to E7 somewhere on the horizon.
Based on my personal experience, I also wanted to provide some guidance on how you want to think about framing each of these priorities to the C-Suite and your Board. This framing can be used as-is, or as a starting point to further tweak so it resonates within your specific context. The main reason I’ve wanted to share this with you is to help ensure you are able to secure leadership buy-in, so that this doesn’t become one more good idea that died on a boardroom whiteboard.
Setting the stage:
Yes, it’s true that Microsoft 365 E5 unlocks the full Microsoft Purview stack, including Microsoft Purview Information Protection, Data Loss Prevention (DLP), Insider Risk Management (IRM), and Data Security Posture Management (DSPM). Procuring is often the easier part of the buy-and-deploy pathway. The steps below are backed by industry-leading recommendations from Gartner, Forrester, and Microsoft itself, on how to determine whether your investment converts into measurable risk reduction at your enterprise organization… or leaves it ‘shelfware’ that all too frequently makes it a prop for more security theatre. Nobody wants that, amirite?!
And now, a confession. My original intent in delivering this content was that it would be a single blog post. It ended up being quite long – even for the style of long-form blogging I prefer. Therefore…
This post is part of a series on Building a Data Security Program with Microsoft Purview. This is post 1 in this series, which will focus on Steps 1, 2, and 3 of this journey.
5 Steps towards building Data Security Programs with Microsoft Purview:
1. Establish a cross-functional Data Security & Governance (DSG) Program:
What this is: with an emphasis on the “cross-functional” part of this step, charter a steering committee consisting of Security, IT, Legal, Privacy, Compliance or Information Management, HR, and business-unit representation. Rather than a committee in name only, this should have a clear vision and measurable goals to direct the work that follows. Run a formal data risk assessment and agree on risk appetite and set outcome metrics before configuring a single policy in Microsoft Purview. There’s an increasing awareness of inappropriate AI usage by employees and one of the instinctual remedies within SecOps is to deploy IRM in isolation, and the time urgency usually means this is done without appropriate inputs. Well as it so happens, Microsoft’s own planning guide calls out this stakeholder list as a prerequisite.
Why this matters: Without a robust DSG program, there is a prevailing risk that the security tooling you are configuring will most likely drift away from business value. The DSG program ensures that business drivers are at the forefront of what’s being used and how the intended outcomes are being measured. No Board cares about vanity metrics like how many policies have been configured in Purview Data Loss Prevention. They care about what sorts of data loss is being monitored for and successfully prevented. It’s important you know what kind of data loss is important to prevent, so your own security shop is not distracting you with vanity metrics that are meaningless to you or those you are ultimately accountable to.
Where Organizations often go wrong: de-emphasizing the importance that this should truly be “cross-functional”, which then causes the deploying of capabilities within Microsoft Purview as a check-the-checkbox audit requirement. What tends to follow is IT teams just strap on their deployment helmets and run off in a direction based on their own idea of what should happen, where, and in what order of priority which is a euphemism for what seemed easiest for them to deploy first. Corporate communications are informed to ‘let users know’ as an eleventh-hour activity. Poor deployments (and frequently) rollbacks ensue.
How to frame this to your Board: Data Security is a business-continuity and regulatory issue, not an IT feature. This committee converts the spend on Microsoft 365 E5 security capabilities into sustainable risk reduction the board can track every quarter.
2. Discover and Classify Data for the Business, not for the Template:
What this is: Conducting a data inventory first, using things like sensitive information types and trainable classifiers. Next, have discussions that result in a concrete decision on an org-wide data classification schema that a sensitivity labeling taxonomy can be aligned with (e.g.: unclassified, confidential, secret, etc.). Begin with a small pilot to deploy default sensitivity labels on files and emails and label recommendations to pilot participants that improves adoption and awareness. Gather feedback and tweak your Organizational Change Management before expanding the deployment org-wide.
Why this matters: According to an analyst at Forrester, “sensitive data discovery and classification is foundational for Zero Trust data security, privacy, and AI governance”. Couldn’t have said it better myself! Gartner also ranks data classification as the pivot point of its data security maturity roadmap.
Where Organizations often go wrong: Deploying Purview DLP before sensitivity labels. Alternatively a rushed sensitivity labels deployment where label taxonomies are copied wholesale from Microsoft’s default templates and applied without regard to how your business units actually classify information. This leaves DLP rules feeling incongruent to the greater whole, and perhaps too loose to make a true difference, or too harsh whereby end users find a way to circumvent, leaving you open to much of the original risk anyway.
How to frame this to your Board: every organization has its own data ‘crown jewels’. You cannot protect what you cannot adequately identify. Classification is the map that makes every downstream security control (DLP, encryption, AI protection, etc.) accurate and defensible.
3. Deploy Data Loss Prevention in Audit-mode first… then Enforcement:
What this is: Deploy Purview Data Loss Prevention (DLP) to provide coverage across emails in Outlook, and files in OneDrive, SharePoint Online, Teams, and endpoints and even third-party apps via Microsoft Defender for Cloud Apps. Start off with audit/simulation mode to baseline false positives. Give yourself some time to finetune configurations, and then progress to block-with-override. Only when you are confident that your configurations are not obstructing legitimate business scenarios (reflected in a reduction of user overrides of the blocks), then you can mature your configurations to a full block as a proactive enforcement.
Why this matters: Security priorities are often seen to be in conflict with productivity priorities, and nowhere is this more true than when business users are prevented from performing an activity they have been assigned a mandate to accomplish. Poorly thought out DLP programs stall because of inefficient program development, and its reactive nature which corrodes confidence. The focus should therefore be on identifying business objectives, and reducing violations to earn stakeholder trust.
Where Organizations often go wrong: hastily moving to blocking/enforcement actions before adequately baselining false positives. Believe me your users will hate you when they couldn’t send a routine email to an external recipient because your poorly calibrated policy wrongly detected sensitive information. Hate is a strong emotion that you can perhaps stand your ground on. However, what if that user who hates you is your CEO, because that routine email did not in fact contain any sensitive information, and the external recipient in this case is a Board member? Ouch!How to frame this to your Board: DLP is a powerful tool that helps prevent the accidental or malicious leaking of sensitive corporate data to unauthorized parties, when tuned properly. Tuning it properly is what ensures it’s not blocking legitimate business activity that could negatively impact revenue or operational costs.
Thanks for reading this part 1, and stay tuned for Part 2 that’s coming up! Please feel free to reach out if you’d like to discuss the practical next steps you can take… or if you have a question and just want to chat more!
