Segregated Environment for Malicious Code Analysis
Malicious code should be analyzed in a separate, isolated environment to prevent system contamination.
Plain language
When analysing suspicious software or files, it's crucial to do so in a separate, secure area so it doesn't spread to your main systems. This protects your business from potential damage and keeps your everyday operations safe.
Framework
ASD Information Security Manual (ISM)
Control effect
Responsive
Classifications
NC, OS, P, S, TS
ISM last updated
June 2026
Control Stack last updated
18 June 2026
E8 maturity levels
N/A
Official control statement
Malicious code processing for cyber security incident response or research purposes is conducted in a dedicated analysis environment segregated from other systems.
Why it matters
Without an isolated analysis space, harmful software could spread, disrupting business operations and risking data loss.
Operational notes
Ensure the analysis environment remains isolated and updated, and review access logs regularly to prevent any potential breaches.
Implementation tips
- IT team should set up a dedicated analysis environment. Create a separate computer or network that is not connected to your main systems to safely analyse potentially harmful software.
- System owner should ensure only authorised staff access the analysis environment. Limit who can enter this area to trained cybersecurity staff to prevent accidental spread of malware.
- IT team should regularly update the analysis environment's security tools. Keep antivirus and monitoring software up-to-date to catch new types of malicious code.
- Managers should provide staff training on malicious code handling. Educate your team on recognising suspicious files and why using the isolated environment is important.
- Security team should document each analysis session. Keep a log of what malicious files were tested and the results, which helps refine future security responses.
Audit / evidence tips
- Askthe environment setup documentation. Verify there's a description of the isolated setup and the security measures in placeGoodwill show well-documented separation from main systems
- Goodshows regular monitoring and no unauthorised access
- Aska report on antivirus updates in the analysis environmentLook atrecords showing timely updates and patches applied to the systemGoodincludes consistent, up-to-date logs
- Look atcompletion certificates or attendance records for training coursesGoodshows regular and recent training sessions
- Aska sample of analysis logs. Review entries to ensure they detail files tested and outcomes, indicating structured and careful analysisGoodis comprehensive and regularly updated logs
Cross-framework mappings
How ISM-1970 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
layersPartially meets(2)expand_less | ||
| Annex A 8.22 | ISM-1970 specifies analysis of malicious code in a segregated environment to safeguard other systems | |
| Annex A 8.31 | ISM-1970 mandates the use of a dedicated environment for analysing malicious code to prevent interference with other systems | |
handshakeSupports(2)expand_less | ||
| Annex A 8.16 | Annex A 8.16 requires monitoring networks, systems and applications for anomalous behaviour and then evaluating potential incidents | |
| Annex A 8.20 | ISM-1970 necessitates segregated environments for malware analysis, supporting the concept in ISO/IEC 27001:2022 Annex A 8.20, which ensu... | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ASD ISM controls in Cyber security incidents
See all Guidelines for cyber security incidents controls, or browse the full ASD ISM library.