SOX Section 404(b) has not changed since the PCAOB issued AS 2201 in 2007, and Section 302 certification requirements look roughly the same as they did in 2002. What has changed, this cycle and the last few, is the context in which those requirements operate. Cloud migration has redrawn the ITGC landscape. Automated controls are now routine where manual controls were once the default. And the documentation tools available to internal audit teams have expanded enough that external auditors are starting to have opinions about how evidence is presented, not just what evidence exists.
For internal audit teams preparing for or in the middle of their 2026 SOX cycle, the baseline compliance requirements are well understood. This piece focuses on the operational shifts that matter most right now: what has changed in ITGC scope, where documentation expectations are tightening, and where new tooling creates both opportunity and additional complexity.
ITGC Scope in a Cloud-Heavy Environment
The four traditional ITGC categories under SOX remain standard: access to programs and data, program change management, computer operations, and program development. What has shifted is the distribution of evidence across those categories when the infrastructure is primarily cloud-hosted.
Access controls that used to live in on-premise Active Directory now live in cloud identity providers, and the evidence to support them looks different. A user access review under SOX historically meant pulling a provisioned user list from the directory and comparing it to an HR termination report. In a cloud environment, that evidence may come from an identity provider's audit log, an SCIM provisioning report, and a role assignment export from a SaaS platform, none of which are naturally formatted for easy workpaper inclusion. Teams that have not updated their PBC templates for cloud-native evidence formats are asking control owners for documentation the owners cannot easily produce, which is one reason evidence collection timelines have stretched in the last few cycles.
Change management controls face a similar translation problem. ITGC change management evidence in an on-premise environment typically meant documented change request approvals and deployment records. In a CI/CD pipeline, approvals live in merge request metadata, deployment records live in release automation logs, and the approval workflow may involve automated quality gates rather than human sign-offs on a change ticket. The control objective is the same: ensure that only authorized changes reach production. The evidence package looks completely different, and the workpaper documentation has to bridge that gap clearly.
PCAOB AS 1215 requires that workpapers contain sufficient information to support the conclusions reached. For ITGC workpapers covering cloud-hosted controls, this means being explicit about what each piece of evidence demonstrates and what the auditor did to confirm its completeness. Population completeness assertions for cloud log exports require a different kind of evidence than population completeness for a database query, and the workpaper should explain what was done to establish that the export was complete.
Key Reports and Automated Controls
Management review controls (MRCs) and key reports have become a significant area of focus as more financial reporting processes depend on automated outputs. When a key financial report is generated by an ERP system or a reporting tool, the SOX workpaper for that control needs to document not just that the report was reviewed, but that the underlying system and data inputs are reliable. This is called IT-dependent controls testing in practice, and it is where ITGC work and financial control work intersect most visibly.
For a SOX team, the practical implication is that testing a management review control over a key financial report requires coordination between the financial control workpaper and the ITGC workpaper for the system that generates the report. If access to that system is tested and documented under ITGC, and if change management over that system is tested and documented under ITGC, those results should be cross-referenced in the MRC workpaper. This cross-referencing is often done informally or not at all in manual workpaper processes, which is a documentation gap that external auditors have been flagging more frequently.
Test of design versus test of operating effectiveness is another area where documentation precision matters. A test of design establishes that a control is theoretically capable of preventing or detecting the relevant risk. A test of operating effectiveness establishes that the control actually operated as designed during the period under audit. These are different procedures with different evidence requirements. Workpapers that blend the two without distinguishing them create review ambiguity, and in a year when external auditors are working through their own documentation requirements under PCAOB, they are less tolerant of ambiguity than they were a few years ago.
Where Documentation Expectations Are Tightening
External auditor reliance on internal audit work under AS 2605 requires that the internal audit documentation meet a quality bar the external auditor can independently assess. This has practical consequences for workpaper formatting and completeness. External auditors are not just asking "did you test this control?" They are asking "can we follow your work without asking you to explain it?"
Tickmarks and cross-references are the most visible place where quality gaps show up. A tickmark that says "agreed to source" without specifying what source, or a workpaper that refers to "the access report" without specifying which report, from which date, pulled by whom, is technically compliant with AS 1215 in that it represents the auditor's documented conclusion. It is not helpful documentation from a reliance perspective. Teams that have historically written workpapers for internal use rather than external reliance are finding this cycle that their documentation standards need to step up.
SOD (segregation of duties) testing is another area where documentation completeness matters specifically. An SOD control workpaper needs to document not just the test procedure but the conflict definitions used, the system access levels reviewed, and the population of users reviewed. If any exceptions were found, the workpaper needs to document the compensating control review. Shorthand entries like "no conflicts found" without supporting evidence of what was reviewed are a review comment risk in a way they were not five years ago.
What This Means Operationally for Your Team
For teams running their 2026 SOX cycle, three operational areas deserve attention before fieldwork gets underway. First, PBC templates: have they been updated to reflect cloud-native evidence formats? A PBC line item that asks for "provisioned user list" should specify the source system, the export method, and what fields are needed. Vague requests produce inconsistent returns, and inconsistent returns require follow-up that consumes senior time mid-cycle.
Second, control-to-evidence mapping clarity in the workpaper format. Before the team starts collecting evidence, each workpaper section should specify exactly what evidence is expected for that control, what the auditor will do with it (inquiry, inspection, reperformance), and what a satisfactory conclusion looks like. Building this clarity at the front of the cycle rather than reconstructing it during workpaper assembly at the end saves time and reduces review comments.
Third, rollforward procedures. Controls that were tested and passed last year still require current-year evidence of operating effectiveness. The rollforward should be explicit about what was carried over from prior year and what was tested fresh. Workpapers that implicitly rely on prior-year results without documenting the rollforward decision are a documentation deficiency, not a substantive failure, but they create unnecessary review friction.
None of these are new compliance requirements. They are operational discipline areas where the gap between current practice and documentation standard is widening, and where closing that gap this cycle is more valuable than explaining the gap later.