Deploying sensitivity labels with label policies for the Australian Government

This article provides guidance for Australian Government organizations on Microsoft Purview sensitivity label policy configuration. Its purpose is to demonstrate how label policies can be configured to best align with requirements outlined in the Protective Security Policy Framework (PSPF) and Information Security Manual (ISM).

For sensitivity labels to be selectable by users for application to items, they need to be published via label policies. Label policies are configured within the Microsoft Purview portal under the information protection menu.

For step-by-step instructions on the standard process of creating a sensitivity label, see creating a sensitivity label. This article expands this guidance by providing configurations aligning with Australian Government requirements.

Label policy settings

Sensitivity label policies contain various policy settings, which control the behavior of the sensitivity label-aware clients. These settings are important to allowing Australian Government organizations to meet some key requirements.

Default label

The Default label option tells Microsoft 365 to automatically apply the selected label to items. To meet Australian Government PSPF and ISM requirements, the default label settings be set to none. Without preventing default application of labels, there's risk that security classifications weren't appropriately set.

Requirement	Detail
PSPF 2024 - 09. Classifications & Caveats - Requirement 60	The security classification is set at the lowest reasonable level.
ISM-0271 (March 2025)	Protective marking tools don't automatically insert protective markings into emails.

Label change justification

For Australian Government organizations, Microsoft recommends that label change justification is enabled.

For many organizations, information sensitivity is likely to change over time. Examples include embargoed information and media releases where, following information being made public, it no longer needs to be regarded as sensitive. Label change justification triggers in the event a user attempts to remove or lower an applied sensitivity label. The option requests that the user provides a reason for the change:

Auditing of label changes

All label changes and their justification responses are recorded in the audit log and are visible to administrators in Microsoft Purview Activity Explorer.

Audit log information, including events around label changes, can be ingested into Microsoft Sentinel or an equivalent Security Information and Event Management (SIEM) solution. These solutions can be configured to alert or report on any label changes.

Sensitivity label changes are also visible to Insider Risk Management , which can be configured to consider label downgrades as a sign of user risk, potentially blocking users from sharing data via Adaptive Protection if their risk level hits a configured threshold.

Tip

Insider Risk Management policies can also be configured to focus on particular sensitivity labels, such as PROTECTED, and to trigger alerting whenever these items have their sensitivity label lowered.

Label change justification doesn't trigger for changes between sublabels. If using a label taxonomy with IMMs under a parent label, users can add or remove an Information Management Marker (IMM) without needing to justify the action. This works in our favor as removal or addition of an IMM doesn't constitute a change in security classification. Note, however, that these label changes are recorded in the Microsoft 365 audit log.

Government organizations should also consider retention of label change justification responses. Audit log retention policies can be used to extend retention of this log information. More information on the audit log and options for log retention can be found in audit log.

Reclassification considerations

Label change justification is a feature where available options do differ from the intent of Government requirements. PSPF states that the originator of an item, which is defined as the entity that initially generated or received the information, must remain responsible for controlling its declassification or reclassification:

Requirement	Detail
PSPF 2024 - 09. Classifications & Caveats - Requirement 58	The originator remains responsible for controlling the sanitization, reclassification, or declassification of official and security classified information, and approves any changes to the information's security classification.

In addition, the ISM-1089 states that:

Requirement	Detail
ISM-1089 (March 2025)	Protective marking tools don't allow users replying to or forwarding emails to select protective markings lower than previously used.

The approach used in Microsoft Purview is one of 'trust but verify,' which allows users with permission to edit items and to adjust the label applied to those items. Label change justification provides monitoring and accountability for any changes.

Those considering PSPF reclassification requirements in line with Microsoft's 'trust but verify' approach should consider a combination of the following options to help mitigate declassification risks.

Blocking reclassified email

DLP can be used to identify and address declassification. Consider an email conversation which has been labeled as PROTECTED. This conversation includes one or more protective markings, such as a subject marking of [SEC=PROTECTED] within the email's body. A DLP policy can be constructed with conditions of:

• Content contains sensitivity labels: UNOFFICIAL, OFFICIAL, or OFFICIAL: Sensitive, and
• Content contains keyword 'SEC=PROTECTED'.

The above conditions provide a clear indication that the item has been reclassified with a lower sensitivity label. Blocking and reporting actions can be configured to action the occurrence. An example of an approach that assesses markings applied to items rather than sensitivity label can be seen in Controlling email of marked information via DLP.

Insider Risk Management controls

Insider Risk Management includes a long list of risk indicators that can be considered when determining a user's risk level. This includes indicators for lowering of an applied sensitivity label. Insider Risk Management also understands malicious patterns of use, such as lowering of the classification applied to an item followed by exfiltration.

Insider Risk Management alerts administrators users who repeatedly attempt to exfiltrate information as 'risky' and allow for security teams to intervene. This tool has the ability to ingest HR data feeds and correlate data exfiltration activities with HR signals, such as pending contract end date. This capability signals to administrators users with malicious intent can be identified and dealt with promptly, removing risk of malicious declassification and exfiltration.

To build on this even further, Adaptive Protection features can be enabled in Insider Risk Management, which can automatically restrict risky user's access and ability to exfiltrate labeled information following a risk event. This can help to secure information by implementing controls immediately rather than waiting for security teams to act on alerting.

Layering of DLP controls

Traditional DLP approaches were focused on a single identifier of item sensitivity, which was an item's security classification. Modern data classification techniques allow for the scanning and identification of sensitive content within items. When sensitive information is identified within an item, it can be protected regardless of the sensitivity label that might be applied to it. The layering of DLP policies to provide protection based on sensitivity label (item context) and the item's enclosed information (item content), provides a depth of protection that is superior to traditional classificaiton-only approaches.

Following the DLP configuration guidance provided in both preventing inappropriate distribution of security classified information and limiting distribution of sensitive information, will provide layered approach to data security that isn't dependent on classification alone.

Organizational policy

Microsoft recommends Australian Government organizations implement organizational policy-based controls as a method of meeting declassification requirements. This approach should be reinforced with user training and knowledge base articles, which can be made available to users via label aware clients more info links.

Preventing reclassification

For those that are adamant that they do want to prevent reclassification, there are two options natively available in Microsoft 365. These options do impact usability, so Microsoft recommends exploring DLP, Insider Risk Management, and organizational policy-based approaches first.

Encryption-based approach

Sensitivity label encryption can be configured with permissions that restrict user ability to modify item properties. Co-owner permissions permit property changes, including to the applied label, while coauthor permissions allow for items to be edited but not their properties. Such a configuration would need to be backed by a group structure to support the allocation of such permissions to those that require them. This configuration would also need to consider the other aspects to label encryption that are discussed in sensitivity label encryption.

Item level encryption, which is undoubtedly the future for data security, can have some impacts to existing services, such as records management systems which might be unable to index items in their encrypted format. There are also likely to be impacts when items need to be shared with external agencies, such as National Archives, who might need to complete their own indexing.

For more information on the required Azure Rights Management permissions to support this, see Configure usage rights for Azure Information Protection (AIP).

Label 'lock' approach

Section 24 and Section 26 of the Archives Act prohibits the disposal or alteration of certain Commonwealth records types. Label changes are metadata to a record and can constitute alteration of that record. To prohibit label changes, organizations can implement retention labels that utilize Microsoft Purview Records Management features to 'lock' items in a state. Once locked, items and their associated sensitivity label can't be changed, preventing reclassification. Configuring Microsoft 365 in such a manner helps organizations to meet both PSPF and Archive Act requirements for those Commonwealth records types.

For more information on preventing changes to items via records labels, see declare records by using retention labels.

Mandatory labeling

Label policies provide the ability to require users to select a label for documents and emails. This setting prompts users to select a label whenever they:

• Save a new item (file or email),
• Attempt to send an unlabeled email, or
• Change an item, which doesn’t already have a label applied.

This setting ensures that all items have protective markings and other associated controls applied.

Requirement	Detail
PSPF 2024 - 09. Classifications & Caveats - Requirement 59	The value, importance, or sensitivity of official information (intended for use as official record) is assessed by the originator by considering the potential damage to the government, the national interest, organizations, or individuals that would arise if the information's confidentiality were compromised.

Tip

While the mandatory labeling setting ensures that items have labels applied, it's recommended that client-based auto-labeling recommendations and configured and enabled to guide users on accurate label application. More information on this capability can be found in the Client-based Autolabeling article.

Label inheritance

The label inheritance setting allows for emails to inherit the sensitivity of their attachments. This comes into effect if an item with a higher sensitivity is attached to an email with a lower sensitivity label applied. This setting helps to ensure that highly sensitive items aren't inappropriately disclosed via lower sensitivity emails.

As with all auto-labeling processes, automation won't override a manually applied label. To obtain most benefit, Australian Government organizations should select both options. Selecting both options allows for newly created items to inherit attachment sensitivity. In situations where a user has already applied a label, the second option comes into effect and recommend that the email's sensitivity is increased to match.

This setting aligns with the following requirements:

Requirement	Detail
ISM-0270 (March 2025)	Protective markings are applied to emails and reflect the highest sensitivity or classification of the subject, body, and attachments.
ISM-0271 (March 2025)	Protective marking tools don't automatically insert protective markings into emails.

Label inheritance helps ensure that:

• Any mail-flow or DLP related controls that are tied to the email’s label (for example, those discussed in preventing email distribution of classified information) is applied based on the email's attachments.
• If the inherited label includes any advanced controls, such as label encryption, the email has these controls applied (as discussed in Sensitivity label encryption).

Custom help page

The custom help page option allows organizations to provide a link via a 'learn more' option displayed at the bottom of the label menu. The user is directed to the URL of a site providing information on how to correctly apply sensitivity labels and inform users of their marking or classification obligations.

Along with label tooltips, the 'learn more' website is be used by staff when determining which label is most appropriate for an item. This aligns with PSPF 2024 Requirement 60, as it assists users in their assessment of sensitive and security classified information.

Requirement	Detail
PSPF 2024 - 09. Classifications & Caveats - Requirement 60	The security classification is set at the lowest reasonable level.

Organizations typically make use of a staff intranet or similar location to publish content relevant to classification requirements and processes. This same site might be an appropriate target for this 'Learn More' link. There are other uses for such a site, which is further discussed in Data out-of-place alerting.

Multiple policies

Many organizations will be able to meet their label requirements with a single policy. Organizations with more granular requirements need extra policies. For example, an organization who wants their PROTECTED label and associated sublabels published to a subset of users, requires another policy to achieve this. A policy named protected label policy could be created, which has only the PROTECTED labels selected. The policy can then be published to a protected users group.

ASD's Blueprint for Secure Cloud recommends two policies, one for users up to OFFICIAL: Sensitive and another for up to PROTECTED. This will likely be a good approach for many organizations

Important

Restricting the ability to apply a label doesn't prevent access to information that has the label applied. To apply access restriction in concert with the label policy, configuration including Data Loss Prevention (DLP), authentication context and label encryption must be applied.

Policy ordering

Multiple label policies can be configured to deploy different sets of labels or different policy options to groups of users. In these scenarios, policy ordering is important. Users within the scope of multiple policies receive all labels that have been assigned to them via the various policies, but they'll only receive settings from the policy with the highest order.

Example label policies

The following label example demonstrates a typical policy configuration for Australian Government organizations. The protected policy below is intended to demonstrate how a set of labels can be published only to a subset of users and won't be required by every organization:

Policy name	Order	Labels published	Published to
All User Policy	0	- UNOFFICIAL - OFFICIAL - OFFICIAL: Sensitive - OFFICIAL: Sensitive Personal Privacy - OFFICIAL: Sensitive Legal Privilege - OFFICIAL: Sensitive Legislative Secrecy - OFFICIAL: Sensitive NATIONAL CABINET	All Users
Test Policy	1	All	Test user accounts
Protected Policy	2	- PROTECTED - PROTECTED Personal-Privacy - PROTECTED Legal-Privilege - PROTECTED Legislative-Secrecy - PROTECTED CABINET - PROTECTED NATIONAL CABINET	'Protected Users' Microsoft 365 group

These policies can be configured with the following settings, which best align with Australian Government requirements:

Policy option	Setting
Users must provide a justification to remove a label or lower its classification.	ON
Require users to apply a label to their emails and documents.	ON
Require users to apply a label to their Power BI content.	ON
Provide users with a link to a custom help page.	insert intranet-based help site URL
Default label for documents.	None
Default label for emails.	None
Inherit label from attachments. - Email inherits highest priority label from attachments. - Recommend users apply the attachment's label instead of automatically applying it.	ON ON
Default label for meetings and calendar events.	None
Require users to apply a label to their meetings and calendar events.	ON
Default label for sites and groups.	None
Require users to apply a label to their groups or sites.	ON
Default label for Power BI.	None

Label policy changes

Staff responsible for managing changes to label or label policy configuration should note that changes take a maximum of 24 hours for any changes to be deployed to users and to sync through to client devices. This should be factored into testing and technical change windows.

Tip

Where a configuration needs to be tested quickly by users, those users can sign out of their Microsoft 365 Apps Outlook or Office client and then sign back in. As the client signs in it receives a newer copy of the allocated policies, speeding the label or policy deployment process.