IT people are experts at making hardware and software work together to support the business. They're down in the weeds every day. So it's no surprise they tend to interpret a request to "document and test the system of internal controls" with that same level of detail, whether it's needed or not.
The Sarbanes-Oxley Act (SOX) stipulates that IT must test the "general computer controls" most important ("key") to assuring the completeness and accuracy of financial reports. This means testing controls that affect the systems instrumental in feeding or processing those reports. No more, no less.
IT might also be unclear about what the "key" controls are. That's because "key" isn't clearly defined in any official documentation, and management hasn't done a good job of explaining what they consider to be key. That leads to over-testing, just to be on the safe side.
The process should start at that higher level. Your company's top managers have to identify what your control objectives are -- i.e., what's inarguably required to assure complete and accurate financial statements. For example, that might be business applications and supporting system software that effectively supports financial reporting requirements (which you may need to develop or acquire), and/ or a stable infrastructure to support it. To define objectives, frameworks such as COBIT for SOX and COSO can help.
Once you've defined your objectives, your next step is to document the control activities absolutely necessary to achieve those goals. Generally, you should strive for at least two activities per objective: a preventative control, to find undesirable situations before they affect anything; and a detective control, to find undesirable situations after they've happened but before the impact is significant.
Let's look at the example where the objective is to create or acquire software that supports financial reporting requirements. Here, the activity would be using your organization's documented system development life cycle (SDLC) methodology to consider the security, integrity and availability requirements of the software you're going to buy or build. This precludes consideration of any packages that won't meet compliance requirements. Your SDLC also engages management, who ensure that users are involved in the design and testing of applications. This enables you to fix any problems before rolling them out.
Enabling Verification
As you document each control activity, make sure you provide enough background information and references so that a person who doesn't work for your organization can test the controls with minimal instruction. Also ask your team to describe how one could verify with documentation (sign-off forms) or electronic evidence (system logs) that each control is operating as intended.
So where does your internal audit department come in? Use us for education in defining "control objectives," "control activities" and what constitutes an adequate test of a control. Use us to review your definitions and documentation.
Following this process and involving the business, IT and audit sides of the house will ensure that you have the right controls in your documentation and testing package to comply with SOX. It will keep you from extraneous testing.
Matt Zerega is a West Coast IT auditor who has worked in energy, electronics and other fields. To comment on this story, email editor@ciodecisions.com.
This was first published in May 2005