Looking at SOX

  • TravisDBA (3/18/2011)


    I see too many smaller companies not currently under SOX get away with this like posting a single job that includes: Application Developer, Project Manager, Database Administrator, Web Developer, and Network Admin duties all in one job requirement. Simply because they are too cheap to hire separate people for each job description.

    Too cheap or don't have enough work? If there's an option between hiring one or two people to do the above work or hiring five part time consultants because they don't need a full time Network Admin or DBA I can't blame them for not going the consultant route.

  • I work on an Electric Health Record so HIPPA has a huge affect on how we do things. Not just in coding the application but in supporting it as well. If a client needs to know the output of a script we can't just email it to them. We have to post it someplace that they can retrieve it and we know who is retrieving it.

  • I see too many smaller companies not currently under SOX get away with this like posting a single job that includes: Application Developer, Project Manager, Database Administrator, Web Developer, and Network Admin duties all in one job requirement. Simply because they are too cheap to hire separate people for each job description. SOX takes care of this, and that is a good thing IMHO

    Working at a small private company, I'm still a Jack of all trades wearing too many hats for too little. So SOX hasn't affected me a bit. :hehe::-P

  • chrisn-585491 (3/18/2011)


    I see too many smaller companies not currently under SOX get away with this like posting a single job that includes: Application Developer, Project Manager, Database Administrator, Web Developer, and Network Admin duties all in one job requirement. Simply because they are too cheap to hire separate people for each job description. SOX takes care of this, and that is a good thing IMHO

    Working at a small private company, I'm still a Jack of all trades wearing too many hats for too little. So SOX hasn't affected me a bit. :hehe::-P

    Duh...Reading is fundamental. That was my point. Small private companies don't currently fall under SOX standards, so they get away with doing this.:-D

    "Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"

  • chrisn-585491 (3/18/2011)


    Working at a small private company, I'm still a Jack of all trades wearing too many hats for too little. So SOX hasn't affected me a bit. :hehe::-P

    SOX was not meant to affect you at all.

    It was written to keep Publicly Traded Companies from destroying our economy in the ways ENRON and Author Anderson did.

    After the dust settled it was difficult to prove that people other than the floor traders knew that changes where being made on the fly alegedly without appoval to shut down California Power Stations create more market demand.

    With SOX, these types of Game Changing updates to infrastructure and financial documents require documentation. Unless you want the SEC putting you in the cell next to Madeoff.

    😎

  • cfradenburg (3/18/2011)


    TravisDBA (3/18/2011)


    I see too many smaller companies not currently under SOX get away with this like posting a single job that includes: Application Developer, Project Manager, Database Administrator, Web Developer, and Network Admin duties all in one job requirement. Simply because they are too cheap to hire separate people for each job description.

    Too cheap or don't have enough work? If there's an option between hiring one or two people to do the above work or hiring five part time consultants because they don't need a full time Network Admin or DBA I can't blame them for not going the consultant route.

    In most cases I would venture to say, too cheap.:-D

    "Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"

  • Being a financial company we were impacted by SOX requirements. Although we were not certified, we had several processes in place that already added to the paperwork burden. However, all of us accepted the new requirements. And then, the economy took a downturn and impacted our company and we lost several of our colleagues.

    Now we feel the real challenge. With fewer people it has become a big impediment to our work efficiency.

    We have removed a few steps but continue to feel the pains of carrying this burden with the number of people left here.

    Cheers,

    BN

  • TravisDBA:

    Duh...Reading is fundamental. That was my point. Small private companies don't currently fall under SOX standards, so they get away with doing this

    .

    RIF yourself~! 😛

    I sometimes wish I had more structure so I don't get swept away in the cowboy tsunami of the chaos that is private companies....

  • HIPAA and, to a much lesser extent, PCI are what we have to comply with. The approach we took was to actually turn it into a competitive advantage of sorts.

    For the customers/prospects who are in "wait and see" mode about HIPAA, the compliance our organization and products offer gives us another check mark in the plus column for them choosing or sticking with our products. For our customers who are intense about HIPAA, it's additional peace of mind that we began our initiatives early. We've even been in a couple of situations where we've advised our customers on parts of their own HIPAA initiatives.

    As others have experienced, the changes to our environment has brought improvements in our security and system reliability.

    In the end, I'm very glad we chose the carrot over the stick.

    I think where you see more skepticism about SOX than HIPAA stems from the fact that almost all of us have health information stored on a computer somewhere. On the other hand, SOX feels more like the situation where the recess monitor takes the basketball away from everyone when only 2 kids were fighting over it.

    Phil Helmer
    Database Engineer

  • phelmer (3/18/2011)


    HIPAA and, to a much lesser extent, PCI are what we have to comply with. The approach we took was to actually turn it into a competitive advantage of sorts.

    That's great to see. Turn it around and take advantage of it. Good for business, and likely a fun challenge.

  • TravisDBA (3/18/2011)


    The "Separation of duties" is the big thing I see in SOX. No more "Jack of all trades" job descriptions. I see too many smaller companies not currently under SOX get away with this like posting a single job that includes: Application Developer, Project Manager, Database Administrator, Web Developer, and Network Admin duties all in one job requirement. Simply because they are too cheap to hire separate people for each job description. SOX takes care of this, and that is a good thing IMHO.:-D

    Those smaller shops may not be able to afford to hire two or three people as SOX would require under a strict interpretation. However, if you have established solid processes and documentation procedures showing what is going on through out the process with several sets of eyes observing the process and signing off, I don't see a problem.

    The problem is if you don't have a process that shows the chain of events. That is where problems can arise. It may take more effort in a small shop, but if done it will benefit the company as it grows and can begin to separate duties.

  • However, if you have established solid processes and documentation procedures showing what is going on through out the process with several sets of eyes observing the process and signing off, I don't see a problem.

    Well, there's the rub right there isn't it? Most smaller shops don't have this established, and as a result they tend to fly by the seat of their pants while managing their processes by crisis. I have actually seen company owners and managers that encourage this kind of environment. I have never understood completely why that is, but this is exactly what SOX standards tries to prevent by taking this kind of bad business behavior out of the hands pf owners and managers that have their own agendas.:-D

    "Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"

  • Well, SOX can be applied to smaller companies without requiring them to hire personnel they can't afford. SOX could require they establish those necessary policies and procedures.

  • I have worked in shops both requiring SOX and not, nothing with HIPAA yet.. However, even where SOX compliance isn't required that doesn't mean that applying change control and a level of job separation is not a good thing. I can't count the times in small shops where some seemingly inconsequential change had a substantially negative effect. A formal change control process is a good thing, even if your only customers are internal.. Now on the topic of separation of duties, this is where I have a bit more trouble. I see some areas of the company where more separation as good, such as accounting. In one environment on the IT side of change control there were effectively three roles, the requestor, the implementor, and the verifier. The requestor requests a change be put in, this is usually a piece of code that was developed or a script to be run, when possible all changes were scripted and included in the change request. The implementor was the guy(or gal) who actually applied the change to production. The verifier checks to see if the change that was applied WAS the change requested and if it did what was expected. The rule was there had to be at least 2 people filling those three roles, this worked well. BUT, I've seen separation of duties taken WAAAAAAAAAY to far as well and the organization was ok with it, it cost them a LOT of $$$$$$$$$ without any real benefit but hey they were ok with it.

    Having a formal software development and testing process is good as well. I worked in "cowboy" shops early on and changes to prod were slammed in as soon as some testing was done, I cringe when I thin about it now. The reality is that I alone couldn't conceive of all the ways it was possible to break a particular piece of code. In later years when I was working with formal software development lifecycles I turned out MUCH better code and was happy to do it. I don't think SOX expressly requires SDLC but an "easy" way to help achieve the goals of SOX are to apply it.

    The first few months after change control or SDLC are implemented are hard but over time they smooth themselves out. And the changes being implemented are of higher quality and less likely to break other things.

    A poster ahead of me was lamenting companies being too cheap to hire additional staff for separation of duties, to that poster, I don't think you realize that every person costs $$$$, and in some shops adding one person can mean the difference between being in the black or in the red for a year. As a business grows you can add additional people and spread that out but early on, it isn't going to happen and it has nothing to do with being cheap. There will be some companies who will be cheap but everybody wants the most bang for the buck. I don't think that classifies them as cheap.

    CEWII

  • In many industries, separation of duties is a good thing. One reason already discussed is for one developer changing code in dev, while another person (DBA) implements the change in production. But there are many, many other [business] reasons why SOX can save more than it costs.

    Consider the health care industry. What if a single person has access to 'all claims' tables or features. A single person can then enter a [fake] claim, and approve it. Fraud can cost a ton and, unfortunately, happens more than we even realize - even on OUR systems.

    Without a separation of duties policy, many shops may not think of these benefits. It would not be the course of wisdom to allow that to degrade our attitude, complaining about the potential work burden and all of the reasons not to implement SOX or similar. Really though, in the case of fraud, the main reason for implementing a policy may not be for an IT reason. Perhaps we will never know the real reason or know every single benefit.

    But if our company is trying to implement SOX, resisting is not going to change the policy, it would likely irritate everyone else when we throw that wrench in the wheel each day.

    My professional opinion is if a company is too small to properly adhere to SOX, not to discount it, but to investigate it and do the best with what resources are available. Will it be implemented according to the 'letter'? Nope. But it is something. It'll also make future growth easier. Likewise, if our company adopts a similar policy and we are chartered with implementing our part, that it would be wise to do our best without murmuring. It is in the best interest of the company and it's customers.

    Jim

    Jim Murphy
    http://www.sqlwatchmen.com
    @SQLMurph

Viewing 15 posts - 16 through 30 (of 30 total)

You must be logged in to reply to this topic. Login to reply