When does a compensating control reduce a SOX ITGC deficiency?
A compensating control reduces the severity of an ITGC deficiency only if it operates at a level of precision that would prevent or detect a misstatement that could be material, as PCAOB AS 2201 (paragraph 68) requires. Management owns the control and must design, document and run it, but the external auditor decides whether it actually mitigates the deficiency. A control that merely exists, or that runs on a calendar without a defined threshold, usually does not meet that test. The first question to answer is therefore not whether a compensating control exists, but whether someone can show that it would have caught an error large enough to change a reported number.
The answer depends on the financially significant reports and on the automated or IT-dependent controls that rely on the failed ITGC. Start by listing each affected application, database or interface, then trace which账户 balances, disclosures and reconciliations depend on it. For a failed change management control over an ERP configuration, for example, the relevant question is whether a reviewer of the affected accounts would notice an unauthorized change to a calculation before the period closes. Auditors also consider the reasonable possibility that the failure goes undetected, together with the size of the potential misstatement under AS 2201 (paragraph 63). Preventive and detective controls are both allowed under AS 2201 (paragraph A8), but a detective review that runs quarterly against a threshold set far above materiality will often be judged too imprecise. Confirm with your auditor, early and in writing, what precision they expect before you invest in a new review.
Which detective reviews usually get tested as compensating controls
Management often proposes a detective review when a preventive ITGC is weak or missing. Auditors accept these reviews only when the reviewer compares a complete population against an independent source at a precision that could catch a material misstatement, so each card names what is compared, the precision needed and the evidence kept.
Privileged and super-user access reviews
The reviewer compares the current list of accounts holding administrative, super-user or database owner rights against an approved roster from the access owner. Each account needs a documented business reason and the reviewer confirms that unexpected grants were removed. Because the list is generated by a system, the reviewer must test that the extraction includes every privileged role, including direct database and operating system accounts. Keep the signed review, the source report and the removal tickets.
Change log review against production population
The reviewer selects changes from the complete population of production deployments for the period and traces each to an approved ticket, a test result and an approver who is independent of the developer. Gaps in the sequence, such as deployments with no ticket, are investigated individually. The reviewer should agree the population to the deployment tool's full output rather than to a sample the tool happened to export. Retain the population report, the selection and the traced documents.
Program change reports reconciled to approvals
This review reconciles the change report that lists compiled programs or configuration versions in production to the approvals on file. Any version found in production without a matching approval is an exception that must be explained and assessed. The reconciliation only mitigates if the reviewer can show that the change report comes from a system the developers cannot edit. Retain the reconciliation workpaper, the report and the exception follow-up.
Terminated user access reviews
The reviewer compares the list of users terminated during the period, supplied by HR, against active accounts in each in-scope application, database and directory. Any terminated person with an active or recently used account is an exception. The timing matters: a review that runs months after separation may not prevent unauthorized postings in the meantime, so confirm the review frequency and the lag between termination and detection. Keep the HR extract, the account listings and the disablement evidence.
Database and batch job exception reviews
The reviewer examines the exception log for failed, rerun or manually altered batch jobs and database changes made outside the normal application path. Each exception is matched to a documented resolution and a reviewer's sign-off, and the reviewer checks that the log covers every scheduled job in scope. Exception reviews run late in the cycle often fail the timeliness test, so confirm how quickly issues surface. Keep the job schedule, the exception log and the resolution records.
Compilation date and system-generated report reviews
PCAOB AS 2201 lists reports of compilation dates for programs placed in production as evidence that controls within a program have not changed. The reviewer compares each compilation date against the approved change window and confirms that the report is available and reliable. The reviewer must also test the report's completeness and accuracy, because a report that omits programs proves nothing. Keep the report, the test of its completeness and the comparison workpaper.
Why monitoring that finds issues late may not mitigate
A detective control that runs quarterly, monthly or only after year end may not offset an ITGC deficiency when the deficiency could produce a misstatement earlier in the period. The reason is timing. If an unauthorized change reaches a production interface in March and a reconciliation review catches it in July, the financial data processed in the intervening months may already have been posted, reported in an interim period or used in a management decision. The question an auditor asks is whether the control would detect a misstatement in time to correct it, not whether the company eventually notices the problem.
The distinction that matters is between detecting a failure and preventing a misstatement. PCAOB AS 2201 recognizes that controls over financial reporting may be preventive or detective, and a compensating control only reduces severity if it operates at a level of precision that would prevent or detect a misstatement that could be material. A review that lists all production changes for a period may show that an unauthorized change occurred, yet still fail to show that the change did not affect balances before the review ran. For the organization, this means documenting the review frequency, the population it covers, the threshold for investigation and what it would find about the period between the change and the review date.
Auditors evaluate this in context, considering the financial statement accounts affected, the volume of transactions, how quickly errors would accumulate and whether other controls would catch the same misstatement sooner. Management should not assume a late detective control qualifies. Confirm with the external auditor, before year end, which period the review must cover to be relied on, and write down the analysis: the exposure window, the transactions that could have been affected, and why the control still provides adequate protection or why it does not. A documented conclusion that a late review is insufficient is more useful than an unsupported claim that it mitigates.
How the answer changes by control situation
A failure in access to a financially significant application is the situation where a compensating control is most often proposed and least often accepted on its own. If users hold excessive or unreviewed access, the risk is that someone can post or alter financial data without detection. A management review of a user access listing can help, but only if the reviewer has the right information, the review happens often enough, and the reviewer would notice an inappropriate entitlement that could produce a material misstatement. A periodic review that is performed quarterly and compares names against a roster may not meet that bar.
- Plausibility: A detective review of privileged or high-risk roles, such as journal entry or payment release, is more credible than a broad review of every user.
- Precision: The reviewer should compare the access listing against an authorization source and investigate exceptions, and the review should be documented with a threshold or population.
- Evidence of activity: Auditors will ask whether the reviewer also looked at the activity logs for those users during the period, since access without use is a different risk.
- Timing: A review that runs after a misstatement could have occurred may not mitigate it, so auditors will ask how often the review runs.
- Interaction with other controls: Auditors will ask whether the business reconciliation or approval controls would catch an unauthorized entry.
Before relying on a compensating control, confirm with your auditor which population, frequency and precision they will accept for your specific application.
A failure in program change control means that a change to a financially significant application, configuration or interface may have reached production without authorization or testing. The compensating control question here is whether management can detect unauthorized changes before they affect reported numbers. A post-change review of a change log is a common candidate, yet it is often the weakest one because it depends on the completeness of the log and on whether the reviewer can see changes made outside the ticketing process.
- Completeness of population: Auditors will ask how the organization knows the change log includes every production change, including direct database and configuration edits.
- Reviewer precision: A reviewer who samples tickets is less persuasive than one who reconciles production change records against approved tickets.
- Detection of reversal: Monitoring that reports a change only after it has been in production for a period may not prevent a misstatement from being posted in the meantime.
- Reports and calculations: Where a change alters a calculation, auditors may ask for a comparison of key outputs before and after the change.
- Program compilation dates: Auditors will look for reliable compilation date reports showing that programs have not changed, as AS 2201 paragraph B31 describes.
Confirm with your auditor whether they will rely on a detective reconciliation for change control, and what population they will test.
A failure in computer operations, such as batch processing, means that a scheduled job may have failed, run incompletely, or processed data incorrectly. Because batch failures often produce visible errors, a compensating control can sometimes be strong, provided the downstream reconciliation is independent of the job itself. The key question is whether a control catches a missing or inaccurate batch before the financial statements are affected, and whether that control operates at a precision level that would detect a material misstatement.
- Reconciliation of control totals: A review that compares record counts and dollar totals from the source system to the output or ledger is a common mitigating control.
- Timing of the review: The reconciliation should run before the period is closed, not weeks later, so that errors can be corrected in the period.
- Independence: The person performing the reconciliation should not be the person who schedules or runs the job.
- Exception handling: Auditors will ask how exceptions are investigated, resolved and documented.
- Scope of failures: Auditors will ask whether a failed job could be partially successful without triggering an alert, since silent partial failure is harder to detect.
Specify with your auditor which totals and tolerances will be used and how they will test that the reconciliation operated throughout the period.
A smaller company with few accounting staff often cannot separate duties in the way larger organizations do. The note to AS 2201 paragraph 42 recognizes this situation: where duties cannot be segregated, a company may implement alternative controls, and the auditor evaluates whether those alternative controls are effective. The alternative is not automatically acceptable because it is different from the standard design. The auditor will test whether it works in practice and whether it would catch the kind of error or misstatement the segregation was meant to prevent.
- Alternative design: Common alternatives include a second-person review of significant transactions, independent review of system access reports, or a reconciliation performed by someone outside the process.
- Evidence of review: The reviewer's sign-off, the population reviewed and the exceptions found should all be documented.
- Management oversight: Auditors may ask whether a senior person with sufficient knowledge reviews the results and retains evidence of that review.
- Effectiveness testing: The auditor will test whether the alternative actually detects errors, which may require sample transactions or seeded exceptions.
- Limits of the alternative: An alternative that cannot detect a misstatement of a material size will not reduce severity, however well documented.
Ask your auditor early whether your proposed alternatives will be accepted before you rely on them for the year-end assessment.
What a compensating control costs and who pays for it
This table lists each cost component of running a compensating control for an ITGC deficiency, who is paid for it, whether it is one-time or recurring, and what drives it up. Use it to frame questions for internal owners, consultants and your external auditor before you commit budget. No figures are given here, so ask for scoped estimates in writing.
| Cost component | Who is paid or carries the cost | One-time or recurring | What drives it up |
|---|---|---|---|
| Control owner time to design and run the review | Internal control owner (salaried time, or contractor if backfilled) | Design is one-time; running the review is recurring | Number of systems in scope, frequency of the review, and how many manual reconciliations are needed |
| Reviewer time | Independent reviewer, such as a finance manager or IT leader | Recurring for each review cycle | Volume of access grants or changes to review, and whether reviewers must chase missing context |
| System report development | Internal IT or platform engineers, or the implementation partner | One-time build, with recurring maintenance when systems change | Number of data sources, custom reports needed, and how often application or schema updates break them |
| External consultant time to design and document the control | Consultant, billed under the agreed written scope | One-time for design and documentation; re-engagement when the control changes | Complexity of the deficiency, number of accounts affected, and gaps in existing documentation |
| External auditor time to test design and operating effectiveness | Independent auditor, billed by the audit firm | Recurring each audit cycle, with extra work for remediation testing | Precision of the review, sample sizes needed for operating tests, and quality of the evidence retained |
| Tooling and evidence storage | Software vendor or internal platform budget | Licensing or hosting recurs; configuration is one-time | Number of integrations, retention requirements, and whether reports must be generated automatically |
| Legacy control retirement and parallel running | Internal owners and auditors during transition | One-time, during the period both controls operate | Length of the overlap needed before the new control is tested and how many periods must be evidenced |
How to build and evidence a compensating control
This sequence turns an identified ITGC deficiency into a documented detective control with a defined precision, complete evidence and an auditor-reviewed design before year end, so that it can be tested and considered when judging severity.
Identify the deficiency and its dependent controls
Start from the ITGC deficiency and list every financial reporting control that relies on it, such as automated calculations, interfaces, reports used in review controls and configured approvals. Management owns this analysis, and the output is a written list of affected controls tied to the ICFR risk each one addresses. Confirm the list with the control owners so no dependent control is missed before the next step.
Quantify affected accounts and assertions
For each dependent control, identify the financial statement accounts, disclosures and assertions it covers, such as existence, completeness, accuracy or valuation. Estimate the potential magnitude of misstatement in each area, since severity depends on both the reasonable possibility of failure and the size of the potential misstatement. The output is a table linking each deficiency to accounts, assertions and a magnitude range that the compensating control must be able to catch.
Define the threshold and the population
Set the precise criteria that will trigger investigation, such as a dollar threshold, an exception type or a set of high-risk transaction categories, and define the population the review will cover, including whether it is every transaction or a filtered subset. Document the logic that connects the threshold to the magnitude identified in the prior step. The output is a written threshold and population definition that a reviewer and the auditor can read without asking the design owner.
Design the detective review and its precision
Design the review that will examine the population against the threshold, specifying who performs it, how often, what they compare against, and what they must document. Explain why the review operates at a level of precision that would detect a misstatement that could be material, and note that the review is detective, not preventive. The output is a control narrative and a precision rationale that both state how a misstatement would be found and in what timeframe.
Validate completeness and accuracy of the report
Because the review relies on system reports, confirm that each report is complete and accurate before the reviewer uses it. Retain evidence of the report's source, parameters, run date and record counts, and reconcile totals to the system of record. Where the review relies on program version evidence, such as compilation dates of programs placed in production, keep the report that shows those dates are available and reliable. The output is a retained validation package for each report used in the review.
Run the review and document follow-up
Perform the review on the defined population throughout the period, retaining the signed or system-recorded reviewer evidence for each occurrence. For every exception, record the investigation, the conclusion, any correcting entry and the reviewer who signed off. Monitoring that surfaces issues only late in the period may not mitigate the deficiency, so track the timing of each review against the period. The output is a complete log of reviews, exceptions and resolutions.
Share the design with the auditor before year end
Walk the external auditor through the dependent control list, the threshold, the precision rationale, the report validation package and the review log design before year end, so they can plan their testing. Record their feedback and any changes you make in response. The output is a dated record of the design discussion and the auditor's documented view, which shows the compensating control was communicated and open to testing rather than assembled after the fact. Confirm with your auditor how they want this exchange recorded.
What must be in place before the auditor tests it
A compensating control only counts if the evidence around it is ready before the auditor arrives. The cards below cover the groundwork management needs: a documented analysis, a defined precision threshold, trustworthy population data, an independent reviewer, retained sign-off and early agreement on design.
Documented deficiency analysis
Write down the ITGC deficiency, the automated or IT-dependent controls that rely on it, and the accounts and assertions those controls cover. Record how the deficiency could allow a misstatement and how large that misstatement could be. Auditors judge severity on the reasonable possibility of failure and the magnitude of the potential misstatement, so this analysis is the starting point for every later decision about the compensating control.
Defined precision threshold
Set, before testing, the dollar or percentage level at which the detective review will investigate an item. PCAOB AS 2201 says a compensating control mitigates only if it operates at a precision that would prevent or detect a misstatement that could be material. A review that examines a population at a threshold far above the material misstatement level cannot be credited, so confirm the threshold with the auditor in writing.
Complete and accurate population reports
The reviewer needs a population of privileged access grants or program changes that is complete and accurate. Confirm that the report is generated from the system of record, that its filters are documented, and that it can be rerun on request. For programs placed in production, AS 2201 paragraph B31 lists the availability and reliability of a report of compilation dates as evidence that controls within a program have not changed, so keep that report with the review package.
Named reviewer with independence
Assign a specific person to perform each detective review, and make sure that person does not perform, approve or administer the activity being reviewed. A developer reviewing their own production deployments, or an administrator reviewing their own privileged logins, gives the auditor little reason to rely on the control. Record the reviewer's authority to escalate and to require remediation.
Retained sign-off evidence
Keep a dated record showing that the reviewer examined the population, which items were selected, what was investigated, what was found and who acted on exceptions. Signatures alone rarely satisfy an auditor. Store the reviewed population, the threshold applied and the follow-up tickets together so the auditor can retest the review without asking management to rebuild it.
Early auditor alignment on design
Agree the design of the compensating control with the external auditor before the review period starts. Confirm the frequency, precision, population, reviewer and evidence format. A review that is designed around the auditor's view of severity can still fail if the auditor finds it operates too late or too coarsely, so early alignment reduces the risk of a finding discovered at year end.
Questions buyers ask about compensating controls for SOX ITGC
Does a compensating control remove the need to fix the ITGC deficiency?
No. A compensating control can reduce how severe a deficiency looks for the year-end evaluation, but it does not repair the underlying IT general control. The organization still owns the remediation, and the failing control still needs to be corrected and tested. Auditors read a compensating control as a mitigating factor while the fix is in progress. If the fix never arrives, the mitigation becomes harder to defend each period. Ask your auditor early whether they expect a remediation date and what evidence will show the underlying control now operates.
Will an auditor accept a manual review as a compensating control?
Sometimes, but only if the review is precise enough to catch a misstatement that could be material. PCAOB AS 2201 says a compensating control has a mitigating effect only when it operates at a level of precision that would prevent or detect such a misstatement. A monthly glance at a long access report is unlikely to meet that bar. A reviewer who compares a defined population against an approved list, documents exceptions, and follows them to resolution has a much better chance. The review also needs to be timely. Monitoring that surfaces issues only after the reporting period closes may not mitigate the risk in time.
How much effort does it take to design and evidence a compensating control?
The effort depends mostly on how many accounts, systems and reports the control touches, and how well the population can be extracted from source systems. Design work includes defining the population, the expected results, the threshold for an exception, the reviewer, and the frequency. Evidence work includes retaining the extract, the reviewer's sign-off, the exception log, and proof of follow-up. Each recurring review adds effort every period, so a control that is hard to run manually will consume staff time through the whole remediation window. Ask the team to estimate hours per cycle for the reviewer and the control owner before committing.
Can we design and run compensating controls in-house?
Often yes, if the team understands the financial reporting risk, the affected applications and the audit evidence standard. Internal staff usually know the business process best, which helps define a meaningful population and threshold. The harder parts are independence and rigor: the reviewer should not be the person who administers the access or makes the change, and the design should be documented in a form the auditor can test. If internal staff lack SOX experience, a consultant or co-sourced internal audit function can review the design before the auditor does. Management still owns the control and its results either way.
What does a compensating control ask of the control owner and reviewer?
The control owner must run the procedure on schedule, keep complete and accurate records, and escalate exceptions without delay. The reviewer must have enough authority and system knowledge to challenge results, and must be independent of the activity being reviewed. Both roles should sign off with a date and retain the population used. Expect the auditor to ask how each person knows the report is complete and accurate, and how exceptions were resolved. Written responsibilities, a backup for absences, and a clear escalation path reduce the risk that a control quietly stops running mid-year.
Can a consultant design the compensating control while the external auditor tests it?
Yes, provided the roles stay separate. A consultant or implementation partner can help define the population, build the extract, document the procedure and prepare evidence. The organization owns the control, and the external auditor tests its design and operating effectiveness independently. Auditors cannot design controls for management without raising independence concerns, so the auditor will usually want to see management's documented design and the reasoning behind the precision chosen. Only the independent auditor issues the attestation. DeployOpen prepares systems and evidence for these assessments, but it does not issue audit reports or opinions.
What happens if the auditor rejects the compensating control design?
The deficiency keeps its original severity, and management may need to evaluate it as a significant deficiency or material weakness. Auditors may reject a design because the population is incomplete, the threshold is too loose, the reviewer lacks independence, or the review occurs too late to catch a misstatement. The usual next step is to redesign the control, retest it on a sample of periods, and document why the change is precise enough. Waiting until year end to discover the rejection leaves little time to act. Share draft designs with the auditor during the year, and treat a rejection as a signal about the underlying control, not only the mitigation.
How DeployOpen prepares systems and evidence for compensating controls
DeployOpen can prepare the systems, reports and evidence that a compensating control depends on, but the organization owns the control, its design and its remediation, and only the independent external auditor issues an opinion on ICFR. The work usually starts with scoping: identifying which financially significant applications, databases and infrastructure components the failed ITGC touches, which IT-dependent controls rely on them, and which reports those controls use. For a detective control such as a periodic review of privileged access or production changes, the first questions are practical. Which system generates the population, how is that population extracted, and can the organization show that the extract is complete and unaltered? DeployOpen works through these questions with the client's control owners in the client's own cloud accounts, data center or network, so the reports come from the systems the auditor will test.
The configuration step covers the detective control itself. Depending on the platform, this can mean enabling audit logging in a self-hosted application, scheduling a report that lists user role assignments or change records, and setting up the review workflow so the reviewer's sign-off, the date and the population are retained together. Where the precision of the review is the open question, DeployOpen can help the client document the threshold, the attributes examined and the follow-up on exceptions, and can run a dry run on a sample period so the team sees what the reviewer will actually receive. Whether that precision is sufficient to mitigate a deficiency is a judgment for management and the auditor, not something a configuration can settle in advance.
