First SOX 404(b) audit: what changes for IT teams

What changes for IT in your first SOX 404(b) audit

A company facing its first auditor ICFR attestation should expect the external auditor to test IT general controls over automated controls and over the reports those controls rely on, as part of the integrated audit of internal control and the financial statements. The first-year cost is higher than later years: the SEC's 2009 study found mixed results for first-time Section 404(b) compliance after the 2007 reforms, with no statistically significant fall in mean cost, while second-year costs were significantly lower. The effort in year one depends on three things: how many systems, reports and controls the auditor selects, the state of the evidence that already exists, and whether management's own testing is already running. A company that has never tested its access reviews or change approvals on a regular cycle will spend most of its first year building that history. Confirm early with your audit firm which applications and reports fall in scope, and ask how many samples and which periods it expects to see. Those answers drive the workload more than any other single factor. Management owns the controls, performs and documents its own assessment, and is responsible for the written representations the auditor requests. The external auditor, not the company or any implementation partner, issues the opinion on ICFR. Outside help can prepare systems, extract population reports and organize evidence, but it cannot stand in for management's testing or the auditor's independent work. Decide early who on the IT side owns each control and each evidence package, because the auditor will ask those people to walk through their processes.

How the first integrated ICFR audit runs for IT

The first integrated audit moves from auditor planning through walkthroughs, testing and written communications, and each phase leaves a specific IT output that the external auditor relies on. Knowing the order lets IT teams have systems, evidence and owners ready before the auditor asks for them.

Agree audit scope and planning with the external auditor
The external auditor plans the ICFR audit alongside the financial statement audit under PCAOB AS 2201, which is reorganized from Auditing Standard No. 5 and integrated with the financial statement audit. For IT, this means confirming which financially significant applications, databases, infrastructure and reports are in scope, and which IT-dependent controls rely on them. The output is a shared list of systems and control owners, and IT should confirm that list against its own inventory before fieldwork begins.
Document and walk through IT-dependent processes
Under AS 2201, paragraph 37, a walkthrough follows one transaction from origination through the company's processes and information systems to the financial records. The auditor uses the same documents and IT personnel that the company uses, combining inquiry, observation, inspection and re-performance. IT should have current process narratives, system diagrams and configuration screenshots ready, and the walkthrough is complete when the auditor confirms the design of each control matches what operators actually do.
Confirm the accuracy of system-generated reports
PCAOB AS 1105 requires the auditor to test the accuracy and completeness of information the company produces, or the controls over that information, and to judge whether it is precise and detailed enough for the control. For IT, this covers reports, queries and spreadsheets pulled from financial systems that operators use in controls. Each report needs a documented source, parameters, and evidence of how its completeness was verified. The step closes when the auditor accepts the report as reliable for testing.
Test ITGCs that support automated controls
Testing covers the IT general controls that keep automated controls and key reports working, including access, program changes, program development and computer operations. The auditor samples changes, access reviews, job logs and recovery tests, and asks for the tickets, approvals and system records that prove each control operated during the period. IT owns the evidence trail, so it should be retrievable without rebuilding it from memory. The step is complete when each tested control has a documented result.
Evaluate deficiencies and their effect on controls
When testing finds a gap, management and the auditor assess whether it is a deficiency, a significant deficiency or a material weakness, and whether an IT-dependent control still works in its place. IT contributes by explaining root cause, the population affected and the date the gap was corrected. The output is a written evaluation for each finding, which feeds the auditor's conclusion and the company's own assessment.
Provide written representations from management
AS 2201, paragraph 75, requires written representations from management. These include a statement that management did not use the auditor's procedures as part of the basis for its own ICFR assessment, and that management disclosed all deficiencies it identified. IT leaders should confirm in writing that known control failures, workarounds and system incidents were reported to finance and the auditor. The step closes when signed representations match the deficiency log.
Receive deficiency communications from the auditor
Under AS 2201, paragraph 81, the auditor must tell management in writing about all deficiencies less severe than material weaknesses that it identified, and inform the audit committee that it has done so. IT receives the technical detail behind those letters, so it should check each item against its own records and agree on remediation owners and dates. The step is complete when management responds to each written item and the audit committee has been informed.
Plan how prior-year knowledge reduces later testing
AS 2201, paragraphs 57 to 59, lets the auditor use knowledge from prior years, including earlier results and any changes to a control or process. Stable, well-documented ITGCs can lower assessed risk and reduce testing in later years, while changes made in the first year may need fresh testing. IT should record every control change, system upgrade and remediation so that the next cycle starts from an accurate baseline.

Walkthroughs and ITGC testing over automated controls and reports

The first integrated audit tests whether IT can show that the systems behind financial controls work as described, and the walkthrough is where that test starts. Under PCAOB AS 2201, paragraph 37, the auditor follows a transaction from origination through the company's processes and information systems to the financial records. The auditor uses the same documents and the same IT personnel the company uses, and typically combines inquiry, observation, inspection and re-performance. For IT, this means the people who administer the application, the database and the job scheduler should be ready to walk the auditor through a live example, show the configuration screens or logs that prove it, and explain who can change them. Confirm early which IT staff the auditor will ask to walk through each system, because a walkthrough that stalls on a missing administrator delays every test that follows.

Where a control depends on a report the system generates, such as an aged receivables listing or a three-way match exception report, the auditor also needs to trust the report. PCAOB AS 1105 requires the auditor to test the accuracy and completeness of information the company produced for use in a control, or to test the controls over that accuracy and completeness, and to decide whether the information is precise and detailed enough for its purpose. In practice, IT should document the report's source tables, the parameters and filters, who can change them, and how completeness is checked, such as record counts or control totals reconciled to the ledger. Those reports sit on top of the ITGCs that the auditor tests. The SEC's Release 33-8810 names program development, program changes, computer operations and access to programs and data as areas management might consider, and most auditors examine the same four areas in the first year. These are not an official catalog, so ask the external auditor early which areas and systems it plans to cover and which it considers relevant to each automated control.

What the audit asks of IT teams

The external auditor will ask IT for the same kinds of evidence across every financially significant system, so the work is organized around six deliverables. Each one feeds the walkthroughs, ITGC testing and deficiency discussions that the first integrated audit requires.

System and report inventory

Auditors start from a list of the applications, databases, infrastructure and reports that feed financial statements. IT should own a current inventory with each system's owner, hosting location and the reports it produces, because scope decisions depend on it. Check that every report used in a key control is listed, since reports produced by the company are tested for accuracy and completeness.

Current ITGC design documentation

Before testing begins, IT needs written descriptions of how access, change and operations controls actually work today, not how the policy says they should work. The documentation should name the control owner, the trigger, the approver and the system where each step happens. Stale documents often produce the first design findings of the year.

Population lists for changes and access reviews

Testing samples come from complete populations, so IT must produce every change ticket, deployment and access review for the period under audit. Each population should reconcile to system logs or the change tool's full export. A sample drawn from an incomplete list invites a scope limitation discussion.

Evidence of report accuracy

Under AS 1105, reports the company uses in controls must be tested for accuracy and completeness, or the controls over them must be tested. IT should document how each report is generated, which parameters are fixed, and who can change them. Keep the query, the run date and a reconciliation to source data with each report.

Prepared walkthrough participants

Walkthroughs follow a transaction through the company's systems using the documents and personnel that people actually use. IT should name the administrators and application owners who will explain each step, and confirm they can show screens live. Participants who cannot explain their own controls make the design evaluation harder to complete.

A single owner for requests

Auditor requests arrive daily and often overlap across systems. One named IT coordinator should log each request, assign the owner, track due dates and keep the response library in one place. Without this role, duplicate requests and inconsistent answers become a source of deficiencies in their own right.

Written representations and deficiency communications

Before the external auditor signs anything, management signs written representations, and two of them matter most for IT teams. Under PCAOB AS 2201 (paragraph 75), management represents that it did not use the auditor's procedures as part of the basis for its own ICFR assessment, and that it has disclosed to the auditor all deficiencies it identified. The second representation is the one IT leads should take literally. If a access review gap, a failed change approval or a backup restore problem was found by your own team and never written down or passed up the chain, it still counts as an identified deficiency, and the representation is untrue. The practical consequence is that every ITGC issue your team finds must enter the same tracking system as issues found by the auditor, with an owner, a severity rating and a documented remediation status.

Under AS 2201 (paragraph 81), the auditor must tell management in writing about every deficiency it identified that is less severe than a material weakness, and must inform the audit committee that it has done so. In practice this means IT findings can surface in an auditor letter even when they never reach the material weakness threshold, and the letter becomes a record the audit committee reads. Ask your controller to confirm how deficiencies are logged, who classifies severity, and how remediation dates are recorded so that IT's view and management's view match before the letter is drafted. Confirm also how your audit committee receives these communications, since the timing and format are set by your own governance calendar and the auditor's engagement terms.

For IT, the operational checklist follows from these two obligations. Keep a single deficiency register that covers failed access reviews, unapproved emergency changes, missing job-monitoring evidence and provider report gaps, and record the date each issue was found, by whom, and what evidence closed it. Do not close an item by overwriting its history. Review the register with the controller at each month-end and before the representation letter is drafted. The question to answer for each entry is whether management can truthfully say it was disclosed, which is far easier to defend than explaining a finding the auditor discovered first. The full text of AS 2201 is available from the PCAOB Auditing Standard No. 5 release, and it is worth reading paragraphs 75 and 81 with your controller before the first year.

What first-year SOX IT work costs and who gets paid

This table compares each cost component of a first integrated ICFR audit against who pays for it, whether it is one-time or recurring, and what drives it up. Use it to decide which quotes to request and which costs to budget internally. The main takeaway is that first-year costs run higher than later years, so the scope of the first audit matters most.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it
External auditor ICFR attestation fees	Independent registered public accounting firm, which issues the attestation	Recurring annually, with a heavier first year	Number of IT-dependent controls tested, number of systems in scope, and how much the auditor must test directly rather than relying on management's work
Management staff time for walkthroughs and evidence	Internal staff (IT, finance, control owners); no outside payment	Recurring, larger in the first year	Number of walkthroughs, how many systems lack documented controls, and how quickly owners produce evidence
Remediation of ITGC gaps before testing	Internal engineering teams, system vendors, or outside implementation partners	One-time for most fixes, then ongoing upkeep	Gaps found in readiness work, such as missing change approvals, unreviewed access, or undocumented backups
External consultant or co-sourced internal audit	Consulting firm that prepares controls and documentation; the company keeps ownership of its controls	Often one-time for readiness, sometimes recurring for testing support	Fixed scope agreed in writing, the team's existing SOX experience, and whether the work is preparation or testing
Tooling and evidence systems	Software vendors or open-source platform operators; internal team for hosting and upkeep	Licenses recur; setup and log configuration are one-time	Ticketing and change tools already in place, log retention needs, and whether evidence can be exported in auditor-ready form
Cloud or outsourced provider reports	Provider issues its own SOC 1 or equivalent report; company pays for its contracted service	Recurring	Number of financially significant services hosted by providers and whether the provider report covers the period under audit
Written representations and deficiency communications	Management time and audit committee involvement; no separate fee	Recurring	Number of deficiencies identified, their severity, and how well management tracks and documents them

Why first-year costs run higher than later years

Year one costs more mainly because the company and its auditor have no shared record of how IT controls work. Under PCAOB AS 2201 (paragraphs 57 to 59), the external auditor uses knowledge from prior years, including earlier test results and any changes to a control or process. When that history exists and the controls have held steady, the auditor may assess risk as lower and reduce testing in later years. The 2009 SEC study found mixed results on first-time 404(b) costs and no statistically significant fall in mean cost after the 2007 reforms, but it found second-year costs significantly lower. The reduction is not guaranteed. It depends on how stable the environment stays and on what the auditor finds.

Most of the first-year effort goes into building what later years will reuse. For IT, that means a current inventory of in-scope applications, databases, infrastructure and reports, a documented baseline for each system's access roles, change workflow and job schedules, and written descriptions of how financial data flows from source systems into the ledger. The team also has to perform first-time walkthroughs of each automated control and its supporting ITGCs, keep the evidence trail intact (tickets, approvals, access reviews, backup logs and restore tests), and show that this evidence is complete and accurate. Each of these is slow when nothing exists yet, and each becomes faster once it is maintained.

Ask your auditor early which prior-year elements it can rely on, and confirm in writing what it will need to re-test in year one. Ask your implementation partner or internal team to name the owner of every baseline document and the date of its last review, because stale documentation weakens the case for reduced testing. Plan for the first year as the year you establish the baseline, and treat any change to an in-scope system during that year as something that may reset the auditor's view of risk. Any estimate of year-one effort should come from your own scope and your auditor's written plan, not from a general figure.

Who owns the controls, who prepares evidence and who issues the opinion

Management owns internal control over financial reporting. The company decides which controls exist, who operates them, and what management concludes about their effectiveness as of fiscal year end. Under Rule 13a-15(c), management must evaluate ICFR against a suitable, recognized framework, and that evaluation cannot be delegated to an outside party. In the first integrated audit, the external auditor also asks management for written representations, so senior officers must be able to stand behind every statement about the control environment.

Control ownership: Management names control owners for IT general controls and the automated controls that depend on them, and those owners answer for operation during the year.
Management assessment: Management performs and documents its own ICFR evaluation, including its conclusions about deficiencies and their severity.
Written representations: Management confirms in writing that it did not use the auditor's procedures as part of its own assessment and that it disclosed all identified deficiencies.
Deficiency decisions: Management decides how to remediate deficiencies, whether compensating controls exist, and what to disclose.
Evidence retention: The company keeps the records that prove each control operated, even when a partner gathered them.

Confirm with your audit committee and external auditor which owner signs off on each IT general control before fieldwork begins.

How to check readiness before the auditor arrives

The external auditor will test the same things management should have tested first: scope, documentation, evidence and ownership. Each check below can be verified by someone on the IT or finance team before fieldwork starts, and each one shows the auditor whether the ICFR program is operating or only documented.

Documented ITGC scope

Confirm there is a written list of the applications, databases, operating systems, infrastructure and reports that feed financially significant accounts, and that each entry names the reason it is in scope. SEC guidance says management evaluates only the IT general controls needed for other controls that address financial reporting risks, so the scope must tie back to those risks. Check that a finance owner and an IT owner have both signed off on it. A list that omits a system the auditor finds through a walkthrough is one of the first readiness gaps assessors report.

Current walkthrough narratives

Verify that each in-scope process has a narrative and a flow of a sample transaction from origination through the systems to the financial records. The auditor will follow the same path using the documents and personnel the company uses, so the narrative must match what the team actually does today. Ask the process owner to walk one transaction end to end and compare it with the written version. Any change since the prior year should be reflected in the narrative before testing begins.

Access review and change approval evidence

Pull the access reviews and change approval records for the full period under audit, not only a recent sample. Each review should show who reviewed what, when, and what action followed any exception. For changes, confirm that each production change links to a request, a test result and an approval made before deployment. Gaps in either population are the most common reason ITGC testing expands in the first year, because the auditor must then reason about what the missing records would have shown.

Population completeness for reports

For every report that management or the auditor uses in a control, confirm the population it comes from is complete and accurate. The company must show that the report captured every record it should, and that the parameters used to generate it are controlled. PCAOB AS 1105 requires the auditor to test the accuracy and completeness of company-produced information or the controls over it. Ask the report owner to regenerate the report from the source system and reconcile the record counts and totals to the ledger.

Deficiency log

Maintain a single log of every control deficiency identified during the year, whether found by management testing, internal audit, IT monitoring or the team itself. Each entry should record the control affected, the severity assessment, the remediation steps and the date of retest. The auditor will ask for this log and will compare it with its own findings. An entry that is missing, or a deficiency closed without retesting, creates a representation problem because management must disclose all deficiencies it identified.

Named owner for each control

Confirm that every key ITGC and every IT-dependent business control has one named owner who can explain it, produce its evidence and sign off on its operation. Check that owners still hold the role and that backups are named for absences. The auditor will often ask a control owner to describe the control without preparation, so a control with no owner or with an owner who left the company is an immediate design concern. Record each owner in the control inventory alongside the review cadence.

What usually delays the first audit or inflates its cost

Most first-year delays come from a few preventable gaps: IT scope that was never pinned down, reports nobody can explain, and evidence that stops partway through the period. Each card names one cause and the step that keeps it from reaching the auditor.

Unclear system scope

If the team has not agreed which applications, databases, infrastructure and report-producing tools sit inside ICFR scope, the auditor will widen the list during walkthroughs and ask for evidence on systems nobody prepared. Start from the financial statement line items and work down to the systems that initiate, process and record them. Confirm the list in writing with finance and the external auditor before the period starts, and record the reason each system is in or out.

Undocumented report logic

Many automated controls depend on system reports, such as aging lists, exception reports or reconciliation extracts. When no one documents how a report is built, which fields it pulls and which filters it applies, the auditor cannot tell whether it is complete and accurate. For each report used in a control, keep the query or configuration, the owner, and a record of who reviewed changes to it. Plan a completeness and accuracy test for each report before the auditor asks for one.

Missing change or access evidence

Auditors test the full period, so a gap in change approvals or user access reviews for even a few months forces extra sampling or a finding. This often happens when a new tool is adopted mid-year or when a team stops keeping tickets after an early milestone. Check the population early by pulling a complete list of production changes and privileged access grants for the whole period. Where a gap exists, document what happened and what compensating review took place.

Late discovery of deficiencies

Deficiencies found in the last weeks of the year leave little time to fix a control, retest it and show it operated. Under the auditor's communication requirements, deficiencies less severe than material weaknesses are reported in writing, and management must also disclose what it identified. Run internal testing of key ITGCs at interim dates, log every exception with an owner and a remediation date, and bring the list to the audit committee on a regular cadence rather than at year end.

Treating the auditor as designer

When management asks the external auditor to define what a control should look like, the auditor cannot test it independently and may later question whether management's own assessment was objective. Auditors must not be used as part of the basis for management's assessment, and that principle is confirmed in management's written representations. Management should design, document and operate the controls, using consultants or internal audit for support, then give the auditor the design and the evidence to test.

Questions buyers ask before the first SOX 404(b) audit

How much effort does IT need to supply for the first SOX 404(b) audit?

IT effort depends mostly on how many financially significant systems, interfaces and reports fall in scope, and on how well those controls are already documented. In a first integrated audit, IT typically supplies walkthrough participants, system and user access listings, change tickets, job logs, and evidence that reports used in controls are accurate and complete. The external auditor must test the accuracy and completeness of information the company produces, so IT must be ready to show how each report was generated and who can change it. Ask your auditor for a written list of requested populations and sample sizes early, and ask your team to estimate effort per population before the fieldwork window opens.

Can our internal staff prepare the evidence without outside help?

Yes, many organizations prepare evidence in-house, and the external auditor does not require outside help. Management owns its controls and must perform its own ICFR assessment, so the people who run the systems must be able to explain and evidence them. Outside help is most useful where the team lacks experience with walkthroughs, report validation or ITGC documentation. A quality test is whether staff can trace a transaction through systems to the financial records without preparing a special narrative. Inexperienced teams often underestimate the volume of screenshots, approvals and system-generated reports the auditor requests, so plan that workload explicitly.

How long does the first SOX 404(b) audit take?

The timeline depends on the company's fiscal year, its scope, and how mature its controls are, so ask your auditor for a written schedule rather than relying on a general estimate. The external auditor performs the ICFR audit under PCAOB AS 2201, which is integrated with the financial statement audit, so the two run on a shared calendar. Walkthroughs usually come first, followed by design and operating effectiveness testing, and then remediation of any deficiencies before year end. Fixing an ITGC gap late in the year can extend testing and add rework. Confirm the testing windows, interim and year-end dates, and the agreed document request list with your auditor before work begins.

What does a deficiency mean for IT?

A deficiency is a control that does not operate as designed or is missing, and in IT it often means an access review was not performed, a change was deployed without approval, or a report used by a financial control was not validated. Under PCAOB AS 2201, the auditor must tell management in writing about all deficiencies less severe than material weaknesses and inform the audit committee that it has done so. A deficiency that could lead to a material misstatement may be classified as a material weakness, which carries public disclosure consequences. IT should track each finding, its root cause, the owner, and the evidence that shows remediation, because the auditor will test whether the fix works over a sufficient period.

When should we bring in a consultant instead of relying on the auditor?

Bring in a consultant when the team needs help preparing for the audit, not when it needs the auditor's opinion. The external auditor audits the company's controls and cannot design or perform management's controls, so it cannot be the party that prepares your evidence without creating an independence conflict. A consultant or implementation partner can help document systems, prepare evidence packages, and test controls before fieldwork. DeployOpen prepares systems, controls and evidence for assessments, but it does not issue audit reports or opinions; only the independent auditor does. Ask any firm for a written, fixed scope listing deliverables, and confirm it will not perform management's assessment on the company's behalf.

Why does the first audit cost more than later years?

The first year is more expensive because the company must build its documentation, walkthroughs and evidence trails from scratch, and the auditor must establish a baseline of risk. A 2009 SEC study found mixed results and no statistically significant fall in mean cost for first-time 404(b) compliance after the 2007 reforms, while second-year costs were significantly lower. In later years, the auditor can use knowledge from prior years, including earlier results and any changes in controls, which may let it assess risk as lower and reduce testing. Costs that recur include auditor fees, internal staff time and tooling, while one-time costs include initial documentation and remediation. Ask your auditor to explain which testing it expects to reduce in later years.

What should we ask for in a consultant's quote?

Ask for a written, fixed scope that lists the systems, applications, databases, infrastructure and reports covered, along with each deliverable and the acceptance criteria. Cost drivers include the number of in-scope systems, the number of ITGC areas covered, the state of existing documentation, whether cloud or outsourced providers are involved, and how much remediation support is needed. Ask which items are one-time work, such as documentation and walkthrough preparation, and which recur, such as quarterly access reviews or annual retesting. Confirm who performs each task, what the company must provide, and what happens if scope changes during the year. DeployOpen does not publish a price list, and a quote follows from the written scope.

How DeployOpen prepares your systems and evidence

DeployOpen's role in a first integrated audit is to prepare systems and evidence, and the boundaries of that work are agreed in writing before anything starts. The engagement scope names the financially significant applications, databases, infrastructure and reports in play, the ITGC areas being prepared, the client environment where the work runs, and the deliverables and timeline. Most engagements are fixed-scope, so the quote follows from that written scope rather than from a published price list. Ask any partner to show you the scope document, the named roles on each side and the list of deliverables before you sign.

Inside your own cloud accounts, data centers or air-gapped networks, DeployOpen can help deploy and harden self-hosted open-source platforms that carry ITGC evidence, such as ticketing and change records, access review exports, job scheduling logs and backup restore results. The work includes preparing walkthrough packages that match the documents and system screens your staff actually use, and building populations for auditor sampling with the completeness and accuracy checks the auditor will ask about. Management still owns the controls, approves the populations and decides what is in scope. Confirm with your auditor which report formats and screenshots they accept before the platform is configured.

At handover, DeployOpen delivers the documentation your team needs to run the controls without the implementation partner in the room, including configuration records, procedure write-ups and evidence retrieval steps. DeployOpen does not issue audit reports, attestations or certifications. Only the independent external auditor performs the ICFR audit and issues the opinion. Ongoing support, upgrades and continuous testing are available as a retainer, which many organizations choose for the period between the first audit and the next fiscal year end. Ask what the retainer covers, how changes to scope are priced and who signs off on evidence before the engagement begins.