Why Was the Sarbanes-Oxley (SOX) Act Enacted?

SOX is a direct effort by the United States Congress to prevent publicly held corporations from experiencing an Enron- or WorldCom-like fiasco. In reaction to the numerous failings of Enron and other corporations that were less than forthcoming regarding the truthfulness and accuracy of their financial statements, the bill assigns responsibility and accountability for the accuracy of a company's financial reports. SOX also encourages separation of responsibilities. As a result, many corporations are splitting the positions of president and CEO between two people. In many corporations, these positions have been held by one individual. Two people provide for more checks and balances, thereby avoiding situations in which any one person holds too much decision-making power. SOX also specifically addresses the role of accounting and auditing firms both for SOX compliance and for traditional audits. It also dictates accounting practices and procedures and specifies the ramifications for officers should they fail to comply and for auditing firms should they not follow the terms of the act.

What Areas of Data Security Does SOX Address?

The simple answer to that question is "none." Unlike the Health Insurance Portability and Accountability Act ( HIPAA) and the Gramm-Leach-Bliley Act (GLBA)--two other U.S. government acts that have received lots of attention from the IT security world--SOX does not specifically spell out any data security requirements. Both HIPAA and GLBA are quite explicit in their requirements, but not SOX. If SOX is not explicit on the data security requirements, why are some people claiming that it has IT implications? Most likely, it's because of SOX's original use of the term "internal control." Before the act was finalized, this term was not well-defined, which led people to believe "internal control" meant many things, including auditing every electronic transaction on a computer and securing the database in which the company's data resided. To eliminate this confusion, the term has been re-worded as "internal controls over financial reporting" and is always used within the context of some aspect of financial reporting.

Does This Mean I Don't Have to Worry About SOX?

One topic SOX addresses is the business risk associated with a company's financial data being inaccurate. A complete analysis requires companies to evaluate their processes and procedures, the obvious goal being to ensure that appropriate processes and procedures are in place to be able to validate and verify what's claimed as a company's bottom line. Does managing this business risk and ensuring appropriate processes are in place preclude IT's involvement or preclude the need for data to be secured appropriately? Absolutely not. Are some CFOs going to investigate IT's processes and require adherence to a more restrictive security policy? Probably. If a company's accounting department is already well-organized with well-established processes and procedures, IT will probably be approached sooner rather than later. Does SOX require that IT be involved? Not in so many words. Is it implied? I'd have to say yes.

However, I believe SOX leaves it up to each corporation to determine how it's going to manage its risk--the primary risk being that the company's stated financials don't match reality. Any auditor who performs a SOX audit is going to analyze the company's financial processes and control procedures and ask what processes or procedures have changed since the last audit. As part of the audit, the auditor is also going to analyze the company's risk associated with managing the accuracy of that financial data. I believe that the auditor will accept that a company has mitigated its risk by securing its electronic data so that only users with a "need to know" have access to it. However, I also believe that the auditor will accept that a company has mitigated its risk by purchasing and implementing a robust software accounting package that helps them implement standard accounting practices and uses more complex algorithms, providing more checks and balances to algorithmically ensure the integrity of the financial data.

It appears that it is up to the company to determine how best to mitigate the risk to its financial data and how best to ensure its accuracy. This is because SOX applies to all publicly traded companies--from large to small; therefore, it cannot mandate a specific solution or resolution to mitigate risk. SOX clearly allows businesses to base risk mitigation actions on the size of the company, cost of the solution, and resources required to implement it. In other words, the act recognizes that one solution will not satisfy every company's requirements. I would be cautious about products that claim to help you become SOX "compliant" because, with the exception of discussing generally acceptable accounting principles, SOX does not specifically spell out how to be in compliance. Could these products help you in your company's compliance? Possibly. But only if the people in your company who are responsible for the integrity of your financial data deem, through a business risk analysis, that the product addresses an area of risk.

Will SOX Ever Address Data Security Issues?

Just because SOX does not currently address either IT or data security, does that mean it never will? No. Acts can be modified. And if there is too much confusion about this issue, it's likely that the act will be modified to address IT and/or data security. But like the final ruling for HIPAA, it's almost guaranteed that the requirements will be general in nature and not dictate a specific solution or product. The ruling must acknowledge that companies are using literally every operating system possible and that not all solutions are available on all platforms. For example, two of the requirements could be that there must be accountability for users' work and that all users must be authenticated. In OS/400 terms, this would mean that users cannot share the same user ID and password (accountability) and that they must be able to prove that they are who they say they are (authentication) via a valid user ID and password, a network authentication mechanism (such as Kerberos), a one-time use password, or a digital certificate. As you can see, even in OS/400 terms, you would have choices for the actual implementation.

If You Want to Be Proactive

Is it inappropriate for you, as an IT professional, to want to apply the intent of SOX to your environment? Not at all. I think it is wise to be proactive. You should determine whether your company's financial data is secured from prying eyes, whether it is backed up regularly, and whether changes to critical files are journaled. Other security "best practices" can be found in ISO standard BS7799. While not all that popular in the United States, BS7799 started out as a British standard and has become widely accepted throughout Europe and Asia as the security standard to be followed.

If you aren't into researching an ISO standard and how it applies to your shop, here are some suggestions:
If you don't have a security policy, now's the time to develop one. A well-written security policy assigns responsibility for various actions and clearly spells out what is acceptable behavior (and what is not).

• Move the responsibility for determining who can access data (financial and otherwise) from IT to the data owner. IT should be the custodian and implementer of the data owner's policies. It should not be making the policy.
• Implement the concept of "least privilege." That is, give users access only to data and applications that they have a direct need for. For example, say that you have an AR (Accounts Receivable) or AP (Accounts Payable) application running on your system. With few exceptions, why should anyone outside of the accounting department need access to this financial data? The accounting department can be given explicit authority to the application libraries, and individual exceptions can also be given explicit authority. Then, the libraries containing the application can be secured by setting them to *PUBLIC *EXCLUDE, preventing the rest of the company--those without a "need to know"--from accessing this financial information.
• Turn on OS/400 auditing to track and record what has occurred on the system.
• Journal the critical data files to capture details of each change made to the file.
• Ensure all financial and other critical data is backed up regularly or is available through data replication or a high-availability solution.

For More Information

Before you get swept up in the SOX furor over its implications on IT, I encourage you to do some research of your own. I've found the explanations of the act at the Sarbanes-Oxley Web site to be very insightful and helpful in clarifying the issues and the intent of the act. The Corporate Governance Online Web site provides timely news regarding the act and has a good document that discusses FAQs regarding "internal controls." And if you'd like some good bedtime reading, you can download the Sarbanes-Oxley Act itself.

Now that you know a bit more about Sarbanes-Oxley, I hope that you feel better prepared to determine whether SOX will have an impact on your IT organization.


Carol Woodbury is co-founder of SkyView Partners, a firm specializing in security consulting and services and developers of the soon-to-be released software, SkyView Risk Assessor for OS/400. Carol has over 12 years in the security industry, 10 of those working for IBM's Enterprise Server Group as the AS/400 Security Architect and Chief Engineering Manager of Security Technology. Look for Carol’s second book, Experts’ Guide to OS/400 Security, to be released later this fall. Carol can be reached at This e-mail address is being protected from spam bots, you need JavaScript enabled to view it .