Scope creep is happening because data architectures are evolving, moving from centralized, ERP-centric systems to distributed, dynamic, data-centric architectures.

Here’s a typical scenario: A SOX control owner creates a new report that pulls from a data lake. 

It’s a great solution for what they need, so they integrate the report into their financial decision-making. 

But they don’t realize the potential financial statement implications until the auditors start asking, “Where did this data come from? How do you know it’s complete and accurate?”

SOX teams are seeing this more often. That’s why SOX Leaders Toby DeRoche and Jason Winter led an April 2026 Internal Audit Collective webinar looking at why and how ITGC scoping is changing and the risks and control considerations introduced by data platforms. (Toby is also the instructor for the Collective’s SYNERGY course, designed to help any auditor level up their IT audit skills.)

Read on to help your SOX program keep its ITGC scope and testing on track. 

Why ITGCs for Data Platforms Are Becoming More Important

As Jason explained, in traditional ERP systems, SOX-relevant data lives and is processed inside controlled, monolithic environments. Accordingly, ITGC testing scope centered around the ERP — and ERP systems are typically governed by well-defined ITGCs.

But as companies modernize their tech stacks, they’re often embracing more distributed architectures (e.g., cloud, data lakes, data warehouses). 

That means SOX-relevant data is now being enriched, aggregated, calculated, transformed, and reconciled across different data platforms.

But these platforms are often self-serve and accessible to anyone in the business. With so much data and so many new reporting tools available, business users are accessing and using data in new ways.

“I’m finding, with data lakes in particular, that we often have surprises in SOX, where something new is in scope that we didn't anticipate,” said Toby. “They’re pulling information that we didn't know would be used for financial purposes — but suddenly it is.” He gave the example of a user referencing operational data that could influence an estimate that might lead to an accrual.

“They don't necessarily realize that their solution pulls data for an in-scope process or SOX control,” explained Jason, “So they’re not realizing that the report or data also needs to be controlled for SOX.” And now there’s a new ITGC, ITAC, or IPE in play that the SOX team didn’t anticipate. 

Data platforms are also getting more scrutiny from External Auditors and regulators. SOX teams need to be ready to answer a range of questions around the accuracy, completeness, reliability, and traceability of data originating there.

Understanding the SOX Implications of Different Data Platforms

Data lakes and data warehouses are often part of tech transformations because they:

• Offer a mechanism to store massive amounts of data from various sources in different formats
• Facilitate data analysis and operational and/or financial reporting

In short, data lakes are flexible repositories for unstructured data, while data warehouses house more structured data (e.g., BI, analytics). The table below has more details. 

Key Considerations for Scoping ITGCs for Data Platforms

1. Categorize the Data Platform’s Role

ITGC scope depends on how platforms are used. So, to hone in on data and/or data flows tied to specific SOX controls or financial statement assertions, start by classifying platforms based on functionality. As Jason and Toby detailed, key categories and considerations include:

• System of Record (SoR) — These authoritative sources are where transactions are initially booked and stored (e.g., ERP GL, subledgers). Because changes here directly impact financial statements, SoRs have high requirements for ITGCs and ITACs.
• System of Aggregation or Computation — These platforms are where data from multiple systems is joined, transformed, or enriched and where calculation logic may live (e.g., cloud data warehouse staging and curated layers, data lake with standardized transformations). Accordingly, these systems typically require ITGCs around access and changes, and ITACs around reconciliations and logic validation.
• System of Reporting or Presentation — These tools sit on top of SoRs or aggregation layers to visualize or present information, usually without complex, material transformation (e.g., BI dashboards, reporting tools with basic filters/sorting). IPE and reporting controls tend to be important in these layers. But if no transformation happens, there can be less emphasis on heavy ITGCs. 

2. Establish Clear Ownership 

ITGC scoping starts with governance, including understanding who owns the data platform and SOX-relevant data sets, who should have access, and who users are. 

But as Toby shared, “It can be really hard to get an answer. Because by its very nature, the data platform spans so many different teams, groups, and use cases, and people are using it however they need to in the organization. So you may end up with what looks like multiple ownership groups.” But at some point, you need to be able to name who’s ultimately responsible. 

Without clear ownership, access controls break down, accountability is diluted, and change management becomes even more challenging.  

3. Map the Data Flows to Refine Scope

Traditionally, SOX scoping requires following the transactions to make sure the appropriate controls, risks, and financial statement assertions are covered. Now, auditors also need to understand how specific data elements and data flows play into scoping.  

That’s why Jason and Toby recommend diagramming the data flows beneath your business process flows. Said Jason, “It’s like peeling back the layers of an onion, making sure you’ve got the appropriate SOX scope related to those significant financial statement line items,” splitting out operational data and building an inventory of SOX-relevant data sets and pipelines. 

As Jason stressed, you need to be able to explain to your External Auditor why certain data or use cases are or aren’t in scope. Mapping the data lineage from end to end helps you do that. 

Mapping data flows can also help your own organization get a handle on the SOX implications of different data platforms. 

For example, Toby’s team recently did a high-level exercise with the company’s IT team, business process team, and External Auditor “showing them how data flows, from coming into the organization all the way through to the financials in very simple terms.” They layered the data lake on top, showing where it sits and how the data undergoes various transformations in the lake. That helped all parties better understand scope and narrow down user access reviews (UARs). 

As Toby pointed out, while this doesn’t change his team’s control work, it does change External Audit’s testing scope: “It’s refining their understanding of what’s actually critical to the organization from a SOX point of view… they can see it's not as big as they were thinking. It's actually a pretty clean path that we pass this data through.” 

4. Examine Access, But Focus on Change Controls

When looking at access, focus primarily on privileged users who can make changes and impact security. Essentially, you want to:

• Identify who can change the data, logic, or code. 
• Drive role-based access and segregation of duties.
• Consider baseline controls such as multi-factor authentication and periodic access reviews scoped to SOX-relevant data sets. 

5. Continuous Monitoring Is Crucial 

Again, the broad, unstructured access enabled by distributed data architecture greatly increases the potential for SOX scope creep. So it’s not enough to check in annually. SOX teams need to put mechanisms in place to help them continuously identify new reports and data usage. 

On a quarterly basis, Toby’s team asks SOX control owners, “Have you pulled in any new data? Have you changed your report? Where does the data come from?”

In particular, Toby and Jason recommend closely monitoring administrators’ activity. Because admins can bypass standard controls, gaining assurance that admins didn’t make unauthorized changes becomes a key focus. Accordingly, effective controls are needed around logging admin activity, reviewing logs periodically, and detecting unauthorized or anomalous changes. 

THE LAST WORD: Time to Get a Better Handle on ITGCS

Toby and Jason’s webinar covered several more common challenges and key considerations. But the reality is… it gets technical. 

For example, they discussed the challenges of understanding change management in data platforms, given that changes often occur via code repositories, development pipelines, and non-UI-based queries — making it harder for auditors to interpret, and harder to explain to SOX stakeholders. 

But the technical bent only reinforces one of the Internal Audit Collective’s core messages: The auditors of the future are “triple-threat” auditors with competencies in analytics/AI, IT audit, and innovating traditional audit. 

If you’re committed to building your triple-threat capabilities, consider:

• SYNERGY, our 16-CPE IT audit training program, helps any auditor develop the competency to audit IT systems, applications, and controls. As one grad attested, “The practical focus — including top-down risk assessments, IT SOX scoping business cases, and real-world examples — made the content immediately applicable.” The next program begins July 7, 2026. 
• SOX Accelerator, our 16-CPE SOX leadership program, gives SOX leaders (or soon-to-be leaders) the tools they need to lead a world-class SOX function — including a robust focus on contemporary considerations for managing, testing, and scoping ITGCs. Since the current program just kicked off, the next program begins September 2, 2026.

Plus, both programs come with a one-year membership to the Internal Audit Collective. So if you’ve been dragging your feet on joining, why not feed two birds with one scone?

‍