An operational risk assessment helps you identify where everyday work can fail before that failure becomes a missed deadline, financial loss, compliance issue, or customer escalation. Yet many assessments end up as static spreadsheets rather than changing how work gets done.
A useful assessment connects each risk to a process, owner, control, response, and review cycle. This turns risk management from an annual documentation exercise into an operating discipline your team can execute and verify.
Operational Risk Comes From How Work Actually Happens
Operational risk is the possibility of loss or disruption caused by failed processes, people, systems, or external events. It exists in routine activities such as approving payments, onboarding vendors, fulfilling orders, managing customer data, and responding to incidents.
This makes operational risk different from broad strategic risks, such as entering the wrong market. It is rooted in execution: the handoffs, decisions, systems, permissions, and exceptions involved in getting work done.
Common sources include:
Process failure: A required step is skipped, performed incorrectly, or completed too late.
Human error: Someone enters incorrect data, misunderstands an instruction, or makes an inconsistent decision.
System failure: An application, integration, or data source becomes unavailable or produces an unexpected result.
Access failure: A person or AI agent has excessive permissions, missing credentials, or inappropriate access.
Third-party failure: A supplier, contractor, payment provider, or hosting partner does not meet its obligations.
External disruption: Weather, cyber incidents, regulatory changes, or infrastructure outages interrupt operations.
The goal is not to eliminate every possible risk. That would be prohibitively expensive and operationally unrealistic. Instead, you need to understand which failures matter most and apply proportionate controls.
A risk register records identified risks. An operational risk assessment goes further by evaluating each risk in context and deciding what to do about it. If your register does not influence procedures, approvals, monitoring, or ownership, it is only an inventory.
Map Risks to Processes, Not Departments
Starting with a blank list and asking managers what could go wrong usually produces vague entries such as “supplier risk” or “data quality.” These labels are too broad to control effectively.
Start with your critical processes instead. A process has a defined trigger, outcome, owner, sequence of work, and set of dependencies, giving your team something concrete to examine.
Prioritize Critical Processes
Create an initial inventory of the processes that affect revenue, customers, cash, compliance, security, and business continuity. You do not need to assess the entire company at once.
Good candidates include:
Customer onboarding and account changes
Order fulfillment or service delivery
Accounts payable and payment approval
Payroll and expense reimbursement
Vendor onboarding and renewal
Employee onboarding and offboarding
Data access and permission changes
Customer complaints and incident response
Regulatory reporting
Backup, recovery, and continuity procedures
For each process, document the trigger, expected outcome, owner, participants, systems, inputs, outputs, and external dependencies. A business process map can expose hidden handoffs and branches before you begin scoring risks.
Examine Specific Failure Modes
A failure mode is a specific way a process could break. “Invoice fraud” is more useful than “financial risk,” but it can still be more precise: “A bank detail change is accepted without independent verification, causing payment to an unauthorized account.”
Review every process using questions such as:
What happens if a required input is missing or wrong?
Where can one person initiate and approve the same action?
Which handoffs have no explicit acceptance criteria or deadline?
What happens if a system or integration is unavailable?
Where does judgment depend on undocumented knowledge?
Which exceptions bypass the standard procedure?
What customer, financial, legal, or security impact could result?
How would you know the failure had occurred?
Talk to the people performing the work, not only the process owner. Frontline employees usually know about workarounds, recurring exceptions, and unreliable systems that do not appear in formal documentation.
Score Inherent and Residual Risk Consistently
Risk scoring helps you compare failure modes and decide where to act first. Avoid creating a mathematically elaborate model that managers cannot apply consistently. A five-point scale for likelihood and impact is usually sufficient.
Score Likelihood and Impact
Use clear definitions for each score rather than relying on intuition.
Score | Likelihood | Impact |
|---|---|---|
1 | Rare; exceptional circumstances | Negligible disruption or loss |
2 | Unlikely; could occur occasionally | Minor, locally contained impact |
3 | Possible; has occurred before | Material rework, delay, or customer impact |
4 | Likely; occurs repeatedly | Major financial, compliance, or service impact |
5 | Almost certain or already recurring | Severe or potentially business-threatening impact |
Calculate the basic risk score as:
Risk score = likelihood × impact
This calculation produces a score from 1 to 25. You can classify 1–4 as low, 5–9 as moderate, 10–16 as high, and 17–25 as critical. Adjust the thresholds to your organization, but document them and apply them consistently.
Impact should reflect the consequences most relevant to your business. Consider financial loss, customer harm, operational downtime, regulatory exposure, data compromise, safety, and reputational damage.
Separate Inherent Risk From Residual Risk
Inherent risk is the exposure before considering existing controls. Residual risk is the exposure that remains after those controls are applied.
Suppose unauthorized vendor bank changes have a likelihood of 4 and an impact of 5. The inherent score is 20. Independent callback verification and dual approval may reduce the likelihood to 2, creating a residual score of 10.
This distinction matters because a high-risk process can be well controlled. Conversely, a moderate inherent risk can remain unacceptable if its controls exist only on paper.
Do not lower the residual score merely because a policy says a control should happen. Look for evidence that it operates consistently, such as completed approvals, access logs, reconciliations, review records, exception reports, or executed workflow histories.
Build an Assessment Your Team Can Use
Your assessment should contain enough detail to drive action without becoming difficult to maintain. The following fields form a practical template.
Field | What to record |
|---|---|
Process | The operational process exposed to the risk |
Failure mode | The specific event or breakdown that could occur |
Cause | Why the failure could happen |
Consequence | The operational, financial, customer, or compliance effect |
Existing controls | Preventive, detective, and corrective measures already operating |
Inherent score | Likelihood × impact before controls |
Control effectiveness | Effective, partially effective, ineffective, or untested |
Residual score | Likelihood × impact after controls |
Risk response | Accept, reduce, transfer, avoid, or prepare contingency |
Risk owner | Person accountable for keeping exposure within tolerance |
Action owner | Person responsible for a specific improvement |
Target date | Deadline for the agreed action |
Evidence | Proof that the control or action was completed |
Review trigger | Date or event that requires reassessment |
Use one row per distinct failure mode. Combining several unrelated risks in one row makes causes, controls, and ownership ambiguous.
Choose an Explicit Response
Every material risk needs one of five responses:
Accept: Take no additional action because the exposure is within tolerance.
Reduce: Add or improve controls to lower likelihood or impact.
Transfer: Shift part of the financial consequence through insurance or contractual terms.
Avoid: Stop the activity or redesign the process to remove the exposure.
Prepare: Establish a contingency or recovery procedure because prevention is insufficient.
Acceptance is a valid decision, but it should be conscious and authorized. Record who accepted the risk, why it is tolerable, and when the decision must be reviewed.
For high-impact disruptions that cannot be fully prevented, connect the assessment to a business continuity plan. Prevention and recovery are complementary, not interchangeable.
Turn Risk Treatments Into Executable Controls
A control is useful only when your team can perform it consistently and prove that it happened. “Managers review payments” is not an adequate control definition because it does not specify the threshold, reviewer, evidence, or response to a problem.
Define each control with six elements:
Trigger: When the control must run
Owner: Who performs or supervises it
Action: What must be checked or completed
Decision criteria: What passes, fails, or requires escalation
Evidence: What record proves execution
Exception path: What happens when the control fails
For example: “For every bank detail change, a finance team member who did not enter the request must call the vendor using a previously verified telephone number. The verifier records the call result, and a second approver releases the change. Failed verification blocks payment and opens an investigation task.”
Controls generally fall into three groups:
Preventive controls stop failures before they occur, such as access restrictions, validation rules, and approval gates.
Detective controls identify failures that have occurred, such as reconciliations, exception reports, and quality reviews.
Corrective controls contain the impact and restore normal operations, such as account suspension, data correction, rollback, or incident response.
A strong design usually combines all three. Preventive controls reduce frequency, while detective and corrective controls limit damage when prevention fails. For more examples, see the guide to internal controls for small businesses.
This is where static risk spreadsheets tend to fail. They describe what should happen but remain disconnected from live work. Move important treatments into executable SOPs and workflows with assigned steps, due dates, approval gates, structured data capture, and escalation rules.
In OKiDO, you can structure controls as versioned SOP templates, launch them as RUNs, and retain comments, submissions, approvals, files, and execution history in context. More complex treatments can use Systems for branching, parallel work, loops, gates, and exception routing. This gives managers a reviewable record showing whether the control operated, not merely a statement that it exists.
Review Risks as Operations Change
Annual review is too slow for processes that change frequently. New software, suppliers, regulations, AI agents, team structures, and customer commitments can alter exposure immediately.
Set a review frequency based on residual risk:
Critical risks: Monthly or after every significant event
High risks: Quarterly
Moderate risks: Every six months
Low risks: Annually
Also create event-based review triggers. Reassess a risk after an incident, near miss, control failure, audit finding, process redesign, system migration, material volume increase, regulatory change, or new third-party dependency.
Your review should answer four questions:
Has the likelihood or potential impact changed?
Are the controls still designed appropriately?
Is there evidence that the controls operate consistently?
Have new failure modes or dependencies appeared?
Track leading indicators where possible. Overdue approvals, rising exception volumes, repeated skipped steps, failed automations, and prolonged blocked work can reveal increasing exposure before a major incident occurs.
Versioning is equally important. When a procedure changes, existing work should retain the rules under which it began, while new work uses the approved revision. OKiDO pins live RUNs to their template version and records execution activity, making it easier to understand which control design applied at a particular time.
An operational risk assessment delivers value only when it changes execution. Map risks to real processes, score them consistently, define accountable responses, and turn treatments into controls that produce evidence.
OKiDO connects process documentation, SOPs, decision logic, systems, approvals, escalations, and audit trails in one operational context layer. Use it to move your risk assessment out of a spreadsheet and into governed workflows that humans and AI can execute reliably.
