SOX ITGC for First-Time Public Companies: What Auditors Test

SOX prescribes no control checklist. Your IT general controls are the access, change-management, program-development and IT-operations controls over every system that feeds financial reporting, and management scopes them for its own assertion under Section 404(a). Whether an external auditor also attests to them depends on your filer status, and this is where first-timers get the wrong answer: 15 U.S.C. 7262(b) requires the auditor attestation only for issuers "other than an issuer that is an emerging growth company", and subsection (c) exempts any issuer that is "neither a large accelerated filer nor an accelerated filer" as those terms are defined in Rule 12b-2. Most newly public companies are one or both, so in year one you are usually building for management's assertion, not for an auditor's opinion on your controls.

That does not make the work optional, and it does not mean your financial statement auditor ignores your systems. It changes what the deliverable is, which changes the sequence. Here is how the scoping actually works, and what gets tested inside it.

Key takeaways

• SOX prescribes no control checklist. Management scopes the ITGCs for its own assertion under Section 404(a), which applies from your first annual report with no filer-status exemption.
• The Section 404(b) auditor attestation is separate, and emerging growth companies and non-accelerated filers are exempt by statute, so year one is usually a management programme.
• The financial statement audit never cared about your filer status. Weak ITGCs mean your auditor tests more, which costs you fees even when nobody opines on your controls.
• Scope top-down: significant accounts, then processes, then applications, then infrastructure. The identity provider is almost always in scope even though it produces no financial data.
• First-year programmes fail on evidence and completeness, not on technical controls. Name the authoritative system for each population now, export it dated, and reconcile it quarterly.

Who owns what in year one

Three distinct obligations get conflated constantly.

Section 404(a): management's assertion. Every annual report must contain an internal control report stating management's responsibility for internal control over financial reporting and containing management's own assessment of its effectiveness as of year end. That obligation attaches on your first annual report after registration, and it has no filer-status exemption.

Section 404(b): the auditor attestation. This is the separate opinion from your registered public accounting firm on management's assessment. An emerging growth company is carved out by the text of 7262(b) itself, and a non-accelerated filer by 7262(c). An emerging growth company is defined at 15 U.S.C. 77b(a)(19) as an issuer with total annual gross revenues below $1,000,000,000 (indexed for inflation), and status runs until the earliest of several triggers, including "the last day of the fiscal year of the issuer following the fifth anniversary of the date of the first sale of common equity securities" under an effective registration statement. So EGC status has a five-year ceiling, and companies that stay small keep the exemption to the end of it.

The financial statement audit. This one never went away and does not care about your filer status. Your auditor still has to understand how information technology affects the flow of transactions, because that understanding drives their risk assessment and the nature of their substantive testing. If your ITGCs are weak, they do not get to ignore that; they respond by testing more, which costs you money in fees even when nobody is issuing an opinion on your controls.

The practical consequence is that year one is a management programme, planned in the knowledge that a 404(b) opinion arrives later. Build documentation that will survive that transition rather than documentation that only satisfies an internal sign-off.

Scoping: from financial statements down to systems

The scoping method is top-down, and PCAOB AS 2201 describes it for auditors in terms management can borrow directly: start at the financial statement level and the overall risks to internal control over financial reporting, consider entity-level controls, then narrow to significant accounts and disclosures and their relevant assertions.

Turn that into a system list in four steps.

1. Identify significant accounts and disclosures. Revenue, receivables, cash, payroll, inventory if you carry it, equity if your cap table is complex.

2. Trace each to the business processes that produce it. Order to cash, procure to pay, hire to retire, record to report.

3. List the applications those processes run on. The general ledger or ERP, the billing or revenue system, payroll, expense management, the CRM if it holds the contract terms that drive revenue recognition, and any spreadsheet doing calculation work that nobody has admitted is a system.

4. List the infrastructure underneath each application. The databases, the operating systems, the cloud accounts, and above all the identity provider, because access to everything above depends on it.

That fourth layer is where the ITGCs live, and it is the layer first-time programmes under-scope. The identity provider is almost always in scope even though it produces no financial data, because it grants the access that every application control depends on.

AS 2201 also gives you a useful sizing principle: in a less complex environment running off-the-shelf software without modification, testing "might focus on the application controls built into the pre-packaged software" and the general controls important to those application controls. A company running unmodified cloud accounting software has a genuinely smaller ITGC footprint than one running a customised ERP, and scoping should reflect that instead of copying a template built for a larger company.

The four domains, and what gets tested

Access to programs and data. Who can get into each in-scope system, who granted it, and whether it was removed when the person left. Testing looks at new-user provisioning with evidence of approval, timely removal on termination, periodic user access reviews performed by someone who understands the roles, privileged and administrative account inventories, and whether anyone can both create and approve a transaction. Segregation of duties conflicts are found here, and they are the ITGC finding most likely to escalate, because a conflict is a design problem rather than a bad month.

Program changes. Changes to in-scope applications and their configurations. Testing looks at the complete population of changes, evidence that each sampled change was authorised and tested before release, that the person who wrote it did not release it unilaterally, and that emergency changes followed a documented emergency path with after-the-fact approval.

Program development. New systems and major implementations. Testing looks at approval, requirements and testing evidence, data conversion validation, and the go-live decision. If you implemented an ERP during the year, this domain moves from a formality to the biggest single item in your programme.

Computer operations. Job scheduling and monitoring for the batch processes that move financial data, backup and recovery, and incident handling for failures that affect financial reporting. Interfaces between systems live here too: if billing pushes revenue into the general ledger nightly, somebody has to prove that failures are detected and corrected.

Underneath all four, management's assessment has to be made against a suitable recognised framework, and in practice that is almost always COSO's Internal Control Integrated Framework. Map your documentation to whichever framework you adopt rather than to an ad hoc scheme of your own, because the mapping is what makes the assessment reviewable by somebody who did not build it.

Where first-year programmes actually fail

Not on technical controls. On evidence and completeness, and the pattern repeats across every framework we work in.

The termination population comes from IT's ticket queue instead of from payroll, so the contractors are missing, and the completeness test finds them. The change population comes from the ticket system instead of the deploy log, so changes that bypassed the ticket are invisible until somebody reconciles. Approvals exist in Slack rather than in the system of record, so there is nothing dated to sample. The access review was performed by a manager who approved a list they did not understand, which is a review in name only. And a spreadsheet nobody scoped turns out to calculate a material accrual.

The habit that prevents all of this is the same one we describe for audit sampling: for every recurring control, name the authoritative system now, produce the population as a dated system export, and reconcile it against an independent source quarterly. Do it in the first quarter and the year-end assessment is a formality. Do it in the fourth and it is a scramble.

How long it takes

Longer than the calendar suggests, and the honest answer is that it is driven by scope rather than by a fixed duration. The sequence is fixed even when the durations are not: scope the significant accounts and systems, document the processes and controls, remediate what is missing, operate the controls long enough for there to be something to test, then test and assess.

The binding constraint is that last-but-one step. A quarterly control needs quarters. A monthly access review that starts in October gives you three occurrences by year end, and an assessment covering three occurrences of a control that should have twelve is a weak assertion. Work backwards from your first annual report, decide which controls need a full year of operation, and start those first. That is why IPO-track companies begin this work well before the S-1 rather than after it.

What transfers from SOC 2

If you already hold a SOC 2, a real portion of the evidence transfers, and a real portion does not.

Transfers: access provisioning and deprovisioning records, access reviews, change approvals, the identity provider configuration, backup and recovery testing. The artifacts are the same artifacts; only the requirement they are tagged to changes, which is the whole argument in reusing evidence across frameworks.

Does not transfer: the scope. SOC 2 is scoped to the system that delivers your service against the Trust Services Criteria. SOX is scoped to what feeds the financial statements. Those two sets overlap in the identity provider and the cloud accounts and diverge almost everywhere else, because your billing system and general ledger are usually outside a SOC 2 boundary and squarely inside a SOX one. Nor does SOC 2 give you the entity-level controls, the significant-account analysis, or the management assessment documentation, all of which are new work.

Where Top Floor fits

The parts of this that benefit from outside help are the scoping decision, the evidence architecture, and the honest conversation about which controls need to start operating now rather than next quarter. That is SOX readiness work and, where the company has no senior owner for it, a fractional security leadership arrangement to carry it.

The part you should not outsource is ownership. Management's assertion is management's, and a programme where an outside firm holds the control register and the internal team holds nothing is a programme that will not survive the year the consultants leave. If you have a controller and a head of IT who will own their halves and meet monthly, buy help for the scoping and keep the rest.

Frequently asked questions

Does a first-time public company need a SOX auditor attestation?

Usually not in year one. 15 U.S.C. 7262(b) requires the auditor attestation only for issuers other than emerging growth companies, and 7262(c) exempts issuers that are neither large accelerated filers nor accelerated filers. Most newly public companies are covered by one exemption or the other. Management's own assessment under Section 404(a) is not exempt and applies from the first annual report, so the year-one deliverable is management's assertion, documented well enough to survive the transition when the attestation eventually applies.

How long does emerging growth company status last?

Up to five years, subject to earlier triggers. Under 15 U.S.C. 77b(a)(19), an issuer with total annual gross revenues below $1,000,000,000 (indexed for inflation) keeps the status until the earliest of several events, one of which is the last day of the fiscal year following the fifth anniversary of the first sale of common equity securities under an effective registration statement. Crossing the revenue threshold or issuing significant non-convertible debt can end it sooner, so treat the five-year figure as a ceiling, not a plan.

What are the four ITGC domains?

Access to programs and data, program changes, program development, and computer operations. Access covers provisioning, removal, periodic review, privileged accounts and segregation of duties. Changes covers authorisation, testing and release of application and configuration changes, including the emergency path. Development covers new systems and major implementations. Operations covers job scheduling and monitoring, backup and recovery, and the interfaces that move financial data between systems.

Which systems are in scope for SOX ITGC?

The ones that feed financial reporting, identified top-down: significant accounts, then the processes that produce them, then the applications those processes run on, then the infrastructure underneath. In practice that is the ERP or general ledger, payroll, billing and revenue systems, expense management, and the databases, cloud accounts and identity provider beneath them. The identity provider is in scope even though it produces no financial data, because every application control above it depends on the access it grants. Any spreadsheet performing a material calculation is a system too, whatever anyone calls it.