Tracking who reads, modifies, creates, or deletes files inside a specific folder requires two separate configurations in Windows: enabling object access auditing at the operating system level and attaching a System Access Control List (SACL) audit entry to the target folder itself. If you enable the system policy alone, Windows records nothing because no folders are flagged for monitoring; if you configure a folder's Auditing tab without enabling the system policy, Windows ignores the rules. Once both layers are active, Windows writes detailed access records—primarily Event IDs 4656, 4663, and 4660—to the Windows Security log in Event Viewer. This native auditing workflow applies to Windows 10, Windows 11, and Windows Server 2016 through Windows Server 2025.

A laptop displays Windows security audit logs beside a file-access checklist and shield graphic. Prerequisites and Compatibility​

Before configuring file-system auditing, verify that your environment meets these technical requirements:

Quick walkthrough

35323444f2b5-exact.webp
  • Account permissions: You must be signed in as a member of the local Administrators group, or possess an account explicitly granted the Manage auditing and security log (SeSecurityPrivilege) user right. Standard users cannot view or modify the Auditing tab on folders or open the Security log in Event Viewer.
  • File system format: The target folder must reside on an NTFS or ReFS volume. Drives formatted with FAT32 or exFAT do not support security descriptors or SACLs and do not display a Security tab in File Explorer.
  • Windows edition: All editions of Windows 10 and Windows 11 support folder SACLs and the command-line auditpol.exe utility. However, the Local Security Policy console (secpol.msc) and Local Group Policy Editor (gpedit.msc) are included only in Windows 10 and Windows 11 Pro, Enterprise, and Education editions (as well as Windows Server). If you use Windows 10 Home or Windows 11 Home, use the elevated Command Prompt method in the alternate section below to enable the system policy.

Step 1: Enable the Audit File System Policy​

Microsoft provides two policy paths for object auditing: legacy category policies and Advanced Audit Policy Configuration. You should always use Advanced Audit Policy Configuration (Audit File System) rather than the legacy Audit object access setting. Enabling the legacy setting turns on auditing across all object subcategories simultaneously (including registry keys, kernel objects, SAM, and certification services), which floods the Security log with thousands of unrelated background events.

Warning: In an Active Directory domain environment, domain-level Group Policy Objects (GPOs) periodically overwrite local audit policy changes. If the machine is domain-joined, check whether a domain GPO controls audit settings before editing local policy, or configure the policy within the appropriate GPO using the Group Policy Management Console (gpmc.msc).

To enable file-system auditing on Windows 10 or Windows 11 Pro, Enterprise, or Education:

  • Press Windows + R to open the Run dialog box, type secpol.msc, and press Enter (or click OK). If prompted by User Account Control, click Yes.
  • In the left navigation pane of the Local Security Policy window, expand Advanced Audit Policy Configuration, expand System Audit Policies - Local Group Policy Object, and select Object Access.
  • In the right pane, double-click Audit File System.
  • Check the Configure the following audit events box.
  • Check Success to log permitted access attempts, Failure to log denied access attempts (such as a user trying to open a restricted file), or both, depending on your monitoring goal.
  • Click Apply and then click OK.

Local Security Policy with the Security Settings tree (Account Policies, Local Policies).

(Optional) If you need to record the exact timestamp when a user or application closes a file handle (Event ID 4658), double-click Audit Handle Manipulation in the same Object Access list, enable Success, and click OK. For standard tracking of who opened, modified, or deleted a file, Audit File System alone is sufficient.

The policy takes effect immediately without requiring a system restart.

Step 2: Configure the Folder Audit Entry (SACL)​

After telling Windows to monitor the file system, you must specify which folder to watch, which users or groups to track, and which specific actions should trigger an event.

Warning: Avoid applying broad Read auditing to system root directories such as C:\, C:\Windows, or C:\Program Files for the Everyone or Users group. Background operating system processes access those paths hundreds of times per second, which can rapidly overwrite your Security log and degrade disk and CPU performance. Scope your audit entry strictly to the sensitive data folders you need to track.
  • Open File Explorer and navigate to the folder you want to monitor.
  • Right-click the folder and select Properties. (On Windows 11, you can also press Alt + Enter with the folder selected, or right-click and choose Properties directly from the top-level menu).
  • Select the Security tab and click the Advanced button near the bottom of the dialog box.
  • In the Advanced Security Settings window, select the Auditing tab. If a Continue button with an administrator shield icon appears in the middle of the tab, click Continue to elevate your view.
  • Click Add at the bottom left to open the Auditing Entry window.
  • Next to Principal, click Select a principal.
  • In the Enter the object name to select box, type the username or group you want to monitor. To track all signed-in domain and local accounts while excluding anonymous network activity, type Authenticated Users (or type Everyone to include all accounts), click Check Names to verify the underline appears, and click OK.
  • Open the Type drop-down menu and select Success, Fail, or All (which covers both successful and failed attempts). Note that you can only select a Type that matches what you enabled in the system policy in Step 1.
  • Open the Applies to drop-down menu and choose the inheritance scope. Select This folder, subfolders and files to monitor the entire directory tree, or select This folder only if you do not want subfolders audited.
  • Under Basic permissions, check the actions you want to log, or click Show advanced permissions on the right side of the dialog box for granular control:
  • To track who opens or views files: Check List folder / read data (under advanced permissions) or Read & execute (under basic permissions).
  • To track who creates or modifies files: Check Create files / write data and Create folders / append data (under advanced permissions), or Write (under basic permissions).
  • To track who deletes files or folders: Click Show advanced permissions, clear the broad read/write boxes if you want to avoid log noise, and check only Delete and Delete subfolders and files.
  • To track who changes permissions or takes ownership: Under advanced permissions, check Change permissions and Take ownership.
  • Click OK to close the Auditing Entry dialog box.
  • Click Apply and then OK in the Advanced Security Settings window, and click OK to close the folder Properties window.

Step 3: Verify Auditing and Interpret Events in Event Viewer​

To confirm your configuration works and learn how to read the output, perform a test action inside the audited folder (such as creating a new text file, opening it, and deleting it) and then inspect the Security log.

  • Press Windows + R, type eventvwr.msc, and press Enter to open Event Viewer.
  • In the left console tree, expand Windows Logs and select Security.
  • In the right-hand Actions pane, click Filter Current Log....
  • In the Includes/Excludes Event IDs box (labeled <All Event IDs>), enter 4656, 4660, 4663 and click OK.
  • Click the newest events at the top of the middle pane and review the General tab below to read the audit details.

Event Viewer opens to its main MMC window with the navigation tree on the left, overview or event content in the center, and the Actions pane on the right.

Understanding File System Event IDs​

When a user interacts with an audited file or folder, Windows records a sequence of events rather than a single line. Understanding how the three primary Event IDs relate to one another prevents misinterpretation:

  • Event ID 4656 (A handle to an object was requested): Logged when an application or user asks the operating system to open a file or folder and specifies what permissions it intends to use. This event records both Audit Success and Audit Failure. If a user without permission attempts to open a restricted file, Event ID 4656 with a keyword of Audit Failure is the primary event you will see; no 4663 event will follow because the handle request was denied.
  • Event ID 4663 (An attempt was made to access an object): Logged only for Audit Success after a handle is granted and the user or process actually performs the requested operation (such as reading data from the file, writing changes, or marking the item for deletion). For confirmed actions, 4663 is the most reliable indicator of what actually happened.
  • Event ID 4660 (An object was deleted): Logged when a file or folder is actually removed from the file system. Because Event ID 4660 records the Handle ID and Transaction ID rather than repeating the full file path in every instance, you correlate its Handle ID with the preceding Event ID 4663 (which contains Accesses: DELETE and the full file path under Object Name).

Key Fields Inside Each Event​

When examining Event ID 4663 or Event ID 4656, look at these four sections on the General tab:

  • Subject: Identifies who performed the action. Check Account Name and Account Domain to see the user account, and Logon ID to tie the activity back to a specific sign-in session (Event ID 4624).
  • Object: Identifies what was touched. Object Server will show Security, Object Type will show File (which Windows uses for both files and directories), and Object Name displays the full local path of the file or folder accessed (for example, D:\Finance\Q4_Budget.xlsx).
  • Process Information: Displays the Process Name of the executable that performed the operation, such as C:\Windows\explorer.exe, C:\Windows\System32\notepad.exe, or C:\Windows\System32\ntoskrnl.exe (when accessed over an SMB network share).
  • Access Request Information: Under Accesses (and numeric Access Mask), Windows lists the exact permission exercised:
  • ReadData (or ListDirectory) (0x1): The file content was read or the directory contents were listed.
  • WriteData (or AddFile) (0x2): Data was written to a file, or a file was added to the folder.
  • AppendData (or AddSubdirectory or CreatePipeInstance) (0x4): Data was appended or a subfolder was created.
  • ReadAttributes (0x80): File Explorer or an application inspected basic metadata (size, timestamps, attributes).
  • DELETE (0x10000): The file or folder was deleted or renamed/moved.
  • WRITE_DAC (0x40000): The folder or file permissions (DACL) were modified.
  • WRITE_owner (0x80000): Ownership of the file or folder was changed.

Filtering by Exact Folder Path (XML Query)​

If you monitor multiple folders on a busy system, filtering by Event ID alone still shows activity across every audited directory. You can filter the Security log down to a single folder or file name using an XML query:

  • In Event Viewer, with the Security log selected, click Filter Current Log... in the Actions pane.
  • Select the XML tab at the top of the dialog box.
  • Check Edit query manually at the bottom and click Yes on the confirmation prompt.
  • Paste the following query into the text box, replacing C:\Shared\Finance\Report.xlsx with the exact full path of a specific file you want to track:
Code:
<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
      *[System[(EventID=4656 or EventID=4663)]]
      and
      *[EventData[Data[@Name='ObjectName']='C:\Shared\Finance\Report.xlsx']]
    </Select>
  </Query>
</QueryList>
  • Click OK to apply the filter.

Alternate Method: Enable and Verify Policy via Command Line​

On Windows 10 Home, Windows 11 Home, Windows Server Core, or when scripting across multiple machines, secpol.msc is either unavailable or impractical. You can configure and verify the system audit policy directly using auditpol.exe.

  • Open the Start menu, type cmd, right-click Command Prompt, and select Run as administrator.
  • To check the current audit state of the Object Access category, run:
    auditpol /get /category:"Object Access"
  • Inspect the line for File System. If it reports No Auditing, enable both Success and Failure auditing by running:
    auditpol /set /subcategory:"File System" /success:enable /failure:enable
    (If you only want to track successful actions, change /failure:enable to /failure:disable).
  • Re-run auditpol /get /category:"Object Access" to confirm File System now displays Success and Failure.

Once enabled via auditpol.exe, configure the folder's Auditing tab in File Explorer using the exact steps in Step 2 (the Auditing tab in File Explorer is present in all Windows editions, including Home).

Increasing the Security Log Maximum Size​

By default, Windows client systems often configure the Security log maximum size to 20 MB (20480 KB), with the retention policy set to Overwrite events as needed (oldest events first). Active folder auditing can fill a 20 MB log in hours or days, erasing older evidence.

To increase the log capacity:

  • In Event Viewer, expand Windows Logs, right-click Security, and select Properties.
  • In the Maximum log size (KB) box, increase the value to a multiple of 64 KB that fits your storage and retention needs—for example, 131072 (128 MB) or 524288 (512 MB).
  • Ensure Overwrite events as needed (oldest events first) is selected so the system does not halt or stop logging when the file reaches capacity.
  • Click Apply and OK.

Troubleshooting and Rollback​

Audit Events Do Not Appear in Event Viewer​

  • Legacy policy is overriding Advanced Audit Policy: If an older Group Policy configures basic audit categories, Windows may ignore subcategory settings unless forced. Open Local Security Policy (secpol.msc), navigate to Local Policies > Security Options, and verify that Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings is set to Enabled.
  • Domain GPO overwrote local settings: Run auditpol /get /category:"Object Access" in an elevated Command Prompt. If File System reverted to No Auditing after a background Group Policy refresh, a domain GPO is managing the machine's audit configuration. Run gpresult /h gpreport.html in an elevated Command Prompt to identify the winning GPO and update the policy there.
  • Inheritance was blocked or the wrong scope was selected: Re-open the folder's Properties > Security > Advanced > Auditing tab. Verify that Applies to is set to This folder, subfolders and files rather than This folder only. If This folder only is selected, opening or deleting files inside the folder will not generate events for those child files.

Too Many Events Generated for a Single File Action​

  • Why it happens: When a user opens a folder in File Explorer or opens a document in Microsoft Word, the application reads file attributes, checks permissions, opens temporary lock files, and reads data blocks across multiple handles. If you check Full control or Read & execute in the folder's Auditing Entry, a single double-click can generate 10 to 30 Event ID 4656 and 4663 entries.
  • How to fix it: Edit the folder's Auditing Entry, click Show advanced permissions, and uncheck Read attributes, Read extended attributes, and Read permissions. Leave only the specific high-value operations checked, such as Create files / write data, Delete, and Delete subfolders and files.

How to Roll Back and Disable Folder Auditing​

If you no longer need to monitor a folder or need to stop Security log growth immediately, remove the SACL entry and disable the system policy:

  • Right-click the audited folder in File Explorer, select Properties, open the Security tab, and click Advanced.
  • Select the Auditing tab (click Continue if prompted).
  • Select the auditing entry you created, click Remove, and click OK twice to save the change. (If the Remove button is grayed out, the audit rule is inherited from a parent directory; either remove the rule on the parent folder indicated in the Inherited from column, or click Disable inheritance at the bottom of the Auditing tab and choose Remove all inherited auditing entries from this object).
  • To turn off system-wide file-system auditing completely, open an elevated Command Prompt and run:
    auditpol /set /subcategory:"File System" /success:disable /failure:disable
 

Last edited by a moderator: