Skip to Content
February 26, 2007 Article 5 min read

Although independent auditors have always been required to consider the existence of internal controls and the impact they have on the financial statements, never has so much attention been directed to this subject until Congress enacted the Sarbanes-Oxley Act of 2002 (SOX). As companies began to work through the process of complying with SOX over the past couple of years, there’s been much criticism relative to the cost and effort inherent in the process. However, the hidden benefits of documenting and testing internal controls are finally beginning to emerge, as companies move into their second or third year of compliance. In one survey, 2 out of 3 chief executives credited SOX and other compliance initiatives with helping them to uncover potentially damaging control weaknesses, and almost two-thirds of those surveyed said that SOX compliance has increased their understanding of their businesses.

It’s these hidden benefits that are driving some non-public companies to start SOX-like projects to develop and document internal controls. Private companies seeking to improve internal controls are looking for a structured approach to guide their efforts. Indeed, many of the problems encountered by the first companies struggling to comply with SOX were a direct result of the ambiguity of the law itself and the fact that there was no plan that had been previously implemented to follow.

This article describes seven steps an organization should follow to develop and document an efficient and value-added internal control program for financial reporting processes. This process works well for both financial and information technology controls. 

Step 1: Plan

A major component of planning is the risk assessment. A risk assessment is needed to identify the specific processes and activities that might contain vulnerabilities that could affect financial statements. Financial risk is assessed at the entity level (by division or location) and at the process or activity level. Once the financial risks are known, an information technology risk assessment is conducted, which maps financial risks to systems, people, and technology. The ultimate goal in conducting a risk assessment is to identify which entities or processes contain key controls that need to be documented and tested. Without a “top-down,” focused risk analysis, a “bottom-up” compliance effort may result in covering nonessential processes and may miss critical key processes altogether. 

Step 2: Establish a control framework

Once the risk assessment process is completed, an appropriate risk control framework can be established. A control framework identifies functional areas, key processes, control objectives, and related control statements.

The control framework establishes the boundaries for documenting and testing the internal control environment, so control objectives should be established for all key process areas identified in the risk assessment. A company that’s required to comply with SOX may want to consult with an experienced CPA on the development of the framework. Ultimately, the design of the framework must be acceptable to the external auditors, and it’s inappropriate for the external auditors to provide management with any specific feedback on the design of an internal control system they will later audit. 

Step 3: Document control activity

Now that control objectives have been identified, the activities or processes that are preformed to ensure the control objectives are met should be documented. The amount of detail may vary in activity descriptions. Some companies have extensive process and task-level documentation for every process, while others have summaries of the activity or processes followed in as little as a few carefully crafted paragraphs. Either way can be acceptable; the key is whether the specific control assertions can be identified in the activity descriptions.

Step 4: Identify specific controls

Identifying the specific controls is very important, because these contain attributes, or action steps, that must be tested to determine the effectiveness of the control processes. Information technology controls provide a foundation layer for enterprise security underlying application and process controls. Controls can be manual or automated, and they can be preventative or detective. Preventative controls proactively attempt to prevent unauthorized or undesirable acts from happening. Detective controls, on the other hand, are designed to detect acts that aren’t authorized or undesirable after they’ve occurred. Both types of controls are essential components of an effective internal control system. 

Step 5: Evaluate control design

Evaluating the design of a control prior to developing tests of compliance is an often overlooked part of the process. When testing compliance with controls, a failure could result if the control is not operating effectively or if there’s a flaw in the design or documentation of the control activity. Control activity descriptions should clearly identify the specific controls and:

  • Who performs the control activity
  • How the control is being performed
  • What reports or other information is used to perform the control
  • How frequently the control operates
  • Whether the documented control activity meets all of the control objective assertions
A control activity description that passes all the above quality review steps would be evaluated as a control that’s “effectively designed.”

Step 6: Test control effectiveness

Once controls have been properly described, controls should be tested to determine if they’re operating as designed and as intended by management. In order to perform unbiased testing, and to ensure that results are representative of the total population, statistical sampling techniques should be used to estimate required sample sizes, and samples should be randomly selected.

After testing has been completed, if no exceptions are found in the unbiased samples, then the control is classified as operating effectively. All testing exceptions should be recorded in a remediation log. 

Step 7: Remediate and retest

All testing exceptions should be documented in a remediation log and assigned to a person responsible for correcting the errors and, at the appropriate time, recommending that controls be retested. Typically some time needs to pass so that a new sample can be selected from transactions that have occurred subsequent to remediation efforts. This cycle of retesting and remediation should continue until the controls are determined to be operating effectively. 

In conclusion

By following the steps above, companies of all sizes can implement and document a program aimed at improving the internal controls over key processes and information technology systems in their organizations.