SOX ITGC readiness before an IPO

A newly public company's first SOX 404 assessment generally falls in its second annual report, and emerging growth status removes the auditor attestation. IT general controls still need to be designed and evidenced well before then.

On this page

When SOX ITGC readiness work must be finished before an IPO

Under Instruction 1 to Item 308 of Regulation S-K and Rule 13a-15(c), a newly public company can omit management's ICFR report and the auditor's attestation until it has filed, or been required to file, an annual report for the prior fiscal year. The first management assessment therefore generally falls in the second annual report. An emerging growth company is also exempt from the auditor attestation under SOX Section 404(b), but it still must perform management's Section 404(a) assessment once that assessment applies. The formal deadline is later than most founders expect, but the working deadline is earlier.

The working deadline is set by the periods the first assessment covers. IT general controls over financially significant systems must be designed, operating and evidenced during those periods, because management cannot evaluate a control that did not exist or did not run. A company that waits until the assessment year to start access reviews, change approvals and job monitoring will often find gaps it cannot close retroactively. Confirm with your auditor and securities counsel which fiscal periods your first report will cover, then work backward from the first date a control must have operated.

The answer varies with company facts: the filing date of the registration statement, the fiscal year end, whether the company is likely to become an accelerated filer, how many financial systems it runs, and whether any of them sit with a cloud or managed provider. Ask counsel to confirm your filer status and the transition language that applies to your first annual report. Then ask your team to map which applications, databases and infrastructure feed financial reporting, and to show evidence for one full quarter of access reviews and change approvals before the IPO filing.

What the transition rules and EGC status allow

Newly public companies get time before full SOX 404 obligations apply, and the exemptions differ by filer status. Each card below covers one rule, what it removes from the first audit cycle, and what it does not remove. None of them removes the need to design and evidence IT general controls for the year being assessed.

Instruction 1 omission

Instruction 1 to Item 308 of Regulation S-K lets a newly public company leave out management's ICFR report and the auditor's attestation until it has filed, or been required to file, an annual report for the prior fiscal year. The first annual report must include a prescribed statement saying so. Check that your counsel drafts that statement correctly, and check the date your first annual report is due, because the omission ends at a fixed point. The relief covers the report, not the controls themselves.

Rule 13a-15(c) first-assessment timing

Rule 13a-15(c) requires the annual ICFR evaluation only after the issuer has filed, or been required to file, an annual report for the prior fiscal year. For most newly public companies, the first management assessment therefore falls in the second annual report. Use the gap to design, implement and run ITGCs over access, program changes, program development and computer operations for a full period, so the first assessed year has operating evidence to show.

EGC exemption from 404(b)

The JOBS Act of 2012 (Public Law 112-106) exempts emerging growth companies from the auditor attestation in SOX Section 404(b). Management's Section 404(a) assessment still applies, so the company must still document and test its ITGCs for financially significant systems. Confirm your EGC status against the statutory conditions with counsel, and confirm when that status would end, because losing it brings the auditor attestation into scope.

Non-accelerated filer exemption under 404(c)

Section 404(c), added by the Dodd-Frank Act in 2010, exempts issuers that are neither accelerated nor large accelerated filers from the Section 404(b) auditor attestation. This is a filer-status exemption, not a growth-stage exemption, so it applies to smaller issuers regardless of EGC status. Management's assessment still applies. Ask your auditor to confirm how filer status is determined for your company each year, since that determination drives which attestation applies.

Twelve-month and one-report accelerated filer test

Under Rule 12b-2, an issuer can become an accelerated filer only after it has been subject to Exchange Act reporting for at least twelve calendar months and has filed at least one annual report. Meeting that test can switch on the Section 404(b) attestation even while the company still looks new. Track the twelve-month date and the public float test together, and plan ITGC evidence for the year the attestation may first apply.

Relief is not a design waiver

Every exemption above delays or removes an attestation, but the assessment still covers the fiscal year being tested, and that year is usually the one with the most change. Auditors still need ITGCs over the financially significant applications, databases and infrastructure that feed the financial statements. Use the timing relief to build access reviews, change approvals and backup evidence before the first assessed year begins, and ask your auditor which systems they expect in scope.

Which IT general controls the first assessment needs in place

The first ICFR assessment does not require a fixed list of IT general controls. SEC Release 33-8810 names program development, program changes, computer operations and access to programs and data as areas management might consider, and it says these do not apply to every company. What a newly public company must have in place is whatever IT general controls are necessary for the proper and consistent operation of the financial reporting controls that depend on technology. Start by listing the financial reporting controls that are automated or rely on system reports, then ask which system conditions keep those controls reliable: who can change the ERP configuration, whether production code changes are approved, whether scheduled jobs complete, and whether backups can restore the ledger. Those answers define the ITGC scope for your company.

The identification of IT risks should be part of management's top-down, risk-based evaluation, not a separate exercise run after the process-level scoping is done. Work from the financial statement risks down to the applications, databases, operating systems and infrastructure that process or store those transactions, and record why each component is or is not in scope. Auditors read this reasoning closely. Under Instruction 2 to Item 308 of Regulation S-K, management must keep evidential matter that reasonably supports its assessment, so the scoping memo, the risk mapping and the test results need to be retained together. Confirm with your auditor how far they expect the first-year documentation to go, because expectations vary by company size and by how much the business depends on packaged or custom systems.

The external auditor will read the same risks through AS 2110 (Appendix B), which requires an understanding of the IT general controls that matter for automated controls. This is why a readiness review should test whether each automated control can be explained in terms of the IT controls behind it. Ask who approves a change to the reporting logic, who grants administrative rights in the finance application, and how a failed batch job is detected and rerun. If the answers depend on a person's memory rather than a recorded procedure with a ticket, a log or a sign-off, expect that gap to surface in the first assessment. Document these controls before the first assessment year, so that operating evidence exists for the period under review.

How the pre-IPO ITGC timeline runs in sequence

The sequence turns an IPO date into a set of ITGCs that are designed, operating and backed by evidence before management must assess them. Each phase hands a specific output to the next, so gaps surface early enough to fix.

  1. Confirm filer status and first annual report date

    Counsel and the finance team establish when the company becomes an Exchange Act reporting issuer, whether it qualifies as an emerging growth company, and which annual report will be its first. Under Item 308 of Regulation S-K, a newly public company can omit management's ICFR report and the auditor's attestation until it has filed, or been required to file, an annual report for the prior fiscal year. Rule 13a-15(c) follows the same logic, so the first formal assessment generally falls in the second annual report. The output is a written filer status memo with the dates that drive every later phase. Confirm the exact dates with your securities counsel and auditor, since the trigger depends on the company's facts.

  2. Scope applications and infrastructure from the top-down risk assessment

    Management starts from the financial statements and works down to the accounts, processes and controls that address material misstatement risk. Only then does it identify the financially significant applications, databases, operating systems, networks and service providers that those controls depend on. SEC guidance says IT risks and controls should be part of this top-down, risk-based evaluation rather than a separate exercise. The output is an in-scope system inventory mapped to key reports, interfaces and automated controls, reviewed with the external auditor. Systems that only affect operational efficiency fall outside the evaluation.

  3. Design and document ITGCs across the four areas

    For each in-scope system, the team writes down the IT general controls in access to programs and data, program changes, program development and computer operations. Each control needs a stated objective, an owner, a frequency and a description of the evidence it produces. Walkthroughs confirm that the documented design matches how the system actually runs. The output is a control matrix and narrative set that the auditor can read before any testing begins. Many gaps appear here, such as shared accounts, unreviewed privileged access or changes that bypass ticketing, so they should be recorded as remediation items at this stage.

  4. Remediate design gaps before operating periods begin

    Gaps found during design work are fixed before the operating period starts, because controls that change mid-period complicate testing. Typical fixes include removing excess administrator rights, adding approval steps to change workflows, restricting direct database access and formalizing backup restoration checks. Each fix needs a change record, an updated control description and a named owner. The output is a remediated design baseline with a log of what changed and when. Ask the auditor which design issues they expect to see in the walkthrough so the team can prioritize them.

  5. Run operating periods long enough to generate evidence

    Once the design is stable, the controls run in production and create the records auditors sample. Access reviews are completed on schedule, change approvals are captured, job failures are investigated and restores are tested. The length of the period and the number of samples depend on control frequency and risk, and the external auditor's testing approach governs those choices. The output is a continuous population of dated, attributable evidence for each control. Set the period length with your auditor, because no fixed duration applies to every company.

  6. Close evidence gaps and test control operation

    Management or internal audit tests a sample of each control to confirm it operated as designed throughout the period. Exceptions are investigated, classified and assessed for their effect on the financial reporting controls that depend on the ITGCs. Missing tickets, late reviews and unexplained privileged changes must be either explained with corroborating evidence or treated as control failures. The output is a test workbook with exception logs, root causes and conclusions. Deficiencies identified here feed the remediation and disclosure decisions that follow.

  7. Hand the evidence file to management and the external auditor

    Management assembles the evidence file that supports its ICFR assessment, organized by control area and system, with the matrix, walkthrough notes, test results and remediation history. Under Instruction 2 to Item 308, the company must maintain evidential matter that reasonably supports its assessment. The external auditor, where attestation applies, then performs its own testing under PCAOB AS 2201. The output is a complete, indexed evidence package and a clear record of open items. Confirm the retention and access arrangements for this file with your counsel and auditor before the package is delivered.

What must be evidenced before the first assessment

A newly public company gets time before its first ICFR assessment, but the IT general controls behind financial reporting need to operate and leave records well before then. Each card below names one area auditors look at first and the check that shows whether the evidence exists.

Access provisioning and reviews

Auditors expect every new or changed user on financially significant applications and databases to have a documented request, an approver and a match between granted rights and the job. Check that joiner, mover and leaver tickets exist for a sample of staff, and that privileged accounts such as database administrators and application superusers are listed. Confirm that periodic access reviews were performed by someone who does not hold the access, that the reviewer compared the list against current roles, and that removals were carried out and recorded.

Change tickets with approval and testing

Changes to financial applications, configurations and infrastructure should be authorized, tested and approved before they reach production, and the record should show each step. Pull a sample of production changes and trace each one to a request, a documented test result, an approval from someone independent of the developer, and a deployment record. Check that emergency changes also have after-the-fact review and that developers cannot push code into production without a second party.

Program development and go-live sign-off

New financially significant systems or major upgrades need evidence that requirements were approved, testing covered financial calculations, data conversion was reconciled, and business and IT owners signed off before go-live. Check that the conversion reconciliation exists for each system that feeds the ledger, that test scripts map to the requirements, and that the go-live approval is dated before the production cutover. Missing go-live sign-offs are a common gap for systems implemented shortly before the IPO.

Job scheduling, backups and recovery

Batch jobs that move financial data must run completely and accurately, and failed jobs must be detected and rerun. Check the job scheduler logs for failed and rerun jobs, and confirm that someone reviews exceptions on a defined cadence. For backups, retain the schedule, the success reports and at least one documented restore test for a financially significant database. A backup that has never been restored is weak evidence of recovery capability.

Incident handling and provider oversight

Incidents that affect financial data or processing should be logged, prioritized, resolved and reviewed for any effect on reporting. If a hosting provider, SaaS vendor or managed service runs part of the financial stack, management still needs evidence that it reviewed that provider's independent control report and the complementary controls assigned to the company. Check that incident tickets record financial impact assessments and that provider reviews are dated, signed and tied to specific systems.

Retained logs and tickets

Management must keep evidence that supports its ICFR assessment, so the logs and tickets behind every check above need to exist for the full period the assessment covers. Confirm that access logs, change records, job logs and approvals are exported or locked so they cannot be edited, and that the retention period is set in writing. Ask the external auditor early which samples and periods they will test, then confirm the evidence is available for those dates.

Who owns the controls, who prepares evidence, and who attests

The company owns its internal control over financial reporting. Management designs the IT general controls, decides which systems fall in scope, operates the controls every day, and performs the assessment that supports its own conclusion. Under Instruction 1 to Item 308 of Regulation S-K, a newly public company may omit management's ICFR report in its first annual report, so the company's first formal assessment usually arrives later, in the second annual report. Readiness work should still start earlier, because the company must be able to show evidence when that first assessment comes.

  • Control ownership: Named owners for access reviews, change approvals, job monitoring and backup testing, each with documented duties.
  • Scope decisions: Management decides which applications, databases, infrastructure and locations matter for financial reporting, and records the reasoning.
  • Management assessment: The company performs the Section 404(a) evaluation and keeps the evidence that supports it, as Instruction 2 to Item 308 requires.
  • Certifications: The CEO and CFO sign the Section 302 certifications, and Section 906 attaches criminal exposure to knowing false certifications.
  • Ongoing operation: Controls must run consistently from the moment they are designed, not only when the auditor looks.

Confirm which of these owners already exist in your organization and whether each one has written authority to approve access and changes.

What delays a pre-IPO ITGC project

Most pre-IPO IT general control projects slip for reasons that have little to do with control design. The gaps below tend to surface late, when the first annual report is close and the evidence trail is thin. Each card names the delay and the check that prevents it.

Late scoping of systems and providers

Teams often finish the financial close and ledger scope but leave cloud hosting, SaaS billing tools and managed service providers out of the ITGC inventory until auditors ask about them. Those systems carry the same financial risk as on-premises applications. Before the first assessment year, confirm each system that feeds a financially significant report, including the cloud accounts and providers that run it. Record the owner, the hosting model and the access paths for each one.

No evidence retention before the first period

Access approvals, change tickets and job logs are often kept in chat threads, personal folders or tools with short default retention. Once the period has ended, reconstructing that evidence is slow and sometimes impossible. Set retention rules for logs, tickets and review sign-offs now, and confirm that the tools in use can export them with timestamps and approver identities. Rule 13a-15 and Item 308 both expect management to hold evidence that supports its assessment.

Access reviews that are not performed

Many pre-IPO companies build privileged access groups during rapid growth and never run the periodic review that proves they are still appropriate. Auditors test whether reviews happen on schedule, whether the reviewer had the information to judge access, and whether removals followed. Start with a complete user list from each in-scope application and database, run one documented review cycle, and keep the signed results. An unperformed review is a gap even when the access itself is correct.

Undocumented emergency changes

Production fixes made during an incident are frequently applied directly and documented later, if at all. Auditors look for a clear path from every production change to an approval, a test result and a post-implementation check, including emergency work. Define an emergency change procedure with a retrospective approval step and a deadline for the record. Then test a sample of recent emergency changes to confirm the paperwork exists and matches the change log.

Provider reports accepted without a gap review

Teams often collect a provider's SOC 1 or SOC 2 report and treat it as covering their own ITGCs. A provider report covers the provider's controls for a stated period, and it usually leaves the customer's own user access, change requests and configuration responsibilities untested. For each provider report, map the complementary user entity controls, identify which apply to your company, and build evidence for those that do. Ask the provider for the exact report period and any exceptions noted.

Questions founders and CFOs ask before the IPO

Does emerging growth company status remove the need for IT general controls?

No. Emerging growth company status exempts an issuer from the auditor attestation under SOX Section 404(b), but management's assessment under Section 404(a) still applies once the company is required to perform it. Management still has to evaluate the IT general controls needed for the proper and consistent operation of automated controls that address financial reporting risks, and it must keep evidence that supports that assessment. The exemption changes who attests to the assessment, not whether the company must have controls in place and evidenced. Confirm your own timing with your securities counsel and auditor, because the first management assessment depends on when your filing obligations begin.

How long does SOX ITGC readiness take before an IPO?

There is no fixed number of months, and you should be wary of any proposal that offers one before scope is known. The duration depends on how many financially significant applications, databases and infrastructure components are in scope, how mature current access and change processes are, how much evidence already exists, and when the external auditor plans to test. Under the transition rules, the first management assessment generally falls in the second annual report, so your work can be planned against that filing date. Ask your auditor which periods they expect to test and what evidence they will request for each control area before agreeing to a timeline.

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

Many companies do part of the work in-house, and the decision depends on capacity and skills rather than on the rule itself. Management owns the controls and the assessment, so someone internal must understand the in-scope systems, approve scope, and sign off on conclusions. Internal staff are usually best placed to run the business process and access reviews. Outside help is often used for scoping, documenting control design, preparing evidence for system configurations, and testing before the auditor arrives. An implementation partner can prepare systems and evidence, but it cannot issue an audit opinion or attestation, and the external auditor cannot design the controls it later tests. Map your internal capacity against the control areas before deciding.

What does a DeployOpen readiness engagement cost?

DeployOpen does not publish a price list. A quote follows from a written scope that names the systems, control areas, deliverables and timeline, and most engagements are fixed-scope with those terms agreed in writing before work starts. Ask any provider to itemize the work into scoping, control design, system configuration, evidence preparation and support, and to state which parts are one-time and which recur, such as access reviews, change reviews and retainers. Also ask what the provider will not do, because the external auditor's testing fees and internal labor are separate costs that a quote may not include.

What does the SEC's 404(b) savings estimate actually cover?

The SEC estimated in Release 34-88365 (March 2020) that an issuer newly exempt from the Section 404(b) auditor attestation would save about $210,000 per year on average. That figure is roughly $110,000 in audit fees and about $100,000 in other costs. The estimate applies to the auditor attestation only. It does not remove management's Section 404(a) assessment, the need for evidence, or the internal labor that supports the assessment. Treat the number as a federal estimate for the attestation exemption, not a forecast of your own costs, and confirm your company's exposure with your auditor.

What does a Section 906 certification add to the CEO and CFO's exposure?

Section 906 requires the CEO and CFO to certify each periodic report containing financial statements, and it attaches criminal penalties to a knowing or willful false certification. Under the statute, a knowing false certification carries fines up to $1,000,000 and up to 10 years' imprisonment, and a willful false certification carries fines up to $5,000,000 and up to 20 years. This is separate from the Section 302 certifications and from the Section 404 ICFR report. For IT general controls, the practical effect is that officers need reliable evidence that financially significant systems were accessed, changed and operated as management believes. Ask counsel to explain how these certifications apply to your first filings.

What evidence should we start keeping before the first assessment?

Start with the evidence the auditor will ask for in each control area, not with a generic collection. Typical items include the list of in-scope applications and infrastructure, user access requests and periodic access reviews, change tickets with approval and testing records, production deployment logs, job scheduling and backup records, and incident and vendor oversight files. Instruction 2 to Item 308 requires the registrant to maintain evidential matter that reasonably supports management's assessment, so records should be complete, dated and retrievable. Self-hosted platforms can produce much of this from their own logs and ticketing, but you should confirm each source is retained and that the auditor accepts it.

How DeployOpen prepares systems and evidence before an IPO

DeployOpen works on SOX ITGC readiness as an implementation partner. We prepare the systems, controls and evidence that management will assess, while the company owns its controls and the independent auditor issues any report. Work starts from a written scope tied to the financial systems that matter before the first assessment.

How we scope

  • Agree in writing which financially significant applications, databases and infrastructure fall inside the ITGC scope before work starts.
  • Map each in-scope system to the IT general control areas and the automated controls that depend on them.
  • Confirm which cloud, SaaS or managed provider systems need provider evidence, and who in the company holds each one.

How we build

  • Configure access, change, development and operations controls in the company's own infrastructure, with the approval steps written down.
  • Set up logging, ticketing and retention so that evidence for each control is produced during normal operations.
  • Test each control with the company's staff before the period that management expects to assess.

How we hand over

  • Deliver control descriptions, procedures, system configurations and an evidence index that the company's team can maintain.
  • Walk the company's internal audit and finance teams through each control and its evidence location.
  • Document open gaps and remediation owners so management can decide what to resolve before year end.

How we support

  • Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
  • Ongoing support, upgrades and continuous testing are available as a retainer after the handover.
  • Ask any partner to confirm in writing that the auditor, not the partner, issues any assessment conclusion.

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.