What Alerts Should I Set for Windows Configuration Drift?

Set Windows configuration drift alerts for changes that weaken access control, endpoint protection, logging, network defenses, or recovery capability: new local administrators, disabled Defender protections, firewall rule changes, audit-policy changes, new or altered services, and cleared logs. Alert immediately for high-impact changes, collect lower-risk changes for daily review, and compare every managed Windows device against an approved baseline at least once per day. For ISO 27001 Annex A control 8.9, the goal is to prove that configurations are established, documented, implemented, monitored, and reviewed—not merely that a tool was installed.

For a small business without dedicated security staff, the practical approach is not to alert on every registry change. It is to identify the small number of settings that could let an attacker stay in the environment, turn off defenses, access sensitive files, or make an investigation impossible. Your monitoring should also record who made the change, when it occurred, which device was affected, and whether the change was approved.

What does “continuous” actually mean for Windows configuration monitoring?

Continuous monitoring does not mean watching a dashboard all day. For this control, it means using two complementary checks: event-based detection when an important configuration changes, and scheduled comparison when a device gradually moves away from its approved state.

• Immediate event alerts: Send an alert within minutes when Windows records a high-risk change, such as a user being added to the local Administrators group or Microsoft Defender real-time protection being disabled.
• Daily baseline checks: Compare each managed laptop, desktop, and server to a documented expected configuration. This catches drift that may not generate a useful event, including a missing Windows update setting, a changed local security policy, or an unauthorized installed application.
• Monthly review: Review exceptions, recurring alerts, and baseline changes. If a legitimate change is repeatedly occurring, update the approved baseline through a simple documented approval process instead of teaching staff to ignore alerts.

For an SMB, “continuous” can be achieved with Microsoft Defender for Business, Microsoft Intune, Microsoft Sentinel, Wazuh, or another managed detection service. The important point is that the monitoring system receives endpoint events reliably and that someone—an owner, managed service provider, or named operations employee—has responsibility for reviewing them.

Document the baseline in a format you can maintain. A simple spreadsheet or controlled configuration document is acceptable if it identifies the required settings, approved exceptions, device scope, owner, and review date. That record supports ISO 27001 control 8.9 and gives your monitoring tool something meaningful to compare against.

Which telemetry sources support Windows configuration drift alerts?

Use native Windows logs first, then add endpoint-management and file-integrity sources where possible. Windows Event Forwarding, Microsoft Defender for Endpoint, Intune, Wazuh, or a managed SIEM can centralize this information. Do not rely only on a user reporting that “something looks different.”

Which settings deserve an immediate alert?

• A user or group is added to local Administrators, Remote Desktop Users, or Backup Operators.
• A new local administrator account is created, enabled, or has its password reset outside an approved support process.
• Microsoft Defender Antivirus, firewall, SmartScreen, tamper protection, or endpoint detection controls are disabled or materially weakened.
• A Defender exclusion is added for a broad path such as C:\, C:\Users\, *.exe, or a business data share.
• Windows audit policy changes, especially for logon events, process creation, privilege use, account management, and policy changes.
• A Windows event log is cleared, forwarding is stopped, or log retention is reduced.
• A service is installed, a security service is stopped, or an existing service is changed to start automatically.
• Remote Desktop is enabled, Network Level Authentication is disabled, or a broad firewall rule opens RDP, SMB, WinRM, or remote-management ports.
• BitLocker protection is suspended or encryption is disabled on a laptop containing company data.

Not every service change is malicious, and not every firewall adjustment is a crisis. However, these changes can materially alter your security posture. That is why Windows drift alerting should focus on security-relevant configuration rather than ordinary user preferences such as desktop background, printer selection, or browser bookmarks.

What SIEM queries can detect high-risk configuration changes?

The following examples are starting points. Test them with a known authorized change before relying on them, and confirm that your endpoint agent is collecting the relevant channels. In Microsoft Sentinel, Windows events are commonly available in the WindowsEvent table.

How can Microsoft Sentinel identify audit, service, and log-clearing changes?

WindowsEvent
| where EventID in (1102, 4719, 4697, 7040, 7045)
| extend Account = tostring(EventData.SubjectUserName)
| extend ServiceName = tostring(EventData.ServiceName)
| project TimeGenerated, Computer, EventID, Account, ServiceName, RenderedDescription
| order by TimeGenerated desc

Create separate analytic rules for Event ID 1102 and 4719 with high severity. A cleared log or reduced audit coverage can hide follow-on activity, so these should create an incident rather than wait for a daily summary.

How can Microsoft Sentinel find Defender configuration changes?

WindowsEvent
| where Provider == "Microsoft-Windows-Windows Defender"
| where EventID == 5007
| project TimeGenerated, Computer, RenderedDescription
| where RenderedDescription has_any (
    "DisableRealtimeMonitoring",
    "DisableBehaviorMonitoring",
    "Exclusions",
    "DisableIOAVProtection",
    "Tamper Protection")
| order by TimeGenerated desc

Defender generates Event ID 5007 for many setting changes. Treat broad exclusions and disabled protections as high severity; route minor, approved policy refreshes to a daily review queue.

How can Splunk identify suspicious Windows service changes?

index=wineventlog sourcetype="WinEventLog:System"
(EventCode=7040 OR EventCode=7045)
| eval critical_change=if(match(Message,
    "(?i)(Windows Defender|WinDefend|EventLog|Sysmon|Wazuh|EDR|backup)"),"yes","no")
| stats values(Message) as details by host, EventCode, critical_change
| where critical_change="yes"

If you use a managed service provider, ask whether it can implement these detections in its existing platform. You do not need to buy a separate SIEM just to meet the intent of the control, but you do need reliable evidence that changes were detected and handled.

How do you tune configuration-drift notifications without missing real problems?

The best way to reduce alert fatigue is to define expected change windows and approved actors before creating broad exclusions. Never suppress an alert merely because it is inconvenient; suppress it only when you can identify the legitimate process that creates it and can still detect misuse.

• Allow known management accounts: Exclude expected changes made by your Intune service account, RMM tool, or documented MSP administrator account—but only during approved maintenance windows where possible.
• Use device groups: A change that is normal on a test PC may be urgent on a file server, finance laptop, or domain controller.
• Set severity by impact: A newly installed printer service may be medium severity; disabled endpoint protection, cleared logs, and new administrative access should be high severity.
• Group duplicates: If Intune changes the same policy on 40 devices, create one incident with affected-device count rather than 40 separate emails.
• Require context: Include hostname, user or process, old and new value, source IP when available, and related ticket number. An alert without this context is difficult for an owner to act on.
• Review suppressions monthly: Expire temporary exceptions automatically. A suppression created for a one-time software rollout should not remain forever.

A useful rule for an owner is simple: if an alert says a security control was weakened and there is no matching change request or maintenance notice, treat it as suspicious until proven otherwise. This keeps the decision manageable without requiring deep security expertise.

How should configuration drift alerts connect to your incident response runbook?

Your alert is only useful if it triggers a repeatable response. Add a short configuration-change section to your incident response runbook, with a named primary reviewer and backup reviewer. This is especially important when the business relies on an MSP: specify whether the MSP only notifies you, investigates, or has authority to isolate a device.

1. Validate: Check the device, affected setting, account or process, timestamp, and any approved change ticket. Confirm whether the device is a server, executive laptop, finance workstation, or ordinary endpoint.
2. Contain: For high-risk unauthorized changes, disconnect the device from the network through your EDR or RMM tool, disable the affected account, and block remote access if needed.
3. Restore: Reapply the approved configuration through Intune, Group Policy, or your RMM platform. Do not simply reverse the visible setting without checking for related accounts, services, scheduled tasks, or exclusions.
4. Investigate: Review recent logons, PowerShell activity, new processes, service installations, and endpoint detections around the change time.
5. Document and review: Record the alert, decision, remediation, evidence, and whether the baseline or alert rule needs adjustment. This provides evidence for ISO 27001 control 8.9 review activities.

Start this week by choosing five high-impact settings, assigning one person to review their alerts, and testing that your monitoring system can detect an authorized change and its restoration.