Requirements for Microsoft 365 capability mapping for Australian Government compliance with PSPF
This article is a key component of the Australian Government Information Protection Guide. It lists Protective Security Policy Framework, Information Security Manual (ISM), andAustralian Government Recordkeeping Metadata Standard (AGRkMS) requirements. It also provides advice on how Microsoft Purview and other Microsoft 365 capabilities can meet the stated requirements and provides links to other sections of the guide where these capabilities are further discussed. The article also provides guidance on state government frameworks, such as the Victorian Government Victorian Protective Data Security Framework (VPDSF).
Protective Security Policy Framework
The Protective Security Policy Framework (PSPF) is a set of policies designed to support Australian Government entities to protect their people, information, and assets. The PSPF outlines the requirements for entities to achieve the Government's desired protective security outcomes.
More information about PSPF, see Protective Security Policy Framework.
The PSPF policies that relate closely to Microsoft Purview Information Protection configurations are:
Key to understanding PSPF application to email services is PSPF Policy 8 Annex F: Australian Government Email Protective Marking Standard, which is referenced in this document.
PSPF includes a reporting mechanism that allows organizations to report on their level of maturity across the various PSPF policies. The intent is that this guide allows organizations with low levels of maturity to improve their PSPF Policy 8 and Policy 9 maturity to 'Managing' or 'Embedded' levels with reduced effort. For more information on PSPF maturity levels, see: Protective Security Policy Framework Assessment Report 2022-23
PSPF Policy 8: sensitive and classified information
Requirements are based on PSPF Policy 8 requirements V2018.8 (updated August 30 2023).
PSPF Policy 8 details how entities correctly assess the sensitivity or security classification of their information and adopt marking, handling, storage, and disposal arrangements that guard against information compromise.
This policy is split into core and supporting requirements. Comments on Microsoft 365 capabilities that align with the requirements and links to the relevant guidance on this site are provided in the following table. The policy can also be read in full at PSPF policy 8: Sensitive and classified information.
Core requirement A and supporting requirement 1: Identifying information holdings
| Solution capability | Section |
|---|---|
| Require users to identify the sensitivity of items (Files and Emails) via sensitivity labels. | Labeling client experience Mandatory labeling Sensitivity labeling PDF integration |
| Apply protective markings to locations (Sites and Teams) and apply protections to marked locations. | Sensitivity label groups and sites configuration |
| Define the sensitivity of meetings and implement associated operational controls. | Sensitivity labeling for calendar items and teams meetings |
| Require users to identify the sensitivity of Power BI workspaces via sensitivity labels. | Power BI and data integration |
| Apply labels to sensitive information residing in database systems. | Schematized data assets |
| Apply email headers, which can be used to identify the sensitivity of incoming items and apply appropriate controls. | Labeling of email during transport |
Core requirement B and supporting requirement 2: Assessing sensitive and security classified information
| Solution capability | Section |
|---|---|
| Provide users an opportunity to assess the value, importance, and sensitivity of items when selecting a sensitivity label. | Mandatory labeling |
| Guide users in the assessment of item sensitivity through label pop-up dialogue boxes containing label descriptions, visible during label selection. | Label description for users |
| Provides the ability to configure an organization specific Learn more link that is accessible from label selection menu and can provide users with further advice regarding appropriate labels for types of information. | Custom help page |
| Assists users in the assessment of information holdings by detecting under-classified items and recommending reevaluation where appropriate. | Recommending labels based on sensitive content detection |
| Assists with the assessment of information by identifying sensitive data that is taken from or exists within database applications or similar platforms. | Exact Data Match Sensitive Information Types |
| Assist with the assessment of information by utilizing machine learning to identify items that would typically be regarded as sensitive. | Trainable classifiers |
| Assist users in the assessment of information holdings by recommending labels that align with markings applied by external organizations. | Recommendations based on external agency markings |
| Assist users in the assessment of information holdings by recommending labels that align with historical markings. | Recommendations based on historical markings Auto-labeling Items with historical security classifications |
| Assist users in the assessment of information holdings by recommending labels that align with markings that have been applied by non-Microsoft classification solutions. | Recommendations based on markings applied by non-Microsoft tools |
| Assisting with the assessment of information by providing visual notifications to users via DLP Policy Tip when sensitive information is detected in an item. | DLP policy tips ahead of violation |
| Identify sensitive information residing within database systems, label the information in place and allow for the label to be inherited on downstream systems. | Power BI and Azure Purview Microsoft Purview Data Map |
Core Requirement C: Implement operational controls for these information holdings proportional to their value, importance, and sensitivity
| Solution capability | Section |
|---|---|
| Prevent the inappropriate distribution of security classified information by using Data Loss Prevention (DLP) policies based on sensitivity labels. | Protecting classified information |
| Prevent the inappropriate distribution of sensitive information by using Data Loss Prevention (DLP) policies targeting sensitive content. | Protecting sensitive information |
| Provide visual markings on individual items that reflect the security classification applied to information within the item. | Sensitivity label content marking |
| Provide visual markings that reflect the highest level of sensitivity that should exist within a location (site or team). | Sharepoint location and item sensitivity |
| Configure location privacy settings based on the sensitivity applied to the location. | Label privacy settings |
| Enable or disable guest access to a location and to items within a location based on the locations applied label. | Guest access configuration |
| Control Microsoft 365 sharing configuration for a SharePoint based location (site or Team) depending on the label applied to the location. | Label sharing configuration |
| Provide user notification and alerting for highly sensitive items located in lower sensitivity locations. | Data out of place alerting |
| Configure other requirements for access to highly sensitive locations (sites or Teams). For example, from unmanaged devices, unsafe devices, or unknown locations. | Conditional access Authentication context Protecting classified information Controlling sharing through adaptive protection |
| Encrypt highly sensitive items to prevent access by unauthorized users, regardless of an item’s location. | Sensitivity label encryption |
| Configure access and usage restrictions for groups of internal users or guests. | Allocating label encryption permissions |
| Restrict the movement of security classified items and/or their contained information to locations where access or further distribution of their enclosed information can't be controlled. | Preventing download or print of security classified items Preventing upload of security classified items to unmanaged locations |
Supporting requirements
Requirement 1: Identifying information holdings
There are no extra supporting requirements beyond the core requirements.
Requirement 2: Assessing sensitive and security classified information
There are no extra supporting requirements beyond the core requirements.
Requirement 3: Declassification
| Solution capability | Section |
|---|---|
| Record an auditable trail of all label related activities, including the removal or lowering of applied sensitivity labels. Record label change activities including the user who made the change and their justification for doing so. |
Label change justification Audit log |
| Apply encryption to items that restrict internal or guests ability to modify items, preserving the item and applied marking/classification. | Allocating label encryption permissions |
| Locking items in place to prevent any item changes, including the ability to change the applied sensitivity label. | Label 'lock' approach |
| Report on users who are undertaking activities deemed to be risky to information security, including label downgrade and exfiltration sequences. | User-risk based approach Monitoring Sharing through Insider Risk Management Controlling sharing through adaptive protection |
| Implement DLP policies to detect protective markings within items alert if the currently applied label is lower than the identified marking. | Implications to malicious label downgrade |
Requirement 4: Marking information
| Solution capability | Section |
|---|---|
| Office clients provide clear identification of an item’s sensitivity via client-based label markings. | Labeling client experience |
| Apply text-based protective markings to mark sensitive and security classified information. | Sensitivity label content marking Information marking strategies |
| Apply colour-coded markings to assist users with sensitivity identification. | Label color |
| Apply protective markings via email metadata (x-headers). | Applying x-protective-marking headers via DLP policy |
| Apply protective markings via email subject. | Applying subject-based email markings |
| Apply markings to locations, such as sites or Teams. These markings identify the highest level of item sensitivity that should exist at the location/container. | Data out-of-place alerting |
| Clearly identify item sensitivity to users when working in SharePoint-based directories (sites, Teams, or OneDrive). | SharePoint location and item sensitivity |
Requirement 5: Using metadata to mark information
| Solution capability | Section |
|---|---|
| Index Security Classification and Security Caveat and Dissemination Limiting Marker properties via SharePoint search, aligning with AGRkMS requirements. | Managing classification and caveat metadata |
| Apply X-Protective-Marking x-headers to meet email metadata requirements as per PSPF Policy 8 Annex F. | Applying x-protective-marking headers via DLP policy |
| Apply metadata to database columns containing sensitive information in connected database systems. | Power BI and data integration |
Requirement 6: Caveats and accountable material
| Solution capability | Section |
|---|---|
| Mark caveated information and associated Dissemination Limiting Markers (DLMs) or classification via sensitivity label structure. | Required sensitivity label taxonomy |
| Mark caveats on associated items via text. | Sensitivity label content marking Subject-based markings |
| Record all incoming and outgoing material transfer. | Audit log |
| Apply Caveat distribution and/or access restrictions. | Limiting distribution of sensitive information Sensitivity label encryption |
Requirement 7: Minimum protections and handling requirements
| Solution capability | Section |
|---|---|
| Information stored in Microsoft 365 datacenters is encrypted at rest via BitLocker encryption. | Encryption overview |
| Require TLS encryption for email-based transmission of sensitive items, ensuring that they're encrypted when transferred via public networks. | Requiring TLS encryption for sensitive email transmission |
| Configure granular access control to marked locations (sites or Teams) and block users, devices, or locations who don't meet access requirements or clearance. | Unmanaged device restrictions Authentication context |
| Maintain need-to-know principles by restricting sharing, guest access, and controlling the privacy configuration of marked locations. | Sensitivity label groups and sites configuration |
| Apply DLP policies to help ensure need-to-know and restrict the distribution of items to unauthorized or uncleared internal users and external organizations. | Limiting distribution of sensitive information |
| Encrypt sensitive or security classified items, providing access control and ensuring that only authorized users have access to the contained information, regardless of the item’s location. | Sensitivity label encryption |
| Apply protections, including encryption, sharing, and DLP related controls to exports or PDFs generated from labeled source systems. | Power BI and data integration |
| Identify items marked with historical security classifications and either autoalign with modern markings or maintain the historical label along with required controls. | Recommendations based on historical markings |
Requirement 8: Disposal
| Solution capability |
|---|
| Implement retention policies, retention labeling, data life cycle and records management configurations, including disposition review, to support archive and records requirements. |
| Align security marking, retention label/policy, and associated disposition where required (noting that security and archive seldom align). |
| Implement retention policies that either permanently remove information once item retention requirements are met, or provide records management teams with disposition review capability that allow for the screening of items before their permanent deletion. |
These articles relate to Microsoft Purview Data Lifecycle Management then Information Protection and are outside scope of this guidance. For guidance on Microsoft Purview Data Lifecycle Management, see lifecycle management.
Requirement 9: Sensitive and security classified discussions
| Solution capability | Section |
|---|---|
| Apply protective markings to Teams meeting invitations and Outlook calendar items. Apply controls to calendar items, such as encryption of meeting attachments. |
Labeling of calendar items |
| Apply protective markings to Teams meetings and configure advanced controls to protect classified conversations, including advanced encryption techniques and meeting watermarks. End-to-end encryption of Teams conversations, providing users with assurance that sensitive or security classified discussions can't be intercepted. |
Teams Premium label configuration |
PSPF Policy 9: Access to information
Access to information is based on PSPF Policy 9 requirements V2018.6 (updated August 16 2022).
PSPF Policy 9 is concerned with the access of timely, reliable, and appropriate access to official information.
As with Policy 8, Policy 9 is split into core and supporting requirements.
Comments on Microsoft 365 capabilities that align with the requirements and links to the relevant sections in this document are provided in the following table.
For information on the PSPF policy source, see: PSPF policy 9: Access to information.
Core Requirement A: Enable appropriate access when sharing information within the entity and with other relevant stakeholders
| Solution capability | Section |
|---|---|
| Restrict sharing, privacy and/or guest access based on the sensitivity label applied to a Team or SharePoint location. | Sensitivity label groups and sites configuration |
| Restrict sharing or caution users when they attempt to share labeled content with unauthorized internal or external groups. | Preventing inappropriate distribution of security classified information Limiting distribution of sensitive information |
| Prevent delivery of labeled emails or email attachments to unauthorized recipients. | Preventing email distribution of classified information to unauthorized organizations Preventing email distribution of classified information to unauthorized users |
| Restrict the upload of labeled content to nonapproved cloud services or locations where it can be further distributed or accessed by unauthorized users. | Preventing the upload of security classified items to unmanaged locations |
| Prevent access to labeled items (files or emails) by unauthorized users in situations where they have been shared inappropriately. | Sensitivity label encryption |
| Prevent labeled items from being uploaded to nonapproved cloud services. Prevent them from being printed, copied to USB, transferred via Bluetooth or unallowed app. | Preventing sharing of security classified information Preventing the download or printing of security classified items |
Core Requirement B: Ensure that individuals who access sensitive, or security classified information have appropriate security clearance and need to know that information
| Solution capability | Sections |
|---|---|
| Restrict access to locations that contain sensitive or classified information to only users that are authorized. | Authentication context |
| Integrate sensitivity labeling and DLP. Policies can be constructed to prevent the sharing (via email or share action) of items with certain markings with unauthorized users. | Preventing email distribution of classified information to unauthorized organizations Preventing email distribution of classified information to unauthorized users Preventing sharing of security classified information |
| Provide DLP policy tips, which warn users against sharing information ahead of policy violation, reducing the likelihood of information disclosure due to situations like mistaken identity. | DLP policy tips ahead of violation |
| Monitor, alert and/or block attempts to share or email labeled items to users who don't have appropriate security clearance. | DLP event management |
| Configure Privacy options for sites or Teams based on a location’s marking. This helps to prevent open access to locations for users who don't have need-to-know and puts Team or location owners in control of access to these locations. It also helps to meet Supporting Requirement 2 by not automatically providing access based on status, rank, or convenience. | Label privacy settings |
| Configure Sharing Restrictions for a site or Team, which ensures that items in marked locations can only be shared with internal users. | Label sharing configuration |
| Use label encryption to control access to labeled content, ensuring that only authorized users have the ability to access it. | Enabling label encryption |
| Alert on security classified or marked information from being moved to lower sensitivity locations where they're more easily accessed by unauthorized users. | Data out-of-place alerting |
Core Requirement C: Controlling access (including remote access) to supporting ICT systems, networks, infrastructure, devices, and applications
| Solution capability | Sections |
|---|---|
| Allows the use of Conditional Access (CA) to restrict access to the Microsoft 365 application to approved users, devices, and locations, only when appropriate authentication requirements are met. | Conditional access |
| Provide granular access control to sensitive or security classified labeled locations. | Authentication context |
| Assess user authentication and authorization at time of access to encrypted items (files or email). | Sensitivity label encryption |
Supporting requirements
Supporting Requirement 1: Formalized agreements for sharing information and resources
| Solution capability | Sections |
|---|---|
| Configure Terms of Use as part of a Conditional Access policy, so that guests are required to agree to terms before access to items is permitted. This complements written agreements between organizations. | Microsoft Entra Business to Business (B2B) configuration is out of scope of this guide1. The concepts are introduced under conditional access. |
| Implement restrictions to prevent the sharing of not only security marked or classified information, but also other types of sensitive information with external organizations. Exceptions can be applied to these policies so that sharing is allowed to an approved list of organizations for which formal agreements are established. | Limiting distribution of sensitive information |
| Configure encryption to restrict access to information (files or email) to guests except for users or organizations for which permissions are configured. | Sensitivity label encryption |
| Configure guest access to permit collaboration activities (including sharing, coedit, chat, and Teams membership) only with approved organizations that formal agreements exist with. | Microsoft Entra B2B configuration is out of scope of this guide1. The concepts or restricting guest access to labeled items are introduced under guest access configuration |
| Audit guest access and membership, prompting resource owners to remove guests when no longer required and recommending removal when resources aren't being accessed. | Microsoft Entra B2B configuration is out of scope of this guide1, 2. |
Note
1 For more information about Microsoft Entra B2B configuration, see Microsoft Cloud Settings for B2B collaboration.
2 For more information on access reviews, see access reviews
Supporting Requirement 2: Limiting access to sensitive and classified information and resources
There are no extra requirements beyond Core Requirement B.
Supporting Requirement 3: Ongoing access security classified information and resources
| Solution capability | Sections |
|---|---|
| Configure DLP policies to prevent the distribution of security classified information to users who aren't cleared to the appropriate level. | Preventing email distribution of classified information to unauthorized organizations |
| Limit access to locations containing security classified (or caveated) information to individuals who are cleared to the appropriate level. | Authentication context |
| Help prevent security classified or marked information from being moved to lower sensitivity locations where they're easily accessed by unauthorized users. | Data out-of-place alerting |
| Configure encryption to ensure users who leave the organization no longer have access to sensitive material. | Sensitivity label encryption |
Supporting Requirement 4: Temporary access to classified information and resources
| Solution capability | Sections |
|---|---|
| Configure label encryption to grant temporary access to sensitive items and revoke the access after a period of time, making the items unreadable by their recipient. | Content access expiry |
Supporting Requirement 5: Managing access to information systems
| Solution capability | Sections |
|---|---|
| Configure Conditional Access (CA) policies to require user identification, authentication, including other 'modern authentication' factors, such as MFA, managed device or known location, before granting access to services. | Conditional access |
| Apply other conditional access requirements to users when they access locations, which are marked with certain labels. | Authentication context |
| Configure label encryption, which confirms identity, authentication and authorization each time an encrypted item is accessed by a user. | Sensitivity label encryption |
Information Security Manual (ISM)
The purpose of the Information Security Manual (ISM) is to outline a cyber security framework that organizations can apply, using their risk management framework, to protect their information and systems from threats. The manual contains controls that Government organizations, and others who work under the PSPF for Australian Federal, State, and Local governments should implement, and at the appropriate level associated with the classification of data that they're managing.
The intent of this Microsoft Purview Information Protection guide isn't to replace any detailed work that organizations should be doing to assess their alignment with the ISM. It's intended to guide organizations on Microsoft 365 configuration that align with ISM controls.
For broader guidance on appropriate Microsoft 365 configuration, we recommend ASD's Blueprint for Secure Cloud.
The ISM requirements discussed in this section refer to ISM version - March 2023.
The following ISM requirements are relevant to a Government organizations Microsoft Purview Information Protection configuration:
ISM-0270: Protective markings are applied to emails and reflect the highest sensitivity or classification of the subject, body, and attachments
| Solution capability | Sections |
|---|---|
| Label inheritance ensures that an email is marked according to the highest sensitivity that is applied to the item or attachment. | Label inheritance |
| Identify sensitive information and recommend a marking of higher sensitivity is applied if an item is under classified. | Client-based auto-labeling Identifying sensitive information |
ISM-0271: Protective marking tools don't automatically insert protective markings into emails
| Solution capability | Sections |
|---|---|
| Require users to select an appropriate sensitivity label for each item (file or email) and ask them for a label if they haven't applied one. | Mandatory labeling |
| Configure label recommendations to suggest that a label is applied following the detection of sensitive content, while leaving determination up to the user. | Client-based auto-labeling recommendations |
ISM-0272: Protective marking tools don't allow users to select protective markings that a system isn't authorized to process, store or communicate
| Solution capability | Sections |
|---|---|
| Users are only able to select and apply sensitivity labels to items that are published to them via a labeling policy. | Sensitivity label policies Labels for information beyond protected level Blocking transmission of nonpermitted classifications |
ISM-1089: Protective marking tools don't allow users replying to or forwarding emails to select protective markings lower than previously used
| Solution capability | Sections |
|---|---|
| Noting differences between this control and Microsoft 365 approach, Purview can be configured to require business justification in order to remove or lower a sensitivity label. This information is retained in the audit log, displayed through data classification portals and can be exported via Security Information and Event Management (SIEM) solutions such as Sentinel. This information is also factored into Insider Risk Management (IRM) metrics, which can be used to identify risky users and prevent them from undertaking nefarious activities. | Controlling email of marked information via DLP Implications to malicious label downgrade Label change justification Audit Log Preventing sharing of security classified information |
| Configure label-based encryption and rights management to prevent changes to labeled items for users that don't have sufficient permissions, preventing label changes. | Sensitivity label encryption |
ISM-0565: Email servers are configured to block, log, and report emails with inappropriate protective markings
| Solution capability | Sections |
|---|---|
| Implement DLP policies to prevent the receipt and further distribution of items with classifications that aren't permitted in the platform. | Blocking transmission of nonpermitted classifications |
| Configure DLP policies or Exchange Mail Flow Rules to block, log, and report emails with missing markings. | Mandatory labeling Blocking transmission of unlabeled email |
ISM-1023: The intended recipients of blocked inbound emails, and the senders of blocked outbound emails, are notified
| Solution capability | Sections |
|---|---|
| Configure DLP policies or Exchange Mail flow rules with different notification options based on recipient. | Blocking transmission of unlabeled email |
ISM-0572: Opportunistic TLS encryption is enabled on email servers that make incoming or outgoing email connections over public network infrastructure
| Solution capability | Sections |
|---|---|
| Opportunistic Transport Layer Security (TLS) is configured by default in Exchange Online. Configure email connectors to set TLS encryption as mandatory for the transmission of sensitive emails, without the need to enforce these requirements on lower-sensitivity items. |
Requiring TLS encryption for sensitive email transmission |
ISM-1405: A centralized event logging facility is implemented and systems are configured to save event logs to the facility as soon as possible after each event occurs
| Solution capability | Sections |
|---|---|
| The unified audit log provides centralized event logging for all Microsoft 365 services. | Audit log |
ISM-0859: Event logs, excluding those for Domain Name System services and web proxies, are retained for at least seven years
| Solution capability | Sections |
|---|---|
| Audit logs can be retained for up to 10 years via audit log retention policies. This period can be further extended via integration of Microsoft 365 with a SIEM solution such as Sentinel. | Audit log |
ISM-0585: For each event logged, the date and time of the event, the relevant user or process, the relevant filename, the event description, and the ICT equipment involved are recorded
| Solution capability | Sections |
|---|---|
| Microsoft 365 audit log captures user and administrative event details. For each event relevant details such as item, user, activity completed, and event time are all recorded. Audit logs capture events for label-related activities such as label application and changes. |
Audit log |
ISM-0133: When a data spill occurs, data owners are advised and access to the data is restricted
| Solution capability | Sections |
|---|---|
| Configure DLP policies to detect data spills, and notify appropriate parties upon detection. | Blocking transmission of nonpermitted classifications |
Australian Government Recordkeeping Metadata Standard
The version of the AGRkMS requirements referred to in this guide is AGRkMS V2.2 (June 2015).
The Australian Government Recordkeeping Metadata Standard (AGRkMS) and the accompanying AGRkMS guide sets out the type of metadata that Australian Government agencies should include in their business systems and specifies the minimum mandatory requirements.
Among these requirements are metadata properties for 'Security Classification' and 'Security Caveat,' which align to the PSPF Policy 8.
The standard includes a statement of purpose for the inclusion of these metadata properties. As with the requirements mentioned in the previous sections, the intent of these AGRkMS’s inclusion of these properties in this standard aligns with capabilities provided by Microsoft Purview Information Protection and associated Microsoft 365 tools:
| Requirement | Sections |
|---|---|
| 1. To facilitate or restrict access to records, or to particular business functions, activities or transactions, by agency staff or the public (Classification and Caveat). 2. To prevent access to records, or to particular business functions, activities, or transactions, by users with insufficient security permissions (Classification). 3. To enable restriction of access to records by those with insufficient security permissions (Caveat). |
Preventing inappropriate distribution of security classified information Label guest access settings Label sharing configuration Authentication context Data out of place alerting |
| 4. To enable records, business functions, activities or transactions, and mandates with security sensitivities to be appropriately identified and managed (Classification and Caveat). | Labeling client experience Label content marking SharePoint location and item sensitivity |
| 5. To alert users to security restrictions on access to records and mandates (Classification and Caveat). | Preventing email distribution of classified information to unauthorized organizations Preventing sharing of security classified information |
| 6. To prevent discovery of the nature of the information or activity covered by particular security compartments (Classification and Caveat). | Compliance boundaries |
These metadata requirements can be met on the Microsoft 365 platform without any advanced metadata manipulation. However, Government organizations aspiring to make use of Microsoft 365 for in-place records management and who want to meet AGRkMS requirements in their entirety should consider the advice provided in the managing classification and caveat metadata section of this guide.
State Government requirements
The following section provides references to State Government requirements and some high-level notes on how their frameworks differ from Federal Government.
Australian Capital Territory
The Australian Capital Territory (ACT) government makes use of the ACT Government Protective Security Policy Framework (PSPF), which is similar to the Federal Government standard in intent, required labels, and Information Management Markers (IMMs). Therefore, the advice in this guide is directly applicable to ACT Government.
New South Wales
New South Wales State (NSW) government uses the NSW Government Information Classification, Labeling and Handling Guidelines.
These requirements align with the Federal PSPF standard at a high level as both sets of requirements make use of UNOFFICIAL to PROTECTED labels. However, the NSW standard makes use of a different set of Dissemination Limiting Markers (DLMs) that don't align with the Federal labels:
"The OFFICIAL: Sensitive label is applied by the Australian Government, and other states and territories. The NSW Government won't apply this label to its information because the six DLMs used in NSW with the OFFICIAL: Sensitive prefix allows for the specificity required in NSW. This means that information labeled OFFICIAL: Sensitive is deemed to have originated from outside of NSW Government."
This means that sensitive NSW Government information isn't marked with federal labels, but is treated separately. For example, the label of 'OFFICIAL Sensitive - NSW Government' has no PSPF equivalent so translation to a PSPF label isn't appropriate.
There are a three options that Federal Government organizations who collaborate with NSW Government should consider when designing their MPIP configuration:
- Use of hidden labels where the admin implements a set of labels that aren't published to users, but available to the auto-labeling service. Hidden labels allow for information generated by State Government organizations to receive similar protections to internal information without the need to relabel items with PSPF markings. For more information, see labels for organizations with differing label taxonomies.
- Use of Sensitive Information Types (SIT) where organizations implement a set of SITs, which identify information marked with NSW Government labels. These SITs are used in DLP and other policy types to ensure that the information is treated appropriately. For more information, see custom sensitive information types.
- Use of NSW aligned labels where organizations opt to apply labels to information received that most closely align with NSW Government markings. This can be manually actioned by users, potentially with the assistance of auto-labeling to suggest the most appropriate (OFFICIAL: Sensitive in most cases). Using this approach, NSW visual marking still apply to items and are complemented with Federal equivalents on reply emails. This would help to ensure that the information is protected in line with tenant configurations while it resides in the environment. For more information, see recommendations based on external agency markings.
These options are also relevant to NSW Government organizations who are considering how best to handle information that is received with Federal PSPF markings, or markings applied by other State’s Governments.
Northern Territory
The Northern Territory (NT) government makes use of the Northern Territory Government Public Sector Organization (NTG PSO): Security Classification System.
This system has partial alignment with Federal PSPF as UNCLASSIFIED and PROTECTED labels exist in the framework. However, it also makes use of CONFIDENTIAL and PUBLIC labels, meaning that organizations collaborating with the NT Government should consider methods for label translation or identification of NT Government CONFIDENTIAL information via the methods mentioned previously in the NSW government section in order to ensure that the information is secured while it resides in Federal Government Microsoft 365 environments.
NT Government organizations should consider the advice in this document but add a PUBLIC label and substitute OFFICIAL: Sensitive for CONFIDENTIAL labels. The above points around protecting information from other jurisdictions are also relevant, so NT should implement Sensitive Information Types, unpublished labels, or client-based labeling recommendations as discussed in the NSW section.
Queensland
Queensland Government organizations are required to adhere to the Queensland Government Information Security Classification Framework (QGISCF)
Like NSW and NT, the Queensland government requirements differ from PSPF - but QGISCF does make use of a similar topology of OFFICIAL, SENSITIVE, and PROTECTED labels and information provided in this document is relevant.
The QGISCF is intended to be compatible with the Australian Government Protective Security Policy Framework and Australian Government Information Security Manual. Because of this, Federal Government organizations should use auto-labeling to translate the information they receive from Queensland Government organizations into equivalent PSPF labels (SENSITIVE to OFFICIAL: Sensitive for example) to ensure that such information is within the scope of DLP and other protections while it resides in Federal Government Microsoft 365 environments. The reverse is applicable to Queensland Government organizations receiving Federal Government information.
South Australia
The South Australian (SA) Protective Security Framework (SAPSF) includes a policy named 'INFOCEC1: Protecting Official Information.' This policy aligns with the federal standard at a high level, noting some variations in terms of information management markers and caveats (for example, SA CABINET and Medical in Confidence). Due to this alignment, Federal Government organizations should be able to identify and protect sensitive SA Government items without significant variation to their configurations. The advice provided in this document is relevant to SA Government without significant need for translation into local markings.
Federal Government organizations receiving information from SA Government agencies should consider how SA Government information is protected within their environments. Establishment of SITs or nonpublished sensitivity labels to capture SA specific markings and DLP policies to apply appropriate protections (as covered under labels for organizations with differing label taxonomies), as appropriate.
SA Government organizations using this guide should consider that the SAPSF framework doesn't specify email metadata requirements such as X-Headers. This is a gap as without the specification, SA Government organizations may have difficulty maintaining classifications and associated protections as information is passed between organizations. Use of the Federal PSPF standard for this is appropriate for achieving email label translation (as covered in labeling of email during transport).
The approach used in PSPF X-Protective-Marking headers can be adapted to cover SA specific labels such as SA CABINET and Medical in Confidence. Some SA Government organizations have implemented PSPF style metadata regardless of it not being included in SAPSF. An example of this would be setting an X-Protective-Marking header of “VER=2018.6, NS=sa.gov.au, SEC=OFFICIAL”. This approach mitigates risks associated with sharing information between SA government organizations and providing a marking that other states and Federal organizations can use to determine the enclosed information’s required protections.
Tasmania
The Information Security Classification Standard for the Tasmanian (TAS) Government is a draft and under review.
For information on markings currently in use by TAS Government, see TAS Information Security Classification
Federal Government organizations wanting to ensure that they protect information received from TAS Government should utilize controls that are in place to help protect legacy information under the previous version of the PSPF. For more information, see Recommendations based on historical markings.
Victoria
The Victorian (VIC) State Government framework is the Victorian Protective Data Security Framework (VPDSF) is similar to SA but still closely aligns with the Federal PSPF.
Victorian State Government organizations should consider the advice provided in this guide as relevant to their own environments.
For the VIC framework, the difference to the markings applied via email x-headers for domain and version values. Victorian Government Cabinet markings also differ to that of Federal Government, so Victorian Government organizations should note a special handling x-header of 'SH:CABINET-IN-CONFIDENCE' is required in place of the 'SH:NATIONAL-CABINET.' For more information on special handling, see applying x-protective-marking headers via DLP policy.
Western Australia
The Western Australian (WA) Government has an Information Classification Policy, makes use of UNOFFICIAL, OFFICIAL, and OFFICIAL: Sensitive labels, which align closely with Federal Government PSPF classifications. However, access and other requirements differ.
The policy states "For the protection of Commonwealth security classified information, agencies are required to comply with the provisions of the relevant inter-jurisdictional agreement(s)." This means Federal Government requirements are required to be considered by WA Government Agencies.
WA Government customers should consider the advice provided in this document for its relevance to their own configurations.
For Federal Government organizations receiving information from WA Government organizations, as WA approach aligns with Federal, the auto-labeling and other configurations covered in this guide help to ensure that such information is protected while it resides in Federal Microsoft 365 environments.