JOnline: Potential Control Processes for Sarbanes-Oxley Compliance 

 
Download Article

The US Sarbanes-Oxley Act of 2002 was passed in response to corporate corruption that surfaced during the past five years. It is a regulation that targets executive leaders who are involved in fraudulent financial disclosures by their organization. This act makes executive management directly responsible for ethical, honest practice in reporting organizational performance.

The immediate challenge for corporate information technology (IT) departments is how to comply with the Sarbanes-Oxley titles that directly impact their accountability under the legislation. To meet the short-term challenge of meeting Sarbanes-Oxley legislation, a compliance road map must be established. This approach includes assessing guidance from external organizations that provide standards, understanding internal controls within the organization, evaluating the depth of compliance needs, and implementing selected compliance activities such as system certification and awareness training.

Introduction

Volumes of material have been written about the Sarbanes-Oxley Act. Compliance efforts for this control regulation have already begun for large organizations and will be required for all public firms with market capitalization of more than US $75 million by the end of 2005 unless the dates are extended again. Up to this point, the compliance process for Sarbanes-Oxley has been primarily viewed as a financial activity. More recently, there has been increased recognition that accuracy of financial reporting is impacted a great deal by the operational IT systems and their associated infrastructure. The IT community has not been adequately involved in the compliance process and, in many cases, does not have a good understanding of its role in the short- and long-term components for compliance. The goal of this article is to translate the essence of the Sarbanes-Oxley regulation into IT terms and identify selected control processes that the IT organization can pursue as part of the compliance activity.

Organizations now generally recognize that the time they have to obtain initial compliance is short (or already passed). If most organizations were rigorously reviewed today, they would likely fail to meet the initial compliance thresholds, since a true baseline for compliance is not known. This issue is destined to place the audit community in a dilemma as to how rigorous it has to be during the initial phase. Over the long term, a more complex goal is dealing with the regulation as it evolves and the organization seeks a cost-effective model for compliance. Because of the complexity and timing of this act, the short-term compliance result is a band-aid approach, while the long-term implications could necessitate changes in the business culture. Sarbanes-Oxley is complex and pervasive in scope. Given that it applies to the full spectrum of business models, the current expectation is that no simple checklist solution will properly deal with compliance.

Guidance and Implications

Understanding internal control and implementing adequate compliance for Sarbanes-Oxley are two overlapping subjects. Two prominent sources for Sarbanes-Oxley guidance are the Committee on Sponsoring Organizations (COSO) and Control Objectives for Information and related Technology (COBIT).1

COSO was originally created in 1985 as an alliance of five professional organizations. As a group, its goal was to establish a single voice in the financial business community on issues of fraudulent financial reporting. COSO’s original work is a report titled “Causal Factors that Can Lead to Fraudulent Financial Reporting,” and the report identifies ways to reduce fraud. At that point, the report was considered groundbreaking. It established an international credibility for what has become known as the Treadway Commission (named after the chairman of the group). In 1992, COSO followed with a report, “Internal Control—Integrated Framework (IC-IF),” designed to be a US auditing standard (AU 319).2 The original report established internal controls as a means of helping a company achieve numerous control objectives, and it was supported by the US Securities and Exchange Commission (SEC).3 The document has become the accepted definitional document for evaluating adequacy of internal controls for Sarbanes-Oxley compliance. IC-IF addresses control objectives relating to operational and compliance issues within the financial reporting domain. It sets a standard against which the effectiveness of a firm’s internal controls can be evaluated, and it explains the responsibilities that management, board members, auditors and legislators have for the proper functioning and assessment of these controls.

Although not a complete implementation road map, it provides needed philosophical structure upon which to build a compliance approach.

COBIT represents a detailed control framework for IT organizations. This framework was initially released by the Information Systems Audit and Control Foundation (ISACF) in 1996. In 1998, this standard was expanded with revised control objectives and an implementation tool set. In 2000, a third edition was sponsored by the IT Governance Institute.

The COBIT control definition contains a detailed IT-oriented framework consisting of four major domains, 34 IT processes and 318 control objectives. Full compliance with this specification is a difficult task for most IT organizations. However, it serves as a best-of-breed control environment definition with more detailed guidance than the other standards sources provide. The current focus of COSO and COBIT greatly expands their earlier focus on control frameworks and moves in the broader view of IT governance and risk management. When integrated, COBIT and COSO provide a potential target for Sarbanes-Oxley compliance control concepts. To authorize compliance activities, IT governance is needed to fund important tasks.

A COBIT and COSO Control Road Map

Figure 1 shows a cross-reference of concepts between the COSO and COBIT models.4 In the table’s cells, the asterisk highlights the mapping between COSO’s high-level control components and COBIT’s control objectives. More on the table’s content and an explanation of the CM, AT, FSP and SC notation is included in the following section.

Recall that the defining standard for Sarbanes-Oxley compliance is COSO, but the actual work will likely map more closely to COBIT. Therefore, this mapping is a worthwhile overview of a target control configuration. However, the chart does not identify adequate control processes, the level of adequacy for specific control processes associated with a control objective or consistent definition in the cross-referenced cells. For example, the COBIT Plan and Organize process of manage quality is cross-referenced with COSO control activities. From the two sources, there is no confirmation that these two activities are actually interconnected. Making these cross-referenced terms more consistent between the COSO and COBIT organizations would aid greatly in validating the integration of the two models.

Figure 1—C OBIT’s Relationship to COSO
COBIT Control Objectives
COSO Component
Control
Environment
Risk
Assessment
Control
Activities
Information and
Communication
Monitoring
Plan and Organize          
Define a strategic IT plan   *   * *
Define the information architecture     * - SC *  
Determine technology direction          
Define the IT organization and relationships * - CM     * - AT  
Manage the IT investment          
Communicate management aims and direction * - CM/AT     * - AT * - AT
Manage human resources *     *  
Ensure compliance with external requirements     * - SC * - AT * - AT
Assess risks   * - SC      
Manage projects          
Manage quality * - CM/AT   * - SC * - AT * - AT
Acquire and Implement          
Identify automated solutions          
Acquire and maintain application software     * - FSP/SC    
Acquire and maintain technology infrastructure     * - FSP/SC    
Develop and maintain procedures     * - FSP/SC * - AT  
Install and accredit systems     * - FSP/SC    
Manage changes     * - FSP/SC   * - SC
Deliver and Support          
Define and manage service levels * - CM/SC   * - SC   *
Mange third-party services * * * - SC   *
Manage performance and capacity *   * - SC    
Ensure continuous service * - CM/SC   * - SC   *
Ensure system integrity * - CM/SC   * - SC * *
Identify and allocate costs          
Educate and train users *     *  
Assist and advise customers          
Manage the configuration *   * - SC *  
Manage problems and incidents     * - SC * * - SC
Manage data     * - SC *  
Manage facilities     * - SC    
Manage operations     * - SC *  
Monitor and Evaluate          
Monitor the processes       * - AT * - AT/SC
Assess internal control adequacy         * - AT/SC
Obtain independent assurance * - SC       *
Provide for independent audit          

 

Measured Compliance Assessment Steps

An important step in a Sarbanes-Oxley compliance plan is to evaluate the current state of readiness. Figure 2 illustrates a targeted Sarbanes-Oxley risk assessment approach.

Constructing a global compliance plan is a critical Sarbanes-Oxley compliance step. Within a global plan, measured steps are needed to ensure systematic control processes. A global plan must address the feeder and core financial systems and surrounding enterprise and IT processes that are used to plan, execute and control financial system operation.

An example of best-of-breed control road maps is offered in figure 1. The important question is what control processes can be implemented to configure to this road map? A four-prong Sarbanes-Oxley compliance model is offered. First, Sarbanes-Oxley compliance managers (CMs), designated for each company’s geographical locations and important financial functions, serve as a focal point for policy and guidance for all compliance matters at each respective site, and their primary responsibility is to distribute policy and compliance guidance. Accordingly, the Sarbanes-Oxley compliance managers oversee compliance activity for each process within their respective IT domain. Second, the Sarbanes-Oxley awareness training (AT) component provides training for company staff. To meet Sarbanes-Oxley compliance requirements, a company must ensure the integrity and confidentiality of information and the authentication and nonrepudiation of its electronic financial transactions. Third, the company’s financial system portfolio (FSP) is the primary compliance target, because the systems codify the rules and procedures of the firm’s financial reports. System certification (SC) is a review process that ensures ongoing integrity of the financial systems. Collectively, these four components represent the surgical Sarbanes-Oxley control processes. In figure 1, the acronyms of the four components are placed in cells where these measured control processes address risk associated with Sarbanes-Oxley compliance.

  • Compliance managers—While senior management is ultimately held accountable for Sarbanes-Oxley compliance, a compliance manager or a coordinated team of compliance managers should be appointed as operational emissaries. When enforcing compliance requirements over operational financial systems, the compliance manager should ensure that his/her segment of the system population adheres to the following:
    • Input and process data comply with Sarbanes-Oxley security and integrity guidelines.
    • Access control lists for each system are maintained.
    • Awareness training for Sarbanes-Oxley compliance is conducted.
    • A person is appointed for each system, with the formal responsibility of monitoring system certification reviews and ensuring completion of those reviews.
      As an agent for the senior management team, a compliance manager is responsible for supporting short- and long-term policies and procedures for internal controls. This role promotes effective coordination of senior management decisions.
  • Awareness training (AT)—After the compliance strategy is determined, a compliance program is formulated to specify the what, why, when and how for program execution. This program must be deployed throughout the company, and staff must be aware of its content, including policies and procedures. Awareness training is a critical vehicle for launching a successful compliance program. Without this training, employees can inadvertently undermine the deployment and operation of internal controls and selected Sarbanes-Oxley compliance initiatives. Since internal controls will evolve over time, awareness training should be conducted periodically to update employees on changing processes.
  • Financial system portfolio (FSP)—A company cannot measure Sarbanes-Oxley compliance if it does not establish the breadth and depth of its financial system portfolio. Again, figure 2 illustrates the targeted risk assessment strategy for Sarbanes-Oxley compliance. The two primary tiers should be reviewed to achieve minimal compliance. The first tier is the financial systems that perform core financial transactions. Next, the second-tier targets are systems that interface with the core systems. For example, a tier-two system captures an input transaction that is later fed to a tier-one finance system. Alternatively, a tier-two reporting system might use extractions from a core financial system to generate company financial reports.

While the core and feeder financial systems are the heart of compliance, other IT process areas also impact financial accountability in that they provide managerial and operational support for the first- and second-tier systems. In addition, there are potential compliance issues with third-tier IT business processes. Figure 3 summarizes tier-three processes that are key IT impact areas affecting Sarbanes-Oxley compliance. The nine items shown describe specific compliance review targets. In each case, these items must be evaluated in light of Sarbanes-Oxley requirements.

Figure 3—Third-tier IT Functions
# Item Control Issues
1 Records management Retention policy, recovery, discovery, legibility, authenticity and auditability
2 E-mail retention policy Retention and recovery requirements will necessitate a review of the historical and existing e-mail.
3 Employee training Education of the business and IT population regarding the compliance and control environment, security standards, and objectives will need to be emphasized
4 Data administration Data issues will emerge from the more formalized control environment, including capacity management, increased storage needs, retrievability and access permissions.
5 Change control System and utility library management plus the change control process surrounding this repository
6 Third-party providers Review of contract terms and internal operation of suppliers and vendors
7 Process documentation Documentation of financially linked processes from a control viewpoint
8 Periodic testing Periodic testing to ensure ongoing compliance
9 Infrastructure implications User access and monitoring, including intrusion detection

 

Figure 2 shows a fourth group of IT control-related areas that are associated with high-level enterprise processes often driven by IT governance. It is unlikely that Sarbanes-Oxley compliance will require control processes for these enterprise functions in the short run. However, they should not be completely ignored. Among the most important are the following:

  • IT role definition—Segregation of critical duties is an audit issue. All IT roles need to be defined and security access specifically identified.
  • Risk assessment—Sarbanes-Oxley specifies that formal risk assessment be performed on all related system areas, including the system area and the infrastructure components.
  • Planning systems—Sarbanes-Oxley specifies that the planning systems processes be visible and approved by appropriate management, including new IT systems business cases and portfolio alignment.
  • Executive involvement—Formal IT links to executive management and the audit committee are specified. Compliance with this requirement will dictate changes to the IT governance process and organizational culture for most organizations.
  • Infrastructure review—Sarbanes-Oxley requires initial and periodic reviews of infrastructure.
  • Business continuity planning—Real-time reporting outlined in section 409 can be in jeopardy.
  • Business process management—Over the longer term, an automated approach to process documentation will be required for efficiency reasons.
  • Whistle-blower system—Sarbanes-Oxley requires confidential access to the audit committee for purposes of reporting suspicious events.
  • Project tracking and oversight—More formalized status metrics are required to measure performance of projects. These metrics involve the collection of more than time and budget information. Maturation of project reporting dashboards is a likely outcome of this requirement.
  • Project planning—Sarbanes-Oxley requires more disciplined project planning documentation, including requirements definition and tracking.
  • Organization communication—Ongoing Sarbanes-Oxley compliance will require broad communication to the organization regarding the control objectives and processes.
  • Software quality assurance—Given the immature state of quality assurance processes in the typical IT organization, this requirement will spur major cultural and technical issues to resolve.
  • Software subcontract management—Oversight for third-party service providers may require additional resources to perform those activities.

The tactical mission involves how to achieve initial compliance, and this mission will most likely require that high-priority targets be tiers one and two.

Nonetheless, enterprise and IT functions in tiers three and four are also important as part of a risk assessment. Many of these functions contain gaps in general internal controls, implying that a portion of the area could be given a high priority.

System certification (SC) is a formal process for evaluating and authenticating a system’s mission and required functional capabilities. Through a certification process, a target system’s operation is assured under a standard companywide process to certify and accredit that its operation maintains internal control processes throughout the system life cycle.

The US Department of Defense (DoD) has defined successful control processes for system security. In these procedures, there is a process for certification of systems as exemplified by the DoD Information Technology Security Certification and Accreditation Process (DITSCAP).5 The systems must meet more than 100 minimum internal control and security requirements to be certified. Generally, the DITSCAP processes for certifying financial systems cover 15 key areas, including:6

  1. Mission description and system identification
  2. Operating environment
  3. System architecture description
  4. System security requirements
  5. Organization and resources
  6. System or operational concept of operation
  7. Information system security policy
  8. Security requirements
  9. Security test
  10. Applicable system development artifacts
  11. System rules of behavior
  12. Incident response plan
  13. Contingency plan
  14. Personnel controls and technical security controls
  15. Security education, training and awareness plan

The DITSCAP certification process is accepted within many government agencies; its structure is well established. There is historical precedence for governmental processes migrating into the commercial sector, and a mature process, such as DITSCAP, could be a readily available tool in meeting Sarbanes-Oxley compliance requirements.

Conclusion

It is important to recognize that Sarbanes-Oxley compliance is not an event. Rather, it is a regulated process improvement activity, which will be long-term as long as the government regulatory sources continue to sponsor it. Beyond the initial compliance stage, there will be ongoing pressure to incrementally improve the internal control and reporting environment. This concept is similar to other organizational process maturation models that many IT organizations have pursued for several years, such as the Software Engineering Institute’s Capability Maturity Model.

Start-up time constraints dictate that many of the new control items be installed in minimal fashion and manually oriented. As the process evolves, organizations will move to automate more of the processes to cut operational support costs. This ongoing activity will stimulate work for the IT organization and, over the long term, the IT organization will improve its management and operational productivity as a result of these changes.

Will all IT organizations agree with this improved benefits position? Probably not, but statutory penalties might sweeten the business appetite for improved internal controls.

As envisioned here, Sarbanes-Oxley will have (already has) a significant impact on the financial, management and IT functions within public companies. Penalties associated with failure to comply with these control regulations suggest that firms will not be able to avoid embracing the specified compliance activity. Unfortunately, it is not clear how the auditors will interpret the legislation. This void leaves IT management in a tenuous position. To meet the compliance requirements and minimize the statutory penalties associated with Sarbanes-Oxley, a four-prong compliance initiative is proposed consisting of the following:

  • Compliance managers
  • Awareness training
  • Financial system portfolio
  • System certification

Even with a tactically oriented compliance initiative, the key question on senior management’s mind is, “What might happen with the regulation in the long term?” Regardless of the answer, target improvement areas need to be documented and presented to executives along with a resource plan to complete the activity. The basic intent of Sarbanes-Oxley, as outlined, is sound. For that reason, IT organizations should use the Act as a stimulus to improve their operational and internal controls. IT organizations must continue to mature their managerial processes, and Sarbanes-Oxley is the right driver to get that accomplished. There is evidence that the maturation improves operational efficiency in the long term.

Endnotes

1 Mogull, Rich; Debra Logan; Lane Lesketa; “CEO Alert: How You Should Prepare for Sarbanes-Oxley,” Gartner Inc., IGG-10012003-03, 1 October 2003
2 Slocumb, Ray; “The Sarbanes-Oxley Act of 2002: Overview and Impact to IT,” Presentation to the Information Systems Research Council, University of Houston, USA, 19 November 2003
3 IT Governance Institute, IT Control Objectives for Sarbanes-Oxley, USA, 2003
4 Marlin, Steven; “Sarbanes-Oxley has Companies Scrambling,” Information Week, 10 November 2003
5 US Department of Defense (DoD), DoD Instruction 5200.40, “DoD Information Technology Security Certification and Accreditation Process (DITSCAP),” Publication ASD(C3I), 30 December 1997
6 Defense Finance and Accounting Service, “System Security Authorization Agreement,” 1 March 2001

Charles W. Butler, Ph.D. is a professor in the Department of Computer Information Systems at Colorado State University, Fort Collins, Colorado, USA. Butler teaches and conducts IT research and collaborates with IT managers in developing improved IT management strategies and processes, software development methodologies, and metrics and quality assurance for traditional and object software. He served in the role of chief software scientist for McCabe & Associates in Columbia, Maryland, USA, and completed consulting engagements in more than 50 Fortune 500 companies.

Gary L. Richardson, Ph.D. is the coordinator for the University of Houston (Texas, USA) graduate-level project management certificate program. He has worked in various types of organizations during his more than 30-year professional career. During the early part of his career, he worked for Texas Instruments as a manufacturing engineer, the Defense Communications Agency and the US Air Force in Washington, DC. Interspersed throughout these assignments, he was a consultant, technologist and professor associated with various universities. He has taught at Texas A&M, University of North Texas, University of South Florida and more recently at the University of Houston (all USA). In addition, he was a part-time adjunct professor at three other universities. Richardson has published four computer-related textbooks and numerous technical articles related to the IT arena. He worked for Texaco and Service Corporation International in CIO-level positions during the latter half of his career.


Information Systems Control Journal, formerly the IS Audit & Control Journal, is published by ISACA®, Inc.. Membership in the association, a voluntary organization of persons interested in information systems (IS) auditing, control and security, entitles one to receive an annual subscription to the Information Systems Control Journal.

Opinions expressed in the Information Systems Control Journal represent the views of the authors and advertisers. They may differ from policies and official statements of ISACA® and/or the IT Governance Institute® and their committees, and from opinions endorsed by authors' employers, or the editors of this Journal. Information Systems Control Journal does not attest to the originality of authors' content.

© Copyright 2005 by ISACA® Inc., formerly the EDP Auditors Association. All rights res erved. ISCATM Information Systems Control AssociationTM

Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in writing from the association. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St., Salem, Mass. 01970, to photocopy articles owned by ISACA® Inc., for a flat fee of US $2.50 per article plus 25¢ per page. Send payment to the CCC stating the ISSN (1526-7407), date, volume, and first and last page number of each article. Copying for other than personal use or internal reference, or of articles or columns not owned by the association without express permission of the association or the copyright owner is expressly prohibited.

www.isaca.org

INFORMATION SYSTEMS CONTROL JOURNAL, VOLUME 2, 2005