This post is part of a series on Building a Data Security Program with Microsoft Purview. This is post 2 in this series, which will focus on steps 4 & 5 in this journey.
5 Steps towards building Data Security Programs with Microsoft Purview:
1. Establish a cross-functional Data Security & Governance (DSG) Program:
2. Discover and Classify Data for the Business, not for the Template:
3. Deploy Data Loss Prevention in Audit-mode first… then Enforcement:
If you haven’t already, check out Part 1 in this blog series, that focuses on the first 3 steps in this journey. The context I’ve provided there will help you better understand the steps I’m covering in this part 2. Let’s continue!
4. Operationalize Insider Risk Management (with privacy by design):
What this is: Enable Microsoft Purview Insider Risk Management (IRM) policy templates (e.g.: data theft by departing users, data leaks, security policy violations) using the Microsoft 365 HR connector, keep pseudonymization on by default, and pilot with a small set of business users before expanding your rollout.
Why this matters: Insider incidents are the least visible risks and Microsoft’s own guidance is that IRM should be positioned as a program, rather than a product to be deployed in isolation or without broad consultation within your organization.
Where Organizations often go wrong: When IRM is seen as a product rather than a program that in practice is multidisciplinary across IT, Compliance, Privacy, Security, HR, and Legal teams. These are all important stakeholders and it’s critical to ensure proper alignment, particularly as you will notice over time your insider risks tend to evolve.
How to frame this to your Board: sensitive information and intellectual property are corporate assets that need protecting, and IRM achieves this while also preserving employee trust at the same time. This shows regulators and the Board that your organization can detect insider risks and malicious intent without becoming a surveillance state.
5. Operationalize Data Security Posture Management to extend security to Copilot (and other GenAI):
What this is: Data Security Posture Management (DSPM) provides a centralized view of your organization’s data security posture by bringing together insights from multiple Microsoft Purview capabilities such as Information Protection (sensitivity labels), DLP and IRM that you have set up to address foundational data security. DSPM further extends your line of sight on persistent risks within your data landscape, in particular, those that relate to interactions with GenAI tools like Microsoft 365 Copilot (and third-party GenAI). Operationalizing DSPM establishes expectations on a periodic review (ideally monthly) of the recommendations.
Why this matters: Gartner’s 2026 Market Guide positions DSPM as “a cornerstone of a modern data security program” and identifies AI as “the key factor driving DSPM adoption”. Without DSPM, there is an operational tendency for other Microsoft Purview dashboards to remain siloed.
Where Organizations often go wrong: DSPM makes it seductively easy to action the templated recommendations presented to your Purview admins within the DSPM dashboard, to rapidly configure the DLP or IRM policies based on those recommended actions. These ‘one-click’ policies short circuit any Organizational Change Management that should be conducted, and is one of the main issues to cause significant embarrassment to SecOps teams that are forced to rollback when they were just trying to be helpful. The moral of the story here is, just because you can, doesn’t mean you should! That point of caution aside, those recommendations are helpful, and should be actioned within the deployment readiness framework that your Data Security & Governance program will have formalized by the time your organization gets to this stage of your journey.
How to frame this to your Board: DSPM is the single pane that drives holistic visibility for the Board, by connecting fragmented control activity into a portfolio view of data risk exposure, and provides ongoing value realization as AI usage expands across the organization.
A personal observation I want to share:
I have been helping technology leaders make better use of Microsoft Purview as a critical component powering their Data Security Programs for several years now. This experience has allowed me to observe a root cause of failure across the five steps described in this blog post series. Essentially, it comes down to viewing Microsoft Purview as a technology deployment that’s owned by IT, rather than a transformation vector to significantly improve on your Data Security outcomes.
The organizations that are most successful at this, invest as much effort in building up the capacity as they do in configuring the tech. What do I mean by “capacity”? This is the people and process components of successful transformations (governance, operational processes, aligning stakeholders through collaborative engagement, and continuous refinement, etc.). Configuring the tech is the easy part. It’s also human nature that tech-minded individuals tend to rush to deploy. Configuring tech for people that traditionally look at this as a simple matter of configuring the right scopes and conditions – is unfortunately – also why this ‘configure and continue’ mentality produces so much misplaced confidence that things are in good working order.
The toolset is supposed to come into the conversation at the appropriate time, and frequently I see the configuration talk puts the cart before the horse. The real benefit here is when you can go beyond security theatre and produce security outcomes that matter. Failing to do so is often why some organizations form the opinion that there’s a better tool out there for them. To what degree that’s true, is entirely subjective. What remains objectively true however, is even those other tools are kneecapped from an outcomes standpoint without the capacity investments into your people and your processes mentioned above.
An actionable next step:
If this forward pathway feels right and you want to take some concrete actions to move forward, the reality is you’re probably going to seek investment commitments beyond just the subscription fees for Microsoft 365 E5. The steps I’ve described in this blog series will require an investment of human capital. In the initial phase that probably means a business analysis and project management capacity, but over the medium to long term it implies commitments of staffing to steer the Data Security & Governance (DSG) Program. In my opinion this is essential to help achieve security outcomes as the risk horizon evolves for your organization. Naturally this begs the obvious question on how are you going to “sell this” to your C-Suite colleagues and to your Board? A single narrative like this may help:
Our corporate data is a strategic asset. Steered and overseen by a Data Security & Governance committee, we will stand up a Data Security Program whose goals are to ensure we understand, protect, and govern our corporate data, monitor the human and agentic risk around the data, and continuously measure and improve the organization’s data security posture.
Together, these outcomes reduce the likelihood of material data breaches and protect intellectual property, strengthen regulatory resilience, enable responsible AI adoption, and provide leadership with a clear line of sight into current and emerging enterprise data risks we face.
I hope this 2-part series on setting up a Data Security Program using Microsoft Purview has been valuable for you as you chart your path forward.
Thanks for reading, and please 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!
