In the dozens of IT assessments and audits I've been involved with over the years, some common mistakes stand out. Industry and company size don't matter -- somehow, when it comes to efforts to comply with regulations or respond to auditors, IT folks tend to act the same way.
Thus, in an effort to save you time and money -- not to mention a headache or two -- here is a collection of the biggest mistakes I've seen most often and how to avoid them.
- Taking your external auditor's documentation too literally. External auditors employ a lot of recent college graduates who understand IT controls only in a general sense. Sometimes their generic reference calls for a specific piece of equipment, such as an SAProuter. That doesn't mean you need to respond by implementing this exact router; it does mean you need to consider some additional level of control over the data moving among your SAP systems, and between your SAP system and external networks. As long as you achieve the same level of control that the SAP router provides, you are covered. All you have to do is explain to the auditor how you achieve an equivalent level of control.
- Asking your internal IT audit shop whether you're in compliance with Sarbanes-Oxley. This whole SOX thing is about management's assessment of the effectiveness of internal controls over financial reporting. "Management" does not include your internal audit department! Your internal audit department can help you understand how to document your controls and what constitutes an adequate test; however, it cannot conclude whether your controls meet management's objectives. Your internal auditor must remain independent. Ask management instead.
- Fixing something because your auditor -- internal or external -- calls it into question. Don't fix anything just because an auditor identifies an absent or potentially weak control. Management must first determine if that weakness creates a risk that exceeds acceptable levels. If it does, then both business and IT management should work together to determine if the cost to fix it reduces the risk by a commensurate level. If not, no changes will be in order. But the audit process has nonetheless done its job: It's identified a weakness and held management accountable for the decision on fixing it.
- Hiding a known weakness in your controls because you think it's probably outside the scope of what your auditor is examining. Auditors expect IT management to be open and forthcoming during an audit. Any indication that you're not can turn into your worst nightmare. If your auditor thinks you're not being straightforward, he or she will feel compelled to undertake a copious, detailed examination of all of your controls, assuming that you're hiding something. This means a lot of extra work for you. So, put your cards on the table from the beginning, and the process will go much more smoothly.
- Not keeping records of approvals and reviews. Auditors assume that if it isn't documented, it didn't happen. An auditor needs hard evidence to properly verify that you are using the appropriate controls in your environment. For example, if you implement code changes only after business management has signed off on change requests, you must maintain a record of those sign-offs, or you can't demonstrate that you are getting them. You must also record which individuals did the signing, so the auditor can verify their managerial positions.
In summary: Don't assume. Don't hide. Document. That's the auditor's world.
Matt Zerega is a West Coast IT auditor who has worked in energy, electronics and other fields. To comment on this story, email firstname.lastname@example.org.