Web Content - SOX???? 1279

  • We’ve been using SOX for a while but as many have stated, the IT section is very vague. I believe our nagement and/or the auditors have taken it a bit too far.
    I maintain the content for an ecommerce web site. We have page code in a source control software as I feel it should be with code. Content (text, graphics, etc.) are not.
    Today I ran into an issue I can’t believe. I updated the copyright in the footer of our site from 2005 to 2006. One number changed. No code. Management actually said I needed to complete the paperwork to move it to production.
    Does anyone know if SOX requires web content to have piles of paperwork completed? I feel it should just be for code updates/changes.

  • How can the system tell the difference between you wanting to change only one number and you wanting to put inappropriate content on the website?
    I guess, in case you have proper controls over changes on your website, then you have to go through the formal process EVERY time you change something on the website - even a single character.

  • There are no SOX-specific rules for IT. There are, however, best practice guidelines (COBIT). Your company must determine what its policy is in relation to changing production programs. Failure to follow those policies would constitute a SOX deficiency. In this case, it sounds like the policy is to have certain paperwork completed prior to making changes to your production environment. You should follow those guidelines.

  • In addition to the comments and feedback from the other individuals on this forum, some online guidance over Change and Patch Management can be found at:
    An excerpt from the site URL listed above:
    Guide 2: Change and Patch Management Controls: Critical for Organizational Success
    With the impact of business process outsourcing, ERP implementation failures, and changes in the regulatory requirements such as Sarbanes Oxley Section 404, The IIA recognizes that guidance on IT change and patch management is urgently required. Change and Patch Management Controls: Critical for Organizational Success is the second in the GTAG Series. Why has The IIA chosen to provide guidance on this subject?
    This publication is about managing risks that are a growing concern to those involved in the governance process. Like information security, management of IT changes is a fundamental process that can cause damage to the entire enterprise and easily disrupt operations if it is not performed well. This enterprisewide impact makes change management of interest to many audit committees and, as a result, to top management.
    The objective of this guide is to convey how effective and efficient IT change and patch management contribute to organizational success. The target audience is CAEs, their peers, and their staff. Because audit’s role requires it to assess risks and provide assurance to the organization, auditors cannot ignore the potential impact that changes to information systems and other IT assets can have on business operations. More importantly, this guide will give readers the necessary knowledge to help them counsel their boards about change-management risks and controls and to help their organizations comply with constantly changing regulatory requirements.

  • I agree that even date changes for the underlying HTML code most likely needs to be controlled through a promotion process to production (i.e., esp on an e-commerce web page). These types of release should be performed through an efficient process, so that they are not a tedious endeavor to make.
    For example, email and particularly work flow tools should be used in lieu of physical ‘paperwork’ to create an efficient change management process, plus save a few trees along the way 😉
    The SOX compliancy designers need to balance good controls with efficiency to avoid creating bottlenecks in the processing flow. Also, a highly inefficient process will lead to folks taking shortcuts and trying to circumvent the system.

Log in to reply