Protect PowerShell Script Block Logs
PowerShell logs are safeguarded by secure event logging that ensures their protection.
Plain language
PowerShell is a tool often used to automate tasks on computers. If someone with bad intentions gets access to your system, they could use PowerShell to cause harm without you knowing. Protecting PowerShell logs ensures that any activity is recorded and cannot be tampered with, helping to detect and prevent misuse.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
Sept 2020
Control Stack last updated
19 Mar 2026
E8 maturity levels
N/A
Official control statement
PowerShell script block logs are protected by Protected Event Logging functionality.
Why it matters
If PowerShell script block logs are not protected with Protected Event Logging, attackers can tamper with or hide executed scripts, delaying detection and enabling compromise.
Operational notes
Confirm Protected Event Logging is enabled and uses the correct certificate; routinely validate that PowerShell Script Block Logging events are being recorded and are not writable by users.
Implementation tips
- IT team should enable Protected Event Logging for PowerShell: They need to configure the computers so that all PowerShell activities are securely logged. This can be done by adjusting settings in Windows Group Policy to ensure logs are encrypted and stored safely.
- System administrators should review PowerShell log settings regularly: They must check that logging is enabled and that the logs are being stored correctly. These checks can be scheduled monthly by going into the system’s event viewer and reviewing the configuration settings.
- Security officers should provide training for staff on recognising suspicious PowerShell activity: They should organise a workshop or session to go over what PowerShell is and why certain activities need observation. Use examples of common scripts and explain the importance of reporting anything unusual.
- Management should ensure there's a policy for responding to PowerShell log alerts: Document procedures for what to do when suspicious activities are detected in the logs. This should include who to notify and what information needs to be gathered to verify the issue.
- Procurement should verify that new software includes features compatible with Protected Event Logging: When buying new software or IT services, ensure they are compatible with secure logging practices. Include this requirement in procurement checklists and contracts.
Audit / evidence tips
- AskThe Group Policy settings documentation: Request a printout or screenshot showing how Protected Event Logging is configured for PowerShell GoodShows clear configurations where the log settings are enabled and set to secure storage areas
- AskA recent audit of PowerShell log reviews: Request the report from the latest review of PowerShell logs GoodIncludes a review within the last month showing identified and actioned items
- AskTraining attendance records for PowerShell security courses: Request the sign-in sheets or electronic records for staff training sessions GoodShows recent training with a majority of relevant staff in attendance
- AskThe incident response policy that includes PowerShell: Require a copy of the procedures for handling detected PowerShell misuse GoodProvides a detailed, easy-to-follow plan with assigned roles
- AskContract details with software providers: Request terms of purchase that specify secure logging compliance for PowerShell GoodIncludes explicit requirements in the procurement documents
Cross-framework mappings
How ISM-1624 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| handshake Supports (1) expand_less | ||
| Annex A 5.28 | ISM-1624 requires PowerShell script block logs to be protected using Protected Event Logging functionality | |
E8
| Control | Notes | Details |
|---|---|---|
| layers Partially meets (3) expand_less | ||
| sync_alt Partially overlaps (1) expand_less | ||
| handshake Supports (2) expand_less | ||
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.