Introduction
A control is preventive when it is designed to stop an unwanted event before that event occurs. In an insurance process, the event might be an unauthorized policy being bound, an unsupported claim payment being released, or a user making a transaction they are not permitted to make. The timing matters: a control that reviews a completed transaction may help identify an exception, but it did not prevent that transaction from occurring.
The earlier material on control objectives and the risk-control link connects a control to the event it is intended to influence. Applying that link here means asking two questions: what event is the control intended to prevent, and does it act before that event? A control can reduce the chance of an event without eliminating it. It can also fail, be bypassed, or be poorly matched to the risk.
Classifying a Control by Its Timing
Classification depends on the event being considered. Suppose the event is “an unauthorized payment is released.” A required approval before release can be preventive because it can block the payment. A review of the payment file after release cannot prevent that release, even if it later prompts investigation or remediation. The same activity may be preventive with respect to one event but not another: a pre-bind authority check may prevent an unauthorized policy from being bound, while doing nothing to prevent a later data-entry error in a claim file.
A control objective describes the outcome sought, such as “only properly authorized risks are bound.” The control activity is the specific step used to pursue that objective, such as a system rule that rejects a submission above an underwriter’s authority. A policy stating that employees must follow authority limits is not, by itself, proof that each transaction is blocked when it exceeds a limit. For classification, identify the actual action, its timing, and the event it is intended to prevent.
| Question | What to identify | Why it matters |
|---|---|---|
| What is the unwanted event? | A specific action or condition, such as binding outside delegated authority | A control cannot be classified accurately without a defined event |
| When does the activity occur? | Before, during, or after the event | Preventive controls act before the event they target |
| What does it do? | Block, restrict, require approval, or enforce a precondition | Intent alone does not show that an activity can prevent the event |
| What assumptions limit the conclusion? | Whether the control is applied, its stated blocking rate, and possible bypasses | A designed control is not an absolute guarantee |
The central classification test is not whether a step is called a “control,” nor whether it involves a review. It is whether, for the event in question, the activity operates early enough and has a mechanism capable of preventing that event. A review before authorization can be preventive if it can stop the transaction. A review after the transaction is completed is not preventive for that transaction, even if it is valuable for other control purposes.
Why a Preventive Gate Can Reduce Events
A simple model makes the logic explicit. Suppose there are \(N\) attempted transactions, and each attempt would produce the unwanted event if it were not blocked. Let \(b\) be the probability that the preventive control blocks an attempt before the event. Assume the same blocking probability applies to every attempt and that an unblocked attempt results in the event. The probability of an event on one attempt is then \(1-b\), so the expected number of events is \(N(1-b)\).
This result follows by defining an indicator for each attempt: it equals 1 if that attempt is not blocked and 0 otherwise. Each indicator has expected value \(1-b\). The total event count is the sum of the indicators, so its expected value is the sum of their expectations, \(N(1-b)\). Independence between attempts is not needed for this expected-count result, although it would matter for some calculations about the distribution of the total count.
The model is deliberately limited. If some attempts would not have caused the event even without the control, the model must include that probability. If an unblocked attempt does not always cause the event, the model must also reflect that. The formula does not account for a control being disabled or systematically bypassed unless that possibility is included in \(b\). Treat the result as an estimate under stated assumptions, not as proof that the control is effective in practice.
Worked Example: Underwriting Authority Before Binding
A hypothetical insurer receives 16 submissions in one month that exceed the authority of the assigned underwriter. Without an effective gate, assume each would be bound without the required referral. A system check blocks 75% of these submissions before binding; every submission it does not block is bound. The average loss attributable to an improperly bound policy is estimated at $24,000. Estimate the number of unauthorized bindings and the associated expected loss after the gate. Identify the preventive control and a common calculation error.
Method. Treat the 16 submissions as attempts and use the stated blocking probability. This calculation assumes that the gate’s 75% blocking rate applies to these submissions and that unblocked submissions are bound.
Step 1: Calculate the fraction not blocked. The gate blocks 75%, so the fraction not blocked is \(1-0.75=0.25\).
The expected number of unauthorized bindings is 4. Here the result is a whole number, but expected counts need not be whole numbers in other examples.
Step 2: Calculate expected loss. Multiply the expected number of unauthorized bindings by the stated average loss per binding.
Check. Without the gate, the assumed count would be 16 and the corresponding loss would be \(16\times \$24{,}000=\$384{,}000\). The gate leaves one quarter of that modeled count and loss: \(0.25\times \$384{,}000=\$96{,}000\), consistent with the calculation.
Classification and common mistake. A system check that blocks an out-of-authority submission before binding is preventive for the event “unauthorized policy is bound.” A common error is to multiply 16 by 0.75 and report 12 unauthorized bindings. That is the number blocked, not the number that proceed. The correction is to use the unblocked fraction, \(1-0.75=0.25\), giving 4 expected bindings.
Approval Gates for Insurance Payments
A payment approval is preventive when approval is a condition that must be satisfied before the payment is released. The control objective might be to prevent unsupported invoices or claims from being paid. The activity could require an authorized approver to confirm specified documentation before release. The control is not preventive for a payment if the review occurs only after funds have been sent.
The distinction is about what the approval can do, not the job title of the reviewer. A manager’s signature after payment does not make the payment preventive. Conversely, an automated rule that stops release until required authorization is recorded may be preventive even though it does not involve a manager. A useful analysis names the event precisely, such as “an unsupported claim payment is released,” rather than broadly saying “payment risk.”
Worked Example: Approval Before Claim Payment
In a hypothetical claims unit, 12 of 180 payment requests in a month lack a required supporting document and would be paid if no pre-release check intervened. A workflow requires approval before release and blocks 75% of those unsupported requests. Assume every unsupported request not blocked is released, and each such payment creates an average loss of $2,500. Calculate the expected number of unsupported payments released and their expected loss. State why a post-payment review would be classified differently.
Method. Apply the blocking rate only to the 12 unsupported requests. The other 168 requests are not part of the stated calculation because the problem provides no reason to treat them as unsupported.
Step 1: Find the fraction of unsupported requests not blocked.
Step 2: Calculate the expected number released.
The expected number of unsupported payments released is 3.
Step 3: Calculate expected loss.
Check. If all 12 unsupported requests were paid, the modeled loss would be \(12\times \$2{,}500=\$30{,}000\). The gate leaves 25% of that amount: \(0.25\times \$30{,}000=\$7{,}500\).
Classification and common mistake. The required approval is preventive for unsupported payments because it can block release before funds are sent. A common mistake is to apply the 75% rate to all 180 requests, producing 45 requests, even though the stated blocking rate concerns the 12 unsupported requests. The correct calculation uses only the relevant group. A review performed after payment could identify an exception, but it could not prevent that payment’s release; it is not preventive for this event.
System Access as a Preventive Control
System access controls can prevent users from initiating or completing actions outside their permitted roles. Examples include requiring a unique user account, assigning permissions that limit which records a role can change, or blocking a transaction type unless the user has the required authority. The control should be linked to a defined event: for instance, “a user without payment authority changes a bank instruction.” Broadly stating “the system has security” does not identify what event is prevented or how.
For the access restriction to be preventive in design, it must act before the prohibited action is completed. A system that rejects the attempted change before saving it can prevent that change. A report that lists unauthorized changes after they have been saved does not prevent those changes, even if someone later reviews the report. This timing distinction is sufficient for classification; assessing whether the control is well designed or consistently operating is a separate task.
Worked Example: Restricting Changes to Payment Instructions
A hypothetical insurer records 40 attempts per quarter by users without payment-administration authority to change bank instructions. An access rule rejects 90% of these attempts before a change is saved; assume every unblocked attempt results in a completed change. Each completed unauthorized change has an estimated average loss of $8,000. Estimate the number of completed changes and expected loss under the rule. Then compare the access rule with a quarterly report reviewed after changes are made.
Method. Use the unblocked proportion of attempts to estimate completed changes, then multiply by the given average loss.
Step 1: Calculate the unblocked proportion.
Step 2: Estimate completed changes.
The model estimates 4 completed unauthorized changes per quarter.
Step 3: Calculate expected loss.
Check. Without blocking, the modeled loss would be \(40\times \$8{,}000=\$320{,}000\). Ten percent of that amount is $32,000, matching the estimate after the rule.
Classification and common mistake. The access rule is preventive for unauthorized changes because it rejects the action before the change is saved. A quarterly report reviewed after the changes are made is not preventive for those changes: it may reveal them, but it acts too late to block them. A common calculation error is to use 90% as the remaining proportion and report 36 completed changes. The 90% is the blocked fraction; the remaining 10% produces the 4 modeled changes.
Common Classification Traps
The main exam trap is to classify controls by their names or by the general purpose of the department rather than by timing and event. A “review” could be preventive if it is a required precondition and can stop the transaction. A “system control” could be preventive if it rejects an unauthorized action before completion. Neither label is enough without the sequence of events.
- Confusing blocked with unblocked. If a control blocks 80% of attempts, the proportion that can proceed is 20%, not 80%.
- Using the wrong population. Apply a stated rate only to the attempts or transactions to which it applies. Do not apply a rate for unsupported payments to every payment request.
- Treating a rule as a guarantee. A requirement or policy may express intent, but a control can fail, be bypassed, or be applied inconsistently. Do not infer perfect prevention unless the problem explicitly assumes it.
- Ignoring the event boundary. A gate may prevent a policy from being bound but does not automatically prevent every later error involving that policy.
- Calling a late review preventive. If the defined event has already happened before the review, the review did not prevent that event.
When a problem provides a blocking percentage and a loss per event, state the assumptions before calculating. In particular, clarify whether the percentage applies to all attempts or only a subset, whether unblocked attempts become events, and whether the loss figure applies to each event. This keeps the arithmetic tied to the control objective instead of turning a rate into an unsupported claim about actual performance.
Check Your Understanding
For each situation, identify the preventive control, if present, and use the stated assumptions to calculate the requested quantity.
- A hypothetical underwriting team has 10 submissions that exceed assigned authority. A pre-bind rule blocks 60%, and all unblocked submissions are bound. How many unauthorized bindings are expected? (Answer: 4 expected bindings.)
- A claims unit receives 90 payment requests, including 8 unsupported requests. A pre-release approval gate blocks 50% of unsupported requests; every unblocked unsupported request is paid. What is the expected number of unsupported payments released? (Answer: 4 expected payments.)
- There are 25 quarterly attempts to change customer bank details by users without the required permission. An access restriction blocks 92% before saving, and every unblocked attempt completes. Estimate completed unauthorized changes. (Answer: 2 expected changes.)
- A hypothetical insurer has 6 unsupported payment requests, each associated with an average loss of $3,200 if paid. A pre-release rule blocks 75% of these requests, and every unblocked request is paid. Calculate expected loss and name the fraction used. (Answer: $4,800 expected loss, using the 25% unblocked fraction.)
- An underwriter must receive a referral approval before binding any risk above a stated limit. A monthly report lists exceptions two weeks after binding. For the event “a risk above the limit is bound without referral,” which activity is preventive, and why is the report not preventive for that event? (Answer: The required pre-bind referral approval is preventive because it can stop binding before it occurs; the later report is not preventive because the binding has already occurred.)