Key Insights:
IT risk engagements tend to break in the same places. Scope creeps past planning. Evidence ends up scattered across the client's ticketing tool, SharePoint, and a shared inbox. The findings memo keeps growing without sharpening into something a board will act on. Clients are asking harder questions, too: AI exposure, fourth-party concentration, whether the cyber program would survive regulatory scrutiny. This article covers the IT risk categories practitioners encounter most often, the frameworks reshaping how engagements get scoped, and how AI is changing both what the work covers and how it gets done.
IT risk management is how an organization identifies, assesses, responds to, and monitors the risks tied to its technology, data, and the controls around them. The definition is the easy part. The real question is whether any of it actually drives decisions, and whether the scope you agreed to in planning still holds up by the time you're in fieldwork. Clients hire firms because that gap is hard to close on their own. In the 2025 EY poll, 69% of respondents named cybersecurity program assessments among the most valued technology risk mitigation services, and CTOs consistently point to data security and digital resilience as top reasons they bring in an audit and advisory firm.
The risk environment has shifted fast. When the IIA asked chief audit executives to rank their top risks for 2026 Risk in Focus, cybersecurity ranked first at 73%, digital disruption (including AI) came in at 48%, and regulatory change reached 41%.
Cybersecurity is still the risk practitioners encounter on most engagements, and even mature programs face frequent incidents. The threat landscape doesn't sit still: identity-based attacks have moved from edge cases to top concerns, and adversarial AI and AI-enabled attacks now sit alongside them as active vectors. That last category has grown large enough that AI is now its own IT risk discipline.
AI and model risk is the fastest-growing area practitioners are being asked to evaluate, and it spans more than the obvious model-output questions. Practitioners scope governance (who owns AI risk, what policy applies, how training data is handled), shadow AI (the systems business units are using outside IT's awareness), and the controls around vendor models the organization can't directly inspect. What makes the category distinct is its velocity: new model versions, new use cases, and new regulatory positions arrive faster than annual review cycles can absorb. The exposure also extends beyond the organization's own AI to the vendors and third-party models it depends on.
Third-party and vendor risk now sits well outside the boundaries of a traditional security questionnaire. Most clients rely on service providers for cloud and data center infrastructure, back-office processing, and even product delivery, which means third-party assessments increasingly carry regulatory scope: cyber disclosure, ESG, and AI usage monitoring on top of traditional vendor due diligence. Concentration creates downstream risk: when a critical provider has a problem, it becomes the client's data or infrastructure problem.
Data governance, cloud infrastructure, and operational technology round out the IT risk landscape practitioners encounter. Data governance gaps show up during access reviews, when no one can name who owns a given dataset. Cloud risk centers on the shared responsibility model. Clients often can't articulate what they own versus what sits with the provider. Operational technology sits outside the standard IT estate entirely, and getting it into scope is often the first negotiation of the engagement. Across all three, the lifecycle is the same: who owns the asset, what controls protect it, and how the client monitors it over time.
When you're assessing a client's IT risk management program, you're really looking at four things: how they frame risk, how they assess it, how they respond, and how they monitor over time. The cycle shows up at firm, business-unit, and project levels, and the same gaps tend to appear at each.
Without solid risk identification, the rest of the program is on shaky ground. The work itself isn't complicated: inventory the assets, identify the threats that target each one, document the vulnerabilities those threats could exploit, and map the controls already in place. Each asset-and-threat pair becomes a risk scenario, ideally with both a worst-case and a most-probable outcome attached. What separates a strong program from a weak one is whether the scenarios reflect the client's actual business processes or got lifted from a framework template years ago and never updated. The fastest check is asking when the register was last updated and what triggered the change.
Once scenarios exist on paper, the real test is whether anything downstream actually uses them.
Assessment turns the register from a list into a decision tool. Some clients lean on subject matter expert judgment; others build out quantitative models. Both approaches are valid under NIST SP 800-30 Rev. 1. What matters more is whether the output actually shapes resource allocation, control prioritization, and board reporting, or just produces a heat map nobody opens.
Response is the easier piece to test. You're looking for documented treatment decisions across the four standard options (avoid, mitigate, share, accept), with evidence each one was made deliberately rather than by default. A risk that's been accepted without an explicit owner and a review date is usually forgotten.
Programs often come apart at monitoring. Point-in-time assessments are everywhere; ongoing monitoring with defined key risk indicators and trigger thresholds is rare. What you're testing for is whether the KRIs are tied to specific risk scenarios rather than generic metrics, and whether breaches actually trigger documented follow-up. That's the gap that usually separates a Tier 1 (Partial) program from a Tier 3 (Repeatable) one under CSF 2.0.
The rules a firm tested against last year aren't necessarily the rules in play this year, and the reconciliation work is where engagement teams are spending their planning hours.
NIST CSF 2.0 anchors most cybersecurity scoping work today. Its distinguishing feature is the GOVERN function, which treats cybersecurity governance as a foundational function in its own right rather than embedding it under Identify the way CSF 1.1 did. CSF 2.0 also moved supply chain risk management into GOVERN, and broadened the audience from critical infrastructure to any organization of any size or sector.
For practitioners testing governance maturity, GOVERN provides a clear structure to evaluate against, covering organizational context; risk management strategy; roles, responsibilities, and authorities; policy; oversight; and supply chain risk management. The practical effect is that governance gaps now drive scoping as much as technical control gaps do.
The most time-sensitive change in this category is the IIA's Cybersecurity Topical Requirement, which became effective February 5, 2026. For internal audit clients, that creates reconciliation work no matter what framework they already use.
COBIT 2019 is still the current version, and most internal audit functions reference two risk-related processes from it: EDM03 (Ensured Risk Optimization) at the governance layer and APO12 (Managed Risk) at the management layer. Clients aligned to COBIT, or to NIST CSF or NIST SP 800-53, still have to map their existing testing against the new IIA requirement. The User Guide accompanying the requirement does the mapping work for them, and the IIA's published Q&A addresses the most common scoping questions. For firms advising on internal audit readiness, that reconciliation remains the engagement driver this year.
ISO is the steady one in the group. ISO 27005:2022 covers information security risk within the ISMS context and adapts ISO 31000:2018's general risk principles to that domain. Neither has been revised since their current editions, which makes scoping easier on engagements centered on ISO 27001 certification support. The framework isn't moving under you, so the testing approach you used last year still maps to the standard your client is being audited against this year.
Most clients don't walk in with mature programs. A Baker Tilly ERM study of 567 professionals found only 34% of organizations have complete ERM processes in place. That's a fourfold jump from 9% in 2010. Only 36% report agreed-upon risk taxonomies across functions, and those gaps show up directly in control design, governance, and monitoring practices.
Strong programs share a short list of traits practitioners can spot in the first walkthrough:
Many clients fall short on at least two of these dimensions.
Weak programs are just as easy to identify, and they often share the same shape:
Access controls are where the recurring findings tend to pile up. The Journal of Accountancy flags unauthorized access, excessive IT privileges, unauthorized master-file changes, and inability to access data when needed. When those issues show up together, you're not looking at one-off lapses. You're looking at a control environment that isn't catching them, and oversight that isn't catching it either.
That's where board oversight comes in, and where many programs run out of road. An EY board study found only 13% of boards report direct visibility into data, technology, and cybersecurity. The disconnect between what the board sees and the risk the organization actually carries is itself a finding worth surfacing in the report.
AI has reshaped the scope of IT risk engagements faster than most factors in the past two years. Many practices are adjusting while standards, tooling, and client expectations all move at once.
AI governance has settled into mainstream IT risk work. Two references are worth keeping handy: the IIA's AI framework (September 2024), which sets out where internal audit sits in providing assurance over AI controls, and KPMG guidance, which goes deep on AI risks and their controls.
The scoping work itself has a familiar shape. You're testing ownership of AI risk and controls, legal compliance (EU AI Act readiness is now a standard item), and whether AI initiatives align with what the business is actually trying to do. You're also looking at bias monitoring as practiced (not just documented in policy), and at how training data is sourced and governed.
Most of that is familiar territory. The piece that breaks the pattern is explainability. Some model types, generative AI in particular, don't break down into clean logic paths the way traditional systems do, so walkthroughs and trace techniques need to adapt. ISACA's new credentials (AAIA for auditors, AAIR for risk professionals) both center on this work.
AI is changing how IT risk engagements actually get done, not just what they cover. Practitioners are already using AI in risk work for evidence review at scale, risk-based audit planning, and control testing that runs more often than traditional periodic reviews. The advantage shows up clearest in volume: AI can scan dozens of policy and procedure documents at once and surface mismatches a manual reviewer would miss, like access-control language that contradicts what's in the change-management procedure.
For firms running IT risk engagements, AI-assisted evidence review and control testing directly affect engagement economics. Once assessors map documents to requirements, AI helps extract the relevant content, match it against test procedures, and draft findings documentation. That's where the timeline compression actually happens, and where the difference between a profitable engagement and an over-budget one tends to live.
As IT risk engagements grow broader and client turnaround expectations tighten, Fieldguide provides firms with a centralized platform to manage the entire workflow: scoping, evidence review, control testing, and reporting. This consolidation is vital, preventing engagement teams from being spread across disconnected tools, which is particularly critical for risk advisory practices managing concurrent engagements across multiple frameworks. While Field Agents execute the foundational work, practitioners maintain oversight, reviewing every output and owning the final judgment. Request a demo to see how the platform fits your IT risk practice.