ASD ISM 1584 Prevent unauthorised changes to security settings
What it says
Unprivileged users are prevented from bypassing, disabling or modifying security functionality of operating systems.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEnsure non-admin users cannot change or disable security settings on operating systems.
This control is about making sure that everyday users can't mess with important security settings on their computers. It matters because if anyone could change these settings, they might accidentally or intentionally turn off protections that keep your data safe and secure.
Free. Save your status, tasks and notes.
Why it matters
If unprivileged users can change OS security settings, protections may be disabled, enabling malware execution or unauthorised access.
How to implement
The IT team should set user permissions: They need to configure computers so that only authorised administrators can change system security settings.
This can be done by setting up accounts for regular users with restrictions in the system settings.
Managers should check user roles: They need to ensure employees have the correct level of access for their job.
They can liaise with IT to understand which roles need more, or fewer, permissions.
System owners should organise regular checks: They should work with IT to periodically review and confirm that no unauthorised changes have been made to system settings by running system audits.
HR, in conjunction with IT, should run training sessions: Explain to staff why they should not attempt to change security settings, and clarify the potential risks involved.
Conduct training during onboarding and as part of regular security awareness programs.
Procurement teams should evaluate software before purchase: Ensure that any new systems or software bought for the company have the capability to limit changes to security settings by regular users.
They can include these requirements in procurement checklists.
Keep it running
Restrict OS security setting changes to admins via GPO/MDM, and monitor/audit events for attempts to disable or bypass controls.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
A user access control list: Request a document that shows which employees have administrative privileges.
Look at
Details on who can change security settings.
Good evidence
List will show only a few trusted administrators with these privileges.
- Check 2 of 5What an auditor asks for
Ask for
Policy documents on user roles: Request written policies that outline roles and access levels. Check that roles are clearly defined with restrictions on changing security settings.
Good evidence
Policy explains the role structure and security measure responsibilities.
- Check 3 of 5What an auditor asks for
Ask for
System audit logs: Request a recent log of security changes on key systems. Check entries to see if unauthorised users have altered settings. Good logs will show that only authorised users made changes and all entries are properly documented.
- Check 4 of 5What an auditor asks for
Ask for
Content from security awareness sessions. Check that materials include information about the risks of changing security settings. Good training resources will explain risks in relatable terms and show completion records for staff.
- Check 5 of 5What an auditor asks for
Ask for
Procurement documents: Request samples of requirement checklists used in software purchases. Check for criteria related to locking down security settings. Good documents include notes on the ability to restrict user access to security configurations.
Mappings
Closest match in ISO/IEC 27001: A.8.18, Use of privileged utility programs, which partially overlaps with this control.
ISO/IEC 27001: 1 mapping
This control partially overlaps A.8.18.
ISM-1584 ensures that unprivileged users are prevented from bypassing, disabling or modifying operating system security functionality. Annex A 8.18 supports this by requiring tight restriction and control of utility programs capable of overriding system and application controls, reducing the practical means by which a non-admin could circumvent OS security mechanisms. Annex A 8.18 focuses on controlling high-risk utilities (a pathway to bypassing controls), while ISM-1584 is the explicit OS-level outcome that such bypass/disable/modify actions are not possible for unprivileged users.
ASD Essential Eight: 2 mappings
This control supports E8-AH-ML3.2.
E8-AH-ML3.2 requires organisations to disable or remove Windows PowerShell 2.0. ISM-1584 requires preventing unprivileged users from bypassing, disabling or modifying operating system security functionality. Implementing ISM-1584 supports E8-AH-ML3.2 by ensuring users cannot re-enable or tamper with the PowerShell 2.0 feature once it has been disabled or removed.
This control supports E8-RM-ML1.4.
E8-RM-ML1.4 requires that Microsoft Office macro security settings cannot be changed by users. ISM-1584 prevents unprivileged users from bypassing, disabling or modifying operating system security functionality, which supports enforcing and protecting policy enforcement mechanisms used to lock down Office settings. ISM-1584 is OS-focused and does not itself mandate Office macro configuration, but it strengthens the ability to keep E8-RM-ML1.4 effective against local tampering.
ASD Essentials for enterprise IT: 1 mapping
- IT.PRO-12.2Restrict account and role management and privileged functions to authorised administrative rolesPartially overlaps
This control partially overlaps IT.PRO-12.2.
IT.PRO-12.2 requires only authorised administrative roles to manage accounts and roles or access privileged functions; ISM-1584 prevents unprivileged users from bypassing, disabling or modifying operating system security functionality, keeping those functions out of their reach.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.