File server auditing is the practice of recording who opened, changed, deleted or changed permissions on files and folders, so you can answer for your data when someone asks. Windows Server can do this natively, but it takes two separate settings to work, and a careless setup either records nothing useful or buries you in events. This guide covers how to set it up, which events matter, how to keep the volume sensible, and what auditors expect to see.
Why file server auditing matters
File shares hold a lot of the data regulations care about: finance exports, HR records, patient documents, customer lists. They also tend to accumulate broad permissions over the years. When a question comes up, whether from an investigator or an auditor, it is usually very specific: who accessed this folder between these dates, and what did they do?
Several frameworks require you to be able to answer. PCI DSS 10.2.1.1 says audit logs must capture all individual user access to cardholder data. HIPAA’s 45 CFR 164.312(b) requires mechanisms that record and examine activity in systems containing electronic protected health information. The GLBA Safeguards Rule, at 16 CFR 314.4(c)(8), requires monitoring and logging the activity of authorized users and detecting unauthorized access to customer information.
How to enable file auditing on Windows Server
This is where most setups go wrong. Windows needs both of these in place, and neither one works alone:
- The audit policy. In Group Policy, under Advanced Audit Policy Configuration, enable the Audit File System subcategory for the file servers.
- The SACL on the folder. In the folder’s Properties, go to Security, then Advanced, then Auditing, and add an entry stating whose access to record and which kinds of access.
As Microsoft’s documentation puts it, audit events are generated only for objects with configured SACLs, and only if the type of access requested and the account making the request match the settings in the SACL. So a policy with no SACL produces nothing, and a SACL with no policy produces nothing either. Neither failure shows an error, which is how organizations end up discovering the gap during an incident.
Once both are set, test them. Open, change and delete a test file in an audited folder, then confirm the events appear in the Security log on that server.
Which file server events to watch
| Event ID | What Windows records | How to use it |
|---|---|---|
| 4663 | An attempt was made to access an object | The main event. It shows that an access right was actually used, rather than only requested. |
| 4656 | A handle to an object was requested | Shows the access requested, and failures when auditing covers them. Noisier than 4663. |
| 4660 | An object was deleted | Generated on real deletions, but it holds only a handle ID and not the file name. Pair it with 4663. |
| 4670 | Permissions on an object were changed | Important for spotting folders being opened up. It does not fire for changes to the auditing settings themselves. |
| 4907 | Auditing settings on object were changed | Tells you when someone changed what is being recorded on an object. |
| 5140 | A network share object was accessed | Shows a connection to a share, from the Audit File Share subcategory. |
| 5145 | A network share object was checked to see whether client can be granted desired access | Share-level detail, from Audit Detailed File Share. Useful for failures, and high in volume on success. |
Two details are worth remembering. To find out who deleted a file, you generally need 4663 with DELETE access, because event 4660 does not name the file. And reading these events takes some interpretation, since one action in Windows Explorer can produce several records.
How to keep the event volume manageable
The most common mistake after a failed setup is the opposite one: auditing everyone, everything, everywhere. A busy file server can then produce far more events than anyone will read, and the Security log wraps sooner, which can destroy the evidence you were trying to keep. A few choices keep it under control.
- Start with what is in scope. Audit the folders holding regulated or sensitive data rather than the whole volume. If you do not know where that data lives, solve that first. See find your sensitive data before an auditor does.
- Record meaningful access types. Writes, deletes and permission changes are usually the priority. Add read auditing where the framework or data requires it, as with cardholder data under PCI DSS 10.2.1.1.
- Be deliberate with failures. Microsoft notes that success auditing on Detailed File Share can generate high volume, especially on domain controllers because of SYSVOL, and suggests monitoring failed access attempts there instead.
- Send events off the server. Forwarding to a central store protects the history from log rollover, and from anyone with administrator rights on the file server itself.
Where native file auditing runs out
Native auditing can generate the record, but it leaves you several jobs:
- Each server keeps its own log. Following one person across several servers means collecting from each.
- Windows only covers Windows. Linux and macOS file systems and OpenText NSS volumes have their own mechanisms and formats, so a mixed estate produces mixed evidence.
- Events describe actions rather than exposure. The log can tell you someone opened a file. It will not tell you that a folder of sensitive files is readable by far too many people.
- Nothing connects a record to a control. An auditor is testing a specific requirement, and raw events still have to be turned into something that answers it.
What auditors expect from file access records
A useful file access record identifies the account, the object, the action, the time and the outcome. PCI DSS 10.2.2 spells out a similar list: user identification, type of event, date and time, success or failure, origination, and the identity of the affected data or resource. NIST SP 800-171 Rev. 3 sets out comparable content in 03.03.02.
Beyond the record itself, expect these questions:
- Can you cover the whole period? PCI DSS 10.5.1 requires 12 months of history with three months immediately available. NIST 03.03.03 ties retention to your own policy. HIPAA’s audit controls standard does not state a log retention period, so document your decision, and take advice on how the six-year documentation rule in 45 CFR 164.316 applies to you.
- Who reviews it? HIPAA 45 CFR 164.308(a)(1)(ii)(D) requires regular review of activity records, and PCI DSS 10.4.1 requires daily review of security events and logs from in-scope systems. Keep a record of the review, not only the logs.
- Are the logs protected? PCI DSS 10.3.2 and NIST 03.03.08 both expect protection from modification.
- Who has access now? PCI DSS 7.2.4 requires access reviews at least every six months. File share permissions are often the part of this review that gets skipped.
A file server auditing checklist
- Sensitive and regulated folders have been identified.
- Audit File System is enabled on every in-scope server, confirmed by checking the effective policy.
- SACLs are applied to in-scope folders and cover the right access types.
- A test has confirmed that events appear for reads, writes, deletes and permission changes.
- Events are forwarded to a central store that file server administrators cannot alter.
- Retention is documented and meets your framework.
- Alerts exist for permission changes on sensitive folders and for unusual bursts of access.
- Share and folder permissions are included in your periodic access reviews.
- You have tested answering “who accessed this folder” for a date six months ago.
Common questions about file server auditing
How do I see who accessed a file on a Windows server?
Enable the Audit File System policy, add a SACL to the folder, then check the Security log on that server for event 4663. It shows the account, the file and the access used. Windows only records access from the point auditing was turned on, so it cannot answer for earlier activity.
Why are my file audit events not appearing?
The usual cause is that only one of the two required settings is in place. You need the Audit File System policy applied to the server and a SACL on the folder that matches the user and access type. Also confirm the policy is effective on that server, and that the log has not wrapped.
Can Windows tell me who deleted a file?
Yes, if auditing was already on. Look for event 4663 with DELETE access, which names the file and the account. Event 4660 confirms a deletion occurred, but contains only a handle ID, so use the two together. Without prior auditing, Windows has no record of who did it.
Does file auditing slow down a server?
It can add load, and the effect depends on how much you audit and how busy the server is. Broad read auditing across a whole volume costs the most. Scoping auditing to sensitive folders and meaningful access types keeps both overhead and log volume down, so test in your own environment.
See file activity in one place
LT AuditorMP® monitors file and folder access across Windows, Linux and macOS systems and OpenText NSS file systems, detects permission changes, and discovers sensitive data across your environment. It keeps that activity alongside identity events and exports reporting mapped to frameworks including HIPAA, PCI DSS, ISO 27001 and NIST. For the identity side, read our guide to Active Directory auditing.
Request a demo to see who is accessing what in your own environment.