A Sensitivity Label Taxonomy People Actually Use at a 3,200-employee Manufacturer
Three years of label requests had produced 17 labels and sublabels, a picker that ran to two screens, and a workforce that classified everything as General. We cut the taxonomy to 4, moved the heavy lifting to auto-labelling, and turned on mandatory labelling without a helpdesk spike.
About the Client
The Challenge
The manufacturer had published sensitivity labels three years before we arrived, and almost nobody applied them. The taxonomy had reached 17 labels and sublabels because every function that asked for one got one. Engineering had labels by drawing class, legal by contract type, and the export control group had quietly added a parallel set of its own. The menu in Word ran past the bottom of the screen.
What people do with a menu that long is predictable. They pick the first entry, or accept the default and move on. A spot check of recent documents found a mislabel rate of 6% — not malice, just a decision nobody had the context to make while saving a file.
Everything downstream inherited the problem. Data loss prevention rules keyed on label conditions were reading noise, and retention labels meant to trigger on classification never fired. The Copilot conversation the CIO wanted had no foundation, because label-based exclusions only work if labels mean something.
Containers were worse than content. Teams and SharePoint sites were created by whoever needed one, with external sharing, guest access and default link type decided by the site creator. Across 620 workspaces there was no consistent stance on whether an engineering project site should admit guests at all. The engagement was triggered by export-controlled drawings reaching a supplier's guest account.
Our Approach
A label taxonomy is a user interface before it is a control. We rebuilt it around the handling decisions people actually make, then moved as much work as possible into automatic classification.
Taxonomy Teardown and Usage Evidence (Weeks 1-3)
Used Content Explorer and Activity Explorer to establish which of the 17 labels had ever been applied and to what. A long tail carried fewer than ten documents each. We then interviewed the requesters. Most had wanted a different sharing or retention outcome rather than a new classification — a label was simply the only thing anyone knew how to ask for. Every label was mapped to one of four handling outcomes.
Four Tiers, Sublabels Only Where Protection Differs (Weeks 3-5)
There is a published ceiling on taxonomy size and it is lower than most organisations assume: classification effectiveness drops noticeably once a user sees more than five main labels, or more than five sublabels under one main label. Some applications cannot render the full set when too many are published to one user. 17 was past both thresholds several times over, which gave the steering group a target rather than an argument about taste. We rebuilt the scheme as Public, Internal, Confidential and Restricted, with sublabels only where encryption or permissions genuinely differ — Confidential \ Supplier NDA applies Do Not Forward, Restricted \ Export Controlled encrypts to a named security group with a short offline access window. The hierarchy is two tiers deep because that is all the platform supports. Label priority order was set deliberately, since priority decides which label wins when policies collide, and parent labels with sublabels were made unselectable.
Auto-Labelling in Simulation (Weeks 5-9)
Two mechanisms, deployed for different jobs. Client-side auto-labelling in the Office apps recommends a label as the user types, which teaches the taxonomy without forcing it. Service-side policies work on data already at rest in SharePoint, OneDrive and Exchange, and those ran in simulation for weeks before anything was applied. Conditions combined a trainable classifier built on the firm's own engineering change documents, sensitive information types for export control markings, and optical character recognition for scanned drawings that carry their classification as an image. Where conditions collide, the last label and then the last sublabel wins, so the evaluation order was written down rather than discovered.
Container Labels and Fixing Co-authoring (Weeks 8-12)
Published container labels for Microsoft 365 Groups, Teams and SharePoint sites, controlling privacy, external sharing, access from unmanaged devices and the default sharing link type. We were explicit with stakeholders that a container label does not encrypt the files inside it — the misunderstanding that most often makes container labelling look sufficient. In parallel we removed the legacy Azure Information Protection add-in, standardised Office builds and enabled the tenant setting for co-authoring on labelled and encrypted files, which takes 24 hours to replicate before it does anything.
Mandatory Labelling and Downgrade Justification (Weeks 11-16)
Mandatory labelling was only switched on once the taxonomy was small enough to justify it. Each policy carried a default label suited to its audience rather than one tenant-wide default, and users had to give a justification before removing a label or lowering a classification. That text lands in the audit log and feeds insider risk detection. Rollout ran by policy group, starting with 140 before the wider population.
Solution Architecture
Taxonomy: Four top-level labels with sublabels only where protection differs, priority order set so the more restrictive classification wins, and parent labels made unselectable
Classification sources: Trainable classifier on engineering change documents, sensitive information types for export control markings, OCR for scanned drawings, and manual selection as fallback rather than default path
Protection: Encryption with named group permissions and a bounded offline access window on the top tier, Do Not Forward on supplier material, visual markings on everything at Confidential and above
Containers: Labels on Microsoft 365 Groups, Teams and SharePoint sites governing privacy, guest access, unmanaged device access and default link type, aligned to the SharePoint site provisioning process
Operations: Content Explorer and Activity Explorer reviewed monthly by information security, under a standing rule that no label is published without an owner and a retirement date
Results
Client identity withheld under confidentiality. Figures are representative of engagements of this scope.
Technologies Used
Key Takeaways
If your organization is facing a similar challenge, here's what we learned:
Label count is inversely related to label accuracy, and the ceiling is published. Effectiveness falls away past five main labels or five sublabels under one main label. Four top-level choices is a taxonomy. Forty is a quiz, and people fail quizzes by guessing.
Most label requests are really requests for something else. Ask what the requester wants to happen to the document — who opens it, who forwards it, how long it is kept — and the answer usually maps to a label that already exists, or to a retention setting.
Container labels do not protect the content inside the container. They govern the site: privacy, guest access, unmanaged device access, default link type. A file leaving a labelled site carries no protection unless the file itself is labelled.
Fix co-authoring before you make labelling mandatory. If protected documents cannot be edited by two people at once, users keep them out of SharePoint, and you have driven your most sensitive content into the places you cannot see. The legacy add-in goes first.
Downgrade justification is a detection surface, not paperwork. The text a user types when lowering a classification is written to the audit log. Read alongside departure dates and egress activity, a run of downgrades is one of the clearest early signals of intent.
Related Case Studies
Is Anyone Actually Using Your Labels?
If your taxonomy has grown past what a person can hold in their head, classification accuracy has already collapsed. We rebuild label schemes around handling decisions and move the work to auto-labelling.