Sox as an excuse 1763
EMM last edited by
I have just been informed that the term ‘SOX’ is being used accross the group for all sorts of insignificant matters.
My concern as teh SOX Manager, is that our department will now be blamed for futile exercises, whilst our cycle processes and key controls remain neglected by the same persons using the term.
What is the best manner in which to put a stop to this before the real SOX project is no longer taken seriously? Do all staff need to be trained all over again?
harrywaldron last edited by
Hi EMM - This is a valid concern and we’ve seen this issue frequently in the forums. We’ve definitely seen a # of things implemented in the ‘name of SOX’ that truly weren’t requirements.
Folks can certainly misuse this for leverage in trying to get changes accomplished. In some cases, there are borderline or indirect relationships with SOX, where someone wanting to improve IT security may see a need to control something, that’s not spelled out specifically.
In some respects, SOX compliancy is more of an art than science. It’s subject to interpretation and judgement, as the regulations are written in general rather than specific terms to encompass a wide range of companies and industries.
Some of these ideas might help:
- Before implementing any new SOX related requirement, make sure the team finds specific wording in the SOX requirements or things like COSO or COBIT if you are using these standards.
- Emphasize to the team, that improper implementations cost the company time and USDUSDUSD … That’s even worst than not complying, as it’s wasting the companies resources.
- Some formal training is a good idea … It can even be accomplished with some focused team meetings. It’s always helpful to look at what SOX is and how it should be implemented in a cost-effective manner might help everyone achieve a more balanced approach.
- Set up a formal approval system for SOX standards , so that if something is labeled as SOX it gets your blessings. It’s important to keep in mind that there’s lots of great non-SOX standards as well. They can be added to the list as needed, but shouldn’t fit into the SOX umbrella.
NC last edited by
Ha ha ha
greato… now some body is getting the feeling that i have been getting.
Best thing to do would be to Push the whole SOX implementation portion to the Quality Department and make it a part of quality compliances( ideally link compliances to performance appraisals). Ideally all compliances like ISO, BS etc. can be treated this way.
This way, no body would dare to make SOX( or at least make SOX look) as an excuse. Any compliance would be a mere COMPLIANCE requirement of th e Quality department.
No body dare question these sply when they are linked to PERFORMANCE APPRAISALS