ASD ISM 1657 Restrict application execution to approved set
What it says
Application control restricts the execution of executables, libraries, scripts, installers, compiled HTML, HTML applications and control panel applets to an organisation-approved set.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishOnly approved software and scripts can run, enhancing system security.
This control ensures that only approved software is allowed to run on your organisation's computers. It's important because if unauthorised programs are executed, they could introduce viruses or allow hackers to steal information, causing serious business disruptions.
Free. Save your status, tasks and notes.
Why it matters
Without application control (approved allow list), unauthorised executables, scripts or libraries can run, enabling malware, privilege abuse and unauthorised access to systems and data.
How to implement
IT team: Compile a list of approved applications that are necessary for organisational tasks.
Work with department heads to determine which programs are essential for daily operations and ensure these are the only ones allowed to run.
System owner: Implement application control software to manage which applications can be executed.
Use the approved applications list to configure the software to block anything not listed.
Management: Communicate to all staff the importance of using only approved software for their tasks.
This can be done via email or a team meeting, highlighting the risks of unauthorised software.
IT team: Regularly review and update the list of approved applications.
Set a quarterly meeting with key stakeholders to ensure new software needs are considered and keep the list current.
IT team: Train staff on recognising and reporting attempts to run unauthorised software.
Offer workshops or online courses explaining the steps they should take if they receive suspicious software requests.
Keep it running
Maintain and review the application allow list; test and deploy updates promptly. Verify enforcement blocks unapproved executables, scripts, installers and libraries, and monitor logs for blocked attempts.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
A copy of the approved applications list: Request the list of software and scripts that are currently approved for use.
Look at
The contents to ensure it is up-to-date and comprehensive.
Good evidence
List will have software names, version numbers, and approval dates.
- Check 2 of 5What an auditor asks for
Ask for
A demonstration of the application control software: Request a live demonstration showing how the software blocks unauthorised applications.
Look at
The software's settings and logs.
Good evidence
Demonstration will show blocked attempts to run unapproved applications.
- Check 3 of 5What an auditor asks for
Ask for
Results of the latest review of approved applications: Request documentation of the last review meeting outcomes.
Look at
Notes detailing stakeholder input and updates made.
Good evidence
Includes a summary of reviewed applications and any changes made.
- Check 4 of 5What an auditor asks for
Ask for
To see staff training records on application control: Request evidence of completed training courses or sessions.
Look at
Records showing participation and awareness. Good records will have dates, participant names, and summary of the training conducted.
- Check 5 of 5What an auditor asks for
Ask for
Examples of user reports on unauthorised software attempts.
Look at
Any incident logs or reporting records from staff.
Good evidence
Shows that staff are vigilant and reports are being addressed promptly.
Mappings
Closest match in ASD Essential Eight: E8-AC-ML1.3, Ensure only approved applications and scripts can run, which asks for the same thing.
ISO/IEC 27001: 1 mapping
This control partially overlaps A.8.18.
Annex A 8.18 requires restricting and tightly controlling use of utility programs that can override system and application controls, effectively limiting what can be installed or run with elevated capability on operational systems. ISM-1657 enforces application control so only an organisation-approved set of executables, libraries, scripts and installers can execute, which is a strong technical mechanism to prevent unauthorised software installation/execution. ISM-1657 is broader in execution control coverage, while Annex A 8.18 is specifically concerned with powerful utilities that bypass controls and the governance around their use.
ASD Essential Eight: 9 mappings
This control is equivalent to E8-AC-ML1.3.
E8-AC-ML1.3 requires application control to restrict execution of executables, libraries, scripts, installers, and similar content to an organisation-approved set. ISM-1657 states the same requirement with the same object types and intent, restricting execution to an approved set.
This control is broader than E8-AC-ML1.1.
E8-AC-ML1.1 requires implementing application control on workstations to restrict what software can execute. ISM-1657 relates directly by detailing the execution objects that application control must restrict (executables, libraries, scripts, installers, HTA/CHM, control panel applets) to an organisation-approved set. ISM-1657 is more prescriptive about coverage, while E8-AC-ML1.1 states the requirement at a higher level without listing the specific artefact types.
This control is broader than E8-AC-ML1.2.
E8-AC-ML1.2 requires application control to be applied to user profiles and temporary folders used by operating systems, browsers and email clients. ISM-1657 is broader, defining the application control objective of restricting execution of multiple content types (executables, libraries, scripts, installers and more) to an organisation-approved set, regardless of where they are located. E8-AC-ML1.2 is a specific scoping requirement about including user and temp paths within an application control program as described more generally by ISM-1657.
This control is broader than E8-AC-ML2.3.
E8-AC-ML2.3 requires implementing Microsoft's recommended application blocklist to block known unwanted applications. ISM-1657 requires application control that restricts execution of executables, libraries, scripts, installers and related content to an organisation-approved set, which is a broader allowlisting/denylisting regime. Microsoft's blocklist in E8-AC-ML2.3 is one specific mechanism that can be used within the broader execution restriction approach of ISM-1657.
This control is broader than E8-AC-ML3.2.
ISM-1657 requires restricting execution to an organisation-approved set for a wide range of application artefacts (executables, libraries, scripts, installers, HTML/CHM/HTA, and control panel applets). E8-AC-ML3.2 focuses specifically on restricting driver execution to an approved set, which is one component of overall execution control. ISM-1657 does not explicitly call out drivers, but its broader execution control objective encompasses this subset in practice for many platforms.
This control partially overlaps E8-AC-ML2.1.
E8-AC-ML2.1 requires application control on internet-facing servers to ensure only approved applications run. ISM-1657 supports this by defining what application control should restrict (executables, libraries, scripts, installers and other code types) to an organisation-approved set. ISM-1657 is more specific about the coverage of file types, while E8-AC-ML2.1 is focused on the internet-facing server scope.
This control partially overlaps E8-AC-ML2.2.
ISM-1657 requires application control that restricts execution to an organisation-approved set of executable artefacts. E8-AC-ML2.2 requires application control be applied to all locations other than user profiles and temporary folders, which is a particular scoping decision about where enforcement occurs. They overlap because both are about implementing execution control, but ISM-1657 is agnostic about location scoping while E8-AC-ML2.2 focuses on enforcement coverage decisions rather than the approved-set definition itself.
This control partially overlaps E8-AC-ML3.1.
E8-AC-ML3.1 requires application control on non-internet-facing servers to ensure only approved software can run. ISM-1657 details the scope of what application control must restrict (executables, libraries, scripts, installers, and related components) to an organisation-approved set, which is directly relevant to achieving E8-AC-ML3.1. The primary control is environment-scoped (non-internet-facing servers), while ISM-1657 is control-mechanism scoped (what must be controlled).
This control supports E8-AC-ML2.4.
ISM-1657 requires restricting application execution to an organisation-approved set, which depends on the quality and currency of the allowlist/rules. E8-AC-ML2.4 requires application control rulesets to be validated at least annually, helping ensure the ISM-1657 approved set remains accurate and effective over time. The candidate is governance/assurance for the rules rather than the core execution restriction requirement.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.