SOX ITGCs for acquired businesses: the one-year exclusion

SOX ITGCs for acquired businesses: when the one-year exclusion applies

Management may exclude a recently acquired business from its ICFR assessment for up to one year from the acquisition date, and from no more than one annual report, provided it identifies the business and indicates its significance. That is the SEC staff's position in Question 3 of its management's report FAQ, and it is the first thing a CFO or CIO facing a closing date should confirm. The exclusion is a relief on the assessment, not a relief on the controls. It does not remove the need to bring the target's systems into scope, and it does not tell you when those systems must be ready. The answer depends on three things: the size of the deal relative to the company's financial reporting, which systems the target uses to produce its transactions and balances, and where the closing date falls relative to the fiscal year end. Pull those facts together before the signing date, not after the close.

Start by identifying the target's financially significant systems: its general ledger, billing, payroll, procurement and any spreadsheets or reporting tools that feed the consolidated numbers. Then decide, with the external auditor's input, whether the target falls inside the audit scope for the year of acquisition. PCAOB AS 2201 (paragraph B14) includes entities acquired on or before management's assessment date in the auditor's scope, so the exclusion that management takes does not automatically carry over to the audit. Confirm that position with the auditor early. Also check whether the acquisition is material enough to require disclosure of changes in ICFR under Item 308(c) of Regulation S-K, and whether Rule 13a-15(d) requires a quarterly evaluation of the changes you make to the target's environment in the meantime. Moving the target onto the parent's ERP or access model is itself a change that the SEC staff lists as potentially material.

Which changes after an acquisition must be disclosed

Once a target joins the group, management has to decide whether the change in internal control is material and what that means for its quarterly evaluation and annual report. These cards cover the decisions that connect the acquisition to ICFR disclosure, and the judgments the organization must make and record itself.

Quarterly evaluation of changes

Rule 13a-15(d) requires management to evaluate, each fiscal quarter, any change in ICFR that has materially affected or is reasonably likely to materially affect it. An acquisition often brings new ledgers, new user populations and new interfaces, so the quarter in which the deal closes is the first point to run this evaluation. Confirm with the finance and IT teams which target changes were made that quarter and record the conclusion, even when the answer is that nothing was material.

Item 308(c) disclosure

Item 308(c) of Regulation S-K requires disclosure of changes in ICFR during the last fiscal quarter that materially affected, or are reasonably likely to materially affect, ICFR. This applies to changes that occur on the acquirer's side as well as changes brought in by integrating the target. Ask counsel and the SEC reporting team to confirm how the change narrative will read in the annual report, and keep the supporting analysis that shows why the disclosure was or was not required.

Changes made before the first report

The SEC staff's Question 7 says the staff would not object if a registrant did not disclose changes made in preparation for its first management report. This position is narrow. It covers preparation work, not changes already in operation that affected ICFR during a reported period. For a target that is being readied for its first management assessment, document which changes were preparatory and which were live, because the two are treated differently.

New information systems as material changes

The same staff FAQ gives implementing a new information system as an example of a change that could be material. An ERP migration, a new general ledger, or a move of the target's billing or close process onto the acquirer's platform can each change access, change management and computer operations at once. Assess the system's role in significant accounts and whether its automated and IT-dependent controls changed, rather than judging by the system's size alone.

Owning and documenting materiality

Whether a change is material is a judgment that management makes and must be able to defend to the external auditor. Management owns this decision, and the auditor evaluates it rather than making it. Record the facts considered, the accounts and controls affected, who reviewed the conclusion and when, and how the outcome was communicated to the audit committee. A consultant can help assemble this file, but the sign-off stays with the company.

How the target's systems enter the next assessment

This sequence takes an acquired business from closing day to a documented ICFR position that management and the external auditor can test. It makes sure the target's financially significant systems are either covered by the acquirer's controls or remediated before they are relied on in a future assessment.

Confirm the target and its significance
Management identifies the acquired business by legal entity and acquisition date, then assesses how significant it is to the consolidated financial statements. The acquirer's finance and legal teams confirm the closing date, since that date starts the one-year window. The output is a short written record naming the business and stating its significance, which is the disclosure the SEC staff FAQ expects if the business is excluded. Confirm with the audit committee and the external auditor that the exclusion approach is agreed before relying on it.
Inventory financially significant systems
Working with the target's finance and IT leads, the acquirer lists every application, database, operating system, directory, network component and hosted service that produces, stores or changes data used in financial reporting. Each entry is tied to the significant accounts and assertions it supports, and to the reports and automated controls the target's staff rely on. The output is a system inventory with owners and hosting locations, including any SaaS or managed providers. Anything unclear is flagged for the next step rather than assumed out of scope.
Map access, change and operations gaps
The acquirer compares the target's practices against its own ITGC design for access to programs and data, program changes and computer operations. Typical gaps include shared or unreviewed administrator accounts, leaver access not removed promptly, production changes made without documented approval, and backups or job monitoring that are not evidenced. Each gap is written as a specific condition with the system it affects. The output is a gap register that separates items to fix before the next assessment from items that need a compensating approach.
Remediate and assign owners
Each gap is assigned to a named owner on the target or acquirer side with a target state described in writing. Remediation usually includes bringing the target's users into the acquirer's identity and access processes, restricting privileged access, adding change approval and testing records, and setting up backup and incident evidence. Where a system will be replaced or retired, management records that decision and the change process used to implement it, since a new information system can itself be a material change. The output is closed remediation items with the evidence that shows each one was completed.
Run design and operating tests
Once remediation is in place, management or internal audit walks through each key control with the people who perform it, then tests whether it is designed to address the risk. Operating tests sample transactions, access reviews, changes and job runs over the period the control was in effect. Test results are compared with the criteria the control owner defined, and the source reports used in testing are checked for completeness and accuracy. The output is a signed test workpaper for each control, with exceptions logged and evaluated.
Evaluate deficiencies and disclosure
Any exceptions are evaluated for severity, including whether they could lead to a material weakness or a significant deficiency under the SEC definitions. Management also considers whether changes made to bring the target's systems into the acquirer's environment materially affected or are reasonably likely to materially affect ICFR, which determines what is disclosed under the quarterly change requirement. The output is a written conclusion on each deficiency and a decision on disclosure, reviewed by the audit committee and the external auditor.
Document the position for the auditor
Management assembles the file the external auditor will need: the acquisition record, the system inventory, the gap register, remediation evidence, test workpapers and the disclosure conclusion. The file shows which entity was excluded and for how long, or which systems were brought into scope at the next assessment. The output is a documented ICFR position that the auditor can trace from the acquisition date through each control, ready for the walkthroughs planned for the next assessment cycle.

Access, change and operations gaps a private target should close

A privately held target often runs financial systems under informal controls that were never designed for an external audit. The gaps below cluster around access, program changes and computer operations, the same areas SEC guidance names for IT general controls. Each card names the evidence an auditor will ask for, and DeployOpen prepares systems and evidence while the organization owns and operates the controls.

Shared and generic administrator accounts

Target teams often share root, domain admin or database owner logins, so no action can be tied to one person. Auditors will ask for a complete list of privileged accounts, the named owner of each, and logs showing who used them and when. The organization must decide which accounts are retired, which are replaced with named administrator accounts, and how any break-glass account is approved and reviewed. Check this first, because every other access test depends on it.

No joiner, mover and leaver process

Without a documented process, access is granted by email and rarely removed when people change roles or leave. Auditors typically sample new hires, transfers and terminations and compare each access grant to an approval and each removal to a termination date. The evidence is a request and approval record, a periodic access review signed by a manager who understands the access, and removal tickets dated against HR records. Ask the target for its termination list from the last year and reconcile it to active accounts.

Developers with direct production access

In many private companies, the same engineers write code, deploy it and hold credentials to the production database. This removes the separation that makes a change review meaningful. Auditors will look for role assignments, deployment permissions and any exception granted for a specific fix. The organization should define who may promote code, restrict production write access to a small group, and keep the approval record that links each release to a reviewer.

Untracked changes and emergency fixes

Configuration edits, scripts and hotfixes made directly on servers or in application settings often leave no ticket. Auditors will ask for the population of changes in the period, sampled changes traced to requests, testing evidence and approval, and a separate list of emergency changes with after-the-fact review. Ask the target how many production changes it made last quarter and whether each one can be matched to a ticket. Changes with no ticket are the most common finding in this area.

Direct database updates without logs

Finance teams sometimes correct balances, reprocess transactions or fix records with direct SQL statements run by an administrator. Unless database auditing is on and these updates are approved, the change bypasses application controls entirely. Auditors will request database audit logs, a list of users with update rights and a sample of manual updates with business justification and approval. The organization should decide which manual updates are allowed, who authorizes them and how each one is logged and reviewed.

Unreviewed backups and job monitoring

Private targets often rely on a scheduled job that nobody checks and backups that have never been restored. Auditors will look for job schedules, failure alerts with documented follow-up, backup completion logs and at least one restore test with its result. For each financially significant batch process, confirm who monitors it, what happens on failure and where the record of resolution is kept. A backup that cannot be shown to restore is weak evidence for the recovery control.

Undocumented third-party hosting

A target may run its ledger, payroll or reporting tools with a hosting provider or managed service under a contract that does not address controls. Auditors will ask for the provider list, the contracts, and the provider's independent assurance report or other evidence about its controls, along with how the target reviews that evidence. The organization still owns its access and change controls on the provider's platform. Ask the target to list every system holding financial data and who operates each one.

Who owns the controls, who prepares evidence and who tests them

The acquirer's finance and IT leadership remain responsible for management's ICFR assessment for the parent. During the exclusion window, they decide whether the target is excluded, document the basis for that decision, and confirm that the target's significance is identified in the report where the exclusion is used. They also decide whether any change in the parent's own controls, such as integrating the target's data into a consolidated ledger, is a change that must be evaluated each quarter.

Exclusion decision: Finance leadership documents which acquired business is excluded, from which acquisition date, and why its significance is stated as it is.
Quarterly change evaluation: IT and finance review integration changes each fiscal quarter to judge whether they materially affect or are reasonably likely to materially affect ICFR.
Disclosure judgment: Leadership decides how material changes are described under Item 308(c) of Regulation S-K.
Integration owner: A named owner tracks when the target's systems enter the parent's assessment and what must be ready by then.
Vendor and contract ownership: The parent keeps responsibility for any provider contracts it signs as part of integration.

Confirm with your auditor which parent controls must be evaluated during the exclusion period and which integration changes they expect to see documented.

Options for the target's first year: exclude, bring in early or run a readiness review

This table compares the three paths an acquirer can take for a newly acquired business's systems during its first year. Read each row as a trade-off between effort now and exposure at the next assessment, and use the last row to see what stays open under every option.

Option	When it fits	Effort it takes	What it leaves open
Rely on the one-year exclusion	The target's systems do not feed significant accounts, or the acquirer has no near-term plan to rely on them for ICFR	Low at the acquirer: document the business, its significance and the exclusion decision for the annual report	Gaps in the target's access, change and operations controls can persist; the exclusion is not a reason to ignore them, and it cannot extend beyond one annual report
Bring key target systems into scope early	The target's ledgers, interfaces or reports feed material accounts, or the deal changes how those accounts are processed	High: mapping target controls to the acquirer's ITGC design, migrating access and change processes, and testing operation before year end	Integration work can itself be a material change that must be evaluated and possibly disclosed, and it may run late against the assessment date
Run a readiness review before the next assessment	The exclusion will end, or management expects to rely on target controls in the next annual report	Moderate: a gap assessment of target access, change and operations controls, followed by remediation plans with owners and dates	Findings may still be open at year end, so management needs a clear view of which deficiencies could be material weaknesses
Confirm with the auditor and counsel	Any option, especially where the target is significant or the timeline is tight	Low to moderate: written positions on exclusion scope, change disclosure and the evidence the auditor expects	Auditor views on specific facts can differ, so confirm the approach in writing before the assessment date

Questions buyers ask about SOX ITGCs after an acquisition

Does the one-year exclusion remove an acquired business from the auditor's scope?

No. The exclusion applies to management's assessment, not to the external auditor's work. Under PCAOB AS 2201, the audit scope includes entities acquired on or before management's assessment date, so the auditor still considers the target's controls when it forms an opinion on the combined company. Management's exclusion must still identify the acquired business and indicate its significance. Confirm with the external auditor early how it plans to treat the target's systems in the year of acquisition, because the auditor's view of the target's IT general controls can differ from management's scoping decision.

Can an acquired business stay outside the ICFR assessment for a full year?

Yes, but only for up to one year from the acquisition date and in no more than one annual report. The SEC staff FAQ allows management to exclude the business during that window if it is identified and its significance is disclosed. After that report, the target must be brought into management's assessment. Plan the integration timeline around this limit. If the target's systems carry financially significant data, waiting until the last months of the window before testing its access, change and operations controls leaves little room to fix gaps before year end. Confirm the acquisition date and the significance analysis with counsel and the auditor.

What must a public company disclose in its 10-K after an acquisition?

Management must disclose changes in ICFR during the last fiscal quarter that materially affected, or are reasonably likely to materially affect, ICFR under Item 308(c) of Regulation S-K. Rule 13a-15(d) also requires management to evaluate such changes each fiscal quarter. Bringing a target onto the acquirer's access, change or operations controls can count as a change, and the SEC staff FAQ gives implementing a new information system as an example of a change that could be material. The staff would not object if changes made purely in preparation for the first management report were not disclosed, but counsel should decide where that line falls for each deal. Ask counsel to review the disclosure language and the exclusion statement together.

What should a private acquisition target fix first in its IT general controls?

Start with the controls that protect financial data and the processing that produces financial reports. In practice, the first gaps to close are usually:

Access: a current list of users with privileged rights to the finance applications, databases and servers, removal of leavers, and periodic reviews that someone signs.
Program changes: a documented approval path for changes to financially significant systems, with separation between developers and production access.
Computer operations: job scheduling records, backup and restore testing, and incident and problem logs that show how failures were handled.

Document each control so an assessor can trace it from design to evidence. Confirm the scope of in-scope systems with the acquirer's team before fixing anything, since the acquirer's auditor will decide what evidence it needs.

Who pays for ITGC gap remediation after an acquisition?

The party that owns the target's systems pays for the work, and that is usually the acquirer once the deal closes. Costs come from several places: internal staff time, changes to identity and access tooling, logging and backup work, and outside help for assessment or remediation. Costs are mostly one-time for initial fixes and recurring for reviews, evidence collection and testing each year. Costs rise with the number of in-scope applications, the number of privileged users, how many systems are customized or hosted with third parties, and how much documentation is missing. Ask any provider for a written scope that lists the systems, controls and deliverables before agreeing to a price. Deal terms may also allocate these costs, so confirm the allocation with counsel.

Can the target's own team handle SOX ITGC work after an acquisition?

Often yes, but only if the team has people who understand both the financial processes and the technology, and if it has time that does not compete with integration work. Management owns the controls, so the acquirer's management and internal audit must be able to rely on the evidence the team produces. Many organizations keep ownership in-house and bring in outside help for specific gaps, such as building the testing evidence, documenting design or configuring logging. An independent auditor or assessor issues any reports, so an outside partner can prepare evidence but cannot provide the audit opinion. Confirm the division of responsibilities with the external auditor before the team starts.

How DeployOpen prepares an acquired target's systems for SOX review

DeployOpen works with the target's systems, not the acquirer's audit opinion. We scope the target's financially relevant platforms, build or harden the access, change and operations controls a private company usually lacks, and document them so management can decide what enters its next assessment. Management owns the controls and the conclusions, and only an independent auditor issues opinions.

How we scope

Written scope agreed before work starts, listing the target systems, environments and reports in question
Review of which financial applications, databases and infrastructure feed the target's reporting processes
Identification of the acquired business's significance and the dates management needs to document for its exclusion

How we build

Access controls on financially relevant systems: provisioning, least privilege, periodic review and removal of leavers
Change management with documented approval, testing and separation of duties before production deployment
Backup, recovery, job monitoring and incident handling records that show the operations controls run as designed

How we hand over

Control descriptions, configuration baselines and evidence checklists that the target's management can own after handover
Test-ready evidence packages organized by control, with the gaps and remediation status stated plainly
Walkthrough sessions with the target's finance, IT and internal audit staff to confirm they can explain each control

How we support

Ongoing support and continuous testing are available as a retainer after the fixed-scope work ends
Support for the change, access and operations evidence that the acquirer's auditors may request for the next assessment
Clear confirmation with the client's auditor and internal audit on which evidence they will accept before work is finalized