Wazuh detects software installs and uninstalls in Windows by capturing Event IDs 11707 and 11724 from the Application log. Adding just two custom rules in local_rules.xml is enough to receive real-time alerts with the software name, the machine and the user involved.
Which Windows Event IDs do these actions generate?
Windows Installer writes events to the Application log whenever software is installed or uninstalled:
| Event ID | Action | Description |
| 11707 | Install | Software installed successfully |
| 11724 | Uninstall | Software removed from the system |
How do you write the rule to detect installs?
Add this rule in /var/ossec/etc/rules/local_rules.xml:
<rule id="100200" level="8">
<if_group>windows</if_group>
<field name="win.system.eventID">^11707$</field>
<description>Software instalado en Windows: $(win.eventdata.data)</description>
<options>no_full_log</options>
<group>software_install,policy_violation</group>
</rule>Explanation:
if_group windows: Applies only to Windows eventswin.system.eventID: Filters on Event ID 11707$(win.eventdata.data): Includes the software name in the alertlevel="8": Medium-high severityno_full_log: Excludes the full log (reduces size)
How do you write the rule to detect uninstalls?
Uninstalls can be more critical (removal of security software, for example):
<rule id="100201" level="12">
<if_group>windows</if_group>
<field name="win.system.eventID">^11724$</field>
<description>Software desinstalado en Windows: $(win.eventdata.data)</description>
<options>no_full_log</options>
<group>software_uninstall,policy_violation</group>
</rule>Note: Level 12 is higher because uninstalling software can indicate:
- Removal of antivirus or security tools
- A user trying to hide their activity
- Preparation to install malicious software
How do you apply the rules in Wazuh?
Restart the manager to apply them:
systemctl restart wazuh-managerWhat information will you see in the Wazuh dashboard?
When a user installs or uninstalls software, you will see alerts in the dashboard with:
- Name of the software affected
- Machine where it happened
- User who performed the action
- Exact timestamp
Which use cases is this monitoring useful for?
- Regulatory compliance: Auditing software changes (ISO 27001, ENS)
- Threat detection: Alerting if the antivirus is uninstalled
- Policy control: Detecting unauthorized installs
- Software inventory: Keeping a record of changes
Which ISO 27001:2022 controls does this setup cover?
Monitoring software installs and uninstalls with Wazuh helps you comply with several controls in Annex A of ISO 27001:2022:
| Control | Name | How Wazuh helps |
| A.8.19 | Installation of software on operational systems | Detects any install in real time so you can verify whether it is authorized |
| A.8.9 | Configuration management | Records changes to the system configuration (software installed/removed) |
| A.8.15 | Logging | Stores event logs with date, user and affected machine |
| A.8.16 | Monitoring activities | Continuous monitoring with automatic alerts on changes |
| A.5.36 | Compliance with policies and standards | Auditable evidence that permitted software is controlled |
Key benefit: Wazuh rules generate automatic documentary evidence for ISO 27001 audits, proving that there is active control over the software installed on your systems.
Which ENS measures does this monitoring meet?
For Spanish public sector organizations or vendors working with the administration, the ENS (RD 311/2022) requires specific measures that this monitoring helps meet:
| Measure | Name | How Wazuh helps |
| op.exp.1 | Asset inventory | Automatic record of software changes on each machine |
| op.exp.8 | User activity logging | Captures which user installed/uninstalled software and when |
| op.mon.1 | Intrusion detection | Detects unauthorized software that could indicate a compromise |
| op.mon.2 | Metrics system | Centralized dashboard with install statistics |
| mp.sw.1 | Application development | Control over which development tools are installed |
| mp.sw.2 | Acceptance and commissioning | Evidence that deployed software is authorized |
ENS categorization level
The measures op.mon.1 and op.mon.2 are mandatory from the MEDIUM level of the ENS. With these Wazuh rules you meet those requirements automatically and with full documentation.
Why use Wazuh for regulatory compliance?
- Automatic evidence: Every alert is recorded with timestamp, user and machine
- Configurable retention: You can keep logs for as long as the regulation requires (the ENS demands a minimum of 2 years)
- Dashboards for audits: Visual reports ready to present to auditors
- Real-time alerts: You do not wait for an audit to detect non-compliance
- SIEM integration: Correlates software events with other security alerts
- Zero licensing cost: Wazuh is open source, ideal for SMEs on a limited budget
Next steps
Building custom decoders for your own application logs is another part of a complete Wazuh deployment. Once installs and uninstalls are flowing in, a useful refinement is to add an allow-list rule that lowers the level for approved products (your standard browser, your antivirus updater) so the level 12 uninstall alert is reserved for genuinely suspicious removals. Because Wazuh is open source with zero licensing cost, this kind of policy control scales to hundreds of Windows agents without per-endpoint fees, which is why it fits SMEs that still need to prove ISO 27001 and ENS compliance to auditors. Discover our Wazuh services.
Frequently Asked Questions
Which Windows Event IDs signal a software install or uninstall?
Windows Installer (MsiInstaller) writes Event ID 11707 to the Application log on a successful install and Event ID 11724 on a successful uninstall. Both events include the product name, which Wazuh surfaces through the win.eventdata.data field.
Why assign a higher severity level to uninstalls than to installs?
In the example rules the install rule uses level 8 and the uninstall rule uses level 12. Uninstalls deserve a higher level because removing software can mean an attacker is disabling antivirus or security tooling, hiding activity, or preparing to deploy malware.
Do I need a custom decoder to detect software events?
No. The events arrive already parsed in the Windows event channel, so you only filter on win.system.eventID with if_group windows. Two small rules in local_rules.xml are enough; no custom decoder is required.
Which ISO 27001:2022 controls does this monitoring cover?
It maps to A.8.19 (installation of software on operational systems), A.8.9 (configuration management), A.8.15 (logging), A.8.16 (monitoring activities) and A.5.36 (compliance with policies and standards).
How long must I keep these logs for ENS compliance?
The ENS requires a minimum log retention of 2 years. Measures op.mon.1 and op.mon.2 are mandatory from the MEDIUM ENS level, and these Wazuh rules satisfy them automatically while keeping auditable evidence.