Windows Security Log · Event 4719
Event 4719: The audit policy itself was changed
Someone changed what Windows records. This is the event that tells you your logging has been altered — and because turning auditing off is a standard step before doing anything else, a 4719 that nobody can account for deserves more attention than most events in the Security log.
Also written as Event ID 4719System audit policy was changed4719 audit policy tamperingaudit policy changed event log
- How oftenUncommon
- Vendor calls itAudit Success
- LogSecurity
- SourceMicrosoft-Windows-Security-Auditing
What it means for you
For an analyst
The trap is that Group Policy reapplies audit settings on every refresh cycle, so a domain-joined estate produces a steady baseline of 4719s that are entirely legitimate. Alert on the ones that do not match: a change made by a user account rather than SYSTEM, a change that removes a subcategory rather than adding one, or a change on a machine outside the refresh pattern. Note also that 4719 cannot record its own disabling gracefully — an attacker who turns off the Policy Change subcategory removes future 4719s, which makes the last one before the silence the interesting one.
The fields that decide it
Everything else in the log line is context.
- Subject Account Name
- Who changed it. SYSTEM applying Group Policy is the routine case; a named user account is the one to look at.
- Category and Subcategory
- Which part of the audit policy changed. Some subcategories matter much more than others.
-
Logon/LogoffTurning this off removes the record of who signed in. Very high impact. -
Detailed TrackingProcess creation auditing. Disabling it removes Event 4688. -
Policy ChangeThe subcategory that produces this event. Disabling it stops future audit-policy changes being recorded at all. -
Object AccessFile and registry auditing. Usually toggled legitimately because of volume. -
Account ManagementAccount and group changes. Disabling it hides account creation and privilege grants. - Changes
- What was done to the subcategory, expressed as success and failure auditing being added or removed. Removal is what matters; addition is almost always someone improving coverage.
- Subcategory GUID
- The stable identifier for the subcategory. Use this rather than the display name in queries, because display names differ by language and Windows version.
Common questions
Is Event 4719 always suspicious?
No, and treating it that way produces constant false alarms. Group Policy reapplies audit settings on every refresh, so domain-joined machines generate these routinely under the SYSTEM account. The signal is in the exception: a change made by a named user, a subcategory being removed rather than added, or a change on a machine that is not in a refresh window.
How do I see the current audit policy on a machine?
Run 'auditpol /get /category:*' from an elevated prompt. It shows every subcategory and whether success and failure auditing are on. Compare it against what your policy says it should be — a difference means either a local change, which 4719 should have recorded, or a policy that is not reaching the machine.
Why should I care about audit policy changes?
Because every other detection you have depends on the events still being written. Disabling process creation auditing removes Event 4688; disabling logon auditing removes 4624 and 4625. The machine looks quiet afterwards, and quiet is indistinguishable from safe unless you noticed the change. That is the reason this event is worth a rule of its own.
Can an attacker turn off Event 4719 itself?
Yes. It belongs to the Policy Change category, so disabling that category stops further audit-policy changes being recorded. What survives is the 4719 that recorded the disabling, immediately before the silence. In practice this makes an unexplained gap in these events meaningful in itself, which is why some teams alert on the absence as well as the presence.
Read next
- Escalation of Event 1102: The audit log was cleared The Security log being cleared, the blunter version of the same intent.
- Usually comes after Event 4688: A new process has been created Process creation, which stops being recorded if Detailed Tracking is disabled here.
- Usually comes after Event 4624: An account was successfully logged on Logon events, which stop being recorded if Logon/Logoff is disabled here.
- Read alongside Event 5156: The firewall allowed a connection Filtering Platform auditing, the subcategory most often toggled for entirely legitimate volume reasons.
- The equivalent of Event 7040: A service's start type was changed Disabling a service, the other common way to stop something being recorded.
Mentioned by
Vendor documentation
Last reviewed 6 September 2026