What about Best Practices? 1828



  • Just for context - Me: Software development background, freelance consulting, eCommerce, ERP systems, PMP designation. ZERO financial training.
    Like anyone else in IT, I’ve experienced the same headaches. I’ve learned a lot about SOX, and here in Canada ‘Bill 198’ (essentially the same thing).
    While a lot of the headaches remain, I now understand a few things in a new perspective:

    1. SOX often causes panic and over-reaction as a result of a lack of SOX knowledge. Often leading to poorly implemented procedures before the business is ready.
    2. SOX is often used to deflect responsibility/work. ‘I can’t do that, it’s against SOX’. WTF??
    3. The nature of IT folks in general (myself included) is that we like the power and control. Having it taken away doesn’t feel so good. But did we really NEED it? Supporting live systems can be done in a professional and controlled manner.
    4. If an IT shop were set up originally using best practices (eg. ITIL), legislation such as SOX would have had less impact. Most of the IT changes that are being implemented to support corporate SOX policies are simply best practice.
    5. Policies, Procedures and Controls slow down development/changes to systems. YES… Exactly… IMHO this is a good thing. Stop. Analyze. Review. Test. Document. Build it once, correctly.
      Naturally I’ve over simplified things, but in general I don’t see SOX as being negative. It’s merely forcing me to do things the way they should have been done in the first place. The right way.
      Just my USD.02
      Now, back to the damned audit reports. 😉


  • I agree with you.
    The biggest headache i have with SOX is just getting people to perform the controls they claim operate or have been asked to do. Many people in my organisation are very stubborn and set in their ways and therefore cannot see the benefits…
    Most of the changes I have recommended do not take much time to complete and yet I seem to be ignored most of the time.
    (just have to get of my chest every once in a while.)



    1. If an IT shop were set up originally using best practices (eg. ITIL), legislation such as SOX would have had less impact. Most of the IT changes that are being implemented to support corporate SOX policies are simply best practice.

    yes I have seen that if you are following ITIL practices (correctly) in the IT shop specially those related to change management and configuration management it results in a good control environment and aids testing for SOX Compliance.
    Calvin



  • Just my USD.02
    It’s good to finally see somone in the day-to-day part of IT understand what we’re doing and why 🙂



  • Hi and welcome to forums 🙂 It’s good to have fellow IT professionals to share prespectives in supporting SOX requirements. I’ve also been in IT for 33 years (started as a programmer/analyst right after I gradudated from high school) Below are some brief comments:

    1. SOX often causes panic and over-reaction as a result of a lack of SOX knowledge. Often leading to poorly implemented procedures before the business is ready.
      Below is what I feel is needed … Some good old fashioned education and project planning:
      http://www.sarbanes-oxley-forum.com/modules.php?name=Forums-and-file=viewtopic-and-p=5838#5838
    2. SOX is often used to deflect responsibility/work. ‘I can’t do that, it’s against SOX’.
      Yes, we’ve seen a lot of classical examples of folks going way out the scope of SOX requirements (e.g., trying to control USD.50 pens for example in link below). This is why education and a good knowledge of SOX is essential to actually question folks setting up unusual requirements 😉
      http://www.sarbanes-oxley-forum.com/modules.php?name=Forums-and-file=viewtopic-and-t=1506
    3. The nature of IT folks in general (myself included) is that we like the power and control. Having it taken away doesn’t feel so good. But did we really NEED it? Supporting live systems can be done in a professional and controlled manner.
      Times have indeed changed from the 1970s and 1980s, as now IT professionals should also be ‘business savy’. I work in the insurance profession and over 30 years earned several professional designations in insurance (e.g., CPCU, AAI, etc) – as I took advantage of free training opportunities and was a good test taker 😉 The days of just being a coder or a pure IT systems analyst are drawing to a close, as IT professionals need to know both the business and technology well. IT is a very demanding profession as our original poster well knows (e.g., esp. when you consider on-call support plus the pressure to constantly deliver in our highly automated business world).
    4. If an IT shop were set up originally using best practices (eg. ITIL), legislation such as SOX would have had less impact. Most of the IT changes that are being implemented to support corporate SOX policies are simply best practice.
      True - In a well audited and regulated company, some of our Sox experts here have noted that they simply ‘dropped SOX in’ with little or no major impacts. Obviously, there’s more work to do with SOX and it costs businesses USDUSDUSD. Still, it’s a whole lot easier for a company that has great security, best practices, great exisiting financial controls (e.g., checks-and-balances, separation of duties, autonomy controls, etc)
    5. Policies, Procedures and Controls slow down development/changes to systems. YES… Exactly… IMHO this is a good thing. Stop. Analyze. Review. Test. Document. Build it once, correctly.
      Indeed 🙂 I’m a firm believer in the Project Management process and have worked with a # of methodologies. Building a system is like building a house – you need a good blueprint, top notch workers, a plan to bring it all together, testing, inspections, etc. Hopefully, when you turn the key you’ll have something good, rather than falling through the floor 😉

Log in to reply