Control Testing KRIs: Exception Rates, Repeat Findings, and Failed Retesting

TL;DR

• A control test exception rate is only meaningful with a baseline — an unexpectedly low rate may signal testing design gaps as much as strong control performance
• The KRIs most programs skip are repeat exception rate (same control fails twice in a row), failed retesting rate, and overdue coverage — all of which examiners flag before you do
• The OCC’s FY2025 Supervision Operating Plan specifically called out preventative controls for the first time; knowing which high-priority controls have been tested — and which haven’t — is now an exam-ready question
• Severity mix is more informative than exception count — a program surfacing 40 low-severity exceptions may be missing two critical failures underneath

Your control test came back with a 12% exception rate. Is that bad?

The honest answer: it depends on what you tested, what you expected, and what you’ve seen before.

A 12% rate on a high-volume, automated process might be alarming — controls at that scale should perform more consistently. The same rate on a manual review process with a small sample might indicate the test is working exactly as it should, surfacing the exceptions your testers were trained to find.

The problem for most programs is they’re measuring control testing results without a baseline, without a severity lens, and without the pattern metrics that actually predict what an examiner is going to find. They have exception counts. They don’t have control testing KRIs.

Here are the six that close the gap.

Why Control Testing KRIs Matter

The OCC’s Internal Control Comptroller’s Handbook defines effective internal control as a process designed to provide reasonable assurance about achievement of objectives in three areas: effectiveness and efficiency of operations, reliability of financial reporting, and compliance with applicable laws and regulations.

The testing component requires more than running tests. It requires knowing whether tests are surfacing genuine control performance — or producing false greens because the scope is narrow, the sample too small, or the same exceptions keep appearing without escalation.

In its FY2025 Bank Supervision Operating Plan, the OCC specifically called out preventative controls for the first time — instructing examiners to assess new and changed internal controls alongside incident response and operational resilience. The implication: the OCC is asking whether your highest-risk controls were tested before they failed, not after.

The FINRA 2026 Annual Regulatory Oversight Report reinforces this, specifically noting that firms should schedule periodic assessments of alerts and exception reports to confirm proper functioning — not as a checkbox, but as a risk signal.

The 6 Control Testing KRIs

KRI 1: Control Test Exception Rate

What it measures: The percentage of individual control tests within a testing cycle that returned at least one exception.

Why it matters: This is the foundation KRI, but it requires interpretation. An unexpectedly high exception rate signals control failures. An unexpectedly low rate — especially relative to prior cycles — may signal testing design problems: tests scoped too narrowly, samples too small, or criteria not rigorous enough to catch genuine failures.

Data source: Testing program results, tracked by control and testing cycle.

Owner: Second-line compliance or risk. Exception rate trends should be reviewed alongside testing design — a rate moving in an unexpected direction is a trigger to review methodology, not just control health.

KRI 2: Repeat Exception Rate

What it measures: The percentage of exceptions in the current cycle that also appeared in the immediately prior cycle for the same control.

Why it matters: A single exception signals a control gap. A repeat exception — same control, same failure mode, consecutive cycles — signals that remediation either didn’t happen or didn’t work. This is the metric most closely linked to examiner concern. The OCC has cited weak internal controls and repeat deficiencies as grounds for formal supervisory action in multiple enforcement contexts.

Data source: Testing results with control-ID linkage across cycles.

Owner: Control owner for initial remediation; second-line for escalation and retest scheduling. Any control reaching three consecutive exception cycles should trigger a formal root cause analysis and remediation plan — not just another corrective action note.

KRI 3: Failed Retesting Rate

What it measures: The percentage of controls retested following remediation that fail the retest.

Why it matters: Retesting is the quality gate on remediation. When a control fails on retest, it means the corrective action was insufficient — the root cause wasn’t addressed, the fix wasn’t implemented as described, or the control design itself is inadequate for the risk. Failed retesting is a leading indicator of issues program weakness: the CAP that produced the remediation likely had a similar design flaw.

Data source: Testing program results filtered for retest entries, with pass/fail outcome recorded separately from initial test results.

Owner: Second-line compliance, with mandatory escalation to the risk committee for any Critical control failing retest. Failed retests should trigger a revised CAP requirement — the original remediation was insufficient, and the new plan needs to explain why.

KRI 4: Exception Severity Mix

What it measures: The distribution of exceptions by severity tier — specifically the ratio of Critical/High exceptions to total exceptions in a testing cycle.

Why it matters: Exception count is a volume metric. Severity mix is a risk signal. A program surfacing 40 exceptions per cycle, all rated low severity, may be testing the wrong controls, applying insufficient severity criteria, or systematically downrating exceptions to avoid escalation. The ratio of high-severity exceptions to total, and how that ratio shifts, is often more informative than the total exception count.

Data source: Testing results with a severity field, tracked as a distribution over time.

Owner: Compliance testing function. The “zero high-severity exceptions in a high-risk area” pattern is counterintuitive but real — programs that never surface critical findings in complex, regulated areas deserve a testing design review before concluding controls are strong.

KRI 5: Control Owner Response Time

What it measures: The median days from exception identification to a documented first-response remediation commitment from the control owner.

Why it matters: Exceptions that sit unacknowledged signal that control owners don’t know they have a finding, don’t understand what’s expected of them, or don’t treat the testing program as authoritative. Response time is an early warning indicator for due date miss risk — owners who respond slowly to exceptions tend to miss their remediation targets.

Data source: Issues tracker or testing workflow, with timestamps for exception notification and first documented owner response.

Owner: Compliance testing function, with escalation to the owner’s functional head when amber. Slow response times often indicate that control owners don’t see testing as connected to their own accountability — a training and governance issue that response-time data surfaces.

KRI 6: Overdue Control Testing Rate

What it measures: The percentage of controls in your testing universe that are past their scheduled testing date.

Why it matters: Most programs focus on the quality of tests performed. The coverage question — which controls haven’t been tested at all, and how long since their last test — is the gap that examiners and auditors find first. The OCC’s Compliance Management Systems Handbook expects institutions to demonstrate that compliance monitoring systematically covers their risk universe — not just the controls that were convenient to test this quarter.

Data source: Testing schedule with planned dates, compared against actual completion dates, tracked at the control-universe level.

Owner: Compliance testing or operational risk. An overdue rate that is rising typically signals a capacity problem — the universe is larger than the team can cover at the required cadence. That’s a resourcing discussion for the risk committee, not an exception to track in silence.

Summary Table

What Examiners See in Testing Programs

The patterns OCC and FDIC examination teams tend to cite in control testing programs with gaps:

No written testing plan. The program doesn’t have a documented universe, cadence, sampling methodology, or criteria. Examiners cannot assess coverage without it — and the absence of a testing plan is itself an issues management finding.

Exception severity applied inconsistently. One examiner’s review shows similar failures rated differently across testers or time periods, making trend analysis unreliable and comparison across cycles impossible.

Repeat exceptions with no escalation trail. A control has failed testing twice in a row, but the issues log shows the same corrective action language both times, no root cause analysis, and no senior sign-off on the revised remediation approach.

Retesting not scheduled or documented. Controls with exceptions are closed in the issues tracker after a corrective action is implemented — but no retest was scheduled, no retest result is documented, and no one can confirm whether the fix worked.

The control testing techniques framework covers how to structure testing designs, sampling approaches, and evidence collection. The KRIs above are the monitoring layer that sits on top of that methodology — they tell you whether the methodology is working.

For KRI governance and ownership, the control testing KRIs should map clearly: compliance testing function as metric owner, control owners as data sources, and the risk committee as escalation recipient for red-threshold findings.

Calibrating Thresholds

The thresholds above assume a stable, established testing program. Calibration matters:

Build 4–6 cycles of baseline before applying amber/red thresholds. Early testing cycles produce exception rates that reflect the newness of testing, not steady-state control performance. Setting a red threshold before you have a baseline will generate false alarms.

Calibrate by control type. Automated controls in mature technology environments typically have lower exception rates than manual controls. Applying the same threshold to both obscures the signal from both.

Review testing design when thresholds behave unexpectedly. An exception rate dropping sharply from one cycle to the next usually reflects a testing change — scope, sample, or criteria — not an actual improvement across all controls.

Treat the overdue rate as a program-level metric, not just a scheduling issue. Rising overdue rates over multiple quarters indicate that either the testing universe is expanding faster than capacity, or the cadence was set without realistic resource assumptions. Both are management decisions, not testing-team failures.

So What?

Control testing KRIs close the loop between two functions that often operate without direct connection: the testing program that runs the controls and the risk program that reports on them.

Without these KRIs, your operational risk program can show stable indicators while the testing program is quietly accumulating repeat failures, missing retest deadlines, and losing coverage of high-risk controls.

The six KRIs above are not exotic. Most of the underlying data is already in your testing workflow or issues tracker. What’s missing, in most programs, is the extraction logic — the calculations that turn testing results into pattern signals rather than individual test outcomes.

If you can’t answer these questions from your program data today — which controls have failed twice in a row, what percentage failed retest, which controls are past their testing date — start there. The answers will tell you more about your program’s health than any single testing result.

The KRI Library includes pre-built control testing and compliance monitoring KRIs with threshold calibration guidance, alongside 132 indicators across operational, compliance, cyber, vendor, and BSA/AML risk domains.