9.3 Procedures to Test Control Efficiency

Key Takeaways

  • An effective control can still be inefficient: duplicate approval layers, manual re-keying of data the system already holds, or 100% checking of low-risk items that do not match the risk
  • Efficiency procedures measure cycle time the control adds, fully loaded cost versus risk reduced, exception rates, and whether an automated preventive control would replace after-the-fact detective cleanup
  • Do not call a slow but timely detective control 'ineffective' — slowness with timely detection is efficiency; detection too late for the risk is design or operating effectiveness
  • Match tone to the engagement: if economy or efficiency is in the assurance objective and criteria, you can conclude on inefficiency; if not, raise an advisory insight rather than inflating a control failure
  • A6c is still procedure selection for the work program — not work-program adequacy, resource budgeting, or domain methodology catalogs (Chapter 10)
Last updated: August 2026

9.3 Procedures to Test Control Efficiency

Quick Answer: Even a control that prevents or detects the risk can be inefficient. CIA Part 2 A6c tests whether you can identify procedures that measure cycle time, cost versus risk reduction, exception rates, and automated preventive versus after-the-fact detective placement. Do not call a slow but timely detective control ineffective. Match assurance versus advisory tone to whether efficiency is in the engagement objective and criteria.

Sections 9.1 and 9.2 asked whether the control could work and whether it did work. This section asks a different question: does it achieve the control objective with a reasonable consumption of resources relative to the risk? COSO and GIAS both treat effectiveness and efficiency of operations as a legitimate engagement concern — but only when you have criteria and an objective that let you say so. A6c is still procedure types for the work program, not an evaluation of whether the whole program is adequate and not a resource-budget chapter.

Effectiveness is not efficiency

ConceptQuestionA control can fail this while passing the other
Design adequacyIf followed, would it prevent or detect the risk in time?Four sequential approvals of every $75 supply invoice can be designed to prevent unauthorized payment — and still be wasteful
Operating effectivenessDid it operate as designed, all period, right people, right evidence?The four approvers all signed, every time
EfficiencyIs the residual-risk reduction worth the time, delay, and cost?Same four-layer control: long cycle time, high labor cost, almost no extra risk reduction versus a sound two-layer design

The exam trap is collapsing the third column into the word ineffective. Unauthorized payments were prevented. The control operated. Calling it ineffective because it is slow or expensive is a vocabulary error that will cost you the item. The right label is inefficient (or “effective but not economical”), and only as an assurance finding if efficiency is in scope with agreed criteria.

What inefficient-but-effective looks like

Memorize concrete patterns. The syllabus will dress them in new industries; the structure repeats.

Duplicate approvals. Policy and system already require a $5,000 single-approver threshold that is designed and operating. Local practice adds three more sequential approvers on every $50 office-supply invoice “for comfort.” If you tested operating effectiveness, you will find four signatures. That is not a win. Plan procedures that count approval layers versus the delegation-of-authority criterion and measure the elapsed time each extra layer adds.

Manual re-keying. Invoices already arrive through an electronic feed into the ERP. Clerks re-type vendor, amount, and invoice number into a second spreadsheet “so the supervisor can see them.” Re-keying introduces new error risk and labor. The original feed plus application match may already be the preventive control. Efficiency procedures compare touch time and error rates of re-keying versus using the system report.

Excessive checking of low-risk items. The team inspects 100% of invoices under $100 line by line, with the same intensity as $50,000 construction invoices. That is a management control-efficiency issue (and, if internal audit copies it, a work-program issue in Chapter 10). A6c wants you to identify tests of whether the activity’s own control intensity matches risk — not to celebrate a huge sample of petty items.

Detective cleanup that could be prevented at the source. A team spends the first ten days of every month manually reversing duplicate payments that an automated duplicate check at invoice entry would have blocked. The detective work may be operating effectively (duplicates are found and reversed). It is usually inefficient compared with a preventive application control, and the delay may also threaten design if cash is gone before detection.

Procedures to identify (the A6c toolkit)

ProcedureWhat you measureSuggests inefficiency when
Cycle timeElapsed time the control adds (invoice receipt → first approval → last approval → payment-run inclusion); queue time between layersDelay is long relative to the SLA and relative to extra detection value; extra layers sit idle in inboxes
Cost versus risk reductionFully loaded hours × rate, system or vendor cost, working-capital cost of delay, versus the residual risk the extra layer actually reducesCost of the extra control dwarfs the incremental risk it removes
Exception ratesHits from a detective control; override rates; reworkPersistent zero exceptions on a low-risk population may mean over-control; high exceptions may mean a missing preventive control upstream (that upstream gap is design/effectiveness, not “the detective control is inefficient”)
Automated versus after-the-fact detectiveWhere in the process the control sitsMonth-end cleanup after the loss is more expensive (and often later) than a source automated prevent

You obtain these measures with the same natures you already know — inquiry to find the intended path, inspection of time stamps and workflow history, data extracts of queue time, observation of re-keying, limited reperformance of a cheaper automated alternative — but you aim them at economy, not at “did the signature exist.”

Cycle time needs a definition (clock start, clock stop, exclusions) the same way Section 3.1 demanded specific criteria. “The process feels slow” is not a procedure. “Median hours from invoice scan to second approval, ERP time stamps, excluding valid holds, for invoices under $5,000” is a procedure.

Cost versus risk reduction is not a full actuarial model. Part 2 wants you to identify that you will compare incremental control cost to incremental risk reduction. Four approvers on $75 invoices do not reduce unauthorized-payment risk much if the first approver already has authority and the ERP blocks unapproved posts. They do consume four people’s time and stretch cycle time.

Exception rates need interpretation. A detective duplicate-payment report that catches items every week may be effective and may signal that preventive design upstream is weak. A detective report that has caught nothing for 18 months on a low-value, low-fraud population may be a candidate to reduce frequency or automate — an efficiency conversation, not an automatic “ineffective control” finding.

The trap: slow detective control labeled ineffective

This trap is named because it is cheap to write and easy to miss.

A month-end bank reconciliation is designed as a detective control to support cash completeness and to catch misappropriation before financial close. It routinely finishes on business day 8, all reconciling items are cleared, and the designed timetable is “complete before close.” Operating tests show it ran every month, by the right person, on complete IPE.

That control is effective. It is slower than a real-time bank feed. Slowness may be an efficiency (and maybe an advisory) point if a feed would cut cost or shrink the detection window without changing the conclusion that the designed detective control met its objective.

Contrast: the same reconciliation is completed 90 days after month-end. Cash fraud in week one cannot be detected in time to stop a second month of loss. Timeliness has failed relative to the risk. That is design (the control as designed cannot detect in time) or operating (the designed day-8 timetable was missed). It is not “merely inefficient.”

Rule you can quote: untimely relative to the risk = effectiveness/design. Costly or slower than a better method but still timely = efficiency. Do not use “slow” as a synonym for “ineffective.”

Assurance tone versus advisory tone

Internal audit engagements are assurance, advisory, or blended. Efficiency comments change clothes with the objective.

Efficiency is in the assurance objective — for example, the engagement will evaluate economy and efficiency of the shared-service AP process against the signed SLA and the board-approved cost-per-invoice target, and those criteria survived the Section 3.1 tests. Then A6c procedures support an assurance finding: the four-layer $75 approval operated effectively against the unauthorized-payment criterion and is inefficient against the SLA/cost criteria. Condition, criterion, cause, and effect still apply. You are not inventing a yardstick.

Efficiency is not in the assurance objective — the objective is accuracy and compliance of payments. The extra approval layers did not cause unauthorized payments. You may still see waste. The professional response is usually an advisory insight or opportunity for improvement: consider aligning layers to the delegation-of-authority policy; consider stopping re-keying. Do not inflate that insight into “the payment control is ineffective” in an assurance report. Relabeling an assurance engagement as advisory after you want to talk about efficiency, solely to dodge or to overclaim, is a quality problem — pick the objective in planning (Chapter 2) and keep the tone consistent.

Advisory work can comment on efficiency; that is often why management asked for it. Advisory still needs agreed criteria if you want management to act. “We think you have too many approvers” without a DOA policy, SLA, or cost target is a weak product in either channel.

Worked example: four layers on small invoices

Shared-service AP. Delegation of authority: one approver up to $5,000; two up to $25,000. Local desk procedure requires four sequential approvals on every invoice, including $75 supplies. Operating tests: all four signatures present all year; no unauthorized payments in the sample. Design of dual approval above $5,000 is sound.

Efficiency procedures to put in the work program:

  1. Extract workflow time stamps; compute median and 90th-percentile hours per approval layer for invoices under $5,000 versus $5,000–$25,000.
  2. Estimate fully loaded cost of layers three and four (volume × minutes × rate) and compare to residual unauthorized-payment risk already addressed by layer one plus the system block on unapproved posts.
  3. Inspect exception/override logs: do layers three and four ever stop an item layer one missed, or do they only add queue time?
  4. Compare an automated preventive path (system-enforced DOA thresholds) with the current after-the-fact email chasing of late approvers.
  5. Decide tone: if the engagement includes efficiency against the SLA of 10-day clean-invoice payment, the extra layers that push median cycle time to 14 days support an assurance inefficiency finding. If the engagement is payment accuracy only, write an advisory note. In neither case do you call the four-signature control ineffective solely because it is slow.

What this section is not

  • Not A6d: “is the work program adequate?” (Chapter 10).
  • Not A6e: testing methodologies by accounting, finance, IT, operations, or cybersecurity domain (Chapter 10).
  • Not A7: whether you have enough people, money, or tools (Chapter 10).
  • Not a license to skip operating tests of a high-risk control because testing it would be “inefficient” for internal audit. Auditor-hour economy is a resource/work-program issue. A6c is about the activity’s controls.

Exam traps

  • Calling a slow but timely detective control ineffective.
  • Treating four documented approvals as proof the small-invoice process is well controlled and well designed for economy.
  • Measuring “feelings about lean culture” instead of cycle time, cost, and exception rates.
  • Using efficiency language when detection is actually too late for the risk (that is effectiveness/design).
  • Writing a harsh assurance failure on efficiency when efficiency was never in the objective or criteria.
  • Confusing management’s 100% checks of low-risk items with a requirement that you sample 100% of low-risk items.

Efficiency procedures are complete when the work program can show how you will tell effective-but-wasteful from ineffective, and how you will say it in the correct assurance or advisory voice.

Loading diagram...
Effectiveness versus efficiency (do not mix the labels)
Illustrative efficiency index (100 = reasonable cost and delay relative to risk reduced)
Test Your Knowledge

Four sequential approvals are documented on every $75 supply invoice. Operating tests find all signatures present and no unauthorized payments. Delegation of authority already allows a single approver below $5,000. What is the best A6c response?

A
B
C
D
Test Your Knowledge

A month-end cash reconciliation finishes on business day 8, before close, with all items cleared, performed by the right person on complete reports. A teammate wants to call the control ineffective because a real-time bank feed would be faster. What should you do?

A
B
C
D
Test Your Knowledge

Which set of procedures best tests control efficiency rather than operating effectiveness?

A
B
C
D