Why this layer exists
SharePoint permissions and external-sharing controls govern access while content lives inside the platform. The moment content is downloaded, attached to email, or copied to a USB drive, those controls stop applying. Sensitivity labels, DLP, and Conditional Access are the layer that enforces protection beyond the platform boundary.
These controls don't replace permissions and sharing — they layer on top. Permissions decide who can reach the content. Sensitivity labels and DLP decide what users can do with it and how it can travel.
Two label layers — container and document
Microsoft Purview sensitivity labels operate at two scopes. Both are needed; neither is sufficient on its own.
| Layer | Applies to | Decides |
|---|---|---|
| Container labels | SharePoint sites, Teams, Microsoft 365 Groups. | Privacy, external sharing posture, guest access, Conditional Access on unmanaged devices, discoverability. |
| Document labels | Individual documents, emails, meeting invites. | Encryption, content marking (header/footer/watermark), and what authenticated users can do (open, edit, print). |
A private site does not stop a user from forwarding a downloaded file. An encrypted file in a public site is still trivially discoverable. Used together, they form a defense-in-depth pattern: the container decides who can reach the workspace; the document decides what users can do with each file once they have it.
The two label layers are configured as parallel flat families in Purview — site labels in one family, document labels in another. They evolve independently and don't share state. (For the architectural reasoning, see the topic guide Site Sensitivity Labels.)
Site (container) labels — two starter labels
Two flat, site-scoped labels are enough to cover the majority of practical scenarios and give site owners a clear, fast choice at provisioning time.
| Setting | Internal Only | External Allowed |
|---|---|---|
| Intent | Staff only. No guests, no external sharing. | Workspace expects collaboration with people outside the organization. |
| Privacy | Private (members only). | None — owner decides. |
| Guest membership in the Group / Team | Not permitted. | Permitted. |
| SharePoint external sharing | Only people in your organization. | New and existing guests. |
| Conditional Access (unmanaged devices) | Allow full access (review as governance matures). | Allow full access. |
| Typical uses | HR, finance, legal, executive, internal-only projects. | Client engagements, partner workspaces, vendor collaboration. |
Two flat container labels cover most decisions and keep the provisioning experience simple. Owners pick the label that matches the work, and the platform applies the configuration consistently. As governance matures, additional container labels can be introduced — typically a stricter tier that adds Conditional Access for unmanaged devices.
Kybera Impact's workspace templates apply the right container label at provisioning. A Project — External template applies External Allowed; an HR Operations template applies Internal Only. The label becomes a property of the template, not a manual configuration step a site owner has to remember.
Document labels — a starter set of five
Five document labels arranged as one unencrypted root label plus two label groups. The groups separate encrypted labels by who can decrypt the file — and inside each group, two sensitivity tiers (Protected A, Protected B) carry the content marking that travels with the file.
| Label | Audience that can decrypt | Encryption | Content marking |
|---|---|---|---|
| Unclassified | Anyone (no restriction) | None | Footer — "Classification: Unclassified" |
| Internal Only / Protected A | All users in your organization (no guests) | View, Edit, Save, Print | Footer — "PROTECTED A — Internal Only"; grey watermark |
| Internal Only / Protected B | All users in your organization (no guests) | Same baseline, can be tightened | Footer — "PROTECTED B — Internal Only"; red watermark |
| External Allowed / Protected A | Any authenticated user (internal + guests + social authentication) | View, Edit, Save, Print | Footer — "PROTECTED A"; grey watermark |
| External Allowed / Protected B | Any authenticated user | Same baseline, can be tightened | Footer — "PROTECTED B"; red watermark |
Why this shape
- Unclassified is explicit, not absent. Every document carries a label — including documents that don't need protection. This makes mandatory-labelling policies practical, and it's the difference between "labelled" and "encrypted."
- Two encryption groups split by audience. Users naturally ask "who needs to read this?" before they ask "how sensitive is it?" — so audience-first grouping matches the question the labeller is actually answering.
- Protected A and Protected B as distinct tiers. The Canadian federal classification convention (and many regulated-industry equivalents) recognizes two levels of confidentiality below classified material. Keeping them as distinct sub-labels lets the visible content marking reflect the sensitivity tier — a downstream recipient who sees PROTECTED B immediately knows they're looking at the more sensitive of the two.
- Five is the limit. Microsoft's own guidance recommends no more than five top-level choices in the picker. More labels means users pick wrong, mis-label, or skip labelling entirely.
Don't try to model every nuance of every business area in the label taxonomy. Five labels is almost always enough; ten is too many. Users won't remember the difference between Confidential — Project Alpha and Confidential — Project Beta, and inconsistent labelling is worse than coarse labelling.
Data Loss Prevention (DLP)
DLP policies detect content that matches defined patterns — credit card numbers, social-insurance numbers, health information, custom regular expressions — and apply controls when that content is shared, emailed, or moved.
- Built-in sensitive information types. Microsoft ships hundreds of detectors for PII, financial data, healthcare data, and regulatory schemes (GDPR, HIPAA, PCI).
- Custom sensitive information types. Organization-specific patterns (employee IDs, customer numbers, internal classifications).
- Trainable classifiers. ML models trained on organizational content (resumes, source code, contracts) — broader than pattern matching.
- Policies. Combine detectors with conditions (location, recipient, sharing scope) and actions (block, warn, justify, audit).
Common DLP patterns:
- Block external sharing of files containing PII or financial data.
- Warn (with override option) when sharing files containing customer data outside the company.
- Block emailing files containing classified content.
- Audit access to highly sensitive content for forensic purposes.
DLP can be configured in audit only mode (log violations, take no action) or enforcement mode (block, warn, require justification). Most organizations should pilot in audit mode for 30–60 days to understand where their content actually triggers detection, then move to enforcement once the false-positive rate is acceptable.
Conditional Access basics
Conditional Access policies in Microsoft Entra ID govern when and how users can authenticate to Microsoft 365. They sit upstream of all the controls above and decide whether a sign-in succeeds at all.
- MFA enforcement for all users, all admins, or all access from outside the corporate network.
- Device compliance. Block access from unmanaged or non-compliant devices for sensitive applications.
- Risk-based access. Microsoft Entra ID Protection scores sign-ins for risk; high-risk sign-ins require additional verification or are blocked.
- Guest restrictions. Tighter requirements for guest access — MFA, device compliance, named applications only.
- Session controls. Restrict downloads on unmanaged devices (web-only access to SharePoint, no local sync).
Auto-labelling (Phase 2)
Once the manual labelling baseline is in place, auto-labelling reduces the burden on users:
- Pattern-based auto-label. Documents containing detected sensitive content get labelled automatically.
- Trainable classifier auto-label. Documents matching a trained content category get labelled.
- Policy-based defaults. New files in a workspace inherit a default document label from its container label.
Don't try to launch with auto-labelling. Get the manual taxonomy stable first (3–6 months), then introduce auto-labelling on the highest-volume cases where users consistently mis-label or skip labelling entirely. Trainable classifiers are E5 territory and require curation effort — worth it for high-value content categories, expensive for everything.
Discussion questions
• Are we comfortable starting with two container labels — Internal Only and External Allowed — for sites and Teams?
• Are we comfortable starting with the five-label document set — Unclassified plus Internal/External × Protected A/B?
• Do we have downstream recipients who'd benefit from distinct visible marking for Protected A vs Protected B?
• What DLP detectors matter most — PII, financial data, healthcare data, custom patterns?
• Should we pilot DLP in audit mode first, or go straight to enforcement?
• What Conditional Access posture applies to guest users and unmanaged devices?
• What's our training plan for users to learn the labels and apply them correctly?
• Do we have the licensing (E5 or appropriate add-ons) for trainable classifiers and advanced DLP?