ASD ISM 1969 Preventing accidental execution of malicious code
What it says
Malicious code, when stored or communicated, is treated beforehand to prevent accidental execution.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEnsure malicious code cannot accidentally run by treating it before storage or communication.
This control is about making sure that bad software, which can harm your computers and steal your information, doesn't run by accident. It's important because if this harmful code does run, it can disrupt your business, damage your reputation, and cost a lot of money to fix.
Free. Save your status, tasks and notes.
Why it matters
Failure to pre-treat malicious code can lead to accidental execution, resulting in data breaches, operational disruption, and financial loss.
How to implement
IT team should regularly scan all incoming files and emails for malware.
Use trusted software solutions to carry out these scans automatically before any files are stored or sent to others. This helps catch harmful software before it has a chance to spread.
System owners should create and apply rules for how files are handled.
Clearly outline steps everyone must follow when opening, storing, or sharing files to ensure these don't accidentally run harmful code. Include training sessions to explain these rules to all employees.
Managers should ensure the software that is used by staff is set to prevent automatic running of downloaded files.
Confirm settings on all company computers are adjusted to block automatic execution unless manually overridden. This reduces the risk of harmful code running without your knowledge.
Procurement teams should source software from reputable vendors who ensure their products are secure by default.
Verify that any new software includes features to detect and block harmful code execution before installation.
HR should coordinate training for staff on recognising suspicious files or links.
Use real-world examples to educate employees about risks and encourage them to double-check unexpected attachments or links before opening them.
Keep it running
Sanitise or quarantine captured malware samples (e.g., password-protect archives) before storing or sharing to prevent execution.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The latest malware scan reports: Request documentation showing regular scan results from IT.
Look at
Noted dates, scan results, and actions taken on detected threats.
Good evidence
Will show consistent, timely scans with appropriate follow-up actions on any threats found.
- Check 2 of 5What an auditor asks for
Ask for
The file handling policy document: Request to see written guidelines on file storage and sharing practices.
Look at
How clearly they are communicated and whether they cover necessary precautions.
Good evidence
Is a well-structured document with clear, comprehensive guidelines.
- Check 3 of 5What an auditor asks for
Ask for
System configuration settings: Request details on settings related to file execution restrictions.
Look at
Evidence that these settings are applied company-wide.
Good evidence
Shows a consistent approach across all devices managed by the organisation.
- Check 4 of 5What an auditor asks for
Ask for
Records of software vendor assessments: Request documentation showing how vendors are chosen based on security features.
Look at
Criteria assessing vendor security reputation.
Good evidence
Shows vendor evaluations focused on security assurances.
- Check 5 of 5What an auditor asks for
Ask for
Staff training logs relating to cyber security: Request training records that demonstrate staff attendance and understanding.
Look at
Dates, attendance lists, and training content coverage.
Good evidence
Includes regular sessions specifically addressing safe file handling and recognising threats.
Mappings
Closest match in ISO/IEC 27001: A.8.7, Protection against malware, which this control partially meets.
ISO/IEC 27001: 1 mapping
This control partially meets A.8.7.
Annex A 8.7 requires implementing and supporting measures to prevent and detect malware, including user awareness. ISM-1969 relates by requiring malicious code to be treated in advance when stored or communicated so it cannot be accidentally executed, which is a preventative anti-malware handling practice. ISM-1969 is narrower and focuses on safe handling of suspected malicious code, while Annex A 8.7 covers the full organisational malware protection program and awareness.
ASD Essential Eight: 1 mapping
This control partially overlaps E8-AH-ML2.3.
ISM-1969 requires treating malicious code prior to storage or communication to prevent accidental execution. E8-AH-ML2.3 overlaps by preventing Office from creating executable content, which reduces opportunities for malicious code to be embedded and later executed when documents are stored or shared. However, ISM-1969 is about safe handling/neutralisation of known or suspected malicious code, while E8-AH-ML2.3 is a preventive hardening control for a specific application behaviour.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.