ITGC scoping from business process walkthroughs: a practical method

Ask a SOX team how they scoped their ITGCs and you'll usually hear some version of "the same applications as last year, plus the new ERP." Ask why those applications and not others, and the answer gets vaguer. That vagueness is where scoping gaps live — and scoping gaps are the deficiency category external auditors have gotten noticeably more aggressive about, because PCAOB inspections keep hammering firms on IPE and automated-control reliance.

There's a method that closes the gap, and it isn't new — it's implicit in how the audit methodologies are written. What's rare is doing it systematically: deriving ITGC scope bottom-up from business process walkthroughs, so that every in-scope application traces to a specific reliance, and every reliance traces to coverage. Here's the method in practice. (Disclosure: I build a tool, SoxDesk, that automates this structure — but everything below works in a spreadsheet too, and the method matters more than the tooling.)

The core idea: scope is a chain, not a list

Traditional scoping treats the application list as the starting point. The bottom-up method treats it as a derived artifact. The chain is:

Business process walkthrough → IT dependency → application → ITGC coverage

Each link answers a question:

• The walkthrough answers: how does this process actually run, and where does it lean on systems?
• The IT dependency answers: what specifically are we relying on? Not "SAP" — a named thing: this report, this automated control, this interface, this calculation.
• The application answers: where does that dependency live?
• The ITGC coverage answers: what gives us comfort that the application is well-managed enough for the reliance to hold — access, change management, operations controls?

If you can walk every link of that chain in both directions, your scope is defensible by construction. Let's build it.

Step 1: mine the walkthroughs for dependencies

During each business process walkthrough (order-to-cash, procure-to-pay, payroll, close), you're already documenting the flow. Add one discipline: every time the process touches a system, classify the touch as one of four dependency types:

1. Report / IPE — information produced by a system that a control (or your own testing) relies on: the aged trial balance, the three-way-match exception report, the user access listing itself.
2. Automated control — the system enforces something: tolerance blocks, mandatory fields, posting-period locks, approval routing.
3. Interface — data moves between systems and completeness/accuracy of the transfer matters: the sub-ledger-to-GL feed, the payroll file to the bank.
4. Calculation — the system computes something material: depreciation runs, standard cost roll-ups, revenue allocation.

Give each dependency a name and record which walkthrough surfaced it. The four-type classification isn't bureaucracy — each type implies a different testing consequence. An IPE dependency means someone needs to address completeness and accuracy of that report. An automated-control dependency means someone is (or should be) baselining that control and relying on change management to carry the conclusion through the year.

A useful field discipline: if the walkthrough narrative uses a verb like "the system calculates/blocks/generates/transfers," a dependency should exist. Auditing your own narratives for those verbs is a fast completeness check.

Step 2: resolve dependencies to applications

Every dependency maps to the application (or applications — an interface has two ends) it lives in. This step sounds trivial and isn't, for two reasons.

First, it builds your application inventory from evidence rather than from memory or IT's CMDB. Applications appear on the list because something relies on them — which means each one arrives with its justification attached.

Second, it surfaces the awkward middle tier: the reporting warehouse between the ERP and the report, the RPA scripts, the department-built Access database that turns out to feed a key reconciliation. Top-down scoping misses these because nobody thinks of them as "applications." Bottom-up scoping catches them because the dependency chain runs through them.

Step 3: make the scoping decision explicit, per application

Now — and only now — decide scope. For each application, record one of three statuses, each with a written rationale:

• In scope: dependencies on it are significant enough that ITGC comfort is required.
• Out of scope: dependencies exist but are addressed another way — the classic example is deciding to treat a report as unreliable and have the control owner verify it manually each time, or where the dependency is immaterial. Write down which mitigation, because your external auditor will ask.
• Pending: dependencies rely on it but no decision has been made yet. Naming this state explicitly matters — the most dangerous applications in any scoping exercise are the ones nobody has decided about, silently treated as out of scope by default.

Step 4: map ITGC coverage — and check it both ways

For each in-scope application, link the ITGCs that cover it: access management, change management, IT operations, as your risk assessment dictates. Then run the two reconciliations that make this whole method pay off:

Reconciliation A — scope without coverage. Any application marked in-scope with no ITGCs linked to it is a gap. This is the finding external auditors love: "management identified the application as in scope but had no controls addressing it."

Reconciliation B — undecided reliance. Any application with dependencies pointing at it but scope still pending is an open risk decision. Age these; a "pending" that survives past interim testing is a problem.

And a third check that separates a living scoping model from a memo: coverage should reflect test status, not just linkage. An in-scope application "covered" by a change-management control whose test failed isn't covered — it's an evaluation question (does the ITGC failure undermine the automated controls and IPE relying on that application?). You can only ask that question quickly if the chain from failed ITGC back to dependent business controls is traversable.

Step 5: keep it alive through the year

The chain isn't an annual memo; it's a data structure that earns its keep at exactly three moments:

• When a system changes mid-year (migration, upgrade, new interface): walk forward from the application to every dependency and walkthrough relying on it — that's your impact list for re-walkthrough and re-baselining decisions.
• When an ITGC fails: walk from the control to the application to the dependencies — that's the population for your reliance-impact evaluation, on paper in minutes instead of a week of archaeology.
• At roll-forward: next year starts from this year's chain, and the update discipline is "what changed," not "rebuild the map."

Doing it in a spreadsheet vs. doing it in a tool

You can absolutely run this method in Excel: a dependencies tab (walkthrough, name, type, application), an applications tab (status, rationale), a coverage tab (application → ITGC), and lookup formulas for the two reconciliations. Teams do it, and it's far better than list-based scoping.

The failure mode is maintenance: three tabs of manual keys drift, the reconciliation formulas break when someone inserts a row, and by year-end the model reflects March. This is the part SoxDesk automates — walkthroughs, dependencies, applications, and ITGC links are one linked structure with the drill-back built in, uncovered in-scope apps and undecided pending apps flagged automatically, and coverage showing the live status of the covering control's actual test. But to be clear about the order of operations: adopt the method first. A tool can only automate a discipline you've decided to have.

If you'd rather see the structure working than build the tabs, SoxDesk's free 60-day trial ships with a sample SOX audit that has the full chain populated — walkthroughs through dependencies to flagged coverage gaps. It runs entirely on your own machine (nothing leaves your network), so trying it is an afternoon, not a procurement.