Remediating SOX ITGC deficiencies before year end

Remediating SOX ITGC deficiencies before year end: what it takes to count

A fix to a failed access or change control counts for the year-end assessment only if the replacement control is in place early enough to operate and be tested before the assessment date. The organization owns that work. An implementation partner can design the new control, build the configuration, and assemble the evidence, and an independent auditor will test it, but neither can decide that the control is operating or sign off on the remediation. When a CFO or CIO learns weeks before fiscal year end that a user access review or change approval step has failed, the first question is not how to patch the gap but whether a new control can run and leave testable evidence before the assessment date. Under PCAOB AS 2201 (paragraph 53), if management replaces a control before the assessment date and the new control has operated long enough to be tested, the auditor need not test the superseded control for the ICFR opinion. The phrase "long enough to be tested" is the constraint that matters.

The answer depends on four things. The first is control design: a quarterly access review can be replaced in a few weeks only if the population, reviewer and sign-off are already defined, while a change to a system's logic may need a full testing cycle. The second is how many months remain, because the auditor weights evidence from testing closer to the assessment date and over a longer period (AS 2201, paragraph 52), so a new control that has run for only one cycle may not carry much weight. The third is whether the superseded control still operated during the period, since the auditor will still examine it for the time it was in place. The fourth is severity: a control deficiency that management judges to be a material weakness changes the disclosure path, not just the remediation plan.

Before committing to a date, confirm with the external auditor in writing which evidence they will accept, how many operating instances they expect, and whether the superseded control must still be tested for earlier months. Then map each open deficiency to its replacement control, its first operating date and its evidence owner. Ask the implementation partner for a written scope that states which systems, reports and approval steps are covered, and keep management's own assessment, not the consultant's summary, as the record of what was remediated.

The remediation sequence from failure to tested control

The sequence turns a failed IT general control into a replacement control that has operated long enough for management and the external auditor to test it before the assessment date. Each step produces a record the auditor can follow from the original failure to the final evidence.

Confirm the deficiency and its root cause
Management confirms that the control failed to operate as designed, then traces why it failed, such as a missing approval step, an access role granted outside the process, or a change deployed without testing. The owner of the control, the IT lead and the SOX program team agree on the facts and record which financially significant systems and reports are affected. The output is a root cause memo with dated examples and the population of exceptions. The step is done when the team can state what failed and why in terms the auditor would accept.
Evaluate severity through dependent controls
Because an ITGC failure matters through the automated and IT-dependent controls that rely on it, the team lists every business process control that depends on the failed control and assesses whether misstatements could go undetected. Management reaches a documented conclusion on whether the deficiency is a control deficiency, significant deficiency or material weakness, using the definitions in the SEC guidance and PCAOB standards. The output is a severity evaluation memo signed by the control owner and reviewed by the disclosure committee. The step is done when each dependent control has a recorded conclusion.
Design the replacement control
The team writes a control design that addresses the root cause, names the owner, states the precision of the review or the restriction being enforced, defines the population and frequency, and specifies the evidence the control will leave behind. Compensating controls may be considered in the design but should be documented as separate controls with their own precision requirements. The output is a control design document and a risk and control matrix update. The step is done when the design has been reviewed by the control owner, the SOX program lead and, where appropriate, the external auditor.
Implement and configure the control
Engineering or the system owner builds the change in the production environment, such as a role removal, a workflow approval gate, a monitoring rule or a revised change procedure. Each implementation step is recorded in a change ticket with requester, approver, test results and deployment date, so the change itself is controlled. The output is the completed change record and configuration evidence, such as screenshots, system exports or pipeline logs. The step is done when the change is live and the ticket is closed with the approvals attached.
Operate the control and retain evidence
The new control runs in normal operations, and the owner performs each occurrence exactly as designed. Every execution produces retained evidence, such as signed review sign-offs, system-generated reports with timestamps, or approval records, stored in a location with restricted access. The output is an evidence log that lists each occurrence, the evidence location and the reviewer. The step is done when the control has operated for enough occurrences and periods to be tested, which the auditor's standards tie to the period and timing of testing.
Test the replacement control as management
Management, usually through the SOX program team or internal audit, tests the new control's design and operating effectiveness before the assessment date. The tester selects samples from the operating period, examines the evidence, checks precision and documents exceptions and their causes. The output is a test workpaper with the population, sample selection, procedures performed and conclusion. The step is done when testing shows the control operated effectively, or when any exceptions have been evaluated and the design has been corrected.
Hand the evidence to the auditor and close the superseded control
The team gives the external auditor the root cause memo, the severity evaluation, the design document, the change records, the evidence log and the management test workpapers. The superseded control is formally retired in the control matrix with a date and a reason, so the record shows when it stopped being the key control. The output is an auditor request response package and an updated control matrix. The step is done when the auditor confirms receipt and any questions are answered in writing.

What happens to the superseded control

Replacing a failed ITGC does not erase the failure for the period it covered. A superseded control still matters for every part of the year in which it operated, so management must still evaluate whether the deficiency existed, how far it reached and how severe it was. For example, if a privileged access review was missed for three quarters before a new quarterly review went live, the earlier quarters remain in the evaluation even though the new review now passes. The replacement fixes the future, and the assessment still has to account for the past.

Removing a control from the design is different from stopping its evidence. The design change is the decision to retire the old procedure, while the evidence is the record that it ran, such as access review sign-offs, change approval tickets or job logs. Teams often disable a report, reassign a reviewer or change a workflow tool and lose the trail that shows what happened before. Before retiring anything, confirm where each superseded control's evidence is stored, who can still retrieve it, and how long your retention schedule keeps it. Keep prior-period evidence in a read-only location so the deficiency evaluation and any auditor request can be answered from the original records.

Under AS 2201 (paragraph 53), if management replaces a control before the assessment date and the new control has operated long enough to be tested, the auditor need not test the superseded control for the ICFR opinion. That point only helps when the new control has a real operating history, so plan the cutover date with the test window in mind. Confirm with your audit firm how many occurrences of the new control they will expect to see and whether the replacement date gives them enough of them. The earlier period still needs its own evaluation, so document the replacement date, the reason for the change and the conclusion on the prior deficiency together.

What must be in place before the year-end test

A replacement control only helps the year-end assessment if it exists, has an owner, runs on real systems and leaves evidence an auditor can sample. The five items below connect design, ownership, configuration, evidence and planning, and each one can be checked before fieldwork starts.

Documented design of the replacement control

Write down what the new control does, which risk it addresses, which system and population it covers, who performs it, how often, and what a reviewer looks for. Check that the design would prevent or detect the failure the old control missed. Ask whether a reviewer could re-perform the control from the document alone. Illustrative example: a quarterly user access review that lists every privileged account in the financial application and states how terminated users are removed.

Named owner and documented approval

Assign one accountable owner for the control and one reviewer or approver who is independent of the work being reviewed. Record the approval date and the approver's authority in the control documentation. Confirm the owner knows the operating cadence and has the access needed to perform the review. An approval signed after the control has already run weakens its credibility with the auditor.

Configured system settings and access changes

Confirm that the replacement control is backed by actual configuration in the financial applications, databases and infrastructure, not only by a policy. Examples include enforced password and approval settings, removed excess roles, or change tickets that the change tool requires before deployment. Export the configuration or screenshot it with a date and the system name. Note which changes were made in the last fiscal quarter, because those may need disclosure review.

Defined evidence trail

List the records the control produces: tickets, approvals, system logs, review sign-offs, exception reports and follow-up on exceptions. Decide where each record is stored, who can alter it, and how long it is kept. Check that a sample can be pulled for any date in the operating period without reconstruction. Evidence that exists only in email threads or personal folders is hard to rely on in an audit.

Management test plan with a date

Write a test plan that states the sample size, population, period covered, the tester, and the date by which management will complete its own test of the new control. Testing that operates long enough and closer to the assessment date gives stronger evidence, so schedule the test with that in mind. Ask the auditor early which periods and samples they expect. Keep the plan and results in the same evidence repository as the control records.

Who owns each part of the fix

Management owns the internal control over financial reporting, including every ITGC fix. Management decides how the control will be redesigned, approves the change, evaluates whether the original failure is a deficiency, significant deficiency or material weakness, and determines when the replacement control has operated long enough to be relied on. The certifying officers then sign the Section 302 certifications and the management report under Section 404, and they stand behind those statements whoever built the systems.

Control ownership: Name an accountable owner for the replacement control and for the superseded control's retirement, with a documented effective date.
Deficiency evaluation: Document the severity analysis, including the IT-dependent and automated controls that rely on the failed ITGC.
Operating history: Decide and record when the new control has run long enough to test, and when it will be evidenced for the assessment date.
Disclosure judgment: Assess whether the change materially affected or is reasonably likely to affect ICFR, which drives quarterly disclosure under Item 308(c).
Certifications: Confirm that the officers have evaluated controls within the required window and have reported deficiencies to the auditors and audit committee.

Check that the minutes, sign-offs and deficiency memos show management's own reasoning, not only a vendor's summary.

When a fix must be disclosed as a change

A remediation is itself a change in internal control over financial reporting, and it can trigger disclosure even when the deficiency it fixes was never reported as a weakness. Under Rule 13a-15(d), management must evaluate, each fiscal quarter, any change in ICFR that has materially affected or is reasonably likely to materially affect it. Item 308(c) of Regulation S-K then requires the annual report to disclose changes made in the last fiscal quarter that materially affected, or are reasonably likely to materially affect, ICFR. For IT general controls, the practical question is whether replacing an access review, a change approval workflow or a privileged account process alters how financially relevant controls operate, not whether the fix looks large to the IT team.

Several remediation steps can meet that threshold. Moving a change approval step into a new ticketing system, reassigning administrator rights in a financial application, or introducing a new monitoring review that management relies on for a key control can each change the control environment. Document the quarter in which each change went live, the control it affects, and the reason it was made. Confirm with the finance and internal audit leads whether the change is one the company would describe as material, and record that conclusion with the quarterly evaluation. Teams often overlook changes made to superseded controls, so include the retirement date of the old control in the same record.

Counsel and the external auditor decide the wording of any disclosure, and management should not draft it alone. Ask counsel to review whether the change belongs in the annual report, and ask the auditor how the change interacts with the deficiency evaluation and the remediation narrative. Confirm the fiscal quarter boundaries and the dates your remediation evidence carries, because those dates determine which quarter a change falls in. Plan for the disclosure to be consistent with the certifying officers' statements under Section 302, which cover significant changes and the evaluation of controls within 90 days before the report.

What usually delays a fix or lets it fail testing

Most failed ITGC remediations do not fail on the technical fix itself. They fail on paperwork, operating history, or changes that route around the new control. The cards below cover the four pitfalls we see most often and a practical step to avoid each one.

Replacement configured but not documented

The new control works in the system, but there is no updated narrative, risk and control matrix entry, or procedure that describes who performs it, how often, and what evidence it produces. An auditor testing the control against the documentation will find a gap even when the configuration is sound. Before the control goes live, write the control description with its owner, frequency, precision threshold, and evidence location, then have the control owner sign off. Ask the auditor whether they want the design walked through before operating testing starts.

Control runs without a retained approval

A review or approval step happens in chat, email, or a meeting, and nothing is kept in a form the auditor can sample. The reviewer may have done the work correctly, but without a dated record showing who approved what and when, the operation cannot be shown. Choose a system of record for each approval, such as a ticketing workflow or an access review export, and confirm that it captures the reviewer, the population reviewed, the outcome, and any follow-up. Test the retention by pulling a sample yourself before the auditor does.

Late start leaves thin operating history

A new control needs enough operating occurrences before the auditor can test it with confidence, and the amount depends on the control frequency and the auditor's sample expectations. Starting the new control close to the assessment date can leave too few instances, which forces either a deficiency finding or a scramble to reconstruct evidence. Agree the expected frequency and minimum sample with the external auditor early, and schedule the go-live date so that the control has run through the period they will sample. Ask the auditor how they handle a control that changed mid-year.

Changes that bypass the new control

Teams often keep using the old path to make changes after the new control is live, through emergency fixes, direct database updates, or shared administrator accounts. Any change that skips the new control undermines its operating effectiveness, and the auditor will look for these exceptions in system logs. Review privileged activity and change records for the period, reconcile them against approved tickets, and document each emergency change with after-the-fact approval. Restrict the access that makes the bypass possible so the new control is the only route.

Questions finance and IT leaders ask about ITGC remediation

Does an ITGC fix have to be finished before year end?

No single date is written into the rules, but the fix has to be in place and operating long enough for the auditor to test it before management's assessment date. Under PCAOB AS 2201, if management replaces a control before the assessment date and the new control has operated long enough to be tested, the auditor need not test the superseded control for the ICFR opinion. Testing over a longer period and closer to the assessment date gives more evidence, so a late fix may leave too little operating history to rely on. Confirm the operating period your auditor expects with them early, and plan the change window backward from that date.

Can management remediate an ITGC deficiency without outside help?

Yes, management owns its controls and can redesign, implement and evidence them internally. Outside help is usually a question of capacity and skills. Teams often need help with access role design, change pipeline configuration, evidence collection for a defined operating period, or documentation that matches what the system actually does. Management still has to evaluate the deficiency, decide the remediation design, approve it and test it. An implementation partner can prepare systems and evidence, but it does not decide whether a control is effective or issue any opinion on it.

What does an implementation partner do and what does it not do?

An implementation partner helps build and configure the remediated control, prepares the systems, and organizes the evidence the control produces. For example, a partner might configure role-based access reviews in a self-hosted identity platform and export review records for the period under test. A partner does not own the control, sign management's assessment, or issue audit reports, attestations or opinions. Only the company's management and the independent external auditor fill those roles. Ask any provider to put this split in the written scope so both sides know who signs what.

What evidence does the external auditor need to accept a remediated control?

The auditor needs evidence that the new control was designed to address the risk and that it operated consistently over the period it is tested. Typical evidence includes the written control description, the approval records, system-generated logs or reports that show the control ran, samples of completed reviews or approvals, and documentation of how exceptions were investigated. Auditors also check that the reports used in the control are complete and accurate. Agree the sample population and the evidence format with the auditor before the new control goes live, so the operating records are collected in the form they will test.

How is the severity of an ITGC deficiency decided?

Severity depends on whether a misstatement could go undetected or uncorrected, not on how often the failure happened. SEC guidance says that when management finds a control is not operating effectively, a deficiency exists and must be evaluated to determine whether it is a material weakness. PCAOB AS 2201 defines a control deficiency as a design or operation of a control that does not let management or employees prevent or detect misstatements on a timely basis. Because ITGCs support automated and IT-dependent controls, the evaluation looks at which financial reporting controls rely on the failed ITGC and whether a compensating control could catch errors in time. Document this analysis as it happens, since the severity conclusion drives disclosure.

How does DeployOpen scope ITGC remediation work?

DeployOpen scopes this work as a fixed-scope engagement, with the systems, controls, evidence and deliverables agreed in writing before work starts. The scope usually starts with the deficiency statement, the affected applications and infrastructure, the controls that depend on them, and the operating period the auditor will test. Timelines follow from that written scope rather than from a standard package. DeployOpen does not publish a price list, so a quote follows from the scope. Ask for the scope document, the list of responsibilities for management and DeployOpen, and the evidence handover format before you sign.

What drives the cost of remediating an ITGC deficiency?

The main cost drivers are the number of systems and controls affected, how much of the environment must be redesigned versus configured, how much evidence history must be produced, and how many internal and external parties must review the change. Costs are partly one-time, covering design, configuration and documentation, and partly recurring, covering periodic reviews, monitoring and evidence collection in later years. Internal staff time is usually the largest hidden cost. Request a quote that separates one-time implementation from recurring operation, lists the systems in scope, and states which evidence tasks remain with your team. The 2020 SEC estimate of about $210,000 per year applies only to issuers newly exempt from the Section 404(b) auditor attestation (Release 34-88365), not to remediation costs.

How DeployOpen works on this

DeployOpen works on remediation as an engineering and evidence project inside your own infrastructure, not as a finding to close on paper. We scope the affected systems and the controls that depend on them, build or harden the replacement control so it can operate and be tested before the assessment date, and document what the organization owns. Independent auditors remain responsible for testing and opinions.

How we scope

The written scope names the deficient ITGC, the IT-dependent controls it affects, and the systems involved.
We confirm with your team which replacement control will be in place and when it must start operating.
Scope, deliverables and timelines are agreed in writing before any work starts, as engagements are fixed-scope.

How we build

We implement or harden the replacement control on the self-hosted open-source platform in your own cloud or data center.
Access, change approval and monitoring configurations are set up so they produce records an auditor can sample.
We test the new control end to end and keep the superseded control documented until your auditor agrees how it is handled.

How we hand over

You receive control descriptions, configuration baselines, runbooks and the evidence paths for each operating instance.
Remediation records show the deficiency, the change made, the operating dates and the owners who approved them.
Your management, internal audit and external auditor decide the conclusions; DeployOpen prepares the systems and evidence only.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the remediation is handed over.
Retainer support can keep the control operating and its evidence current for later quarterly change assessments.
Confirm with your auditor which evidence periods and interim samples they will request before the scope is signed.

Remediating SOX ITGC deficiencies before year end