ASD ISM 0272 Restrict protective marking tools to authorised system markings
What it says
Protective marking tools do not allow the selection of protective markings that a system has not been authorised to process, store or communicate.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishConfigure protective marking tools so users can only choose classifications the system is authorised to handle, blocking over-classified content from being created on the wrong system.
Protective marking tools are the add-ins and features (in email clients, office suites and similar applications) that let a user pick a classification such as OFFICIAL, OFFICIAL: Sensitive, PROTECTED or SECRET and stamp it on a document or message. Every system is authorised to process, store or communicate information up to a particular level. This control requires that the marking tool only offers markings up to that authorised level, and nothing higher, on each system. Why it matters: if a user on a system authorised only for OFFICIAL: Sensitive can select PROTECTED from a drop-down list, they can create, save and send PROTECTED information on a system that was never assessed or secured to handle it. The marking tool is often the first place where a user declares how sensitive the content is, so limiting the available choices stops the problem at its source. It also keeps automated controls (email gateways, data loss prevention and file handling rules) consistent, because content cannot be labelled at a level the system does not support.
Free. Save your status, tasks and notes.
Why it matters
If marking tools offer classifications above what a system is authorised for, users can generate and store information at those higher levels on infrastructure that lacks the required protections. That information may be transmitted over connections, stored on media or backed up to services that have not been authorised for it, creating a spill. Higher-marked content also becomes a magnet for attackers if the system is compromised. The organisation may breach its authorisation conditions and government protective security obligations, face costly spill investigations and clean-up, and lose confidence in the accuracy of its markings across all systems.
How to implement
System owners and the security team document, for each system, the highest protective marking it is authorised to process, store or communicate, and derive the exact list of markings the marking tool may offer on that system.
Endpoint or messaging administrators configure the protective marking tool (email add-in, office suite labelling, or equivalent) with only the permitted markings, removing or hiding every higher marking from the selection list rather than relying on user judgement.
Administrators deploy and enforce the marking configuration centrally through group policy, MDM profiles, the tool's management console or a locked configuration file, and set permissions so end users cannot edit the marking list locally.
The change manager adds a mandatory check to the change process for marking tools, standard operating environment images and application upgrades, requiring a tester to confirm the available markings still match the system's authorisation before release.
The security team, when a system's authorisation changes, raises a linked change to update the marking tool configuration on that system and verifies on a sample of endpoints that the new marking list has taken effect.
Keep it running
Day to day, this control lives in the configuration of the marking tools deployed to endpoints and mail clients. Administrators maintain a per-system (or per-network) marking policy that lists the permitted markings, and that policy is pushed centrally through the tool's configuration file, registry settings, group policy or management console so users cannot alter it.
Keep the list tied to each system's authorisation: when a system is authorised for a new level, or its authorisation is reduced, the marking tool configuration must be updated in step. Include a check of the available markings in change management for the marking tool, new operating system images and application upgrades, because vendor updates can reset defaults to a full marking set. Spot-check workstations periodically by opening the marking tool and confirming only the expected options appear, and review any user requests to "add a missing classification" as a potential sign that the wrong system is being used for that work.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the register or authorisation documentation showing the highest protective marking each in-scope system is authorised to process, store or communicate.
Look at
Check that every system running a marking tool has a clearly recorded authorised level and that the record is current.
Good evidence
Each system has an unambiguous authorised marking level, and the security team can readily map it to the marking tool configuration used on that system.
- Check 2 of 5What an auditor asks for
Ask for
Ask for the marking tool configuration (policy file, group policy object, MDM profile or console export) applied to each system.
Look at
Compare the list of selectable markings in the configuration with the authorised level for that system, looking for any marking above the authorised level.
Good evidence
The configuration offers only markings at or below the authorised level, and the configuration is the one actually deployed rather than a draft.
- Check 3 of 5What an auditor asks for
Ask for
Ask to observe a user workstation or mail client on each system while a staff member opens the marking tool to classify a new message or document.
Look at
Watch which markings appear in the selection list and try to choose a marking above the system's authorised level.
Good evidence
Higher markings are not visible or selectable, and the observed behaviour matches the documented configuration.
- Check 4 of 5What an auditor asks for
Ask for
Ask how the marking configuration is protected from local change, including the permissions on configuration files or settings and whether users have administrative rights.
Look at
Review the enforcement mechanism (central policy, locked files, read-only registry keys) and any evidence that user edits are prevented or overwritten.
Good evidence
The marking list is centrally enforced, users cannot alter it, and any local drift is reset by policy refresh.
- Check 5 of 5What an auditor asks for
Ask for
Ask for change records for recent marking tool updates, image rebuilds or authorisation changes affecting in-scope systems.
Look at
Look for a test or verification step confirming that the selectable markings still matched the system's authorisation after the change.
Good evidence
Each relevant change includes evidence that the marking list was verified, and any discrepancies found were corrected before release.
Mappings
Closest match in ISO/IEC 27001: A.5.12, Information classification policy and practices, which this control partially meets.
ISO/IEC 27001: 3 mappings
This control partially meets A.5.12.
ISM-0272 requires system configuration so users can only apply protective markings that match what the system is authorised to handle. This supports Annex A 5.12 (Information Classification Policy and Practices) by enforcing the practical application of the classification scheme at the point of use, reducing misclassification or inappropriate creation of higher-marked content on lower-authorised systems. Annex A 5.12 defines the overarching classification approach, whereas ISM-0272 is a concrete system-level constraint that implements part of that approach.
This control partially meets A.5.13.
ISM-0272 requires protective marking tools to prevent users selecting protective markings that the system is not authorised to process, store or communicate. This directly relates to Annex A 5.13 (Labelling of Information), which requires procedures for applying labels/markings in accordance with the organisation's classification scheme, including consistent application. ISM-0272 is a specific technical enforcement requirement within tooling, while Annex A 5.13 is broader and can be satisfied through a mix of policy, process, and technology across many labelling methods.
This control partially meets A.8.9.
ISM-0272 requires a secure configuration outcome: protective marking tools must not allow markings beyond the system's authorised classification handling. This maps to Annex A 8.9 (Configuration Management for Secure IT Systems) because that control governs establishing, implementing, monitoring, and reviewing security configurations for software and services, including application configuration settings that enforce security rules. Annex A 8.9 is broad configuration governance, while ISM-0272 is one specific configuration requirement focused on information marking enforcement.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.