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.