Mobilizing The PCI Resistance, Part V: The GAIT Vision For Solving The SOX-404 IT Scoping Problem
This is Part 5 of the "Mobilizing PCI Resistance" series. Briefly, we've covered:
- Part I: "Upset about the subjectivity and ambiguity in the PCI DSS compliance standards? My #BSides submission on the answer..."
- Part II: "The problems that management and auditors faced in 2005 and 2006 for the IT portions of SOX-404."
- Part III: "Quantifying the huge amount of wasted IT audit effort in SOX-404"
- Part IV: "What goes wrong in a bottom-up SOX-404 audit: a cautionary tale..."
Okay, enough on the problem. Let's talk about the solution....
What We Wanted GAIT To Achieve
So, what was our vision in January 2006?
- Enable auditors and management to appropriately identify and link assertions to IT activities and processes, and then appropriately scope relevant IT controls work
What we wanted to achieve provide was a way for auditors and management to precisely scope what in IT mattered for the achievement of SOX-404 objectives. Or put more precisely, to link internal control objectives for financial reporting to specific IT functionality.
And then only audit those things. Instead of carpet-bombing/auditing everything in IT. - Provide a common context for management and auditors to support and test management’s assessment that the necessary IT controls exist and are effective
Initial target is internal control objectives for financial reporting, but should extend to operating effectiveness and complying with laws and regulations (as defined by COSO)
What we were suggesting here is that "SOX-404 is only the beginning. The same principles could be applied to the other COSO objectives: security, compliance with laws/regulations/contractual obligations."
(Look, it's the PCI DSS!!!)
And Stopping The Madness Of "See, This Audit Deficiency Didn't Really Matter!"
Lastly, shown above is what is known as "Chart 3" of the "A Framework For Evaluating IT Control Deficiencies" document, authored by the nine CPA firms that did SOX-404 audits or advisory work, as well as Dr. William F. Messier, Jr.
Basically you would have to dig out this chart for every IT deficiency to try to wiggle out of a material weakness. You would go through this decision tree to decide whether the deficiency would result in a material weakness, a significant deficiency or just a deficiency.
Just so at the end you could say, "See? I told you so! That audit finding isn't really important."
Trouble is, to arrive at that decision took man-weeks of work. Why was the test performed in the first place?
Our observation is that if you were spending lots of time going through Chart 3 for all your IT findings, only to find that they wouldn't result in a material weakness, it was a scoping error. So, GAIT would enable you to do this thinking up front, during scoping, so that we would only perform those tests that would result in an undetected material weakness.
In my next post, I intend to write about the constituencies and politics of getting GAIT approved by all the parties:
- internal auditors
- IT management
- security/compliance management
- professional organizations: IIA, ISACA, FASB
- enforcement organizations: PCAOB
I'll talk about how we assembled the constituencies, what was in it for them, and how I learned to use one of the most valuable tools in my career.
And then I'll start talking about the GAIT Principles, and how we're extending it towards application towards PCI DSS.
(Many were fellow committee members with me at the Institute of Internal Auditors. In the next post, I'll describe why we had assembled the specific players in the room: SEC publicly held companies, their audit engagement partners from the Big Four, as well as their respective national practice leaders, the Institute of Internal Auditors, and the PCAOB.)
Reader Comments