In 2002 the Sarbanes Oxley Act (SOX) passed following the scandals around Enron and Worldcom. The main goal was to establish transparency structures within big US companies. SOX e.g. asks for processes in the company, who reports to whom, who has access to figures and how are decisions made regarding e.g how prices for products are computed and communicated.
SOX has been criticised for loading more bureaucracy to the companies employees – and it certainly does, because we are living in a 3 dimensional world. What I mean is, that for every manual step a human has to make it takes time and therefore money.
SOX on the other hand is a very good tool and reason to have a look at your processes and starting optimizing them – with e.g. more-dimensional software.
With more dimensional software I mean pieces of code, which are not intended to just do their job (like functions in a script) but to also report via a standardised API to a SOX control software. This could look like
and could so be identified and easily extended for SOX control software.
If code would report itself it was easily possible to control what is done in the deepest niches of corporate software and critical snippets could be identified and controlled. IT power is cheaper than human resources and new structures could be more easily integrated.
On the other hand with a real coding framework (which was compliant to the 2004 COSO framework, but pushes it into a more practical and pragmatical direction) the architecture of e.g. payment-systems could be done more easily: SOX then builds the quasi backbone of the billing system and system-wide standards were guaranteed. Especially from a security point of view a wishable aspect because daily work and email-systems offer security holes en masse.