Why Control-Gap Diagnosis Matters
A control test may identify an exception, but the exception alone does not explain what failed. A missing approval, an ineffective review, a missed review, and a review with no retained record require different responses. If they are treated as the same problem, remediation may address the visible symptom while leaving the process weakness in place.
Diagnosis begins with the control objective and the control as it is actually designed. The earlier material on control objectives, design effectiveness, operating effectiveness, and documentary evidence provides the necessary distinctions: a control must be capable of addressing the relevant risk, must operate as intended, and must be supported by evidence sufficient to evaluate it. This tutorial uses those distinctions to classify gaps and trace their causes.
Four Useful Gap Classifications
Classify the gap by asking what the evidence establishes about the control. These categories identify different failure points; they are not labels for the severity of a risk or a judgment about an individual’s effort.
| Classification | What it means | Diagnostic question |
|---|---|---|
| Absent | No control activity or assigned mechanism exists to address the objective. | Is there a control intended to perform this function? |
| Poorly designed | A control exists, but its scope, timing, criteria, responsibility, or authority is inadequate for the objective. | If performed exactly as specified, could it address the risk? |
| Inconsistently performed | The control is adequately designed, but it is not performed reliably, at the required frequency, or for the required items. | Did actual execution depart from an adequate design? |
| Unsupported by evidence | Available records do not establish whether the control operated or what it concluded. | Can operation be verified from reliable evidence? |
The categories can coexist in a finding. For example, a poorly designed control may also be performed inconsistently. State the primary gap that best explains the test result, then note any separate contributing weakness. An evidence limitation should also be stated accurately: inability to verify an activity is not, by itself, proof that the activity did not occur.
A Structured Diagnostic Method
A disciplined review moves from the control objective to observable facts, then to classification and cause. This order reduces the risk of starting with a favored explanation, such as “staff need more training,” before checking whether the control itself was workable.
Identify the risk the control is meant to address and the process point at which it should do so. A control cannot be assessed without knowing what it is intended to achieve.
Determine who performs the control, what items it covers, when it occurs, what criteria guide the decision, and what happens when an exception is found.
Ask whether faithful performance would address the relevant risk. If not, the gap is in design, even if the activity occurs every time.
Use appropriate evidence to establish whether the control operated for the intended population and period. Departures from an adequate design indicate inconsistent performance.
If the records do not establish what happened, say that operation is unsupported. Seek corroborating evidence before concluding the control was absent or missed.
Follow the workflow, responsibilities, systems, information, and escalation path to determine what condition produced the gap. Confirm the explanation against facts rather than treating an initial hypothesis as a finding.
From Finding to Root Cause
A test exception is an observation, not a complete causal explanation. “Three approvals were missing” describes what a reviewer saw. “The approval queue had no designated backup owner during staff absences” proposes a process condition that could explain why approvals were missed. The second statement is a candidate cause that must be checked against workflow records, responsibilities, and interviews.
A useful causal chain is objective → control requirement → observed condition → process mechanism → verified cause. Each link should be supported. For instance, if the objective is to prevent unauthorized changes, the control requirement might be independent approval before release. The observed condition could be a release without approval. The process mechanism might be that emergency changes bypass the standard queue. The cause might then be that the emergency procedure has no required independent authorization step. Simply calling the event “human error” does not explain why the process allowed it.
Useful follow-up questions are specific and testable: Who owned the task? What event initiated it? Was the expected data available? Was the control feasible within the processing deadline? What did the system record? Was there an escalation path? Did the same condition affect other transactions or periods? The aim is to identify a repeatable process explanation, not to assign blame.
Worked Example: Missing Approvals During Staff Absences
A hypothetical insurer requires an independent review of every high-severity reserve adjustment before posting. The procedure defines the review criteria, requires the reviewer to record approval or rejection in a workflow, and names both a primary reviewer and a trained alternate. The workflow generates a daily list of pending adjustments. A test finds that 3 of 12 sampled adjustments were posted without a recorded review. Workflow logs show that all 3 arrived during the primary reviewer’s absence; the alternate was available, but the assignments remained in the primary reviewer’s queue.
Step 1: Establish the objective and design. The objective is to ensure that each high-severity adjustment receives independent scrutiny before posting. The design specifies the full population, timing, review criteria, record of the decision, and alternate coverage. If followed, it is capable of addressing the stated objective.
Step 2: Compare performance with the design. Three sampled adjustments were posted without a recorded review. The control design was adequate, but these items did not follow it. The primary classification is inconsistently performed, not poorly designed.
Step 3: Trace the process cause. The logs show that the tasks stayed with the absent primary reviewer even though an alternate existed. The process cause is not simply “the reviewer was away”; the design already anticipated absence. The assignment process failed to route pending work to the alternate.
Conclusion and check. The finding should identify the three unreviewed adjustments, the failed reassignment mechanism, and the evidence supporting that explanation. The classification is checked against the design: if the workflow had automatically reassigned work and the alternate had ignored the tasks, the cause would instead concern execution by the alternate. Common mistake avoided: calling this a design failure merely because an absence occurred, without checking the specified backup arrangement and workflow logs.
Worked Example: A Review That Cannot Detect the Targeted Error
A hypothetical claims unit performs a monthly automated check on payments. Its documented objective is to identify duplicate payments. The check compares payment amounts and claimant identifiers, but only flags payments above $25,000. A test identifies two duplicate payments of $8,400 and $9,100. System logs confirm that the check ran on the full payment file each month and applied the documented threshold.
Step 1: Separate design from execution. The check operated consistently on the full file, so the finding is not explained by a missed run or omitted population. The question is whether the specified logic can meet its objective.
Step 2: Compare the rule with the objective. The objective covers duplicate payments, while the rule ignores every payment at or below $25,000. The two identified duplicates fall below that threshold. A duplicate-specific comparison would need to test relevant identifiers or payment references, rather than rely solely on amount.
Step 3: Classify and trace. The primary gap is poor design: faithful operation of the documented rule cannot identify all duplicates within the intended scope. A plausible process cause is that the check was configured around a high-dollar review threshold rather than the duplicate-payment objective. Confirm that explanation by reviewing the rule specification and how the threshold was selected.
Conclusion and check. The system logs show consistent execution, but they do not establish effectiveness against the objective. The classification is checked by asking whether running the same rule perfectly would have flagged the two payments; it would not. Common mistake avoided: calling the gap inconsistent performance because exceptions occurred, when the control ran as configured and the weakness is in its logic.
Worked Example: A Quarterly Review With No Retained Record
A hypothetical operations manager states that a quarterly review of privileged user access was completed for a 40-person unit. The review procedure requires examination of a dated access listing, a decision for each user, and sign-off by the manager. The manager recalls discussing several accounts, but the team cannot locate the listing, marked decisions, sign-off, or a workflow record. System access logs show that accounts remained active, but do not show whether the manager reviewed them.
Step 1: Determine what the evidence supports. The manager’s recollection is relevant but does not establish that all 40 accounts were reviewed or what decisions were made. Access logs establish account activity, not the occurrence of the review.
Step 2: Classify cautiously. The available evidence does not establish whether the review operated as specified. The primary classification is unsupported by evidence. It would be inaccurate to conclude from missing documentation alone that the review definitely did not occur.
Step 3: Trace a candidate cause and verify it. The required records were not retained or cannot be located. The reviewer should determine whether the review used an informal process with no recordkeeping step, whether records were stored in an unavailable location, or whether the records were deleted under a retention rule. These are distinct process explanations and require different evidence.
Conclusion and check. The finding should state that operation cannot be verified, identify the required records that were unavailable, and leave the factual question of performance unresolved unless further evidence answers it. If follow-up establishes that no review took place, the classification changes to absent or inconsistently performed depending on whether the control existed and whether the failure affected a period or item. Common mistake avoided: treating lack of documentation as conclusive proof of nonperformance.
Worked Example: No Control for a New Processing Route
A hypothetical insurer introduces a new digital channel for policy amendments. The existing process requires a supervisor to approve amendments submitted through the call-center system, but the digital channel sends amendments directly to the policy administration system. A walkthrough and system configuration review confirm that no approval rule, exception report, or other review covers digital amendments.
Step 1: Define the objective. The relevant objective is to ensure that amendments receive the required authorization before they change policy records.
Step 2: Establish whether a control exists for this route. The supervisor approval applies to call-center submissions only. The digital route has no equivalent approval or monitoring mechanism. This is not merely a missed performance of the call-center control; the new route falls outside its scope.
Step 3: Classify and trace. For digital amendments, the control is absent. The process cause is the channel implementation: the design of the new route did not include an authorization step or a control owner’s review of the route’s risk coverage. Confirm this cause against process maps, configuration, and implementation decisions.
Conclusion and check. The finding should identify the uncovered processing route and the missing control mechanism. The conclusion is checked by confirming that no other control addresses the same objective for these amendments. Common mistake avoided: labeling the gap inconsistent performance when no control was ever assigned to this channel.
Common Diagnostic Traps
- Confusing an exception with a design flaw. A control can be well designed and still be missed. Establish what the control requires before judging the design.
- Assuming that a control exists because a policy describes it. Confirm that the activity applies to the process route and population being assessed.
- Treating missing documentation as proof of absence. State the evidence limitation, then seek corroboration before concluding that the control did not occur.
- Stopping at “human error.” Ask why the process did not prevent, detect, or escalate the error, and verify the process explanation.
- Combining distinct gaps into one vague finding. If design, execution, and evidence each have separate deficiencies, describe them separately and identify their relationship.
Check Your Understanding
For each situation, identify the primary gap classification and the most defensible process cause or evidence conclusion.
- A hypothetical insurer’s procedure requires a daily reconciliation of policy counts between two systems. The reconciliation is adequately specified, but records show that it was completed on 18 of 20 business days because the assigned analyst’s queue was not monitored during a two-day absence. What is the primary classification and the process cause? (Answer: Inconsistently performed; the daily task lacked effective absence coverage or queue monitoring.)
- A hypothetical claims control is intended to identify duplicate invoices. It compares vendor names but does not compare invoice numbers or amounts; testing shows duplicates with slightly different vendor-name formatting. The check ran every week. What is the primary classification? (Answer: Poorly designed; its matching criteria cannot reliably identify duplicates when vendor-name formatting differs.)
- A manager says a monthly exception review occurred, but no report, sign-off, or system record is available. The system’s transaction log does not record reviews. What should the finding conclude? (Answer: Operation is unsupported by evidence; the missing records do not by themselves prove the review did not occur.)
- A new payment channel is found to have no approval requirement, no review report, and no control owner assigned, while the older channel has a documented approval control. What is the primary classification for the new channel? (Answer: Absent; no control mechanism addresses the approval objective for the new channel.)
- A well-specified monthly access review is performed and documented for every user, but the reviewer receives a listing that omits temporary privileged accounts. What is the primary classification, and why? (Answer: Poorly designed; the review operates as specified, but its information scope excludes a relevant user population.)