The Honest Limits of Microsoft Purview

Every vendor course tells you what the product does. This section is the other half, and it exists because the fastest way to lose a room is to promise something the product cannot deliver and be found out by an auditor rather than by yourself.

What it cannot see

Start with the hard boundary, because everything else is a preference.

Encrypted content is opaque. A classifier reads text. A file somebody has protected with a password, or encrypted with a tool of their own, contains nothing a classifier can evaluate. The uncomfortable corollary is that the documents most likely to be the ones you care about are disproportionately the ones somebody already protected, and the control cannot see inside them.

Images are not text until you pay for them to be. A photographed whiteboard is pixels. Optical character recognition changes that, at a price per page, and it introduces a reading that can be wrong: a misread digit fails a checksum, and the card in that photograph becomes invisible to a control you are paying for.

Nothing outside the tenant exists. Data on a personal device, in a supplier's mailbox, on a USB stick that left last year, in the SaaS tool a team bought on a card: Purview has no view of any of it. Your controls stop at your boundary, and data does not.

And it cannot read intent. It sees an engineer downloading forty documents. Whether that is a handover or a theft is a fact about the person, not about the event, and no amount of telemetry contains it.

What it cannot stop

The second class is worse, because these are things it can see and cannot prevent.

A screenshot. A user who can read a document can photograph their screen with a phone that your organization does not own. Every control in this course is downstream of that, and there is no answer to it.

Retyping. Somebody reads a contract reference and types it into a personal email. No file moved, no policy fired, and the data left.

A legitimate action that happens to be wrong. The single most common cause of real data loss is not an attacker and not a thief. It is somebody attaching the wrong file, or sharing a link with the wrong scope, or replying-all with a spreadsheet. Every one of those is a permitted action performed by an authorised user for a good reason, and your policy either allows it or breaks the business.

Which is the trade underneath the whole discipline. You are not building a wall. You are raising the effort and the visibility of the ordinary paths, and accepting that a determined person with legitimate access will always win. A control that stops a determined insider stops everybody else too, and you will be asked to remove it by Thursday.

The limits that are choices rather than physics

The three above are properties of the world. There is a fourth class that is simply where Microsoft stopped, and it matters because these move, and because a limit you believe is permanent will shape a design that outlives it.

Some capabilities are behind licence rather than behind engineering. Exact Data Match and trainable classifiers are E5, and there is nothing about them that could not run on E3 except a commercial decision. When you tell a client on E3 that you cannot verify their data against a table, you are describing a contract rather than a constraint, and it is worth being precise about which.

Some are behind a meter. Optical character recognition is not a licence tier at all; it is pay-as-you-go, and your spend is a function of what your organization photographed that day. That is a genuinely different kind of limit from the others: it is not that you cannot, it is that you have to decide how much you want to.

Some are just gaps in the product, and they close. Language coverage, file type support, which workloads a given control reaches: all of that has moved in the last two years and will move again. Which is the argument for learning the mechanism rather than the matrix. A course that taught you the current support table would be teaching you something with a shelf life. If you understand why a trainable classifier is English-only today, you will understand what changes when it is not.

The dangerous version of this is the limit you assume without checking. Somebody tells you in 2024 that a control cannot reach Teams, you design around it, and in 2026 it can and your architecture still has the detour in it. Nobody re-tests a constraint they were told about by a colleague they trust.

What it will never tell you

The third class is the one this course is built around, and it is not a limitation of Purview so much as a property of the discipline.

It will not tell you it is wrong. A classifier that matches nothing looks exactly like a classifier with nothing to find. A policy scoped to a location that no longer holds the data reports zero matches and a healthy status. A retention label applied to the wrong population is indistinguishable, from the dashboard, from one applied to the right one.

It will not tell you what you missed. Every screen in the product reports what it found. There is no screen anywhere that reports what it did not find, because the product does not know, and neither will you unless you bring something that already knows the truth.

And it will not tell you the number means nothing. It will happily report 4,318 matches with the same confidence as 4,318 real cards, because it has no opinion about which it is looking at.

That is not a criticism of the product. No product can do this, because the missing ingredient is not telemetry, it is a definition of what should have been found, and that definition lives in your organization rather than in the tenant. Purview cannot tell you it is wrong for the same reason a ruler cannot tell you that you measured the wrong plank.

The consequence for you is a working habit rather than a feature request. Every number this product gives you needs a second source before it means anything: a sample you adjudicated, a table you already trust, a population you know the size of. This course teaches three ways to get that second source, and the reason it spends so long on them is that they are the only defence against a class of failure the product is structurally unable to report.

Why this section exists in a course you are paying for

It would be commercially simpler to leave this out. Nobody sells a course by listing what the product cannot do, and an orientation module is the last place you would put it if the goal were to get you to Module 1.

It is here because the alternative is worse for you. Every limit above will arrive eventually, and the only variable is whether it arrives as something you already knew or as something you promised. The engineer who told Rachel that Purview would find everything is not going to be forgiven on the grounds that the vendor page implied it. And a course that spent forty hours teaching you controls without telling you where they stop would have produced somebody confident in exactly the way that gets people hurt.

There is also a practical dividend. Knowing the limits is what lets you say no with a reason, and saying no with a reason is most of how a security function keeps its credibility. "We cannot classify whiteboard photographs affordably, here is what it would cost, here is what I suggest instead" is a sentence that ends an argument. "That is not possible" starts one.

A gap and a decision are different things

Everything above is a limit. None of it is a failure, and the distinction is the most useful thing in this section.

A gap is something your programme does not cover and nobody knows. It is discovered by an auditor, or by an incident, and it is discovered as a surprise, which is the worst possible framing for a thing that was always true.

A decision is the same fact, written down, with a name against it and a reason. Northgate does not classify whiteboard photographs, because the population is unbounded and the cost is a rate rather than a number, and Rachel agreed. That is not weaker security. It is the same security, correctly described.

The only difference between the two is a document that somebody wrote before they were asked. This course will ask you to write that document, more than once, and it is the deliverable that separates a programme from a deployment.

Section 0.6 is practical: what you need if you want to build any of this alongside the course.