The appropriately named Sarbanes-Oxley Compliance Toolkit includes a whole range of materials specifically put together to both introduce, and take you through this most important of legislation.
As security is such a major theme on the Act, many organizations are using the international ISO standards. The ISO 27001 Portal outlines these. A copy of the standards, and security policies, can be obtained via the ISO 17799 Toolkit.
The SOX email storage requirements can be fulfilled using the
GFI MailArchiver
SOX Advertisers
Sarbanes What?
Our server logs indicate some interesting mis-spellings: Sarbannes Oxley, Sorbane Oxley, Sarbanne Oxley, Sarbaines Oxley, Sarbanesoxley, Sorbanes Oxley, Sabanes Oxley, Sarbane Oxley, and Sarbanes Oaxley, to name but a few!
Sarbanes-Oxley Act Forum: Forums
The Sarbanes Oxley Act :: View topic - Service Operations compliancy
Posted: Thu Jun 04, 2009 9:24 am Post subject: Service Operations compliancy
Hello,
I'm a database developer, however I'm not in the IT department. I work for Service Operations.
I validate my own reports I create from a SQL server database that affect external customers. Am I violating SOX compliancy by doing this? Should I really have someone else valiating my reports?
Thank you for any advice you can provide!
Michelle
Joined: Jan 12, 2006 Posts: 849 Location: Roanoke, Virginia
Posted: Thu Jun 04, 2009 11:04 am Post subject:
Hi Michelle and welcome to the forums
The purpose of SOX is to ensure Financial systems are well controlled, address material risks, and that financial workflows have proper oversight. However, SOX is often silent on detailed techniques because it allows a wide variety of companies flexibilities in achieving controls. Certainly, it is subject to interpretation as I've seen companies set up SOX related controls which are completely unrelated to the act itself.
End users can generate their own reports for the company, but it should be done with some acertainment of risks and with proper checks-and-balances.
Below are some key questions to evaluate:
-- Are these reports you generate financial in nature?
-- As you validate returned query results, do you balance to other controls or validate for reasonableness?
-- If errors were to be made, could it have a major impact on your company's income, valuation, or expenses?
-- Could someone in your position in collusion with the external customers commit fraud of a significant nature?
Some ideas and additional resources for clarification:
-- Sometimes controls can be setup, where users can validate their own work within a certain financial threshold. They would only need approval or validation from others on much larger transactions.
-- In your specific case, the external SOX auditors assigned to company would be the best judge of any additional controls needed.
-- COBIT 4 provides SOX 404 guidelines that many SOX auditors check against for IT related controls and COSO is used for the workflow and "human side" in evaluating the process
Joined: May 26, 2008 Posts: 187 Location: Switzerland
Posted: Wed Jun 24, 2009 8:35 am Post subject: database reports and SOX
Section 404 of the Sarbanes-Oxley Act deals with assuring the quality of financial reporting.
So the first question would be whether your reports are used as an input to create postings in financial accounting and ultimately financial statements or at least to verify their quality.
If yes, the next question would be whether the numbers in there are material for the financial statements (e.g. as a percentage of net profit or total assets).
If both of the above points are true, you should assess what assures that your reports perform as intended? Do they select the data in a complete way or are certain records inadverently omitted? Are elements included that should not be there? Are there any logical errors? Usually a user that uses the report in practice and that provided the requirements what the report should do, should test the report in a test envionment that uses realistic data (e.g. a copy of recent live data). Ideally the test scenarios should also include weird inputs that a new user or a user that makes typoes could use.
If the report is really complicated and materially important, you may also consider having another database developer review your code and look for any logic errors in your code (e.g. a record in a table does not have any corresponding record in a joined table and you still want its fields to be displayed but have forgotten to define an outer join so that the ouput of that record is omitted, your forget some of multiple joint conditions and get unnecessary output lines of joins of the data, etc.).
You would be amazed how many complicated Excel sheets are used as input for material accounting postings where nobody has ever reviewed the quality of the Excel formulas or where links to other Excel files have been forgotten to be updated or point to the wrong cell because rows or columns have been added to the other Excel file.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
Trademarks referenced on the SOX Act Forum are property of their respective owners. Comments are property of their respective posters. Sarbanes-Oxley Act Implementation Portal: Sarbanes Oxley compliance, information, software, & internal audit committee resources. Sarbox. Site source is copyright nuke (c)2003, and is Free Software under the GNU / GPL licence agreement. All Rights Are Reserved.