The US Sarbanes-Oxley Act is an old bandwagon for most of the publicly listed companies, as they have been riding on it since its inception in 2002. But, most companies face newer challenges every day with the birth of newer technology, rapidly changing business conditions, and/or mergers and acquisitions.
Even after 8 years of Sarbanes-Oxley, companies are still struggling to identify the right scope and the appropriate approach toward Sarbanes-Oxley IT general controls (ITGC). Lack of knowledge to identify the right scope can lead to an increase in the overall cost of compliance since organizations may test applications that would otherwise be deemed out of scope if an appropriate risk assessment had been performed.
The question that should be asked is, what should companies do to identify the exact scope for ITGC? Not only is it important to identify the systems that would fall into the scope of Sarbanes-Oxley, it is also important to identify the extent to which a specific system should be tested. For example, an auditor would definitely perform detailed testing for the financial system of records (SAP or PeopleSoft), but would not spend too much time or cost on performing the same level of testing for a system that falls into the scope but has only a handful of system administrators managing it.
The most appropriate and effective way to define the right scope and the extent of testing for each Sarbanes-Oxley in-scope system is to perform a risk assessment focusing on the risks associated with Sarbanes-Oxley requirements and specific to ITGC. Risk assessment is not a new buzzword—everyone in today’s world talks about risk-based approach, risk assessments, etc., but few understand that for a risk assessment exercise to be successful, it is extremely important to identify whether the focus of risk assessment is confidentiality, integrity and/or availability, and then to define the risk criteria/parameters.
For example, a risk assessment exercise for Payment Card Industry (PCI) Data Security Standard (DSS) compliance focuses on what should and should not be stored to ensure that credit card information is not compromised and, thus, to ensure data privacy. However, for Sarbanes-Oxley, the same approach cannot be applied because Sarbanes-Oxley focuses on data integrity and misstatements to financial reporting. Therefore, the risk assessment criterion shifts from data privacy to data integrity.
The right approach to identify the exact scope and extent of testing for Sarbanes-Oxley ITGC is to perform a detailed risk assessment that is focused on the risks that are associated with each general control process area, such as change management, logical access, computer operations, job scheduling, and third parties/service organizations that manage applications or data centers.
Identify Risk Criteria/Parameters
The organization’s approach to Sarbanes-Oxley risk assessment should identify the key risk parameters that would help to quantify the risks for ITGC. An application might be considered “high risk” when viewed from a change management perspective because it might undergo hundreds of changes every month, but it might be “low risk” when viewed from a logical access perspective because it has only four to five administrators and no end users accessing the application.
To identify the appropriate risk parameters to perform a risk assessment for Sarbanes-Oxley ITGC, the focus should be on integrity and access risks.
Integrity Risk
Integrity risk encompasses all of the risks associated with the authorization, completeness and accuracy of transactions as they are entered into, processed by, summarized by and reported on by the various application systems deployed by the organization. These risks pervasively apply to every aspect of an application system that is used to support the core financial system.
The following are the critical parameters that could impact the integrity of a financial application:- Number of changes—The number of changes made to a financial application is directly proportional to the risk— the more changes, the higher the risk.
- Number of application controls—If an application is completely automated and the output produced is relied upon for financial reporting without manual intervention, it becomes critical to ensure that all automated application controls are effective. Again, the more automated the application controls, the more reliance on the application and the higher the risk.
- Developed in-house—This parameter is critical to identify appropriate risk levels. If an application is homegrown and an internal team of developers has access to modify and maintain the application, the associated risk should be high; whereas, if an application is commercial, any changes to the source code will need vendor intervention and appropriate methods.
- Number of developers—The number of developers is again directly proportionate to the risk associated with inappropriate application configuration and is a critical parameter in evaluating risk levels.
Access Risk
Access risk focuses on the risk associated with inappropriate access to financial systems, data or information. It encompasses the risks associated with improper segregation of duties, the integrity of financial data and databases, and information confidentiality.
The following are the critical parameters that could impact access to a financial application:- Number of users—The number of users accessing the application has a direct impact on the risk of unauthorized access and unapproved transactions—the more users, the more risk. An application with three users would probably be considered to have low risk; however, an application with 30,000 users will have a higher level of risk because there will be more chances of human error while granting access, of granting conflicting access or of inappropriate access monitoring.
- Number of administrators—Similar to the number of users, the number of administrators managing the application has a direct, proportionate impact on risk levels.
- Direct access to the underlying database—This is a critical parameter, as it can leave backdoor entries for users with direct access to the underlying database. Few applications store user information within the application, and direct access to the database is not allowed; whereas, some applications allow users to directly access the database without going through the application. Again, the risk will be high in the latter case.
- Integrated/independent authentication—It is very important to evaluate the authentication mechanisms in place for a financial application to determine the list of people who have access to the application. If an application uses integrated authentication with the operating system, the risk is high because users who are approved to manage the operating system would also be granted access to the application; whereas, if the application has its own authentication mechanisms, the risk will be low because even though a person might be an administrator of the operating system, he/she would require an application ID to access the financial application.
The above identified risk parameters can help determine/ quantify the actual risk levels for each financial application from an ITGC perspective. A risk scale of low, medium or high is used in the following example, as a demonstration, to calculate the risk ratings for the applications. The risk scale for Sarbanes-Oxley can be defined.
>Implementation of Risk Assessment
The following example demonstrates the implementation of the risk assessment approach.
Company ABC Inc. has two financially critical applications used for financial reporting purposes. App 1 is the financial system of records and is a commercial application that can be customized, but no development is possible. Any development effort requires contacting the vendor. App 1 has about 150 end users from the accounts payable (AP), accounts receivable (AR), general ledger (GL) and payroll departments, who enter financial data. The application has a Structured Query Language (SQL) database that is maintained by two administrators, and no end users have direct access to the database due to security designed within the application. App 1 has its own authentication mechanism. Since App 1 is a commercial application, not many changes are performed, but historical data show that about two changes are performed annually. Since this is a commercial application, the vendor has built several application controls (approximately 25) that control the environment to produce accurate financial reports and results.
App 2 is a homegrown application and is maintained by 20 developers, and about 100 end users access it. It has a database that is maintained by 10 system administrators. The database can be directly accessed by the users if they open an Open Database Connectivity (ODBC) connection outside of the application. The application has integrated authentication with the underlying Windows operating systems. Since it was developed in house, the number of changes is on the higher side—close to 300 annually, according to historical data. No application controls are built into this homegrown application.
The results of risk assessment for these two applications show that App 2 is rated a high risk from a Sarbanes-Oxley ITGC perspective and needs controls to be established to gain reasonable assurance about the integrity of financial data. Since the number of changes made to the application is high, an auditor should test all aspects of change management, including predevelopment approvals, testing (unit, stress and integration, as applicable), verification of test plans and test results, quality assurance testing, separation of environments (development, test, quality assurance, training, production), segregation of duties (no developer access to production), premigration approval, verification that migration is done by authorized individuals, and postimplementation control to ensure that the change is working as expected and that nothing “broke.” Similarly, for logical access, both prevent and detect controls (such as user provisioning/deprovisioning, monitoring of security logs, user access reviews and appropriate password controls) should be established.
App 1 is rated as low risk due to the lower number of changes made to the application and lack of development effort being done internally. For a low-risk application, the organization can consider testing only critical preventive controls, instead of doing a full-blown ITGC testing. For example, for change management, only a preproduction approval should be sufficient, since all development and testing is performed by the external vendor, and all other change management controls can be referred to a Statement on Auditing Standards No. 70 (SAS 70) report or an equivalent. Similarly, for logical access, controls such as system administrator reviews can be eliminated because there are only two administrators and direct access to the database is not allowed. For low-risk applications, preventive controls such as appropriate password configurations and provisioning/deprovisioning provide enough assurance that the applications are secure and the necessity of detect controls can be eliminated using this approach, which will result in fewer controls and reduction in overall cost of compliance.
Once an organization has identified the high-risk and low-risk applications and the controls are established and tested for appropriateness, the internal audit department should analyze the trend for failures and effective controls to evaluate whether more controls should be implemented for certain applications and whether some controls can be eliminated for others. For example, if changes to password configuration controls are very rare and have been effective for a period of time, the control can be put on rotation, where it is tested every two years to reduce the overall effort of testing and cost as well to reduce the load on the IT department. Similarly, if changes are rare for an application (as was the case with App 1 in the previous example), those controls can be performed by inquiry, instead of a full-blown test, to confirm if any changes were made to the application, and further testing can be done only if changes were made. If the trend analysis shows that the controls are effective year on year and, most important, if there is no feedback or issues raised by the external auditor, existing controls are clear enough to ensure that all financial transactions are secure and reliable.
Conclusion
Using this approach, focusing on the parameters that are critical from the Sarbanes-Oxley ITGC perspective, internal audit departments across the organizations can save a lot of time, effort and money and also reduce the load on the IT department. Performing risk assessments periodically with the right parameters in place can be used by audit management as a basis to gain comfort that all systems are being validated and tested as required by the Sarbanes-Oxley ITGC requirements. This will reduce the probability of any significant deficiencies and increase external auditors’ confidence in management’s testing. If the scope of the ITGC audit is appropriate, the extent of manual procedures that an external auditor will typically perform will be reduced, which will further reduce the overall cost of compliance.
Editor’s Note
Collaborate with ISACA members and access additional resources on this topic in the ISACA Knowledge Center located at h04.v6pu.com/knowledgecenter.
Arvind Mehta, CISA, C-EH, ISO 27001 LA
manages a global IT Sarbanes-Oxley program for the Technology Risk Services practice at EXL Risk & Financial Management, a Fortune 1000 company. His responsibilities include managing IT risk advisory projects with a focus on enterprise risk management, IT security, Sarbanes-Oxley section 404, Payment Card Industry (PCI) reviews, IT infrastructure reviews, vulnerability assessments, application security assessments, enterprise resource planning (ERP) security and separation of duties (SoD) reviews for PeopleSoft. Mehta has in-depth knowledge and understanding of enterprise risk management; IT security; and governance, risk and compliance (GRC) domains. With more than eight years of experience, he has worked with industry leaders in the food and beverage, staffing, insurance and banking, and health care industries.