There is a mountain of literature available on Sarbanes-Oxley compliance. We've extracted some of the basics to help you create the test plans needed to certify that your company has appropriate IT controls in place for compliance.
By Angela Weisser
If you work for a public company, chances are there's a Sarbanes Oxley (S-Ox) project underway. As a manager over a key IT area, you've been recruited to help! If your company is like many others, however, there is a shortage of IT auditing expertise in house. So what are you going to do?
Your auditors will eagerly e-mail you links to mountains of literature in order to assist you. But that literature is most likely written in Auditese, a language spoken by auditors and likely incomprehensible. That's where this article comes to your rescue. We've extracted the information you need from the mountain of literature available that will help you create test plans for your company to certify that you have appropriate IT controls in place.
From beginning to end
To begin, let's consider exactly how S-Ox relates to IT. Perhaps the best analogy developed to date is the following. If the act of financial reporting is like a relay race, with each racer representing a significant business process, then IT supports each business process like the bones support a racer's body structure.
In relay racing, team members must finish their segments of the race completely and accurately in order to make a valid handoff to the next racer. Additionally, each racer is restricted to a specific lane.
Even though a racer could still cross the finish line with a broken leg or injuries to the fingers and hands, achieving optimal performance in the race would be next to impossible because such injuries would have a negative effect on the speed and accuracy of a quick handoff. Running the race to the best of the racer’s ability requires healing the injuries. Various short-term remedies, such as first-aid or a leg splint might help. However, only long-term repair will thoroughly heal the leg and allow the racer to run most efficiently.
So the question for IT managers becomes, how healthy are the controls that are built into your infrastructure?
Where IT fits into the process
While some of the terms used in this article may seem alien, keep in mind that this is how the auditing world talks in real life. Under S-Ox, the audit process extends into areas that have a pervasive effect on the ability of the company to perform accounting and financial reporting. Since most business processes are supported by IT directly or indirectly, your project team will make the decision whether or not to create documentation integrated with the business processes or separate documentation for IT. Either way, IT processes that support the applications will also need to be documented.
Put another way, your job will be to document IT processes for computer operations, application development and maintenance, change control, as well as access to programs and data.
Controls, controls, controls
Once the team finishes documenting the company’s processes, it’s time to start the identifying control activities and assessing control design, control effectiveness, and anti-fraud controls. To help wrap your brain around the meaning of those controls, here's a brief overview of assessment and testing.
The assessment and testing process is a two-step course of action. Test plans can only be created after control activities have been identified. At the outset, a company needs to identify its objectives, risks, and control activities for each process.
After the company's objectives are identified, IT can create test plans to assess the effectiveness of these control activities.
Identifying control activities
At the heart of S-Ox compliance is putting in place well designed controls. But how do you know if you have them? A well-designed control activity should satisfy the objective and address the risk that the objective won't be met. For example, if an objective is to allow only authorized users to gain access to corporate data, your control activity must address what would happen if an unauthorized user somehow "gets through" your network defenses. Will the breach be detected in a timely fashion? Is there an audit log generated to assist in investigation of the breach?
So, when you sit down to write your test plans, you should think about what control activities or measures you have in place to manage your risks and prevent or detect errors, intrusions, and other breaches of your controls.
Testing control effectiveness
In general, testing controls boils down to three steps: First, inventory the control activities. Second, write test plans to evaluate the effectiveness of each control activity. Third, relate each activity to an "underlying assertion" in the financial statements.
Once you have an inventory of control activities, you can begin writing your tests of effectiveness. These tests determine whether the control is operating as intended and whether the person performing the control is properly qualified and authorized to do so.
The next step is to classify each control activity by relating it to the underlying financial statement assertions: Existence or Occurrence; Completeness; Valuation or Allocation; Rights and Obligations; & Presentation and Disclosure. Then you'll want to indicate whether your control is manual or automated, and indicate if the control is preventative or detective.
If you're starting to get bogged down by the audit jargon, you can read up on how to apply these terms by going to www.auditnet.org/sbc.htm and downloading the two-volume publication called Standards for Business Controls.
Next, you have to write the test steps, which are also known as audit procedures. Audit procedures consist of a combination of inquiry, observation, and detailed testing through either examination or re-performance. For ideas on how to test your controls, try reviewing existing audit programs. One source of free audit programs is at www.auditnet.org.
To ensure coverage on the test of effectiveness, the PriceWaterHouseCoopers approach uses four information processing objectives: Completeness, Accuracy, Validity and Restricted Access (CAVR). The CAVR approach gives you a standardized means to measure each control activity. You should select the information processing objective(s) which best relates to your control activity. Ideally, each element of CAVR should be addressed in some combination of control activities for each objective.
If you'll just have faith and follow along with what your project manager asks, your piece of the "control effectiveness" mosaic will eventually fit into place.
Getting help with control activities
A control activity is a term coined by the Committee of Sponsoring Organizations of the Treadway Commission (commonly known as COSO). The original examples of control activities are within the two volume set, Internal Control Integrated Framework. Internal Control Integrated Framework is available for purchase through the American Institute of Certified Public Accountants (www.aicpa.org), but the original publication is very light on IT-related material.
A number of more comprehensive resources for IT professionals are free to download. One favorite of professional auditors includes a two-volume publication called Standards for Business Controls. You can download that document at http://www.auditnet.org/sbc.htm and find examples of objectives, risk and control activities. Volume II is strictly for IT processes and is mainframe-oriented due to its age. However, you can update the control objectives by referring to another white paper called IT Objectives for Sarbanes Oxley at www.ISACA.org.
Last but not least, you can borrow sample objectives from SysTrust. However, because these resources are not specific to a particular technology, you will need to heavily customize their sample test plans to fit your organization.