ASD ISM 1823 Lock Office productivity suite security settings against user changes
What it says
Office productivity suite 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 EnglishSecurity settings in office productivity suites are centrally enforced and locked so that no person using the software can alter them.
Office productivity suites (word processors, spreadsheets, presentation tools and similar) carry a set of security settings that decide things like what active content can run, what the application will open and how it handles risky files. This control requires that those security settings cannot be changed by human users. In practice, the settings are applied and enforced centrally by the organisation, and the options in the application are greyed out, hidden or overridden so that a person at the keyboard cannot switch them off. Why it matters: attackers routinely deliver malicious documents that try to convince the recipient to weaken a protection ("enable content", "trust this file", "turn off this warning"). A security setting that a user can change is only as strong as the judgement of the least careful user on the worst day. Users also change settings for convenience, or a support technician changes one to fix a problem and forgets to put it back. Locking the settings takes that decision out of human hands so the hardened configuration stays in place on every device, all the time.
Free. Save your status, tasks and notes.
Why it matters
If users can change office productivity suite security settings, a single click prompted by a phishing email or a malicious attachment can disable the protections the organisation relies on, allowing malicious content to execute and giving an attacker a foothold on the workstation and network. Configuration also drifts silently as people adjust settings for convenience, so the organisation loses confidence that its hardening is actually in effect, and it cannot demonstrate to an assessor that the settings are enforced rather than merely recommended.
How to implement
Have the desktop or endpoint administration team define the office productivity suite security settings in the central configuration tool (group policy, mobile device management profile or the suite's cloud admin console) and set each one as enforced or locked, rather than as a default that the user can still change.
Have administrators configure the suite so the security settings pages and options are greyed out, hidden or read-only for standard users, and verify by logging in as a normal user and attempting to change each setting.
Have the IT team apply the enforced settings to every device and user scope that runs the productivity suite, including laptops, shared workstations, virtual desktops and any managed mobile devices, so no population of users is left with editable settings.
Have the service desk route every request to change a productivity suite security setting through a formal exception process handled by administrators in the central policy, and remove any local administrator rights or workarounds that would let a user or technician change the setting on the device.
Have the endpoint team run a scheduled compliance check that reads the effective security settings from devices and reports any device where a setting differs from the enforced value or where enforcement is missing, then remediate by re-applying policy.
Keep it running
Day to day, this control lives in the central configuration management tooling (such as group policy, mobile device management or the suite's cloud administration console). The security settings are defined once, applied to all devices and marked as enforced or locked so the application does not allow a local override.
Operationally, teams need to handle a few recurring situations. When a user or support technician reports that they "need" a setting changed to make something work, the answer is a documented exception process handled by administrators through the central policy, not a local change. When the suite is upgraded or a new version is rolled out, the enforced settings should be checked to confirm they still apply and that new security options introduced by the vendor are brought under the same lock. When a new device or a new user is onboarded, the enforced settings should land automatically through the standard build and policy assignment.
It also helps to periodically compare the settings actually present on a sample of devices against the intended enforced configuration, so that any gap (a device that missed policy, a policy that was accidentally unlinked) is caught before it matters.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the central policy or configuration profile that sets the office productivity suite security settings.
Look at
Check that each security setting is configured as enforced or locked, not merely set as a preference the user can later change.
Good evidence
Every security setting is present in the policy with an enforced state, and the policy is applied to all devices and users that run the suite.
- Check 2 of 5What an auditor asks for
Ask for
Ask to watch a standard user attempt to change a security setting in the productivity suite on a live device.
Look at
Observe whether the option is greyed out, hidden, or reverts to the enforced value after the user tries to change it.
Good evidence
The user cannot change any security setting; the controls are unavailable or any attempted change is overridden by the central policy.
- Check 3 of 5What an auditor asks for
Ask for
Ask for the scope or assignment of the policy that enforces the settings.
Look at
Compare the targeted groups, devices and platforms against the full population of devices that run the productivity suite.
Good evidence
Every device type and user group with the suite installed receives the enforced settings, with no untargeted exceptions.
- Check 4 of 5What an auditor asks for
Ask for
Ask for the most recent compliance or configuration drift report for the productivity suite settings.
Look at
Check whether the report reads the effective settings from devices and flags any that differ from the enforced values.
Good evidence
The report shows all devices matching the enforced settings, and any discrepancies were remediated and closed.
- Check 5 of 5What an auditor asks for
Ask for
Ask how a request to change a productivity suite security setting would be handled.
Look at
Review the exception process and any recent exception records to see whether changes are made centrally by administrators or locally by users and technicians.
Good evidence
Changes are only ever made by administrators through the central policy under a documented exception, and no user or technician can change a setting on the device itself.
Mappings
Closest match in ASD Essential Eight: E8-AH-ML2.7, Office productivity suite settings are immutable by users, which asks for the same thing.
ISO/IEC 27001: 1 mapping
This control partially meets A.8.9.
ISM-1823 requires office productivity suite security settings to be centrally enforced so human users cannot change them. ISO/IEC 27001:2022 Annex A 8.9 requires secure configuration management to be established, documented, implemented, monitored and reviewed across systems and software. ISM-1823 is a specific configuration-hardening requirement that fits within the broader configuration management discipline in Annex A 8.9.
ASD Essential Eight: 6 mappings
This control is equivalent to E8-AH-ML2.7.
ISM-1823 requires office productivity suite security settings to be locked so human users cannot alter them. E8-AH-ML2.7 states the same requirement that office productivity suite settings are immutable by users. Both controls have the same scope and intent, focusing on preventing end-user changes to centrally enforced suite security settings.
This control is broader than E8-RM-ML1.4.
ISM-1823 requires office productivity suite security settings to be locked so users cannot change any of them. E8-RM-ML1.4 specifically prevents users from changing Microsoft Office macro security settings, which is one subset of suite security settings. Therefore ISM-1823 encompasses the macro-setting immutability requirement but also extends to other Office security settings beyond macros.
This control partially meets E8-AH-ML2.10.
E8-AH-ML2.10 requires that PDF software security settings cannot be changed by users. ISM-1823 requires that office productivity suite security settings cannot be changed by users, which is a broader class of user applications/settings than PDFs alone. E8-AH-ML2.10 is a specific instance of the broader "prevent user changes to app security settings" requirement described in ISM-1823.
This control supports E8-AH-ML2.3.
E8-AH-ML2.3 requires Microsoft Office to be blocked from creating executable content, which relies on Office security settings remaining enforced. ISM-1823 requires that Office productivity suite security settings cannot be changed by users, helping ensure users cannot bypass the block implemented for E8-AH-ML2.3. Without ISM-1823 (or an equivalent enforcement mechanism), the control in E8-AH-ML2.3 may be weakened by local user changes.
This control supports E8-AH-ML2.6.
ISM-1823 requires office productivity suite security settings to be centrally enforced and not changeable by human users. E8-AH-ML2.6 requires office productivity suites to be hardened using ASD and vendor guidance, which typically defines the secure baseline settings that should be enforced. Locking settings under ISM-1823 helps ensure the hardening baseline required by E8-AH-ML2.6 remains effective and cannot be weakened by user behaviour.
This control supports E8-RM-ML3.5.
ISM-1823 requires centrally enforced Office productivity suite security settings that users cannot change. E8-RM-ML3.5 requires blocking the enabling of non‑V3 signed Microsoft Office macros via the Message Bar/Backstage View, which is typically implemented via centrally enforced Office policy settings. ISM-1823 supports E8-RM-ML3.5 by ensuring users cannot override or relax the macro-enablement controls once configured.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.