How does an ITGC failure affect IT-dependent and automated controls?
An ITGC failure is judged through the automated and IT-dependent controls that rely on it, not on the IT control alone. SEC guidance in Release 33-8810 says IT general controls ordinarily do not address financial reporting risks by themselves, so the question your auditor will ask is which application controls, reports and calculations depend on the failed access, change, development or operations control. Severity then follows two factors: the likely size of any misstatement that could result, and whether there is a reasonable possibility that the affected controls will fail to prevent or detect it. Your auditor applies these factors under PCAOB AS 2201, and AS 2201 also lists reliance on other controls, such as ITGCs, as a factor that raises risk.
Start by building a dependency list for the failed control. For an access failure, identify every automated control, such as a three-way match, a credit limit check or a system-calculated accrual, that runs in the affected application or database, and every spreadsheet report extracted from it. For a change failure, identify which configurations, interfaces and scheduled jobs could have changed without authorization. One failure can spread across accounts because a single privileged user or unreviewed change can touch several applications that feed the same ledger. Staff Audit Practice Alert No. 11 notes that a deficient ITGC can impair IT-dependent controls across multiple accounts, which is why the list should be drawn from data flows, not from the org chart.
Your organization owns its controls and the conclusion on their severity. A partner such as DeployOpen can help prepare the systems, dependency mapping and evidence that show what each automated control relied on during the period, but only the independent auditor concludes whether the combined effect is a deficiency, significant deficiency or material weakness. Confirm with your auditor early which reports, query logic and parameter settings they will test, since the alert also cites inspection findings where ITGCs behind report data were not tested. Ask for the severity framework they will apply in writing, so the analysis you present reflects the same two factors they will use.
How one ITGC failure spreads across accounts
This sequence shows how a single access or change failure in a shared system can weaken several automated and IT-dependent controls at once, and how that chain reaches the account balances those controls were meant to protect. Each step names the output an assessor should be able to see before moving on.
Identify the failing general control
Start with the ITGC deficiency itself, such as an access review that was not performed, a privileged account that could change production logic, or a change that reached production without approval. The control owner and the IT team document what failed, the period it covered and the systems involved. The output is a deficiency record that names the general control area (access, program changes, program development or computer operations) and the application or database it touches.
Map the shared application and database
Determine which financially significant applications, databases and infrastructure components the failed control covers. A single identity store, reporting database or middleware layer often serves several ledgers, subledgers and reconciliations. The team confirms this with system owners and architecture diagrams, not assumptions. The output is a list of systems in the failure's path, with each system tied to the processes that depend on it.
Find the automated controls inside those systems
List the automated controls that run within the affected systems, such as three-way matching, calculation logic, interface checks, automated approval routing and configured thresholds. Because these controls execute the same logic every time, a failure in the surrounding access or change process may leave the logic open to unauthorized alteration without any visible sign. The output is an inventory of automated controls whose reliability depends on the failed ITGC.
Trace the reports that feed key controls
Identify the system-generated reports and spreadsheets that management reviews as part of key controls, such as aged receivables listings, inventory valuation reports or exception logs. Test whether the query or parameters that produce each report are covered by the same ITGCs, since auditors have cited firms that did not test the logic used to extract report data. The output is a list of reports, each linked to the review control that relies on it and to the ITGC that protects its source.
Connect controls to the accounts they support
For each affected review control and automated control, identify the financial statement accounts, assertions and disclosures it supports. One failure can therefore touch several accounts, which is why Staff Audit Practice Alert No. 11 says a deficient IT control can impair IT-dependent controls across multiple accounts. The output is a matrix that links the ITGC deficiency to each control and each account, so the team can see the full reach of the problem.
Estimate the likely size of misstatement
Assess whether a misstatement could occur in each affected account and how large it could be, using the nature of the controls, the transaction volumes and the account balances involved. Auditors judge severity by the reasonable possibility that controls fail to prevent or detect a misstatement and by the magnitude of the potential misstatement. The output is a written severity assessment for each account, which management and the auditor can review and challenge.
Classify the combined deficiency
Combine the individual control assessments to decide whether the ITGC failure, alone or with other deficiencies, is a deficiency, a significant deficiency or a material weakness. The classification uses the definitions in the SEC's rules and the PCAOB's severity factors, and it reflects the combined effect across accounts rather than each account in isolation. The output is a documented classification with reasoning, which feeds the remediation and compensating control decisions that follow.
When ITGC weaknesses end reliance on automated controls
Once an ITGC deficiency undermines the controls over program changes, access or computer operations, the auditor can no longer carry forward a clean baseline for the automated controls that depend on them. Under PCAOB AS 2201, paragraph B29, an auditor may rely on an unchanged automated control in later years only if the general controls over program changes, access and computer operations are effective and continue to be tested. When one of those three areas fails, the baseline falls away, and the auditor must test the automated control again in the current year rather than inheriting last year's result.
For the organization, the practical consequence is a larger testing scope in the year the reliance is lost. Expect the auditor to select samples of configured rules, such as a three-way match tolerance, an approval threshold or an automated calculation in the general ledger or subledger, and to test those items directly instead of testing the configuration once and roll-forward testing it. Ask your auditor early which automated controls will need year-specific testing, which populations and change logs they will request, and how many samples they expect for each. Confirm with your own audit team whether the prior-year baseline in your control matrix is documented well enough to show exactly which controls depended on the failed area.
The change in testing is also a cost and timing decision. Sample testing takes more evidence gathering from system owners, more time from the audit team and more room for exceptions, especially if the underlying ITGC is still not operating. Plan for this before year-end fieldwork rather than after it, because the restored reliance usually depends on evidence that the deficient general control has been remediated and tested over a period the auditor accepts. Map each automated control to the ITGC areas it depends on now, so you can see which baselines are at risk before the auditor does.
How auditors decide deficiency, significant deficiency or material weakness
Auditors weigh severity through a small set of questions about likelihood, size and reach. Management reports its own assessment, but the external auditor concludes on severity, so the cards below cover what that judgment turns on.
Reasonable possibility of failure
AS 2201 paragraph 63 asks whether there is a reasonable possibility that the control, including the IT-dependent control, would fail to prevent or detect a misstatement. For an ITGC failure, the question is whether the failure could let an automated control stop working without anyone noticing. Check whether the control that depends on the failed ITGC has any other safeguard that would catch the error.
Magnitude of potential misstatement
Severity also depends on how large a misstatement could become if the control failed. Auditors look at the account balances, transaction volumes and disclosures that flow through the affected application, not only the amount of error found in testing. Ask which accounts a broken access or change control could reach and what the total exposure would be.
Accounts and controls impaired
Staff Audit Practice Alert No. 11 notes that one IT deficiency can impair IT-dependent controls across several accounts, which can raise severity even when no single misstatement is large. Map each failed ITGC to every automated control, report and interface that depends on it. A shared database or interface that feeds many ledgers often widens the count quickly.
Whether testing must go further
AS 2201 paragraph 62 requires the auditor to evaluate each deficiency it finds but does not require a search for deficiencies less severe than a material weakness. When an ITGC fails, the auditor may still need to test beyond the failed control to rule out misstatements. Confirm early with the auditor which additional procedures it expects, since that effort shapes the timeline.
Regulatory definitions
The definitions in 17 CFR 210.1-02 set the terms for a material weakness and a significant deficiency. A material weakness is a deficiency, or combination of deficiencies, creating a reasonable possibility that a material misstatement will not be prevented or detected on a timely basis. Management and the auditor should use these definitions in writing, not informal labels, when they document severity.
How the same ITGC failure can rate differently
Imagine (illustrative) a user access review fails for one reporting application that produces a schedule used only as a reference during the close, with no key control depending on its output. Severity reasoning starts from the question of whether the failure can plausibly let a misstatement through. Here, the report feeds no automated calculation that posts to the ledger, and a manual review of the schedule's totals sits downstream. Auditors generally focus on whether the failure touches a control that addresses a financial reporting risk, and this one may not.
- Limited reliance: No key control depends on the report, so the ITGC failure has few controls to impair.
- Downstream review: A manual review of totals may reduce the reasonable possibility of an undetected misstatement, subject to the auditor's testing.
- Magnitude: The potential misstatement is bounded by the schedule's use, which is narrow.
- Documentation gap: The failure still needs to be recorded and evaluated, even if the rating is low.
- Recurrence check: Confirm the same access review process does not cover other applications with broader reliance.
Before relying on this reasoning, confirm with the auditor which controls actually depend on the report and whether the downstream review is precise enough to count.
Imagine (illustrative) a database administrator group holds inappropriate privileged access, and that database stores the master data behind three automated controls over revenue, payables and inventory valuation. The same ITGC failure now sits underneath several controls at once. Severity reasoning moves from one report to a shared dependency, because a single weak access control can impair the integrity of data every dependent control consumes.
- Multiple dependencies: Three automated controls rely on the same data, so the failure spreads across accounts.
- Higher reasonable possibility: Inappropriate changes to underlying data could go undetected by all three controls at once.
- Larger magnitude: The potential misstatement combines the exposure of several account balances.
- Pressure on compensating controls: Any compensating review must cover the full population, which is often harder to show with precision.
- Scope question: Confirm whether the database is in ITGC scope and whether its logs are reviewed.
Check whether the privileged access is actually used, and whether the auditor's analysis of the three dependent controls reflects the shared data path.
Imagine (illustrative) a change to a pricing configuration in a billing application is moved to production without the required approval, and no one reviews the production change log afterward. Severity reasoning here is driven by the absence of any detective step. A program change failure with no compensating review leaves the dependent controls without a second check, and the auditor may evaluate whether the unapproved change could have altered the figures those controls depend on.
- No second line: Nothing detects the change after it reached production, so the failure runs unchecked.
- Direct effect on calculations: A configuration change can alter the figures that automated controls process.
- Timing: The window of exposure lasts until the change is discovered, which affects the magnitude analysis.
- Evidence of effect: Auditors may test whether any output changed, which shifts the assessment toward actual misstatement.
- Severity drivers: The reasonable possibility question depends on the reliance on the billing controls and the lack of a review.
Confirm with the auditor what evidence they will request to determine whether the change affected financial results, and whether a retrospective review would count as a compensating control.
Imagine (illustrative) an ITGC failure in user access is identified during a late-year testing cycle, and the company has not yet designed a fix or started a remediation plan. Severity reasoning weighs the time the deficiency existed, the controls exposed during that time, and whether anything in the period reduced the risk. A failure that persists without action is judged more severely than one found and corrected early, because the window of potential misstatement stays open.
- Exposure window: Severity depends on how long the failure existed, not only on when it was found.
- No mitigating step: Without remediation or a compensating control, the failure has no offsetting factor.
- Year-end pressure: Remediation that cannot be tested before year end may leave the deficiency in place for the assessment.
- Auditor communication: Late discovery raises questions about how well management monitors its own ITGCs.
- Documentation: Record when the failure was identified, how it was evaluated and what action was taken.
Ask the auditor how they will assess the exposure window and what evidence of remediation timing they expect before year-end testing closes.
Testing gaps that make auditors escalate ITGC findings
Auditors escalate an ITGC finding when the testing behind a control does not cover the data it depends on. PCAOB Staff Audit Practice Alert No. 11 cites inspection findings where firms did not test the ITGCs important to the applications that generate data or reports. For a finance team, this means the ERP module, data warehouse, or spreadsheet-based reporting tool that produces a population, a report, or a system-generated figure used in a key control. If the access and change controls over that application were never tested, the auditor cannot rely on the report, and every automated or IT-dependent control that uses it is weakened.
A second gap sits inside the report itself. The same alert cites firms that did not test the logic of queries or parameters used to extract report data. A report can be generated correctly by the system and still omit transactions because a date filter, a currency field, or a status threshold was set wrong. Ask your team which report logic and extraction controls the auditor will request: the query text, the parameter list, who can change those parameters, and whether a change to them goes through the same approval as a program change. Document the population completeness and accuracy check for each key report before the auditor asks for it.
The third gap is the most damaging: ITGC deficiencies that were found but not addressed. Inspection findings in the alert describe firms that identified a problem and did not evaluate or respond to it. Before fieldwork starts, pull the open items from your access reviews, change tickets, and prior-year deficiency log, and confirm each one has an owner, an assessed effect on the controls that depend on it, and a remediation or compensating control with a date. An unresolved deficiency that management already knew about is harder to defend than the deficiency itself, so treat the log as evidence the auditor will read.
Questions management asks about ITGC failures and control impact
Does every ITGC failure become a material weakness?
No. An IT general control failure is a deficiency until its effect on financial reporting is evaluated, and most do not reach material weakness. Severity depends on whether the failed control leaves a reasonable possibility that a misstatement goes undetected and on how large that misstatement could be. Staff Audit Practice Alert No. 11 explains that a deficient IT control may not cause a misstatement by itself but can impair IT-dependent controls across several accounts, which is why the reach of the failure matters as much as the failure itself. Management should document the analysis for each deficiency, including the controls that depend on it and the likely size of any resulting error, so the conclusion can be defended when the auditor asks.
Can an ITGC failure be limited to one application?
Sometimes, but only if the evidence shows it. A failure in access controls or change management can extend to every automated control that relies on the affected application, the database beneath it, or the infrastructure that hosts it. For example, if a shared administrator account can change configuration in a general ledger application, the reach may include reports, interfaces and reconciliations fed by that system. Review which accounts and data flows the failure touches, confirm whether other systems share the same administrators or change path, and test the logic of any queries or report parameters that depend on it before concluding the scope is narrow.
Who decides how severe an ITGC deficiency is?
Management makes the first assessment, and the external auditor independently evaluates severity under PCAOB AS 2201. Management documents its conclusion as part of its ICFR evaluation under Rule 13a-15(c), and the auditor tests that conclusion and forms its own view. Auditors weigh reliance on other controls as a factor that raises risk, and they do not have to search for deficiencies less severe than a material weakness. Expect to explain the basis for each classification with evidence, not with judgment alone. Disagreements usually come down to how far the failure reaches and whether a compensating control is precise enough to count.
How much effort does analyzing an ITGC failure take?
The effort depends on how many IT-dependent controls rely on the failed control and how well the company already maps those relationships. Work usually includes listing the affected applications, databases and interfaces, identifying the automated and manual controls that depend on them, testing whether those controls still operate, and estimating the likely misstatement for each. A company with a current systems and control inventory can finish this faster than one reconstructing it during an audit. No single figure applies across companies, so ask your auditor and internal team to agree on the scope of the analysis and the evidence required before work begins.
Can our own team assess an ITGC failure without outside help?
Many companies can, provided they have people who understand both the financial processes and the technology. Management owns the evaluation and cannot hand that responsibility to a consultant or the auditor. Internal staff need access to system configurations, change records, access reviews and the report logic that feeds controls, and they need to document their reasoning clearly. Outside help is most useful when the team lacks technical depth in a specific platform, when the analysis spans many systems, or when the company needs independent testing before the auditor arrives. An implementation partner such as DeployOpen can prepare systems and evidence for that work, but the conclusion remains the organization's to reach and the auditor's to test.
What should we ask an outside consultant before hiring one?
Start by asking exactly what the engagement covers and who issues the conclusions. Ask whether the consultant will document which IT-dependent controls depend on the failed control, how they will test the logic of reports and parameters, and what evidence they will hand over. Confirm that the consultant will not sign off on management's assessment or act as the auditor, and ask how they coordinate with your external auditor and internal audit. Request a written scope with deliverables and timelines before work starts, and ask which systems will need access and how that access will be controlled. Finally, ask how the firm handles evidence retention and whether any work will be done inside your own environment.
What to document before the auditor asks about an ITGC failure
When an ITGC fails, the auditor's first questions are about what depended on it. These five items form the file that answers those questions, and each one can be checked by someone outside the control owner's team before fieldwork begins.
Inventory of IT-dependent controls
List every manual review, reconciliation and automated control that uses a system report, interface or calculated field from an affected application. Record the control owner, the frequency and the report or data source each control relies on. To check it, pick three controls at random from the inventory and confirm each one names a report that appears in the application's report list. Gaps usually sit in spreadsheets and ad hoc extracts that no one registered as a dependency.
ITGC areas behind each automated control
For each automated control, state which of the four ITGC areas protects it: access to programs and data, program changes, program development or computer operations. A control that depends on a configurable rule needs change management and access evidence, while a scheduled batch job also needs computer operations evidence. To check it, ask the control owner which ITGC would have to fail for the automated control to produce a wrong result, and compare that answer with the map.
Documented impact assessment
Write down what the ITGC failure could have allowed: who could have changed data or logic, over what period, and whether the affected control could still detect an error. Record the reasoning for each conclusion, including the factors that lower or raise the risk. To check it, confirm a reviewer who did not write the assessment has signed it and that it addresses the period between the last clean test and the failure.
Affected accounts and assertions
Trace each dependent control to the financial statement accounts and assertions it supports, such as existence, completeness or valuation. A single failed access control can touch revenue, payables and the general ledger at once, so the list should show every account reached through the dependency chain. To check it, sample one account from the list and walk it backward to the application, confirming the path through the interface matches what was written.
Evidence the failure was logged and tracked
Keep the ticket or issue record showing when the failure was found, who was notified, the severity assigned and the owner of the fix. Auditors check whether the company acted on the deficiency it identified, so an undocumented known issue is a finding in its own right. To check it, confirm the issue log entry predates any remediation work and that each status change has a timestamp and an approver.
Who owns the impact assessment and who prepares the evidence
Management owns the internal control over financial reporting, including the IT general controls that support automated and IT-dependent controls. When an ITGC deficiency is found, management must decide which controls it affects, how far the failure reaches across accounts and processes, and how severe the combined effect is. That judgment is management's to make and document, and the Section 404 assessment rests on it. Management's documentation should show the reasoning, not only the conclusion.
- Mapping dependencies: Identify every automated control and report that relies on the failed ITGC, including those in other business processes.
- Estimating exposure: Consider the accounts and disclosures those controls touch and the likely size of any misstatement.
- Recording severity: Document the deficiency classification and the factors behind it, including whether a compensating control exists.
- Owning remediation: Assign owners, dates and evidence requirements for each fix, even when an outside party does the technical work.
- Certifying the result: Management's conclusions feed the certifications and the annual report on internal control.
Confirm with your audit committee and external auditor which documentation format they expect for the severity analysis before the year-end cycle begins.
An implementation partner such as DeployOpen can prepare the systems, configurations, logs, reports and evidence that management and the auditor use to evaluate an ITGC failure. For self-hosted open-source platforms in the client's own cloud accounts, data centers or air-gapped networks, that work usually covers rebuilding access reviews, change records, backup restore tests and job monitoring so they can be produced on request. The partner does not decide severity, does not sign management's assessment and does not issue audit reports, attestations or certifications.
- Preparing systems: Configure logging, role assignments and change pipelines so the relevant evidence exists and can be retrieved.
- Producing evidence packs: Assemble reports from the platform with the query logic and parameters documented, so the auditor can test them.
- Supporting remediation: Build or adjust the replacement control, then test it so it can operate long enough to be tested.
- Documenting changes: Maintain runbooks and configuration records that show what changed and when.
- Scoping work in writing: Agree the scope, deliverables and timelines before work starts, so responsibilities are explicit.
Ask any implementation partner to show in writing which deliverables are technical preparation and which decisions remain with management and the auditor.
The external auditor tests the controls, assesses the deficiency and forms the opinion on the effectiveness of internal control over financial reporting. Under PCAOB AS 2201 the auditor evaluates each deficiency it finds and must consider reliance on other controls, such as IT general controls, as a factor that raises risk. The auditor's reliance on automated controls depends on whether the underlying ITGCs are effective and continue to be tested. The auditor can rely on prepared evidence but must test it, and it cannot delegate its opinion to the company or its partner.
- Understanding the environment: Obtain an understanding of the IT general controls important to automated controls, as AS 2110 requires.
- Testing the evidence: Test the logic and parameters of any report used to extract data, and test the ITGCs that produce it.
- Evaluating severity: Consider the reasonable possibility of failure to prevent or detect a misstatement and the potential magnitude.
- Issuing the opinion: Form and sign the attestation opinion where Section 404(b) applies.
- Communicating findings: Discuss deficiencies and significant deficiencies with management and the audit committee.
Confirm early in the cycle which evidence the auditor will accept, how it will be sampled and whether it needs to be independently generated.
Mistakes that widen an ITGC failure into a larger finding
An ITGC failure rarely stays inside one system. Auditors follow it into every automated control and report that depends on the failed control, so the mistakes below usually surface when a single deficiency turns into several. Each one is a point where teams can trace the impact earlier and document it better.
Assuming the failure is contained
Teams often scope a failed access or change control to the application where the problem was found. Auditors ask which other applications, databases and interfaces share the same administrators, change pipeline or service accounts. Staff Audit Practice Alert No. 11 notes that a deficient IT control can impair IT-dependent controls across multiple accounts. Before closing the finding, map every automated control and report that relies on the failed control, and record that map.
Relying on unverified report logic
A report that feeds a review control is only as reliable as the query or parameters that produce it. If nobody tested that logic, an ITGC failure in the source system can flow silently into the reviewer's output. Inspection findings cited by the PCAOB include auditors who did not test the logic of queries or parameters used to extract report data. Confirm that each key report has tested logic and that changes to that logic run through the same change controls.
Depending on late-detecting monitoring
A detective review that runs quarterly may catch an unauthorized change long after it affected several financial periods. Auditors weigh whether a control could fail to prevent or detect a misstatement and how large that misstatement could be. A monitor that surfaces issues late gives little protection for the periods in between. Ask whether the monitoring frequency and precision would have caught the failure within the period it occurred.
Skipping the impact assessment record
Management is expected to show how it evaluated the effect of an ITGC failure on the controls that depend on it. When that reasoning lives only in chat threads or in one engineer's head, auditors cannot test it, and they may conclude the evaluation never happened. Write down the failed control, the dependent automated and IT-dependent controls, the reports involved, the reasoning on severity and the decision reached. Keep it current as facts change.
Letting the automated control baseline lapse
Auditors can rely on an unchanged automated control in later years only while general controls over program changes, access and computer operations stay effective and keep being tested. A failed ITGC can therefore break the baseline without anyone noticing, and the control may need full retesting. Track which baselines depend on which general controls, and flag any baseline that needs testing again after a deficiency is found.
How DeployOpen helps prepare systems and evidence
DeployOpen helps organizations prepare the systems, configurations and evidence that let them show how an ITGC failure flows into IT-dependent and automated controls. We plan and build the work inside your own infrastructure, then hand it over so your management and independent auditor can test it. DeployOpen does not issue audit reports or opinions.
How we scope
- Written scope lists the applications, interfaces and reports whose automated controls depend on each affected ITGC.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- Scope names which system owners, auditors and internal reviewers must confirm the boundary before work begins.
How we build
- We map each automated control to the access, change and operations settings it relies on, then document the dependency.
- Systems are configured to produce logs, change tickets and access reviews that show whether those settings held over the period.
- Testing of the control logic and report parameters is performed and recorded alongside the remediated configuration.
How we hand over
- Handover includes a dependency map, configuration baselines, test scripts and the evidence index your auditor will request.
- Documentation states what management owns, what the implementation partner prepared and what only the independent auditor can conclude.
- Your team receives runbooks so control owners can rerun the evidence collection without DeployOpen involved.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover re-running dependency checks when a system changes, which can affect severity judgments.
- Before engaging, confirm with your auditor which evidence formats and sample periods they will accept.
