ASD ISM 1623 Centralised logging of PowerShell activities
What it says
PowerShell module logging, script block logging and transcription events are centrally logged.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEnsure PowerShell actions and logs are collected in a central place for monitoring.
This control is about making sure all the actions and logs from PowerShell, a tool commonly used in Windows computers, are collected in a central spot. This matters because if you don't keep track of what's happening with PowerShell, you might miss signs that someone is trying to break into your computers or steal important data.
Free. Save your status, tasks and notes.
Why it matters
Without centralised logging of PowerShell module, script block and transcription events, malicious PowerShell use may go unnoticed, leading to compromise or data breach.
How to implement
The IT team should set up a central logging service that collects logs from all computers in the organisation.
This can be done by configuring each computer to send their logs to a central server where they can be stored for review.
System administrators should enable PowerShell module logging on all computers.
This involves changing the settings in PowerShell to record which modules are being used and sending those logs to the central server.
IT personnel need to activate script block logging to capture detailed information about the PowerShell scripts being run.
They can do this by adjusting group policy settings or setting it directly on each computer to ensure scripts are logged properly.
The IT security team should implement transcription logging, which records the input and output of PowerShell sessions.
They can set this up in PowerShell by enabling transcription settings that will then send the logs to a central location.
The IT manager should regularly review the collected PowerShell logs to check for unusual activity.
This involves examining the logs for any signs of unauthorised access or unexpected changes and ensuring they are stored for an appropriate time period as required by company policy or regulations.
Keep it running
Enable module logging, script block logging and transcription, forward events to a central SIEM, and routinely hunt for suspicious cmdlets, encoded commands and unusual scripts.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The central logging server configuration details: Request documents or screenshots showing how computers are set up to send logs to the server.
Look at
The inclusion of all necessary computers and that logs are being actively forwarded.
Good evidence
Result will show an active system where logs are received and stored correctly.
- Check 2 of 5What an auditor asks for
Good evidence
Will show the settings are enabled and functional across all computers.
- Check 3 of 5What an auditor asks for
Ask for
Documentation or screenshots showing script block logging is turned on in PowerShell. Ensure this setting is enabled and logs are going to the central collection.
Good evidence
Result will confirm this feature is active and reporting correctly.
- Check 4 of 5What an auditor asks for
Ask for
Evidence of transcription logging settings: Request details or screenshots proving transcription logging is configured for PowerShell sessions. Check that these settings send the logs centrally and are not disabled.
Good evidence
Will show these logs are being recorded and sent properly.
- Check 5 of 5What an auditor asks for
Look at
Identification of any anomalies and actions taken as a result.
Good evidence
Result will indicate logs are reviewed regularly and any issues are followed up.
Mappings
Closest match in ASD Essential Eight: E8-AH-ML2.11, Centrally log PowerShell module, script block, and transcription events, which asks for the same thing.
ISO/IEC 27001: 2 mappings
This control partially meets A.8.15.
ISM-1623 requires centralised logging specifically for PowerShell module, script block and transcription events. Annex A 8.15 requires organisations to produce, store, protect and analyse logs of relevant activities and events more broadly across systems and applications. ISM-1623 is a specific implementation instance within the broader logging expectations of Annex A 8.15.
This control depends on A.5.28.
ISM-1623 requires centralised collection of detailed PowerShell activity logs (module, script block and transcription). Annex A 5.28 focuses on procedures to collect and preserve evidence related to information security events, which relies on high-quality, centrally available logs when incidents occur. ISM-1623 supports Annex A 5.28 by improving the availability and completeness of forensic evidence for PowerShell-driven activity.
ASD Essential Eight: 2 mappings
This control is equivalent to E8-AH-ML2.11.
ISM-1623 requires that PowerShell module logging, script block logging and transcription events are centrally logged for monitoring. E8-AH-ML2.11 states the same requirement for centrally logging those specific PowerShell event types. Both controls align in scope (PowerShell-specific) and intent (central collection for detection and monitoring).
This control partially overlaps E8-AH-ML2.12.
E8-AH-ML2.12 requires that command line process creation events are centrally logged. ISM-1623 requires central logging of PowerShell module logging, script block logging and transcription, which captures detailed command and script execution content. They overlap because PowerShell activity is often initiated via command line and both aim to centralise execution-related telemetry, but ISM-1623 is PowerShell-specific and focuses on script content rather than generic process creation events across all shells and binaries.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.