SOX controls versus Non-SOX controls 1267

  • My firm is trying to determine the best approach to manage control activities that are non-SOX, but part of the COBIT control framework.
    Currently, many control activities are part of the control framework, but as they are non-SOX, they are not given much attention at this point. Of course, SOX objectives and activities are taken very seriously and rigorously practiced, documented, and audited.
    Now that SOX is becoming more controlled, we are trying to determine how important it is to us to rely on these non-SOX control objectives and activities. Should we enforce the same SOX-like rigor to non-SOX control areas? Should we divorce them completely from the SOX control framework so we don’t dilute the attention on SOX? Or find a solution somewhere in the middle? Of course, SOX folks want NOTHING to do with non-SOX control activities, and want them out of their space.
    As we wrestle with this question, I’m trying to find out what other companies are doing who may have faced similar questions. Any feedback would be greatly appreciated.

  • Can you give some general examples of the non-SOX control activities that people don’t want to have structure around? I would agree that the same level of documentation and testing should not be required, but good business practice would suggest that these controls, if significant to the company operations, should be followed. Instead of regular peer testing, your internal auditors should periodically review these controls to ensure that they are effective.

  • Thanks for the response. One example of non-SOX controls would be those related to business continuity planning. This is an important area, but not within SOX scope. Activities supporting this would include, for example:

    • All critical information technology assets are identified and prioritized for recovery.
    • A written recovery plan for local financial systems and the systems that feed or support the financial systems is prepared and approved by local management (i.e., general manager, IT director, and controller), the divisional IT leader, and the vice president of technology operations.
    • Key team members of the recovery team maintain copies of the plan off-site and at the office.
      I agree with your opinion about following these activities, and periodically auditing against them. The concern relating to SOX compliance is that including too many non-SOX activities (BCP, Hardware Support, Support Agreement oversight) in the control framework dilutes the attention on SOX.

  • Your management team needs to take a position as to which of the non-SOX items they feel are critical to the business and where they are willing to take risks. They do need to know what ‘best practice’ is and where there are gaps to best practice.
    SOX is a subset of our total control environment, but seems to be driving our actions and decision-making. I can see why that is with severe penalties for non-compliance.
    Make certain that the decisions as to what non-SOX control activities are expected to be performed and how your company ensures that what is expected to be done is being done is being made at the right level (i.e., executive level).

  • Thanks kymike - you described exactly where this is headed in the upcoming quarter. Executive decision making on what’s important that is non-SOX, and how aggressively they want to enforce/oversee.
    It does seem unwise to ‘separate’ your SOX control framework from your non-SOX control framework.
    Thanks again.

Log in to reply