SOX ITGC walkthroughs: what auditors trace and ask

What happens in a SOX ITGC walkthrough and who owns each part

A SOX ITGC walkthrough follows one transaction from origination through the company's systems to the financial records, using the documents and people the company actually uses, and auditors use it to confirm that the relevant controls are designed to work. For an IT-dependent process such as revenue billing, journal entry or user provisioning for a general ledger application, the walkthrough traces a single item end to end: where it is created, which application and interfaces touch it, which automated or manual controls act on it, and where it lands in the financial records. The organization owns its controls and the evidence that shows them operating. An implementation partner can help prepare system documentation, configuration exports and evidence packages, but only the independent external auditor concludes on whether the walkthrough supports a design conclusion.

Management's job is to make the walkthrough reproducible. Before the auditor arrives, the control owner should be able to name the application, the module, the interface and the report that carry the transaction, and to point to the approval, configuration or log that proves each control step. Confirm with your auditor which transaction samples they intend to trace, which system owners they expect to attend, and whether they will want screen-level observation or system-generated screenshots. Also confirm that the people who answer questions can speak to the process, not only to a policy document. Gaps found during a walkthrough, such as an interface with no reconciliation or a privileged role nobody can explain, are cheaper to document and disclose internally than to discover during testing.

Expect the auditor to probe at each processing point. Typical questions ask what happens if a record fails validation, who can override a system setting, how a change to the configuration reaches production, and whether a reviewer would notice a missing or duplicate transaction. The auditor's aim is to find where a necessary control is absent or not designed effectively. A walkthrough that combines inquiry, observation and inspection of documents ordinarily supports a design conclusion, and it does not by itself show that the control operated consistently across the year. That operating question is covered by separate testing. Plan your walkthrough notes so each answer points to the evidence that would later be re-performed.

The probing questions auditors ask control owners

During a walkthrough, the auditor follows one transaction through its processing points and pauses to ask questions where a necessary control could be missing or poorly designed. The six areas below are the points where those questions usually land, and each one gives control owners a concrete picture of what the auditor is looking for.

Where data enters the system

Auditors start by asking how a transaction gets into the financial application: manual keying, an upload, an interface feed or an API call. They want to know which fields are validated at entry, who can submit, and whether rejected or incomplete records are caught. Control owners should be able to show the input points on a system diagram and name the control that checks each one.

Where batch jobs and interfaces change data

The next question is where the data is transformed: a scheduled batch job, a currency conversion, an interface mapping or a data load. Auditors ask who owns each job, what triggers it, and how the output is reconciled back to the source. Owners should be ready to show job schedules, mapping logic and the reconciliation report that proves totals agree.

Who can alter the data or logic

Auditors trace which accounts and roles can change records, configurations, or program logic outside the normal transaction path. They look for direct database access, privileged administrator accounts and service accounts with broad rights. Control owners should identify each path, explain how it is restricted and monitored, and show who reviews the activity log.

What happens when processing fails

Auditors ask what occurs when a job abends, an interface drops a file or a transaction errors out. They want to see who is alerted, how failed items are restarted without duplication or loss, and how the team confirms completeness afterward. A walkthrough that stops at the happy path usually leaves this question open, so owners should trace one failure case end to end.

How exceptions are reviewed

Auditors follow exception reports, suspense queues and override logs to see who investigates them, how quickly, and what evidence closes each item. The key question is whether a reviewer with enough knowledge and authority looks at the exception and whether the review is documented. Owners should bring a sample report and the sign-off trail that shows a person acted on it.

Where a necessary control may be missing

Throughout the walkthrough the auditor probes for gaps: a step with no owner, a check that exists on paper but not in the system, or a handoff where nobody verifies the result. Under PCAOB AS 2201, this is how a design weakness is identified before testing begins. Owners should expect to explain each step plainly and admit where a control is informal, since that candor shapes the design conclusion.

How the walkthrough runs from selection to documentation

The walkthrough follows one real transaction from origin to the financial records, so the auditor or management tester can see which controls actually touch it and where they could fail. Each step produces a specific artifact that feeds the design conclusion.

Select a representative transaction
The tester picks one transaction, or a small set, from the population of the process being walked through, usually from a significant account or class of transactions identified in the top-down risk assessment. The selection should reflect a normal path through the process, not an exception. The output is a written record of the transaction identifier, its date, amount and the business process it belongs to, so the same item can be traced again later if questions arise.
Identify the systems and records involved
Starting from the transaction, the tester maps every application, interface, database, report and spreadsheet it touches, from origination through processing to the general ledger or other financial records. This is where IT-dependent steps become visible, such as an automated approval rule, an interface upload or a system-generated report used in a manual review. The output is a system and data flow for that transaction, showing each point where the transaction is created, changed or summarized.
Interview the control owners
The tester asks the people who perform or rely on each control to explain, in their own words, what they do, how often, what triggers the work, what they check and what happens when an exception occurs. Auditors also ask probing questions at important processing points to find where a necessary control is missing or not designed effectively. The output is a set of notes that describe the control as it is understood, including who holds the access and authority to perform it.
Observe the process as it runs
The tester watches the control being performed, either live or on a screen share, and confirms that the steps described in the interviews match what happens in the system. Observation catches differences between the documented process and actual practice, such as a reviewer who approves without opening the supporting report. The output is a note of what was seen, when, and by whom, which is later combined with the inquiry notes.
Inspect the supporting documents
The tester examines the evidence each control produces, such as approval records, system configuration screens, change tickets, exception logs or reconciliation sign-offs, and checks that the evidence shows the control was performed as described. Inspection confirms that the documents exist and contain the information the control requires, rather than relying on the owner's description. The output is a list of documents reviewed, with identifiers and dates, linked to the control each one supports.
Conclude on design effectiveness
The tester compares what was learned against the control objective and asks whether the control, if operated as prescribed by people with the necessary authority and competence, would prevent or detect errors that could cause a material misstatement. Inquiry, observation and inspection together ordinarily support a design conclusion. The output is a design conclusion for each control on the walkthrough, or a noted gap that must be escalated for remediation or further analysis.
Document the walkthrough for re-performance
The tester writes a walkthrough narrative and attaches the transaction trace, control descriptions, interview notes and inspected evidence, so another person could follow the same path and reach the same conclusion. The document is reviewed by a supervisor, and any open questions are closed before the walkthrough is filed. The output is a signed-off walkthrough file that supports the design conclusion and gives the operating effectiveness testers a starting point.

How walkthroughs support design conclusions

A walkthrough supports a design conclusion when it shows that an IT general control, as written and as described by the people who run it, would meet its control objective if it operated as prescribed. Under PCAOB AS 2201, the auditor tests design effectiveness by asking whether the control, operated by people with the necessary authority and competence, satisfies the control objective and can prevent or detect errors or fraud that could cause a material misstatement. For a program change control, that means asking whether the approval, testing and promotion steps would stop an unauthorized change from reaching production, and whether the people named as approvers have the access and authority to give that approval. Paragraph 43 of the standard says design is tested through inquiry, observation and inspection of documentation, and that walkthroughs including these procedures ordinarily are sufficient to evaluate design. The practical point for control owners is that a walkthrough cannot be only a conversation. Each step needs a document, system screen or log that shows the control exists as described.

Auditors reach a design conclusion by comparing what they heard with what they can see. If a change ticket requires approval, the auditor will look for the approval field in the ticketing tool, the approver's role in the access model, and a sample record showing the step performed. Gaps in any of these links, such as an approval that can be bypassed by a system administrator or a reviewer who lacks the knowledge to challenge the change, suggest the control is not designed to meet its objective, even if the team says it always follows the process. Owners should confirm, before the walkthrough, which system screens, reports and configuration settings will be shown, and who will explain each one. Those decisions shape how well the walkthrough supports the design conclusion.

A walkthrough does not, by itself, test operating effectiveness. Paragraph 45 of AS 2201 treats that as a separate test that combines inquiry of personnel, observation of operations, inspection of documentation and re-performance of the control across the period under audit. A clean walkthrough can show a control is well designed and still say nothing about whether it ran consistently in March or October. Management should plan operating tests as a distinct step, select a population and sample method for them, and confirm with the external auditor which of its walkthrough evidence they will rely on. Where the auditor's approach or sample sizes are not yet known, ask the audit team to confirm them in writing before testing begins.

What management, an implementation partner and the auditor each prepare

Management owns the internal control over financial reporting, including the IT general controls that protect IT-dependent controls. Control owners must be able to walk the auditor through a transaction in their own words, name the people who perform each control, and explain what the control is designed to catch. Management also keeps the evidential matter that supports its 404(a) assessment, so the walkthrough has to match what management documents. Before the walkthrough, control owners should confirm the process map, the systems involved and the reports they rely on.

Process ownership: Name the person accountable for each control and the person who performs it, including backups.
Accurate process description: Describe the steps as they run in practice, not only as written in the policy.
System and report inventory: Identify every application, interface, spreadsheet and report that touches the transaction.
Authority and competence: Be ready to explain who has the authority to approve, reject or override.
Exceptions and changes: Disclose known exceptions, recent system changes and open issues before the auditor finds them.

Check that each control owner can explain the control without reading from a script, and that the documentation matches what the system actually does.

What to have in place before auditors walk a process

A walkthrough follows one transaction from origination through systems to the financial records, and auditors ask probing questions at each processing point. The items below are what management should have ready so that the walkthrough tests the controls rather than the team's ability to locate documents.

Current process and system map

Auditors trace a transaction through every application, interface and database it touches, so the map must show the same path the transaction actually takes today. Check it by picking one recent transaction and confirming each system and hand-off on the map appears in its records. Any system that is missing, or any step that happens outside the map, is a design question the auditor will raise. Note the version date on the map and who approved it.

Named control owners who can explain

Each control needs one named owner who can describe what the control does, what triggers it, who performs it and what they do when it fails. Auditors use probing questions at important processing points to find where a control is missing or poorly designed, so an owner who can only point to a policy will struggle. Check this by asking each owner to explain one control in their own words without notes, then confirm they have the authority and competence to operate it.

Sample transactions and system logs

Walkthroughs rely on inspection of documents and records, so the team must be able to produce a sample transaction and its supporting logs quickly, including approvals, system timestamps and user IDs. Check retrieval by timing how long it takes to pull one complete transaction trail from origination to the ledger. If the trail depends on one person's manual export or on logs that roll off before the audit period, fix the retention and extraction process first.

Documented change and job monitoring

Auditors expect to see how changes to the application and scheduled jobs that feed financial records are requested, approved and released, and how failed jobs are detected and rerun. Confirm that the change ticket, test evidence and approval for a recent change can be linked to the production deployment record. For batch jobs, check that the schedule, alert settings and a sample of failure follow-ups are written down and retained.

Interfaces and manual adjustments listed

Interfaces, spreadsheets, manual journal entries and off-system adjustments are where automated controls most often fail to hold, so auditors look for them during the walkthrough. Build a list of every interface that moves financial data, with its owner, frequency and reconciliation control, and a separate list of manual adjustments with their approvers. Check the list against the process map: any hand-off that appears on one but not the other needs an explanation before the walkthrough begins.

Common questions about SOX ITGC walkthroughs

How many transactions does an auditor walk through for a SOX ITGC walkthrough?

The number is set by the auditor's judgment about the process, not by a fixed rule in the standards. A walkthrough follows one transaction, or a small set of representative transactions, from origination through the company's processes and information systems to the financial records. PCAOB AS 2201 describes the walkthrough as tracing a transaction using the same documents and personnel the company uses, so the auditor selects items that show how the process actually runs. Practical drivers include the number of distinct transaction types, the number of systems in the flow, whether the process is manual or automated, and whether prior years showed changes. Ask your auditor early which transaction types they plan to trace, and whether they will accept a sample you prepare in advance.

Can a SOX ITGC walkthrough be done without IT staff?

Not reliably. A walkthrough combines inquiry, observation, inspection and re-performance, and the people who can explain how access, changes and job processing really work are usually in IT. The control owner and the IT personnel who administer the system need to answer probing questions at each processing point. Finance may explain the business flow, but finance cannot confirm how a system enforces a control. Organizations that run walkthroughs with thin IT involvement often end up repeating them. If your team is small, plan named IT contacts, schedule their time before the audit window, and keep a current system diagram so the walkthrough does not depend on one person's memory.

What happens when a walkthrough finds that a control is missing?

The auditor uses the walkthrough to find where a necessary control is missing or not designed effectively, so a gap found here is a design finding. PCAOB AS 2201 asks the auditor to probe at important processing points for exactly this purpose. Management then has to decide whether the gap is a deficiency, a significant deficiency or a material weakness, based on whether it could allow a material misstatement to go undetected. Management may remediate the design before year end, design a compensating control, or accept the finding. Ask the auditor how they will document the gap, what evidence they need to see a fix, and whether a remediated control must operate for a period before they test it.

Does a walkthrough test whether a control operated effectively?

No. A walkthrough primarily supports the design conclusion: whether the control, operated as prescribed by people with the right authority and competence, could meet its objective. PCAOB AS 2201 states that walkthroughs that include inquiry, observation and inspection of documentation ordinarily are sufficient to evaluate design effectiveness. Operating effectiveness requires a separate test that combines inquiry, observation, inspection and re-performance across the period under audit, and it usually needs more than one instance. Some auditors do observe a single item in a walkthrough, which can also contribute evidence about operation, but that single item does not establish operating effectiveness for the full year. Confirm with your auditor which items they will count toward operating effectiveness and which they will not.

How often are SOX ITGC walkthroughs repeated?

Walkthroughs are performed for each significant process and control set in the audit, and they are repeated when something changes that could affect the design of a control. Annual repetition is common in practice, but the standard does not set a fixed cycle. Drivers include system upgrades, changes to access administration, new interfaces, a new ERP module, a change in the process owner, or a prior-year deficiency. Organizations with stable, well-documented systems may need lighter refreshes in later years, while changes to financially significant systems typically trigger a fresh walkthrough. Ask your auditor which changes they consider design-relevant and whether they will rely on the prior year's walkthrough documentation.

Can an outside firm run SOX ITGC walkthroughs for us?

An outside firm can help prepare for and support walkthroughs, but management owns the controls and the walkthrough conclusions. Consultants and co-sourced internal audit teams can map processes, draft narratives, assemble transaction samples and coordinate interviews. The external auditor performs its own walkthroughs and forms its own conclusions, and it cannot hand that judgment to a consultant or accept management's preparation as a substitute for its procedures. DeployOpen prepares systems, controls and evidence for compliance assessments and does not issue audit reports or attestations. Before engaging anyone, confirm with your external auditor what they will accept from a preparer, who will attend the walkthrough and how the scope will be written in the engagement letter.

Where the rules on walkthroughs are written

The walkthrough is defined in PCAOB Auditing Standard No. 5, now codified as AS 2201, which governs how the external auditor tests internal control over financial reporting. That standard describes a walkthrough as following a transaction from the point it starts through the company's processes and information systems to the financial records, using the same documents and personnel the company uses. For IT-dependent processes, this means the walkthrough must reach into the applications, interfaces and reports that carry the transaction, not stop at the business process owner's description. Control owners should read the walkthrough sections of AS 2201 themselves, because their own process narratives are what the auditor will compare against what actually happens.

Management's side of the same work comes from SEC Release 33-8810, the 2007 interpretive guidance on management's report on ICFR. That release explains how management evaluates controls, including the IT general controls needed for other controls over financial reporting to operate properly and consistently. Its role in a walkthrough is to tell management which IT controls matter for a given process, so that the process owner's walkthrough and the auditor's walkthrough start from the same scope. Confirm with your audit committee and external auditor which version of this guidance and which AS 2201 paragraphs they reference in their planning memos, since firms often cite the same material in different ways.

Risk assessment sits upstream of both. PCAOB Auditing Standard No. 12, now AS 2110, requires the auditor to understand the IT general controls important to automated controls, which determines which systems a walkthrough must trace. A practical step is to pull the current AS 2110 and AS 2201 text, map each walkthrough in your process inventory to the systems it touches, and confirm that every system named in a walkthrough also appears in your ITGC scoping. Gaps between those lists are the most common reason a walkthrough has to be repeated.

How DeployOpen works on this

DeployOpen prepares the systems and evidence that a SOX walkthrough follows, from the financial transaction through the applications, configurations and records that carry it. We do not perform the walkthrough, form the design conclusion or issue any report; management owns its controls and the external auditor draws the conclusions.

How we scope

Engagements are fixed-scope, with systems, transaction paths and deliverables agreed in writing before work starts.
We map which self-hosted applications, databases and infrastructure sit on each in-scope transaction path for the walkthrough.
Scope documents list the processing points and personnel that the control owner must be ready to explain to the auditor.

How we build

We configure self-hosted platforms so that automated controls and their settings can be shown and inspected at each processing point.
We build access, change and job-monitoring records so each step of a traced transaction leaves a retrievable artifact.
We document system configurations and data flows in narratives that match what an auditor sees when following a transaction.

How we hand over

We deliver walkthrough packs with transaction paths, system diagrams, configuration exports and the evidence location for each step.
We document the owners of each control and the questions they should be prepared to answer during inquiry.
Handover includes a written record of gaps found during preparation, so the client decides how to remediate them before the auditor arrives.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the initial engagement.
Retainer work can refresh walkthrough packs when a platform is upgraded, reconfigured or moved to a new environment.
Confirm with your auditor which evidence forms and retention periods they accept before finalizing the handover pack.