Executing an IT Audit for Sarbanes-Oxley Compliance

By Michelle Johnston Sollicito

Date: Sep 17, 2004

Return to the article

Concluding her two-part series on handling Sarbanes-Oxley compliance, Michelle Johnston explains how to audit your organization.

My previous article in this series described how to prepare your organization for auditing. Now we'll delve into the audit itself—what's involved, and how to survive it.

What To Audit

The Sarbanes-Oxley Act of 2002 (hereafter simply Sarbanes-Oxley) is designed to ensure the following within a business:

In many companies, most of these controls are IT-based.

Not only must controls be in place; they must be effective, and it must be possible to note exceptions caught by the controls and follow audit trails in order to take appropriate action in response to those exceptions. This requirement puts a new pressure on IT that until now few IT departments have faced.

Ultimately, Sarbanes-Oxley makes executives responsible for ensuring that these controls are in place and effective, and this fact is making Sarbanes-Oxley a high priority on most companies' agendas: Executives are aware that they could go to jail if these processes are not in place and/or are ineffective. Suddenly, executives are very interested in what's going on in the murky depths of the IT department!

For detailed guidance on IT auditing, many have chosen to use the ISACA subset of COBIT to ensure that the key IT aspects related to Sarbanes-Oxley are being tested and ISO 17799 for guidance on which security aspects to audit.

Key Controls Versus General Controls

Early on in the IT audit for Sarbanes-Oxley compliance, it's important to establish two main groupings of IT controls that should be checked: key controls and general controls.

Key Controls

For the purposes of Sarbanes-Oxley audits, key controls are controls that are key to ensuring that the values on the balance sheet are accurate and reliable. Every expense/transaction must be initialized, authorized, controlled, implemented, reported/documented, and validated/cross-checked using key controls. Some of these key controls will be IT based, and should be covered in the IT audit. An example might be a trigger on a database table that ensures that adding any entry into the accounts receivable table automatically creates an entry into the general ledger. It would be important to ensure that this trigger is in place, is correctly coded, and can be changed only by authorized personnel.

Another key control might be the use of database transaction-handling to ensure that either all sub-transactions involved in one big logical transaction are posted or that the whole logical transaction is rolled back, to ensure that the data is never in an inconsistent state. It would be important to check key transactions to ensure that the transaction code is written correctly and that guidelines/standards make it clear how transactions should be structured within the organization to ensure that this is the case.

In some companies, email is so crucial to a process that it's considered to be a key control; in such cases, this email should be subject to message queuing technology, to ensure that if the email fails to be sent, it's re-sent later.

Some other examples of key controls are reports that are used to check the totals of transactions or check that two separate systems tally with one another. Code reviews, design walkthroughs, unit testing, and user-acceptance testing are examples of ways in which reports should be validated as being reliable.

It's the IT auditor's job to ensure that key controls are effective, reliable, and reproducible.

General Controls

General controls are controls that go across all IT systems and are essential to ensuring the integrity, reliability, and quality of the systems. All of the following are examples of general controls:

When assessing general controls, it's important to look at the effects of those controls across all IT systems that are within the scope of the Sarbanes-Oxley audit. General controls usually incorporate at least the following types of controls:

Generally speaking, if it's an IT "best practice," it's usually good from a Sarbanes-Oxley perspective. There are a few exceptions to this rule, though; for example, some open source strategies, while seen as a best practice in the IT world, are arguably not in line with Sarbanes-Oxley requirements, as they contradict the key ideas within Sarbanes-Oxley that access to information should be purely on a "need to know" basis, and that processes should be controlled. It's usually a good thing for Sarbanes-Oxley purposes if a policy, procedure, or process is

Thus, it often makes sense for it to be automated (as this theoretically also makes it more difficult for individuals to manipulate the control either maliciously or by mistake). For example:

Even in smaller IT companies, to conform to Sarbanes-Oxley, it's a good idea to ensure the following:

For each general control, it's important that the internal auditor can show how the relevant policies/procedures/processes are

Assessing General Controls

General controls can be assessed through design walkthroughs, code reviews, interviews to ensure that procedures are followed, sample testing to ensure that documents and records are kept concerning processes and procedures, and so forth. In the next section, I offer some guidelines for assessing some of the general controls.

Auditing the Administration of Duties/Rights

A key aspect of a Sarbanes-Oxley audit is checking that rights and duties are separately assigned to different individuals so that no individual has the power to divert business or transactions in a fraudulent manner.

Clearly, IT often plays a large role in this area. It is the Sarbanes-Oxley IT auditor's job to check that individual IT permissions and roles are organized in such a way as to not make the company vulnerable to fraud. For example, no single individual should be able to access all IT systems involved in financial transactions, because knowledge of the full path through those systems could make it easier for that person to commit fraud.

Within a database, one individual may be given the ability to carry out DDL commands (create tables/views/triggers/stored procedures, modify them, and delete/drop them), while another individual should be given the ability to assign permissions enabling individual users to execute queries, triggers, and stored procedures. The principle of separation of duties and rights is often implemented using the concept of "roles" within an IT system.

The principle of least privilege should be applied when assigning permissions within the operating system, the applications, and the databases. Any individual should be given only the permissions he/she needs in order to carry out his/her job. This principle should be enforced at the operating system level, the network (component) level, the database level, and the application level.

Some aspects of authentication/access control can be fairly easily enforced through the use of a central LDAP or Active Directory repository (or similar identity/directory management system), whereby the role and/or the group to which a userID belongs determines the privileges granted to that user.

An identity/directory management system can also make it easier to make administrative changes when, for example, an employee leaves the company or transfers to another department. Removing or transferring the employee from all groups to which he/she belonged removes privileges automatically, and any future attempts to access unauthorized systems will be logged and flagged in the review process.

User provisioning techniques should ensure that new users are set up with the correct privileges, by creating a standard profile for each type of user; this profile should determine the default permissions assigned to a new user of that type. Such techniques should also enforce rules that prevent users from being assigned the wrong privileges.

The auditor should ensure that the principles of separation of duties, least privilege, and user provisioning are applied to all users of any systems owned/used by the organization that are considered to be in the scope of the audit. The auditor should also be aware that there may be other external requirements to which the company must adhere—for example, the requirements of Visa CISP—that may be even more rigorous than those involved in Sarbanes-Oxley, especially in some of the network security areas.

Where the principles of separation of duties, least privilege, and user provisioning are not clearly in place, the IT system has, strictly speaking, failed to meet Sarbanes-Oxley compliance, and the exception should be noted and flagged up to management so that they can work on remediation.

Assuming that your external auditors are reasonable, the fact that this exception has been noted and flagged will be sufficient, unless it creates a significant risk—so long as you can provide evidence that a plan is in place to remediate the failure in the near future.

However, because Sarbanes Oxley is so new, there are no clear "pass" or "fail" criteria, and all auditors have different levels of comfort with exceptions, and it's best to discuss your individual situation with your own (independent) advisors and/or auditors.

Change Management

The purpose of testing for change management controls is threefold:

The auditor should check that a formal change management process is in place. The process should be documented, approved, effective, and in use by all those making system changes to systems within the scope of the audit.

To be effective, a change management process should usually include a procedure for emergency changes and a procedure for planned changes. It's inevitable that some changes will need to be made very quickly, and it will not be possible to follow the normal change management process for these kinds of changes.

The process should also deal effectively with the different types of changes that may be requested—bugs (usually requiring only a quick fix and a little testing) may need to be dealt with very differently from enhancement requests, which may require whole new development projects or sub-projects to be set up.

The change management procedures should ensure that a full documentation trail tracks changes made, so that it's possible to reenact or roll back changes if necessary, and it's possible to easily find out which program files were affected by any particular change request.

A QA process should exist in order to test changes in the test environment before such changes are placed into the live/production environment.

Ideally, testing should incorporate use of a tool for testing that can produce scripts so that such testing is quickly and easily repeatable.

Security

Because security is such a huge concern within Sarbanes-Oxley generally, IT security should form a large part of the audit process.

TIP

I've written extensively about IT security audits. If you want help on what to consider when reviewing security, see my earlier InformIT series "How To Perform a Security Audit" (part 1, part 2).

Many SOX security auditors are using ISO 17799 for guidance on which aspects of security to check. This is a very good practice, as it removes some of the ambiguity involved; however, it's also a high target to aim for, and for some organizations it may not be practical. The ISO 17799 News portal is a great source of information about ISO 17799. If you decide that you want to do a thorough job of auditing against the ISO 17799 standard, consider buying a tool that can help, such as the ISO 17799 Toolkit.

For those who are not prepared to use an extensive ISO 17799 approach, it's important to be able to illustrate that, at a minimum, policies are in place and are being followed effectively in the following areas:

For advice on the various aspects you should investigate as part of the security audit, many resources are available on the web to help you. For example, WebEx offers a number of VeriSign-sponsored seminars on security.

Policy Creation

As a result of your research, you may realize that you need to implement new security policies. SANS offers a training guide (PDF) to developing security policies for your organization, and many sample policies are available on the web to use as a starting point for your own policy development:

Documenting Your Audit

For automatically documenting Sarbanes-Oxley information, you might consider an automated package such as the Microsoft add-on for Sarbanes-Oxley, or the IBM software for the same purpose. A number of security tools can provide "scoring" of systems against independent criteria—see the Center for Internet Security and others that provide documentation that can support an audit, such as NMAP (a tool that maps out the network and can be used to determine which hosts, OSes, packet filters, firewalls, and so on are in use).

Useful Security Links