What a SOX ITGC consultant does and what it costs

A SOX ITGC consultant helps management scope, design, remediate and evidence IT general controls, but the company owns the controls and only the external auditor attests. This page explains the work, the cost components and the independence line.

On this page

What does a SOX ITGC consultant cost, and what do you get for it?

Outside vendor fees for Section 404 work vary widely, so a budget owner should plan around scope rather than a single number. The SEC's 2009 study of Section 404 costs reported that the mean outside vendor fee for companies with auditor attestation fell from $438,000 before the 2007 reforms to $311,000 after them, and the median fell from $100,000 to $90,000. Those figures are more than fifteen years old and reflect the filers and systems of that period, so they show the shape of the spending, not what a current engagement will cost. The same study found that internal labor could make up more than half of total compliance cost for these companies, which means the outside fee is often the smaller part of the budget. The company owns its controls. A consultant or implementation partner can define ITGC scope, design and document controls, support remediation of failed controls and assemble evidence, but management must perform and monitor those controls and sign the assessment. Only the independent external auditor attests, and only where Section 404(b) applies. When requesting a quote, ask the consultant to itemize work by phase (scoping, design, remediation, evidence preparation and testing support), to state which systems and locations are covered, and to say how many control owners and walkthroughs the price assumes.

Cost drivers are predictable. The number of financially significant applications, the number of databases and infrastructure layers, whether systems run in cloud or with service providers, the maturity of existing documentation, and the number of deficiencies found in the prior year all move the price up or down. One-time work includes the initial scoping, control design and remediation of gaps. Recurring work includes periodic access reviews, change sampling, evidence collection for each fiscal year and updates after system changes. Ask whether the quote covers a first-year build only or an ongoing run, and whether re-performance after a failed test is included or billed separately. Confirm the independence line before you sign anything. If your external audit firm would design, operate or assess the same ITGCs it is auditing, the work may be barred under SEC independence rules, so the consultant should be a separate firm from your auditor. Get the scope, deliverables and timeline in writing, and ask the consultant to show how evidence will be prepared so that the auditor can test it independently.

Who is paid for what in SOX ITGC work

This table compares who is paid for each part of SOX ITGC work, whether the cost is one-time or recurring, and what drives it up. Read it as a map of cost components, not a budget, since the 2009 SEC study found internal labor could exceed 50 percent of total Section 404(b) compliance cost, with outside vendor fees as one component among several.

Who is paidOne-time or recurringMain cost driver
External auditor (attestation fees and ICFR share of audit fees)Recurring each fiscal year where Section 404(b) appliesScope of ICFR testing, number of IT-dependent controls and deficiencies found
Implementation or consulting partner (scoping, control design, remediation, evidence support)Mostly one-time for design and remediation, periodic for testing supportWritten scope, number of systems and locations, and the state of existing controls
Co-sourced internal audit firm (independent testing support)Recurring, usually tied to the annual testing cycleNumber of ITGC areas tested, sample sizes and whether interim testing is included
Tooling and licenses (identity, ticketing, GRC or evidence platforms)Recurring subscription or support, plus one-time setupNumber of users, systems integrated and whether the tool is self-hosted or hosted by a vendor
Internal staff time (control owners, IT, finance and management review)Recurring every control cycle, often the largest shareControl count, manual versus automated evidence and quality of documentation

What makes a SOX ITGC engagement cost more or take longer

Most of the effort in a SOX ITGC engagement comes from how much ground the scope covers and how ready the company's records are. The cards below cover the factors that move cost and schedule, and what management can do to hold each one in check before a consultant is engaged.

Scope breadth across systems

Every financially significant application, database and infrastructure layer that feeds reported numbers adds walkthroughs, design tests and operating tests. A company with a general ledger, a subledger, a reporting database and a shared operating system layer carries four times the testing of a single-system environment with the same controls. Ask the consultant to show which systems were included and why. Tighten scope with a top-down risk assessment that starts from material accounts and works down to the systems that process them.

Locations and third parties

Each location that runs financially significant processes, and each third party that hosts, administers or changes those systems, can require its own walkthroughs and evidence requests. Shared service centers and outsourced payroll or hosting providers often need service organization reports or direct evidence. Ask whether each location or provider is required in scope, or whether it is covered by a report the auditor can rely on. Excluding a location needs a documented reason tied to financial reporting risk.

Cloud and SaaS dependence

When financial systems run in public cloud or as SaaS, part of each control sits with a provider. The company must still obtain and review provider evidence, map responsibilities, and test the controls it keeps, such as user provisioning and configuration of logging. Confirm which controls the provider operates, what reports are available, and whether those reports cover the period under audit. Companies with heavy cloud use often need more coordination time than those on on-premises platforms.

Quality of existing documentation

Engagements run longer when control descriptions are out of date, approvals are missing or evidence is stored in personal folders without a clear population. Auditors must test whether reports used as evidence are complete and accurate, so every system-generated list needs a documented source and parameters. Before engaging a consultant, ask for a sample of prior-year evidence and check whether a second person could reproduce it from the record alone.

Prior deficiencies and open remediation

A deficiency found last year, or one still open, usually expands testing. Management must show that the fix operated for enough time, and the auditor may test more instances or extend the period. A material weakness brings additional communication and disclosure work. Ask whether prior findings have root-cause analysis, owner sign-off and retest evidence. Closing them before the year begins generally keeps the new engagement narrower.

Number of control owners to train

Each control owner must understand what the control is, what evidence it produces and how it will be tested. The more owners there are, and the more often they change, the more briefing, walkthrough time and follow-up requests the engagement absorbs. Consolidate ownership where a single role can operate several controls, and assign backups for absences. Ask the consultant for a short training plan per owner that names the evidence each one must retain.

How a SOX ITGC consulting engagement moves from scoping to the auditor's test

The engagement runs in a fixed sequence so that each phase hands management a defined output, and the external auditor receives controls and evidence it can test without the consultant performing the test or the management assessment. Confirm phase timing in the written scope before work starts.

  1. Scope the ITGC areas and systems

    The consultant works with management to identify which financially significant applications, databases, infrastructure and reports feed controls that address financial reporting risks. The work follows the top-down, risk-based approach in SEC guidance and includes the IT general control areas management decides are relevant: access to programs and data, program changes, program development and computer operations. Management approves the scope in writing. The output is a scoping memo that lists in-scope systems, the business process owners for each, and the reasons any area was excluded.

  2. Document control design and ownership

    For each in-scope area, the consultant documents the control objective, the control activity, the frequency, the named owner and the system or report the control relies on. Management reviews the documentation to confirm it matches how the company actually operates, and where it does not, the gap is recorded rather than smoothed over. Documentation should also identify which system-generated reports the controls depend on, since those reports need their own completeness and accuracy evidence. The output is a control matrix that management signs off as its own description of its controls.

  3. Walk through controls with owners

    The consultant traces one transaction or control instance end to end with each control owner to confirm the documented design exists in the live environment. This walkthrough shows whether the control was put in place and is operating as described, and it highlights any manual step that the documentation missed. Walkthrough notes record who was interviewed, which artifacts were examined and what was observed. The output is a set of signed walkthrough records, with any design gap logged for remediation.

  4. Run pre-audit testing on controls

    The consultant selects samples and tests operating effectiveness across the period under review, using the sample approach management and the auditor have agreed. Testing covers the controls in the matrix, including whether change approvals, access reviews and backup restores were performed on time and by appropriate people. Each exception is documented with its cause and whether it affects other controls. The output is a testing workpaper set and an exceptions log that management can review before the auditor begins its own work.

  5. Remediate gaps and document compensating controls

    For each design gap or exception, management decides the remediation, and the consultant helps implement it, such as tightening access provisioning, adding a review step or correcting a backup schedule. Where a fix cannot be in place for the full period, the team evaluates whether a compensating control addresses the same risk and documents that assessment. Management retains the decision on severity and on whether a deficiency is significant or a material weakness. The output is a remediation tracker with dates, owners and retest results.

  6. Package evidence for the auditor

    The consultant assembles evidence in a consistent index that links each control to its population, sample selections, source artifacts and the report or query that generated them. Each system-generated report is checked for completeness and accuracy, so the auditor can rely on it under its information produced by the entity testing. Evidence is stored under management's control, with access logs where relevant. The output is an evidence binder that management reviews for accuracy before it goes to the auditor.

  7. Hand over to management and the auditor

    The consultant transfers the control matrix, testing workpapers, remediation records and evidence index to management, along with a short guide to running the controls and retaining evidence after the engagement ends. Management presents its ICFR evaluation and makes the representations it owes, and the external auditor performs its own independent procedures under its standards. The consultant does not issue an opinion or sign any attestation. The output is a documented handover and a written confirmation from management that it owns the controls and the evidence going forward.

Where the consultant's work stops and the auditor's independence begins

The external auditor cannot build or run the controls it tests, but a consultant that is not the auditor can. Under Regulation S-X Rule 2-01(c)(4), as published in the eCFR, an accountant is not independent if it operates or supervises an audit client's information system, or designs or implements a system that aggregates source data underlying the financial statements, unless the results will not be subject to audit procedures. The same rule bars outsourced internal audit over internal accounting controls, financial systems or financial statements on the same condition. For ITGC work, this means the audit firm cannot configure the access model, own the change approval workflow or perform the periodic access reviews, and then test those same controls. A consultant with no audit role can perform those tasks, provided management owns the controls and the consultant's output is evidence that management reviews and can stand behind.

The line between permitted and prohibited work depends on who performs it and who ends up relying on it. PCAOB AS 2201 paragraphs 17 and 18 let the auditor use work done by internal auditors, other company personnel and third parties working under management's or the audit committee's direction, but only where the people doing the work have enough objectivity and enough competence. A consultant that designed the control it later tests on management's behalf may be judged to lack objectivity, so the auditor may decline to rely on it and perform more of its own testing. Before engaging a consultant, ask the audit firm in writing which tasks it considers acceptable and whether it will rely on the consultant's testing. Confirm this with the auditor for your own facts, since reliance decisions are made case by case.

Your team, the consultant and the auditor: who owns which SOX ITGC task

Management owns the internal control over financial reporting and must assess it each year. Under 15 U.S.C. 7262, that assessment is management's obligation, and an outside firm cannot take it over. Control owners in IT and the business run the daily activities that the ITGCs describe, such as approving access, reviewing changes and monitoring job failures. Outside help can prepare documentation and testing, but the people who operate the controls and sign off on the assessment remain inside the company.

  • Management assessment: Management evaluates whether ICFR is effective as of fiscal year end and documents the basis for that conclusion.
  • Control design and ownership: Named owners define each ITGC, its frequency, its precision and the evidence it produces.
  • Day-to-day operation: Staff perform access reviews, change approvals and backup checks as designed, and keep the records.
  • Scoping decisions: Management decides which applications, databases and infrastructure fall inside scope, and documents the risk basis.
  • Remediation accountability: Management decides how to respond to deficiencies, including compensating controls and disclosure.

Before engaging a partner, confirm that each control has a named internal owner who can explain it to the auditor without help.

What must be in place before you hire a consultant

A consultant can scope, design, test and document SOX ITGCs, but management still owns the controls and the conclusion. These six items decide whether an outside engagement starts from a clear baseline or spends its budget on discovery. Check each one before you sign a statement of work.

Named executive owner

One accountable executive, usually the CIO or CFO delegate, must own the ICFR assessment. Management's Section 404 obligation stays with the issuer, so a consultant cannot sign off on the conclusion. Confirm the owner in writing, confirm they can approve scope and remediation priorities, and confirm they will receive the consultant's status reports directly.

Documented scope list

A scope list names the applications, databases, infrastructure, locations and reports that feed financial statements. Without it, a consultant will either test too much or miss a system the auditor later selects. Ask for the list to show the basis for each inclusion, such as a link to a significant account or a financial report, and confirm who approved it.

Access to systems and change records

Consultants need read access to configurations, user listings, change tickets, job logs and backup reports before they can walk through a control. Confirm which accounts they will receive, whether access is read-only, and how privileged access will be logged. Delays here usually push fieldwork into the period when auditors need results.

Current control inventory

A control inventory lists each ITGC, its owner, its frequency, the system it covers and the evidence it produces. Consultants use it to design tests and find gaps, and they should not have to build it from scratch at a premium rate. Ask whether the inventory maps each control to a financial reporting risk, and whether it was updated after the last year end.

Prior deficiencies and remediation status

Open deficiencies from the last assessment or from the external auditor's communications change the work. A consultant needs the full list, the severity assigned, any compensating controls and the evidence already provided. Ask for it before the scope is fixed, because a known weakness can expand testing well beyond the original estimate.

External auditor consultation

Decide whether the company's external auditor has reviewed the plan, the scope and the planned reliance on outside work. The auditor may use work from third parties under management's direction, but it cannot design or operate the controls it audits. Record the auditor's comments, and keep a clear line between the consultant's role and the auditor's independence rules.

Questions buyers ask before hiring a SOX ITGC consultant

Does a SOX ITGC consultant replace the external auditor?

No. A consultant helps management prepare its IT general controls, documentation and evidence, but it does not attest to anything. Under Section 404, management owns its ICFR assessment, and where Section 404(b) applies, the issuer's independent auditor performs the attestation. The consultant's role ends at preparation, testing support and remediation. The auditor still decides what it can rely on, how much testing it performs and what it reports, so a consultant can shorten the path to a clean audit but cannot stand in for the auditor's opinion. Confirm this split in the written scope before work begins.

Can our internal team run SOX ITGC work without outside help?

Often yes, and many companies do. SEC guidance says management evaluates only the IT general controls needed for the proper and consistent operation of controls that address financial reporting risks, so the workload depends on how many financially significant systems you run and how mature your controls are. The questions to answer honestly are whether your team can map controls to risks, document design and operating effectiveness, and produce evidence the auditor can test. Internal labor can make up more than 50 percent of total Section 404 compliance cost for 404(b) companies, according to the SEC's 2009 study, so the real comparison is internal hours against outside fees plus the internal time still needed.

What does the company have to supply to a SOX ITGC consultant?

Expect to supply system access, documentation and people. Typical inputs include a current list of financially significant applications, databases, infrastructure and locations, the reports the business relies on, access and change records, job schedules, backup logs, and prior audit findings or deficiency reports. You also need named control owners who can explain how their controls run and who can approve decisions quickly. Ask the consultant to list these inputs in the written scope with an owner and a due date for each. Gaps in inputs are a common reason fixed-scope work slips, so agree how delays are handled before work starts.

How does consultant cost compare with internal labor cost?

Compare total cost, not invoice totals alone. The SEC's 2009 study reported that the mean outside vendor fee for 404(b) companies fell from $438,000 before the 2007 reforms to $311,000 after, and the median fell from $100,000 to $90,000. Those figures cover all outside vendor work for Section 404, not ITGC alone, and they are from 2009, so use them as context only. Outside cost is mostly one-time for initial scoping, design and remediation, with recurring cost for annual testing support. Internal cost is salaries, time diverted from other work and tool licenses. Drivers that raise both include the number of in-scope systems, the number of deficiencies, the age of the environment and whether systems are cloud or outsourced.

Will our external auditor accept work done by a consultant?

Yes, if the work meets the auditor's standards. PCAOB AS 2201 lets the auditor use work performed by internal auditors, other company personnel and third parties working under the direction of management or the audit committee. The auditor must also judge the competence and objectivity of those people, and it should not rely on work from someone with low objectivity or low competence, regardless of the other attribute. Ask your auditor early which deliverables it expects, how it wants testing documented and whether it will review the consultant's workpapers. Make sure the consultant does not design or operate the systems it later tests, since that pushes it toward a conflict.

What should a written quote for SOX ITGC work include?

A useful quote states the scope in writing, including which applications, databases, infrastructure, locations and reports are in or out. It should list deliverables such as the ITGC narrative, control matrix, walkthrough documentation, test scripts, evidence packages and remediation plans, with the acceptance criteria for each. Ask for the named people, their roles, the client inputs needed, the assumptions behind the effort, the timeline and milestones, and what happens if scope changes. Also confirm the independence position in writing: the consultant will not operate systems, will not make management decisions and will not issue any audit opinion. DeployOpen works from a written, fixed scope, and it does not publish a price list, so expect a quote that follows from that scope.

Can a consultant guarantee a clean SOX ITGC audit result?

No responsible consultant can promise a clean result, because the outcome depends on the auditor's testing, the actual operation of your controls over the year and deficiencies that may appear. A consultant can reduce preventable gaps by checking design, preparing evidence and fixing issues before year end. Be cautious of any proposal that promises an outcome rather than defining the work. Ask what the consultant will test, how it will document results and how it will report gaps to management and the audit committee.

Which parts of SOX ITGC work should stay with management?

Management keeps the decisions and accountability. That includes deciding the ICFR scope and risk assessment, approving control design, owning the conclusion on effectiveness, deciding remediation priorities and signing off on the assessment. Consultants commonly take on documentation drafting, walkthrough support, test preparation, evidence collection, gap analysis and remediation planning. Keep the split explicit in the statement of work so that the company, not the consultant, can explain every conclusion to its auditor and audit committee.

How DeployOpen prepares systems and evidence for SOX ITGC audits

DeployOpen works as an implementation partner on the systems and evidence behind SOX IT general controls, not as the control owner or the auditor. We prepare self-hosted open-source platforms inside your own infrastructure so that management can operate and document its ITGCs. Management keeps the control ownership, and the independent auditor issues any opinion.

How we scope

  • We agree the scope in writing before work starts, listing systems, environments and control areas covered.
  • Scope names the financially significant applications, databases and infrastructure that your ITGC owners and auditors have confirmed.
  • Ongoing support and continuous testing can be added as a retainer once the fixed-scope work is complete.

How we build

  • We plan, implement, customize, integrate and harden open-source platforms inside your cloud accounts, data centers or air-gapped networks.
  • We configure access, change and backup workflows so that each ITGC produces records that management can review and retain.
  • We run security testing on applications, APIs and infrastructure to surface weaknesses before the auditor's walkthroughs begin.

How we hand over

  • We document configurations, procedures, data flows and ownership so control owners can operate the controls after handover.
  • We prepare evidence packages for walkthroughs and testing, with the system reports and logs your auditor will ask to see.
  • We confirm with your team and auditor which evidence and report formats they will accept before the audit period starts.

How we support

  • Upgrades, backups and platform maintenance can be covered under a retainer so controls stay in the state they were tested.
  • Changes to in-scope systems are documented and reviewed so that management can explain them to the auditor.
  • Questions about auditor independence, scope or evidence sufficiency should go to your external auditor, who makes those determinations.

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.