Sensitivity Label Groups and sites configuration for Australian Government compliance with PSPF

This article provides guidance on the use of Microsoft Purview groups and sites configuration to enable sensitivity labels for SharePoint sites and Microsoft Teams. Its purpose is to help Australian Government organizations to increase their ability to protect security classified information in these services while adhering with requirements outlined in the Protective Security Policy Framework (PSPF) and Information Security Manual (ISM).

Groups and sites settings can be enabled for a sensitivity label when configuring the label scope. These settings allow sensitivity labels to be applied to locations such as SharePoint sites Teams, and Microsoft 365 groups.

Groups and sites configuration allow us to consistently apply the following controls for locations with a label applied:

• Location visual markings
• Location privacy settings
• Location guest membership permissions
• Location sharing options
• Location conditional access requirements (based on device management or a full Conditional Access policy)
• Location data out of place alertings that trigger when higher sensitivity labeled items are moved to lower sensitivity locations

Enablement of groups and sites label configuration brings the configured label policy options into play for any newly created SharePoint sites or Teams. If a user is within the scope of a label policy that requires mandatory labeling for these items, then every time the user creates a new SharePoint site or Microsoft 365 group, the user is required to select a sensitivity label.

These settings align with Protective Security Policy Framework (PSPF) Policy 8 Core Requirement C as the policy is configured proportional to a location’s sensitivity.

Requirement	Detail
PSPF Policy 8 Core Requirement C (v2018.6)	Implement operational controls for these information holdings proportional to their value, importance, and sensitivity.

These settings also align with PSPF Policy 8 Core Requirement A and Supporting Requirement 1 as they're extending the requirement for users to identify files and emails to locations such as SharePoint sites and Teams.

Requirement	Detail
Core requirement A and supporting requirement 1: Identifying information holdings (v2018.6)	The originator must determine whether information being generated is official information (intended for use as an official record) and whether that information is security classified.

These settings also align with Supporting Requirement 4 as the capability extends marking requirements from files and emails to SharePoint sites, Teams, and Microsoft 365 groups.

Requirement	Detail
PSPF Policy 8 Supporting Requirement 4 - Marking information (v2018.6)	The originator must clearly identify sensitive and security classified information, including emails, using applicable protective markings.

Note

To automatically apply a chosen label to any item created within a location, use the Default labeling for SharePoint option.

SharePoint location and item sensitivity

When a sensitivity label is applied to a SharePoint location, visual markings, which are provided at the top of the site, provide an indication of the location sensitivity to users. This information is useful for determining if the information located in the site is appropriate for distribution.

Labels applied to SharePoint sites are modified by Site Owners or SharePoint administrators.

Tip

Views in SharePoint document libraries can be modified to show the sensitivity label applied to items. This feature is useful for identifying items in a location, which may be out of place.

File icons in SharePoint directory can be customized to display icon markers for labeled items that are subject to sharing restrictions or items that have a policy tip configured. These two configurations are aligned with OFFICIAL: Sensitive and PROTECTED security classifications to provide a different marking approach for users working in document libraries. For example:

For more information on limiting sharing options, see preventing sharing of security classified information.

Teams location and item sensitivity

Like SharePoint, new Teams created by users who are within the scope of labeling policies are subject to that policy's requirements, which can require them to select a label.

Labels applied to Teams are modified by Team owners, Teams administrators, or Microsoft Entra ID administrators via the Team's underlying Microsoft 365 group.

As with SharePoint, Teams file views can be modified so that users have a clear indication of item sensitivity.

Microsoft 365 group sensitivity

Groups and sites configuration enforces the policy labels which as applied to Microsoft 365 groups. Microsoft 365 groups are used as the membership service for Teams and for SharePoint team sites. This feature has other uses within Microsoft 365 environments. For example, it's used as the membership service behind group mailboxes. This is a progression from traditional Exchange Distribution Lists, that allows for user self-administration, and the ability to subscribe or unsubscribe from group messages being delivered directly to your mailbox.

Application of labels to group mailboxes can provide a clear indication of the sensitivity of content that should exist or is safe to be shared with group members. Other controls could also be configured to restrict distribution of content of higher sensitivities.

Labels requiring groups and sites configuration

Groups and sites configuration may not be applicable for all labels, and requires tailoring. For example, Information Management Markers (IMMs) are more relevant to individual items than locations. An analogy is that a label applied to a location is similar to a container class that is applied to a lockable cabinet or safe. The container comes with a set of controls to protect contained information, but we may not necessarily need a container for each label. Items marked with the various combinations of a label (for example, OFFICIAL Sensitive and all associated IMMs and other sublabels), can potentially reside in the same container with the same level of protections applied. Individual items within the container could have any variation of labels applied to them up to and including the label of the container.

When treating groups and sites configuration in this manner, we may only require one label per category to be applicable to groups and sites. This could be the label without IMMs applied. With groups and sites settings only enabled for certain labels, only those labels are available for application to these locations. The following table is an example in the Australian Government context.

Sensitivity label	Groups and sites configuration	Available for application to SharePoint and Teams
UNOFFICIAL	On	Selectable
OFFICIAL	On	Selectable
OFFICIAL Sensitive	Off
- OFFICIAL Sensitive	On	Selectable
- OFFICIAL Sensitive Personal Privacy	Off
- OFFICIAL Sensitive Legal Privilege	Off
- OFFICIAL Sensitive Legislative Secrecy	Off
- OFFICIAL Sensitive NATIONAL CABINET	Off

In this configuration, a location that was labeled as OFFICIAL Sensitive would be expected to contain OFFICIAL: Sensitive information, including information relating to IMMs of Personal Privacy, Legal Privilege, and Legislative Secrecy.

There are situations where alternate configuration is required and appropriate business analysis needs to be completed to determine this. For example, Government organizations who have a requirement for different controls to be applied to PROTECTED Legal Privilege locations may wish for groups and sites configuration to be enabled for this label. There may also be a need to record label change justifications for changes to these items. In such situations, the PROTECTED Legal Privilege label would need to be a full label rather than a sublabel. It would also need to be positioned above the other PROTECTED category so that changes label from PROTECTED Legal Privilege to PROTECTED can be identified as a lowering of sensitivity. The following table is an example of this in the Australian Government context.

Sensitivity label	Groups and sites configuration	Available for application to SharePoint and Teams
PROTECTED	Off
- PROTECTED	On	Selectable
- PROTECTED Personal Privacy	Off
- PROTECTED Legislative Secrecy	Off
- PROTECTED CABINET	Off
PROTECTED Legal Privilege	On	Selectable

Enabling groups and sites integration

To apply groups and sites settings to labels, the option must be enabled for the organization. This process involves the use of Security & Compliance PowerShell. For more information on this process, see Assign sensitivity labels to groups - Microsoft Entra | Microsoft Learn.

Once groups and sites settings are successfully enabled via PowerShell, the option to select this configuration becomes available within label configuration.

Label privacy settings

The first option available via groups and sites configuration is privacy. This setting allows organizations to enforce privacy settings on any Microsoft 365 groups (including group mailboxes), Teams, and SharePoint sites. Privacy can be set to public, private, or none.

Privacy settings are relevant to PSPF Policy 9 Requirement 2, which relates to the need-to-know principle:

Requirement	Detail
PSPF Policy 9 Requirement 2 - Limiting access to sensitive and classified information and resources (v2018.6)	To reduce the risk of unauthorized disclosure, entities must ensure access to sensitive and security classified information or resources is only provided to people with a need-to-know.

A privacy setting of public allows anyone in the organization to join the group and/or access the groups content. This setting may be appropriate for the UNOFFICIAL label.

Setting a label’s privacy to none allows group owners the flexibility to decide on an appropriate privacy setting.

For OFFICIAL content, PSPF Policy 8 states that the need-to-know principle is recommended but not mandated. The OFFICIAL label will likely be applied to numerous items that are intended for distribution. Therefore, giving owners of OFFICIAL groups the flexibility to decide on privacy.

Requirement	Detail
PSPF Policy 8 Annex A – Minimum protections and handling requirements for OFFICIAL information (v2018.6)	The need-to-know principle is recommended for OFFICIAL information.

For OFFICIAL: Sensitive and PROTECTED information, the need-to-know principle applies. Privacy options should be set to private. This helps keep any contained information from being accessible by those who don't have need-to-know and makes group owners accountable for all membership additions.

Requirement	Detail
PSPF Policy 8 Annex A – Minimum protections and handling requirements for OFFICIAL: Sensitive information (v2018.6)	The need-to-know principle applies to all OFFICIAL: Sensitive information.
PSPF Policy 8 Annex A – Minimum protections and handling requirements for PROTECTED information (v2018.6)	The need-to-know principle applies to all PROTECTED information.

Guest access configuration

Available options for controlling guest access via sensitivity label are simple configurations, but the desired approach varies depending on the organization's configuration and their wider external collaboration requirements. Because of this, there's specific advice for organizations with requirements for high external collaboration control versus organizations with low control needs.

High external collaboration control

Organizations with high external collaboration control require a strict configuration, which tightly governs outside access to their Microsoft 365 environment. Such organizations have configured:

• Restrictions to limit guest access to directory objects.
• Restrictions limiting user's ability to invite guests except for those who are granted 'guest inviter' permissions.
• Restrictions to limit guest invitations to only preapproved domains.
• Conditional Access policies requiring use of multifactor authentication (MFA) and agreement to terms of use for guest access.
• Guest approval workflows, potentially including a check of guest security clearances and confirmation of 'need to know.'
• Ongoing guest management processes making use of access reviews to audit guest accounts and remove guests from the environment when access is no longer required.

Organizations will also have agreements in place with external organizations, which outline the administrative obligations on each side of the partnership.

The following requirements are relevant to high external collaboration control:

Requirement	Detail
PSPF Policy 8 Core Requirement C (v2018.6)	Implement operational controls for these information holdings proportional to their value, importance, and sensitivity.
PSPF Policy 8 Annex A – Minimum protections and handling requirements for PROTECTED information (v2018.6)	Ongoing access to PROTECTED information requires a Baseline security clearance (minimum).
PSPF Policy 9 Requirement 1 - Formalized agreements for sharing information and resources (v2018.6)	When disclosing security classified information or resources to a person or organization outside of government, entities must have in place an agreement or arrangement, such as a contract or deed, governing how the information is used and protected.
PSPF Policy 9 Requirement 3a - Ongoing access security classified information and resources (v2018.6)	Entities must ensure that people requiring ongoing access to security classified information or resources are security cleared to the appropriate level.

Organizations who have implemented the previous list of controls are able to enable guest access and external collaboration for all labels up to and including PROTECTED (provided the guest clearance is obtained and maintained at the appropriate level).

Low external collaboration control

Organizations with low external collaboration controls and haven't implemented the previous list of controls, should note the following:

• Don't have restricted guest invitation to approved organizations only.
• Don't have a guest approval workflow, which includes a check of guest security clearances.
• Don't have a process for ongoing guest management including the use of access reviews.

For such organizations, enabling guest access to PROTECTED content isn't appropriate, as operational controls and processes, which ensure appropriate security clearances aren't enabled.

Label external user access settings

The 'external user access' setting controls whether guests are able to be added to Microsoft 365 groups (which includes Teams) with the label applied.

Organizations with high external collaboration control can enable this setting on all labels to allow guest collaboration across the board.

Those with lower control may wish to enable this option for UNOFFICIAL and OFFICIAL sites, Teams, and groups only.

Organizations that don't use guest collaboration within their tenant should turn off this setting and in addition, disable guest access settings within Entra.

Important

Guest tenant settings configured in Entra always take precedence over any label-based configuration.

If guests aren't enabled for the environment in Entra, the external user access setting from the label is irrelevant and ignored.

The external access settings provided in example groups and sites settings demonstrates operational controls proportional to a location's sensitivity (as per PSPF Policy 8 Core Requirement C).

Label sharing configuration

Label groups and sites settings enable consistent configuration sharing settings based on the label applied to a location.

The organization's default (their lowest permissible setting) is obtained from the configured SharePoint sharing setting. The administrator can then configure more restrictive settings individually on site or configured based on the sites applied sensitivity label.

The benefit of configuration based on sensitivity labels is sensitive locations are protected from inappropriate sharing via the label-based configuration rather than inheriting the organization's default minimum value.

The following options are available for label-based sharing controls:

• Anyone allows for items to be shared from the labeled location and accessed by users receiving the links without any authentication or authorization. Ensuring 'need-to-know' for this link type isn't enabled.
• New and existing guests requires that guests authenticate before accessing links and can also be used to create guest accounts at time of access. This option isn't recommended for organizations seeking high external collaboration control.
• Existing guests allows sharing of items from labeled locations with guest accounts that already exist in an organization’s directory. This option is a good fit for many situations as it provides authentication and authorization. This option is recommended for organizations seeking high external collaboration control.
• Only people in your organization limits sharing to internal users only.

A typical deployment would start with the 'new and existing guests' option selected for low sensitivity locations, progressing to 'only people in your organization' for high sensitivity, such as PROTECTED locations. Organizations with high external collaboration control make use of the 'Existing guests' option on all labels.

As with external access settings, the example configurations provided in example groups and sites settings are designed to demonstrate operational controls proportional to a location's sensitivity (as per PSPF Policy 8 Core Requirement C).

If an organization wishes to further restrict sharing from labeled locations, advanced capabilities can be enabled via PowerShell that control the sharing options made available to site or Team members. This configuration can be applied to PROTECTED labels to align with PSPF Policy 9 Requirement 2:

Requirement	Detail
PSPF Policy 9 Requirement 2 - Limiting access to sensitive and classified information and resources (v2018.6)	To reduce the risk of unauthorized disclosure, entities must ensure access to sensitive and security classified information or resources is only provided to people with a need-to-know.

This option ensures that Team owners have control of user access to content stored within PROTECTED locations as they need either complete all sharing activities on behalf of members or provide access to the site or Team’s contained information by expanding its membership.

These capabilities can be configured via the following PowerShell:

Set-Label -Identity <Label_GUID> -AdvancedSettings @{MembersCanShare="MemberShareNone"}

For more information on the MembersCanShare option, see Use sensitivity labels with Microsoft Teams, Microsoft 365 Groups, and SharePoint sites.

Conditional access

Conditional access policies in Microsoft Entra ID provide controls to govern access to services that use Entra authentication and access control. Conditional access policies evaluate specific conditions to determine if access is or isn't be allowed to specific services, such as SharePoint, Teams, or Microsoft 365 in general. The default capability of conditional access policies doesn't allow for more granular control of access to the specific group or site level.

Sensitivity label conditional access configuration allows for alignment between the label applied to a location (site or team) and user access requirements. This provides a more granular level of control than would be achievable via standard conditional access, which for most situations is checked at sign-in or connection to a service.

Sensitivity label-specific conditional access requirements are applied in addition to any conditional access sign-in requirements. For example, if a conditional access policy requires that:

1. Users authenticate.
2. Users verify their identity via multifactor authentication (MFA).
3. Users must be on a managed device.

If these conditions are all true, then a label-based policy that also requires a managed device, provides little value as this requirement is met by the conditional access policy triggering at sign in.

However, users may be allowed to authenticate and access some locations (for example, UNOFFICIAL or OFFICIAL) via unmanaged devices. If they then attempt to access a higher sensitivity location (for example, OFFICIAL: Sensitive), which is configured to require managed devices, then their access is blocked. These capabilities can be used to permit remote work by enabling a level of access via personal mobile devices or home computers, without opening the organization to the risk of such devices being used to access highly sensitive locations.

As with many of the groups and sites configuration options, these controls can be tied to PSPF Policy 8 Core Requirement C as they allow the application of access restrictions based on the sensitivity of a location:

Requirement	Detail
PSPF Policy 8 Core Requirement C (v2018.6)	Implement operational controls for these information holdings proportional to their value, importance, and sensitivity.

Additionally, as this set of controls is concerned with restricting access to information and helping to ensure need-to-know, PSPF Policy 9 Requirement 2 is also applicable:

Requirement	Detail
PSPF Policy 9 Requirement 2 - Limiting access to sensitive and classified information and resources (v2018.6)	To reduce the risk of unauthorized disclosure, entities must ensure access to sensitive and security classified information or resources is only provided to people with a need-to-know.

There are two conditional access configuration categories available via groups and sites settings, which are:

• Unmanaged device restrictions
• Authentication context

Unmanaged device restrictions

Unmanaged devices are devices that aren't enrolled into the Intune device management platform or aren't joined to Microsoft Entra ID. Identifying unmanaged devices helps to ensure that devices connecting to the environment are known, that users have authenticated with an organizational account, and that a basic set of device requirements are in place. Devices that don't meet these requirements can be deemed as higher risk than those which do.

For more information on Microsoft Entra ID joined devices, see What is an Azure AD joined device?

Configuring unmanaged device options on sensitivity labels allow labeled SharePoint sites or Teams to be linked to conditional access policies targeting unmanaged devices and enforcing 'app-enforced restrictions.'

There are three configuration options available:

• Allow full access from desktop apps, mobile apps and the web: This option allows unmanaged devices to access labeled locations without any restrictions. This allows users to download files from these locations to their unmanaged device, which may lead to data loss without other controls in place. Because of this, some organizations may opt to enable this only for lower sensitivity locations.
• Allow limited, web-only access: This option allows unmanaged devices to access labeled locations only via a web browser. These web-only sessions can also remove the ability to download or print files, helping to ensure need-to-know by protecting from sensitive information being downloaded and stored in locations where it may be easily accessed by an attacker or accidentally viewed.
• Block access: This option can be used to block unmanaged device access to locations with a label applied.

Authentication context

There are some scenarios where organizations may need to apply more granular controls to labeled locations than those based purely on device management status. Authentication context allows the alignment of a fully featured conditional access policy with labeled locations.

An authentication context is essentially an 'object,' which is used to link a conditional access policy with a sensitivity label. Attempts to access a labeled site trigger the linked conditional access policy and apply its requirements.

Benefits of authentication context are:

• It allows for the consistent application of full conditional access policies based on sensitivity of locations.
• The granular control of a full conditional access policy allows us to cater for more niche scenarios, such as user or group-based exclusions, location, or IP based restrictions.

Authentication context and its associated conditional access policies, need to be created within Microsoft Entra ID before they can be linked to a label.

Alignment with minimum handling protections

PSPF Policy 8 Annex A includes a list of controls, which should be in place for the use and storage of information outside of Government facilities.

These annexes include definitions of managed (secured state) and unmanaged (unsecured state) devices along with statements around the use of authorized nongovernment devices, is complex. For more information on the details of these annexes, see the Protective Security Policy Framework (PSPF).

Regarding the use of nonauthorized, nongovernment devices, which falls into the 'all other mobile devices' category:

Requirement	Detail
PSPF Policy 8 Annex B - Minimum protections and handling requirements for government-issued mobile devices (v2018.6)	All other mobile devices – devices that aren't owned, issued, or authorized by the entity. These devices must not be authorized to access, process, store, or communicate government OFFICIAL: Sensitive or higher information.

The following is an example of how label-based conditional access policies are configured in alignment with PSPF Policy 8 Core requirement C (controls proportional to sensitivity). The example further demonstrates that general conditional access policies apply to users trigger on authentication/access to the service before any location-based controls that might apply to labeled locations via authentication context:

Label	Conditional access settings
UNOFFICIAL	Allow full access.
OFFICIAL	Allow full access.
OFFICIAL: Sensitive	Block access on all unmanaged devices.
PROTECTED	Link to an authentication context which: - Requires a managed device, - Requires membership of a group of authorized users, and - Requires access from a trusted location.

Data out of place alerting

Application of a label to a location via groups and sites configuration enables data out of place alerting.

When an administrator applies a label to a location, they establish that the location is appropriate for the storage of items up to and including the applied label. If a location is configured as 'OFFICIAL: Sensitive' then it can contain items of all labels up to and including 'OFFICIAL: Sensitive' and any sublabels that may exist within the same grouping.

If a PROTECTED item is moved to an 'OFFICIAL: Sensitive' location, this is a data spill and requires remediation, which is where out of place alerting is important.

When such events occur:

1. The action isn't blocked, which is important as it may have been due to a reclassification or other required business process.
2. An incompatible sensitivity label detected alert is sent to the user, which attempts to educate them on the issue, provide links to the item, the item's and location and can direct them to a URL for further assistance.
3. An alert is sent to the SharePoint site’s administrator advising them of the incident. If necessary, mail flow rules or similar configurations can be implemented to direct these alerts to security teams.
4. A 'Detected document sensitivity mismatch' audit log event is generated.

The following is an example of an alert, which is sent to users when such an action occurs:

Tip

The HelpLink URL provided in these notification can be configured via:

Set-SPOTenant –LabelMismatchEmailHelpLink “URL”

Data out of place alerts should be closely monitored as:

• Need-to-know principles may be hard to adhere to when PROTECTED or OFFICIAL: Sensitive items are moved to lower sensitivity containers that might, for example, have more permissive privacy configuration.
• Controls such as conditional access are likely to be more relaxed in lower sensitivity locations, which could lead to data being exfiltrated or moved to unmanaged devices.

Government organizations can reduce risks of data exfiltration of data out of place, using Microsoft Purview layered approach. This includes:

• Approaches for monitoring data out of place alerting.
• Inclusion of layers of Data Loss Prevention (DLP) protections that assess the content included in items beyond the applied label (as explored in Limiting distribution of sensitive information).
• Identifying risky user behavior ahead of serious policy violation via tools such as Insider Risk Management and Adaptive Protection.

Monitoring data out of place alerting

By default, sensitivity mismatch alerts are visible within the audit log, in site administrator mailboxes, and are surfaced in the activity explorer. Microsoft Purview implementations for Government organizations should include a strategy and processes for dealing with sensitivity mismatch alerts. The strategy should also include prioritization to ensure that more critical alerts are given priority over lower priority mismatches.

For example, OFFICIAL information that is moved to a SharePoint location labeled as UNOFFICIAL has less consequence than PROTECTED information that is moved to a SharePoint location labeled as UNOFFICIAL, and priority should be given in order of rank.

The following example priority matrix demonstrates the ways that organizations could determine which events to prioritize for data out of place remediation:

Item label	UNOFFICIAL location	OFFICIAL location	OFFICIAL Sensitive location	PROTECTED location
UNOFFICIAL Item	-	-	-	-
OFFICIAL Item	Lower priority	-	-	-
OFFICIAL Sensitive Item	Medium priority	Medium priority	-	-
PROTECTED Item	Highest priority	High priority	High priority	-

For monitoring and actioning these events would be to make use of a Security Information and Event Management (SIEM) solution such as Microsoft Sentinel to ingest the audit log, and filter events based on the sensitivity of the location, and the sensitivity of the item. We would then trigger alerting or remediation activities to address the situation.

For organizations not using a SIEM capability, granular alerting can be provided via a Mail Flow Rule, which checks the body of alert emails sent to offending users and directs the emails elsewhere for action. For example:

Such rules can be configured to check the body of emails for file and site sensitivity details and then trigger an appropriate alert, for example, notification to security teams.

Power Automate offers other reporting or alerting options. For example, a flow could be created to act on items sent to a data out of place alerting mailbox, obtain the offending users Manager field from Microsoft Entra ID, and send the manager an incident report, allowing them to address the situation with their subordinate.

Tip

The best approach is to develop an alerting/reporting strategy that aligns with other business processes. Using Microsoft Sentinel as your SIEM is the best option, as it is built and designed to work together with Microsoft Purview.

Example groups and sites configuration

The following is intended to provide an example of how granular controls can be applied to locations based on applied sensitivity label. This is aligned with PSPF Policy 8 core requirement C, and offers operational controls proportional to item's value, importance, and sensitivity.

Sensitivity label	Groups & sites	Privacy settings	External access	External sharing	Conditional access
UNOFFICIAL	On	Off or None (User decides)	Allow guests	Allow to existing guests	Off or allow full access from unmanaged devices
OFFICIAL	On	Off or None (User decides)	Allow guests	Allow to existing guests	Off or allow full access from unmanaged devices
OFFICIAL Sensitive (Category)	Off	N/A	N/A	N/A	N/A
OFFICIAL Sensitive	On	Private	Allow guests	Allow to existing guests	Block access on unmanaged devices
OFFICIAL Sensitive Personal Privacy	Off	N/A	N/A	N/A	N/A
OFFICIAL Sensitive Legal Privilege	Off	N/A	N/A	N/A	N/A
OFFICIAL Sensitive Legislative Secrecy	Off	N/A	N/A	N/A	N/A
OFFICIAL Sensitive NATIONAL CABINET	Off	N/A	N/A	N/A	N/A
PROTECTED (Category)	Off	N/A	N/A	N/A	N/A
PROTECTED	On	Private	Don't allow guests	Only people in your organization	Authentication Context: - Require MFA, - Managed Device; and - Trusted location.
PROTECTED - Personal Privacy	Off	N/A	N/A	N/A	N/A
PROTECTED - Legal Privilege	Off	N/A	N/A	N/A	N/A
PROTECTED - Legislative Secrecy	Off	N/A	N/A	N/A	N/A
PROTECTED CABINET	On	Private	Don't allow guests	Only people in your organization	Authentication Context: - Require MFA, - Managed Device; and - Trusted location.
PROTECTED NATIONAL CABINET	On	Private	Don't allow guests	Only people in your organization	Authentication Context: - Require MFA, - Managed Device; and - Trusted location.

Default labeling for SharePoint

Default labeling is a capability that allows for items created within SharePoint document libraries to automatically inherit a sensitivity label. Inherited labels are applied to any new or unlabeled items, and those with an existing label that is lower in order than the default label. Default labels can be used to help match the sensitivity of the site with that of the files stored within it.

Government organizations may be concerned by the obvious close proximity between default labeling options and requirements that prohibit the use of automatic classification, for example:

Requirement	Detail
PSPF Policy 8, Requirement 2a (Core Requirement): Assessing sensitive and security classified information (v2018.6)	To decide which security classification to apply, the originator must: i. Assess the value, importance, or sensitivity of official information by considering the potential damage to government, the national interest, organizations, or individuals, that would arise if the information’s confidentiality was compromised ... and ii. Set the security classification at the lowest reasonable level.

Default labeling in the Australian Government environment can be useful in situations where items are generated by systems. For example, if there was an application used as part of a business process, which creates items in bulk (a Power Automate flow for example). The location that the items are generated in could apply a default label. This ensures all items generated by the process have consistent labels applied.

Only newly created items, and those modified or moved to the location after the default setting is applied, will inherit the label. Labels can't be applied to existing files at rest in the location.

For organizations using label encryption, the following points should be noted with default labeling:

• Without coauthoring on encrypted content enabled (as mentioned in label encryption constraints), there may be a slight delay in applying the default sensitivity label for a document library when users select the File > Save as option.
• As with sensitivity labels for Office 365 for the web, some label configurations that apply encryption aren't supported for SharePoint. For example:
  • Let users assign permissions encryption options require user interaction and aren't appropriate for default labeling.
  • Options around user access expiry and Double Key Encryption may also be impacted.

For information on default labeling, see Configure a default sensitivity label for a SharePoint document library.