The IT Audit Landscape in 2026: What Is Changing and What Auditors Must Do About It

Three years ago, the IT audit function was stable in a way that now feels like a different profession. Cloud was the main structural change. AI was a topic for the agenda, not a control domain. Regulatory volume was manageable. The four-phase audit cycle (plan, execute, report, follow up) fit the reality it was applied to.

That alignment is gone. The IT audit landscape in 2026 is being reshaped simultaneously by three forces that compound each other: AI tooling embedded inside the organisations being audited, regulatory volume and complexity accelerating faster than audit programmes can absorb, and a cloud and infrastructure control surface expanding faster than audit coverage can follow. Each force alone would require adaptation. Together they are forcing a rethink of what the function is actually for.

Force One: AI Is Inside the Environment Now

Microsoft Copilot is deployed across Microsoft 365 in most large financial institutions. Copilot Studio agents are being built on top of SharePoint and Teams data. ChatGPT Enterprise and Google Gemini are running in procurement, legal, and credit functions. In most cases, IT audit programmes have not caught up.

The control questions this creates are not speculative. Copilot can surface documents a user has no explicit permission to view, because its permissions model operates on the user's effective access: inherited group memberships the user, their manager, and the data owner are often unaware of. Prompt injection is a live risk in any Copilot Studio agent that ingests external content. Model cards are not audit artefacts. Most of the evidence needed for a generative AI audit does not exist in the format traditional audit programmes expect.

The IIA's 2024 Global Internal Audit Common Body of Knowledge identifies AI as the top emerging risk area for internal audit functions globally. DORA Article 9 requires ICT risk management to cover AI systems used in critical or important functions, an active obligation from January 2025 for in-scope institutions. The EU AI Act's high-risk classification for credit scoring and creditworthiness AI (Annex III, point 5b) triggers conformity assessment, Fundamental Rights Impact Assessment under Article 27, and human oversight requirements under Article 14. These are current audit scope items, not upcoming ones.

What this means in practice: AI governance needs to be a standing workstream in the IT audit plan, not a one-off project. The programme needs to cover model inventory, access governance for AI tools, prompt injection testing for agentic deployments, and evidence quality for AI-assisted decisions. The audit methodology for generative AI is covered in detail here.

Force Two: Regulatory Volume Is Outpacing Audit Coverage

DORA came into full application in January 2025. For any financial institution operating in the EU, or servicing EU clients with ICT systems, this is not a compliance project. It is a permanent operating model. Article 9 mandates ICT risk management with annual reviews. Article 11 requires business continuity testing. Article 13 requires continuous ICT monitoring. Articles 28 through 30 create an ICT third-party risk framework with contractual minimums, register obligations, and critical ICT TPP supervision by the ESAs.

The FFIEC CAT has been updated with AI maturity domains. MAS TRM 2024 revisions introduced cloud resilience and AI governance expectations for Singapore-regulated institutions. The FCA and PRA published a joint AI discussion paper in 2025. SEBI has issued guidance on AI use in securities market intermediaries. RBI's FREE-AI framework covers AI in financial services with 26 recommendations across six pillars.

No single IT audit programme covers all of this in a traditional annual cycle. The function has to make explicit prioritisation decisions: which regulatory obligations create the highest consequence for control failure, which are most likely to have gaps in the current environment, and which can be addressed through existing workstreams. That prioritisation requires current regulatory intelligence, not a once-a-year framework review.

The practical consequence for audit plans: the regulatory calendar needs to drive audit scheduling, not just inform it. DORA ICT testing obligations require annual penetration testing and biennial threat-led testing. Those dates are fixed. Build the plan around them, not around convenient quarterly cycles.

Force Three: The Control Surface Is Expanding Faster Than Audit Coverage

Cloud has been the dominant IT audit challenge for the past decade. What has changed is the rate of expansion and the complexity of what is being deployed. Multi-cloud is the default for large institutions. Kubernetes clusters are running production workloads. Infrastructure-as-code means configuration is version-controlled, but it also means configuration drift is a pipeline problem rather than a change management problem. Serverless functions are executing business logic with no server to audit.

Privileged access is the most persistent gap. IAM and PAM controls are consistently the highest-frequency finding in technology audit programmes. The problem is structural: cloud environments create privileged access pathways invisible to traditional access reviews. Service accounts, managed identities, workload identities, federation trusts, and cross-account role assumptions all create elevation paths that do not appear in any joiner-mover-leaver process. Most audit programmes are still reviewing access through the lens of user accounts.

The ISACA State of Cybersecurity 2024 survey identified cloud security and IAM as the two most common skill gaps in audit and security functions globally. This is not a training problem. It is a recruitment and capability design problem. An IT audit function that cannot test cloud IAM controls cannot provide reliable assurance on cloud risk. The gap between what auditors are testing and what actually carries the risk is widening.

What the Function Needs to Become

The traditional IT audit function was designed around a stable control environment, annual cycles, and evidence that existed in documents and databases. None of those assumptions hold for most large organisations in 2026.

The shift required is from compliance verification to control engineering assessment. The question changes from "does the control exist and was it operating effectively during the period?" to "is the control design sound, is the evidence architecture defensible, and will this hold under regulatory scrutiny or incident investigation?" That is a more demanding question. It requires deeper technical knowledge, earlier engagement in project lifecycles, and a willingness to give uncomfortable opinions about control adequacy rather than just documenting findings against criteria.

Continuous auditing is part of the answer but not all of it. Continuous monitoring of control signals (access anomalies, configuration drift, patch coverage, logging completeness) reduces reliance on point-in-time testing. But it requires investment in tooling, data pipelines, and the analytical capability to distinguish signal from noise. Most audit functions are not there yet. The path runs through the CISA domains, particularly Domain 1 (Information System Auditing Process) and Domain 5 (Protection of Information Assets), the IIA GTAG on data analytics in audit, and the ISACA CISA review manual updated for 2025.

The auditors positioned well for the next three years are those who can operate across the technical and regulatory layers simultaneously: who understand what a Kubernetes RBAC misconfiguration looks like and what it means for a DORA ICT risk report, who can read a SOC 2 Type II report critically and identify what it does not cover, who can design an AI audit programme that produces evidence a regulator will find credible. That combination is rare. Building it inside your function is the audit leadership challenge of this period.

The Priority List

If you are building or retooling an IT audit function right now, the priority sequence is clear.

First, build AI governance into the standing audit plan as a permanent workstream. Cover model inventory, access governance for AI tools, prompt injection risk for agentic deployments, and evidence quality for AI-assisted decisions.

Second, map regulatory obligations by consequence and schedule the audit plan around them. DORA testing timelines are fixed. Work backwards from them.

Third, fix the IAM/PAM coverage gap. If access reviews are not covering cloud workload identities, service accounts, and cross-account trust relationships, there is a material blind spot in the programme.

Fourth, invest in continuous monitoring for the controls that carry the most risk: privileged access, configuration integrity, logging coverage. This is where the evidence architecture needs to go.

The IT audit landscape is not getting simpler. The function that is useful in 2028 is the one that stops trying to be a compliance checker and starts operating as a control engineering function.