Hardware fault fixes and SOX compliance 1894

  • Hi,
    Does anyone out there have any info on how SOX affects simple planned hardware fixes as I can’t any info anywhere specifically relating to this.
    Basically my problem is this, a big part of my work is to manage planned hardware fault fixes. This inevitably involves Change Management and they are hitting everything with a big SOX stick and I am finding it increasingly difficult to do my job. The delays caused by this alone threaten my allocated maintenance slots and actually increase the risk to the data.
    If a piece of redundant hardware fails, it is in the companies interests to get that hardware replaced as quickly as possible in case another failure results in data loss. Change management however are insisting that I must provide evidence that I have tested the change somewhere previously. But how can I do this? The chances of having another machine fail previously with exactly the same configuration and having exactly the same component failure are practically zero.
    The thing that really bothers me here though is that I am not actually changing anything really, just restoring the hardware to its optimum configuration. I don’t have a choice about it, I can’t leave it broken as this is more of a risk than not being SOX compliant.
    Surely there must be a better way of doing this, whilst still meeting all the requirements of SOX? Our hardware vendors are paid millions each year and contracted to fix our broken servers we have to trust what they tell us to do. Surely some kind of statement from them that we could attach to the change procedure documentation would be enough to satisfy SOX?
    Thanks in anticipation of any advice.

  • Hi Mike and welcome to the forums 🙂
    The following ideas might help:

    1. General search (avoid vendor ‘sales’ links in favor of SOX articles related to hardware incident management)
      Please add www and paste each link to browser
      google.com/search?hl=en-and-lr=-and-q=SOX Hardware incidents
    2. Specifically, IT related SOX needs fall under SOX 404 and many of the major audit firms use COBIT 4.0 standards as a measure tool for compliancy. Searches on these keywords might be beneficial.
    3. In many respects, SOX 404 compliancy can be vague … Full text of law is noted below in PDF format. It was interesting that I did a search on ‘hardware’ and came up empty.
      Full text of SOX law
      Please paste entire string into browser (www is not needed)
    4. As you noted, it’s important to record indicents in the Change Management and Incident’s reporting systems.
      Change management however are insisting that I must provide evidence that I have tested the change somewhere previously
      However as noted, I also think it’s sometimes unrealistic to perform full tests on replacement hardware. As you replace items, you can test some items (e.g., server, PC, etc.) before bringing them on-line, but even then it’s mainly to ensure the device is operational. Sometimes replacing a faulty hardware device, and ‘throwing the switch’ to turn it on in a production environment is the only prudent solution (as it’s unrealistic to lab test everything). Thus, I’d most likely add a ‘Testing component’ to the checklist and document where it’s unrealistic or there are no parallel testing capabilities. You may need to work with the SOX team and audit, so that there’s a balance between good controls, realism, and not incurring expensive downtime with extra unneeded steps.
      Good luck on this issue 🙂

  • I hear you. Here is what I suggest:

    1. Tailor the change management controls language to ensure that one procedure is not applied to all changes. Some applications have test beds available to perform extensive testing before migration to production but its not the case specially in networks, servers and other hardware. So in this case control should state that testing needs to be performed whenever testing environment is present or can be setup in reasonable amount of time. You can add reasonable assurance from the vendor and no direct effect on integrity of the application or other interfaces to tailor it further if it’s acceptable to the auditors.
    2. Add a monitoring control - what this means is, in absence of testing the change will be monitored for extended duration then the normal change. So you need to monitor the replaced hardware for some more time then normal.
    3. Back off procedures are must for the changes with no testing. This reduces the risk of further damage associated with change.
      Add 2 3 and you have some reasonable way of preventing the risk to the application due to change.
      Hope this helps.

Log in to reply