Having been through this about a billion times, I would say the suggestions the folks above have given is are very good. SQL Security is tough to get right given some of the inherent security issues with SQL server. Some suggestions on effective SQL security implementation.
1. Limiting all users with the ability to update data to only those with a valid business need. That said, I find it hard for most to justify the use of Builting\Admins when it almost by default has domain admins, backup admins, service IDs which aren't properly locked down etc. If you don't need, you should consider removing it. SQL server does not need it to run.
2. Learn the stored procedures in SQL which allow you to audit system config and security. For example, sp_configure, sp_helplogins, sp_helpusers, sp_helproles, sp_rolesecurity...etc. There are about 10 that help you understand SQL security and how it is rolled out.
3. In line with item #1, make sure you understand object security and who has access to run those stored procedures. For example, those who can update SQL configuration table through sp_configure could take the database down or enable bogus config, that would be bad. Likewise, access to xp_ stored procedures like xp_cmdshell could give a user who has access to just connect to the database (think public role) ability to issue OS commands and get access to data via that mechanism.
4. If you do implement logging (which you may or may not be asked to by your external auditors; I belive this request changes based upon the size / skill of the DBA group and limitations presented by applications), you need to consider logging both users updating or deleting data and also changes to configurations, and stored procedures. If you can turn off the log or update the audit log, it's not effective. If you can turn off auditing (also, available in sp_configure, turn off the backup log, or change a scheduled task), not really effective.
5. Make sure you check the public role and remove the guest account from databases where you can. By default, guest has access to nothing but it does allow you to view data if it is given a view role on a database instance. While SOX isn't concerned about view only (that is, of course, if the darn application doesn't give those who can view data (e.g. select) ability to query the password table for the app))
6. I know this is new in 2005, but if you can implement strong password security, I would consider it.
As the folks in this thread have echoed, having documentation that addresses how your relevant system security settings are set, who has access to roles that can update data, what tools are used to access data, what types of passwords must be used to access data, and how access to teh system is administered and reviewed periodically.
If you have any specific compliance questions, let me know.