If an expected Windows security event is missing, first read the audit policy rather than enabling every category or assuming the event was deleted. The built-in auditpol /get command retrieves audit settings without changing them. Its output describes policy at the time you query it; it does not prove an action occurred, an event was generated, or a collector received that event.
This workflow is for an authorised review of a Windows workstation or server. It separates a configuration question from an event-evidence question, so a support ticket contains something more useful than an empty search screenshot.
Read the system policy without choosing an English category name
Open Command Prompt on the computer you are investigating and run:
auditpol /get /category:*The asterisk requests all audit categories. Leaving out /user means that the query is for system audit policy, not a named account’s per-user policy. This matters when an investigation involves one user: system settings and a specific per-user audit policy are different things, so label the evidence accurately.
Microsoft documents a read-permission requirement for system and per-user policy queries. The Manage auditing and security log user right can also permit the operation, but grants additional access beyond a simple read. If access is denied, record the error and use your organisation’s approved administrator or security-team workflow. Do not disable protection or grant a broad privilege merely to make an evidence command succeed.
Interpret success and failure as separate settings
Read the subcategory relevant to the action you expected to see. Success auditing and failure auditing refer to different outcomes; seeing one enabled does not establish that the other is enabled. A failed sign-in investigation should not rely only on a success setting, for example.
Conversely, an enabled setting is not a promise that every application action produces the event you had in mind. Identify the expected event, the action that should generate it, and the computer where generation should occur. An application’s own log and the Windows Security log need not represent the same event stream.
For a hypothetical ticket, write: “System audit policy read on the affected computer; relevant subcategory shows the displayed success/failure settings; expected event not found in the searched interval.” Do not turn that observation into “auditing has always been enabled” or “the user never attempted the action.” A current snapshot cannot establish either historical claim.
Use report output for a structured handoff
To display the policy in comma-separated report format, use:
auditpol /get /category:* /rThe report format can make a review easier to retain or compare, but it still describes audit policy rather than exported event records. Review it on screen first. If you save or attach output through an approved process, record the computer, collection time including timezone, command, and whether the session had additional privileges. Protect machine names and other operational details according to your evidence-handling rules.
For a narrower follow-up, Microsoft supports category and subcategory names or GUIDs. Do not paste an English display name into a localised environment and assume it identifies the intended setting. The all-category query avoids needing a translated name for this first inventory. If a command errors, preserve the error rather than interpreting it as “no auditing.”
Follow the evidence chain before changing policy
- Confirm that the query ran on the intended computer, not a technician’s own device.
- Record the relevant current subcategory settings and the expected event or action.
- Check the searched log, interval, timezone, and filters separately from policy.
- If forwarding is involved, distinguish local event presence from collector arrival.
- Ask the authorised owner to review historical configuration and event-retention evidence where needed.
Change management comes after that read-only investigation. Avoid broad enablement as an improvised troubleshooting step: it changes the system being investigated and can increase event volume. This article deliberately contains no policy-changing command, so there is no configuration rollback to perform.
Questions that prevent misleading conclusions
Does this prove compliance? No. It supplies one configuration observation, not a complete control assessment or proof of retained events.
Does a successful command prove logging works? No. Query success means the policy read completed. Event generation, storage, retention, forwarding, and review need separate evidence.
For another read-only endpoint review, see checking Microsoft Defender signature freshness. That inspection addresses antivirus signatures, not Windows audit-policy coverage.
Source: Microsoft’s auditpol get command reference documents the query syntax, permission requirements, system/per-user distinction, and report option.
Safety: This tutorial is for educational purposes. Test commands carefully before production use and obtain authorisation. The site owner is not responsible for misuse, damage, data loss, or production issues.
