ASD ISM 1608 Scan third-party SOEs for malicious code
What it says
SOEs provided by third parties are scanned for malicious code and configurations.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishThird-party standard operating environments must be checked for viruses and bad configurations.
This control is about ensuring that software and systems we get from outside sources are checked for harmful code or configurations that could cause problems or expose us to cyber attacks. It's important to do this because, if missed, malicious code could harm our operations, steal data, or let outsiders access our systems.
Free. Save your status, tasks and notes.
Why it matters
Neglecting to scan third-party SOEs can introduce malware or insecure settings, leading to compromise, data breaches, and operational disruption.
How to implement
The IT team should scan third-party software before it's installed on company systems.
Use reliable antivirus and anti-malware tools to perform these scans. Make sure the tools are updated regularly so they can catch the latest threats.
Procurement officers should require third-party vendors to provide documentation or certification that their software has been tested for security issues.
This might involve asking vendors for security assessment reports or compliance certificates before purchase orders are approved.
System owners should review any third-party software updates or patches before they're applied.
Collaborate with IT to test updates in a safe, separate environment (sandbox) to check for issues without affecting live systems.
Managers should set up a procedure for reporting security concerns.
Encourage staff to report suspicious behaviour related to third-party software promptly to the IT team for further investigation.
HR should incorporate cyber security awareness training about the risks of third-party software.
Ensure staff know the importance of not using unmanaged software or plugins that haven't been properly vetted by the organisation.
Keep it running
Before deployment, scan all third-party SOE images for malware and insecure configurations; re-scan on updates and keep scan results as evidence.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Virus and malware scan reports for third-party software: Request documentation of scan reports detailing when and how software was checked.
Look at
The scan dates and results.
Good evidence
Is recent, clear reports showing no threats were detected and the software is safe.
- Check 2 of 5What an auditor asks for
Ask for
Vendor security certifications or assessment reports: Request security documents provided by vendors for their software.
Look at
The details of these reports for recognised security standards or certifications they adhere to.
Good evidence
Includes up-to-date certifications from reputable organisations.
- Check 3 of 5What an auditor asks for
Ask for
Logs or records from the sandbox testing of software updates: Request documentation showing that updates were tested in a safe environment.
Look at
What tests were conducted and their outcomes.
Good evidence
Is detailed testing logs showing no issues and green light for installation.
- Check 4 of 5What an auditor asks for
Ask for
The incident report log related to third-party software: Request access to records of any incidents linked to third-party software.
Look at
Details on how they were handled and resolved.
Good evidence
Is a complete incident log with prompt resolutions and follow-up actions mentioned.
- Check 5 of 5What an auditor asks for
Ask for
Records of staff training sessions related to third-party software risks: Request training attendance records and materials used.
Look at
Participation rates and relevance of content.
Good evidence
Is comprehensive records showing regular, relevant training sessions were conducted.
Mappings
Closest match in ISO/IEC 27001: A.8.7, Protection against malware, which this control partially meets.
ISO/IEC 27001: 3 mappings
This control partially meets A.8.7.
ISM-1608 requires third-party standard operating environments (SOEs) to be scanned for malicious code and checked for unsafe/non-compliant configurations before use. This aligns with ISO/IEC 27001:2022 Annex A 8.7, which requires the organisation to implement malware protection controls across the environment, including controls that prevent malware introduction via externally sourced software or images. ISM-1608 is a specific supply-chain intake/checkpoint for malware assurance on third-party SOEs, while Annex A 8.7 is broader and also covers ongoing detection, response and user awareness beyond SOE ingestion.
This control partially meets A.8.19.
ISM-1608 requires scanning and verification of third-party SOEs for malicious code and unsafe configurations before they are introduced into the environment. This supports ISO/IEC 27001:2022 Annex A 8.19 because secure software installation procedures are strengthened when an organisation has a defined step to verify the integrity and configuration of externally supplied images/packages prior to installation. Annex A 8.19 is about the broader procedural controls around software installation (authorisation, handling, rollback, logging, etc.), while ISM-1608 is a specific assurance activity focused on third-party SOE intake rather than the full installation lifecycle.
This control partially overlaps A.8.9.
ISM-1608 requires third-party SOEs to be checked for insecure or non-compliant configurations (as well as malicious code) before they are adopted. This overlaps with ISO/IEC 27001:2022 Annex A 8.9, which requires configurations for hardware, software, services, and networks to be established, documented, implemented, monitored, and reviewed across the environment. Both address configuration correctness, but ISM-1608 is specifically an acceptance/ingestion control for externally provided SOE builds, whereas Annex A 8.9 is a lifecycle governance control that extends to internal builds and ongoing monitoring/review rather than a one-off acceptance gate.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.