Hi, this is Richard Sasser 'Rick', MCM, Red shirted dude (security guy). This might seem like old data, but you’d be surprised how many people looked at Security Auditing in Windows Server 2008 and 2008R2, saw that the old policies applied, and subsequently just checked the box and moved forward.
Auditing changed. Auditing changed a LOT. If your security team did not redesign your audit policy in 2008, then you absolutely must address this problem. And before you look at me and say, but “surely since 2008 they have…” close thy mouth, blasphemer. They haven’t. There’s a reason I’m writing this in 2014, and that’s because this has started to become a pattern I’m seeing EVERYWHERE. The state of security in the IT World is “We have a whole lot of work to do.” I won’t editorialize on the reasons here, but you might find some editorializing later.
So you might have security auditing problem if:
You have configured your audit policies with Windows 2003’s original 9 policies and let them roll forward
Windows 2003 has nine Auditing categories. Windows 2008 and later have subcategories. There are nine, arguably ten, subcategories. (See HERE). Those subcategories have 53+ settings (more were added later). If you left the nine categories enabled, all you really did was enable every subcategory. Congratulations. If “Object Access” was enabled, you just enabled Filtering Platform Connection. And your server might now be a candidate for EXCESSIVE logging.
You have configured everything (or even just the wrong things) for success and failure
Excessive logging is the equivalent of not logging. I’ve seen windows servers log 3,000 events per second. Yep. Not a typo. While initially the performance of the queue in 2008 and later is asynchronous, under heavy logging the queue becomes synchronous and your performance is gated on the ability to audit. So in the instance above of Filtering Platform Connection, success, you just made your ultrafast SQL, webserver, whatever, as fast as C:\ drive. Not the bottleneck you were looking for? To get an idea of performance you need to measure disk performance on C:\ drive before and after. Transfers/sec, Sec/Transfer and pages/sec counters on the drive that stores the evtx files will generally get you there, but realistically you need before and after trending to validate improvements (Or degradations). This is about RATE. Not Size. Which brings us to:
You have configured your security log to be 4 GB in size because you don’t want to miss anything
Remember that sixteen GB server you bought? Congratulations, you took 4 GB out of it. Security Event logs are memory mapped files (download RAM MAP and see). That’s why pages/sec can be a useful counter. Virtualizing thousands of hosts? Want to save RAM? Might want to set this just a bit lower. Some more, albeit older data is in Recommended settings for event log sizes in Windows Server 2003, Windows XP, Windows Server 2008 and Windows Vista
You configured the audit policy and checked it with GPRESULT /h
More of Mr. Pyle’s wisdom can be found here. The ONLY, and I mean ONLY way to get the actual effective audit policy is to use auditpol /get /category:*. Mr. Pyle also references another important setting in that blog, which is
You have set Audit: Force audit policy subcategory settings to disabled
Information from the same blog, above. You’re looking at never applying the new policies. Everything will be the old policies, which pretty much MEANS all of the subcategories. Try not to do this 
You have configured your log scraping/monitoring/software to catch the three digit id’s you’re looking for
And those droids just slipped right on by. I'm pretty sure getting a "Below Expectations" review in the Empire is a one time event. Security event ID’s were three digits in Windows Server 2003. They’re four digits in Windows 2008 and later. “Testify”, I literally helped a customer years ago, and we notified the monitoring team that the event id’s changed, gave them a spreadsheet of the new event id’s and discussed what we were auditing. Three months later we get a frantic email. “We’re not collecting any audit data from the new servers. What’s the problem?” Well, the answer to that one was “You don’t have a technical issue we can solve, but thanks for contacting us”.
You have given me much think on, Master, where may I find additional wisdom
Excellent, grasshopper. You have snatched the pebble from my hand. Now, additional wisdom may be found in the Security Compliance Manager. This is the official guidance for audit and all security settings from Microsoft. You can also look at Planning and Deploying Advanced Security Audit Polices. And finally, you can download the spreadsheets with all the event ids in:
Security Audit Events for Windows 7 and Windows Server 2008 R2
Windows 8 and Windows Server 2012 Security Event Details
Richard ‘Rick’ Sasser. Sho’nuff.