You may notice a lot on this site and our sister sites about the “Sarbanes-Oxley Act”. You may be wondering why a piece of American financial legislation would be of interest to anyone?

Sarbanes-Oxley is an important because it affects nearly every major company in the US. Many foreign companies if they want to raise capital in the US are also affected.

The act itself was born out of the dotcom crash. Such high profile failures as Enron and WorldCom highlighted shortcomings in the financial reporting arena.

Fast growing technology were perceived as some of the worst culprits. As these may be the sort of companies you are working for or running, maybe it should doubly interest you.

The effects can be seen everywhere from the detail required in software to the final accounts. Thus we can not sit back and think “This has nothing to do with Me”. Perhaps we come across it in testing the software or our company is penalised for not complying.

The Sarbanes-Oxley Act is a piece of American legislation, introduced in 2002. The aim was to cllean up financial reporting and audits of major companies. Authorities such as the Securities Exchange Commission (SEC) have been given more extensive powers under the Act.

Sarbanes-Oxley has to be taken into account in many areas. For example development. >Especially in financial software, an eye must be kept open for issues affecting compliance with Sarbanes-Oxley.

Issues may arise not just explicity. E.g. The requirements may say “this functionality is needed to comply with section 404.” However the developer or tester may notice that a vital piece of data has been missed due to not being mentioned in requirements.

Of course these issues are not confined to finance software. They can be applied to any software that is to be used in a legislative constrained environment.

Developing software is essentially about risk management. The customer wants a solution to a problem. In this instance, a software solution that will aid compliance with the Sarbanes-Oxley Act.

The risk involved is that the software supplied does not actually aid compliance. The risk has not been mitigated. Testing, if done properly should confirm that the solution does actually mitigate the risk.

Mechanisms should be in place to ensure that issues regarding compliance can be raised. The mechanisms can either be internal or external. They can also be part of the normal defect tracking systems used in most developments.

A risk management strategy is very useful. Risk can highlighted early on in the process. Planning can then go into tactical measures to mitigate the risk. If at any stage of development it looks like the software or process may lead to a failure of compliance this must be raised as a defect.

In some cases a concerned individual may choose to become a whistleblower. This typically happens where the person is concerned that a potential failure is covered up.

Whistleblowing can be conducted intenally or externally. Internally the person would raise the matter with senior management or some other structure such as internal audit. Externally the whistleblower will contact either the regulatory authorities. Alternatively a group connected with the company such as large shareholders.

Whistleblowing is seen in many quarters as informing on your company, managers and colleagues. Consequently it can be damaging to your career. A growth industry is therefore for whistleblower hotlines which operate in confidence. Due to the very large amounts involved, Sarbanes-oxley hotlines are very popular as an offering.