Classifying Process, People, Systems, and External Risks

Why Source Classification Matters

Operational incidents can look similar in their consequences while arising from quite different sources. A delayed claim payment, for example, might follow an unclear procedure, an employee's mistake, a technology outage, or a natural hazard that interrupts access to the office. Classifying the source helps an organization describe its exposures consistently and see where different incidents share a cause.

The categories in this tutorial are process, people, systems, and external events. They are a practical way to organize operational risk exposures, not a claim that every incident has exactly one cause. An event may have one primary source and several contributing factors. The classification should make that distinction visible rather than forcing a complicated chain of events into a single label without explanation.

Definition: A process risk arises from the design, execution, or failure of a business procedure or workflow. A people risk arises from an individual's action, omission, capability, or conduct. A systems risk arises from the failure, inadequacy, or unavailability of technology or other systems used in operations. An external-event risk arises from a cause originating outside the organization, such as a natural hazard or disruption to an external service.

These categories refer to sources, not to the size of a loss or the department where it appears. A claim-processing error remains process-related even if the financial loss is recorded in a claims unit. A storm that damages an office is an external event even if the resulting disruption is felt inside the organization.

A Consistent Classification Method

Start with the incident sequence: what happened first, what failed next, and what produced the operational consequence? Then identify the source of the initiating failure and any meaningful contributors. The goal is not to find a person or team to blame. It is to describe the mechanism that allowed the exposure to arise.

State the operational consequence.
Describe what went wrong in neutral terms, such as an incorrect payment, a delayed transaction, or an unavailable service.

Trace the sequence backward.
Identify the immediate failure and the earlier conditions that made it possible. Do not stop at the visible loss or disruption.

Assign a primary source.
Use the source most directly responsible for initiating the operational failure: procedure, individual action, system, or outside event.

Record contributors separately.
If other categories increased the likelihood or impact, retain them as contributing factors instead of silently treating them as additional primary incidents.

A useful distinction is whether the procedure itself was deficient or whether an individual failed to follow a sound procedure. If instructions are missing, ambiguous, or designed in a way that predictably permits an error, process is central. If a clear and workable procedure exists but an individual does not follow it, people may be central. If a technology component does not perform as intended, systems may be central. If the initiating cause lies outside the organization, such as a natural hazard, the external-event category is relevant.

The distinctions are not always clean. A person may make an error while using a poorly designed workflow, or an external hazard may expose a weakness in backup technology. In these cases, state the primary classification and the contributors, together with the facts that support the judgment. Where the evidence is insufficient to establish a primary source, note the uncertainty instead of presenting a guess as established cause.

Worked Classifications

Worked Example: Duplicate Claim Payments

A hypothetical insurer makes 300 duplicate claim payments totaling $180,000 during a quarter. A clerk submits a batch that includes records already paid. The clerk follows the written instructions, which do not require a duplicate check, and the payment system processes each submitted record as designed. Classify the primary source and any contributors. Explain why the visible employee action is not, by itself, enough to make this a people risk.

Step 1: State the consequence. The operational consequence is duplicate payments. The number of payments and total amount describe the incident's scale, but neither identifies its source.

Step 2: Trace the sequence. The records were resubmitted because the workflow did not include a check for prior payment. The clerk acted in accordance with the written instructions, and the system performed as designed.

Step 3: Assign the primary source. Classify the primary source as process. The missing duplicate-check step is the directly identified weakness that permitted already-paid records to proceed.

Step 4: Consider other categories. The facts do not establish a systems failure: the payment system processed the submitted records as intended. They do not establish a people failure: the clerk followed the available instructions. Thus, neither category should be added as a confirmed contributor on these facts.

Common mistake and correction. An incorrect entry would label the incident “people” solely because the clerk pressed the submit button. That confuses the person performing a step with the source of the failure. The correction is to classify the deficient workflow as primary and to avoid assigning individual error where the clerk followed the stated procedure. The method used is sequence tracing: follow the record from resubmission to payment and identify the first demonstrated weakness.

Worked Example: Deliberate Changes to Payment Instructions

In a hypothetical insurance operation, an employee knowingly changes a payee's bank details to divert a premium refund. The system accepts the employee's valid login, and the procedure allows one authorized employee to make the change without a second review. Classify the primary source and the contributing factors. Do not assume that the use of technology makes the event a systems failure.

Step 1: State the consequence. The refund is directed to an unauthorized account. This describes what happened, not why.

Step 2: Identify the initiating action. The employee knowingly changed the payee details to divert the refund. The deliberate action is the direct initiating source described in the scenario.

Step 3: Assign the primary source. Classify the primary source as people, specifically individual misconduct. The system accepted a valid login and behaved as configured; that fact alone does not demonstrate that the system malfunctioned.

Step 4: Record contributors. The procedure allowing one employee to make the change without a second review is a process contributor. It made the unauthorized change easier to complete or less likely to be detected. The available facts do not establish a systems defect.

Common mistake and correction. An incorrect classification might be “systems,” on the grounds that the transaction was entered through an application. The correction is to classify the source of the action, not the tool used to carry it out: here, the primary source is people, with process as a contributor. The method used is to separate the initiating act from the conditions that enabled it.

Worked Example: A Storm-Related Service Outage

A hypothetical insurer loses access to its regional office for two days after an exceptional storm causes a local power outage. The office's backup power equipment does not start because of a failed component. Staff cannot process time-sensitive transactions during the interruption. Classify the primary source and contributors, and distinguish the cause of the outage from its operational consequences.

Step 1: State the consequence. The office is unavailable and transactions are delayed. Those are operational consequences; they do not by themselves determine the source category.

Step 2: Trace the sequence. The storm caused a local power outage. The backup equipment then failed to start because a component had failed. Without functioning backup power, staff could not use the office to process transactions.

Step 3: Assign the primary source. On the stated facts, classify the primary initiating source as an external event: the storm and resulting local power outage originated outside the organization.

Step 4: Record contributors. The failed backup component is a systems contributor because backup equipment did not perform when needed. The classification does not assert that the organization caused the storm; it shows that an internal system weakness contributed to the operational impact.

Common mistake and correction. An incorrect entry would classify the whole incident as systems risk simply because backup equipment failed. The correction is to preserve the sequence: the external event initiated the interruption, while the systems failure contributed to the outage's effect. If further evidence showed that the equipment failure alone would have caused the same outage, the primary classification might need reconsideration. The method used is causal sequencing, not classification by the most visible failed asset.

Classifying a Set of Incidents

Source classification is also used to summarize a portfolio of operational events. A summary requires a consistent counting rule. If every event receives one primary category, the primary-category counts should add to the total number of events. Contributing categories can be tracked separately, but they should not be mixed into that same total as if they represented additional events.

For example, an event can be counted once under its primary source while also carrying a secondary tag for a contributing source. This preserves information about complex causes without inflating the number of incidents or making percentages appear to exceed 100 percent.

Worked Example: Summarizing Primary Sources

A hypothetical review covers 20 operational events. After reviewing the sequences, analysts assign one primary source to each: 8 process, 5 people, 4 systems, and 3 external events. Four of the 20 events also have a contributing factor from a different category. Calculate the share of events in each primary category, and explain why adding the contributing tags to the primary counts would be a mistake.

Step 1: Check the denominator. The primary counts sum to $8+5+4+3=20$, matching the 20 events reviewed.

Step 2: Calculate each primary share. Process is $8/20=40\%$. People is $5/20=25\%$. Systems is $4/20=20\%$. External events are $3/20=15\%$. These shares sum to $40\%+25\%+20\%+15\%=100\%$.

Step 3: Keep contributing tags separate. The four contributing tags describe additional factors in some of the same 20 events. They do not create four new events. Adding them to the primary counts would produce 24 category assignments while still using 20 events as the denominator. Those assignments would sum to $24/20=120\%$, which is not a valid partition of the event count.

Correction and check. Report the primary-source shares as 40%, 25%, 20%, and 15%, and report contributing factors in a separate analysis. The method is to use one primary category per event for the partition, then check that the counts sum to the event total and the shares sum to 100%.

Common Classification Traps

Classifying by consequence rather than source. A service delay is an outcome, not a source category. Trace what caused the delay.
Assuming any employee involvement means people risk. An individual may carry out a step in a deficient process without being the source of the failure.
Assuming use of technology means systems risk. A system can work as designed while enabling a process weakness or an individual's action.
Forcing a single category onto a causal chain. Use a primary source where the evidence supports one, and retain relevant contributing categories separately.
Counting contributing categories as additional events. For a primary-source breakdown, each event should be counted once; secondary tags belong in a separate summary.
Choosing a category without stating the evidence. Explain which step in the incident sequence supports the classification. If facts are incomplete, note the uncertainty.

Key takeaway: Classify operational risk by tracing how the incident arose, not by its financial consequence, the department involved, or the technology used. Identify a primary source when the evidence supports one, preserve meaningful contributors separately, and apply the same counting rule when summarizing events.

Check Your Understanding

For each scenario, identify the primary source, any supported contributing source, and the key fact that determines the classification.

A hypothetical insurer's claims procedure sends the same approved claim to two payment queues. Both payments are made; employees followed the procedure and the payment platform operated normally. (Answer: Primary source process; no people or systems contributor is established by the stated facts. The procedure created two payment paths.)
A staff member accidentally enters a payment amount incorrectly despite a clear instruction to copy the approved amount. The system records the amount as entered. (Answer: Primary source people, because the individual made an entry error contrary to a clear instruction; no system failure is stated.)
A regional flood blocks access to an office, and the office's backup network equipment also fails, preventing remote processing. (Answer: Primary source external event; systems is a contributing source because backup network equipment failed. The flood initiates the disruption.)
A manager reports 10 incidents: 4 primary process, 3 primary people, and 3 primary systems. Two of those incidents also have external-event contributing tags. What are the primary-category percentages, and should the contributing tags be added to the primary counts? (Answer: Process 40%, people 30%, systems 30%; no. The two tags describe contributors to existing events and should be summarized separately.)
A system produces a correct transaction according to its programmed rules, but the rules implement a procedure that permits refunds without confirming that the original payment cleared. Refunds are sent for uncleared payments. Classify the primary source and explain the distinction. (Answer: Primary source process, because the operational rule or workflow is deficient; systems is not established as a malfunction merely because the application executes that rule.)

What You'll Learn