Developing Controls
Work with management, notably finance and internal audit, to develop the necessary controls required to protect the key accounts. These controls must be a balanced mixture of preventive (policies, procedures, etc.) and detective (change detection, log review, etc.) and based on standards wherever possible.
When asking auditors for assistance, bear in mind proper segregation of duties mandates they cannot design the processes they will eventually audit. You risk a over familiarity, the appearance of the possibility of fraud, as well as fraud itself. The point is auditors are a resource, but they are bound by their profession to be very careful in terms of what they do when it comes to process design.
In terms of an overall framework, use COBIT (Control Objectives for Information and related Technology) to identify what to do. The external auditor community is heavily versed in this framework and by using COBIT, or at least mapping your efforts to COBIT, you will be far better positioned to communicate with the auditors.
By adhering to COBIT audits will go far more smoothly, faster and, of course, cost less. The last thing you want, as my good friend Gene Kim, the CTO of Tripwire, puts it, is for the auditors to have to go into “archaeology mode” to determine how things are done.
Ideally, you’d implement all of COBIT, but because time is of the essence, sit down with management and identify what parts of COBIT are essential to protecting the organization. The selected detailed control objectives must be relevant to protecting the identified key accounts.
In terms of how to fulfill the various detailed COBIT control objectives, refer to the IT Infrastructure Library (ITIL), the IT Process Institute’s (ITPI) Visible Ops, and ISO 17799 for best practice guidance. Again, be sure to document the thought processes used to identify key controls. In other words, document how you arrived at the key controls to put in place.
Document, Communicate, Train
Document, communicate and train people on the identified controls. One of the benefits of all this work should be useful formal documentation. Far too often, IT lacks proper documentation for what it does. As a result, people do things different ways and causes mistakes, difficulty in sharing best practices and longer learning curves for new employees, employees changing roles, etc.
Beware of shelfware. The outcome of this effort must not be simply a set of books on everyone’s shelves. The controls must be followed and for this to happen, people must understand them and see the value. Whenever possible be very certain to highlight how controls benefit the organization and the various parties involved. Internalization of controls is far easier when people understand benefits versus a blunt message like “Follow these controls for now on” (or else).
Once in place, test the controls for operational effectiveness plus plan on regularly auditing of processes to ensure the controls are being followed, are still effective and so on. Document findings as well as corrective actions taken.
Review the controls annually. The only constant in life is change. Processes must evolve in order to be effective and continue to support the business. Do not plan on putting controls in place and never looking at them again. In fact, it is mandated controls over key accounts be reviewed at least annually. As always, be sure to document findings and corrective actions taken.
No Time Like the Present
The bottom line is IT must work with the business to determine what financial accounts, processes, reports and, thus, systems are important for financial reporting and how to protect them.
Careful consideration must be given to the timeframe left before your firm must be in SOX compliant. For example, many organizations would benefit from doing all of COBIT, yet there may not be sufficient time to do everything. Thus, it’s important to focus on the controls most beneficial to the organization first and others afterwards.
Never forget, if it isn’t in writing, meaning formally documented, then, by SOX standards, it doesn’t exist. SOX 404 compliance is far from easy, but it is not impossible. Maybe the best way to start is to look at this challenge as an opportunity to improve.
George Spafford is a frequent author and consultant on IT process improvement, security and business impacts. Additional information is on his firm’s Web site.
Want to discuss looming Section 404? Take it over to our IT Management Forum.