I can't understand why I am limited by SoX? 1949
bchalker last edited by
Started at a company with over 10k employees and bound by SoX. I’m the webmaster of the site. I have a skill set heavy on design, but based on HTML/JS coding.
Our structure is set up as:
- Development server
- Staging server
- Production server
The site is NOT dynamic, in general. All pages are manually updated. We do have an e-commerce setup on part of the site, and a legal/investors page with PRs and info.
Why am I only allowed to push to the Dev and Staging server, but not Production? I mean ANY push. I change content (fix a word, add a graphic, etc.), and I have to put a ticket in to IT Security to push live. The is NO approval or discriminating that goes on…just a push of the pages I request.
The reason, I’m told, is SoX, and the ‘segregation of duties’. Does this actually apply in my case?
kymike last edited by
SOX would not apply if you are not touching anything that could your company’s financial statements. That being said, it is generally easier to apply good segregation of duties policies to all processes than to just the financial processes.
From a good control perspective, who is to say that you will not make more substantial changes than a simple word or spelling correction? Controls are in place to prevent what could happen versus what a trusted employee might do.
This may seem like bureaucracy, but is best practice.
Chhaava last edited by
You are on the dot.
Denis last edited by
It is possible that this is a valid position and it is equally possible that it may be an overcautious position. I don’t know enough about the specific situation to comment with authority.
It may apply depending on how well you can differentiate between the ecommerce part of the site and the rest. If access to update the ‘brochureware’ part of the site also allows access to the ecommerce portion then this would represent a possible financial reporting risk. If it was only an informational website one would be hard poushed to justify this under the guise of SOX - though as Mike says it would still be best practice.
Ultimately what SOX requires is for management to identify risks to financial reporting, design controls to meet them and report on the effectiveness thereon. SOX specifies the thought process that management must go through but does not mandate any particular judgements or actions. If management determines that this is a risk that needs to be controlled then they have done this is response to their wider SOX obligation not a specific requirement.
Added to this mix is a requirement to keep the auditor happy which can lead to overcontrolling a process.
harrywaldron last edited by
Hi and welcome to the forums
I’ve also been some web development for about a decade or so, and can relate to the need sometimes to expediently fix small text issues v. a major rollout of an entire site.
Here’s some quick thoughts:
- The use of term ‘SOX’ might have been used out of context, if the entire website is devoted to non-financical content. Although sometimes even sites that don’t have financial content might be indirectly used for referiential needs or other business requirements?
- Still, it’s a good practice to formally promote code through a change management, as it must formally go through procedures and provides backups in case something isn’t copied correctly or fails in production.
- IT is most likely not going to change their mind on these types of source management controls (we have to do the same thing in our company also). Accountability, audit trails, and release controls may hinder development but after a while I’ve found ways to adapt and work within the system to the best of my abilities. Certainly, management should streamline the process where they can to promote efficiencies.
- It’s beneficial to also ensure your system is efficient and that folks are there 24x7 or as needed to release content. The change management process should be efficient or it will be more burdensome to develop and release application changes.
- One idea also if there is a need for expedient production repairs is to use an emergency account (sparingly), so that content can be quickly fixed and then released as needed.