The SOX act was passed after the Enron scandal (a year before this happened I interviewed with them).
The point of it is to make the cheif executive of a company directly responsible for the correct financial reporting of everything that goes on in their company. This act has real teeth – CEO’s are now more afraid of failing a SOX complaince audit than actually carrying out their business!
My problem is not with the act itself (it does not even mention IT in the text of the act) but with the interpriation being put upon it by the consulancies that have taken on the role of advisors and auditiors. You have trained accountants coming fresh to an IT environment and without understanding what they are doing demanding radical changes (asking that developers be denied access to version control software!). The senior management are so afraid of failing that audit that they take what the consultants say at face value.
Back in the early 90’s there was a scam going around the ISO 9000 audits. ISO 9000 basically consists of having a company document their procedures and demonstrate that they are following them. The idea was that companies could use this process to understand their own business and make improvements. However like most things it can be subverted by empire builders to increase their influence and status.
The following text would be a complete (although effectively useless) procedure:
This company does whatever is needed and requires no records to be kept (other than required by external requirements).
The ISO 9000 scam was how do you deal with the ISO 9000 complaince of your suppliers. All you really needed was some process for checking what had been supplied. Several consulatancies twisted this into that all suppliers in the supply chain must alkso be ISO 9000 accredited. This meant that all of your business partners also needed consulatants creating more work for the ISO 9000 industry.
Sox and IT
The basic idea of the sox compliance is that “sox compliant applications” (to qualify you must handle money or equivalent) must have certain controls in place:
- Any change to the system must be authorised by a business user.
- Developers of a system must not have access to the production system (the part missed is if they do they must fully log all changes made so that they can be approved by a manager).
- All data changes to the production system must be audited.
In theory these are sound principles and could be implemented at a sufficiently large company.
You could have distinct teams of development, implementation and support.
The problem is that the auditors are applying this as a one size fits all solution to all sox applications.
Large companies can afford to do this.
What happens when you have a small team that both develops and supports an application.
The auditors are insisting that all developers be denied even read access to production databases.
This means in the case of a data fix (which will happen from time to time) a developer will have to create a script and then pass it to someone (who has no special knowledge of the system) to run. The developer would have to create this without any possible testing! How is this possibly in the best interests of the company. For systems that operate 24×6 the poor guys with database access (who will be shared across multiple applications) will be on call at any time of the day to run scripts that developers will supply them. The room for errors is huge. What if the problem crosses multiple systems. The poor support engineer will have scripts being sent from each system and is having to run the correct (posibly untested) script on each system. This is just asking for trouble.
The SOX act is being used to comprimise the effectiveness of in house development teams!