No DLP solution on the market, including Microsoft Purview, can guarantee 100% detection of sensitive data exfiltration. You could argue that Exact Data Match (EDM) solves the precision problem, but EDM requires exact input formatting, rigid schema alignment, and constant upkeep. Any drift between your real-world identifiers and the uploaded
my reaction when you're back to read another one of my blogs: Mapping the NIST AI Risk Management Framework onto compliance dashboards, DLP rules, policies, etc. is great; don't get me wrong. But, configuring controls isn't always enough. In this case, we need to
Hello again. Rapid AI adoption is really pushing security teams to prove control effectiveness. NIST’s AI Risk Management Framework (AI RMF) offers guidance around this, but you still need reliable tech to actually apply said guidance. I cobbled together a minimalist infographic that distills the match-up for Data Security
You may have noticed that the “Choose Protection Setting” dropdown is no longer functional when selecting “Encrypt email messages.” It's not a bug, just a shift in how Microsoft handles email encryption. The native DLP action now expects encryption to be managed via Sensitivity Labels, not legacy protection
After publishing my last write-up on the technical limitations of auto-labeling in Exchange Online, I received a ton of messages from security engineers, admins, and compliance leaders asking for the actual solution. So, here it is. Microsoft Purview currently doesn’t scan mailbox content at rest for Sensitive Information Types
Apparently you can change the default colors of your Information Protection Sensitivity Labels! This is great because, well...why burgundy? Using the following PowerShell cmdlets, I decided to change my "Highly Confidential" label to bright red: >Connect-IPPSSession >Set-Label -Identity "Highly Confidential" -AdvancedSettings @{color="
I decided to throw together a quick reference graphic for the high-level differences between E3 and E5 regarding Purview Data Security. Now of course, there is so much more nuance within Purview licensing that we could get into. That aside, these are the ones I get asked about the most.
Over the last few weeks, I’ve been leading a data security engagement for a customer struggling to meet a very specific compliance requirement: identify and delete emails containing U.S. Social Security Numbers (SSNs) already stored in Exchange Online mailboxes. Simple ask, right? Turns out, not so much. The
When Microsoft announced Data Security Investigations (DSI) under the Purview umbrella, it sounded like another incremental compliance feature. Another dashboard. Another portal. Another cost center. Look closer, though: this is a paradigm shift hiding in plain sight. DSI is not just another incident response tool. It quietly marks the first
I'm losing count of how many times I have to answer that question. And, since there are multiple pieces of documentation related to it, it's not a straightforward answer. We'll go through the multiple categories associated with this question, and I'll also
Purview can generate a significant number of false positives from its built-in Sensitive Information Types. Part of my job when running #datasecurity projects is to help resolve these and keep them from popping up again in the future. Some of this may be common sense, and some of it may
One of the most common issues I'm tasked with resolving for my Purview customers is the structure of the DLP Rules within their DLP Policies. You build a rule based on common sense understanding and find that common sense isn't always the right approach. It'