Edit

Share via

Sensitivity label taxonomy for the Australian Government

This article provides guidance for Australian Government organizations on required sensitivity labels to align with data security classifications. Its purpose is to assist organizations to decide on an appropriate sensitivity label taxonomy to deploy to their Microsoft 365 environments. Guidance in this article aligns with Protective Security Policy Framework (PSPF) PSPF Release 2024.

Australian Government organizations need to determine an appropriate sensitivity label taxonomy before deploying the capability. Required labels vary between organizations depending on the types of information that they work with.

Standard configuration

Typical label requirements include a combination of security classifications, often combined with an Information Management Marker (IMM) and/or caveats. Organizations with high compliance maturity are also likely to include labels to cater for various data security requirements. For example, labels that apply Azure Rights Management encryption to ensure that only authorized users can access items.

The following example demonstrates basic markings for Australian Government organization:

Marking or classification Information Management Marker Caveat
UNOFFICIAL
OFFICIAL
OFFICIAL: Sensitive
PROTECTED		 Personal Privacy
Legal Privilege
Legislative Secrecy		 CABINET

Note

PSPF includes several other caveats to cater for different situations, such as special handling requirements. These aren't discussed in this guide. Organizations needing to utilize these caveats need to add them to this base configuration.

Labels are singular and only one label can be applied to an item or location. Any required combination of these three items need to be assembled into a singular label to meet requirements. For example, if an item is required to be classified as PROTECTED, and it also contains CABINET information, then a single label containing these elements needs to be provided; PROTECTED CABINET.

The following example demonstrates basic labels for Australian Government organizations. This list makes use of a combination of parent labels (categories) and sublabels:

  • UNOFFICIAL
  • OFFICIAL
  • OFFICIAL Sensitive (Category)
    • OFFICIAL Sensitive
    • OFFICIAL Sensitive Personal Privacy
    • OFFICIAL Sensitive Legal Privilege
    • OFFICIAL Sensitive Legislative Secrecy
    • OFFICIAL Sensitive NATIONAL CABINET
  • PROTECTED (Category)
    • PROTECTED
    • PROTECTED Personal Privacy
    • PROTECTED Legal Privilege
    • PROTECTED Legislative Secrecy
    • PROTECTED CABINET

Note

PSPF Release 2024 Guidelines state that "the NATIONAL CABINET security caveat is being phase out as National Cabinet is no longer a committee of Cabinet. Entities are encouraged to remove this security caveat from use." Organizations who are newly deploying Microsoft Purview might omit this sensitivity label. For those that currently have it applied to information, it's recommended that the label be kept but removed from the sensitivity label policy. This allows for DLP and other data security controls to be maintained.

Government organizations with more complex requirements need extra labels. The maximum number of labels an organization wants to deploy is more relevant to usability constraints than technical limitations. However, there's a limit of 500 labels that can be created per organization.

The use of sublabels in the previous list is intended to improve user experience but also has some beneficial impacts to label behavior. For example, label change justification won't trigger when a user changes between sublabels. This allows users to apply different IMMs, caveats, or security controls and only trigger justification if they attempt to lower the applied security classification by moving outside of a label category.

Considerations regarding PROTECTED labeling

Australian Government organizations are able to configure their Microsoft 365 environments to store information up to the PROTECTED level. Microsoft's ability to store information at this level is independently assessed as part of the Infosec Registered Assessors Program (IRAP). The Microsoft 365 Cloud Security Assessment is publicly available via the Microsoft Service Trust Portal.

The Australian Signals Directorate (ASD) maintains the Information Security Manual (ISM), which is a cybersecurity risk management framework that helps to protect information technology systems from cyberthreats. This manual includes numerous requirements along with applicability markings, which designate the clearance levels that controls apply to.

Important

Deploying a PROTECTED label to a Microsoft 365 environment doesn't sufficiently provide for PROTECTED data security requirements. To keep data safe, the full set of ISM and other security requirements should be considered.

ASD maintain ASD's Blueprint for Secure Cloud, which is a great resource for guidance on how to configure Microsoft 365 environments securely. Guidance in this blueprint aligns with guidance provided in this Microsoft Purview guide and should be followed to help reduce the risk of data security incidents.

Accountable material

Accountable material is information that requires the strictest control over its access and movement. Organizations that work with or receive accoutnable material should consider creating one or more sensitivity labels to align with the information. This sensitivity label can be used in conjunction with Data Loss Prevention (DLP), encryption and other label-based controls to help protect the enclosed information. Sensitivity labels for accountable material could be configured as sublabels to the PROTECTED label.

Use of multiple IMMs

Some Australian Government organizations make use of classification taxonomies that allow for the application of more than one Information Management Marker (IMM) to each item. For example, 'OFFICIAL: Sensitive Legislative Secrecy Personal Privacy.' While this type of configuration can be achieved, requirements should be considered, in particular:

  • IMMs are derived from the Australian Government Recordkeeping Metadata Standard (AGRkMS) where it specifies that a single IMM value can be applied.
  • Protective Security Policy Framework (PSPF) Policy 8 states that IMMs are optional.

Microsoft's recommendation is to keep things as simple as possible. Only deploying labels that your organization actually needs improves the user experience as users have fewer labels to navigate. Having a smaller taxonomy also eases administration as there's less configuration to maintain, particularly across Data Loss Protection (DLP) and auto-labeling policies.

Organizations considering the use of multiple IMM combinations should consider the following potential complications:

  • Auto-labeling complications: Items with multiple IMMs applied are more difficult to match via auto-labeling as expressions to interpret subject markings or x-headers need to be able to accommodate them via the policies discussed in service-based auto-labeling recommendations.
  • Subject length: Email clients will often truncate or make it difficult to view long email subjects. In situations where multiple markings have been applied to a single email, users might be unaware of IMM or Caveat markings as they aren't visible.
  • X-header length: X-Protective-Marking x-headers, which are discussed in marking strategies are used to apply classification metadata to email. The amount of metadata that be applied to an email is dependent of several factors, including the email client being used. Organizations applying multiple IMMs to emails are likely to exceed the permitted x-header length, resulting in some classification metadata being truncated.

If multiple labels are required, ensure that elements are ordered from least to most important to your organization. For example:

  1. Security classification
  2. Caveat (if necessary)
  3. Most sensitive IMM
  4. Less sensitive IMM

Labels for information beyond PROTECTED level

Organizations that hold SECRET and above data need to utilize a secure enclave. The organization must implement network separation and a wide range of other measures to stop this information from leaving the enclave. If an item containing a SECRET marking appeared in a Microsoft 365 location, then the occurrence requires the organizations IT Security Advisor (ITSA) to perform data spill management. ASD provides guidance on how to manage remediation activities, see ASD data spill management guide.

Government organizations should consider implementing labels for information that shouldn't reside in their Microsoft 365 services. These labels aren't published directly to users, but are instead used to assist with the automated identification of items that shouldn't be on the platform. Such configuration assists security teams with identification and remediation activities.

Labels for this type of use vary between organizations, but could include:

  • PROTECTED (for organizations who work at OFFICIAL: Sensitive or below)
  • SECRET
  • TOP SECRET

As per ISM-0272, these labels shouldn't be published to users, as if the service isn't authorized to host such information, users shouldn't be able to apply the labels to items:

Requirement Detail
ISM-0272 (March 2025) Protective marking tools don't allow users to select protective markings that a system hasn't been authorized to process, store or communicate.

Note

*Unpublished labels refer to labels, which aren't published to end users. In order for a label to be considered by the auto-labeling service, they'll need to be published to a single user, such as an administrative or break-glass account.

In order to help prevent data spill, organizations should consider applying the following controls via these unpublished labels:

Labels for organizations with differing label taxonomies

Some Australian State Governments, such as the New South Wales and Queensland, make use of classification taxonomies that don't fully align with PSPF. This can create some challenges for how Federal Government organizations interpret the sensitivity of information that they receive from State Governments. Similar challenges exist for Federal Government organizations that correspond with foreign Governments, as classifications aren't likely to align.

The data security frameworks and standards applied by external organization's that your organization communicates with are highly relevant to your label taxonomy. External markings can be utilized with the following methods:

  • Markings applied by external organizations can be converted to a tenant equivalent

    For example, if an item with a 'QLD Government SENSITIVE' marking applied to it, is received by a Federal Government organization, the marking provides useful information on the item's sensitivity. A user could apply a label of 'OFFICIAL Sensitive' to the item to bring it into scope of the tenant's label-based protections. Alternatively, auto-labeling could be configured to automatically map this QLD marking to the OFFICIAL Sensitive label.

  • Organizations can maintain external classifications, and appropriate protections to information while they are custodians of it

    Rather than reclassifying items that don't align with your environment's sensitivity labeling, Microsoft Purview could be configured with a set of 'unpublished labels' that align with external classifications. These labels don't need to be selectable by users within label-aware clients. Instead they can apply service-based auto-labeling. Once received items are labeled, users aren't prompted to apply a label to them. The labels can also be aligned with a set of DLP and other controls to ensure that the contained information isn't inappropriately disclosed.

Alignment in label naming and marking methods between aligned organizations provides the best outcomes as it allows for simpler configurations. If alignment isn't achievable, agreement on classification equivalencies provides the next best alternative. The situation that should be avoided is external markings being completely disregarded, as it will likely to lead to data security incidents such as a data spill.

  1. Classification alignment (recommended, best practice)
  2. Classification equivalence (recommended if option one not possible)
  3. Classification disregarded (not recommended, increases risk of data spill)

Note

Where Government organizations interact with foreign Governments, PSPF Section 12 - Information sharing provides detailed guidance. For more information, see PSPF Release 2024.

Approach for classification alignment

If an organization were to decide to convert an external classification to a tenant equivalent, they would need to:

  1. Determine how the classification is to be identified. For example, via email subject marking, email x-header, keywords, or document property.
  2. Configure service-based auto-labeling to apply the relevant internal sensitivity label when items are identified, as explored in Service-based auto-labeling recommendations.

The benefits to this approach are that all data security controls that configured to help protect internal security classifications also apply to the aligning external information.

Approach for classification equivalence

If an organization decides to maintain an external classification within their environment, they would need to:

  1. Configure a sensitivity label for the external classification.
  2. Publish the label to a nonuser account to bring it within scope of the auto-labeling service.
  3. Determine how the external classification is to be identified on items. For example, via email subject marking, email x-header, keywords, or document property.
  4. Configure service-based auto-labeling to apply the hidden sensitivity label when items are identified, as explored in Service-based auto-labeling recommendations.
  5. Configure a set of DLP policies to protect items with the sensitivity label applied, as explored in Preventing inappropriate distribution of security classified information.

The following table is an example of how unpublished labels can be implemented with auto-labeling in order to maintain markings applied by external organizations. The example shows a set of PSPF labels, the bulk of which appear as sublabels to the OFFICIAL Sensitive parent label. Underneath this parent label, the user can choose to include labels that align with NSW and QLD equivalent Information Management Markers (IMMs):

PSPF labels
(published to all users)		 NSW Government
(unpublished labels)		 QLD Government
(unpublished labels)
UNOFFICIAL
OFFICIAL
OFFICIAL: Sensitive
- OFFICIAL: Sensitive
- OFFICIAL: Sensitive Personal Privacy
- OFFICIAL: Sensitive Legal Privilege
- OFFICIAL: Sensitive Legislative Secrecy
- OFFICIAL: Sensitive NATIONAL CABINET		 - OFFICIAL Sensitive NSW Cabinet
- OFFICIAL Sensitive Legal
- OFFICIAL Sensitive Law enforcement
- OFFICIAL Sensitive Health information
- OFFICIAL Sensitive Personal
- OFFICIAL Sensitive NSW Government		 - SENSITIVE

The benefits to this approach are:

  • Information landing in a federal government Microsoft 365 tenant, which has been labeled with NSW or QLD labels, will benefit from OFFICIAL: Sensitive data out of place alerting (further explained in data out-of-place alerting), which alerts and assists the prevention of data from being moved to locations where it could be inappropriately disclosed.
  • Data identification services, such as Content Explorer, can be used to identify where state-owned or generated sensitive information might reside across Microsoft 365 services.

Note

Without deciding on an approach for identifying and protecting information marked with external classifications, received information is likely to fall outside of classification-based data security controls. However, content based controls such as DLP policies targeting sensitive information, will still apply.

Azure Rights Management encryption

Azure Rights Management can be used to ensure that only authorized users can access content with a label applied. For information on setting up Azure Rights Management encryption, see how to set up message encryption.

Azure Rights Management is typically applied via sensitivity labeling. A label or set of labels can be configured so that when labels are applied to an item, they're encrypted with a set of permissions that govern who can access the item and how it can be used.

The following is examples demonstrate how an organizations label taxonomy could be expanded to provide encryption options to users:

  • A sublabel marked as Internal Only could be used to allow users to restrict items to internal users only.
  • A sublabel of Recipients Only could be used to ensure that emails can't be forwarded to unauthorized recipients.
  • A sublabel of Project Budgerigar Only could be used to ensure that only the subset of users who have need-to-know for Project Budgerigar and related information can access items.

Using these labels and associated controls alongside the basic set of OFFICIAL: Sensitive labels, the topology result is:

  • OFFICIAL: Sensitive
    • OFFICIAL: Sensitive Internal Only
    • OFFICIAL: Sensitive Recipients Only
    • OFFICIAL: Sensitive Project Budgerigar Only
    • OFFICIAL: Sensitive (no protection)
    • OFFICIAL: Sensitive Personal Privacy
    • OFFICIAL: Sensitive Legal Privilege
    • OFFICIAL: Sensitive Legislative Secrecy
    • OFFICIAL: Sensitive NATIONAL CABINET

There are some obvious challenges with the previous example, including:

  • The list of labels is a lot longer, which could impact usability.
  • The previous set of label options require users need to make decisions around whether to apply an IMM, CAVEAT, or encryption configuration, which presents a problem.

In such situations, protection of data should be considered paramount. IMMs are regarded as optional and shouldn't be included at the expense of data security measures like encryption. If label taxonomy needs to be shortened, consider dropping IMMs first or perhaps modifying label policies to ensure that they're only published to users that need them. Caveats, such as CABINET and NATIONAL CABINET, are likely more important than IMMs and shouldn't be omitted.

Note

As an organizations data security maturity increases, it's likely that they'll uncover new scenarios requiring protections. A result of this is that label taxonomy might expand over time as labels are added to accommodate new requirements.

Microsoft recommends limiting published labels to a core set required by users, and omitting any IMM and Caveat combinations that aren't likely to be required by your organization. Consider reporting via tools like Content Explorer to identify unused labels and removing them from your published set to allow room for configuration to grow without impacting usability or complexity.