The Microsoft Purview Surface: Where the Controls Actually Live

Purview is not one product. It is roughly a dozen, assembled over a decade, renamed three times, and presented behind a single left-hand menu that groups them by the team that built them rather than by anything you would recognise as a job.

The map is drawn by the sellers

The single most useful thing to understand on day one is that the menu is not a workflow. It is a price list.

Each item on it was a product, or an acquisition, or a compliance feature, and the grouping reflects how Microsoft packages and licenses them. That is a legitimate way to organize a portal and it is a terrible way to learn a job, because the work cuts across the menu constantly. Classifying a contract touches Information Protection. Stopping it leaving touches Data Loss Prevention. Keeping it seven years touches Data Lifecycle Management. Finding out who moved it touches Audit. Those are four menu items and one task.

So the orientation that matters is not memorising the menu. It is knowing which few things do the work, and which names are describing a package rather than a capability.

Three addresses, one product, a decade of renames

If you inherit a runbook, or read a blog post, or follow a Microsoft Learn link from a search result, you will land in a portal that no longer exists under a name nobody uses. It is worth knowing the lineage, because the artifacts do not move when the branding does.

This was the Office 365 Security and Compliance Center. Then it split, and the compliance half became the Microsoft 365 compliance center at compliance.microsoft.com. Then it was rebranded Microsoft Purview and moved to purview.microsoft.com, where it now lives alongside a redesigned experience that is still arriving in pieces. Each move kept the underlying objects intact and changed every path in every document written before it.

The practical consequences are three. Older documentation is often still correct about the mechanism and wrong about the route. Your organization's existing runbooks, if it has any, are probably written against a portal that redirects. And the PowerShell module is still called Security and Compliance PowerShell, because the cmdlets never got the memo, which is a small mercy: New-DlpSensitiveInformationType has meant the same thing across all three brands.

The two ways in

Everything in this course can be done in the portal. Not everything in this course can be done well in the portal, and the split is worth knowing before you need it.

The portal is where you learn. It shows you the shape of an object, it validates as you type, and it will not let you build something structurally impossible. For a first classifier, a first label, a first policy, it is the right instrument and this course uses it heavily, because Purview is a portal-driven product and pretending otherwise teaches you a job nobody has.

PowerShell is where you operate. It is the only way to script anything, the only way to review configuration in bulk, and occasionally the only way to do a thing at all: this course will show you a Microsoft page that documents a portal path for creating a document fingerprint and then states, two paragraphs down, that fingerprints can currently only be created in Security and Compliance PowerShell. Both statements are live. Neither is a typo.

You do not need to be fluent. You need to be able to read a cmdlet and understand what it asserts, because a cmdlet is often the clearest specification of an object that exists. When this course shows you PowerShell it is usually because the command says the thing more precisely than the screen does.

The names that mislead

Four of them cost people real time, so they are worth knowing before you go looking.

Information Protection sounds like the whole discipline and is one part of it: deciding what content is, and marking it. Classifiers live here. Labels live here. It does not stop anything leaving.

Data Lifecycle Management and Records Management are the same machinery at two levels of formality. Retention labels are configured in one and, if the label declares something a record, it becomes immutable and lives in the other. They are one topic and Module 8 treats them as one.

Data Loss Prevention is the only name on the menu that says what it does, and even that misleads slightly, because it is not one thing: DLP for the cloud services and endpoint DLP on devices are configured in the same place, share a policy structure, and behave differently enough that this course gives them a module each.

DSPM and DSPM for AI are the newest and the most confusing, because they are not controls at all. They are reporting surfaces that read what your other controls already know. DSPM for AI is where you find out that Copilot has been answering questions using documents nobody labelled, which is Module 11, and it is worth knowing early that nothing there enforces anything.

Microsoft Purview itself is also the name of a completely separate data-governance product for Azure data estates, with a Data Map and a catalogue, aimed at data engineers rather than at you. If you search for Purview documentation and land in something about scanning Azure SQL lineage, you are in the right brand and the wrong product.

What you will actually be in

Strip it back and this course lives in four places.

Classifiers, under Information Protection, where you build the things that decide what content is. You will spend more time here than anywhere else, because everything downstream is a consumer of it.

Sensitivity labels and their policies, also under Information Protection, where the decision becomes a mark that travels with the file.

Policies, under Data Loss Prevention and its endpoint settings, where the mark becomes an action, and where you will spend your most nervous afternoon in the course rolling one out.

And the explorers, which are the only screens in the product that tell you the truth about your own tenant. Two of them show what your classifiers matched, at rest, right now. A third shows what happened to it. Almost nobody opens them before writing policy, and Module 2 argues that this is the single cheapest mistake to stop making.

Everything else on that menu is either a consumer of those four, a report about them, or a different product.

The asymmetry in that list is worth noticing now, because it shapes the whole course. Three of the four are places you configure something and one is a place you find out. Almost every failure in this discipline is a configuration that looked right and was never checked against the fourth, and almost every deployment allocates its time in exactly that ratio, backwards.

What the portal will not show you

One more thing about this surface, and it is the one that catches experienced administrators hardest.

The portal shows you configuration. It does not show you consequence. You can look at a DLP policy and read every condition in it, and nothing on that screen tells you how many people it would stop tomorrow. You can open a sensitive information type and read its pattern, and nothing tells you it matches four thousand part numbers. You can see that a classifier exists and not that it has never fired.

That is not an oversight, it is a property of the model: configuration is a statement about intent and consequence is a fact about your estate, and the product knows the first perfectly and the second only if you ask. The explorers are where you ask. Simulation mode, in Module 6, is where you ask about a policy before it can hurt anybody.

Which produces the most common shape of failure in this discipline, and it is not a mistake anybody would call careless. Somebody configures something correctly, the screen agrees it is correct, and the thing is wrong about the organization in a way the screen has no opinion about. The portal will confirm your configuration all day. It will never volunteer that your configuration is a false statement about your company.

The portal moves, and the docs lag

One practical warning, because it will happen to you in week one and it is not your fault.

The portal is under active redesign. Menu paths in this course are correct at the time of writing and some will move. More awkwardly, Microsoft's own documentation is not always internally consistent: this course will show you a page that documents a portal path and then states, two paragraphs down, that the thing can only be done in PowerShell. Both statements ship. Neither is a typo.

The defence is to learn the object rather than the route. A sensitivity information type is a definition with a primary element, supporting evidence, proximity and a confidence level. That is true regardless of which blade it is behind this quarter, and if you know it you can find it. If you learned a click path, you learned something with an expiry date.

Section 0.3 covers how this course is built, why the module order is not negotiable, and what the thing you just met in 0.1 was.