ASD ISM 1671 Disable Office macros for users lacking a demonstrated business requirement
What it says
Microsoft Office macros are disabled for human users that do not have a demonstrated business requirement.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishKeep Office macros switched off for every person unless they can show a genuine work reason to use them, so the default for most staff is no macro execution at all.
Microsoft Office macros are small pieces of code embedded in Word, Excel and other Office files that run when the file is opened or a button is pressed. They are also one of the most common ways attackers get malware onto a computer: a convincing email arrives with an attachment, the person opens it, and the macro inside quietly downloads and runs something malicious. This control says that macros should be disabled for human users by default. Only people who can demonstrate a real business requirement (for example, a finance analyst whose reporting genuinely depends on a macro-enabled workbook) should have macros enabled. Everyone else, including staff who have never needed a macro, should not be able to run them at all. It matters because most people in most organisations never need macros, yet if macros are enabled everywhere, every one of those people becomes a potential entry point. Restricting macros to a small, justified group shrinks the attack surface dramatically without disrupting the work of the people who actually rely on them. The word "demonstrated" is important: the requirement has to be shown and recorded, not simply asserted.
Free. Save your status, tasks and notes.
Why it matters
If macros remain enabled for people who do not need them, a single phishing email with a macro-laden attachment can lead to malware execution, credential theft, ransomware or a foothold for a wider intrusion. Because the affected users have no legitimate use for macros, the exposure delivers no business benefit, only risk. The organisation also cannot claim this Essential Eight maturity requirement is met, and a compromise through an unnecessary macro is likely to be viewed as an avoidable failure of basic hygiene.
How to implement
The security or desktop team sets the default Office macro configuration to disabled for all human user accounts through central management (for example, Group Policy or the device management platform) so that no one can run macros unless they are explicitly excepted.
Business unit managers identify the staff who genuinely need macros and submit a short written justification for each, describing the specific task or file that depends on a macro; the security owner approves or declines each request.
The identity or desktop team creates a dedicated security group for approved macro users and scopes the macro-enabling policy to that group only, so that adding or removing a person from the group is the single way macro access changes.
The security owner maintains a register of approved macro users that records the person, the demonstrated business requirement, the approver and the approval date, and updates it every time an exception is granted or withdrawn.
The security or desktop team runs a periodic reconciliation (for example, quarterly and on role changes or departures) comparing the register against the actual membership of the macro-enabled group and the applied device settings, and removes access wherever the business requirement no longer exists.
Keep it running
Day to day, this control lives in two places: the technical setting that disables macros, and the record of who has been granted an exception and why.
The technical side is usually a centrally managed configuration (such as Group Policy or a device management platform) that disables macros for all users, with a separate group or policy scope that enables them only for approved people. The policy should apply to accounts used by people; automated or service processes are outside this particular control.
The administrative side is a register of approved macro users. Each entry should name the person, the business requirement they demonstrated, who approved it and when. New requests should go through a simple approval step where the requester explains what work needs a macro and a manager or security owner confirms it. Exceptions should be revisited when people change roles or leave, and periodically to confirm the need still exists.
Watch for drift: local administrators changing settings, new devices built from an old image, or users added to the wrong security group. A regular comparison between the approved list and the group that actually has macros enabled catches these quickly.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the central configuration that governs Office macros for user accounts, such as the Group Policy object or device management policy and its scope.
Look at
Look at the default setting that applies to all human users and confirm it disables macros, and check which group or scope receives any setting that enables them.
Good evidence
Macros are disabled for the whole user population by default, and any enabling policy is scoped tightly to a named group of approved users rather than to everyone.
- Check 2 of 5What an auditor asks for
Ask for
Ask for the register of users who have macros enabled, including the business justification recorded for each.
Look at
Look at whether each person has a specific, documented reason tied to their work, who approved it and when it was granted.
Good evidence
Every enabled user has a clearly demonstrated business requirement on record with a named approver; there are no blank or generic justifications.
- Check 3 of 5What an auditor asks for
Ask for
Ask for the current membership of the security group or policy scope that actually enables macros on devices.
Look at
Compare the membership against the approved register and check for people who are not on the register, have left, or have changed roles.
Good evidence
The technical group and the approved register match exactly, and any differences found during the audit can be explained and are promptly corrected.
- Check 4 of 5What an auditor asks for
Ask for
Ask for the process used when someone requests macro access, and a sample of recent requests.
Look at
Look at whether requesters had to explain the work that needs macros and whether an appropriate person reviewed and approved or declined the request before access was granted.
Good evidence
Requests show a written business reason and an approval decision recorded before the setting was changed, with some requests declined where the need was not demonstrated.
- Check 5 of 5What an auditor asks for
Ask for
Ask for evidence of the most recent review of macro exceptions, such as a reconciliation report or review sign-off.
Look at
Look at when the review happened, what it compared, and whether any access was removed because the business requirement no longer applied.
Good evidence
Reviews occur on a regular cycle and after staff changes, and they result in access being removed when it is no longer justified rather than being rubber-stamped.
Mappings
Closest match in ASD Essential Eight: E8-RM-ML1.1, Disable Microsoft Office macros for users without a business need, which asks for the same thing.
ASD Essential Eight: 5 mappings
This control is equivalent to E8-RM-ML1.1.
E8-RM-ML1.1 requires Microsoft Office macros to be disabled for users unless they have a demonstrated business need. ISM-1671 states the same requirement and intent, targeting macro execution for unauthorised/unjustified users. The scope and implementation outcome are substantially identical, so implementing one would largely satisfy the other.
This control partially overlaps E8-RM-ML1.2.
E8-RM-ML1.2 requires Microsoft Office macros from internet-originating files to be blocked. ISM-1671 overlaps by requiring macros to be disabled for users without a demonstrated business requirement, which also reduces macro execution from common delivery channels, including the internet. However, while E8-RM-ML1.2 is source-based (internet-origin), ISM-1671 focuses on user/authorization-based control.
- E8-RM-ML3.1Restrict Microsoft Office macros to only trusted or sandboxed environmentsPartially overlaps
This control partially overlaps E8-RM-ML3.1.
ISM-1671 requires Microsoft Office macros to be disabled for users unless they have a demonstrated business requirement. E8-RM-ML3.1 complements this by defining conditions for safe macro execution (sandboxed, Trusted Location, or trusted publisher), aligning with how organisations safely enable macros for authorised users. ISM-1671 is about user permissions for macros, whereas E8-RM-ML3.1 is about controlling macro execution.
This control partially overlaps E8-RM-ML3.3.
ISM-1671 requires macros to be disabled for users unless they can demonstrate a business need. E8-RM-ML3.3 overlaps by focusing on where macros are permitted to run (Trusted Locations) and ensuring only vetted, privileged maintainers can place or modify macro-enabled content there. ISM-1671 is primarily about user-level allowance/denial, whereas E8-RM-ML3.3 is about controlling the authorised distribution points for macro code when macros are required.
This control depends on E8-RM-ML1.4.
ISM-1671 requires Microsoft Office macros to be disabled for human users unless they have a demonstrated business requirement. E8-RM-ML1.4 supports this by preventing users from changing macro security settings, helping ensure the organisation-enforced 'macros off by default' posture cannot be bypassed locally. ISM-1671 sets the entitlement/allow-list expectation, while E8-RM-ML1.4 is a technical enforcement mechanism that stabilises that configuration.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.