Database security access and auditing

Here's a list of steps I would take:

1. Identify all members of sysadmin and securityadmin roles.
2. Determine which of those belong to real people and which are service accounts.
3. Take the list of real people to management and have them decide who really needs access.
4. Write your own server-side trace (don't use C2) to monitor for logins and try to determine if and when any of the service accounts are used.
5. For service accounts that have no activity over an extended period of time (one week, one month), take the list to management with a recommendation to disable but not delete. This way, if the account is actually used, but only rarely, it's a simple matter to reactivate.
6. After a specified period of time agreed upon with management, remove the service accounts that were inactive.
7. After the list of valid service accounts are identified, determine what applications they are tied to. Work with the teams responsible for managing those applications to determine what the actual permissions needed are. If some of these are 3rd party applications, prepare to deal with the fact that some companies will not support their application unless you give out the permissions they demand, even if they don't need it.
8. Build queries to run daily and weekly to monitor changes to the environment, especially with regards to login creation/deletion and role membership changes.
9. Now attack the operating system the same way you did SQL Server: determine who are members of the local Administrators and Power Users groups and take a similar methodology.

What do you mean by "The sysadmins and the securityadmin list are unbelievable"?

I would recommend that if your question is so broad that you would be best off getting a test server set up and then purchasing a couple of books Denny Cherry (@MrDenny) has a book for 2008 that I would recommend - http://www.amazon.co.uk/Securing-SQL-Server-Protecting-Attackers/dp/1597496251/ref=sr_1_1?ie=UTF8&qid=1303034839&sr=8-1 and there are similar for the previous versions.

I take that to mean there are accounts showing up under sysadmins and securityadmin fixed server roles that you are asking yourself: Why do they have that access?

I've been there and still deal with that one.

The top two choices you have for auditing that are quick and easy to implement are default trace (which should be on by default) and C2 Auditing. The default trace captures mostly changes to configuration options. Then C2 auditing will capture everything done on the instance of SQL Server. Caution, when you enable C2 auditing if your instance is very active you will need to manage the storage space where the trace files are created, because it can get out of hand very quickly.

The first step I would take though is run these two commands:

EXEC sp_helpsrvrolemember 'sysadmin'
EXEC sp_helpsrvrolemember 'securityadmin'

Take those list of accounts to your upper management, or whoever your supervisor might be, and ask them who in this list ACTUALLY needs this permission. That is a legitmate concern and should be addressed by management.