IT General Controls / Internal Controls  |  7 min read  |  Raayzel Business Consulting

IT General Controls: why the highest-frequency audit finding is also the most preventable

IT General Controls are the single most consistent source of audit findings across SOX compliance programmes, SOC engagements, internal audit reviews, and now Provision 29 material controls declarations. They appear at the top of deficiency lists year after year, across organisations of every size and sector, regardless of how mature their overall control environments are. And yet ITGCs are also among the most preventable categories of control failure, because the gaps that generate findings are well understood, consistently located, and almost always traceable to the same structural weaknesses rather than novel or unpredictable risks.

The persistence of ITGC deficiencies in the face of that predictability is one of the more revealing patterns in corporate governance. It tells you something important about the relationship between IT, finance, and audit functions in most organisations. The controls exist. The testing happens. The findings arrive anyway. And next year, in most organisations, a version of the same findings will arrive again.

This article examines why ITGCs fail with such regularity, where the structural weaknesses consistently appear, and what CFOs, Finance Directors, and internal audit functions need to address to break the cycle rather than manage it.

What ITGCs are and why they matter

IT General Controls are the controls that govern the integrity and security of the technology environment within which business processes and financial reporting operate. They are not application controls, which govern specific business processes within individual systems. They are the foundational controls that determine whether the applications producing financial data can be trusted to produce it accurately, completely, and securely.

The three core ITGC domains are change management, access management, and computer operations. Change management controls govern how changes to in-scope IT systems are authorised, tested, and implemented. Access management controls govern who has access to in-scope systems and data, at what level of privilege, and how that access is reviewed, modified, and removed. Computer operations controls govern how system availability, data integrity, and processing completeness are maintained and monitored.

The reason ITGCs matter so much to financial reporting assurance is direct and logical. A financial reporting system that can be changed without authorisation, accessed without appropriate controls, or operated without adequate monitoring cannot be relied upon to produce accurate and complete financial information. The auditor’s conclusion on financial statement accuracy depends, in part, on a conclusion that the IT environment producing the financial data is adequately controlled. When ITGCs fail, that conclusion is undermined, and the scope and cost of audit testing increases accordingly.

Under Provision 29 of the UK Corporate Governance Code, the connection between ITGCs and the board’s material controls declaration is direct. The IT systems that support financial reporting, operational processes, and compliance activities all depend on ITGC foundations. A board that declares its material controls effective without adequate evidence that the ITGCs underpinning those controls are operating cannot make a credible declaration. ITGC weakness is not a separate IT problem. It is a material controls problem.

Why change management is the most consequential ITGC domain

Change management is the ITGC domain that generates the most significant consequences when it fails and the one that most organisations find hardest to maintain consistently. The requirement is straightforward: changes to in-scope IT systems must be authorised before implementation, tested before deployment to production, and approved by an appropriate individual who is independent of the person who developed or implemented the change. Evidence of each step must be retained.

In practice, the change management process breaks down in predictable ways. Emergency changes are implemented under time pressure without following the standard authorisation and testing process, and the retrospective documentation that is supposed to capture the emergency approval is incomplete or missing. Developers have access to production environments that allows them to implement changes without going through the formal change management process, and those direct changes are not detected or documented. Approval evidence is generic rather than specific: an approval that says change approved does not demonstrate that the approver understood what was being changed, why it was necessary, or what the testing confirmed.

The migration to cloud infrastructure and hybrid IT environments has introduced a new layer of change management complexity that many organisations have not yet adequately addressed in their ITGC frameworks. Cloud service providers implement changes to underlying infrastructure continuously, and the organisation’s change management controls were typically designed for an on-premises environment where the company had direct control over the infrastructure. The question of how the organisation controls and evidences changes made by cloud providers to systems within scope of its ITGC framework is one that most ITGC programmes have not fully resolved.

The consequence of change management failure extends beyond the finding itself. When the change management process cannot demonstrate that all changes to in-scope systems were authorised and tested, the auditor cannot conclude that the system being tested at year-end is the same system that was operating throughout the year. That uncertainty requires additional substantive testing to compensate for the ITGC weakness, increasing audit cost and scope, and potentially delaying the audit opinion.

Access management: the highest-frequency finding with the clearest root cause

Access management generates more ITGC findings than any other domain, and the root cause is almost always the same: the process of managing user access across the lifecycle of joiners, movers, and leavers is not owned clearly enough by any single function to be executed consistently.

The joiners process creates access rights when a new user joins or takes on a new role. The movers process modifies access rights when a user’s role changes. The leavers process removes access rights when a user leaves the organisation or changes to a role that no longer requires the access. In most organisations, all three processes depend on coordination between IT, HR, and line management. None of them owns the end-to-end process. Each of them owns a component. And the gaps between the components are where access management findings are born.

The specific patterns that appear most consistently in access management findings are well documented. Terminated employees retain system access beyond the date their employment ended, because the offboarding process that triggers access removal did not execute promptly or completely. Users who have moved into new roles retain access from their previous role in addition to their new access, creating privilege accumulation over time that was never reviewed or approved. Privileged access, including administrator rights, is not reviewed with the frequency or rigour the control description specifies, so users who no longer require elevated privileges continue to hold them.

The periodic access review control is the mechanism that is supposed to catch these failures. Most organisations have a defined access review process: at regular intervals, a control owner reviews the list of users with access to each in-scope system and confirms that each user’s access is appropriate. The finding appears when the review was completed but exceptions identified during the review were not remediated within the timeframe specified in the control, or when the review was not completed on schedule, or when the evidence of the review is insufficient to demonstrate that it was performed with genuine scrutiny rather than as a documentation exercise.

The access management problem is rarely a technical problem. The systems to manage user access exist. The processes to conduct access reviews exist. The failure is operational: the people performing the controls do not have sufficient clarity about what they are responsible for, when they need to act, and what constitutes adequate evidence. That is a governance design problem, not a technology problem, and it is not solved by implementing a new identity management tool. It is solved by resolving the ownership ambiguity and building the operational discipline that makes the control function consistently.

Computer operations: the domain that is underscoped in most ITGC programmes

Computer operations controls govern system availability, data backup and recovery, job scheduling and processing completeness, and the monitoring of system performance and errors. They are the domain that most ITGC programmes address least rigorously, and the one where the gap between what the control framework describes and what actually happens is most often invisible until something goes wrong.

The backup and recovery controls are the most commonly tested within this domain. Most organisations have defined controls specifying how frequently backups are taken, where they are stored, how long they are retained, and how recovery capability is tested. The finding appears when backup testing has not been performed within the required timeframe, when recovery tests have identified failures that were not remediated, or when the backup scope does not cover all in-scope systems and data.

The job scheduling and processing completeness controls are less consistently designed and tested. These controls govern whether automated processes that produce or transform financial data complete successfully, whether failures are detected and escalated, and whether incomplete processing is identified before financial reporting is produced. In organisations that have migrated significant financial processing to cloud or SaaS platforms, the question of who monitors processing completeness within those platforms and how evidence of successful processing is generated and retained is often inadequately addressed.

The monitoring controls within computer operations are the ones that provide the earliest warning of ITGC breakdown. An organisation that monitors its systems effectively will detect access anomalies, change management bypass attempts, and processing failures before they become audit findings. An organisation whose monitoring is incomplete, retrospective, or not reviewed at an appropriate level of management is one where ITGC failures can accumulate undetected until the audit cycle begins.

The cloud and hybrid environment gap

The shift to cloud infrastructure, SaaS applications, and hybrid IT environments has created an ITGC gap that most programmes designed for on-premises environments have not adequately closed. The gap is structural: ITGC frameworks were built on the assumption that the organisation controls the infrastructure, the change process, and the access environment directly. In a cloud or SaaS context, significant elements of all three are managed by the service provider, and the organisation’s controls operate at a different layer of the stack.

The practical consequences are significant. Change management controls need to address both the organisation’s own changes to in-scope systems and the service provider’s changes to underlying infrastructure. Access management controls need to cover both direct access to in-scope applications and access to the cloud platforms, administrative consoles, and integration layers that connect them. Computer operations controls need to address the monitoring of cloud-hosted systems whose underlying infrastructure is not visible to the organisation’s IT function. The SOC 1 or SOC 2 report from the cloud or SaaS provider is the mechanism most organisations use to obtain assurance over the provider’s controls. The challenge that Raayzel identified in its earlier article on SOC audit readiness applies equally here: the SOC report tells you about the provider’s controls. It does not tell you whether the complementary user entity controls that the organisation is supposed to maintain, the controls on the organisation’s side of the responsibility boundary, are actually in place and operating. Most ITGC programmes have not adequately mapped and tested those complementary controls, and the gap between the SOC report’s scope and the organisation’s actual control obligations is where ITGC findings in cloud environments most often originate.

The relationship between ITGCs and the broader control environment

ITGC weaknesses do not exist in isolation. They have direct consequences for the reliability of every other control in the framework that depends on the IT environment. A financial reporting control that relies on system-generated reports to confirm completeness and accuracy cannot be relied upon if the change management controls over the system producing those reports have not operated effectively. An access control that prevents unauthorised journal entries cannot be assessed as effective if the access management controls over the system containing the journal entry function have generated findings.

This cascading effect is one of the most significant consequences of ITGC failure that CFOs and Finance Directors often underestimate. When ITGCs fail, the scope of the impact extends beyond the specific ITGC findings to every application control and financial reporting control that depends on the compromised IT environment. The auditor must either obtain additional compensating assurance through increased substantive testing or issue a qualification that reflects the limitation on the reliance it can place on the control environment.

Under the Provision 29 framework, this cascading effect has direct implications for the board’s material controls declaration. A board that has identified material controls across financial reporting, operational processes, and compliance activities needs to understand that the effectiveness of those controls depends on the ITGC foundations. A Provision 29 declaration that addresses application-level material controls without adequately evidencing the ITGC environment that underpins them is a declaration made on incomplete information.

Why the same findings keep appearing

The persistence of ITGC findings across audit cycles is not primarily a technical failure. It is a governance failure. The technical controls exist. The processes are designed. The policies are documented. The findings appear because the operational discipline required to execute those processes consistently, across the full joiner-mover-leaver lifecycle, throughout the full change management cycle, and across the complete scope of in-scope systems and environments, is not being maintained.

Three structural weaknesses explain the persistence more than any others. First, ITGC ownership is frequently shared across IT, finance, and line management without any single function carrying unambiguous accountability for the end-to-end control. Shared ownership in practice means that when a failure occurs, each function can point to the others, and the control gap persists in the space between them.

Second, ITGC testing in most organisations is conducted primarily to satisfy audit requirements rather than to provide genuine assurance. Testing happens when auditors arrive. Evidence is assembled for the testing population. Findings are remediated to close the audit cycle. And then the discipline that produced the clean testing population lapses until the next audit begins. The audit cycle drives the ITGC programme rather than the other way around.

Third, the connection between ITGC performance and financial reporting reliability is not adequately understood at CFO and board level. ITGC findings are managed as IT compliance matters rather than as financial reporting risk. The CFO who does not understand that a change management deficiency in the financial reporting system creates uncertainty about the accuracy of the financial data the system produces is not in a position to demand the governance investment that would prevent the deficiency from recurring.

What needs to change

Breaking the cycle of recurring ITGC findings requires addressing the structural weaknesses rather than managing the findings they produce. Three specific changes produce the most significant improvement in ITGC performance.

• Resolved ownership architecture: every ITGC control needs a single named owner with unambiguous accountability for its consistent operation, the evidence it generates, and the remediation of any failures. Where ITGCs sit at the boundary between IT, HR, and finance, the ownership decision needs to be made explicitly and documented, not left to the informal coordination that produces the ownership ambiguity in the first place. The owner needs to understand what the control requires, when it must be performed, and what constitutes adequate evidence, before the audit cycle begins.
• Continuous operation rather than audit-driven execution: ITGC controls need to operate as routine business activities rather than audit preparation exercises. Access reviews need to happen on schedule because the schedule exists and the owner is accountable for it, not because the auditors have arrived. Change management documentation needs to be completed at the time of the change, not assembled retrospectively. Backup testing needs to be completed and evidenced within the required timeframe regardless of where it falls in the audit calendar. The test of whether an ITGC programme is genuinely embedded is whether it would produce the same evidence population if the audit were moved forward by three months with no notice.

CFO and board visibility of ITGC performance: the CFO needs to receive regular information about ITGC performance, not only the audit findings that result from ITGC failure. A reporting mechanism that surfaces access review completion rates, change management compliance, and any exceptions or anomalies detected through monitoring on a defined cadence allows the CFO to identify emerging ITGC weakness before it becomes a finding and to make informed governance decisions about the IT controls investment the organisation needs. Under Provision 29, this visibility is also the governance evidence that demonstrates the board has monitored the controls that underpin its material controls declaration.

The governance question ITGCs are really asking

The recurring nature of ITGC findings is not primarily a story about technology. It is a story about governance. The question that persistent ITGC deficiencies are asking of CFOs, Finance Directors, and boards is one that goes beyond the specific control domains: does the organisation have the ownership clarity, the operational discipline, and the management visibility to maintain the IT control environment that its financial reporting and compliance obligations require, not just during audit cycles but continuously?

Most organisations that experience recurring ITGC findings can answer yes to some elements of that question and no to others. The ownership is partially clear. The discipline is partially maintained. The visibility is partially adequate. The findings appear in the gaps between the partial answers.

The organisations that achieve and sustain clean ITGC environments are those that have resolved all three elements simultaneously. They know who owns each control. They have built the operational routines that make execution independent of audit pressure. And they have given the CFO and the board the visibility to govern the IT control environment rather than simply receiving the audit findings it produces.

That governance architecture is achievable for organisations of every size. It is not primarily a technology investment. It is a governance design investment, and the return on it is measured not only in clean audit opinions but in the management time, audit cost, and remediation effort that persistent ITGC findings consume year after year when the investment is not made.

Raayzel works with CFOs, Finance Directors, internal audit functions, and boards to assess ITGC maturity, design ownership and accountability frameworks, build continuous operation programmes that reduce audit-driven dependency, and establish the management reporting that gives senior leadership genuine visibility of IT control performance. The work is advisory and execution-oriented, calibrated to the specific technology environment, audit scope, and governance architecture of each organisation.

Stay ahead of the IT controls and governance agenda.

Sign up for free insights and resources from Raayzel Business Consulting: https://lp.constantcontactpages.com/sl/sBV4psC/insights

Book a free 30-minute consultation with us: https://calendly.com/raayzelconsulting/30min