S-Ox Testing unveiled!

S-Ox

I suppose this is the buzz word around us recently and everyone believe that this is the best procedure in town to implement and of course increase the productivity and reduce the cost. This article will speak on what this buzz word is all about and how does it differ from others, what we normally gaze through and work on.

S-Ox Testing:

S-Ox is a famous auditing procedure named after Sarbanes Oxley, which talks about financial controls of an organization. The S-Ox auditing procedure covers various sections and obliges the organization to follow the control measures for managing the financial aspects of the organization.

So how is it related to IT?

Though the term relies on the act of financial reporting, IT being the backbone of an Organization’s finance at present, has to be addressed with this. Under S-Ox, the audit process extends into areas that have a pervasive effect on the ability of the company to perform accounting and financial reporting. Since most business processes are supported by IT directly or indirectly, your project team will make the decision whether or not to create documentation integrated with the business processes or separate documentation for IT. Either way, IT processes that support the applications will also need to be documented. Thus S-Ox plays a role and this article will explain the implementation of S-Ox into IT.

S-Ox relies on control objectives and continuously monitors the activities that are needed in meeting the same. Hence understanding S-Ox is so simple. The motto behind S-Ox testing is that are we performing all that are needed in meeting what is required. I hope this is the motto of all testing and only the implementation varies. So how S-Ox testing is implemented?

Implementing S-Ox Testing:

S-Ox testing as any other testing process can easily be implemented and will yield you a great outcome of what is being developed. Once the documentation as stated above is done, team will have to work on “Control objectives” of the complete project. The real purpose, the basic requirement well drilled down, the objective of a product in various dimensions is called a control objective.

Now after framing a control objective, control activities are identified. Control activities are so simple, the activities that are required to address the objective and possess the risk by which the objective won’t be met. I believe the complexity of this can be reduced with this example:

Say, the control objective is “no unauthorized access”. Now the ‘control activity’ has to address what if there is a breach? What time frame would it take to identify it? This could be the risk and counter measures are to be identified. Then we go for implementing the test plan thereby knowing what the risk is and how do we address it. This will eventually increase the scope as well as coverage of testing which obviously will improvise the quality of the product and that too in low cost.

This article is referred from unrecognizable web pages at many parts which helped me out actually to understand this, which was in a typical auditor language.