Prevent Child Processes in Microsoft Office
Microsoft Office is configured to prevent it from starting other programs or processes.
🏛️ Framework
ASD Information Security Manual (ISM)
🧭 Control effect
Preventative
🔐 Classifications
NC, OS, P, S, TS
🗓️ ISM last updated
Aug 2021
✏️ Control Stack last updated
22 Feb 2026
🎯 E8 maturity levels
ML2, ML3
Guideline
Guidelines for system hardeningSection
User application hardeningMicrosoft Office is blocked from creating child processes.
Source: ASD Information Security Manual (ISM)
Plain language
This control ensures that Microsoft Office programs, like Word or Excel, can't start other programs on your computer. By stopping this, you reduce the risk of getting a virus or malware that sneaks in via Office and does harmful things on your computer.
Why it matters
Allowing Office to start child processes can lead to malware execution, data breaches, or system compromises through malicious documents.
Operational notes
Regularly confirm the ASR rule 'Block Office from creating child processes' is enabled and enforced; review blocked events to tune exceptions.
Implementation tips
- Office Manager should coordinate with the IT team to check that Microsoft Office apps are configured correctly. This means ensuring settings prevent these apps from launching other programs. IT can do this by updating group policies or using configuration management tools.
- The IT team should review Group Policy or similar tools used in your organisation to ensure restrictions on child processes are applied. This involves checking that the settings block Word, Excel, and other Office apps from running other software.
- System Owner should work with the IT department to deploy any necessary security updates. Make sure Office apps are set to update automatically as these updates often fix security vulnerabilities that could allow child processes to run.
- IT team should conduct regular checks to confirm the settings are active. This includes testing whether the software restrictions on child processes are actually being enforced by trying to run a script or program from within an Office app and ensuring it’s blocked.
- Management should communicate the importance of these measures to all staff, ensuring they understand not to change settings that enable child processes. Provide training that highlights the security risks involved if these settings are altered.
Audit / evidence tips
-
Ask: a report from the IT team showing the configuration settings applied to Microsoft Office
Good: will show settings like Group Policy Object (GPO) configurations that restrict these actions
-
Good: is logs showing blocked attempts with date and time stamps
-
Ask: a demonstration where an IT member attempts to run a program from within Word or Excel. Look closely to ensure the attempt is blocked and recorded
Good: will show the attempt fails and is logged
-
Good: would be a log or report listing updates and their impact on security configurations
-
Ask: training records or communications sent to staff about security settings in Office
Good: is a complete record of educational efforts detailing why the control is important
Cross-framework mappings
How ISM-1667 relates to controls across ISO/IEC 27001, Essential Eight, and ASD ISM.
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
E8
| Control | Notes | Details |
|---|---|---|
| Partially overlaps (4) | ||
| E8-RM-ML2.1 | E8-RM-ML2.1 focuses on preventing Win32 API calls from Office macros to limit interaction with the system | |
| E8-AH-ML2.3 | ISM-1667 requires Microsoft Office to be blocked from creating child processes | |
| E8-AH-ML2.4 | E8-AH-ML2.4 requires blocking Microsoft Office from injecting code into other processes | |
| E8-AH-ML2.5 | E8-AH-ML2.5 requires Microsoft Office to be configured to prevent activation of OLE packages to reduce embedded-object execution risk | |
| Related (1) | ||
| E8-AH-ML2.2 | ISM-1667 requires Microsoft Office to be blocked from creating child processes | |