ASD ISM 1622 Ensure PowerShell uses Constrained Language Mode
What it says
PowerShell is configured to use Constrained Language Mode.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishPowerShell should be setup to limit script execution and mitigate potential risks.
This control is about making sure that PowerShell, a tool used to manage and automate tasks on your computer network, is set up to reduce risk. It's important because if PowerShell isn't limited, a hacker could use it to access sensitive information or disrupt your operations.
Free. Save your status, tasks and notes.
Why it matters
Without Constrained Language Mode, PowerShell can be exploited for code execution, risking data breaches and operational disruptions.
How to implement
The IT team should configure all computers to use PowerShell in Constrained Language Mode.
This means adjusting the settings on each computer so that PowerShell can only perform safe, simple tasks and cannot use powerful, risky ones.
Business managers should ask their IT team to include this configuration in regular security checks.
This ensures the settings remain effective and consistent across the organisation.
System administrators should update documentation to reflect this change.
Clearly indicate that PowerShell is limited in its capabilities, providing guidance for users on what that means for daily operations.
The IT manager should establish a process to routinely verify that Constrained Language Mode is enabled.
This could involve setting reminders for periodic checks or using software that automatically reports the setting status.
Executives should support these changes by explaining to staff why they are necessary.
Sharing how these efforts help protect the business can motivate cooperation and compliance.
Keep it running
Regularly check $ExecutionContext.SessionState.LanguageMode is ConstrainedLanguage across endpoints and confirm WDAC/AppLocker policies enforce it to prevent drift.
Evidence and audit
- Check 1 of 4What an auditor asks for
Ask for
Configuration reports from the IT team: Request documentation or system logs showing the current PowerShell settings across your computers.
Look at
Whether they reflect Constrained Language Mode.
Good evidence
Includes a report dated recently that clearly indicates PowerShell is set to the limited mode on all devices.
- Check 2 of 4What an auditor asks for
Ask for
The IT department for policy documents.
Look at
Company policies regarding PowerShell use. Check these documents for references to Constrained Language Mode and details about permissible actions with PowerShell.
Good evidence
Includes a comprehensive policy that mentions Constrained Language Mode as a requirement.
- Check 3 of 4What an auditor asks for
Ask for
To see staff communications or training records.
Look at
Evidence that shows staff were informed about the PowerShell configuration change. Good evidence includes an email or memo sent to all employees explaining the new settings and their purpose.
Good evidence
Will show consistent settings across sampled devices, ideally with automated monitoring proof.
- Check 4 of 4What an auditor asks for
Look at
Records where a deviation from Constrained Language Mode was noted and addressed. This demonstrates ongoing compliance and proactive management.
Good evidence
Includes logs confirming that any detected deviations were corrected promptly.
Mappings
Closest match in ASD Essential Eight: E8-AH-ML3.3, PowerShell is configured to use Constrained Language Mode, which asks for the same thing.
ISO/IEC 27001: 2 mappings
This control partially meets A.8.8.
ISM-1622 requires a specific hardening configuration: PowerShell must use Constrained Language Mode. Annex A 8.8 is broader, requiring organisations to identify technical vulnerabilities, assess exposure, and implement appropriate mitigations across information systems. Configuring Constrained Language Mode is one example of an appropriate measure to reduce exposure to PowerShell-based exploitation, but Annex A 8.8 extends well beyond PowerShell.
This control partially meets A.8.9.
ISM-1622 mandates a particular security configuration for a specific technology (PowerShell Constrained Language Mode). Annex A 8.9 requires security configurations for hardware, software, services and networks to be established, documented, implemented, monitored and reviewed. ISM-1622 fits within Annex A 8.9 as a single configuration requirement, while Annex A 8.9 also covers governance, documentation and monitoring across all system configurations.
ASD Essential Eight: 3 mappings
This control is equivalent to E8-AH-ML3.3.
ISM-1622 requires PowerShell to be configured to use Constrained Language Mode to limit script capability and reduce abuse. E8-AH-ML3.3 states the same requirement with the same technical outcome (PowerShell constrained to CLM). Implementing either control would substantially satisfy the other as they target the same configuration setting and risk.
This control partially overlaps E8-AC-ML1.3.
ISM-1622 requires PowerShell to run in Constrained Language Mode to limit what PowerShell scripts and commands can do. E8-AC-ML1.3 requires application control so only approved applications and scripts can execute. They overlap in reducing malicious script execution, but ISM-1622 constrains PowerShell capability even when it runs, while E8-AC-ML1.3 is an allow-list control across many executable/script types beyond PowerShell.
This control depends on E8-AH-ML3.2.
ISM-1622 requires PowerShell to use Constrained Language Mode to reduce capability available to scripts and interactive sessions. E8-AH-ML3.2 requires Windows PowerShell 2.0 to be disabled or removed to eliminate an older, less controllable engine that can weaken PowerShell security controls. Disabling PowerShell 2.0 supports effective enforcement of modern PowerShell protections (including CLM), but it is a different requirement to configuring CLM itself.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.