Downtime Becomes Documentation Time

Computerworld - The past week wasn't extremely insane for a change, so I focused on completing some much-needed documentation and organization of some of our recent activities. The first area I tackled was the ongoing and tiresome Sarbanes-Oxley project.
At this point in this seemingly never-ending initiative, all of the IT security controls have been identified, tested, remediated and, most importantly, automated and made repeatable. Those last two items are key, since having automated and repeatable processes will save us time when we have to demonstrate compliance with Sarbanes-Oxley Act mandates again. In addition, having automated and repeatable processes will help with any other audits or attestations that we may be responsible for, since other regulations will most likely encompass the same activities covered by Sarbanes-Oxley.
Now it's just a matter of putting together some documentation about the processes so that in years to come we can quickly produce the information needed to ensure continued compliance. I'll explain with a couple of examples.
Following the Rules
During the IT security portion of our Sarbanes-Oxley project, dozens of control objectives were identified, and we came up with repeatable methods to test against those controls. One control that we identified involves ensuring that users are restricted from logging into an "in-scope" Unix system directly as root. The proper method for gaining root-level access is to log in with an assigned user account and SecurID token and then issue the "switch user" (SU) command to gain root-level access.
But there are always people who seem to be either too lazy or too inconvenienced to follow these rules. Yes, our Unix systems are configured to deny direct root log-ins, but console servers are attached to each system for emergency access in the event that an interface goes down and an administrator needs to troubleshoot. The need to provide such emergency access is real, especially in remote data centers, but the console access provides a user with root- or administrator-level privileges.
Whenever an administrator accesses the system, though, logs are generated that identify the method of access and the use of SU to gain root-level access. Part of the Sarbanes-Oxley control objective states that these logs are to be regularly reviewed in order to monitor methods of access.
The documentation I created discusses the responsibility, frequency, location and methodology of reviewing those logs. Eventually, we will put some technical controls in place so that we won't have to review logs manually, but for now, this activity satisfies that particular control objective.
Another example: We have written scripts