How to define the scope and extent of work on ITGC for SOX
My congratulations go to Arvind Mehta for his article, ‘An Approach towards Sarbanes-Oxley ITGC Risk Assessment’, in the current issue of the ISACA Journal. I believe it adds value to the scoping exercise; as he says:
“Even after eight years of Sarbanes-Oxley, companies are still struggling to identify the right scope and the appropriate approach toward Sarbanes-Oxley (SOX) IT general controls (ITGC). Lack of knowledge to identify the right scope can lead to an increase in the overall cost of compliance since organizations may test applications that would otherwise be deemed out of scope if an appropriate risk assessment had been performed.”
Mr. Mehta explains that management should “perform a detailed risk assessment that is focused on the risks that are associated with each general controls process area, such as change management, logical access, computer operations, job scheduling, and third party/services organizations that manage applications or data centers.”
Where I differ, or perhaps extend his point, is that before I get to this level of detail I want to ensure I am using a top-down and risk-based approach to defining my scope.
ISACA’s Risk IT Framework correctly states that:
“IT risk is business risk—specifically, the business risk associated with the use, ownership, operation, involvement, influence and adoption of IT within an enterprise.”
In the same way, I would define ITGC risk for SOX as…
…“the risk to financial reporting associated with potential defects in the design and operation of ITGC processes.”
In a top-down and risk-based approach, such as in Auditing Standard Number 5, the risks of material misstatement of the financials is first identified at the financial statement level. The scoping process continues by identifying the key controls relied upon to manage those risks.
The key controls typically include a combination of:
- Manual controls
- Automated controls
- Hybrid controls (for example, the review of a key, computer-generated exception report)
- Reliance on the security of related data
IT general controls can be relied upon for assurance of the continued, reliable operation of the last three items.
But, we are only relying on ITGC with respect to the key automated and hybrid controls, and the security of the related data. Even within the financial system, we are only concerned with ITGC processes and controls if a failure in their operation would likely result in the undetected failure of the key controls relied upon to manage financial reporting risks!
Fortunately, we have a recognized methodology (free to download) that guides managers how to use a top-down and risk-based methodology for scoping ITGC for SOX.
What the ISACA Journal article does is help with GAIT’s phase 3: “Identify ITGC process risks and related control objectives.” It helps assess whether there is a risk to the operation of critical IT functionality through defects in each of the IT general controls processes Arvind mentions. (Of course, the principles still hold if your organization’s processes have different names, etc.)
What I would like to see: as ISACA and the IIA continue to seek ways to cooperate for mutual advantage, I would like each to contribute to a joint team that will evaluate the GAIT methodology for ITGC scoping for SOX. They will assess whether ISACA should join as co-owners and sponsors with the IIA, and how the methodology can be improved – for example, by integrating some of the concepts in Arvin’s fine article).
What do you think?