These days, every company should take a second look at its own IT compliance self-assessment process to ensure that it's using a risk-based approach and focusing its tests on key control areas. Knowledge Center contributor Craig Linnell explains how your company can better assess whether or not its Internal Controls over Financial Reporting are truly risk-based, particularly in the IT area.
The U.S. Securities and Exchange Commission provided interpretive guidance on the implementation of a risk-based approach for management's self-assessment of Internal Controls over Financial Reporting. It did this in its publication, "Commission Guidance Regarding Management's Report on Internal Control over Financial Reporting under Section 13(a) or 15(d) of the Securities Exchange Act of 1934." This guidance often results in a significant reduction of hours for an organization to complete its tests of ICFR.
Therefore, now may be a good time for an organization to assess whether its ICFR self-assessment is truly risk-based, particularly in the IT area. CIOs, and others tasked with overseeing the IT ICFR self-assessment, should consider the following:
1. Review and assess those IT general controls that have a more direct link to the financial applications supporting the financial reporting process.
It can be difficult to establish a direct link between ITGCs (Information Technology General Controls) and ICFR. However, a strong IT general control environment is an important element of a secure and stable IT processing environment, upon which automated controls and application systems are dependent.
System development and program change controls
In most companies classified as "accelerated filers" (i.e., publicly held companies with a market capitalization of $75 million or more), the IT processing environments are often considered complex. As such, controls over program changes are almost always important and need to be tested. Regardless of whether you use vendor-supplied financial applications or ones developed in-house, controls over the program change process are very important in order to maintain the integrity of the application processing system and related data.
Logical security controls
Logical security controls are essential to maintain the integrity of the programs and related data or databases. They can encompass a variety of areas, including controls over access to production servers, networks, databases, etc. As such, logical security controls are considered of vital importance and need to be tested.
Computer operation controls
Computer job execution, completion and monitoring controls are essential to maintain the integrity of system data and generally should be tested. While data backup can be very important in the recovery of lost or corrupted data, the risk of the process having a material impact on the financial reporting process is normally considered low. Similarly, physical security and environmental controls are often considered to present less risk and therefore only require minimal testing.
IT entity-level controls
Controls over the administration, governance and organization of the IT department are generally limited to the following: segregation of duties within the IT organization, the use of defined roles and responsibilities for personnel, training, strategic planning, the use of a steering committee to control and monitor resources and projects, and the reporting of significant events and security incidents to management or the board.
Controls over the reporting of significant IT events and security incidents to management or the board are considered important and should be tested. All other controls are less important in detecting or preventing a material misstatement in the financial statements, and can be tested as part of the organization's overall entity level controls.
2. Coordinate your approach and related tests with your external auditors to ensure that they are in agreement.
CIOs should be cognizant that internal auditors and external consultants conducting ICFR tests may not always be motivated to use a risk-based approach. CIOs should ensure that internal auditors and external consultants are indeed using a risk-based approach. If they are not doing so, an appropriate first step would be to refer them to the SEC guidance.
An organization's approach to ICFR tests could have a significant impact on your external auditors, particularly if they plan to rely on your work to reduce their tests of controls. The CIO should ensure that the ICFR team is actively coordinating the company's approach with your external auditors.
3. Automated application controls and application-dependent controls are usually considered very important and need to be tested.
Automated application controls, such as edit and validation checks, are essential to ensure that complete and accurate data is being entered into the financial system. IT-dependent controls (such as those application controls over user access to the system and related functions) are essential to maintaining an effective segregation of duties. Both of these control areas should be tested as part of your ICFR IT self-assessment.
IT general controls relevant to the evaluation of ICFR will vary depending upon a company's facts and circumstances. For purposes of management's Section 404 self-assessment, management need only evaluate and test those IT general controls that are necessary for the proper and consistent operation of other controls that are designed to adequately address financial reporting risks. It is not necessary to test IT general controls that only pertain to efficiency and/or effectiveness of a company's operations. In some instances, companies often test other controls not related to financial reporting risks because it may make good business sense for them to do so.
Craig Linnell is a Partner in the Information Systems Assurance Practice of BDO Seidman, LLP, a national accounting firm providing assurance, tax, financial advisory and consulting services to a wide range of publicly-traded and privately-held companies. Based in the Costa Mesa office, Craig can be reached at firstname.lastname@example.org.