ASD ISM 1489 Lock Microsoft Office macro security settings against user changes
What it says
Microsoft Office macro security settings cannot be changed by human users.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishMacro security settings in Microsoft Office must be enforced centrally and locked so that no person using the computer can alter them, even if the options appear in the Trust Centre.
Microsoft Office has a set of macro security settings that decide whether macros in documents, spreadsheets and presentations are blocked, prompted for, or allowed to run. This control requires that those settings are locked so a human user cannot change them. It does not matter whether the user is a regular staff member, a power user, or someone with local administrator rights on their own machine; if a person can open Trust Centre, edit the registry, or otherwise flip the setting, the control is not met. Why it matters: attackers routinely send Office files carrying malicious macros and then use social engineering to talk the recipient into "enabling content" or loosening their security settings so the macro will run. Organisations spend real effort choosing a safe macro configuration, but that effort is wasted the moment an individual can override it under pressure from a convincing email or phone call. Locking the settings takes the decision out of the user's hands, so the organisation's chosen macro posture holds even when a person is tricked, curious, or simply trying to make a document work.
Free. Save your status, tasks and notes.
Why it matters
If users can change macro security settings, a phishing email or a helpful-sounding instruction can lead someone to weaken the settings and run a malicious macro. That typically results in malware execution, credential theft, ransomware or persistent access on the endpoint, and it undermines every other macro control the organisation has put in place because the enforced configuration no longer means anything.
How to implement
Have the endpoint or desktop engineering team configure Microsoft Office macro security settings through a central policy mechanism (Group Policy, Intune or an equivalent management tool) using the current Microsoft Office administrative templates, so the settings are written as policy values rather than user preferences.
Have the same team confirm on a test device that every macro security option in the Trust Centre is greyed out and displays as managed by the organisation, and repeat the check for each Office application in use (Word, Excel, PowerPoint, Outlook, Access, Visio and Project as applicable).
Have the endpoint security team restrict write access to the policy registry paths for Office macro settings, and use application control or endpoint protection rules to block registry editing tools and scripts for standard users, so people with local administrator rights cannot bypass the policy.
Have the desktop engineering team build a compliance check into the device management platform (for example a configuration baseline or compliance script) that reports any endpoint where the enforced macro values are missing or differ from the expected setting, and assign remediation to the service desk.
Have the change manager route every request to alter macro behaviour through the change process, with the change made only in the central policy by the responsible administrator, and have the service desk decline requests to adjust settings on an individual computer.
Keep it running
In day-to-day operation this control is mostly about making sure the enforced configuration keeps applying. Macro security settings should be delivered through a central policy mechanism (for example Group Policy or a mobile device management platform) that writes the policy-controlled registry values, because policy-controlled values are read-only in the Office Trust Centre and override anything a user sets themselves. The same mechanism should also stop users from editing those policy keys through other routes, such as registry tools or scripts, and this matters most on machines where people hold local administrator rights.
Watch for drift: devices that have dropped out of policy scope, new Office installs or channels that use different policy paths, and staged Office upgrades where the administrative templates are older than the client. When a business team genuinely needs a different macro configuration, the change should be made in the central policy by the responsible IT team, not by adjusting a setting on the user's computer. Periodic spot checks that Trust Centre options are greyed out on a sample of endpoints are cheap and catch most problems.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the central policy configuration (Group Policy, Intune or equivalent) that enforces Microsoft Office macro security settings, together with its scope of assignment.
Look at
Check that the macro security settings are set as enforced policy values rather than user preferences, and that the assignment covers all workstations and users who run Microsoft Office.
Good evidence
A single authoritative policy applies to every Office endpoint, and the responsible team can explain why it is enforced rather than preferred.
- Check 2 of 5What an auditor asks for
Ask for
Ask for a live or screen-recorded demonstration of the Trust Centre macro settings on a sample of user devices, including a device used by someone with local administrator rights.
Look at
Look for the macro security options being greyed out with a message that the settings are managed by the organisation, in each Office application in use.
Good evidence
On every sampled device, no human user can select a different macro security option, regardless of their privilege level.
- Check 3 of 5What an auditor asks for
Ask for
Ask what stops a user from changing the policy registry values or Trust Centre settings through other means, such as the registry editor, PowerShell or a local script.
Look at
Look at application control rules, registry permissions or endpoint protection policies that block standard users and local administrators alike from editing the relevant keys.
Good evidence
The organisation has considered bypass routes beyond the Office user interface and has technical controls that block them, with evidence of testing.
- Check 4 of 5What an auditor asks for
Ask for
Ask for the most recent compliance report or configuration baseline results showing which endpoints hold the expected macro security values.
Look at
Look at the number of non-compliant or unreported devices, how long they have been out of compliance, and whether remediation tickets exist for them.
Good evidence
All endpoints report compliant; any exception is recent, ticketed and owned.
- Check 5 of 5What an auditor asks for
Ask for
Ask for the change records for any adjustment to Office macro security settings over the past year.
Look at
Check that each change was made in the central policy by an authorised administrator through the change process, and that no service desk ticket shows a setting being altered on an individual user's computer.
Good evidence
All macro setting changes are centrally made, approved and traceable, with no evidence of per-user or per-device overrides.
Mappings
Closest match in ASD Essential Eight: E8-RM-ML1.4, Prevent users from changing Microsoft Office macro security settings, which asks for the same thing.
ISO/IEC 27001: 1 mapping
This control partially meets A.8.9.
ISM-1489 requires Microsoft Office macro security settings to be centrally enforced and locked against user changes. Annex A 8.9 requires organisations to establish, document, implement, monitor and review secure configurations across IT systems, which is the governance mechanism used to define and maintain those locked macro settings. Annex A 8.9 is broader configuration management, while ISM-1489 is a specific hardening requirement within that configuration baseline.
ASD Essential Eight: 7 mappings
This control is equivalent to E8-RM-ML1.4.
E8-RM-ML1.4 requires that Microsoft Office macro security settings cannot be changed by users. ISM-1489 states the same requirement for Office macro security settings, with effectively identical scope and intent. Implementing ISM-1489 would largely satisfy E8-RM-ML1.4 (and vice versa) because both enforce centrally controlled, user-immutable macro security configuration.
This control partially meets E8-AH-ML2.7.
ISM-1489 requires Microsoft Office macro security settings to be centrally enforced and locked so that human users cannot change them. E8-AH-ML2.7 requires office productivity suite security settings to be immutable by users, which includes (but is not limited to) macro security settings in Microsoft Office. The candidate is broader because it applies to a wider range of Office security settings beyond macros, whereas ISM-1489 is specifically focused on preventing user changes to macro security configuration.
This control partially overlaps E8-AH-ML2.10.
E8-AH-ML2.10 requires preventing users from changing PDF software security settings. ISM-1489 similarly requires preventing users from changing Microsoft Office macro security settings, which is the same governance pattern (users cannot weaken application security) applied to a different application domain. The overlap is in the control mechanism (enforced, centrally managed application security settings), but the protected technology (PDF vs Office macros) differs.
This control supports E8-RM-ML1.1.
E8-RM-ML1.1 requires macros to be disabled for users without a business need. ISM-1489 supports this by ensuring users cannot change Microsoft Office macro security settings to re-enable macros or weaken the restriction. ISM-1489 does not decide who has a business need; it strengthens enforcement of the macro-disable decision made under E8-RM-ML1.1.
This control supports E8-RM-ML1.2.
E8-RM-ML1.2 requires that internet-origin Microsoft Office macros are blocked. ISM-1489 supports this by preventing users from changing Office macro security settings, which helps ensure the internet-macro block cannot be weakened or bypassed by end users. ISM-1489 does not itself mandate blocking internet-origin macros, but it strengthens the durability and enforceability of E8-RM-ML1.2.
This control supports E8-RM-ML3.4.
E8-RM-ML3.4 requires Office to prevent untrusted publisher macros being enabled through the Message Bar or Backstage View. ISM-1489 supports this by ensuring users cannot change macro security settings, reducing the likelihood they can weaken or circumvent the configuration needed to enforce E8-RM-ML3.4. ISM-1489 is about protecting configuration integrity rather than defining the specific untrusted-publisher enablement block.
This control supports E8-RM-ML3.5.
E8-RM-ML3.5 requires enforcing a policy that users cannot enable non‑V3 signed Office macros via the Message Bar or Backstage View. ISM-1489 ensures Microsoft Office macro security settings cannot be changed by users, which helps prevent users from weakening or bypassing the E8-RM-ML3.5 enforcement through local configuration changes. While ISM-1489 does not itself define the V3 signature restriction, it is a prerequisite control to keep that restriction reliably enforced in end-user environments.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.