Cross-industry observations on recurring ITGC control failures and their root causes.
As IT environments continue to evolve toward cloud, SaaS, and highly automated operating models, the nature of ITGC failures is also changing. While core SOX control objectives remain largely unchanged, the way controls break down in practice has shifted.
This document summarizes cross-industry insights from FY2025 ITGC audits, highlighting the most common control failures we observe and the underlying causes behind them. These patterns are drawn from environments where controls are generally well-designed and teams are experienced, yet gaps still emerge due to coverage limitations, system design constraints, and challenges in sustaining control effectiveness over time.
The intent of these insights is not to restate known requirements, but to surface where ITGCs most frequently fail in modern environments, and why these failures continue to occur despite mature processes and advanced tooling.
In cloud infrastructure environments – AWS, GCP, and Azure in particular – privileged access is frequently granted to identities that exist entirely outside the organization’s centralized identity and SSO framework. These identities are typically not provisioned through standard HR workflows and tend to fall outside periodic access reviews – they are less visible than core systems like an ERP and are rarely tied to a named employee or a formal joiner/leaver process.
The most common examples include:
These identities are often highly privileged – capable of creating, modifying, or deleting infrastructure that supports financial reporting systems – yet they fall entirely outside the controls designed to govern access.
Access governance under SOX is typically designed around the employee identity lifecycle: joiners, movers, and leavers. When a separate class of privileged identities exists outside this framework, the control population is structurally incomplete. Periodic access reviews may be performed exactly as designed – on time, with documented approvals – yet still fail to cover material access paths.
Auditors are increasingly focused on whether organizations can demonstrate that all privileged access, regardless of identity type or origin, is governed and subject to review. Producing an access review certification that excludes third-party cloud administrators is not a passing answer, regardless of how well the employee-focused review was performed.
The operational risk compounds the audit risk. Access that is not governed is access that is not monitored – meaning inappropriate activity may go undetected until it becomes a control failure with financial reporting implications. Consider a vendor administrator with standing access to a cloud environment hosting a revenue-critical system: if that access is never reviewed, never revoked, and never monitored, a misconfiguration or unauthorized action could impact the integrity of financial data with no audit trail to detect or explain it.
Organizations that manage this well treat identity governance as a universal requirement, not an HR-scoped process. In practice, this means:
Maintaining an authoritative inventory of all privileged identities across cloud environments, including non-SSO, contractor, service account, and legacy identities.
Requiring all privileged access – regardless of identity type – to be linked to a named, accountable owner with documented business justification.
Including non-SSO and third-party identities in the same periodic access review process used for employees, with the same documentation and certification requirements.
Implementing continuous monitoring for privilege escalation and new identity creation, with alerting when identities are provisioned outside standard workflows.
Formally offboarding contractor and third-party identities through a defined process – not relying on SSO deprovisioning to cover accounts that were never in SSO.
Scytale’s platform addresses this gap through continuous, cross-system access intelligence that goes well beyond employee identity. Via native integrations with cloud infrastructure (AWS, GCP, Azure) and identity providers like Okta, Scytale automatically discovers and inventories all privileged identities – including contractor accounts, service accounts, and non-SSO credentials – and surfaces any that lack a documented owner or fall outside standard review scope. Unlike point-in-time access reviews, Scytale runs automated User Access Review workflows continuously across connected identity systems, ensuring that third-party and infrastructure-level accounts are included in every certification cycle, not just the HR-managed population.
In source code management platforms (e.g., GitHub, GitLab), branch protection rules are designed to enforce approvals before production changes. Over time these controls are frequently altered, bypassed, or inconsistently applied.
This often occurs in environments with multiple administrators, where not all admins are aware of SOX requirements or the audit implications of configuration changes. As a result, controls that were compliant at the start of the audit period may not remain consistently enforced throughout the year. This risk persists even in mature organizations with well-documented change management processes.
In GitLab environments specifically, audit logging is not always enabled or actively reviewed, limiting visibility into configuration changes and administrative actions.
From an audit standpoint,change management controls are designed to prevent unauthorized or unapproved changes to systems that impact financial reporting. When branch protection rules can be altered without detection, changes may reach production without appropriate approval, undermining the effectiveness of the control even if the process is well-designed.
Auditors increasingly focus on whether controls are consistently enforced over time, not just correctly configured at a point in time.
More effective teams continuously monitor branch protection and related administrative settings, treating configuration changes as control events rather than one-time setup tasks. They also ensure that all repository administrators – not just the compliance or IT team understand that branch protection settings are SOX-relevant controls, not routine configuration options. This means documenting clear rules around who can modify these settings, under what circumstances, and what approval is required before any change is made.
Scytale’s Continuous Control Monitoring capability directly targets configuration drift by treating branch protection settings as live, monitored controls rather than one-time setup tasks. Through its native integrations with source code platforms, Scytale continuously validates that required configurations remain in place throughout the audit period – not just at testing time — and surfaces any deviations from best practice directly in the platform. This produces a timestamped configuration history that organizations can present to auditors as evidence of consistent enforcement across the full audit year, closing the gap that arises when administrators make undocumented changes without understanding the SOX implications.
Organizations continue to identify cases where terminated employees retain system access without a valid business reason. While this is a well-known ITGC issue, the underlying cause has shifted in recent years.
Many companies now rely heavily on SSO platforms, HR integrations, or automated scripts to deprovision access upon termination. This increased reliance often leads to high confidence in the effectiveness of the process. In practice, however, access gaps still occur – regardless of the technology or automation in place.
These gaps typically arise from edge cases, system limitations, integration failures, or identities and applications that fall outside standard SSO coverage.
From an audit standpoint, terminated user access represents a clear control failure. The challenge is not awareness of the risk, but the timing of detection. Because organizations assume automation is working as intended, issues are often discovered late in the audit cycle, when remediation options are limited.
Auditors increasingly scrutinize whether automated controls are complemented by sufficient monitoring and validation, rather than accepted at face value.
More mature teams continuously expand and refine their automation coverage while acknowledging its limitations. They supplement automated deprovisioning with independent monitoring of terminated users, focusing specifically on access paths that automation cannot reliably control.
Stronger teams also account for edge cases – such as vendor defects, non-standard identities, and local or legacy accounts – and ensure these are actively reviewed rather than implicitly trusted to automation.
Scytale supplements deprovisioning automation with independent, continuous monitoring that does not rely on SSO coverage being complete. By integrating directly with HR systems, identity providers, and individual applications, Scytale continuously cross-references active access against termination records – including in systems outside SSO scope – and surfaces unresolved access in near real time. This means terminated access gaps are detected and flagged for remediation during the operating period, not discovered by auditors during fieldwork when remediation options are limited.
As SaaS platforms increasingly support financial reporting processes, audit populations are often derived directly from system logs and audit trails. However, not all SaaS solutions retain the data required to support SOX testing for the full audit period.
In some cases, audit logs are retained only for a portion of the year by default. As a result, when audit execution begins, the population needed to test the control no longer exists, causing the control to fail despite appropriate execution earlier in the period. This is frequently observed in areas such as Salesforce change logs.
In other cases, audit trails supporting remediation or administrative actions are retained for limited periods (e.g., 30 days in certain Azure configurations) or are not available at all, reducing the ability to validate corrective actions or confirm control operation.
From an audit standpoint, control effectiveness depends not only on execution, but on the ability to produce a complete and reliable population for the audit period. When audit trails are incomplete or unavailable due to retention limitations, auditors cannot rely on the population, resulting in control failures even when processes were followed in practice.
These issues are often discovered late in the audit cycle, when data cannot be recovered and remediation options are constrained.
More mature teams explicitly assess audit trail availability and retention requirements as part of every new SaaS implementation — not as an afterthought, but as a defined workstream before go-live. Where gaps exist between SOX requirements and system capabilities, they proactively mitigate risk by extending retention, increasing control frequency, implementing compensating controls, or working with vendors to obtain required data.
Stronger teams also confirm, at the start of each audit period, that audit trail configurations and retention settings have not changed, rather than assuming prior-year configurations remain in place. A configuration that was compliant last year may not be this year if a platform update reset a default setting.
Scytale’s automated evidence collection engine centralizes log ingestion from across the technology stack, including Salesforce and Netsuite, into a persistent, audit-ready repository that is not subject to the default retention limitations of individual SaaS platforms. Evidence is collected continuously throughout the year, meaning Scytale maintains a complete, structured population for every in-scope control period without depending on each platform’s native log retention. Scytale also monitors for changes to audit trail configurations and surfaces deviations from expected settings directly in the platform, catching the problem before data is lost rather than after.
As SaaS platforms increasingly support financial reporting processes, administrative access is decentralized across multiple teams and business functions. Systems may be owned by MIS, R&D, Finance, or other groups, resulting in administrative permissions being distributed across roles with overlapping and incompatible responsibilities — often without a single owner who has visibility into the combined access picture.
In some cases, administrative access is also granted to vendors, contractors, or other external parties, further increasing complexity and risk. Unlike earlier environments where a single, clearly defined administrator role existed per system, modern SaaS platforms often require administrators from different disciplines, each managing a slice of the system without full awareness of what the others can do.
In certain tools, the software itself does not support effective segregation of duties between administrative functions, forcing incompatible activities into a single role by design – a constraint that no amount of process improvement can fully resolve.
From an audit standpoint, administrative access represents a high-risk control area. When segregation of duties cannot be effectively enforced – due to decentralized access models, third-party administrators, or role design limitations – control effectiveness is undermined, even if administrative access reviews are performed on time and as designed.
Auditors increasingly assess not only whether administrative access is reviewed, but whether roles are appropriately designed, limited in scope, and aligned with business responsibilities and financial reporting risks. A certified access review that does not account for role conflicts or third-party administrators does not satisfy this expectation.
More mature teams explicitly recognize the risks introduced by decentralized administrative access and third-party administrators, and work to reduce privileged permissions to the minimum feasible population. They actively reassess administrative roles, review related audit trails, and eliminate incompatible responsibilities where possible.
Where segregation-of-duties conflicts are unavoidable by design, stronger teams formally document the limitation, engage vendors for clarification, and retain supporting documentation explaining system constraints. They also implement compensating controls and clearly document their risk assessment and mitigation rationale, demonstrating a thoughtful and defensible governance approach rather than leaving auditors to draw their own conclusions.
Scytale’s SOD Module automates the detection of segregation-of-duties conflicts by continuously mapping user roles and permissions against defined incompatibility rules, producing conflict reports that reflect the current access state rather than a snapshot from the last manual review. This means that when roles change, when new users are provisioned, or when platform configurations are updated, conflicts are identified immediately, not at the next scheduled review cycle. Where platform design prevents effective segregation, conflicts are formally recorded in the platform and risk assessments are retained, giving organizations the documented evidence auditors require to demonstrate that known limitations are understood, accepted, and actively managed rather than simply overlooked.
Change management remains a well-established SOX control, typically supported by ticketing systems, documented testing, and multiple approval steps prior to production deployment. However, maintaining discipline in this process has become more challenging as more systems move to cloud and SaaS platforms.
In many SaaS environments, it is difficult to clearly distinguish between changes executed by the company, changes performed by the vendor, and system-generated activity that appears in audit logs but does not represent an actual configuration or functional change. As a result, it becomes difficult to determine which events constitute in-scope changes for SOX purposes.
Additionally, some SaaS platforms allow certain changes to be made directly in production with minimal friction, increasing the risk of changes occurring outside the formal change management process. While some improvement has been observed compared to prior years, this remains a significant and recurring challenge.
From a SOX perspective, ineffective change identification undermines the ability to ensure that systems affecting financial reporting are modified only through approved and tested processes. When changes are easy to execute but difficult to identify or classify, the risk of unintended functionality, misconfiguration, or misuse increases.
This risk has always existed, but modern SaaS platforms make it both easier to implement changes outside formal change management processes and more difficult to consistently monitor them. The result is a control that may be well-designed on paper but is structurally difficult to enforce and evidence in practice.
More mature teams address this risk through a combination of process discipline and technical understanding. They ensure that formal change management procedures are clearly defined, communicated, and consistently executed – and critically, they invest time in understanding how each SaaS platform records and exposes changes at a technical level, so they know exactly what they are looking at when they pull an audit population.
In parallel, they continuously monitor system activity to identify changes that occur without prior documentation and act promptly to investigate and remediate exceptions. Stronger teams document these platform-specific behaviors formally, so that the logic behind their change population is transparent and defensible to auditors.
Scytale addresses the change identification challenge through native integrations with in-scope SaaS platforms, continuously monitoring system activity and surfacing configuration changes directly in the platform. Rather than relying on organizations to manually extract and interpret raw logs, Scytale presents a structured, filtered view of change activity – making it significantly easier to distinguish company-executed changes from vendor-initiated or system-generated activity. Where changes are identified that occurred outside the formal change management process, these are surfaced as exceptions for the control owner to investigate and document. This gives organizations a continuously maintained, audit-ready change population without the manual effort of constructing one from raw SaaS logs at the end of the year.
See more on how Scytale automates your ITGC audits and ensures continuous compliance.
