Information classification with Microsoft Purview – from classification model to actual protection

Summary: Information classification only creates value once the classification changes how information may actually be handled. With Microsoft Purview, an organisation’s classification model can be turned into sensitivity labels for documents, email, Teams and SharePoint. Those labels can in turn govern content marking, encryption, external sharing and DLP. But the technical work should not begin by creating a large number of labels in Microsoft 365. A working implementation starts with the business classification and then builds technical protection that users understand and can work with.

Many organisations already have an information classification model. It may say Public, Internal, Confidential and Highly Confidential, or use other levels. The organisation has discussed confidentiality, integrity and availability. Information owners have been appointed and some sets of information have been classified.

Then the practical question arrives: what should the classification actually mean when someone is working in Word, Outlook, Teams or SharePoint?

This is where Microsoft Purview becomes interesting. Microsoft Purview Information Protection makes it possible to create sensitivity labels that users and Microsoft 365 services can use to classify and protect information. Microsoft describes the label as persistent: it is stored in clear text in the metadata of files and emails, so it stays with the content wherever it is saved, and other systems can read it.

But Purview is not a replacement for information classification. It is the tool that can help an organisation put parts of that classification into practice.

Start with the business, not with the Purview portal

It is tempting to open Microsoft Purview and start creating labels. Public, Internal, Confidential, Highly Confidential. Then configure some colours, watermarks and encryption settings. Technically it is quick.

The harder work is being able to explain to a colleague when a particular label should be chosen. And more importantly: what happens when it is.

Microsoft itself writes that labels are customisable and that you can create categories that fit your organisation’s specific needs, giving examples such as Personal, Public, General, Confidential and Highly Confidential. But it is the organisation’s own information classification that should drive the design, not the other way round.

That is close to how we work with information classification in practice. First the business needs to understand the value of the information and the consequences if it is disclosed, altered incorrectly or unavailable. Then it is decided what protective measures each class actually implies. Our offering follows that order: appointed information owners, classification together with the business, and concrete protective measures per class.

Purview comes after that.

Information classification and Purview are not exactly the same thing

There is an important difference here. A traditional information classification often looks at several protection aspects, usually confidentiality, integrity and availability. Purview sensitivity labels are primarily a tool for identifying the sensitivity of information and governing how content and collaborative workspaces are protected and handled.

That means a classification model cannot always be translated directly, cell by cell, into a label.

Suppose some information has very high availability requirements but relatively low confidentiality requirements. High availability may mean requirements for redundancy, backup, recovery, continuity and monitoring. Those are important security measures. But they are not solved by giving the document a stronger Purview label.

In the same way, high integrity requirements can lead to change control, approval, version management and logging.

Purview therefore becomes part of the protection, not the whole protection model. The connection is strongest where the classification is turned into rules for access, sharing, encryption and data loss prevention.

From class to sensitivity label

Say that after its classification work the organisation has a level called Confidential, and that the business has decided information in that class may be used internally but normally not shared freely outside the organisation.

The corresponding Purview label can then make the classification visible to the user and, depending on need and licensing, be linked to technical protection. Microsoft describes two main protection capabilities: content marking in the form of headers, footers and watermarks, and encryption that controls who may open the content and which actions they may take.

A simple translation table usually helps when the model is being designed.

Class	Handling rule decided by the business	Possible technical effect in Purview
Public	May be shared freely	Label as classification, no protection
Internal	May be used internally, not published	Label plus content marking
Confidential	Limited audience, normally not outside the organisation	Marking plus restricted external sharing
Highly confidential	Named audience, traceable access	Encryption with defined usage rights

What matters is that the technology follows the handling rules decided for the class, not the other way round. If the business says Confidential means one thing and Microsoft 365 does something else entirely when the user picks the label, the model quickly loses credibility.

Not every label needs to encrypt

This is an area where we think caution is warranted. It is easy to assume that a high class means encrypt everything. But encryption affects how content can be opened, shared, integrated and used in other systems.

Microsoft explicitly describes labelling content without using any protection settings. The label then works as classification and metadata, gives users a visual map of data sensitivity, and generates usage reports and activity data. Protection can be added later, where it is genuinely needed.

That allows a staged model. The organisation can first get users to understand and use the classification. Protection can then be tightened where the risks justify it. That is often considerably easier than combining a new classification model with far-reaching encryption and sharing restrictions from day one.

Microsoft also warns specifically against setting an encrypting label as the default label for documents, because many organisations need to share documents with external recipients who may not have apps or accounts that support the encryption.

Documents and email are the natural starting point

The most common scenario is that labels are used in Microsoft 365 applications such as Word, Excel, PowerPoint and Outlook. The user sees the classification as the document is created and can choose or change the label according to the organisation’s rules.

Microsoft also supports policy settings that can make labels mandatory, set a default label, and require justification when a user lowers the sensitivity level.

But we do not think mandatory labelling should automatically be the starting point. If users are given four labels without understanding the difference, the result is often that they pick whichever looks least troublesome. Microsoft writes the same thing: without user training these settings can result in inaccurate labelling, and mandatory labelling can frustrate users with frequent prompts.

Technology can require that a choice is made. It cannot replace understanding why the choice is made.

Teams and SharePoint need handling at two levels

An important detail in Purview is the difference between labels on content and labels on collaborative workspaces.

Labels can be applied to Teams, Microsoft 365 Groups, SharePoint sites, Viva Engage communities and Loop workspaces. At that level the label can affect privacy settings, external user access and external sharing, access from unmanaged devices, and how channels may be shared with other teams.

But a label on a SharePoint site or a Team does not mean the documents inside get the same label. Microsoft is explicit on this point: that label configuration does not result in individual items being automatically labelled, but instead protects content by controlling access to the container where content can be stored.

This matters when the model is designed. An organisation may have a Team classified as Confidential, with restricted external access, and still need to handle different types of information inside that workspace.

In other cases the organisation wants documents in a particular SharePoint library to receive a given label by default. Microsoft supports default labels on document libraries, but that is a separate feature with its own licensing requirements at E5 level.

Automatic classification: useful, but start carefully

Once manual classification works, the next question usually arrives: can Microsoft not label the information for us?

To some extent. Purview can use sensitive information types and other conditions to recommend or automatically apply labels. Microsoft also describes trainable classifiers and service-side auto-labelling for SharePoint, OneDrive and Exchange.

It sounds attractive. But automatic classification needs testing. A personal identity number in a document does not automatically mean the whole document should always be treated at the organisation’s highest protection level. And a document without an easily identifiable pattern can still be highly sensitive.

Automation should therefore be used where the organisation can formulate sufficiently stable rules. Microsoft has built that approach in: a service-side labelling policy runs in simulation mode when it is saved, so the organisation can see what the policy would label before it starts making real changes, and gradually increase the scope from a single location to more.

First understand, then simulate, then automate.

The link to DLP is what makes the model powerful

A classification becomes particularly useful when other security controls can make decisions based on it. Microsoft Purview Data Loss Prevention can use sensitivity labels as a condition in policies, including in Exchange, SharePoint, OneDrive and on devices.

That creates the chain of information classification, label and technical policy. Instead of merely writing that confidential information must not be shared inappropriately, the organisation can in certain flows detect, warn about or block actions that breach the policy.

That is a significant difference. One practical prerequisite, however, is that SharePoint and OneDrive are enabled to read and enforce sensitivity labels, which does not happen by default.

The same principle applies here as for labelling: a DLP policy that blocks normal work every day quickly becomes a productivity problem and generates exceptions. It needs testing, calibration and follow-up.

Purview also supports Microsoft 365 Copilot

Classification has become even more relevant as organisations introduce Microsoft 365 Copilot and other AI capabilities.

Microsoft describes how Copilot and agents recognise and use the sensitivity labels the organisation has applied. Where a label applies encryption, Copilot checks the user’s usage rights and returns data from an item only if the user has permission to copy from it. In a Copilot conversation that draws on several items, the label with the highest priority is shown, which is normally the most restrictive one.

That does not make classification a solution to poor access management. If a user already has access to large volumes of information they do not actually need, the underlying problem is still the access.

Purview therefore needs to be combined with access management, SharePoint governance, control of external sharing, identity and information ownership. That is also a reason we see information classification and Microsoft 365 governance as adjacent questions rather than separate projects.

Check the licensing before the design is locked

Purview is an area where licences should be checked before the final solution is designed, because the capabilities sit at different levels.

Manual use of sensitivity labels is included in Microsoft 365 E3 and Business Premium, among others. Automatic labelling, both client-side and service-side, normally requires E5 level or Microsoft Purview Information Protection Plan 2. Default labels on SharePoint libraries have their own requirements at E5 level.

This means the organisation should not start with a wish list of everything Purview can do. A better order is:

1. What do we need to achieve?
2. Which Purview capabilities solve that need?
3. What licensing does that require?

It is the same approach we use in Microsoft 365 work more generally: the licence level determines which protections in Conditional Access, Intune, Defender and Purview can actually be used.

A practical path from classification model to Purview

We usually see the work in a number of clear phases.

1. Classification model. The organisation has, or develops, an understandable model and defines what each level actually means.
2. Label model. The relevant parts are translated into labels in Purview: names, descriptions, any hierarchy, and which type of information the label is intended for.
3. Technical effect per label. One label may be visible classification only. Another should apply content marking. A third may need to govern encryption or external sharing.
4. Pilot. The label policy is tested with a pilot group, where you can see whether users understand the model, whether labels create unexpected consequences, and whether collaboration with external parties still works.
5. Wider rollout. Only then do automation, mandatory labelling or DLP rules become appropriate.

Microsoft’s own guidance points the same way, with simulation mode before live automatic labelling and a gradually widened scope.

The most common mistake: too many labels

An information security function can often understand the difference between Internal, Internal restricted, Confidential, Confidential personal data, Confidential financial, Strictly confidential and Strictly confidential executive. For the ordinary user it becomes considerably harder.

If a user has to read a long instruction every time a document is labelled, the organisation has probably built too complicated a model.

Here Microsoft is unusually concrete. Technically a tenant supports more than a thousand labels, but Microsoft writes that real-world deployments show effectiveness is noticeably reduced when users have more than five main labels, or more than five sublabels per main label, and recommends keeping the number to a minimum.

That is the same principle we use in classification work: as few levels as the business can actually use. The technology makes it possible to create many variants. That does not mean you should.

Another mistake: starting with encryption

Encryption can be exactly right for some sets of information. But if it is introduced before the collaboration patterns are understood, the result can be external recipients who cannot open material, integrations that stop working, or people who look for ways around the process.

The organisation should therefore first map how information is actually shared today:

• with customers
• with suppliers
• with the board
• with consultants
• with other Microsoft 365 tenants

Technical protection has to support those real working patterns. Otherwise the security control itself becomes a business problem.

Measure whether the classification is actually used

The rollout is not finished when the label policy has been published. Purview has Information Protection reporting covering label distribution and adoption, auto-labelling policy coverage and label activity. Activity explorer also shows events for the last thirty days, including the justification when a user lowers a label.

That makes it possible to follow questions such as:

• Are the labels being used?
• Is almost everything labelled at the same level?
• Are there parts of the organisation that never classify?
• Do users often lower the classification?
• Is automatic labelling hitting sensibly?
• Is DLP creating a lot of noise?

Follow-up then becomes part of the information security work, instead of Purview becoming another technical installation that nobody manages.

Microsoft Purview does not replace the information owner

Purview can identify patterns. It can read metadata. It can apply policies. But the tool does not automatically know the business consequence if a particular strategy plan, engineering drawing, customer list or internal analysis is shared incorrectly.

It is still the business that needs to understand the value of the information. The technology should therefore not take over information ownership. It should help the information owner get those decisions enforced in the technical environment.

That is also where we think the combination is strongest. The business classifies. Information security defines the handling requirements. Microsoft Purview helps enforce them.

How Kristensson i Skåne can help

Kristensson i Skåne works with both the governing side of information classification and the technical Microsoft 365 environment. That lets us help organisations all the way from classification model to working implementation. Support can include, for example:

• information inventory and classification model
• workshops with information owners
• mapping between classification levels and sensitivity labels
• design and implementation of label policies
• pilot and user support
• encryption and external sharing
• DLP
• automatic or recommended labelling
• SharePoint and Teams governance
• licence assessment
• ongoing follow-up and management

Our starting point is the same whether the engagement begins in information security or in Microsoft 365: the technology should carry out the organisation’s security model, not create it for them.

Frequently asked questions

Would you like to turn your classification model into something that works in Microsoft 365? Read more about our information classification offering or contact us for an informal conversation.

Sources: Microsoft Learn, Learn about sensitivity labels (updated 15 April 2026), Use sensitivity labels to protect collaborative workspaces, Automatically apply a sensitivity label to Microsoft 365 data, Use sensitivity labels as conditions in DLP policies, and the Microsoft Purview service description for licensing. Verified 16 September 2026.

This text is general information. Microsoft’s capabilities and licensing terms change over time; always check the current terms before designing an implementation.