Audit policy is the cheapest security control on a Windows Server and also the fastest way to fill a Security log. Turning on “Audit object access” with both Success and Failure sounds harmless until you measure it: a single file server session that opens, reads, and closes 400 documents a day generates roughly 1,200 events for each active user, and a backup agent scanning a share can produce six figures of event 4663 in an hour. The Security log then rolls over and destroys the very evidence you enabled auditing to collect.
The fix is not “audit less” in the abstract — it is to audit the specific object-access subcategories that map to an incident you can actually act on, with a SACL scoped to the paths that matter. This walks through the categories, the volume math, and a recommended subset that keeps a 128 MB Security log covering weeks instead of hours. On a small VPS with limited disk, the log pressure angle matters even more than on a managed server — the Windows VPS plan comparison shows which tiers give you enough disk to keep logs local.
The auditpol categories that matter
Windows splits auditing into categories and subcategories, and only the subcategory setting takes effect when group policy is configured. The object-access category contains at least nine subcategories: File System, Registry, Kernel Object, SAM, Certification Services, Application Generated, Handle Manipulation, File Share, and Detailed File Share. Listing them is one command: auditpol /list /subcategory:* /category:"Object Access".
Enabling the whole category is the default mistake, because “Detailed File Share” alone can multiply event volume by two to five times and “Handle Manipulation” produces an event for every handle open, not every file access. Configure per-subcategory with auditpol /set /subcategory:"File System" /success:enable /failure:enable and never use the category-level switch on a production VPS.
What actually floods the Security log
The high-volume events are 4663 (an object was accessed), 4656 (a handle was requested), 4658 (the handle was closed), and 4670 (permissions on an object were changed). 4656 and 4658 come in pairs with 4663 between them, so a single successful read is often three events. On a file share with 20 users each opening 300 files per day, that is 20 × 300 × 3 = 18,000 events per day before any failure is logged.
Add the access mask. A read-only open is one 4663; a locate-then-read pattern adds a 4656. A backup agent running as SYSTEM scanning 400,000 files nightly can emit well over a million events in a single pass. If SYSTEM is included in your SACL, your Security log will exist only to describe the backup job.
Volume math per user and per day
A 4663 record with full properties is roughly 700-900 bytes in EVTX once headers and strings are included; 4656 and 4658 sit around 600 bytes. Ten thousand events therefore consume 7-9 MB. A 128 MB Security log with 20% headroom holds roughly 115,000 to 145,000 events — which, at 18,000 events per day for 20 users, is about one week. Double the users and you are down to three days.
On a 2 TB share with more than 50 active users, sized for a 30-day retention requirement, file-system success auditing for all users is simply not affordable on a single VPS disk. The answer is to audit failure only across the whole share, and success only on a narrow set of sensitive folders.
Recommended subset for a VPS file server
| Subcategory | Success | Failure | Reason |
|---|---|---|---|
| File System | Off broadly, On for sensitive SACL paths | On | Failures are rare and always interesting |
| File Share | Off | On | Share-level denial, low volume |
| Detailed File Share | Off | Off | Multiplies volume, duplicates File System |
| Registry | Off | On (key SACLs only) | Persistence attempts touch Run keys |
| Handle Manipulation | Off | Off | Only for handle-leak debugging |
| SAM | Off | On | Local account modification evidence |
| Kernel Object | Off | Off | No actionable signal on a VPS |
4624 and 4656: the events that dominate once file access is on
Once File System success auditing is enabled, 4663 usually takes second place to 4656, because every handle request is logged whether or not the read succeeds. Meanwhile 4624 counts once per logon type — a mapped drive keeps one Type 3 logon alive, but a script that connects, copies, and disconnects 200 times a day writes 200 of them. On a share used by a nightly ETL job, 4656 outnumbers 4663 by roughly 3:1.
That is the strongest argument for auditing failures only at the volume level and successes only on a small SACL path. Failure volume is driven by anomalies rather than routine, so it stays flat at a few hundred events per day and every one of them is worth reading. If the Security log is one week deep on a well-used share, success auditing is what consumed it.
Scoping a SACL to one folder instead of the volume
A SACL is what actually causes object-access events; the audit policy subcategory only permits them to be written. Grant the SACL to the principal you care about, not to Everyone: icacls D:\finance /audit:*(S,F) "DOMAIN\SG_Finance_Users" writes successes and failures. Apply to a folder with 500 files, not to a 2 TB volume. Test with Get-Acl D:\finance -Audit | Format-List.
For registry persistence, target the keys that matter: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, RunOnce, and the service registry root. Auditing the entire HKLM subtree produces tens of thousands of events daily from normal system activity and buries the one entry that matters. A SACL on three keys is a week of work once and near-zero volume thereafter.
Log rollover pressure and what to do about it
The Security log is circular by default. Once it fills, oldest events are overwritten and 1102 is recorded only if someone clears it manually — overwrite is silent. Two changes reduce risk without buying disk: set AutoBackupLogFiles in HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Security to 1, and shrink a few noisy subcategories rather than raising the maximum size past what the VPS disk can spare.
Forward events off the box if retention matters. Windows Event Forwarding to a collector over WinRM on 5986 costs a few KB per event on the wire and removes the dependency on local disk entirely. If you cannot run a collector, then the correct answer is a much smaller audit subset — the log is a bridge to your alerting, not an archive. Decide which audit categories you can afford before you buy disk, and check the storage included in each plan on the provider comparison table to size the log against real capacity.
