The short answer: IT General Controls (ITGC) are the foundation layer of the SOX ITGC stack — the automated and manual controls that govern access to financial-reporting systems, changes to those systems, and operations of those systems, on which application-level controls depend. PCAOB Auditing Standard No. 2201 §.36 requires the external auditor to identify controls that address significant risks; §.39 requires sufficient appropriate evidence of control operation; §.42 governs nature, timing, and extent of tests of controls; §.46 governs testing design effectiveness; §.47 governs testing operating effectiveness; §.50 governs evaluating deficiencies. Approximately 60–75 percent of ITGC control activities are agent-testable at an AS 2201-aligned evidence bar in 2026, concentrated on access review, change management, segregation of duties, incident response monitoring, and configuration baselines. The remaining 25–40 percent requires human judgment or hybrid testing. PCAOB inspection reports from late 2025 and early 2026 have specifically validated automated ITGC evidence where the evidence demonstrates authenticity (cryptographic hashing), completeness (continuous-population testing), source reliability (direct read-only system integration), and reperformability (preserved reasoning traces). SOC 2 Trust Services Criteria CC6.1 (access), CC6.2 (account management), CC6.3 (access removal), CC7.1 (monitoring), CC7.2 (detection), CC8.1 (change management) overlap 85–90 percent with SOX ITGC, meaning a single well-designed continuous-testing evidence stream produces evidence for both frameworks simultaneously. This post walks the mapping honestly, family by family.
This post is written for the Controller, Internal Audit Director, IT Audit Manager, or CFO at a 300–1,500 emp PE portco, pre-IPO company, public microcap, or multi-entity mid-market that is evaluating how PCAOB AS 2201 specifically governs IT General Controls testing and how agent-driven continuous testing fits the evidence bar. The reader is assumed audit-literate and specifically interested in the AS 2201 paragraph-level mapping, not a general introduction to SOX.
What are IT General Controls (ITGC) and why do they sit at the foundation of SOX?
ITGC are the controls over information technology that support the operation of application-level controls — the automated controls that directly address financial-reporting assertions. Application controls tell you whether a specific journal entry posted correctly or whether a revenue transaction was recognized in the appropriate period. ITGC tell you whether the systems executing those application controls were secure, accessible only to authorized users, subject to disciplined change management, and monitored for anomalies.
The dependency is asymmetric. Application controls rely on ITGC. If the access control ITGC fails, an unauthorized user could modify application control logic or directly manipulate data, invalidating every downstream application control's evidence. If the change management ITGC fails, an unauthorized change could introduce an error in the application control logic that operates undetected for the entire attestation period. The PCAOB AS 2201 framework recognizes this dependency explicitly in §.39 and §.42 — ITGC testing is prerequisite to application-control testing reliance.
The five core ITGC families at 300–1,500 emp companies:
Access management — user provisioning, access reviews, terminated-user access removal, privileged access management, segregation of duties at the entitlement level.
Change management — deployment approval, testing evidence, separation of duties between developer and deployer, emergency change documentation, post-implementation review.
ITGC operations (baseline) — backup completion, job scheduling, incident response, vendor access management, physical security of data center or cloud infrastructure.
Configuration management — baseline configurations, configuration change tracking, patching cadence, hardening standards, vulnerability management.
Logging and monitoring — audit log generation, audit log retention, audit log review, security event detection and response.
Across 300–1,500 emp mid-market companies, ITGC control populations range 40–140 controls depending on system complexity, cloud footprint, ERP count, and multi-entity scope. This concentrated scope is why ITGC automation typically returns the highest proportion of audit hours among SOX control families.
What does PCAOB AS 2201 §.39 actually require for ITGC evidence?
PCAOB Auditing Standard No. 2201 §.39 (evidence of control operation) establishes the evidence bar: "The auditor must obtain evidence of the effectiveness of controls over the relevant assertions for all significant accounts and disclosures in the financial statements. The auditor must obtain evidence about the design effectiveness and operating effectiveness of controls at the entity level, controls over management's period-end financial reporting process, and controls over information technology general controls."
The paragraph establishes four evidence characteristics that recur through the 2025–2026 PCAOB inspection findings:
Authenticity — the evidence must actually come from the system of record and must not have been altered between collection and review. Documentation versions must be auditable.
Completeness — the evidence must cover the full control population during the attestation period, not just a point-in-time snapshot. Sampling is permitted under §.42 but sampling methodology must meet the statistical inference requirements.
Source reliability — the evidence source must be independent of the operator being tested. A user's own attestation that they performed an access review is weaker than a system-generated log of the review's execution.
Reperformability — the auditor must be able to re-execute the test and obtain consistent results. This is the characteristic that differentiates audit evidence from assurance evidence.
Agent-produced ITGC evidence maps cleanly to these four characteristics when the evidence is: SHA-256 cryptographically hashed at the moment of signing (authenticity preserved); pulled continuously against the full control population rather than sampled (completeness established); collected through direct read-only system integration rather than user-submitted attestation (source reliability strong); and recorded with the agent's preserved reasoning trace plus the query parameters (reperformability supported by re-executing the same query against the same system).
Document-centric evidence (screenshots, PDF uploads, SharePoint attachments) meets these characteristics weakly because the evidence can be altered, the collection cadence is typically periodic not continuous, the source reliability depends on the uploader's integrity, and reperformability requires re-execution by the human who performed the original test. This is not a claim that document-centric evidence fails AS 2201 — it can meet the bar at sufficient rigor — but the rigor required is higher than for agent-produced evidence.
What does §.42 require for nature, timing, and extent of ITGC testing?
PCAOB AS 2201 §.42 governs "the nature, timing, and extent of tests of controls": "The auditor must perform tests of controls that are sufficient to obtain evidence about the operating effectiveness of the controls. The nature, timing, and extent of tests of controls depend on the assessed risk of material misstatement, the complexity of the controls being tested, and the evidence already obtained."
Nature refers to the type of test — inquiry, observation, inspection, reperformance. For ITGC specifically, reperformance is the highest-evidence test type because it demonstrates the control operated as designed. Inquiry alone is insufficient under §.42.
Timing refers to when tests are performed — interim versus period-end, dated controls versus continuous controls. Under §.42, continuous controls have structural evidence advantages because every point-in-time within the attestation period is tested, eliminating the gap between test dates that sampling creates.
Extent refers to sample size — how much of the control population is tested. Under §.42, sample size must support the auditor's conclusion on operating effectiveness; larger populations typically require larger samples, subject to statistical inference requirements and the auditor's professional judgment.
Agent-driven continuous testing collapses the §.42 math favorably: the nature is reperformance (agent re-executes the control's logic against observed data); the timing is continuous (every date within the attestation period is tested); the extent is full population (100 percent of the population is tested continuously, not a sample). This triple-optimization produces evidence that exceeds the §.42 sufficiency threshold for most ITGC control families.
The honest caveat: continuous full-population testing surfaces more exceptions than sampling, which can appear as "more deficiencies" in the first testing cycle. This is not a deterioration in control effectiveness — it is higher-fidelity detection. The IA Director should prepare management and the external auditor for this surfacing effect before the first agent-tested cycle.
What does §.46 require for testing control design effectiveness?
PCAOB AS 2201 §.46 (testing design effectiveness of controls) requires the auditor to test the design effectiveness of the controls — whether the controls, if operating as designed, would prevent or detect errors or fraud that could result in material misstatements.
Design effectiveness testing is distinct from operating effectiveness testing. A control can operate as designed and still fail to address the risk if the control's design is inadequate. Design effectiveness evaluation is primarily judgmental and is performed by the Internal Audit Director, the CAE, or the external auditor — agent-driven testing is not the right tool for design effectiveness evaluation.
For ITGC specifically, §.46 design effectiveness questions include: does the access review control address the risk of excessive or inappropriate access? does the change management control address the risk of unauthorized or erroneous code changes? does the incident response control address the risk of undetected security events?
Agent-driven continuous testing supports §.46 evaluation by providing the operating-effectiveness evidence against which design effectiveness is tested. The auditor evaluating design effectiveness reviews the control narrative, the agent's reasoning trace (how the agent interpreted the control objective), and the evidence output to assess whether the design is adequate. A well-designed agent test illuminates design gaps that manual testing might miss by showing whether the control's stated objective matches the agent's interpretation.
What does §.47 require for testing operating effectiveness?
PCAOB AS 2201 §.47 (testing operating effectiveness of controls) requires the auditor to test operating effectiveness — whether the control is operating as designed and whether the person performing the control possesses the necessary authority and competence.
Operating effectiveness testing is where agent-driven continuous testing earns its evidence. A 650-emp PE portco with 120 ITGC controls running traditional manual sample-based testing produces evidence on perhaps 25–40 sample points per control per year. The same portco with continuous agent testing produces evidence on every point-in-time within the attestation period — typically 1,000–10,000+ test executions per control per year, depending on the control's population size.
Under §.47, evidence weight is influenced by the sample size and testing period coverage. Continuous full-population testing produces evidence weight that exceeds sample-based testing for the same underlying control population. The PCAOB inspection posture in 2025–2026 has validated this evidence weight when the agent design meets the §.39 authenticity, completeness, source reliability, and reperformability characteristics.
The honest architectural note: continuous testing does not automatically satisfy §.47. A poorly-designed agent that fails to interpret the control objective accurately produces continuous false evidence, which is worse than no evidence. The §.47 bar requires the agent's reasoning to be accurate, which is validated through the agent's reasoning trace review by the IA function and the external auditor.
What does §.50 require for evaluating identified deficiencies?
PCAOB AS 2201 §.50 (evaluating identified deficiencies) governs how the auditor evaluates the severity of control deficiencies and determines whether they rise to significant deficiency or material weakness. The evaluation considers the likelihood and magnitude of potential misstatement.
Continuous agent testing affects §.50 evaluation in two ways. First, deficiency surfacing is higher-fidelity — exceptions that manual sampling would miss are surfaced. This can appear as more deficiencies early in the agent-testing deployment, which requires management response on whether each exception indicates a control deficiency or represents expected variation within control tolerance.
Second, deficiency evidence is richer. Each exception comes with the agent's reasoning trace, the source-system snapshot, the timestamp, and the evidence hash. The external auditor evaluating the exception under §.50 has more evidence per exception than document-based testing provides, which supports more accurate deficiency severity evaluation.
The practical implication: the first year of continuous agent testing typically produces a temporary uptick in identified deficiencies as higher-fidelity surfacing reveals exceptions that sampling missed. The surface is not a control-effectiveness deterioration — it is a detection-quality improvement. Management and the external auditor should scope the first-year deficiency evaluation with this dynamic in mind.
Which ITGC families are agent-testable at AS 2201-aligned evidence bar?
The family-by-family mapping for 2026:
Access management — high-confidence agent-testable. User provisioning tracked through identity system integration (Okta, Entra ID, Workday, Rippling). Access reviews executed continuously against role-entitlement matrix. Terminated-user access removal verified against HRIS termination date with SLA threshold. Privileged access management tracked against policy exceptions. Segregation of duties at entitlement level enforced through access pattern analysis. Agent-coverage: 70–85 percent of access management control activities.
Change management — high-confidence agent-testable. Deployment approval evidence tracked through source control and CI/CD pipelines (GitHub, GitLab, Bitbucket, Jenkins). Testing evidence verified through automated test execution records. SoD between developer and deployer enforced through commit author vs deploy author verification. Emergency change documentation tracked against post-facto approval workflow. Post-implementation review recorded with timestamps. Agent-coverage: 65–80 percent of change management control activities.
ITGC operations baseline — medium-to-high-confidence agent-testable. Backup completion verified through system logs. Job scheduling tracked against scheduled vs actual execution. Incident response monitoring tracked continuously; incident handling (the judgmental response portion) requires human review. Vendor access management verified through identity system integration. Physical security of cloud infrastructure is provider-attested (AWS, GCP, Azure SOC 2 reports); on-premises physical security requires human assessment. Agent-coverage: 55–70 percent.
Configuration management — medium-confidence agent-testable. Baseline configurations verified through continuous configuration drift detection. Configuration change tracking integrates with change management. Patching cadence tracked against vulnerability disclosure SLA. Hardening standards verified through configuration audit. Vulnerability management scanning is agent-executable; vulnerability disposition (the judgmental response portion) requires human evaluation. Agent-coverage: 55–70 percent.
Logging and monitoring — medium-to-high-confidence agent-testable. Audit log generation verified through log volume analysis. Audit log retention verified against policy-defined retention period. Audit log review is hybrid — the agent can surface anomalies but judgmental review of each anomaly requires human evaluation. Security event detection tested continuously. Agent-coverage: 60–75 percent.
Aggregate across all ITGC families: approximately 60–75 percent of ITGC control activities are agent-testable at an AS 2201-aligned evidence bar in 2026. The remaining 25–40 percent requires hybrid testing (agent surfaces, human evaluates) or human-only testing (physical security, judgmental evaluation).
How does PCAOB inspection posture in 2025–2026 treat agent-produced ITGC evidence?
PCAOB inspection reports are the authoritative source for how automated evidence is treated by the regulator. The 2024 and 2025 annual reports specifically addressed automated control testing with a cautiously accepting tone. The 2026 inspection cycle is expected to further normalize the acceptance.
Key posture points from recent inspection findings:
Evidence authenticity: cryptographic hashing (SHA-256 or stronger) of evidence at the moment of signing is recognized as meeting the authenticity characteristic under AS 2201 §.39. Inspection reports have called out document-centric evidence that lacked cryptographic integrity controls as exposure.
Evidence completeness: continuous-population testing is recognized as structurally stronger than sample-based testing under AS 2201 §.42 when the agent coverage is comprehensive and the agent's test logic is validated. Inspection reports have not required continuous testing but have recognized its evidence-weight advantages.
Source reliability: direct read-only system integration is recognized as meeting the source reliability characteristic. Evidence uploaded by the control performer (user-submitted attestation, screenshot upload) is recognized as meeting the characteristic only when supported by independent system verification.
Reperformability: preserved reasoning traces combined with source-system query parameters are recognized as meeting the reperformability characteristic. Inspection reports have specifically called out "black box" automated evidence (where the auditor cannot re-execute the test and understand the logic) as a deficiency.
Agent design validation: the IA Director's and external auditor's review of the agent's reasoning trace is recognized as the control-design validation mechanism. Inspection reports have highlighted that agent-produced evidence is only as strong as the agent's design.
The aggregate posture: agent-produced ITGC evidence that demonstrates authenticity, completeness, source reliability, and reperformability is accepted by PCAOB inspection in 2026. Evidence that fails one or more of these characteristics faces inspection exposure regardless of format.
How does SOC 2 Trust Services Criteria overlap with SOX ITGC?
SOC 2 TSC (AICPA Trust Services Principles and Criteria, as revised in Trust Services Criteria 2017) overlaps heavily with SOX ITGC. The key criteria:
CC6.1 (access controls) — maps to SOX ITGC access management (user provisioning, authentication, authorization). Overlap: approximately 90 percent.
CC6.2 (account management) — maps to SOX ITGC access management (user lifecycle, role assignment, entitlement review). Overlap: approximately 85 percent.
CC6.3 (access removal) — maps to SOX ITGC terminated-user access. Overlap: approximately 95 percent.
CC6.6 (network security) — maps to SOX ITGC configuration management (boundary protection, network segmentation). Overlap: approximately 75 percent.
CC6.7 (data protection) — maps to SOX ITGC logging and monitoring (data in transit, data at rest). Overlap: approximately 70 percent.
CC7.1 (monitoring of changes) — maps to SOX ITGC configuration management. Overlap: approximately 80 percent.
CC7.2 (detection of anomalies) — maps to SOX ITGC logging and monitoring. Overlap: approximately 85 percent.
CC7.3 (evaluation of security events) — maps to SOX ITGC incident response. Overlap: approximately 75 percent.
CC8.1 (change management) — maps to SOX ITGC change management. Overlap: approximately 90 percent.
Aggregate overlap: approximately 85–90 percent of SOC 2 TSC CC6 (logical access), CC7 (system operations), and CC8 (change management) requirements overlap with SOX ITGC activities. A single continuous-testing evidence stream with framework-tag mappings produces evidence for both SOX ITGC under AS 2201 §.39 and SOC 2 TSC simultaneously.
The consolidation economics: a 650-emp PE portco running SOX ITGC + SOC 2 separately typically spends 3,400–5,200 total testing hours per year with approximately 65 percent overlap in the testing work. A consolidated evidence stream reduces total hours to 2,100–3,400 — returning 1,300–1,800 hours per year to higher-value IA work.
The takeaway
IT General Controls are the foundation of the SOX ITGC stack. PCAOB AS 2201 §.39, §.42, §.46, §.47, and §.50 govern how the external auditor evaluates ITGC evidence, and the four evidence characteristics (authenticity, completeness, source reliability, reperformability) define the acceptance bar.
Agent-driven continuous testing covers approximately 60–75 percent of ITGC control activities at an AS 2201-aligned evidence bar in 2026. The agent-testable families — access management, change management, logging and monitoring, ITGC operations baseline, configuration management — consume the highest proportion of traditional manual-testing labor, which is why automation returns the most hours here.
PCAOB inspection posture in 2025–2026 has validated agent-produced ITGC evidence when the evidence demonstrates cryptographic authenticity (SHA-256 hashing), continuous-population completeness, direct read-only source reliability, and preserved reasoning-trace reperformability. Document-centric evidence can meet the bar but requires higher rigor per characteristic.
SOC 2 TSC CC6, CC7, and CC8 overlap 85–90 percent with SOX ITGC. A single continuous-testing evidence stream with framework-tag mappings produces evidence for both frameworks simultaneously, saving 1,300–1,800 hours per year at 650-emp scale.
Design effectiveness (§.46) evaluation and deficiency severity (§.50) evaluation remain judgmental and should be performed by the IA Director and external auditor, not the agent. Agent-driven testing supports these evaluations by providing the operating-effectiveness evidence base.
If you are the Controller, Internal Audit Director, IT Audit Manager, or CFO at a PE portfolio company, pre-IPO 300–1,500 emp company, public microcap under $1B, or multi-entity mid-market evaluating ITGC evidence architecture for your 2026 or 2027 attestation cycle, the next step is concrete: run a PCAOB AS 2201 evidence-characteristics review against your current ITGC evidence stack, then evaluate whether agent-driven continuous testing would raise the evidence bar while reducing testing hours. Request a design partner slot to walk through the ITGC family mapping with your external audit partner. Related reading: continuous control testing primer, SOX automation for PE portfolio companies, AuditBoard alternatives comparison, Workiva vs Prova comparison.