Windows Security Event 4699 is the audit event for a scheduled task being deleted. It shows that an existing task was removed from the system, which can matter when investigating lost automation, tampering, or an attempt to hide a scheduled task used for persistence.
What the event means in practice
Windows Security Event 4699 means a scheduled task was deleted. That matters because scheduled tasks often carry the automation behind persistence, maintenance, reporting, or defensive tooling, so deletion can be either routine housekeeping or a sign of tampering.
Viewed operationally, the event is not proof of malice by itself. It is a change record that tells you an existing task disappeared, which can break expected automation, remove a foothold, or obscure a compromise path that used scheduled execution.
Why task deletion is security-relevant
Scheduled tasks are attractive to defenders and attackers because they run on a timer, can execute with elevated context, and may blend into normal administration. When a task vanishes, the security question is often not only “what was removed?” but also “what capability, privilege, or persistence mechanism was lost with it?”
Deletion can also be used to hide evidence after abuse. A malicious actor may remove a task after it has executed, after it has granted repeated access, or after defenders begin investigating the host. For broader Windows event coverage and the surrounding event IDs that help interpret task changes, see the Windows Event Log Guide.
How to interpret and validate exposure
To understand exposure, compare Event 4699 against your asset inventory, approved automation list, and change records. A deleted task is more concerning when it belonged to a server role, ran under a privileged account, or was not tied to a known deployment, patching, or maintenance process.
Correlate the deletion with nearby logon, process creation, service, and task creation or modification events, then check whether the task name, command line, author, and run context match an expected admin workflow. Good logging design matters here, because the event is most useful when it sits inside a searchable and retained audit trail. A practical logging baseline is outlined in the NIST SP 800-92 Log Management Guide.
Detection and response after a deletion event
Event 4699 should trigger a quick review of whether the deleted task was defensive, operational, or suspicious. If the task supported backups, monitoring, patching, or automation, its removal may create an availability gap even when no attacker is present. If the task looks unauthorized, treat it as part of a possible persistence or cleanup sequence.
Response usually means rebuilding the missing task from a trusted source, confirming the associated executable and parameters are still legitimate, and checking for adjacent signs of compromise such as log clearing, script changes, new scheduled tasks, or unexpected privilege use. For fast Windows event triage and log tampering checks, the Hayabusa and Chainsaw Guide is a useful companion.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1053 — Scheduled Task/Job | Event 4699 often marks deletion of task-based persistence or automation in Windows. |
| Recommendation — Map deleted task activity to scheduled-task abuse and correlate it with adjacent persistence or cleanup activity. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | Event 4699 requires review and correlation with related host activity to determine significance. |
| SI-4 — System Monitoring | Task deletion can indicate tampering or loss of a monitored execution path on an endpoint. | |
| Recommendation — Review task deletion events with surrounding logs to determine whether the change was authorised or suspicious. Monitor for unexpected task removal as a potential indicator of compromise or control suppression. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Windows task deletion events are part of the audit trail needed for investigation and detection. |
| Recommendation — Centralise and retain Windows audit events so task deletions remain available for investigation. | ||
Practitioner Guidance
What to watch for: Treat Event 4699 as higher priority when the deleted task is tied to persistence, privileged automation, security tooling, or recurring maintenance. The most important judgement is whether the deletion is explainable by an authorised change record or whether it represents loss of a control or stealth activity.
Practitioner takeaway: Event 4699 is best handled as a change signal plus an investigation cue, not as a stand-alone verdict. Its value comes from correlation, because the meaning of a deleted task depends on what that task did, who removed it, and what else happened on the host.
Related resources from NHI Mgmt Group
- How should security teams improve Windows logon auditing when native Event Viewer is too manual for compliance and forensics?
- Why do provider-aware Windows event mappings matter for security operations?
- How should security teams validate that Windows event normalisation is working?
- How should security teams choose between Windows Event Forwarding and an OpenTelemetry collector for central log collection?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org