Information security is about protecting the confidentiality, integrity and availability (CIA) of information assets, but the SOX component is only concerned with a subset: data integrity and misstatements to financial reporting. Accordingly, a SOX risk assessment should focus on data integrity and access risks in the area of financial reporting.
Integrity risk encompasses all of the risks associated with the authorization, completeness and accuracy of transactions as they occur, are processed, summarized and reported on by the various application systems deployed by the organization. These risks pervasively apply to every aspect of periphery apps that support the core financial system.
The following are the critical parameters that could impact the integrity of a financial application.
- Quantity of changes—The number of changes made to a financial application is directly proportional to the risk— the more changes, the higher the risk.
- Application controls—When an application is completely automated and the output produced is relied upon for financial reporting without manual intervention, it becomes more 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.
- Direct access to the underlying database—Databases are typically back-end components that store information for an application. The application controls how the data is entered, manipulated and stored. To access that data directly bypassing the application potentially destroys the integrity otherwise provided by application controls.
- Developed in-house vs COTS—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. Alternatively, if an application is commercial-off-the-shelf (COTS), any changes to the source code will need vendor intervention and appropriate methods.
- Quantity 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 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.
- Volume 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 thousands of 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 with superuser access has a direct, proportionate impact on risk levels.
- Direct access to the underlying database—Again, this is a big no-no, with implications to access risk as well, as it can leave backdoor entries for users with direct access to the underlying database.
- Source of authentication— If an application uses integrated authentication with the operating system, the risk may be higher as users who are approved to manage the operating system would also have access to the application and database. If the application has its own authentication mechanisms, the risk may be lower as OS admins would still require other credentials to access the financial application. (Note that one can argue the opposite; using integrated authentication database like Active Directory may be more secure since it is more frequently audited.)
- Auditing mechanisms— Auditing mechanisms can track and alert management to weaknesses and violations in access controls. The less auditing, the more risk.
The above identified risk parameters can help determine/ quantify the actual risk levels for each financial application from a general 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 SOX can be defined as shown below.
|Item||High Risk||Medium Risk||Low Risk|
|Impact to revenue/profit||Significant||Moderate||Little to None|
|Relationship to Financials||Material||Possibly material||Immaterial|
|Audit Implications||Qualification||Letter||Little to None|
|Legal Implications||Legal actions and fines||Potential fines||Non-serious|
|Interruption to Business Continuity||Significant||Moderate||Little to None|
|Alerts||Board of Directors||Executive Management||Functional Management|