Your Next SOX Audit Runs on New PCAOB Rules
By Kenio Shirley · · 8 min read
AS 2201 amendments take effect for fiscal years ending on or after December 15, 2026. Here is what actually changes for your ITGC program.
Most SOX programs have a rhythm: controls get tested, deficiencies get rated, remediation happens in the off-season, and the whole cycle repeats against standards that have barely moved in two decades. That rhythm is about to break, and the date is specific: the PCAOB’s amendments to AS 2201, the standard governing the audit of internal control over financial reporting, are effective for audits of fiscal years ending on or after December 15, 2026. PCAOB, AS 2201: An Audit of Internal Control Over Financial Reporting
For a December year-end company, that is this audit cycle. And the change that matters most for technology teams is not procedural — it is how deficiencies get evaluated, which changes what your ITGC gaps cost.
The context: AS 1000 already changed the ground
The AS 2201 amendments did not arrive alone. AS 1000, General Responsibilities of the Auditor in Conducting an Audit, reorganized four legacy standards into a single technology-aware framework and is already in force. PCAOB, AS 1000: General Responsibilities of the Auditor The theme running through both is the same: the Board is rewriting its standards for an environment where financial reporting runs on automated systems, third-party platforms and data pipelines — not on the paper-and-ledger world the originals were written for.
The deficiency question is no longer only “did the control fail?” It is “what did the failure touch, and could it have moved a number?” Automated systems make the second question answerable — and auditors are now required to ask it.
What the AS 2201 amendments change for ITGC
Three shifts deserve your attention before fieldwork starts.
First, a sharper line on severity. The amendments refine how auditors evaluate whether a control deficiency is a deficiency, a significant deficiency or a material weakness — with more disciplined analysis of likelihood and magnitude in an automated environment. For ITGC, this cuts both ways. A failed change-management control on a system that cannot touch the financial statements has a clearer path to a lower rating. A failed control on a system in the reporting pipeline has a clearer path to a higher one. The era of the vague middle, where everything mediocre got rated the same, is ending.
Second, more weight on the auditor’s risk assessment of your technology stack. Expect deeper identification of which applications, databases, interfaces and reports are actually in scope — and more scrutiny of how your organization made that determination. If your scoping is “the same systems as last year,” that answer is aging badly. Acquisitions, replatforming, shadow SaaS and new integrations all move the ICFR boundary, and the amended standard gives auditors both the mandate and the method to challenge stale scoping.
Third, continued convergence on system-generated evidence. Nothing in the amendments rescues the screenshot-and-spreadsheet evidence model. Population completeness — the requirement that the auditor can satisfy themselves your change or access population is complete before sampling from it — is where ITGC audits already failed most often, and nothing in the new standard makes that easier. I wrote a whole article about it because it is the finding nobody plans for.
What to fix in Q4, before fieldwork
If you own ITGC for a SOX-scoped platform, this is the work that pays back immediately under the amended standard:
- Re-run your scoping exercise honestly. List every system that stores, processes or reports financially relevant data — including the integration middleware, the reporting layer and the SaaS tools finance adopted this year. If a system entered or left the boundary in 2026, document the analysis, not just the conclusion.
- Rate your own deficiencies the new way. Take every open ITGC deficiency and re-evaluate it against a simple question: could this gap, unmitigated, have moved a number in the financial statements? If yes, the remediation timeline is not next year’s budget cycle. If no, write down why — that reasoning is now part of the evidence.
- Close the completeness gap on your two most-sampled populations. For most companies that is change management and user access. Reconcile your change tickets against deployment logs; reconcile your access review lists against the identity provider of record. Do it before your auditor asks, and keep the reconciliation — the reconciliation itself is audit evidence.
- Fix segregation-of-duties debt in the ERP and the pipeline at the same time. Under AS 1000’s technology-aware lens, an engineer who can both approve and deploy to a financially relevant system is the same finding whether it lives in Jira or in the general ledger.
The pattern underneath
Step back and the PCAOB is doing what every assurance regime is doing this decade: replacing point-in-time attestation with evidence that traces to systems, and replacing uniform severity with analysis of actual exposure. The companies that will feel this as a non-event are the ones whose ITGC program was already run as an engineering discipline — scoped from architecture, evidenced by systems, rated by what a failure could actually do.
The companies that will feel it are the ones whose program exists to produce the audit rather than to survive it. If that sentence stings, the good news is timing: for a December filer, there is one quarter left, and the fixes above are all quarter-sized. The standard changed. The response is still the boring one — know your boundary, reconcile your populations, and let the systems write the evidence.