Key Insights:
Operational risk management (ORM) sits underneath nearly every engagement an audit or advisory firm runs. When the structure is solid, your team focuses on the right risks. When it isn't, scope drifts, frameworks overlap, and audit conclusions miss what the audit committee actually wants to know. This article covers what ORM is, how the major frameworks fit together, and how risk advisory and internal audit teams use it in practice.
Operational risk is the day-to-day risk that a business runs by virtue of operating: the risk that a process fails, a person makes a mistake, a system goes down, or something external disrupts the work. It is distinct from strategic risk (which is about the choices the business makes) and financial risk (which is about market and credit exposure), and it is the category that audit and advisory firms spend the most time on.
The standard way to break operational risk down is into four sources: process breakdowns, people failures, system failures, and external events. ORM is the practice of identifying those failure points and managing them before they cause loss.
For practitioners at audit and advisory firms, ORM means evaluating where the client's failure points actually sit and whether existing controls address them at the right level of the process.
No single framework covers operational risk end-to-end. The practical move on an ORM engagement is matching the right framework to the right phase of the work, then knowing where each one's coverage ends.
When you're evaluating board oversight and strategy alignment, COSO ERM gives you a clear structure. It organizes enterprise risk management around five components:
For SOX engagements, the COSO Internal Control-Integrated Framework remains your anchor for assessing internal controls over financial reporting.
When you need a practical process model, ISO 31000:2018 gives you principles and guidelines that work across industries and organization sizes. It is principles-based rather than a certifiable management system standard. That means you can use it as a process reference instead of a compliance target. That makes it useful when you want to embed risk management into day-to-day business activity.
You can think of the frameworks as playing different roles in the same engagement. COSO gives you governance structure. ISO 31000 gives you process discipline. The IIA standards define how you provide assurance over both. Most firms get better results by using each framework for the role it plays best.
When an engagement touches IT risk or cybersecurity, it's worth knowing that NIST SP 800-221 maps aspects of enterprise technology risk management to ISO 31000 and COSO concepts. That makes it a useful cross-reference rather than a separate framework to choose among.
The frameworks above tell you what good operational risk management looks like. The ORM process is how it actually gets done on an engagement. Most ORM processes follow the same arc: identify the risks the client is exposed to, assess how serious each one is, decide how to respond, and monitor whether the response is working.
The process typically starts with mapping the client's key processes, objectives, failure points, and external dependencies. It works best when iterative and organization-wide. Without context around risk appetite and system boundaries, assessments lack the specificity that makes them actionable. From there, teams assess likelihood and impact through a mix of qualitative judgment and quantitative data where available.
Once risks are assessed, management usually decides to accept, avoid, mitigate, or transfer the exposure based on risk appetite, control cost, and operational constraints. The practitioner's role is to evaluate whether that response makes sense and whether the controls support it in practice.
Teams typically test those decisions through four approaches:
The mix depends on engagement scope and client maturity.
In the NIST Risk Management Framework, the Monitor step focuses on maintaining ongoing situational awareness of security and privacy risks, including tracking controls and environmental changes that may affect their effectiveness. In practice, that means looking at whether the client has ongoing monitoring mechanisms rather than only periodic assessments. It also means considering whether those mechanisms feed reporting to the right decision-makers. A control environment that looks solid during annual testing but lacks continuous monitoring is worth highlighting in your findings.
Risk advisory firms don't usually run pure ORM engagements. The work shows up as something else: a SOC 2 audit, a HITRUST certification, a vendor program review, a SOX third-party assessment. ORM is the structure underneath those engagements that determines whether you're testing the right things in the right order.
When that structure is missing, clients feel it through duplicated requests, overlapping control reviews, and repeated testing across assurance teams. When it's there, the same body of work supports multiple framework deliverables, and the team spends its time on analysis rather than reconciliation. This section covers how that plays out across the engagement types where ORM thinking changes the most.
The same SOC 2 engagement looks different depending on where you start. Controls-first engagements list and test what's already in place; ORM-first engagements identify what could break, then evaluate whether existing controls actually address those risks. The second approach maps directly to the AICPA's Trust Services Criteria, which require service organizations to demonstrate controls over real risks to security, availability, processing integrity, confidentiality, and privacy.
HITRUST takes the same approach further. Its CSF harmonizes over 60 regulations and standards and tailors control requirements based on the organization's risk profile, system characteristics, and regulatory factors. Done well, a HITRUST engagement is an ORM exercise that produces a certification, not a checklist that produces documentation.
Most clients face overlapping framework obligations: SOC 2 for service customers, HITRUST for healthcare partners, PCI DSS for payment processing, ISO 27001 for international markets. ORM is what makes "test once, report many" possible. Without that structure, every framework becomes a separate engagement.
The integration usually organizes around shared control themes: access management, logging, vulnerability management, third-party oversight. A single set of access controls evaluated once can support testing across all four frameworks, with framework-specific reporting layered on top.
Third-party risk is another natural integration point. Vendor management auditing benefits from reviewing available independent assurance reports such as SOC 1 and SOC 2, along with ISACA guidance on vendor program controls. When you structure vendor risk within ORM, it connects to your SOC, cybersecurity, and financial control engagements rather than sitting in its own silo.
Even with cross-framework integration, documentation work still consumes a disproportionate share of ORM engagement time, leaving teams less capacity for analysis, client communication, and judgment-intensive work.
AI is changing the landscape. EY documented one engagement where AI cut risk assessment task time from 50 hours to 6 hours, an 88% reduction. Adoption is uneven, though. The IIA Pulse report found that about 41% of internal audit functions use generative AI, but most usage is infrequent and concentrated in narrow tasks. Most firms sit at Level 0 or 1 of the AI Maturity Framework, using general-purpose AI for isolated tasks rather than embedding it in the engagement workflow itself.
Fieldguide is an AI-native platform built for audit and advisory firms. Its engagement AI comes in two layers built to work together. AI Assist gives practitioners on-demand AI for the tasks they want to drive themselves: AI Chat for document-grounded answers with cited references, and AI Actions for column-level content generation. The Agent Workforce takes on the multi-step procedural work end-to-end: Field Agents like Field Auditor execute full workflows while practitioners review the output and apply judgment. For document-heavy ORM work, the two layers cover both ends of the engagement.
Two capabilities matter most:
The BerryDunn case study illustrates what this looks like in practice: the firm reported 30–50% efficiency gains and doubled its engagement capacity after adopting the platform. For ORM engagements that lean heavily on documentation, that capacity goes to the work that earns the fee: risk analysis, client communication, and the judgment AI can't make.
Operational risk management sits at the center of every risk advisory engagement your firm delivers. Fieldguide is an end-to-end AI-native platform purpose-built for audit and advisory firms, with the Agent Workforce, methodology depth, and audit-grade rigor needed to manage engagements from initial scoping through final reporting.
Practitioners stay accountable for scoping, testing, and forming conclusions while the Agent Workforce handles execution. Request a demo to see how it works.